Menu
▾
▴
openvrml-develop — OpenVRML developers mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(25) |
Dec
(46) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(3) |
Feb
(23) |
Mar
(6) |
Apr
(15) |
May
(16) |
Jun
(24) |
Jul
(16) |
Aug
(92) |
Sep
(31) |
Oct
(40) |
Nov
(24) |
Dec
(32) |
| 2002 |
Jan
(22) |
Feb
(4) |
Mar
(38) |
Apr
(52) |
May
(38) |
Jun
(61) |
Jul
(44) |
Aug
(9) |
Sep
(15) |
Oct
(13) |
Nov
(34) |
Dec
(25) |
| 2003 |
Jan
(26) |
Feb
(10) |
Mar
(10) |
Apr
(5) |
May
(30) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(29) |
Oct
(12) |
Nov
(18) |
Dec
(14) |
| 2004 |
Jan
(18) |
Feb
(23) |
Mar
(17) |
Apr
(17) |
May
(9) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(9) |
Dec
(29) |
| 2005 |
Jan
(37) |
Feb
(24) |
Mar
(6) |
Apr
(4) |
May
(2) |
Jun
(18) |
Jul
(3) |
Aug
(14) |
Sep
(6) |
Oct
(7) |
Nov
(25) |
Dec
(21) |
| 2006 |
Jan
(21) |
Feb
(17) |
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(4) |
Oct
(22) |
Nov
(31) |
Dec
(19) |
| 2007 |
Jan
(10) |
Feb
(9) |
Mar
(8) |
Apr
(4) |
May
(1) |
Jun
(8) |
Jul
(13) |
Aug
(2) |
Sep
(7) |
Oct
(8) |
Nov
(3) |
Dec
(5) |
| 2008 |
Jan
(13) |
Feb
(5) |
Mar
(7) |
Apr
(13) |
May
(12) |
Jun
(8) |
Jul
(24) |
Aug
(25) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(4) |
Feb
(13) |
Mar
(9) |
Apr
|
May
(2) |
Jun
|
Jul
(11) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
|
| 2010 |
Jan
(4) |
Feb
(11) |
Mar
(38) |
Apr
(7) |
May
(13) |
Jun
(4) |
Jul
(17) |
Aug
(1) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
|
| 2011 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
(6) |
May
(8) |
Jun
(2) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2012 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(7) |
Jun
(8) |
Jul
(1) |
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(4) |
Nov
(3) |
Dec
|
|
From: Andreas K. H. <and...@ph...> - 2010-03-15 09:56:31
|
This looks just like the problems I encountered on 0.18.3 on Gentoo. Sorry for not getting back to you so far. I did some quick tests with 0.18.5, saw problems and decided to investigate more before reporting. Then kept postponing this because of other stuff... More in the next days, Andreas > > - openvrml-player doesn't work at all. The best it manages is a single > > frame before crashing, and that only on extremely simple worlds. On at > > least a couple of occasions it chokes with signs of memory corruption: > > > > openvrml-player pngboxes.wrl > > ** (openvrml-xembed:26721): DEBUG: inserted reference to :1.197 > > get fences failed: -1 > > param: 6, val: 0 > > *** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0xb29b35e0 *** > > ======= Backtrace: ========= > > [snip] > > Ouch. > > The DEBUG message from openvrml-xembed is normal. Everything south of > that is not. > > I can reproduce this; I'll find out what's going on here. > > > and simultaneously this stuff showed up for any X event in the player window: > > > > ** (openvrml-player:26724): CRITICAL **: void<unnamed>::reset_fds(<unnamed>::CURLSource&): assertion `Invalid multi handle' failed > > [x many] > > That just means that openvrml-xembed has died unexpectedly and the > openvrml-player process doesn't know what to do. :-/ > > Are the other problem worlds publicly available? -- Dr. Andreas K. Huettel Institute for Experimental and Applied Physics University of Regensburg D-93040 Regensburg Germany tel. +49 151 241 67748 (mobile) e-mail ma...@ak... http://www.akhuettel.de/research/ |
|
From: Braden M. <br...@en...> - 2010-03-15 09:03:51
|
On Sun, 2010-03-14 at 21:39 -0700, Greg Roelofs wrote:
> Lots o' issues, a few successes...
>
> Docs:
>
> - README needs to call out libtool/libltdl as a required dependency.
Yes, it should.
> - 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. 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.
> 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.
> - The dependency list is...stunning. I had to install close to a gigabyte
> of additional stuff, and I already had a fairly decent development box.
> Extra/upgraded Ubuntu packages:
>
> sudo apt-get install libboost1.37-dev libboost1.37-doc
> - [51MB of archives, 183MB of disk space]
> - [gccxml libboost-date-time1.37-dev libboost-date-time1.37.0
> libboost-filesystem1.37-dev libboost-filesystem1.37.0
> libboost-graph1.37-dev libboost-graph1.37.0 libboost-iostreams1.37-dev
> libboost-iostreams1.37.0 libboost-program-options1.37-dev
> libboost-program-options1.37.0 libboost-python1.37-dev
> libboost-python1.37.0 libboost-regex1.37-dev libboost-regex1.37.0
> libboost-serialization1.37-dev libboost-serialization1.37.0
> libboost-signals1.37-dev libboost-signals1.37.0 libboost-system1.37-dev
> libboost-system1.37.0 libboost-test1.37-dev libboost-test1.37.0
> libboost-thread1.37-dev libboost-thread1.37.0 libboost-wave1.37-dev
> libboost-wave1.37.0 libboost1.37-dev libboost1.37-doc]
This could probably be narrowed a bit. But Boost upstream is
distributed en masse; Debian has divided it up.
> sudo apt-get install libpng-dev libjpeg-dev xulrunner-1.9-dev default-jdk libgl1-mesa-dev libglw1-mesa-dev libosmesa6-dev libgtkglext1 libgtkglext1-dev libcurl4-gnutls-dev libdbus-1-dev libdbus-glib-1-dev libsdl1.2debian-pulseaudio doxygen doxygen-doc
> - [25.5MB of archives, 110MB of disk space]
> - [comerr-dev default-jdk doxygen doxygen-doc libcurl4-gnutls-dev
> libdbus-1-dev libdbus-glib-1-dev libgcrypt11-dev libglw1-mesa
> libglw1-mesa-dev libgnutls-dev libgpg-error-dev libgtkglext1
> libgtkglext1-dev libidn11-dev libkadm55 libkrb5-dev libldap2-dev
> libnspr4-dev libnss3-dev libosmesa6 libosmesa6-dev
> libsdl1.2debian-pulseaudio libtasn1-3-dev libxmu-dev libxmu-headers
> openjdk-6-jdk xulrunner-1.9-dev]
> - [REMOVE libsdl1.2debian-alsa]
> sudo apt-get install gcj libgcj-dev libgcj-doc java-gcj-compat java-gcj-compat-dev ant
> - [96.7MB of archives, 604MB of disk space]
> - [ant-gcj ant-optional ant-optional-gcj antlr ecj ecj-gcj fastjar gcj-4.3
> gcj-4.3-base gappletviewer-4.3 gij gij-4.3 gjdoc java-gcj-compat-headless
> libantlr-java libantlr-java-gcj libbcel-java libecj-java libecj-java-gcj
> libgcj-bc libgcj-common libgcj9-0 libgcj9-0-awt libgcj9-dev libgcj9-jar
> libgcj9-src libjaxp1.3-java libjaxp1.3-java-gcj liblog4j1.2-java
> liblog4j1.2-java-gcj libmx4j-java libregexp-java libxerces2-java
> libxerces2-java-gcj]
Dude, I just need jni.h and javac. Blame this on the JDK and/or gcj
folks.
> sudo apt-get install libtool libtool-doc
> - [libltdl7-dev libtool libtool-doc]
> sudo apt-get install libxml2-dev libxml2-doc
> - [libxml2-dev libxml2-doc]
> sudo apt-get install libmozjs-dev
> - [libmozjs-dev]
> sudo apt-get install libgnomeui-dev libgnomeui-doc
> - [4102kB of archives, 21.7MB of disk space]
> - [libart-2.0-dev libavahi-client-dev libavahi-common-dev libavahi-glib-dev
> libbonobo2-dev libbonoboui2-dev libgail-dev libgconf2-dev
> libgnome-keyring-dev libgnome2-dev libgnomecanvas2-dev libgnomeui-dev
> libgnomeui-doc libgnomevfs2-dev libidl-dev liborbit2-dev libpopt-dev
> libselinux1-dev libsepol1-dev orbit2]
Well, that goes to show how much good being a good citizen and not
depending on deprecated GNOME libraries does me. (I'm talking to you,
gnomevfs2.)
> 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.
> 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.
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.
By comparison, an i7 920 using -j8 can build all of OpenVRML in about
five minutes.
> - I'm kind of amazed that, a month after release, nobody has yet noticed
> that JPEG is broken:
>
> if test X$enable_jpeg_textures = Xno; then
> JPEG_LIBS=""
> JPEG_LIBS="-ljpeg"
>
> cat >>confdefs.h <<\_ACEOF
> #define OPENVRML_ENABLE_JPEG_TEXTURES 1
> _ACEOF
>
> fi
>
> Yeah, not so much.
Argh. Missing comma in configure.ac.
> Install:
>
> - Where's sdl-viewer? Oh, buried down in an example directory. Given
> the issues with openvrml-player (below), it would probably be good to
> install sdl-viewer by default (maybe as openvrml-sdl-viewer, for
> consistency and general non-generic-ness).
I'd rather fix openvrml-player. But aside from issues with automatic
activation of openvrml-xembed, it's not clear to me that you're having
problems that aren't shared by sdl-viewer.
> Run:
>
> - openvrml-player doesn't work at all. The best it manages is a single
> frame before crashing, and that only on extremely simple worlds. On at
> least a couple of occasions it chokes with signs of memory corruption:
>
> openvrml-player pngboxes.wrl
> ** (openvrml-xembed:26721): DEBUG: inserted reference to :1.197
> get fences failed: -1
> param: 6, val: 0
> *** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0xb29b35e0 ***
> ======= Backtrace: =========
[snip]
Ouch.
The DEBUG message from openvrml-xembed is normal. Everything south of
that is not.
I can reproduce this; I'll find out what's going on here.
> and simultaneously this stuff showed up for any X event in the player window:
>
> ** (openvrml-player:26724): CRITICAL **: void<unnamed>::reset_fds(<unnamed>::CURLSource&): assertion `Invalid multi handle' failed
> [x many]
That just means that openvrml-xembed has died unexpectedly and the
openvrml-player process doesn't know what to do. :-/
Are the other problem worlds publicly available?
> - sdl-viewer, as someone else (Braden?) noted a few months back, does work
> (mostly), and it conveniently doesn't kill xembed even when the viewer
> aborts.
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.
> - Speaking of things that haven't changed since 2000, I see the Background
> node still doesn't transform with Viewpoint...I know I reported that bug
> many, many years ago.
OpenVRML's renderer really needs a near-complete rewrite at this
point. :-/
> - The normalized-vector warning is kind of annoying. I don't know how much
> more normalized it expects me to get, but if 6+ nines won't cut it, there's
> something wrong with the code:
>
> orientation -0.10618 0.98856 0.10712 1.5911
>
> sqrt(0.10618*0.10618 + 0.98856*0.98856 + 0.10712*0.10712)
> .99999988019999282397
>
> Not a big deal, obviously, but it's also 100% trivial to check whether
> the vector's within, say, 0.001 of 1.0, which should be "good enough."
Yes; OpenVRML's float comparison is probably being too picky.
> System particulars:
>
> - 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.
> - 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.
Thanks for taking the time to hammer on OpenVRML.
--
Braden McDaniel <br...@en...>
|
|
From: Greg R. <ne...@po...> - 2010-03-15 04:39:37
|
Lots o' issues, a few successes...
Docs:
- README needs to call out libtool/libltdl as a required dependency.
- 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.
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.
- The dependency list is...stunning. I had to install close to a gigabyte
of additional stuff, and I already had a fairly decent development box.
Extra/upgraded Ubuntu packages:
sudo apt-get install libboost1.37-dev libboost1.37-doc
- [51MB of archives, 183MB of disk space]
- [gccxml libboost-date-time1.37-dev libboost-date-time1.37.0
libboost-filesystem1.37-dev libboost-filesystem1.37.0
libboost-graph1.37-dev libboost-graph1.37.0 libboost-iostreams1.37-dev
libboost-iostreams1.37.0 libboost-program-options1.37-dev
libboost-program-options1.37.0 libboost-python1.37-dev
libboost-python1.37.0 libboost-regex1.37-dev libboost-regex1.37.0
libboost-serialization1.37-dev libboost-serialization1.37.0
libboost-signals1.37-dev libboost-signals1.37.0 libboost-system1.37-dev
libboost-system1.37.0 libboost-test1.37-dev libboost-test1.37.0
libboost-thread1.37-dev libboost-thread1.37.0 libboost-wave1.37-dev
libboost-wave1.37.0 libboost1.37-dev libboost1.37-doc]
sudo apt-get install libpng-dev libjpeg-dev xulrunner-1.9-dev default-jdk libgl1-mesa-dev libglw1-mesa-dev libosmesa6-dev libgtkglext1 libgtkglext1-dev libcurl4-gnutls-dev libdbus-1-dev libdbus-glib-1-dev libsdl1.2debian-pulseaudio doxygen doxygen-doc
- [25.5MB of archives, 110MB of disk space]
- [comerr-dev default-jdk doxygen doxygen-doc libcurl4-gnutls-dev
libdbus-1-dev libdbus-glib-1-dev libgcrypt11-dev libglw1-mesa
libglw1-mesa-dev libgnutls-dev libgpg-error-dev libgtkglext1
libgtkglext1-dev libidn11-dev libkadm55 libkrb5-dev libldap2-dev
libnspr4-dev libnss3-dev libosmesa6 libosmesa6-dev
libsdl1.2debian-pulseaudio libtasn1-3-dev libxmu-dev libxmu-headers
openjdk-6-jdk xulrunner-1.9-dev]
- [REMOVE libsdl1.2debian-alsa]
sudo apt-get install gcj libgcj-dev libgcj-doc java-gcj-compat java-gcj-compat-dev ant
- [96.7MB of archives, 604MB of disk space]
- [ant-gcj ant-optional ant-optional-gcj antlr ecj ecj-gcj fastjar gcj-4.3
gcj-4.3-base gappletviewer-4.3 gij gij-4.3 gjdoc java-gcj-compat-headless
libantlr-java libantlr-java-gcj libbcel-java libecj-java libecj-java-gcj
libgcj-bc libgcj-common libgcj9-0 libgcj9-0-awt libgcj9-dev libgcj9-jar
libgcj9-src libjaxp1.3-java libjaxp1.3-java-gcj liblog4j1.2-java
liblog4j1.2-java-gcj libmx4j-java libregexp-java libxerces2-java
libxerces2-java-gcj]
sudo apt-get install libtool libtool-doc
- [libltdl7-dev libtool libtool-doc]
sudo apt-get install libxml2-dev libxml2-doc
- [libxml2-dev libxml2-doc]
sudo apt-get install libmozjs-dev
- [libmozjs-dev]
sudo apt-get install libgnomeui-dev libgnomeui-doc
- [4102kB of archives, 21.7MB of disk space]
- [libart-2.0-dev libavahi-client-dev libavahi-common-dev libavahi-glib-dev
libbonobo2-dev libbonoboui2-dev libgail-dev libgconf2-dev
libgnome-keyring-dev libgnome2-dev libgnomecanvas2-dev libgnomeui-dev
libgnomeui-doc libgnomevfs2-dev libidl-dev liborbit2-dev libpopt-dev
libselinux1-dev libsepol1-dev orbit2]
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]
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:
- I'm kind of amazed that, a month after release, nobody has yet noticed
that JPEG is broken:
if test X$enable_jpeg_textures = Xno; then
JPEG_LIBS=""
JPEG_LIBS="-ljpeg"
cat >>confdefs.h <<\_ACEOF
#define OPENVRML_ENABLE_JPEG_TEXTURES 1
_ACEOF
fi
Yeah, not so much.
Install:
- Where's sdl-viewer? Oh, buried down in an example directory. Given
the issues with openvrml-player (below), it would probably be good to
install sdl-viewer by default (maybe as openvrml-sdl-viewer, for
consistency and general non-generic-ness).
Run:
- openvrml-player doesn't work at all. The best it manages is a single
frame before crashing, and that only on extremely simple worlds. On at
least a couple of occasions it chokes with signs of memory corruption:
openvrml-player pngboxes.wrl
** (openvrml-xembed:26721): DEBUG: inserted reference to :1.197
get fences failed: -1
param: 6, val: 0
*** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0xb29b35e0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb6c92604]
/lib/tls/i686/cmov/libc.so.6[0xb6c955d2]
/lib/tls/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb6c969c5]
/usr/lib/libglib-2.0.so.0(g_malloc+0x34)[0xb7567284]
/usr/lib/libglib-2.0.so.0(g_strdup+0x39)[0xb757ffa9]
/usr/lib/libgobject-2.0.so.0(g_value_set_string+0x7b)[0xb76240db]
/usr/lib/libdbus-glib-1.so.2[0xb7f5518e]
/usr/lib/libdbus-glib-1.so.2[0xb7f53a55]
/usr/lib/libdbus-glib-1.so.2[0xb7f53b9c]
/usr/lib/libdbus-glib-1.so.2[0xb7f51baf]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x1ab)[0xb75fcc7b]
/usr/lib/libgobject-2.0.so.0[0xb7612e57]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7b9)[0xb76144b9]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x26)[0xb7614936]
/usr/lib/libdbus-glib-1.so.2[0xb7f52e3f]
/lib/libdbus-1.so.3(dbus_connection_dispatch+0x395)[0xb7f180d5]
/usr/lib/libdbus-glib-1.so.2[0xb7f496bd]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1e8)[0xb755eb88]
/usr/lib/libglib-2.0.so.0[0xb75620eb]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1ca)[0xb75625ba]
/usr/local/libexec/openvrml-xembed[0x805675e]
/usr/local/libexec/openvrml-xembed(_ZNK5boost9function0IvEclEv+0x21)[0x8057a61]
/usr/lib/libboost_thread-mt.so.1.37.0(thread_proxy+0x68)[0xb6edf848]
/lib/tls/i686/cmov/libpthread.so.0[0xb6d8c4ff]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb6d0749e]
======= Memory map: ========
08048000-0806d000 r-xp 00000000 08:07 456472 /usr/local/libexec/openvrml-xembed
0806d000-0806e000 r--p 00025000 08:07 456472 /usr/local/libexec/openvrml-xembed
0806e000-0806f000 rw-p 00026000 08:07 456472 /usr/local/libexec/openvrml-xembed
0918b000-09271000 rw-p 0918b000 00:00 0 [heap]
adca8000-adca9000 ---p adca8000 00:00 0
adca9000-ae4a9000 rwxp adca9000 00:00 0
ae4a9000-ae4aa000 ---p ae4a9000 00:00 0
ae4aa000-aecaa000 rwxp ae4aa000 00:00 0
aecaa000-aecab000 ---p aecaa000 00:00 0
aecab000-af4ab000 rwxp aecab000 00:00 0
af4ab000-af4ac000 ---p af4ab000 00:00 0
af4ac000-afcac000 rwxp af4ac000 00:00 0
afcac000-afcad000 ---p afcac000 00:00 0
afcad000-b04ad000 rwxp afcad000 00:00 0
b04ad000-b04ae000 ---p b04ad000 00:00 0
b04ae000-b0cae000 rwxp b04ae000 00:00 0
b04ae000-b0cae000 rwxp b04ae000 00:00 0
b0cae000-b0caf000 ---p b0cae000 00:00 0
b0caf000-b14af000 rwxp b0caf000 00:00 0
b14af000-b1500000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1500000-b152c000 rw-p b1500000 00:00 0
b152c000-b1600000 ---p b152c000 00:00 0
b164e000-b169f000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b169f000-b16f0000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b16f0000-b1741000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1741000-b1792000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1792000-b17e3000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b17e3000-b1834000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1834000-b1885000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1885000-b18d6000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b18d6000-b1927000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1927000-b1978000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1978000-b19c9000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b19c9000-b1a1a000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1a1a000-b1a6b000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1a6b000-b1abc000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1abc000-b1b0d000 r--p 00000000 08:07 888953 /us
[7] Abort /usr/local/libexec/openvrml-xembed
and simultaneously this stuff showed up for any X event in the player window:
** (openvrml-player:26724): CRITICAL **: void<unnamed>::reset_fds(<unnamed>::CURLSource&): assertion `Invalid multi handle' failed
[x many]
A later run displayed a single frame before dying:
openvrml-player dodecahedron.wrl
** (openvrml-xembed:27181): DEBUG: inserted reference to :1.225
get fences failed: -1
param: 6, val: 0
splut:/data/vrml 1351> ** (openvrml-xembed:27181): DEBUG: erased references to :1.225
[7] Done /usr/local/libexec/openvrml-xembed
On a single-(JPEG-)texture, 12-polygon world, it coughed up a weird MIME-
type error/warning and displayed nothing at all:
openvrml-player dodecahedron.wrl
** (openvrml-xembed:27008): DEBUG: inserted reference to :1.219
get fences failed: -1
param: 6, val: 0
unexpected media type "application/octet-stream"
splut:/data/vrml 1346> ** (openvrml-xembed:27008): DEBUG: erased references to :1.219
[7] Done /usr/local/libexec/openvrml-xembed
(The constant killing of xembed is kind of frustrating, too.)
On a single-PixelTexture world, it did the single-frame display before
dying with a mutex failure:
openvrml-player hypnosphere-chek97.wrl
** (openvrml-xembed:27020): DEBUG: inserted reference to :1.222
get fences failed: -1
param: 6, val: 0
file:///data/vrml/hypnosphere-chek97.wrl:37:46: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:37:66: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:38:12: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:1979:44: warning: rotation axis should be a normalized vector
file:///data/vrml/hypnosphere-chek97.wrl:1988:37: warning: rotation axis should be a normalized vector
splut:/data/vrml 1349> openvrml-xembed: /usr/include/boost/thread/pthread/mutex.hpp:50: void boost::mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed.
[7] Abort /usr/local/libexec/openvrml-xembed
On a five-PNG/JPEG-texture world (mostly just plain polygons), it again
died without displaying anything:
openvrml-player cubicles.wrl
** (openvrml-xembed:27214): DEBUG: inserted reference to :1.236
get fences failed: -1
param: 6, val: 0
unexpected media type "application/octet-stream"
splut:/data/vrml/cubicles 1360> ** (openvrml-xembed:27214): DEBUG: erased references to :1.236
[7] Done /usr/local/libexec/openvrml-xembed
// blank slate...nothing displayed at all
- sdl-viewer, as someone else (Braden?) noted a few months back, does work
(mostly), and it conveniently doesn't kill xembed even when the viewer
aborts. It has some serious problems with this world, however (which is
highly ironic, given libvrml97's performance on it 10 or 12 years ago):
openvrml-sdl-viewer pngboxes.wrl
get fences failed: -1
param: 6, val: 0
Segmentation fault
DOH!
openvrml-sdl-viewer pngboxes.wrl
get fences failed: -1
param: 6, val: 0
*** glibc detected *** openvrml-sdl-viewer: corrupted double-linked list: 0x0a4d5e68 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7616604]
/lib/tls/i686/cmov/libc.so.6[0xb7618367]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb76185b6]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7812231]
/usr/local/lib/libopenvrml.so.9[0xb7b9594b]
/usr/local/lib/libopenvrml.so.9(_ZNK5boost9function0IvEclEv+0x2c)[0xb7b9af8c]
/usr/local/lib/libopenvrml.so.9(_ZN5boost6detail11thread_dataINS_9function0IvEEE3runEv+0x22)[0xb7b9b202]
/usr/lib/libboost_thread-mt.so.1.37.0(thread_proxy+0x68)[0xb7863848]
/lib/tls/i686/cmov/libpthread.so.0[0xb77104ff]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb768b49e]
======= Memory map: ========
08048000-08050000 r-xp 00000000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08050000-08051000 r--p 00007000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08051000-08052000 rw-p 00008000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
09c77000-0a532000 rw-p 09c77000 00:00 0 [heap]
acc00000-acc21000 rw-p acc00000 00:00 0
acc21000-acd00000 ---p acc21000 00:00 0
acd41000-acd42000 ---p acd41000 00:00 0
acd42000-ad542000 rwxp acd42000 00:00 0
ad542000-ad54a000 rw-s 00000000 00:09 6990848 /drm mm object (deleted)
ad54a000-ad54b000 ---p ad54a000 00:00 0
ad54b000-add4b000 rwxp ad54b000 00:00 0
add4b000-add4c000 ---p add4b000 00:00 0
add4c000-ae54c000 rwxp add4c000 00:00 0
ae54c000-ae554000 rw-s 00000000 00:09 6990846 /drm mm object (deleted)
ae554000-ae55c000 rw-s 00000000 00:09 6990844 /drm mm object (deleted)
ae55c000-ae564000 rw-s 00000000 00:09 6990842 /drm mm object (deleted)
ae564000-ae565000 ---p ae564000 00:00 0
ae565000-aed65000 rwxp ae565000 00:00 0
aed65000-aed66000 ---p aed65000 00:00 0
aed66000-af566000 rwxp aed66000 00:00 0
af566000-af56e000 rw-s 00000000 00:09 6990840 /drm mm object (deleted)
af56e000-af576000 rw-s 00000000 00:09 6990838 /drm mm object (deleted)
af576000-af57e000 rw-s 00000000 00:09 6990836 /drm mm object (deleted)
af57e000-af57f000 ---p af57e000 00:00 0
af57f000-afd7f000 rwxp af57f000 00:00 0
afd7f000-afd80000 ---p afd7f000 00:00 0
afd80000-b0580000 rwxp afd80000 00:00 0
b0580000-b0588000 rw-s 00000000 00:09 6990834 /drm mm object (deleted)
b0588000-b0589000 ---p b0588000 00:00 0
b0589000-b0d89000 rwxp b0589000 00:00 0
b0d89000-b0d8a000 ---p b0d89000 00:00 0
b0d8a000-b158a000 rwxp b0d8a000 00:00 0
b158a000-b1592000 rw-s 00000000 00:09 6990832 /drm mm object (deleted)
b1592000-b159a000 rw-s 00000000 00:09 6990830 /drm mm object (deleted)
b159a000-b15a2000 rw-s 00000000 00:09 6990828 /drm mm object (deleted)
b15a2000-b15aa000 rw-s 00000000 00:09 6990826 /drm mm object (deleted)
b15aa000-b15ab000 ---p b15aa000 00:00 0
b15ab000-b1dab000 rwxp b15ab000 00:00 0
b1dab000-b1db3000 rw-s 00000000 00:09 6990823 /drm mm object (deleted)
b1db3000-b1dbb000 rw-s 00000000 00:09 6990822 /drm mm object (deleted)
b1dbb000-b1dc3000 rw-s 00000000 00:09 6990820 /drm mm object (deleted)
b1dc3000-b1e14000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1e14000-b1e65000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1e65000-b1eb6000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1eb6000-b1f07000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1f07000-b1f58000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1f58000-b1fa9000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1fa9000-b1ffa000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b1ffa000-b204b000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b204b000-b209c000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b209c000-b20ed000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b20ed000-b213e000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b213e000-b218f000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b218f000-b21e0000 r--p 00000000 08:07 888953 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSerif.ttf
b21e0000Abort
DOH!
openvrml-sdl-viewer pngboxes.wrl
get fences failed: -1
param: 6, val: 0
*** glibc detected *** openvrml-sdl-viewer: free(): invalid pointer: 0x0989a1b0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb75ad604]
/lib/tls/i686/cmov/libc.so.6(cfree+0x96)[0xb75af5b6]
/usr/lib/dri/i915_dri.so(_mesa_align_free+0x1d)[0xb5dee40d]
/usr/lib/dri/i915_dri.so(_math_matrix_dtr+0x3d)[0xb5e30edd]
/usr/lib/dri/i915_dri.so[0xb5df1f43]
/usr/lib/dri/i915_dri.so(_mesa_free_matrix_data+0x52)[0xb5df1fc2]
/usr/lib/dri/i915_dri.so(_mesa_free_context_data+0x120)[0xb5db2ed0]
/usr/lib/dri/i915_dri.so(intelDestroyContext+0xf6)[0xb5d784d6]
/usr/lib/dri/i915_dri.so[0xb5d531c7]
/usr/lib/libGL.so.1[0xb7d8cfcc]
/usr/lib/libGL.so.1[0xb7d68bc5]
/usr/lib/libSDL-1.2.so.0[0xb7e7e886]
/usr/lib/libSDL-1.2.so.0[0xb7e82ce7]
/usr/lib/libSDL-1.2.so.0[0xb7e82f22]
/usr/lib/libSDL-1.2.so.0(SDL_VideoQuit+0x50)[0xb7e718a0]
/usr/lib/libSDL-1.2.so.0(SDL_QuitSubSystem+0x55)[0xb7e462e5]
/usr/lib/libSDL-1.2.so.0(SDL_Quit+0x1e)[0xb7e4636e]
/usr/lib/libSDL-1.2.so.0[0xb7e46bff]
[0xb7eed400]
/usr/lib/dri/i915_dri.so[0xb5d5e6fd]
/usr/lib/dri/i915_dri.so(_tnl_draw_prims+0xbf8)[0xb5e41558]
/usr/lib/dri/i915_dri.so(vbo_save_playback_vertex_list+0x351)[0xb5e3fd31]
/usr/lib/dri/i915_dri.so[0xb5dca63d]
/usr/lib/dri/i915_dri.so(_mesa_CallList+0x4a)[0xb5dcd4da]
/usr/local/lib/libopenvrml-gl.so.8(_ZN8openvrml2gl6viewer15do_insert_shellERKNS_13geometry_nodeEjRKSt6vectorINS_5vec3fESaIS6_EERKS5_IiSaIiEERKS5_INS_5colorESaISF_EESE_SA_SE_RKS5_INS_5vec2fESaISK_EESE_+0x58b)[0xb7e319db]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml6viewer12insert_shellERKNS_13geometry_nodeEjRKSt6vectorINS_5vec3fESaIS5_EERKS4_IiSaIiEERKS4_INS_5colorESaISE_EESD_S9_SD_RKS4_INS_5vec2fESaISJ_EESD_+0x57)[0xb7b3da97]
/usr/local/lib/openvrml/node/vrml97.so[0xb4b749f2]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml13geometry_node15render_geometryERNS_6viewerENS_17rendering_contextE+0x82)[0xb7ae42f2]
/usr/local/lib/openvrml/node/vrml97.so[0xb4b3af41]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb00ec]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb2570]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb00ec]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb2570]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb00ec]
/usr/local/lib/openvrml/node/vrml97.so[0xb4bb2570]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/openvrml/node/vrml97.so[0xb4a8a93c]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x74)[0xb7ae43c4]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml5scene6renderERNS_6viewerENS_17rendering_contextE+0x76)[0xb7b2ef66]
/usr/local/lib/libopenvrml.so.9(_ZN8openvrml7browser6renderEv+0x32b)[0xb7b37d2b]
/usr/local/lib/libopenvrml-gl.so.8(_ZN8openvrml2gl6viewer6redrawEv+0x11c)[0xb7e3029c]
openvrml-sdl-viewer[0x804cd97]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7554775]
openvrml-sdl-viewer[0x804bd01]
======= Memory map: ========
08048000-08050000 r-xp 00000000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08050000-08051000 r--p 00007000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
08051000-08052000 rw-p 00008000 08:07 325863 /usr/local/bin/openvrml-sdl-viewer
0981d000-09cf9000 rw-p 0981d000 00:00 0 [heap]
a0d92000-a0d93000 ---p a0d92000 00:00 0
a0d93000-a1593000 rwxp a0d93000 00:00 0
a1593000-a1594000 ---p a1593000 00:00 0
a1594000-a1d94000 rwxp a1594000 00:00 0
a1d94000-a1d95000 ---p a1d94000 00:00 0
a1d95000-a2595000 rwxp a1d95000 00:00 0
a2595000-a2596000 ---p a2595000 00:00 0
a2596000-a2d96000 rwxp a2596000 00:00 0
a2d96000-a2d97000 ---p a2d96000 00:00 0
a2d97000-a3597000 rwxp a2d97000 00:00 0
a3597000-a3598000 ---p a3597000 00:00 0
a3598000-a3d98000 rwxp a3598000 00:00 0
a3d98000-a3d99000 ---p a3d98000 00:00 0
a3d99000-a4599000 rwxp a3d99000 00:00 0
a4599000-a459a000 ---p a4599000 00:00 0
a459a000-a4d9a000 rwxp a459a000 00:00 0
a4d9a000-a4d9b000 ---p a4d9a000 00:00 0
a4d9b000-a559b000 rwxp a4d9b000 00:00 0
a559b000-a559c000 ---p a559b000 00:00 0
a559c000-a5d9c000 rwxp a559c000 00:00 0
a5d9c000-a5da0000 rw-s 00000000 00:09 7041732 /drm mm object (deleted)
a5da0000-a5da1000 ---p a5da0000 00:00 0
a5da1000-a65a1000 rwxp a5da1000 00:00 0
a65a1000-a65a2000 ---p a65a1000 00:00 0
a65a2000-a6da2000 rwxp a65a2000 00:00 0
a6da2000-a6da3000 ---p a6da2000 00:00 0
a6da3000-a75a3000 rwxp a6da3000 00:00 0
a75a3000-a75a4000 ---p a75a3000 00:00 0
a75a4000-a7da4000 rwxp a75a4000 00:00 0
a7da4000-a7da5000 ---p a7da4000 00:00 0
a7da5000-a85a5000 rwxp a7da5000 00:00 0
a85a5000-a85ad000 rw-s 00000000 00:09 7041718 /drm mm object (deleted)
a85ad000-a85ae000 rw-s 00000000 00:09 7041717 /drm mm object (deleted)
a85ae000-a85af000 ---p a85ae000 00:00 0
a85af000-a8daf000 rwxp a85af000 00:00 0
a8daf000-a8db0000 ---p a8daf000 00:00 0
a8db0000-a95b0000 rwxp a8db0000 00:00 0
a95b0000-a95b1000 ---p a95b0000 00:00 0
a95b1000-a9db1000 rwxp a95b1000 00:00 0
a9db1000-a9db2000 ---p a9db1000 00:00 0
a9db2000-aa5b2000 rwxp a9db2000 00:00 0
aa5b2000-aa5b3000 ---p aa5b2000 00:00 0
aa5b3000-aadb3000 rwxp aa5b3000 00:00 0
aadb3000-aadb4000 ---p aadb3000 00:00 0
aadb4000-ab5b4000 rwxp aadb4000 00:00 0
ab5b4000-ab5b5000 ---p ab5b4000 00:00 0
ab5b5000-abdb5000 rwxp ab5b5000 00:00 0
abdb5000-abdb6000 ---p abdb5000 00:00 0
abdb6000-ac5b6000 rwxp abdb6000 00:00 0
ac5b6000-ac5b7000 ---p ac5b6000 00:00 0
ac5b7000-acdb7000 rwxp ac5b7000 00:00 0
acdb7000-acdb8000 ---p acdb7000 00:00 0
acdb8000-ad5b8000 rwxp acdb8000 00:00 0
ad5b8000-ad5b9000 ---p ad5b8000 00:00 0
ad5b9000-addb9000 rwxp ad5b9000 00:00 0
addb9000-addba000 ---p addb9000 00:00 0
addba000-ae5ba000 rwxp addba000 00:00 0
ae5ba000-ae5bb000 ---p ae5ba000 00:00 0
ae5bb000-aedbb000 rwxp ae5bb000 00:00 0
aedbb000-aedbc000 ---p aedbb000 00:00 0
aedbc000-af5bc000 rwxp aedbc000 00:00 0
af5bc000-af5bd000 ---p af5bc000 00:00 0
af5bd000-afdbd000 rwxp af5bd000 00:00 0
afdbd000-afdbe000 ---p afdbd000 00:00 0
afdbe000-b05be000 rwxp afdbe000 00:00 0
b05be000-b05bf000 ---p b05be000 00:00 0
b05bf000-b0dbf000 rwxp b05bf000 00:00 0
b0dbf000-b0dc7000 rw-s 00000000 00:09 7041683 /drm mm object (deleted)
b0dc7000-b0dcf000 rw-s 00000000 00:09 7041682 Abort
DOH!
But other than this world (which, aside from some inconsequential shifting
of text in two-line blocks, hasn't changed since 2000), I haven't found
another world that kills the viewer--at least, out of the three or four
I've tried. :-)
(Btw, that one's still at http://www.libpng.org/pub/png/pngvrml/pngboxes.wrl
AFAIK there are no errors, but I no longer have a VRML syntax-checker,
and Trapezium/Vorlon is long gone.)
- Speaking of things that haven't changed since 2000, I see the Background
node still doesn't transform with Viewpoint...I know I reported that bug
many, many years ago.
- The normalized-vector warning is kind of annoying. I don't know how much
more normalized it expects me to get, but if 6+ nines won't cut it, there's
something wrong with the code:
orientation -0.10618 0.98856 0.10712 1.5911
sqrt(0.10618*0.10618 + 0.98856*0.98856 + 0.10712*0.10712)
.99999988019999282397
Not a big deal, obviously, but it's also 100% trivial to check whether
the vector's within, say, 0.001 of 1.0, which should be "good enough."
System particulars:
- dual Intel Atom 330 1.6 GHz, 2 GB RAM, Intel 945G graphics
- Ubuntu 2009.04 32-bit (64-bit box shipped that way, argh...)
- Linux "2.6.28-17-generic", gcc 4.3.3, glibc 2.9, libstdc++ 6.0.10 (whatever
version that really is)
- openvrml 0.18.5
Regards,
Greg
|
|
From: Braden M. <br...@en...> - 2010-03-09 06:12:27
|
On Mon, 2010-03-08 at 04:56 -0800, cheribhai wrote: > > Hello, > It seems that routes declared inside PROTO definitions do not seem > to be working as expected. > e.g. I have a time sensor and a script in a PROTO definition. When I try to > route the 'time' of the time sensor to a function of the script which simply > prints out the value of the time, it doesn't work. Quick debugging in the > time sensor node tells me that the time update is being done (and > consequently emitted), but somehow the script node does not receive this > event. > > Am I missing something? Maybe; but I'll need a concrete example to know whether you are or you've found a bug. The attached example works for me; that is, I see "Ouch!" printed to the console when I click the sphere. -- Braden McDaniel <br...@en...> |
|
From: Braden M. <br...@en...> - 2010-03-09 05:04:39
|
On Mon, 2010-03-08 at 04:56 -0800, cheribhai wrote: > > Hello, > It seems that routes declared inside PROTO definitions do not seem > to be working as expected. > e.g. I have a time sensor and a script in a PROTO definition. When I try to > route the 'time' of the time sensor to a function of the script which simply > prints out the value of the time, it doesn't work. Quick debugging in the > time sensor node tells me that the time update is being done (and > consequently emitted), but somehow the script node does not receive this > event. > > Am I missing something? Maybe; but I'll need a concrete example to know whether you are or you've found a bug. The attached example works for me; that is, I see "Ouch!" printed to the console when I click the sphere. -- Braden McDaniel <br...@en...> |
|
From: cheribhai <cha...@gm...> - 2010-03-08 12:56:52
|
Hello,
It seems that routes declared inside PROTO definitions do not seem
to be working as expected.
e.g. I have a time sensor and a script in a PROTO definition. When I try to
route the 'time' of the time sensor to a function of the script which simply
prints out the value of the time, it doesn't work. Quick debugging in the
time sensor node tells me that the time update is being done (and
consequently emitted), but somehow the script node does not receive this
event.
Am I missing something?
Cheers - Cherian
--
View this message in context: http://old.nabble.com/Routes-in-PROTO-tp27819866p27819866.html
Sent from the openvrml-develop mailing list archive at Nabble.com.
|
|
From: Braden M. <br...@en...> - 2010-03-07 02:04:14
|
On Sat, 2010-03-06 at 22:48 +0100, Grzegorz Wieczorek wrote: > I have problem with compilation on Gentoo, can someone help me? > > gentoo openvrml-0.18.5 # ./configure [no obvious problems here] > When I run make I have some errors: > > make[4]: *** [libopenvrml/openvrml/libopenvrml_libopenvrml_la-basetypes.lo] > Błąd 1 > make[4]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5/src' > make[3]: *** [all-recursive] Błąd 1 > make[3]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5/src' > make[2]: *** [all] Błąd 2 > make[2]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5/src' > make[1]: *** [all-recursive] Błąd 1 > make[1]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5' > make: *** [all] Błąd 2 > > > Any hints? You've omitted the actual error messages from the compiler. I can't tell what's going on without those. -- Braden McDaniel <br...@en...> |
|
From: Grzegorz W. <grz...@gm...> - 2010-03-06 21:48:38
|
I have problem with compilation on Gentoo, can someone help me? gentoo openvrml-0.18.5 # ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking how to create a pax tar archive... gnutar checking for style of include used by make... GNU checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for a sed that does not truncate output... /bin/sed checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/x86_64-pc-linux-gnu/bin/ld checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/x86_64-pc-linux-gnu/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking how to run the C preprocessor... gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... no checking for dlopen in -ldl... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... no checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking whether we are using the GNU C++ compiler... (cached) yes checking whether g++ accepts -g... (cached) yes checking dependency style of g++... (cached) gcc3 checking how to run the C++ preprocessor... g++ -E checking for ld used by g++... /usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64 checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) is GNU ld... yes checking whether the g++ linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC -DPIC checking if g++ PIC flag -fPIC -DPIC works... yes checking if g++ static flag -static works... yes checking if g++ supports -c -o file.o... yes checking if g++ supports -c -o file.o... (cached) yes checking whether the g++ linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking how to run the C++ preprocessor... g++ -E checking for gcj... gcj checking dependency style of gcj... gcc3 checking dependency style of gcj... (cached) gcc3 checking if gcj supports -fno-rtti -fno-exceptions... (cached) no checking for gcj option to produce PIC... -fPIC checking if gcj PIC flag -fPIC works... yes checking if gcj static flag -static works... no checking if gcj supports -c -o file.o... yes checking if gcj supports -c -o file.o... (cached) yes checking whether the gcj linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.18.0... yes checking for gcjh... gcjh -jni checking for jar... jar checking for doxygen... /usr/bin/doxygen checking for Rez... no checking if the compiler supports the gcc visibility attribute... yes checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking ltdl.h usability... yes checking ltdl.h presence... yes checking for ltdl.h... yes checking jni.h usability... yes checking jni.h presence... yes checking for jni.h... yes checking if JNI function signatures use const... no checking for boost_thread-mt library... yes checking for XML... yes checking for PNG... yes checking for FONTCONFIG... yes checking for FREETYPE... yes checking if FreeType callback function signatures use const... yes checking for JS... no checking for JS... no checking for JS... no checking for JS... yes checking for JS_Init in -ljs... no checking jsapi.h usability... yes checking jsapi.h presence... yes checking for jsapi.h... yes checking for DBUS_G... yes checking for dbus-binding-tool... /usr/bin/dbus-binding-tool checking for GTKGL... yes checking for GNOMEUI... yes checking for GIO... yes checking for CURL... yes checking for MOZILLA_PLUGIN... yes checking for X... libraries , headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking whether we are using the Microsoft C compiler... no checking windows.h usability... no checking windows.h presence... no checking for windows.h... no checking for GL/gl.h... yes checking for OpenGL/gl.h... no checking for OpenGL library... -lGL checking for GL/glu.h... yes checking for OpenGL/glu.h... no checking for OpenGL Utility library... -lGLU checking for varargs GLU tesselator callback function type... no checking for sdl-config... /usr/bin/sdl-config checking for JNI_CreateJavaVM in -ljvm... no configure: WARNING: no libjvm found at JAVA_HOME configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating ide-projects/Makefile config.status: creating models/Makefile config.status: creating models/audio/Makefile config.status: creating models/textures/Makefile config.status: creating src/Makefile config.status: creating src/libopenvrml/openvrml-config.h config.status: creating src/libopenvrml-gl/openvrml-gl-config.h config.status: creating src/script/Makefile config.status: creating src/script/java/Makefile config.status: creating src/script/java/vrml/Makefile config.status: creating src/script/java/vrml/field/Makefile config.status: creating src/script/java/vrml/node/Makefile config.status: creating data/Makefile config.status: creating examples/Makefile config.status: creating tests/Makefile config.status: creating tests/atlocal config.status: creating openvrml.pc config.status: creating openvrml-gl.pc config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands config.status: executing tests/atconfig commands When I run make I have some errors: make[4]: *** [libopenvrml/openvrml/libopenvrml_libopenvrml_la-basetypes.lo] Błąd 1 make[4]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5/src' make[3]: *** [all-recursive] Błąd 1 make[3]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5/src' make[2]: *** [all] Błąd 2 make[2]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5/src' make[1]: *** [all-recursive] Błąd 1 make[1]: Opuszczenie katalogu `/home/grzew/Downloads/openvrml-0.18.5' make: *** [all] Błąd 2 Any hints? |
|
From: Braden M. <br...@en...> - 2010-03-05 04:14:08
|
On Thu, 2010-03-04 at 19:35 -0800, Rich Cook wrote: > On Mar 4, 2010, at 7:26 PM, Braden McDaniel wrote: > > > On Thu, 2010-03-04 at 19:07 -0800, Rich Cook wrote: > >> Thanks, my sysadmin has informed me we need an upgrade to glib, they > >> started rolling gio into glib a couple versions after ours. Said > >> upgrade is probably not going to happen, due to institutional > >> inertia. :-( > > > > Bummer. Well, the only part that needs this is openvrml-player; so > > you > > can --disable-player when running configure to get past this. > > > > Also, I seem to recall that I only used GIO to inspect the MIME type > > of > > local files. I think it would be trivial to patch that out; your > > version of GLib might even have some substitute functions. FWIW. > > That sounds promising, however, there is also the GTK dependency on > GtkBuilder which is equally at issue for us -- is that a simple patch > as well? :-) Not nearly as simple; but doable if you're determined. GtkBuilder replaced libglade, which you can find employed in older OpenVRML releases (0.17). I think it would be doable to graft that back onto OpenVRML 0.18 in place of GtkBuilder. But we're talking about hours of work rather than minutes. > The player would be nice. We tried freeWRL but it seems to not render > accurately from what I can see. I'd like to have a local viewer for > our scientists if possible. This looks like a nice way to share data > with colleagues potentially. Well, if you can't use newer dependencies, you could try an older OpenVRML--like 0.17.12. -- Braden McDaniel <br...@en...> |
|
From: Rich C. <rc...@ll...> - 2010-03-05 03:35:22
|
On Mar 4, 2010, at 7:26 PM, Braden McDaniel wrote: > On Thu, 2010-03-04 at 19:07 -0800, Rich Cook wrote: >> Thanks, my sysadmin has informed me we need an upgrade to glib, they >> started rolling gio into glib a couple versions after ours. Said >> upgrade is probably not going to happen, due to institutional >> inertia. :-( > > Bummer. Well, the only part that needs this is openvrml-player; so > you > can --disable-player when running configure to get past this. > > Also, I seem to recall that I only used GIO to inspect the MIME type > of > local files. I think it would be trivial to patch that out; your > version of GLib might even have some substitute functions. FWIW. That sounds promising, however, there is also the GTK dependency on GtkBuilder which is equally at issue for us -- is that a simple patch as well? :-) The player would be nice. We tried freeWRL but it seems to not render accurately from what I can see. I'd like to have a local viewer for our scientists if possible. This looks like a nice way to share data with colleagues potentially. > > -- > Braden McDaniel <br...@en...> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://*p.sf.net/sfu/intel-sw-dev > _______________________________________________ > openvrml-develop mailing list > ope...@li... > https://*lists.sourceforge.net/lists/listinfo/openvrml-develop > /* A function that takes a single integer argument and returns a pointer to a function that takes two integer arguments and returns a floating-point number. */ float (*func2(int a))(int, int); Rich Cook rc...@ll... |
|
From: Braden M. <br...@en...> - 2010-03-05 03:26:53
|
On Thu, 2010-03-04 at 19:07 -0800, Rich Cook wrote: > Thanks, my sysadmin has informed me we need an upgrade to glib, they > started rolling gio into glib a couple versions after ours. Said > upgrade is probably not going to happen, due to institutional > inertia. :-( Bummer. Well, the only part that needs this is openvrml-player; so you can --disable-player when running configure to get past this. Also, I seem to recall that I only used GIO to inspect the MIME type of local files. I think it would be trivial to patch that out; your version of GLib might even have some substitute functions. FWIW. -- Braden McDaniel <br...@en...> |
|
From: Rich C. <rc...@ll...> - 2010-03-05 03:07:52
|
Thanks, my sysadmin has informed me we need an upgrade to glib, they started rolling gio into glib a couple versions after ours. Said upgrade is probably not going to happen, due to institutional inertia. :-( On Mar 4, 2010, at 6:21 PM, Braden McDaniel wrote: > On Thu, 2010-03-04 at 16:25 -0800, Rich Cook wrote: >> Hello, >> On our clusters, the configure script exits with the following error: >> >> configure: error: in `/usr/global/tools/VRML/OpenVRML/0.18.5/ >> chaos_4_x86_64_ib/openvrml-0.18.5': >> configure: error: GIO is required to build OpenVRML Player >> See `config.log' for more details. >> It appears this is generated by the following code: >> configure:21442: checking for GIO >> configure:21449: $PKG_CONFIG --exists --print-errors "gio-2.0" >> Package gio-2.0 was not found in the pkg-config search path. >> Perhaps you should add the directory containing `gio-2.0.pc' >> to the PKG_CONFIG_PATH environment variable >> No package 'gio-2.0' found >> configure:21452: $? = 1 >> I did a Google search and this seems to be part of glib, maybe. > > It is; but it has its own .pc file and it's deployed as a distinct > library. > >> I'm >> having trouble figuring out what to ask my sysadmin to install in >> order to make autoconf happy here. Can someone tell me what RPM is >> missing? Thanks! > > On my Fedora 12 box: > > $ rpm -qf /usr/lib64/pkgconfig/gio-2.0.pc > glib2-devel-2.22.4-2.fc12.x86_64 > > -- > Braden McDaniel <br...@en...> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://*p.sf.net/sfu/intel-sw-dev > _______________________________________________ > openvrml-develop mailing list > ope...@li... > https://*lists.sourceforge.net/lists/listinfo/openvrml-develop > /* A function that takes a single integer argument and returns a pointer to a function that takes two integer arguments and returns a floating-point number. */ float (*func2(int a))(int, int); Rich Cook rc...@ll... |
|
From: Braden M. <br...@en...> - 2010-03-05 02:22:03
|
On Thu, 2010-03-04 at 16:25 -0800, Rich Cook wrote:
> Hello,
> On our clusters, the configure script exits with the following error:
>
> configure: error: in `/usr/global/tools/VRML/OpenVRML/0.18.5/
> chaos_4_x86_64_ib/openvrml-0.18.5':
> configure: error: GIO is required to build OpenVRML Player
> See `config.log' for more details.
> It appears this is generated by the following code:
> configure:21442: checking for GIO
> configure:21449: $PKG_CONFIG --exists --print-errors "gio-2.0"
> Package gio-2.0 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `gio-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'gio-2.0' found
> configure:21452: $? = 1
> I did a Google search and this seems to be part of glib, maybe.
It is; but it has its own .pc file and it's deployed as a distinct
library.
> I'm
> having trouble figuring out what to ask my sysadmin to install in
> order to make autoconf happy here. Can someone tell me what RPM is
> missing? Thanks!
On my Fedora 12 box:
$ rpm -qf /usr/lib64/pkgconfig/gio-2.0.pc
glib2-devel-2.22.4-2.fc12.x86_64
--
Braden McDaniel <br...@en...>
|
|
From: Rich C. <rc...@ll...> - 2010-03-05 00:25:36
|
Hello,
On our clusters, the configure script exits with the following error:
configure: error: in `/usr/global/tools/VRML/OpenVRML/0.18.5/
chaos_4_x86_64_ib/openvrml-0.18.5':
configure: error: GIO is required to build OpenVRML Player
See `config.log' for more details.
It appears this is generated by the following code:
configure:21442: checking for GIO
configure:21449: $PKG_CONFIG --exists --print-errors "gio-2.0"
Package gio-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gio-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gio-2.0' found
configure:21452: $? = 1
I did a Google search and this seems to be part of glib, maybe. I'm
having trouble figuring out what to ask my sysadmin to install in
order to make autoconf happy here. Can someone tell me what RPM is
missing? Thanks!
/* A function that takes a single integer argument and returns
a pointer to a function that takes two integer arguments and
returns a floating-point number. */
float (*func2(int a))(int, int);
Rich Cook
rc...@ll...
|
|
From: Braden M. <br...@en...> - 2010-03-03 18:30:05
|
On Mon, 2010-03-01 at 04:36 -0800, cheribhai wrote: > > Hello, > A couple of things I noticed in the 'do_update' function of the > time_sensor_node class (comments are based on version 0.18.5). > > 1)The VRML97 spec states that "A TimeSensor node can be set up to be active > at read time by specifying loop TRUE (not the default) and stopTime less > than or equal to startTime (satisfied by the default values). ", but one of > the checks to make the node active is > 'this->stop_time_.sftime::value() < this->start_time_.value()'. > Should this not be > 'this->stop_time_.sftime::value() <= this->start_time_.value()'. Yes, I believe you're right; except we want to use fless_equal here. > 2)The spec also states that "If an active time-dependent node receives a > set_loop FALSE event, execution continues until the end of the current cycle > or until stopTime (if stopTime > startTime), whichever occurs first." The > code currently works such that the above is true only if we are in the first > cycle. After the first one is over the exectution jumps directly to the end > of the cycle in the next simulation tick instead of continuing to the end of > the current cycle. This is affected by the check, > (!this->loop_.sfbool::value() && fless_equal(this->start_time_.value() > + cycleInt, timeNow.value())). > > I have attempted to fix this but before I provide the fix, I just wanted to > be sure that this is truly an error (and that I am not mistaken). I think you're right here as well. Can you please file a bug in trac and attach a patch? -- Braden McDaniel <br...@en...> |
|
From: Braden M. <br...@en...> - 2010-03-03 18:13:32
|
On Mon, 2010-03-01 at 04:40 -0800, cheribhai wrote:
>
> Hello,
> A quick question on vector asssignment using openvrml. I have a
> javascript function where I am dynamically changing the key values of a
> position interpolator, but the assignment does not seem to work.
> I have tried
> PosInter.keyValue[1][0] = targetPosition[0]; // x
> PosInter.keyValue[1][0] = targetPosition[1]; // y
^
a typo, presumably. :-)
> PosInter.keyValue[1][2] = targetPosition[2]; // z
First off, you need to be using directOutput TRUE in order to set the
node field like this.
But assuming you've done that, I think this still doesn't work because
you end up setting the elements of a temporary SFVec3f that keyValue[1]
returns. I think there's an argument to be made that this syntax should
work; but I haven't found a good way to do that with SpiderMonkey.
It should work to set the entire SFVec3f element at once:
PosInter.keyValue[1] = targetPosition;
> and also
>
> PosInter.keyValue = [0 0 0, targetPosition[0] targetPosition[1]
> targetPosition[2]];
>
> but both don't work.
MF* types are not JavaScript arrays; so I wouldn't expect that to work.
--
Braden McDaniel <br...@en...>
|
|
From: cheribhai <cha...@gm...> - 2010-03-01 12:48:08
|
Hello,
A couple of things I noticed in the 'do_update' function of the
time_sensor_node class (comments are based on version 0.18.5).
1)The VRML97 spec states that "A TimeSensor node can be set up to be active
at read time by specifying loop TRUE (not the default) and stopTime less
than or equal to startTime (satisfied by the default values). ", but one of
the checks to make the node active is
'this->stop_time_.sftime::value() < this->start_time_.value()'.
Should this not be
'this->stop_time_.sftime::value() <= this->start_time_.value()'.
2)The spec also states that "If an active time-dependent node receives a
set_loop FALSE event, execution continues until the end of the current cycle
or until stopTime (if stopTime > startTime), whichever occurs first." The
code currently works such that the above is true only if we are in the first
cycle. After the first one is over the exectution jumps directly to the end
of the cycle in the next simulation tick instead of continuing to the end of
the current cycle. This is affected by the check,
(!this->loop_.sfbool::value() && fless_equal(this->start_time_.value()
+ cycleInt, timeNow.value())).
I have attempted to fix this but before I provide the fix, I just wanted to
be sure that this is truly an error (and that I am not mistaken).
Please advise.
Cherian
--
View this message in context: http://old.nabble.com/Time-Sensor-Node-tp27742840p27742840.html
Sent from the openvrml-develop mailing list archive at Nabble.com.
|
|
From: cheribhai <cha...@gm...> - 2010-03-01 12:48:05
|
Hello,
A quick question on vector asssignment using openvrml. I have a
javascript function where I am dynamically changing the key values of a
position interpolator, but the assignment does not seem to work.
I have tried
PosInter.keyValue[1][0] = targetPosition[0]; // x
PosInter.keyValue[1][0] = targetPosition[1]; // y
PosInter.keyValue[1][2] = targetPosition[2]; // z
and also
PosInter.keyValue = [0 0 0, targetPosition[0] targetPosition[1]
targetPosition[2]];
but both don't work.
cheers
Cherian
--
View this message in context: http://old.nabble.com/Vector-Assignment-tp27742867p27742867.html
Sent from the openvrml-develop mailing list archive at Nabble.com.
|
|
From: Braden M. <br...@en...> - 2010-02-16 19:49:40
|
On 2/16/10 2:04 PM, Ignacio Enriquez Gutierre wrote: > > > Braden McDaniel wrote: >> >> In "Get Info" for your project, you need to uncheck "Generate Debug >> Symbols" under the "Code Generation" section. >>> Could you exactly write what are your paths in Xcode? : >>> Header Search Path and >>> Library Search Path and if there is other I need please write it. >> My "Header Search Path" is >> /opt/local/include /opt/local/include/openvrml >> My "Library Search Path" is >> /opt/local/lib >> I'm building against OpenVRML installed from MacPorts. >> > > Thanks! I will try it later. > > I It seems to be a GCC4.2 bug which is said to be fixed in later versions > but since Apple is using the old 4.2 we cannot do anything since is old but > it has modifications to work with Apple stuff. Yes; an internal compiler error is going to be either a compiler bug or faulty hardware (e.g., bad memory). One that's repeatable on different machines is pretty certainly the former. > I think this is the Bug: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899 That looks like a pretty good candidate. > I will try with GCC4.4 from macports and report something later. FWIW, this builds just fine with gcc 4.4 on Linux. (Of course, Apple modifies their gcc, so consistency cannot be guaranteed.) -- Braden McDaniel <br...@en...> |
|
From: Ignacio E. G. <na...@gm...> - 2010-02-16 19:04:09
|
Braden McDaniel wrote: > > In "Get Info" for your project, you need to uncheck "Generate Debug > Symbols" under the "Code Generation" section. >> Could you exactly write what are your paths in Xcode? : >> Header Search Path and >> Library Search Path and if there is other I need please write it. > My "Header Search Path" is > /opt/local/include /opt/local/include/openvrml > My "Library Search Path" is > /opt/local/lib > I'm building against OpenVRML installed from MacPorts. > Thanks! I will try it later. I It seems to be a GCC4.2 bug which is said to be fixed in later versions but since Apple is using the old 4.2 we cannot do anything since is old but it has modifications to work with Apple stuff. I think this is the Bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899 I will try with GCC4.4 from macports and report something later. Thank you Braden Ignacio -- View this message in context: http://old.nabble.com/NEWBIE%3A-using-openvrml-in-mac-OS-10.6-tp26253956p27613395.html Sent from the openvrml-develop mailing list archive at Nabble.com. |
|
From: Braden M. <br...@en...> - 2010-02-16 14:50:34
|
On Tue, 2010-02-16 at 00:17 -0800, Ignacio Enriquez Gutierre wrote: > Hi Braden > > > > Yes. I was able to get around the internal compiler error I was > > experiencing by turning off debugging symbols (i.e., *not* passing -g to > > the compiler). Pretty annoying if you actually need to debug something; > > but at least it gets you a binary. > >> There is also a thread I began last year in stackoverflow.com > >> http://stackoverflow.com/questions/1678828/openvrml-in-snow-leopard-from-macports > > I have not observed the failure mode you describe there and in your > > previous posting. The responses seem to point to the use of recursive > > search paths as a culprit for this; I'm pretty sure you *don't* want this. > > > > I did uncheck the flag for recursive but I still have one error in > vrml97_grammar.h file > in line425 using boost::test_tools::check_is_close; > Internal compiler error: in reference_to_unused, at dwarf2out.c10603 > > Is this the error you got? Yes. > In that case how do I set -g flag? in Xcode? I said *don't* set that flag. In "Get Info" for your project, you need to uncheck "Generate Debug Symbols" under the "Code Generation" section. > Could you exactly write what are your paths in Xcode? : > Header Search Path and > Library Search Path and if there is other I need please write it. My "Header Search Path" is /opt/local/include /opt/local/include/openvrml My "Library Search Path" is /opt/local/lib I'm building against OpenVRML installed from MacPorts. -- Braden McDaniel <br...@en...> |
|
From: Nicholas F. P. <np...@vt...> - 2010-02-16 14:03:52
|
Hi all~ I hope this email finds you well! I am pleased to announce the Call for Papers for Web3D 2010!!! http://conferences.web3d.org/web3d2010/ 15th International Conference on 3D Web Technology July 24 – 25, 2010 Los Angeles, CA Sponsored & Co-Located w/ ACM SIGGRAPH In Cooperation with Web3D Consortium & EuroGraphics Full & Short Paper submission deadline: April 25, 2010 Author Notification: June 1, 2010 Camera-ready due: June 14, 2010 Fifteenth in the series, the 2010 ACM International Web3D Conference will address a wide range of topics about 3D on the World Wide Web and on Multimedia Devices. Topics include: tools, object retrieval, rendering, modeling, distributed virtual environments, exposing large-scale databases, Web-wide human-computer interaction, and innovative applications. Of particular interest are issues regarding the interoperability, durability or delivery of 4D information assets. The annual ACM Web3D Conference is a major event which unites researchers, developers, entrepreneurs, experimenters, artists and content creators in a dynamic learning environment. Attendees share and explore methods of using, enhancing and creating new 3D Web and Multimedia technologies such as X3D, VRML, Collada, MPEG family, U3D, Java3D. The conference highlights capabilities and trends in interactive 3D graphics across a wide range of applications and devices from mobile hand-helds to high-end immersive environments. Authors are invited to submit their work (short or full papers) for review by the international Program Committee. Both research and applications papers are of interest to Web3D 2010. The papers must be innovative, original, and contribute to the advancement of 3D technologies in the Internet space. Topics of interest include (but are not limited to): • High-performance 3D graphics for distributed environments, tele-presence and tele-operation systems • Advanced methods for modeling, representation, retrieval and rendering of complex geometry, structure and behaviors over the Web • Interactive 3D graphics for embedded devices such as PDAs and cellular phones • Agents, animated humanoids and complex reactive characters • User-interface paradigms, interaction methods and usability for real-time 3D graphics in virtual, augmented and mixed reality environments • Web, Multimedia and other Standards integration and interoperation, including SVG, SMIL and Semantic Web technologies • New and proven applications using 3D graphics on the Web/Multimedia in industry, science, geospatial, digital cities, health, cultural heritage and learning Submission instructions Authors are invited to submit full papers of up to 9 pages (including figures and references) or short papers of up to 4 pages (including figures and references) in PDF format via the SRM Submission Site. Papers must be formatted using the document templates for conferences sponsored by ACM SIGGRAPH. Upon acceptance, the final revised paper is required also in electronic form. Accepted papers will appear in the Web 3D 2010 Conference Proceedings, published by ACM Press. Looking forward to seeing you there! br, _nicholas -- Nicholas F. Polys Ph.D. Director of Visual Computing Virginia Tech Information Technology - ARC Affiliate Research Professor Virginia Tech Computer Science |
|
From: Ignacio E. G. <na...@gm...> - 2010-02-16 08:17:10
|
Hi Braden > Yes. I was able to get around the internal compiler error I was > experiencing by turning off debugging symbols (i.e., *not* passing -g to > the compiler). Pretty annoying if you actually need to debug something; > but at least it gets you a binary. >> There is also a thread I began last year in stackoverflow.com >> http://stackoverflow.com/questions/1678828/openvrml-in-snow-leopard-from-macports > I have not observed the failure mode you describe there and in your > previous posting. The responses seem to point to the use of recursive > search paths as a culprit for this; I'm pretty sure you *don't* want this. > I did uncheck the flag for recursive but I still have one error in vrml97_grammar.h file in line425 using boost::test_tools::check_is_close; Internal compiler error: in reference_to_unused, at dwarf2out.c10603 Is this the error you got? In that case how do I set -g flag? in Xcode? Could you exactly write what are your paths in Xcode? : Header Search Path and Library Search Path and if there is other I need please write it. I will appreciate is very much. -- View this message in context: http://old.nabble.com/NEWBIE%3A-using-openvrml-in-mac-OS-10.6-tp26253956p27604839.html Sent from the openvrml-develop mailing list archive at Nabble.com. |
|
From: Braden M. <br...@en...> - 2010-02-16 02:53:59
|
OpenVRML 0.18.5 is now available. The distribution can be obtained from <http://downloads.sourceforge.net/project/openvrml/openvrml/0.18.5/openvrml-0.18.5.tar.gz> OpenVRML is a C++ runtime library for VRML97 and X3D worlds. It is capable of reading and displaying VRML/X3D; it can be used for creating loaders, file converters, and VRML/X3D browsers. OpenVRML includes an out-of-process viewer component for use in X11 environments along with hosts for this component in the form of a Mozilla browser plug-in and a stand-alone player. You can find OpenVRML on the Web at <http://openvrml.org> New in OpenVRML 0.18.5: - Fixed build configuration issues for Mac OS X and Cygwin. |
|
From: Braden M. <br...@en...> - 2010-02-15 05:30:29
|
On 2/14/10 1:36 AM, Ignacio Enriquez Gutierre wrote: > > It's been a long time,... > Did you succeed in compiling the sample program in Xcode? I couldn't. Yes. I was able to get around the internal compiler error I was experiencing by turning off debugging symbols (i.e., *not* passing -g to the compiler). Pretty annoying if you actually need to debug something; but at least it gets you a binary. > There is also a thread I began last year in stackoverflow.com > http://stackoverflow.com/questions/1678828/openvrml-in-snow-leopard-from-macports I have not observed the failure mode you describe there and in your previous posting. The responses seem to point to the use of recursive search paths as a culprit for this; I'm pretty sure you *don't* want this. -- Braden McDaniel <br...@en...> |
2 messages has been excluded from this view by a project administrator.
