Re: [openvrml-develop] ANN: OpenVRML 0.18.5

[Greg R. <ne...@po...>]

>> - D-Bus does _not_ automatically start openvrml-xembed on my box.  No clue
>>    how that's supposed to work.  The workaround mentioned on the list works,
>>    but the README is slightly misleading.

> You do have to install it for this to work.

Sorry, I meant to note that this was after I installed it (openvrml) via
"make install" as root.  Or did you mean D-Bus itself?

> It works (when it does)
> because OpenVRML installs a descriptor to a place that D-Bus knows
> about.  On Fedora, that's:

>         /usr/share/dbus-1/services/org.openvrml.BrowserControl.service

> If D-Bus is looking somewhere different on Debian, that would be a
> problem.

I have that directory, but there's no openvrml file in there.  Very strange.
I do see the relevant test and install command in my log, but it didn't work:

 [...]
----------------------------------------------------------------------
test -z "/usr/local/include/openvrml" || /bin/mkdir -p "/usr/local/include/openvrml"
 /usr/X11R6/bin/install -c -m 644 libopenvrml/openvrml-config.h libopenvrml/openvrml-common.h libopenvrml-gl/openvrml-gl-config.h libopenvrml-gl/openvrml-gl-common.h '/usr/local/include/openvrml'
test -z "/usr/local/share/dbus-1/services" || /bin/mkdir -p "/usr/local/share/dbus-1/services"
 /usr/X11R6/bin/install -c -m 644 openvrml-xembed/org.openvrml.BrowserControl.service '/usr/local/share/dbus-1/services'
make[4]: Leaving directory `/util/3D/openvrml-0.18.5/src'
make[3]: Leaving directory `/util/3D/openvrml-0.18.5/src'
make[2]: Leaving directory `/util/3D/openvrml-0.18.5/src'
make[1]: Leaving directory `/util/3D/openvrml-0.18.5/src'
Making install in data
 [...]

Not installed and later removed, either:

% ll -d /usr/share/dbus-1/services
drwxr-xr-x 2 root 4096 Aug  1  2009 /usr/share/dbus-1/services/

Weird.

>> Build:
>> 
>>  - AFAICT, it is flat out impossible to do a full openvrml build on reasonably
>>    modern Debian/Ubuntu.  Both xulrunner 1.9.1 (required due to some unique
>>    header file, according to configure) and 1.8.1 (the source of libmozjs)
>>    are required, and they cannot be installed simultaneously due to some
>>    unspecified conflict.  Ergo, no JS.

> That sounds like something you should complain to Debian's xulrunner
> package maintainers about.

Yes, this next section was more as a reference for others than explicit
bug-reporting.  Ubuntu has version 1.9.2 for either Karmic or Lucid, but
I don't have sufficient deb-fu to be able to pick that apart and see if
whatever conflict they saw has been resolved.  (xulrunner's dependency
list is even bigger than openvrml's, apparently, so I'm not inclined to
try building it manually.  The 44MB source tarball is none too inviting,
either.)

> This could probably be narrowed a bit.  But Boost upstream is
> distributed en masse; Debian has divided it up.

Not a complaint; I can use a modern Boost (and Java, doxygen, and even
ant) for other stuff, so I wanted a reasonably complete set.  But someone
working on Slackware, for example, would be feeling some serious pain at
all of the dependencies and sub-dependencies.  It's useful to have some
idea of what a "complete" list looks like.

>> sudo apt-get install xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support
>>    - [13.5MB of archives, 25.3MB of disk space]
>>    - [xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support]
>>    - [REMOVE libmozjs-dev xulrunner-1.9-dev]

> I don't think you can blame me or mozilla.org for this.  And ordinarily
> I really enjoy blaming mozilla.org for stuff.

Don't we all, don't we all...

Without knowing the nature of the putative incompatibility, it's hard to
judge.  The Debian/Ubuntu changelog wasn't much help.

> > The (single-threaded) first, non-JS build took 102 minutes on one of two
> >    1.6 GHz Atom 330's; build directory was 820 MB afterward.  Still chugging
> >    away on the second build to work around:

> Atoms are, of course, targeted at power efficiency rather than
> performance.  I have an Atom 330 myself.  It's a neat little machine.
> But I don't use it to build software.

Again, that wasn't a complaint, just a reference point for others.  I had
a (slightly) beefier machine but turned it off in favor of this sub-30W,
fanless wonderbox.  (I ended up adding a quiet, external USB fan last summer
since internal temps were approaching the hard drive's stated limits, but
it's still virtually inaudible.)

> FWIW, though, OpenVRML's build parallelizes well.  You should see some
> performance benefit from "make -jN" since the 330 has two cores with
> hyperthreading.  Of course, you may find yourself memory-limited.  But
> if you've installed 4 GB in the machine, I think you should be able to
> use -j4 safely.

Very good to know, thanks.  It's got only 2 GB and HT is disabled, but
there are two real cores in it, so I'll give -j2 a shot next time around.

> By comparison, an i7 920 using -j8 can build all of OpenVRML in about
> five minutes.

Nice.

> Are the other problem worlds publicly available?

I've just uploaded a tarball here:

	http://gregroelofs.com/test/grr-openvrml-0.18.5-test.tgz

Note that the hypnosphere one is _not_ mine; I believe someone in Europe,
possibly Austria, created it, but he didn't leave a name in the comments,
and I didn't keep a download reference.  Hopefully he won't mind...

> sdl-viewer doesn't use openvrml-xembed.  The idea behind openvrml-xembed
> is to have a single viewer backend that is usable as either a
> stand-alone viewer or a browser plug-in.

Huh...I completely missed that.  OK, that explains it.

> OpenVRML's renderer really needs a near-complete rewrite at this
> point. :-/

Ah, I thought maybe that had already happened in the last few years. :-)

>>  - dual Intel Atom 330 1.6 GHz, 2 GB RAM, Intel 945G graphics

> Ah, 2 GB.  Well, since you're using i686 instead of x86_64, "make -j4"
> is probably still doable.

I've got both Firefox and SeaMonkey resident and no swap, so I'll be a
bit conservative there....  It's just time, and the little box is happy
to chug away all night if need be.

>> - Ubuntu 2009.04 32-bit (64-bit box shipped that way, argh...)

> Fixable. :-)  But if you plan on using this to build software, I'd
> recommending 4 GB of RAM if you want to use x86_64 Linux.  gcc can
> consume a lot of memory; and IME, x86_64 can really nearly double its
> memory consumption.

Good to know, thanks.  If the box is capable of it, I may go straight to 8.

> Thanks for taking the time to hammer on OpenVRML.

Likewise. ;-)  It's great to have a working VRML viewer again; time to
start modeling the house.

Greg