openvrml-develop — OpenVRML developers mailing list

Re: [openvrml-develop] How to build OpenVRML on VisualStudio 2005 and 2003

[Larry M. <lar...@gm...>]

Thanks again Braden - it's too late to chicken out - so I built Boost anyway....

now I get the following linker errors....

Linking...
   Creating library
C:\openvrml-0.16.5\ide-projects\Windows\VisualC8_0\OpenVRML\..\lib\openvrmld.lib
and object C:\openvrml-0.16.5\ide-projects\Windows\VisualC8_0\OpenVRML\..\lib\openvrmld.exp
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_Init_FreeType referenced in function "public: __thiscall
`anonymous namespace'::text_metatype::text_metatype(class
openvrml::browser &)"
(??0text_metatype@?A0xbd026fe7@@QAE@AAVbrowser@openvrml@@@Z)
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_Done_FreeType referenced in function "public: virtual
__thiscall `anonymous namespace'::text_metatype::~text_metatype(void)"
(??1text_metatype@?A0xbd026fe7@@UAE@XZ)
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_Done_Face referenced in function "private: virtual void
__thiscall `anonymous namespace'::text_node::do_shutdown(double)"
(?do_shutdown@text_node@?A0xbd026fe7@@EAEXN@Z)
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_New_Face referenced in function "private: void __thiscall
`anonymous namespace'::text_node::update_face(void)"
(?update_face@text_node@?A0xbd026fe7@@AAEXXZ)
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_Outline_Decompose referenced in function "private: void
__thiscall `anonymous namespace'::text_node::update_geometry(void)"
(?update_geometry@text_node@?A0xbd026fe7@@AAEXXZ)
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_Get_Glyph referenced in function "private: void __thiscall
`anonymous namespace'::text_node::update_geometry(void)"
(?update_geometry@text_node@?A0xbd026fe7@@AAEXXZ)
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_Load_Glyph referenced in function "private: void __thiscall
`anonymous namespace'::text_node::update_geometry(void)"
(?update_geometry@text_node@?A0xbd026fe7@@AAEXXZ)
vrml97node.obj : error LNK2019: unresolved external symbol
__imp__FT_Get_Char_Index referenced in function "private: void
__thiscall `anonymous namespace'::text_node::update_geometry(void)"
(?update_geometry@text_node@?A0xbd026fe7@@AAEXXZ)
C:\openvrml-0.16.5\ide-projects\Windows\VisualC8_0\OpenVRML\..\bin\openvrmld.dll
: fatal error LNK1120: 8 unresolved externals
Build log was saved at
"file://c:\openvrml-0.16.5\ide-projects\Windows\VisualC8_0\OpenVRML\openvrml\Debug\BuildLog.htm"
openvrml - 9 error(s), 0 warning(s)




On 7/3/07, Braden McDaniel <br...@en...> wrote:
> Larry Mullen wrote:
> > Thanks Braden - I was able to get past that but now I get the
> > following when building openvrml
> >
> > LINK : fatal error LNK1104: cannot open file
> > 'libboost_thread-vc80-mt-gd-1_34.lib'
> >
> > I could not find reference to this library in any of the project settings.
>
> Boost takes advantage of a feature specific to the Microsoft compiler
> that lets it indicate what library will need to be linked in via the
> headers.
>
> > Unfortunately, if I have to build boost for this, it's time to give up
> > for me....it's going to be a maintenance nightmare and I dont want to
> > support this forever....
>
> You can get pre-built binaries of boost from boost-consulting.com.
>
> Braden
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
>

Re: [openvrml-develop] How to build OpenVRML on VisualStudio 2005 and 2003

[Braden M. <br...@en...>]

Larry Mullen wrote:
> Thanks Braden - I was able to get past that but now I get the
> following when building openvrml
> 
> LINK : fatal error LNK1104: cannot open file
> 'libboost_thread-vc80-mt-gd-1_34.lib'
> 
> I could not find reference to this library in any of the project settings.

Boost takes advantage of a feature specific to the Microsoft compiler 
that lets it indicate what library will need to be linked in via the 
headers.

> Unfortunately, if I have to build boost for this, it's time to give up
> for me....it's going to be a maintenance nightmare and I dont want to
> support this forever....

You can get pre-built binaries of boost from boost-consulting.com.

Braden

Re: [openvrml-develop] How to build OpenVRML on VisualStudio 2005 and 2003

[Larry M. <lar...@gm...>]

Thanks Braden - I was able to get past that but now I get the
following when building openvrml

LINK : fatal error LNK1104: cannot open file
'libboost_thread-vc80-mt-gd-1_34.lib'

I could not find reference to this library in any of the project settings.

Unfortunately, if I have to build boost for this, it's time to give up
for me....it's going to be a maintenance nightmare and I dont want to
support this forever....

Thanks for your help.

Rohit.

On 7/3/07, Braden McDaniel <br...@en...> wrote:
> Larry Mullen wrote:
>
> > I am making an attempt to use OpenVRML to verify the structure of
> > VRMLs I receive from a 3rd party. The current version I downloaded
> > ships with .sln files for VisualStudio 8.0 (2005) . I  searched but
> > could not find any instructions on how to build it with Windows (i.e
> > if some configuration needs to be done etc. ) I have downloaded Boost
> > and FreeType but now an getting an error related to compiling
> > resources
> >
> > Compiling resources...
> > .\openvrml.rc(10) : fatal error RC1015: cannot open include file 'afxres.h'.
> > Build log was saved at
> > "file://c:\openvrml-0.16.5\ide-projects\Windows\VisualC8_0\OpenVRML\openvrml\Debug\BuildLog.htm"
> > openvrml - 1 error(s), 0 warning(s)
>
> Are you using the Express version of Visual Studio? If so, you will need
> to download the Platform SDK from Microsoft.
>
> > I'll eventually have to compile this with VS 2003 as our current stack
> > is using that. Anybody have any experience with that ?
>
> Not for some time. If you turn back the clock in the CVS repository
> (8/1/05 should do), you'll find some project files for Visual C++ 7.1.
> I'm really not sure how useful they'd be as a starting point; you may be
> better off just creating new ones based on what you see in the 8.0
> project files.
>
> Braden
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
>

Re: [openvrml-develop] How to build OpenVRML on VisualStudio 2005 and 2003

[Braden M. <br...@en...>]

Larry Mullen wrote:

> I am making an attempt to use OpenVRML to verify the structure of
> VRMLs I receive from a 3rd party. The current version I downloaded
> ships with .sln files for VisualStudio 8.0 (2005) . I  searched but
> could not find any instructions on how to build it with Windows (i.e
> if some configuration needs to be done etc. ) I have downloaded Boost
> and FreeType but now an getting an error related to compiling
> resources
> 
> Compiling resources...
> .\openvrml.rc(10) : fatal error RC1015: cannot open include file 'afxres.h'.
> Build log was saved at
> "file://c:\openvrml-0.16.5\ide-projects\Windows\VisualC8_0\OpenVRML\openvrml\Debug\BuildLog.htm"
> openvrml - 1 error(s), 0 warning(s)

Are you using the Express version of Visual Studio? If so, you will need 
to download the Platform SDK from Microsoft.

> I'll eventually have to compile this with VS 2003 as our current stack
> is using that. Anybody have any experience with that ?

Not for some time. If you turn back the clock in the CVS repository 
(8/1/05 should do), you'll find some project files for Visual C++ 7.1. 
I'm really not sure how useful they'd be as a starting point; you may be 
better off just creating new ones based on what you see in the 8.0 
project files.

Braden

[openvrml-develop] How to build OpenVRML on VisualStudio 2005 and 2003

[Larry M. <lar...@gm...>]

Hi,

I am making an attempt to use OpenVRML to verify the structure of
VRMLs I receive from a 3rd party. The current version I downloaded
ships with .sln files for VisualStudio 8.0 (2005) . I  searched but
could not find any instructions on how to build it with Windows (i.e
if some configuration needs to be done etc. ) I have downloaded Boost
and FreeType but now an getting an error related to compiling
resources

Compiling resources...
.\openvrml.rc(10) : fatal error RC1015: cannot open include file 'afxres.h'.
Build log was saved at
"file://c:\openvrml-0.16.5\ide-projects\Windows\VisualC8_0\OpenVRML\openvrml\Debug\BuildLog.htm"
openvrml - 1 error(s), 0 warning(s)

I'll eventually have to compile this with VS 2003 as our current stack
is using that. Anybody have any experience with that ?

Any help in this regard will be really appreciated.

Thanks and regards,

Larry.

[openvrml-develop] OpenVRML on Mac OS X

[Braden M. <br...@en...>]

I have access to a machine running Mac OS X (10.4), and I'm beginning to 
put some effort into making OpenVRML behave better on this platform. 
This initial effort is going into making things work with the MacPorts 
toolchain.

As of this writing the trunk builds with the MacPorts tools, sans 
openvrml-xembed, openvrml-player, and the Mozilla plug-in. I have added 
a configure option --with-libjs that facilitates linking against the 
libjs binary that is typical of the stand-alone SpiderMonkey 
distribution (rather than libmozjs that is included with 
Mozilla/Firefox). This will likely come in handy in other build 
scenarios as well.

Since I don't anticipate much interest in an openvrml-player that 
requires X11 on Mac OS X, I doubt I'll be spending any energy on making 
that work. But if someone happens to be interested in this, it shouldn't 
be that hard.

Instead, I would like to get openvrml-player and the Mozilla plug-in 
working with Carbon and/or Cocoa. I'd like that, but unfortunately I 
don't think it's going to be easy. My investigation thus far indicates 
that the Mac GUI frameworks have no support for out-of-process GUI 
components. That means that the pattern by which openvrml-player and the 
Mozilla plug-in share the same back-end (openvrml-xembed) simply won't 
work on the Mac. So as things currently stand, a port will not be as 
simple as mapping functionality from one API to another.

I don't yet know enough about Carbon/Cocoa to know what the right way to 
resolve this is. One possibility is that functionality in 
openvrml-xembed and openvrml-player might be factored out into libraries 
that can be used by different processes on X11 platforms and different 
threads on Mac OS X.

Braden

Re: [openvrml-develop] openvrml-0.16.5: strange behaviour on FreeBSD.

[Braden M. <br...@en...>]

Thierry Thomas wrote:
> Le Mar  5 jui 07 à  1:33:43 +0200, Braden McDaniel <br...@en...>
>  écrivait :
> 
>> Note that libantlr is also a convenience library. The only difference
>> between it and the gtkglext libraries that comes to mind is that
>> libantlr is linked into a shared library (libopenvrml), while the
>> gtkglext libraries are linked into an executable.
>>
>>>  Note that it's not a
>>> problem to install these libs manually, I was just curious.
>> Well, I'm guessing it would be a problem if you tried to install
>> gtkglext on your system as well. :-/
> 
> That was the problem: I had missed this dependency on gtkglext!

Um... Well, the idea behind including gtkglext in the openvrml 
distribution and using its libraries as convenience libraries is that 
users shouldn't *have* to have gtkglext installed.

> Anyway, I'm still getting these errors on models/warbird.wrl, but no
> backtrace: the program exit after "Assertion failed".

You will need to use gdb to get a backtrace. Easiest way is probably to 
attach gdb to the running process before you load warbird.wrl:

    $ gdb --pid=<openvrml-xembed-pid>
    (gdb) c

    [now go load warbird.wrl in openvrml-player and make it crash]

    (gdb) bt

Braden

Re: [openvrml-develop] openvrml-0.16.5: strange behaviour on FreeBSD.

[Thierry T. <th...@Fr...>]

Le Mar  5 jui 07 à  1:33:43 +0200, Braden McDaniel <br...@en...>
 écrivait :

> Note that libantlr is also a convenience library. The only difference
> between it and the gtkglext libraries that comes to mind is that
> libantlr is linked into a shared library (libopenvrml), while the
> gtkglext libraries are linked into an executable.
> 
> >  Note that it's not a
> > problem to install these libs manually, I was just curious.
> 
> Well, I'm guessing it would be a problem if you tried to install
> gtkglext on your system as well. :-/

That was the problem: I had missed this dependency on gtkglext!

Anyway, I'm still getting these errors on models/warbird.wrl, but no
backtrace: the program exit after "Assertion failed".

Still investigating...

Regards,
-- 
Th. Thomas.

Re: [openvrml-develop] openvrml-0.16.5: strange behaviour on FreeBSD.

[Braden M. <br...@en...>]

On Mon, 2007-06-04 at 22:07 +0200, Thierry Thomas wrote:

[snip]

> > > - to run it, I have to manually install libgdkglext-x11-1.0.so and
> > > libgtkglext-x11-1.0.so;
> > 
> > Weird. Perhaps this is something about the way libtool works (or
> > doesn't) on FreeBSD? gtkglext is included in the openvrml distribution
> > and the libraries you mention are used as "convenience libraries"--which
> > means that they should effectively be statically linked into
> > openvrml-xembed. That, anyway, is how it works on Linux.
> 
> Actually on FreeBSD they are not linked statically.

Well, they aren't quite literally linked statically on Linux, either.
automake/libtool recognize when a library in the package isn't installed
and "linking" to such a library actually pulls in all the .o files that
are part of the convenience library.

Note that libantlr is also a convenience library. The only difference
between it and the gtkglext libraries that comes to mind is that
libantlr is linked into a shared library (libopenvrml), while the
gtkglext libraries are linked into an executable.

>  Note that it's not a
> problem to install these libs manually, I was just curious.

Well, I'm guessing it would be a problem if you tried to install
gtkglext on your system as well. :-/

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] openvrml-0.16.5: strange behaviour on FreeBSD.

[Thierry T. <th...@Fr...>]

Le Dim  3 jui 07 à 23:57:20 +0200, Braden McDaniel <br...@en...>
 écrivait :

> > - it builds fine, but I have to link openvrml-xembed and the tests
> > programs with JNI_LIBS, ${JAVA_HOME}/jre/lib/${ARCH}/client/libjvm.so;
> 
> You must have enabled the Script node Java support. That isn't advised.
> This feature isn't really supported in the current release. It doesn't
> work well enough to be called "functional"; so turning it on definitely
> isn't worth any problems doing so may cause.

OK, I have disabled it.

> > - to run it, I have to manually install libgdkglext-x11-1.0.so and
> > libgtkglext-x11-1.0.so;
> 
> Weird. Perhaps this is something about the way libtool works (or
> doesn't) on FreeBSD? gtkglext is included in the openvrml distribution
> and the libraries you mention are used as "convenience libraries"--which
> means that they should effectively be statically linked into
> openvrml-xembed. That, anyway, is how it works on Linux.

Actually on FreeBSD they are not linked statically. Note that it's not a
problem to install these libs manually, I was just curious.

> > - openvrml-player can display e.g. the example Anchor.wrl, but trying
> > warbird.wrl only displays the following messages:
> > 
> > ROLL_TURN: 3: Error: axis component of rotation is not normalized
> > openvrml/script.cpp:3257: verification (ok) failed
> > UP_DOWN_TURN: 5: Error: axis component of rotation is not normalized
> > openvrml/script.cpp:3257: verification (ok) failed
> > 35: Error: axis component of rotation is not normalized
> > openvrml/script.cpp:3257: verification (ok) failed
> > 35: Error: axis component of rotation is not normalized
> > openvrml/script.cpp:3257: verification (ok) failed
> 
> These are normal. The warnings are benign; warbird.wrl just needs to be
> cleaned up a bit to quell these.

OK, thanks. And I forgot to write that all tests pass successfully when
I run `make check-TESTS'.

> > Assertion failed: (value == value), function x, file ./openvrml/basetypes.h, line 475.
> > 
> > (openvrml-player:81595): GLib-CRITICAL **: g_error_free: assertion `error != NULL' failed
> > 
> > Do you see these messages on other platforms?
> 
> This I haven't seen. (Or rather, I've seen things like it before, but
> I'm not seeing it when I run warbird.wrl now.) Could you provide a stack
> trace? (Best would be to open a new bug on SourceForge and attach it to
> that.)

OK, I'll try to build it again with debug symbols and investigate.

Regards,
-- 
Th. Thomas.

Re: [openvrml-develop] openvrml-0.16.5: strange behaviour on FreeBSD.

[Braden M. <br...@en...>]

On Sun, 2007-06-03 at 22:29 +0200, Thierry Thomas wrote:
> Hello,
> 
> Trying to upgrade the FreeBSD port - still v. 0.15.10 - I have noticed
> some points:
> 
> - it builds fine, but I have to link openvrml-xembed and the tests
> programs with JNI_LIBS, ${JAVA_HOME}/jre/lib/${ARCH}/client/libjvm.so;

You must have enabled the Script node Java support. That isn't advised.
This feature isn't really supported in the current release. It doesn't
work well enough to be called "functional"; so turning it on definitely
isn't worth any problems doing so may cause.

> - to run it, I have to manually install libgdkglext-x11-1.0.so and
> libgtkglext-x11-1.0.so;

Weird. Perhaps this is something about the way libtool works (or
doesn't) on FreeBSD? gtkglext is included in the openvrml distribution
and the libraries you mention are used as "convenience libraries"--which
means that they should effectively be statically linked into
openvrml-xembed. That, anyway, is how it works on Linux.

> - openvrml-player can display e.g. the example Anchor.wrl, but trying
> warbird.wrl only displays the following messages:
> 
> ROLL_TURN: 3: Error: axis component of rotation is not normalized
> openvrml/script.cpp:3257: verification (ok) failed
> UP_DOWN_TURN: 5: Error: axis component of rotation is not normalized
> openvrml/script.cpp:3257: verification (ok) failed
> 35: Error: axis component of rotation is not normalized
> openvrml/script.cpp:3257: verification (ok) failed
> 35: Error: axis component of rotation is not normalized
> openvrml/script.cpp:3257: verification (ok) failed

These are normal. The warnings are benign; warbird.wrl just needs to be
cleaned up a bit to quell these.

> Assertion failed: (value == value), function x, file ./openvrml/basetypes.h, line 475.
> 
> (openvrml-player:81595): GLib-CRITICAL **: g_error_free: assertion `error != NULL' failed
> 
> Do you see these messages on other platforms?

This I haven't seen. (Or rather, I've seen things like it before, but
I'm not seeing it when I run warbird.wrl now.) Could you provide a stack
trace? (Best would be to open a new bug on SourceForge and attach it to
that.)

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] openvrml-0.16.5: strange behaviour on FreeBSD.

[Thierry T. <th...@Fr...>]

Hello,

Trying to upgrade the FreeBSD port - still v. 0.15.10 - I have noticed
some points:

- it builds fine, but I have to link openvrml-xembed and the tests
programs with JNI_LIBS, ${JAVA_HOME}/jre/lib/${ARCH}/client/libjvm.so;

- to run it, I have to manually install libgdkglext-x11-1.0.so and
libgtkglext-x11-1.0.so;

- openvrml-player can display e.g. the example Anchor.wrl, but trying
warbird.wrl only displays the following messages:

ROLL_TURN: 3: Error: axis component of rotation is not normalized
openvrml/script.cpp:3257: verification (ok) failed
UP_DOWN_TURN: 5: Error: axis component of rotation is not normalized
openvrml/script.cpp:3257: verification (ok) failed
35: Error: axis component of rotation is not normalized
openvrml/script.cpp:3257: verification (ok) failed
35: Error: axis component of rotation is not normalized
openvrml/script.cpp:3257: verification (ok) failed
Assertion failed: (value == value), function x, file ./openvrml/basetypes.h, line 475.

(openvrml-player:81595): GLib-CRITICAL **: g_error_free: assertion `error != NULL' failed

Do you see these messages on other platforms?

For thoses interested, my patch to upgrade the FreeBSD port is
available at <http://people.freebsd.org/~thierry/ports/openvrml.diff>.

Regards,
-- 
Th. Thomas.

[openvrml-develop] ANN: OpenVRML 0.16.5

[Braden M. <br...@en...>]

OpenVRML 0.16.5 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.16.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.16.5:

- Fixed openvrml-player to know about its application data directory.

[openvrml-develop] Migrating to Subversion

[Braden M. <br...@en...>]

I have put off migrating OpenVRML to Subversion for a while for a couple 
  of reasons:

   * CVS, for the most part, works adequately for this project.
   * I did not want to be an early adopter of the SourceForge Subversion
     service. I'm happy to let someone else experience any growing pains
     associated with that.

But now that SourceForge's Subversion service has been in place for a 
while, I think it's time to take another look at this.

   * Subversion is not without its quirks; but on balance, it tends to
     work better than CVS.
   * New developers are probably about as likely to have used Subversion
     as they are to have used CVS. And as time goes on, they are probably
    *more* likely to have used Subversion than they are to have used CVS.

With this in mind, I'm inclined to migrate OpenVRML to Subversion in the 
near future; probably shortly after 0.16.5 is released.

Braden

[openvrml-develop] ANN: OpenVRML 0.16.4

[Braden M. <br...@en...>]

OpenVRML 0.16.4 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.16.4.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.16.4:

- openvrml-gtkplug has been renamed to openvrml-xembed.

- Added openvrml-player, a stand-alone container for openvrml-xembed.
  openvrml-player uses libcurl for resource fetching.

- Fixed coordinate generation for Extrusion node rendering.

- Fixed progressive rendering of JPEG images.

- Various other minor bug fixes.

Re: [openvrml-develop] Progress toward a release

[Braden M. <br...@en...>]

On Sun, 2007-04-15 at 11:58 -0400, Reed Hedges wrote:
> Sounds good.
> 
> I'm guessing the API change won't be huge?

To 0.16.4? Should be nonexistent with respect to 0.16.3. Or I've made a
boo boo.

As far as 0.17.0 is concerned, it's far too early to say. But based on
what I'm currently planning for that release, I don't think it will be
that big.

>  I've started updating my old
> code to 0.16.3.   I did have one issue with 0.16.3 that I'll post under
> a seperate subject or in the bug tracker.

Please do.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] Progress toward a release

[Reed H. <re...@in...>]

Sounds good.

I'm guessing the API change won't be huge? I've started updating my old
code to 0.16.3.   I did have one issue with 0.16.3 that I'll post under
a seperate subject or in the bug tracker.

Reed



Braden McDaniel wrote:
> I haven't had a whole lot of time to work on OpenVRML lately; what time
> I have had I've spent getting issues with
> openvrml-player/openvrml-xembed worked out.
> 
> As it stands, Bad Things will still happen if a user attempts to load a
> new world (or reload the same world) before the current one (including
> all Inlines, images, etc.) has finished loading. And I have reluctantly
> come to the conclusion that fixing this will require API changes. And
> that means it won't be fixed for 0.16.4.
> 
> Some significant fixes have happened since 0.16.3; so I think 0.16.4
> will be worth doing in spite of this problem. After 0.16.4 is out, I'll
> move on to fixing this for 0.17. This means that 0.17 won't have all the
> new features I had wanted to put in it. But at this point I think the
> most important thing is to ensure the plug-in and stand-alone viewers
> are stable and robust.
> 

[openvrml-develop] Progress toward a release

[Braden M. <br...@en...>]

I haven't had a whole lot of time to work on OpenVRML lately; what time
I have had I've spent getting issues with
openvrml-player/openvrml-xembed worked out.

As it stands, Bad Things will still happen if a user attempts to load a
new world (or reload the same world) before the current one (including
all Inlines, images, etc.) has finished loading. And I have reluctantly
come to the conclusion that fixing this will require API changes. And
that means it won't be fixed for 0.16.4.

Some significant fixes have happened since 0.16.3; so I think 0.16.4
will be worth doing in spite of this problem. After 0.16.4 is out, I'll
move on to fixing this for 0.17. This means that 0.17 won't have all the
new features I had wanted to put in it. But at this point I think the
most important thing is to ensure the plug-in and stand-alone viewers
are stable and robust.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] building for FF 1.5.10 (fedora linux)

[Braden M. <br...@en...>]

Nicholas F. Polys wrote:
> Ah - I was using CFLAGS and not CPPFLAGS.
> It worked - now installed.

Options such as -I and -D are for the C preprocessor.

CFLAGS (for the C compiler) is used hardly anywhere in OpenVRML, since 
it is written in C++. CXXFLAGS (for the C++ compiler) would probably 
have worked (since none of the code in question invokes the C 
preprocessor outside the context of compiling C++); though CPPFLAGS is 
the one that is actually supposed to work.

I found time today to update the Fedora package; so updating OpenVRML 
via that route should work, too. (At least, it will once the new 
binaries propagate to the mirrors.)

I had hoped to have 0.16.4 out by now; however, openvrml-player still 
isn't quite robust enough for me feel it's release-worthy. There is a 
noteworthy fix to the library on the 0penVRML-0_16-BRANCH: loading JPEGs 
over the network should now work reliably. So if you're doing that, I'd 
suggest checking out CVS for the time being.

Braden

Re: [openvrml-develop] building for FF 1.5.10 (fedora linux)

[Nicholas F. P. <np...@vt...>]

Ah - I was using CFLAGS and not CPPFLAGS.
It worked - now installed.

thanks Braden!

_n_polys



Braden McDaniel wrote:
> Nicholas F. Polys wrote:
>> Hi all~
>>
>> any idea of the best way to do this?
>> 	we are having trouble building since it seem O-V was last released for 1.5.9?
> 
> The only problem I am aware of is a minor bug in the build system that 
> prevents the top-level Mozilla include directory from making its way 
> into CPPFLAGS; so finding mozilla-config.h will fail. You should be able 
> to add this to CPPFLAGS explicitly at configure time, e.g.:
> 
>    $ ./configure CPPFLAGS='-I/usr/include/firefox-1.5.0.10'
> 
> As it happens, I think this workaround should also counteract some 
> breakage introduced by the Fedora firefox package maintainers.
> 
> If you are encountering some other problem, I will need details.
> 
> It looks like said package maintainers have finally pushed a version 
> where firefox-js.pc is once again useable; so I will be updating the 
> openvrml package in kind. However, I'm going out of town tomorrow; so if 
> I don't get to it today/tonight, it won't happen until the middle of 
> next week.
> 
> Braden
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
> 

Re: [openvrml-develop] building for FF 1.5.10 (fedora linux)

[Braden M. <br...@en...>]

Nicholas F. Polys wrote:
> Hi all~
> 
> any idea of the best way to do this?
> 	we are having trouble building since it seem O-V was last released for 1.5.9?

The only problem I am aware of is a minor bug in the build system that 
prevents the top-level Mozilla include directory from making its way 
into CPPFLAGS; so finding mozilla-config.h will fail. You should be able 
to add this to CPPFLAGS explicitly at configure time, e.g.:

   $ ./configure CPPFLAGS='-I/usr/include/firefox-1.5.0.10'

As it happens, I think this workaround should also counteract some 
breakage introduced by the Fedora firefox package maintainers.

If you are encountering some other problem, I will need details.

It looks like said package maintainers have finally pushed a version 
where firefox-js.pc is once again useable; so I will be updating the 
openvrml package in kind. However, I'm going out of town tomorrow; so if 
I don't get to it today/tonight, it won't happen until the middle of 
next week.

Braden

[openvrml-develop] building for FF 1.5.10 (fedora linux)

[Nicholas F. P. <np...@vt...>]

Hi all~

any idea of the best way to do this?
	we are having trouble building since it seem O-V was last released for 1.5.9?

thanks and best regards,

	_nicholas


Nicholas F. Polys, Ph.D.

Visualization and Research Computing 
Virginia Tech Information Technology 

Re: [openvrml-develop] please help me..

[Braden M. <br...@en...>]

On Thu, 2007-03-01 at 09:23 +0100, Thomas Engelmeier wrote:
> Am 01.03.2007 um 05:06 schrieb Braden McDaniel:
> 
> > Extremely unlikely. OpenVRML should have no such problem.
> >
> >> anyone could help me?
> >>
> >> thank you for your cooperation
> >
> > I don't know what the file "isctype.c" is. It's not part of OpenVRML.
> > So, a stack trace would help.
> 
> Probably an implementation detail of <ctype.h> aka <cctype> for  
> is_digit( int ch ) et al...

In other words, inside Microsoft's C runtime library.

> It seems to get passed in something that exceeds the unsigned char  
> range [0,255] - either due to an casting error (char vs. unsigned  
> char assigned to an int -> sign expansion) or an file parsing error.

Well, yes. But where this is occurring is anyone's guess. Hence the need
for a stack trace in order to make heads or tails of this.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] please help me..

[Thomas E. <te-...@en...>]

Am 01.03.2007 um 05:06 schrieb Braden McDaniel:

> Extremely unlikely. OpenVRML should have no such problem.
>
>> anyone could help me?
>>
>> thank you for your cooperation
>
> I don't know what the file "isctype.c" is. It's not part of OpenVRML.
> So, a stack trace would help.

Probably an implementation detail of <ctype.h> aka <cctype> for  
is_digit( int ch ) et al...
It seems to get passed in something that exceeds the unsigned char  
range [0,255] - either due to an casting error (char vs. unsigned  
char assigned to an int -> sign expansion) or an file parsing error.

Re: [openvrml-develop] please help me..

[Braden M. <br...@en...>]

On Wed, 2007-02-28 at 19:04 -0800, delia mansor wrote:
> hello everybody.. 
> 
> i have a vrml object but i stuck with this error.
> 
> http://img225.imageshack.us/img225/3421/error4fe8.jpg
> 
> is it because of my vrml object has exceeded the length of 255 line ?

Extremely unlikely. OpenVRML should have no such problem.

> anyone could help me?
> 
> thank you for your cooperation

I don't know what the file "isctype.c" is. It's not part of OpenVRML.
So, a stack trace would help.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>