openvrml-develop

[openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

Hello,


I'm using OpenVRML for the first time, and after compiling and running the VC90 project parse-vrml97,
it crashes on me.  I get the error message:

 

parse-vrml97.exe - Application Error
"The application failed to initialize properly (0xe06d7363). Click on OK to terminate the application."

 

I'm using MSVS 2008 C++, openvrml-0.18.6, and boost_1_43_0.

 

I compiled boost with this line:
bjam.exe --toolset=msvc-9.0 variant=release link=static threading=multi  stage  --with-thread  --with-filesystem  --with-date_time  --with-system

 

and it gives me these libs:
libboost_date_time-vc90-mt-1_43.lib
libboost_filesystem-vc90-mt-1_43.lib
libboost_system-vc90-mt-1_43.lib
libboost_thread-vc90-mt-1_43.lib

 

Then I compiled openvrml and parse-vrml97 in Release mode.  It gave me these files:
parse-vrml97.exe
openvrml.dll


I also tried Debug mode.  I recompile boost and it gives me these files:
libboost_date_time-vc90-mt-gd-1_43.lib
libboost_filesystem-vc90-mt-gd-1_43.lib
libboost_system-vc90-mt-gd-1_43.lib
libboost_thread-vc90-mt-gd-1_43.lib

 

I recompile openvrml in debug mode, and parse-vrml97.exe still crashes.  I get same error message.

 

Any suggestions?

 		 	   		  
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Thu, 2010-07-01 at 06:46 -0400, Sam Url wrote: 
> I'm using OpenVRML for the first time, and after compiling and running the VC90 project parse-vrml97,
> it crashes on me.  I get the error message:
> 
>  
> 
> parse-vrml97.exe - Application Error
> "The application failed to initialize properly (0xe06d7363). Click on OK to terminate the application."

Have you set the environment variables OPENVRML_DATADIR,
OPENVRML_NODE_PATH, and OPENVRML_SCRIPT_PATH (as per README)?  What are
they set to?

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

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

[Please follow-up to the mailing list.]

On 7/1/10 4:39 PM, Sam Url wrote:
> Hi,
>  
> I didn't set any environmental variables yet.
> But, why would that cause a crash, even if they weren't set?

Because libopenvrml uses these variables to initialize some global
objects.  If it can't find what it needs, that initialization fails;
that is, an exception gets thrown.

On Windows, throwing an exception during static initialization appears
to be a bit dodgy; the resulting crash gives a message that isn't
ideally lucid.  The message could probably be improved (with some
platform specific code); but the result (a crash) will be the same.

> I thought these are stand-alone executables?

I'm not 100% clear on what this means to you.  The provided project
files build libopenvrml as a DLL.  And the node implementations and
scripting engines all live in plug-in DLLs.  OPENVRML_NODE_PATH and
OPENVRML_SCRIPT_PATH are used to find these bits.  OPENVRML_DATADIR is
used to find the component XML descriptor files.

> Ok, I added those paths to my environment with some default values,
> and parse-vrml97.exe still crashes.   I also compiled parse-x3dvrml.exe,
> and that crashes too.

What did you set them to?

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

>>What did you set them to?


set OPENVRML_DATADIR=C:\openvrml-0.18.6\data 
set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\src\node
set OPENVRML_SCRIPT_PATH=C:\openvrml-0.18.6\models\rotation_toy.wrl

 

It still crashes on me.

 

>> I'm not 100% clear on what this means to you. The provided project
>> files build libopenvrml as a DLL. And the node implementations and
>> scripting engines all live in plug-in DLLs.

 

I would like to use OpenVRML to open and parse VRML files.  Does this require a node/scripting engine?

 

If I ever distribute my own stand-alone VRML reader/viewer based on the OpenVRML libraries,
can I do this minimalistically, without any node/scripting setup?

 

I was hoping openvrml.dll was the only file I needed to distribute.


 
> Date: Thu, 1 Jul 2010 17:13:14 -0400
> From: br...@en...
> To: ope...@li...
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> [Please follow-up to the mailing list.]
> 
> On 7/1/10 4:39 PM, Sam Url wrote:
> > Hi,
> > 
> > I didn't set any environmental variables yet.
> > But, why would that cause a crash, even if they weren't set?
> 
> Because libopenvrml uses these variables to initialize some global
> objects. If it can't find what it needs, that initialization fails;
> that is, an exception gets thrown.
> 
> On Windows, throwing an exception during static initialization appears
> to be a bit dodgy; the resulting crash gives a message that isn't
> ideally lucid. The message could probably be improved (with some
> platform specific code); but the result (a crash) will be the same.
> 
> > I thought these are stand-alone executables?
> 
> I'm not 100% clear on what this means to you. The provided project
> files build libopenvrml as a DLL. And the node implementations and
> scripting engines all live in plug-in DLLs. OPENVRML_NODE_PATH and
> OPENVRML_SCRIPT_PATH are used to find these bits. OPENVRML_DATADIR is
> used to find the component XML descriptor files.
> 
> > Ok, I added those paths to my environment with some default values,
> > and parse-vrml97.exe still crashes. I also compiled parse-x3dvrml.exe,
> > and that crashes too.
> 
> What did you set them to?
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Thu, 2010-07-01 at 18:43 -0400, Sam Url wrote: 
> >>What did you set them to?
> 
> 
> set OPENVRML_DATADIR=C:\openvrml-0.18.6\data 
> set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\src\node
> set OPENVRML_SCRIPT_PATH=C:\openvrml-0.18.6\models\rotation_toy.wrl
> 
>  
> 
> It still crashes on me.

Again, note the descriptions of these variables in README.
OPENVRML_NODE_PATH is where you have *compiled* node implementations
(e.g., vrml97.dll).  OPENVRML_SCRIPT_PATH is where you have compiled
scripting engines (e.g., javascript.dll).

> >> I'm not 100% clear on what this means to you. The provided project
> >> files build libopenvrml as a DLL. And the node implementations and
> >> scripting engines all live in plug-in DLLs.
> 
>  
> 
> I would like to use OpenVRML to open and parse VRML files.  Does this require a node/scripting engine?

If you provide your own semantic actions for the parser, no.  (You will,
however, still need the component descriptors--that's where the parser
gets its information about how to parse specific nodes.)  See
pretty-print for an example that provides its own semantic actions.

The parse-vrml97 and parse-x3d test programs use the semantic actions
that are compiled into libopenvrml--and these create a tree of
openvrml::nodes using the node implementations.

You only need a scripting engine if you want to process scripts at
run-time.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

Hi,

 

>>OPENVRML_NODE_PATH is where you have *compiled* node implementations
>>(e.g., vrml97.dll). OPENVRML_SCRIPT_PATH is where you have compiled
>>scripting engines (e.g., javascript.dll).

 

Ok, I'm unable to build javascript.dll, because jsapi.h is missing.
But, as you mentioned, I don't need it if I don't use scripting.

 

And, I tried to build vrml97.dll, but it says ft2build.h is missing.

 

I noticed OPENVRML_ENABLE_RENDER_TEXT_NODE was defined in the proprocessor list,
so I removed it.  But, I'm still getting compilation errors from text.cpp
still being dependent on FreeType:
c:\openvrml-0.18.6\src\node\vrml97\text.cpp(139) : error C2061: syntax error : identifier 'FT_Face'

 

Is FreeType required to build vrml97.dll?

 

And there are 3 projects missing:
x3d-environmental-effects (unavailable)
x3d-event-utilities (unavailable)
x3d-key-device-sensor (unavailable)

 

My compiled node .DLLs are located here:
set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\Debug\bin\node

 

x3d-texturing.dll
x3d-cad-geometry.dll
x3d-shape.dll
x3d-rendering.dll
x3d-nurbs.dll
x3d-networking.dll
x3d-core.dll
x3d-interpolation.dll
x3d-h-anim.dll
x3d-grouping.dll
x3d-geospatial.dll
x3d-dis.dll
x3d-geometry2d.dll

 

I was able to compile pretty-print.exe, but this crashes on me too, even after
setting OPENVRML_NODE_PATH.


 
> From: br...@en...
> To: ope...@li...
> Date: Fri, 2 Jul 2010 02:20:44 -0400
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> On Thu, 2010-07-01 at 18:43 -0400, Sam Url wrote: 
> > >>What did you set them to?
> > 
> > 
> > set OPENVRML_DATADIR=C:\openvrml-0.18.6\data 
> > set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\src\node
> > set OPENVRML_SCRIPT_PATH=C:\openvrml-0.18.6\models\rotation_toy.wrl
> > 
> > 
> > 
> > It still crashes on me.
> 
> Again, note the descriptions of these variables in README.
> OPENVRML_NODE_PATH is where you have *compiled* node implementations
> (e.g., vrml97.dll). OPENVRML_SCRIPT_PATH is where you have compiled
> scripting engines (e.g., javascript.dll).
> 
> > >> I'm not 100% clear on what this means to you. The provided project
> > >> files build libopenvrml as a DLL. And the node implementations and
> > >> scripting engines all live in plug-in DLLs.
> > 
> > 
> > 
> > I would like to use OpenVRML to open and parse VRML files. Does this require a node/scripting engine?
> 
> If you provide your own semantic actions for the parser, no. (You will,
> however, still need the component descriptors--that's where the parser
> gets its information about how to parse specific nodes.) See
> pretty-print for an example that provides its own semantic actions.
> 
> The parse-vrml97 and parse-x3d test programs use the semantic actions
> that are compiled into libopenvrml--and these create a tree of
> openvrml::nodes using the node implementations.
> 
> You only need a scripting engine if you want to process scripts at
> run-time.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. 
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Fri, 2010-07-02 at 17:35 -0400, Sam Url wrote: 
> >>OPENVRML_NODE_PATH is where you have *compiled* node implementations
> >>(e.g., vrml97.dll). OPENVRML_SCRIPT_PATH is where you have compiled
> >>scripting engines (e.g., javascript.dll).
>  
> Ok, I'm unable to build javascript.dll, because jsapi.h is missing.
> But, as you mentioned, I don't need it if I don't use scripting.

You'll need the XULRunner SDK or SpiderMonkey to build this.

You'd probably benefit from reading this:

        http://sourceforge.net/apps/trac/openvrml/wiki/BuildOpenvrmlOnWindows

> And, I tried to build vrml97.dll, but it says ft2build.h is missing.
> 
>  
> 
> I noticed OPENVRML_ENABLE_RENDER_TEXT_NODE was defined in the proprocessor list,
> so I removed it.  But, I'm still getting compilation errors from text.cpp
> still being dependent on FreeType:
> c:\openvrml-0.18.6\src\node\vrml97\text.cpp(139) : error C2061: syntax error : identifier 'FT_Face'
> 
>  
> 
> Is FreeType required to build vrml97.dll?

Sigh... Yes; but removing that preprocessor symbol definition is
supposed to remove the need for FreeType.  That's a bug.

> And there are 3 projects missing:
> x3d-environmental-effects (unavailable)
> x3d-event-utilities (unavailable)
> x3d-key-device-sensor (unavailable)

This sounds similar to an error someone else reported; but those files
are present in the archive.  I suspect that there's a problem with your
unarchiving program.

> My compiled node .DLLs are located here:
> set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\Debug\bin\node
> 
>  
> 
> x3d-texturing.dll
> x3d-cad-geometry.dll
> x3d-shape.dll
> x3d-rendering.dll
> x3d-nurbs.dll
> x3d-networking.dll
> x3d-core.dll
> x3d-interpolation.dll
> x3d-h-anim.dll
> x3d-grouping.dll
> x3d-geospatial.dll
> x3d-dis.dll
> x3d-geometry2d.dll
> 
>  
> 
> I was able to compile pretty-print.exe, but this crashes on me too, even after
> setting OPENVRML_NODE_PATH.

I'm going to investigate this.  If you're able to provide me with a
stack trace of where the crash occurs, that will save me some time.  If
you do have this, please file a bug in trac and attach it there.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Fri, 2010-07-02 at 23:31 -0400, Braden McDaniel wrote: 
> On Fri, 2010-07-02 at 17:35 -0400, Sam Url wrote: 

[snip]

> > I noticed OPENVRML_ENABLE_RENDER_TEXT_NODE was defined in the proprocessor list,
> > so I removed it.  But, I'm still getting compilation errors from text.cpp
> > still being dependent on FreeType:
> > c:\openvrml-0.18.6\src\node\vrml97\text.cpp(139) : error C2061: syntax error : identifier 'FT_Face'
> > 
> >  
> > 
> > Is FreeType required to build vrml97.dll?
> 
> Sigh... Yes; but removing that preprocessor symbol definition is
> supposed to remove the need for FreeType.  That's a bug.

This should now be fixed on the trunk and branches/0.18.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

>>You'd probably benefit from reading this:
>>http://sourceforge.net/apps/trac/openvrml/wiki/BuildOpenvrmlOnWindows

 

Thanks, much better!


>>This sounds similar to an error someone else reported; but those files
>>are present in the archive. I suspect that there's a problem with your
>>unarchiving program.

 

I've tried using WinZip, 7-Zip, and WinRar, but those 3 folders still don't have any projects in them.
I also ran an archive file integrity test, and didn't find any archive corruption.


>>I'm going to investigate this. If you're able to provide me with astack trace of where the crash occurs, 
>>that will save me some time. Ifyou do have this, please file a bug in trac and attach it there.

 

Added!


 
> From: br...@en...
> To: ope...@li...
> Date: Fri, 2 Jul 2010 23:31:11 -0400
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> On Fri, 2010-07-02 at 17:35 -0400, Sam Url wrote: 
> > >>OPENVRML_NODE_PATH is where you have *compiled* node implementations
> > >>(e.g., vrml97.dll). OPENVRML_SCRIPT_PATH is where you have compiled
> > >>scripting engines (e.g., javascript.dll).
> > 
> > Ok, I'm unable to build javascript.dll, because jsapi.h is missing.
> > But, as you mentioned, I don't need it if I don't use scripting.
> 
> You'll need the XULRunner SDK or SpiderMonkey to build this.
> 
> You'd probably benefit from reading this:
> 
> http://sourceforge.net/apps/trac/openvrml/wiki/BuildOpenvrmlOnWindows
> 
> > And, I tried to build vrml97.dll, but it says ft2build.h is missing.
> > 
> > 
> > 
> > I noticed OPENVRML_ENABLE_RENDER_TEXT_NODE was defined in the proprocessor list,
> > so I removed it. But, I'm still getting compilation errors from text.cpp
> > still being dependent on FreeType:
> > c:\openvrml-0.18.6\src\node\vrml97\text.cpp(139) : error C2061: syntax error : identifier 'FT_Face'
> > 
> > 
> > 
> > Is FreeType required to build vrml97.dll?
> 
> Sigh... Yes; but removing that preprocessor symbol definition is
> supposed to remove the need for FreeType. That's a bug.
> 
> > And there are 3 projects missing:
> > x3d-environmental-effects (unavailable)
> > x3d-event-utilities (unavailable)
> > x3d-key-device-sensor (unavailable)
> 
> This sounds similar to an error someone else reported; but those files
> are present in the archive. I suspect that there's a problem with your
> unarchiving program.
> 
> > My compiled node .DLLs are located here:
> > set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\Debug\bin\node
> > 
> > 
> > 
> > x3d-texturing.dll
> > x3d-cad-geometry.dll
> > x3d-shape.dll
> > x3d-rendering.dll
> > x3d-nurbs.dll
> > x3d-networking.dll
> > x3d-core.dll
> > x3d-interpolation.dll
> > x3d-h-anim.dll
> > x3d-grouping.dll
> > x3d-geospatial.dll
> > x3d-dis.dll
> > x3d-geometry2d.dll
> > 
> > 
> > 
> > I was able to compile pretty-print.exe, but this crashes on me too, even after
> > setting OPENVRML_NODE_PATH.
> 
> I'm going to investigate this. If you're able to provide me with a
> stack trace of where the crash occurs, that will save me some time. If
> you do have this, please file a bug in trac and attach it there.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Sat, 2010-07-03 at 15:25 -0400, Sam Url wrote: 
> 
> >>You'd probably benefit from reading this:
> >>http://sourceforge.net/apps/trac/openvrml/wiki/BuildOpenvrmlOnWindows
> 
>  
> 
> Thanks, much better!
> 
> 
> >>This sounds similar to an error someone else reported; but those files
> >>are present in the archive. I suspect that there's a problem with your
> >>unarchiving program.
> 
>  
> 
> I've tried using WinZip, 7-Zip, and WinRar, but those 3 folders still don't have any projects in them.
> I also ran an archive file integrity test, and didn't find any archive corruption.

Those programs may have buggy support for the tar pax format that
OpenVRML uses.  (It uses this precisely for the longer path lengths
supported by pax.)  If all else fails, you should be able to get GNU tar
via Cygwin.  The "Services for Unix" subsystem in Windows might provide
it, too.

Note:

        $ tar tvf openvrml-0.18.6.tar.gz | grep environmental-effects[.]vcproj
        -rw-r--r-- braden/users    4598 2009-07-04 17:20 openvrml-0.18.6/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj
        $ tar tvf openvrml-0.18.6.tar.gz | grep event-utilities[.]vcproj
        -rw-r--r-- braden/users    5904 2009-07-04 17:20 openvrml-0.18.6/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-event-utilities/x3d-event-utilities.vcproj
        $ tar tvf openvrml-0.18.6.tar.gz | grep key-device-sensor[.]vcproj
        -rw-r--r-- braden/users    4785 2009-07-04 17:20 openvrml-0.18.6/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-key-device-sensor/x3d-key-device-sensor.vcproj

I didn't realize that faulty PAX support was so widespread among Windows
unarchivers.  Kind of lame, considering this format has been part of
POSIX for a decade.  Oh, well.  I haven't provided a .zip distribution
in the past because I thought a gzipped tarball was reasonably
accessible to Windows users.  But if that's not the case, I need to
reconsider.

> >>I'm going to investigate this. If you're able to provide me with astack trace of where the crash occurs, 
> >>that will save me some time. Ifyou do have this, please file a bug in trac and attach it there.
> 
>  
> 
> Added!

Thank you!

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

>> -rw-r--r-- braden/users 4598 2009-07-04 17:20 openvrml-0.18.6/ide->>projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj


Well, that's strange.  This pathname is only 115 characters.  Windows can support up to 260 characters for MAX_PATH:

 

"openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-environmental-effects\x3d-environmental-effects.vcproj"

 

Length of the path should not be a problem here.

 

I also tried GnuWin32 tar and gzip commandline tools, and it still doesn't list those files.

Have not tried Cygwin.

 

 
> From: br...@en...
> To: ope...@li...
> Date: Sat, 3 Jul 2010 16:45:47 -0400
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> On Sat, 2010-07-03 at 15:25 -0400, Sam Url wrote: 
> > 
> > >>You'd probably benefit from reading this:
> > >>http://sourceforge.net/apps/trac/openvrml/wiki/BuildOpenvrmlOnWindows
> > 
> > 
> > 
> > Thanks, much better!
> > 
> > 
> > >>This sounds similar to an error someone else reported; but those files
> > >>are present in the archive. I suspect that there's a problem with your
> > >>unarchiving program.
> > 
> > 
> > 
> > I've tried using WinZip, 7-Zip, and WinRar, but those 3 folders still don't have any projects in them.
> > I also ran an archive file integrity test, and didn't find any archive corruption.
> 
> Those programs may have buggy support for the tar pax format that
> OpenVRML uses. (It uses this precisely for the longer path lengths
> supported by pax.) If all else fails, you should be able to get GNU tar
> via Cygwin. The "Services for Unix" subsystem in Windows might provide
> it, too.
> 
> Note:
> 
> $ tar tvf openvrml-0.18.6.tar.gz | grep environmental-effects[.]vcproj
> -rw-r--r-- braden/users 4598 2009-07-04 17:20 openvrml-0.18.6/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj
> $ tar tvf openvrml-0.18.6.tar.gz | grep event-utilities[.]vcproj
> -rw-r--r-- braden/users 5904 2009-07-04 17:20 openvrml-0.18.6/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-event-utilities/x3d-event-utilities.vcproj
> $ tar tvf openvrml-0.18.6.tar.gz | grep key-device-sensor[.]vcproj
> -rw-r--r-- braden/users 4785 2009-07-04 17:20 openvrml-0.18.6/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-key-device-sensor/x3d-key-device-sensor.vcproj
> 
> I didn't realize that faulty PAX support was so widespread among Windows
> unarchivers. Kind of lame, considering this format has been part of
> POSIX for a decade. Oh, well. I haven't provided a .zip distribution
> in the past because I thought a gzipped tarball was reasonably
> accessible to Windows users. But if that's not the case, I need to
> reconsider.
> 
> > >>I'm going to investigate this. If you're able to provide me with astack trace of where the crash occurs, 
> > >>that will save me some time. Ifyou do have this, please file a bug in trac and attach it there.
> > 
> > 
> > 
> > Added!
> 
> Thank you!
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Sat, 2010-07-03 at 20:55 -0400, Sam Url wrote: 
> >> -rw-r--r-- braden/users 4598 2009-07-04 17:20 openvrml-0.18.6/ide->>projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj
> 
> 
> Well, that's strange.  This pathname is only 115 characters.  Windows can support up to 260 characters for MAX_PATH:

Windows can actually support path lengths a good deal longer than that;
but various tools impose an artificial restriction because they use an
obsolete API.

> "openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-environmental-effects\x3d-environmental-effects.vcproj"
> 
>  
> 
> Length of the path should not be a problem here.

As far as Windows' limitation is concerned, it shouldn't--in theory.
But I wonder if the path to the current working directory has any
bearing on this.

> I also tried GnuWin32 tar and gzip commandline tools, and it still doesn't list those files.

Now that's especially interesting; because GnuWin32 tar should (I think)
be the same codebase as Cygwin GNU tar (which is the same codebase as
Linux GNU tar).  That sort of thing makes me suspect that this might, in
fact, be an issue of the affected programs using an (arguably
malfunctioning) Windows POSIX API that's imposing an artificially short
path length.

For what it's worth, I think I've decided to move the Visual C++ project
files under the src directory in the distribution to be near their
related source files.  The main reason for not doing this in the past
was some anticipation that lots of (possibly conflicting) project files
might be maintained.  In practice, that hasn't happened.  In particular,
there's never been sufficient interest to maintain project files for
more than one version of Visual C++.

So I'll be making that change when migrating to Visual C++ 2010.  But
there needs to be a Boost release with a shared_mutex that works with
that compiler before I can make an OpenVRML release with Visual C++ 2010
project files.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

Just to let you know, the 3 missing projects I reported, do actually exist.  Only their filenames
are corrupt.  After renaming them, I was able to compile all of them.

 

I noticed that all 3 pathnames stop exactly at 100 characters:

 

openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-environmental-effects\x3d-environmental
openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-event-utilities\x3d-event-utilities.vcp
openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-key-device-sensor\x3d-key-device-sensor

 

Very strange corruption.

 

Anyway, even with all X3D node component DLLs compiled now, pretty-print.exe still crashes.
So, I don't know what else to try.  I tried Debug and Release mode.  Both crash.


 
> From: br...@en...
> To: ope...@li...
> Date: Sat, 3 Jul 2010 21:21:51 -0400
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> On Sat, 2010-07-03 at 20:55 -0400, Sam Url wrote: 
> > >> -rw-r--r-- braden/users 4598 2009-07-04 17:20 openvrml-0.18.6/ide->>projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj
> > 
> > 
> > Well, that's strange. This pathname is only 115 characters. Windows can support up to 260 characters for MAX_PATH:
> 
> Windows can actually support path lengths a good deal longer than that;
> but various tools impose an artificial restriction because they use an
> obsolete API.
> 
> > "openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-environmental-effects\x3d-environmental-effects.vcproj"
> > 
> > 
> > 
> > Length of the path should not be a problem here.
> 
> As far as Windows' limitation is concerned, it shouldn't--in theory.
> But I wonder if the path to the current working directory has any
> bearing on this.
> 
> > I also tried GnuWin32 tar and gzip commandline tools, and it still doesn't list those files.
> 
> Now that's especially interesting; because GnuWin32 tar should (I think)
> be the same codebase as Cygwin GNU tar (which is the same codebase as
> Linux GNU tar). That sort of thing makes me suspect that this might, in
> fact, be an issue of the affected programs using an (arguably
> malfunctioning) Windows POSIX API that's imposing an artificially short
> path length.
> 
> For what it's worth, I think I've decided to move the Visual C++ project
> files under the src directory in the distribution to be near their
> related source files. The main reason for not doing this in the past
> was some anticipation that lots of (possibly conflicting) project files
> might be maintained. In practice, that hasn't happened. In particular,
> there's never been sufficient interest to maintain project files for
> more than one version of Visual C++.
> 
> So I'll be making that change when migrating to Visual C++ 2010. But
> there needs to be a Boost release with a shared_mutex that works with
> that compiler before I can make an OpenVRML release with Visual C++ 2010
> project files.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

Please ignore my last post.  I got it working after setting the node path correctly.
I do recall using that same path before, so the problem might have been something to do with 
not having all the X3D node component DLLs compiled?

 

And I googled "tar 100 characters", and got lot of hits on it.  Everyone prefers
to use GNU tar over Solaris tar, because it apparently solves the char limit problem.

I don't know which one you're using.

 

Anyway, thanks!


 
> From: br...@en...
> To: ope...@li...
> Date: Sat, 3 Jul 2010 21:21:51 -0400
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> On Sat, 2010-07-03 at 20:55 -0400, Sam Url wrote: 
> > >> -rw-r--r-- braden/users 4598 2009-07-04 17:20 openvrml-0.18.6/ide->>projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj
> > 
> > 
> > Well, that's strange. This pathname is only 115 characters. Windows can support up to 260 characters for MAX_PATH:
> 
> Windows can actually support path lengths a good deal longer than that;
> but various tools impose an artificial restriction because they use an
> obsolete API.
> 
> > "openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-environmental-effects\x3d-environmental-effects.vcproj"
> > 
> > 
> > 
> > Length of the path should not be a problem here.
> 
> As far as Windows' limitation is concerned, it shouldn't--in theory.
> But I wonder if the path to the current working directory has any
> bearing on this.
> 
> > I also tried GnuWin32 tar and gzip commandline tools, and it still doesn't list those files.
> 
> Now that's especially interesting; because GnuWin32 tar should (I think)
> be the same codebase as Cygwin GNU tar (which is the same codebase as
> Linux GNU tar). That sort of thing makes me suspect that this might, in
> fact, be an issue of the affected programs using an (arguably
> malfunctioning) Windows POSIX API that's imposing an artificially short
> path length.
> 
> For what it's worth, I think I've decided to move the Visual C++ project
> files under the src directory in the distribution to be near their
> related source files. The main reason for not doing this in the past
> was some anticipation that lots of (possibly conflicting) project files
> might be maintained. In practice, that hasn't happened. In particular,
> there's never been sufficient interest to maintain project files for
> more than one version of Visual C++.
> 
> So I'll be making that change when migrating to Visual C++ 2010. But
> there needs to be a Boost release with a shared_mutex that works with
> that compiler before I can make an OpenVRML release with Visual C++ 2010
> project files.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. 
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Mon, 2010-07-05 at 18:45 -0400, Sam Url wrote: 
> Please ignore my last post.  I got it working after setting the node path correctly.

Was it OPENVRML_NODE_PATH or OPENVRML_DATADIR you had set incorrectly?

> I do recall using that same path before, so the problem might have been something to do with 
> not having all the X3D node component DLLs compiled?

I'm inclined to regard it as a bug if you *need* to have
OPENVRML_NODE_PATH set to run pretty-print.  That is, I think you
shouldn't need the node implementations for that.

> And I googled "tar 100 characters", and got lot of hits on it.  Everyone prefers
> to use GNU tar over Solaris tar, because it apparently solves the char limit problem.
> 
> I don't know which one you're using.

The archives are built with GNU tar on Fedora Linux.  The 0.18.6 tarball
was built, specifically, with GNU tar 1.22 on Fedora 13.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Mon, 2010-07-12 at 00:52 -0400, Braden McDaniel wrote: 
> On Mon, 2010-07-05 at 18:45 -0400, Sam Url wrote: 
> > Please ignore my last post.  I got it working after setting the node path correctly.
> 
> Was it OPENVRML_NODE_PATH or OPENVRML_DATADIR you had set incorrectly?
> 
> > I do recall using that same path before, so the problem might have been something to do with 
> > not having all the X3D node component DLLs compiled?
> 
> I'm inclined to regard it as a bug if you *need* to have
> OPENVRML_NODE_PATH set to run pretty-print.  That is, I think you
> shouldn't need the node implementations for that.

I've tested this, and it appears to be working fine for me.  That is, I
can successfully run pretty-print with only OPENVRML_DATADIR set.

FWIW, note that there are some registry keys that libopenvrml will look
for on Windows in place of these environment variables; see
src/libopenvrml/openvrml/local/conf.cpp.  The idea is that an installer
would set these keys appropriately.  This needs to be documented better;
I'll add information about this to README.

Also, I've discovered that you *can* build openvrml-0.18.6/boost-1.43
using Visual C++ 2010 if you define BOOST_NO_RVALUE_REFERENCES.  I think
the Boost bug that makes this necessary should be fixed in the next
Boost release (1.44).  I am working on a set of Visual C++ 2010 project
files that will appear in the next OpenVRML release.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

Same here too.  As soon as I remove OPENVRML_DATADIR from my environmental variables, the program crashes.

 

 
> From: br...@en...
> To: ope...@li...
> Date: Mon, 12 Jul 2010 16:42:30 -0400
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> On Mon, 2010-07-12 at 00:52 -0400, Braden McDaniel wrote: 
> > On Mon, 2010-07-05 at 18:45 -0400, Sam Url wrote: 
> > > Please ignore my last post. I got it working after setting the node path correctly.
> > 
> > Was it OPENVRML_NODE_PATH or OPENVRML_DATADIR you had set incorrectly?
> > 
> > > I do recall using that same path before, so the problem might have been something to do with 
> > > not having all the X3D node component DLLs compiled?
> > 
> > I'm inclined to regard it as a bug if you *need* to have
> > OPENVRML_NODE_PATH set to run pretty-print. That is, I think you
> > shouldn't need the node implementations for that.
> 
> I've tested this, and it appears to be working fine for me. That is, I
> can successfully run pretty-print with only OPENVRML_DATADIR set.
> 
> FWIW, note that there are some registry keys that libopenvrml will look
> for on Windows in place of these environment variables; see
> src/libopenvrml/openvrml/local/conf.cpp. The idea is that an installer
> would set these keys appropriately. This needs to be documented better;
> I'll add information about this to README.
> 
> Also, I've discovered that you *can* build openvrml-0.18.6/boost-1.43
> using Visual C++ 2010 if you define BOOST_NO_RVALUE_REFERENCES. I think
> the Boost bug that makes this necessary should be fixed in the next
> Boost release (1.44). I am working on a set of Visual C++ 2010 project
> files that will appear in the next OpenVRML release.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1