openvrml-develop Mailing List for OpenVRML (Page 5)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello Braden,

thanks for your help and your hint where to find the exact definition
you use.

I got it to work correctly using some own encoding and decoding.

Greetings,

Frank

On Wed, 2010-09-29 at 18:27 +0200, supplier wrote: 
> Hello,
> 
>  
> 
> We are using openvrml to load wrl-customer-data into our
> visualization-software using our own rendering.
> 
>  
> 
> There's now another issue here on my desk dealing with filenames using
> non-ascii characters. Generally, we use wide-character strings here to
> identify local filenames.
> 
>  
> 
> I guess to be able to load such files using openvrml::browser's
> load_url() I would have to encode the names accordingly to common
> url-conventions just using ascii-chars, and decode them later in my own
> ressource-fetcher on file-access. Is this correct?

Pretty much.

> If so, can I use any
> tools (encode/decode) here within your API to get through easier?

There's nothing like this in OpenVRML's API.

Presumably you're starting from Windows UTF-16.  You probably want to
first convert to UTF-8; then URI-encode any non-ASCII octets and URI
reserved characters.

> I'm not too familiar with url-convention(s); what exactly do you expect
> here?

A valid URI, as specified by RFC 3986:

        http://www.apps.ietf.org/rfc/rfc3986.html

The grammar in Appendix A may be the most helpful bit.

(And truth be told, current OpenVRML really reflects this
specification's predecessor, RFC 2396.  The only major difference is the
addition of the IPv6 bits in 3986.  Support for that will be added when
I update OpenVRML to use Spirit 2.x.)

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

Hello,

We are using openvrml to load wrl-customer-data into our
visualization-software using our own rendering.

There's now another issue here on my desk dealing with filenames using
non-ascii characters. Generally, we use wide-character strings here to
identify local filenames.

I guess to be able to load such files using openvrml::browser's
load_url() I would have to encode the names accordingly to common
url-conventions just using ascii-chars, and decode them later in my own
ressource-fetcher on file-access. Is this correct? If so, can I use any
tools (encode/decode) here within your API to get through easier? 

I'm not too familiar with url-convention(s); what exactly do you expect
here?

Thanks and Greetings,

Frank

On 9/10/10 5:21 PM, Steve Traylen wrote:
> Hi Braden,
> 
> I gave the 0.16.7 version a go.
> 
> openvrml/vrml97node.cpp:5650: warning: missing braces around
> initializer for 'openvrml::node_interface [14]'
> openvrml/vrml97node.cpp: In function
> 'void<unnamed>::openvrml_png_info_callback(png_struct*, png_info*)':
> openvrml/vrml97node.cpp:6435: error: 'MOZ_PNG_get_progressive_ptr' was
> not declared in this scope
> openvrml/vrml97node.cpp:6443: error: 'MOZ_PNG_get_image_w' was not
> declared in this scope
> openvrml/vrml97node.cpp:6444: error: 'MOZ_PNG_get_image_h' was not
> declared in this scope

Since those strings don't occur in OpenVRML's source, I can speculate
that you've managed to include some Mozilla header that has #defined the
conventional libpng function names to something else.  Yet, this error
message suggests that a header that defines these Mozilla-modified
functions is *not* in the include chain.

My advice would be to try to avoid this Mozilla variant of libpng
altogether.  But if for some reason you can't, then I guess you need to
figure out how to ensure these preprocessor macros get applied consistently.

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

Hi Braden,

I gave the 0.16.7 version a go.

openvrml/vrml97node.cpp:5650: warning: missing braces around
initializer for 'openvrml::node_interface [14]'
openvrml/vrml97node.cpp: In function
'void<unnamed>::openvrml_png_info_callback(png_struct*, png_info*)':
openvrml/vrml97node.cpp:6435: error: 'MOZ_PNG_get_progressive_ptr' was
not declared in this scope
openvrml/vrml97node.cpp:6443: error: 'MOZ_PNG_get_image_w' was not
declared in this scope
openvrml/vrml97node.cpp:6444: error: 'MOZ_PNG_get_image_h' was not
declared in this scope

and I've put the full log here.

http://dpaste.org/Nf30/

Any bright ideas.

Steve.

On Fri, Sep 3, 2010 at 11:38 PM, Braden McDaniel <br...@en...> wrote:
> On Fri, 2010-09-03 at 22:38 +0200, Steve Traylen wrote:
>> On Fri, Sep 3, 2010 at 10:29 PM, Braden McDaniel <br...@en...> wrote:
>
> [snip]
>
>> > It's my impression that RHEL6 isn't *that* far away; perhaps it would be
>> > a better target for an EPEL effort?
>>
>> Indeed, we will be running RHEL5 for another 3 or 4 years at least I
>> expect, still
>> have some RHEL3 in some places :-),:-(.
>
> Ouch. :-/
>
>> Will have a go with an older version, I realise GL/Graphics/ .. is a
>> fast moving world.
>> (For what it's worth FreeWRL, is just as hard to build.)
>
> In OpenVRML's case, the Boost and GNOME dependencies are the most
> rapidly moving ones.  If you wanted/needed to do so, you could simply
> build without the GNOME-dependent parts and still have the library
> available.  But Boost gets used in the core stuff; so that one's a lot
> harder to get away from.
>
> --
> Braden McDaniel <br...@en...>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
>

-- 
Steve Traylen

On Fri, 2010-09-03 at 22:38 +0200, Steve Traylen wrote: 
> On Fri, Sep 3, 2010 at 10:29 PM, Braden McDaniel <br...@en...> wrote:

[snip]

> > It's my impression that RHEL6 isn't *that* far away; perhaps it would be
> > a better target for an EPEL effort?
> 
> Indeed, we will be running RHEL5 for another 3 or 4 years at least I
> expect, still
> have some RHEL3 in some places :-),:-(.

Ouch. :-/

> Will have a go with an older version, I realise GL/Graphics/ .. is a
> fast moving world.
> (For what it's worth FreeWRL, is just as hard to build.)

In OpenVRML's case, the Boost and GNOME dependencies are the most
rapidly moving ones.  If you wanted/needed to do so, you could simply
build without the GNOME-dependent parts and still have the library
available.  But Boost gets used in the core stuff; so that one's a lot
harder to get away from.

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

On Fri, Sep 3, 2010 at 10:29 PM, Braden McDaniel <br...@en...> wrote:
> On Fri, 2010-09-03 at 16:19 +0200, Steve Traylen wrote:
>> Hi Braden,
>>
>>  I've been looking at what it would take to add openvrml to EPEL. I am
>> interested to see openvrml availble from
>>  CentOS 5.
>>
>>  The only completely missing dependency for the  0.18.6-5 is gtkglext
>> which can be built into EPEL with a trivial patch
>> which I have.
>
> gtkglext is in Fedora; would it be that hard to get it into EPEL?
>
The patch I have is to the Fedora one, it's just a trivial .spec file change.
This can be done for sure and I'll do it if the subsequent items can
be resolved.

>> However after that it seems that glib amongst other items is to old
>> e.g a lack of gio in it.
>>
>>  Anyway, as per one of your mails in google I tried the 0.17 release
>> and in particular the Fedora 12 .src.rpm
>>
>>  But this has some problems with the available
>> boost-devel-1.33.1-10.el5 (I can supply errors)
>>
>> Have you tried , or are you aware of some successful builds on Centos+EPEL5.
>
> I haven't and I'm not.
>
> But I'd expect you to have to go farther back than Fedora 12 to find one
> that would work with.  Looking through some old specfiles, it looks to
> me like you'd have to go all the way back to Fedora 7 and OpenVRML
> 0.16.7 to find one that provides/requires Boost 1.33.1.

Yes RHEL 5 is for sure embarrassingly out of date in places these days.

> And FWIW, OpenVRML 0.16.x included its own copy of gtkglext; so at least
> you wouldn't have to worry about that dependency.
>
> It's my impression that RHEL6 isn't *that* far away; perhaps it would be
> a better target for an EPEL effort?

Indeed, we will be running RHEL5 for another 3 or 4 years at least I
expect, still
have some RHEL3 in some places :-),:-(.

Will have a go with an older version, I realise GL/Graphics/ .. is a
fast moving world.
(For what it's worth FreeWRL, is just as hard to build.)

  Steve

>
> --
> Braden McDaniel <br...@en...>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
>

-- 
Steve Traylen

On Fri, 2010-09-03 at 16:19 +0200, Steve Traylen wrote: 
> Hi Braden,
> 
>  I've been looking at what it would take to add openvrml to EPEL. I am
> interested to see openvrml availble from
>  CentOS 5.
> 
>  The only completely missing dependency for the  0.18.6-5 is gtkglext
> which can be built into EPEL with a trivial patch
> which I have.

gtkglext is in Fedora; would it be that hard to get it into EPEL?

> However after that it seems that glib amongst other items is to old
> e.g a lack of gio in it.
> 
>  Anyway, as per one of your mails in google I tried the 0.17 release
> and in particular the Fedora 12 .src.rpm
> 
>  But this has some problems with the available
> boost-devel-1.33.1-10.el5 (I can supply errors)
> 
> Have you tried , or are you aware of some successful builds on Centos+EPEL5.

I haven't and I'm not.

But I'd expect you to have to go farther back than Fedora 12 to find one
that would work with.  Looking through some old specfiles, it looks to
me like you'd have to go all the way back to Fedora 7 and OpenVRML
0.16.7 to find one that provides/requires Boost 1.33.1.

And FWIW, OpenVRML 0.16.x included its own copy of gtkglext; so at least
you wouldn't have to worry about that dependency.

It's my impression that RHEL6 isn't *that* far away; perhaps it would be
a better target for an EPEL effort?

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

Hi Braden,

 I've been looking at what it would take to add openvrml to EPEL. I am
interested to see openvrml availble from
 CentOS 5.

 The only completely missing dependency for the  0.18.6-5 is gtkglext
which can be built into EPEL with a trivial patch
which I have.

 However after that it seems that glib amongst other items is to old
e.g a lack of gio in it.

 Anyway, as per one of your mails in google I tried the 0.17 release
and in particular the Fedora 12 .src.rpm

 But this has some problems with the available
boost-devel-1.33.1-10.el5 (I can supply errors)

Have you tried , or are you aware of some successful builds on Centos+EPEL5.

    Steve.

-- 
Steve Traylen

On Thu, 2010-09-02 at 09:18 -0400, Jean-Nicolas Ouellet wrote: 
> Hi,
> 
> I am developing an application where I display a wrl model from a custom
> viewpoint in opengl, similar to what is done in artoolkit. I built the
> latest version of openvrml (0.18.99 for now) along with the dependency and
> successfully integrated it in my application. I use a custom viewer
> (myViewer: openvrml::gl::viewer ) and I can display one model without
> problems. The model is loaded from the browser load_url as in the sample
> sdl_viewer. I use the render function to display the vrml model.
> 
> Now I want to display more models pre-loaded from different wrl files
> dependeing on the user interaction with the application. Is there a simple
> and efficient method to accomplish this. Digging in openvrml source, I found
> the viewer::replace_world which seems to do this but I don't understand the
> documentation. An example of how to do this would be very usefull. Can
> someone explain how this can be done?

You need a vector of nodes.  I think the only direct way of getting such
a thing from libopenvrml is to use browser::create_vrml_from_stream.
But you could also implement your own parsing function that would
produce such output.  (See, for instance, the internal function
openvrml::local::parse_vrml.)

browser::replace_world is designed to support dynamic behavior within a
world.  You might be able to get it to work for the particular models
you're using (especially if they don't use PROTOs); but note that it
does *not* tear down supporting structures like the
node_metatype_registry_.

If you really want to load multiple files concurrently and swap them
out, you should probably have a browser instance for each one.

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

On Thu, 2010-09-02 at 20:41 +0200, Hug...@we... wrote: 
> Hello all,
> I want to try your openvrml. But already at the first step I have a problem.
> The file INSTALL file tells me I should run ./configure.
> but there are two files with suffix opt or dbg - no configure:

You're using the Subversion source.  See README.build_from_svn.

> openvrml> ls -l con*
> -rw-r--r-- 1 fgfs users 16792  2. Sep 19:12 configure.ac
> -rwxr-xr-x 1 fgfs users   436  2. Sep 19:12 configure-gcc-dbg
> -rwxr-xr-x 1 fgfs users   404  2. Sep 19:12 configure-gcc-opt
> 
> What is the difference?

README.build_from_svn answers this, too.

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

Hello all,
I want to try your openvrml. But already at the first step I have a problem.
The file INSTALL file tells me I should run ./configure.
but there are two files with suffix opt or dbg - no configure:

openvrml> ls -l con*
-rw-r--r-- 1 fgfs users 16792  2. Sep 19:12 configure.ac
-rwxr-xr-x 1 fgfs users   436  2. Sep 19:12 configure-gcc-dbg
-rwxr-xr-x 1 fgfs users   404  2. Sep 19:12 configure-gcc-opt

What is the difference?

If I run the dbg version I get:

openvrml> ./configure-gcc-dbg
./configure-gcc-dbg: Zeile 3: ./configure: Datei oder Verzeichnis nicht gefunden

Obviously it wants to run ./configure.  But that is not existing.
What should I do?

Thanks in advance
    Hugo

Hi,

I am developing an application where I display a wrl model from a custom
viewpoint in opengl, similar to what is done in artoolkit. I built the
latest version of openvrml (0.18.99 for now) along with the dependency and
successfully integrated it in my application. I use a custom viewer
(myViewer: openvrml::gl::viewer ) and I can display one model without
problems. The model is loaded from the browser load_url as in the sample
sdl_viewer. I use the render function to display the vrml model.

Now I want to display more models pre-loaded from different wrl files
dependeing on the user interaction with the application. Is there a simple
and efficient method to accomplish this. Digging in openvrml source, I found
the viewer::replace_world which seems to do this but I don't understand the
documentation. An example of how to do this would be very usefull. Can
someone explain how this can be done?

Regards,
JNO

For anyone interested...

I've added Visual C++ 2010 project files to the trunk and the 0.18
branch.  The project files for the previous version are no more.

The project files are no longer buried in the ide-projects subdirectory;
OpenVRML.sln is in the package root directory and the various project
files live in the same directories as their associated source files.

If you have an interest in this working in the next OpenVRML release,
please test it.

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

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

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...>

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...>

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...>

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

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

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...>

>> -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

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...>

>>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

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...>

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

openvrml-develop Mailing List for OpenVRML (Page 5)

openvrml-develop — OpenVRML developers mailing list