Menu
▾
▴
freewrl-develop
|
From: Ian S. A. <ia...@ae...> - 2013-04-16 13:44:01
|
Hey all, so spidermonkey-17 is released, which is going to be the last spidermonkey that has a C API; after this it's C++ only. Should we port freewrl to C++ or freeze our compatibility to spidermonkey-1.5 through 17 ? |
|
From: doug s. <hig...@ho...> - 2013-04-16 15:11:54
|
> > Hey all, so spidermonkey-17 is released, which is going to be the last > spidermonkey that has a C API; after this it's C++ only. > > Should we port freewrl to C++ or freeze our compatibility to > spidermonkey-1.5 through 17 ? > What do you think Ian? Would you like to keep upgrading or would you prefer a freeze? -Doug The last time the freewrl C vs C++ issue came up, C won. I had done a test where I got freewrl to compile as C++. But then it was just C code that took longer to compile on my slow old machine, and had some awkward areas that would need a rewrite. We do have some C++ at-the-margin: libs and plugins. I think there are ways to wrap a C++ library with a C interface, if necessary. But that could be more work for the main javascript maintainer - that's been you Ian - with unknown gain in functionality. My guess: freeze. |
|
From: Ian S. A. <ia...@ae...> - 2013-04-16 16:16:14
|
On 16/04/13 11:11 AM, doug sanden wrote: > >> >> Hey all, so spidermonkey-17 is released, which is going to be the last >> spidermonkey that has a C API; after this it's C++ only. >> >> Should we port freewrl to C++ or freeze our compatibility to >> spidermonkey-1.5 through 17 ? >> > > What do you think Ian? Would you like to keep upgrading or would you > prefer a freeze? > -Doug > The last time the freewrl C vs C++ issue came up, C won. > I had done a test where I got freewrl to compile as C++. But then it was > just C code that took longer to compile on my slow old machine, and had > some awkward areas that would need a rewrite. We do have some C++ > at-the-margin: libs and plugins. > I think there are ways to wrap a C++ library with a C interface, if > necessary. But that could be more work for the main javascript > maintainer - that's been you Ian - with unknown gain in functionality. > My guess: freeze. > Freeze is easier, since we don't have to port. However, not keeping up means we end up relying on dead code--or worse, embedding dead code--which in general isn't very nice to do. It's going to be a -long time- before the next spidermonkey is released (next release is v24, which will be 2014 I think they said), but I thought it'd be worthwhile to bring it up. Also, migration to C++ may have other benefits -- for instance, it might open us up to more contributors or more users of the API. Going through the whole codebase and converting our objects/structs/etc to classes would probably allow us to simplify the code quite a bit too, at least in theory.... I think if we were to do this change, this would put us into FreeWRL-3. |
|
From: doug s. <hig...@ho...> - 2013-04-16 16:50:13
|
> >> > >> Hey all, so spidermonkey-17 is released, which is going to be the last > >> spidermonkey that has a C API; after this it's C++ only. > >> > >> Should we port freewrl to C++ or freeze our compatibility to > >> spidermonkey-1.5 through 17 ? > >> > > > > What do you think Ian? Would you like to keep upgrading or would you > > prefer a freeze? > > -Doug > > The last time the freewrl C vs C++ issue came up, C won. > > I had done a test where I got freewrl to compile as C++. But then it was > > just C code that took longer to compile on my slow old machine, and had > > some awkward areas that would need a rewrite. We do have some C++ > > at-the-margin: libs and plugins. > > I think there are ways to wrap a C++ library with a C interface, if > > necessary. But that could be more work for the main javascript > > maintainer - that's been you Ian - with unknown gain in functionality. > > My guess: freeze. > > > > Freeze is easier, since we don't have to port. However, not keeping up > means we end up relying on dead code--or worse, embedding dead > code--which in general isn't very nice to do. > > It's going to be a -long time- before the next spidermonkey is released > (next release is v24, which will be 2014 I think they said), but I > thought it'd be worthwhile to bring it up. > > Also, migration to C++ may have other benefits -- for instance, it might > open us up to more contributors or more users of the API. Going through > the whole codebase and converting our objects/structs/etc to classes > would probably allow us to simplify the code quite a bit too, at least > in theory.... the gglobal() thing comes to mind. It's 1:1 with 'browser' as seen by SAI, so instead of looking it up by thead it could be passed back to the SAI client in the opaque browser pointer, and passed back in on SAI calls. . web3d.org specs show abstract base classes to nodes. It might help programmers if we were following it more closely. > > I think if we were to do this change, this would put us into FreeWRL-3. > Might need a fork until it was stable and proven? If it broke too many things it might lose developers -all their hard work destroyed, demoralizing us. So it might depend how well it was refactored. If you've ever read books on agile programming or eXtreme programming they talk about unit tests being run after each refactoring step, so they can roll back if they break something. We don't have an automated test suite. So perhaps that could/should be a first step. But even then, Q1. how to set up unit testing to test all the platforms including smartphones and tablets, and 64bit, from any one single platform, in a fast, convenient feedback way? Q2. And how to do unit testing on computer graphics, with input devices and rendered output, and multiple frames and events involved? |
|
From: Ian S. A. <ia...@ae...> - 2013-04-16 17:08:13
|
On 16/04/13 12:50 PM, doug sanden wrote: > > the gglobal() thing comes to mind. It's 1:1 with 'browser' as seen by > SAI, so instead of looking it up by thead it could be passed back to the > SAI client in the opaque browser pointer, and passed back in on SAI calls. > . > web3d.org specs show abstract base classes to nodes. It might help > programmers if we were following it more closely. Interesting idea... >> >> I think if we were to do this change, this would put us into FreeWRL-3. >> > Might need a fork until it was stable and proven? If it broke too many > things it might lose developers -all their hard work destroyed, > demoralizing us. So it might depend how well it was refactored. If > you've ever read books on agile programming or eXtreme programming they > talk about unit tests being run after each refactoring step, so they can > roll back if they break something. Yes, we would definitely want to fork. same idea as what we did when we split the freewrl codebase into freex3d, for the autotools build system and code refactoring. > > We don't have an automated test suite. So perhaps that could/should be a > first step. > > But even then, > Q1. how to set up unit testing to test all the platforms including > smartphones and tablets, and 64bit, from any one single platform, in a > fast, convenient feedback way? I don't think it's possible, in the same way that I don't think it's possible to use one common build system. > Q2. And how to do unit testing on computer graphics, with input devices > and rendered output, and multiple frames and events involved? also don't think it's possible, at least in an automated way. We can test on a benchmarking system what the differences are for output of the test .wrl files, but that's the closest we can do I think. |
|
From: doug s. <hig...@ho...> - 2013-04-18 13:09:48
|
> > > > We don't have an automated test suite. So perhaps that could/should be a > > first step. > > > > But even then, > > Q1. how to set up unit testing to test all the platforms including > > smartphones and tablets, and 64bit, from any one single platform, in a > > fast, convenient feedback way? > > I don't think it's possible, in the same way that I don't think it's > possible to use one common build system. > > > > Q2. And how to do unit testing on computer graphics, with input devices > > and rendered output, and multiple frames and events involved? > > also don't think it's possible, at least in an automated way. We can > test on a benchmarking system what the differences are for output of the > test .wrl files, but that's the closest we can do I think. > Unit Testing - might be a faint hope of doing something, although I don't ambitious enough myself to implement it. For comparison test fixtures: - there are a few dump-scene functions in freewrl - and a snapshot function. The snapshots might render a bit different on each platform / computer? If so then you would generate the trusted snapshot fixtures on each testing platform before beginning refactoring. So one idea is to have a special unit test interface -to augment normal SAI/EAI and scene loading- that would include some things like: 0. specify number of mainloop loops to advance 1. send in a keyboard input char - to trigger dumpscene or snapshot (or direct functions) 2. send in mouse / input device sequence 3. file compare to test fixture 4. some way to capture mouse sequences, keyboard input, number of frames for replay, when generating test fixtures 'Refactoring' means you are changing the structure of the code but not the functionality. If you see bugs or opportunities for functional improvements while refactoring, you'd make a note and do them later, or regenerate test fixtures. |
|
From: Ian S. A. <ia...@ae...> - 2013-04-18 13:29:23
|
On 18/04/13 09:09 AM, doug sanden wrote: >> > >> > We don't have an automated test suite. So perhaps that could/should be a >> > first step. >> > >> > But even then, >> > Q1. how to set up unit testing to test all the platforms including >> > smartphones and tablets, and 64bit, from any one single platform, in a >> > fast, convenient feedback way? >> >> I don't think it's possible, in the same way that I don't think it's >> possible to use one common build system. >> >> >> > Q2. And how to do unit testing on computer graphics, with input devices >> > and rendered output, and multiple frames and events involved? >> >> also don't think it's possible, at least in an automated way. We can >> test on a benchmarking system what the differences are for output of the >> test .wrl files, but that's the closest we can do I think. >> > > Unit Testing - might be a faint hope of doing something, although I > don't ambitious enough myself to implement it. > > For comparison test fixtures: > - there are a few dump-scene functions in freewrl > - and a snapshot function. > The snapshots might render a bit different on each platform / computer? > If so then you would generate the trusted snapshot fixtures on each > testing platform before beginning refactoring. > > So one idea is to have a special unit test interface -to augment normal > SAI/EAI and scene loading- that would include some things like: > 0. specify number of mainloop loops to advance > 1. send in a keyboard input char - to trigger dumpscene or snapshot (or > direct functions) > 2. send in mouse / input device sequence > 3. file compare to test fixture > 4. some way to capture mouse sequences, keyboard input, number of > frames for replay, when generating test fixtures > Michel was doing similar things, iirc -- one of the driving reasons for being able to provide a string of characters to freewrl via the command line, back in the day: scripted .wrl/x3d loading, manipulation, and snapshotting , so that different freewrl instances can be directly compared. I don't know if he had an automated image comparison or not; that would be the next step. The issue is, as you said, the images from one machine to the next won't be the same so we'd need to generate the trusted/reference snapshots first and then test using the same machine (probably including machine configuration, ie mesa version etc). |
|
From: Ian S. A. <ia...@ae...> - 2013-04-19 13:09:19
|
On 16/04/13 12:50 PM, doug sanden wrote: > >> >> >> >> Hey all, so spidermonkey-17 is released, which is going to be the last >> >> spidermonkey that has a C API; after this it's C++ only. >> >> >> >> Should we port freewrl to C++ or freeze our compatibility to >> >> spidermonkey-1.5 through 17 ? >> >> >> > >> > What do you think Ian? Would you like to keep upgrading or would you >> > prefer a freeze? >> > -Doug >> > The last time the freewrl C vs C++ issue came up, C won. >> > I had done a test where I got freewrl to compile as C++. But then it was >> > just C code that took longer to compile on my slow old machine, and had >> > some awkward areas that would need a rewrite. We do have some C++ >> > at-the-margin: libs and plugins. >> > I think there are ways to wrap a C++ library with a C interface, if >> > necessary. But that could be more work for the main javascript >> > maintainer - that's been you Ian - with unknown gain in functionality. >> > My guess: freeze. >> > So something else that has just recently come to my attention -- spidermonkey (mozjs) will no longer work in a multithreaded environment if it's the same "container" across multiple threads. This definitely applies to us -- when the new container functionality was introduced in 1.8.5, I did my best to be sure that we still only worked within a single container, so that we weren't having to deal with multiple root objects and all objects stayed in the same "scope". Our runtime *might* work fine as I believe your threads already handle locking to take care of concurrent access of other shared memory, but i can't say for sure. Now, it could be that my (lack of) understanding of containers means this isn't necessary; i'll look into it in the near future and see if I can figure it out. Anyways, the point being, we may need to freeze at the current version of spidermonkey (1.8.5 official, or 1.8.7 unofficial) without that major refactoring of our codebase. |
|
From: Paulo E. C. <pau...@gm...> - 2013-04-21 11:57:43
|
tl;dr - Rant ahead, sarcastic comments, positive suggestions ...
I've been a subscriber to the mailing list since 2011 though I've trying
to play with freewrl for longer...
And every so often I peek into the folder where the emails end up...
This time it was the codebase port to c++ email that caught my eye... I
read the thread and decided to look at the code.
I cd into the project dir where I have my gitted CVS version and I pull
all the changes from trunk integrating them in my git repository version
of freewrl.
Whilst I blink my eyes I create a test branch and based on my own
personal branch and I rebase trunk/master onto it.
What I get is,the latest trunk with my commits on top of it just as if I
had written them just now.
My commits are just notes, my build scripts, and some examples I've
collected here and there...
Every so often I try to go for a build...
Most of the times a straight build from trunk fails...
But this time I was feeling more energetic and decided to investigate
matters.
I soon found issues with the build ....
And then I remember what I've noticed some time ago, that, though I know
what it does, the code seems rather convoluted and complex to fully
understand.
Then I wish that there could be some guiding doc just explaining the
contents of each dir and briefly detailing how all the pieces fit together.
Something condensed in a single place rather then being scattered in the
code and in the website ...
I also wish there were some tests so that I could at least understand
what is the behaviour and response that you are hoping for the given
parts of the whole beast.
Anyway, I put all those thoughts momentarily aside and decided to take
the code for a build spin ...
Make blows up straight away after configure and friends had run.
I dig in the code, and I remember what I had forgotten, because every
time I look at it it's as if it is the first time ...
Gigantic files, stale code, hardcore C, gigantic functions with no
comments sprinkled with preprocessing directives and commented code to
keep all your brain registers in supercharge.
A couple of greps and some opened files later and I got it....
0001-Make-it-build-0.patch
I try again and boom...
0002-Make-it-build-1.patch
I try going for it again .... Cross fingers harder !!! Boom
0003-make-it-build-2.patch
Last try.... and Finally.... Success!
And after a couple of builds to make sure I had it right, it was only
taking me 2m10s to build the whole thing.
Thank the gods for ccache.
Those patches are just blunt fixes in order to get the thing to build.
I'm not sure how good or ideal they are...
Wrapping thoughts...
It seems like you're using your trunk as a staging area for experiments
whilst sharing code/ideas amongst yourselves or similar.
That's ok and it could be seen as the purpose of a sharing code system
but not the role of a Version Control System.
Your trunk should ideally always be in a buildable condition.
For code sharing and development and testing there's branches.
I would like to help a bit more if it was easier for me to help.
And that's exactly the purpose of this rant to try to bring some
external perspective of how I perceive things to be.
This means that If I see them like this, chances are many more
people/newbies will see them as well.
And for someone who's looking at the code for the first time, I suppose
it can be demoralizing if every time you try to have a go at it it fails.
And you try to find some understanding to how it all fits together and
there's none or it is so scattered that it is easy to loose track of it.
</rant over>
Sometimes you need a step back in order to be able to take two forward...
I decided to write a wishlist of things I think would help me help you
next time I have a look at the project...
<WishList>
- Documentation briefly ( optionally as comprehensive has possible )
describing the contents of each directory.
- How do they work together
- Perhaps enable the sourceforge wiki and condense information there ?
- A strategy to start documenting what each function is supposed to do.
- Start with the more meaty ones
- Consider the Doxygen format perhaps ?
- If you're amending a function/method and you're familiar with what
it does, consider adding some notes at the beginning disclaiming in/out
and expected behaviour
- Some contextual explanation of the purpose of the codegen/ folder and
how to run it.
- Why it exists
- What it generates and why
- How it runs... it seems you're suppose to pipe something into perl
-MVRMLC ? Is that written somewhere ?
- How do you validate that it's producing the right thing ?
- I gather that VRMLC is generating some c,h files but my bet is,
from looking at it, that maintaining it and extending it is super hard.
- If one understands the exact role of these files, higher are the
chances of being able to refactor them into more easily extendible code.
- How could one test the result of this codegen process ?
- How do you test the resulting build ?
- Assuming you couldn't run freewrl after a build, what would be
important to validate as correct behaviour, expected Input/Output ?
- What is really important in terms of what you are implementing ?
- Consider moving to at least SVN preferably Git|Mercurial
- CVS is old, cumbersome and hard to enable collaboration of multiple
people, basically everything is hard with CVS...
- Consider some cleaning
- VRMLC.pm has 500 lines of revision logs in it. That's why VCS
exist. These need not be in the file.
- Consider doing the same for all the other files in the same situation.
- Remove unnecessary trailing whitespace in lines. Standardizing this
helps with future merges and overall diff comprehension and readability
- Editors can be configured to have this removed automagically
- Remove old commented legacy code. Make a note for it on the commit.
- Have a debug flag or preprocessing to enable the output of all
those commented printfs that are really important to see when things get
hairy.
- Coding
- Some coding guidelines ?
- 4 space indentation ? Other ?
- New code has to have some brief documentation ?
- Roadmap
- Where is the project heading
- How much of the X3d/VRML7 spec is the project interested in
covering/implementing
- etc ...
</WishList>
I have extensive experience integrating different components and writing
Modern Perl code.
My C/C++ skills are a bit rusty but I can get along fine.
I don't have much time in my hands but every so often I do enjoy a
detour into playing with something like FreeWRL.
If every such time I could make a positive contribution albeit small I
supposed that everyone would win ...
Hoping this is seen as positive feedback...
PECastro
|
|
From: doug s. <hig...@ho...> - 2013-04-21 17:29:50
|
Paulo, > Your trunk should ideally always be in a buildable condition. The win32 version builds from .sln /.vcproj build files. I'll reserve comment on the linux build except to say recent activities on the win32 build could have broken something. On win32 I just build what's in freewrl/freex3d/src /lib and /bin and /libeai. > I would like to help a bit more if it was easier for me to help. Yes and we are mostly volunteers now: - so addressing your concerns will help us all - we are constrained to what volunteers are interested in and willing to do As a volunteer I do what I feel like doing, when I feel like doing it. Usually I don't have many hours or days in a row, so I prefer to set bite-sized goals and tasks, or break big ones into bite size. I'm often driven by curiosity or have a fuzzy idea and want to see if I can pull it off as a learning challenge. > And you try to find some understanding to how it all fits together and > there's none or it is so scattered that it is easy to loose track of it. It follows www.web3d.org specs, and in general vrml browsers work like game engines: parse input files fetch image resources Loop: - get input from mouse, keyboard - get time delta since last frame - run scripts based on input and time - update geometry based on scripts, time and input - render geometry to frame end loop > - Documentation briefly ( optionally as comprehensive has possible ) > describing the contents of each directory. I'm not familiar with all the directories myself. And some directories no longer adhere to their original intent - they are what I'd call fuzzy categories, not precise. To get precise I build and run and trace the code. If we do a big refactoring, we can perhaps refactor into better category directories in the process. Here's the ones I know: freewrl/freex3d/codegen - perl files to generate GeneratedCode.c and Structs.h node and field plumbing - only run perl after an infrequent change to the node or field structs, check in the GeneratedCode.c and Structs.h. freewrl/freex3d/projectfiles_vc9 and _vc10 - win32 MSVC .proj and .sln build files freewrl/freex3d/src - cross platform source code files for: /libeai - in web3d.org specs there's something called External Authoring Interface EAI that allows scripting via port communications /java - for SAI or Scene Authoring Interface writtin in java /bin - main.c console app - calls lib /libtess - used to tesselate (triangulate into mesh) truetype font polygon outlines, called by /lib /lib - libfreewrl library called by main.c and other gui apps depending on platform within /lib - the directories are fuzzy categories, not strict, and I have only fuzzy ideas about what the cateogry was originally meant for - so check the code to see specifically. Q. If you had to decide between better documentation or better code and directory structure which would you choose? The 'agile' / eXtreme programming school of thought skips the documentation and goes for good structure. A problem with detailed documentation: it can get stale, and keeping it up slows down structural refactoring. And assume for a moment know one knows exactly what a function is supposed to be doing. Then no one can properly document it. That's pretty close to where we are with freewrl. On the other hand, before being able to wisely refactor code, you would need to have some fuzzy idea what it is supposed to do, perhaps through guessing or debugging sessions, and looking where and how it is used, at least enough to form an hypothesis about what it's doing. I'm used to this. The Agile school sets up lots of tests -automated, so they can run them quickly between changes- and if they break tests when refactoring, they roll back. When I do testing there are 50 or so .wrl/.x3d test files I run. http://dug9.users.sourceforge.net/web3d/tests/screenlinks.html Plus depending on what I'm tinkering with, I'll set up special .wrl/.x3d test files, and I've accumulated some samples people have sent in. I think there are different names for different levels of tests. A Unit test is supposed to be for a small bite size module, class or even a function, I think. Functional tests are more from the outside looking in, as a user would see it. I think the 50 wrl tests would be called functional tests. A problem with unit tests: if you're going to refactor your modules and functions, then the unit tests would need to change a lot in the process to keep up. But functional tests as seen from the outside should be stable. So if I was setting up automated tests before major refactoring I'd want functional tests, especially for freewrl which is mostly working well and free of bugs, as seen from the outside, but is "hell's kitchen" on the inside. Or perhaps unit tests could be generated from perl. Having said that, some contextual and overview documentation would likely be stable and helpful to everyone. After a major refactoring, the code might be stable enough to make more refined granularity of documentation useable. > - Some contextual explanation of the purpose of the codegen/ folder and > how to run it. > - Why it exists > - What it generates and why > - How it runs... it seems you're suppose to pipe something into perl > -MVRMLC ? Is that written somewhere ? VRML has 2 main entity types: nodes and fields. There's a lot of repetitive plumbing for each of those types, and for each specific node and field type. When changing the system occassionally -very infrequently- if a generic field struct or node struct needs to be changed, instead of changing it repetitvely in hundreds of node or field structs, it's changed on one line in a codegen/ perl file, and the perl is re-run to generate all the repetitive plumbing code. To re-run the perl, in windows I put it in a .bat file in /codegen, install perl somwhere, then run the .bat, which looks like this: E:/Perl/bin/perl.exe VRMLC.pm pause That's it. It does it's own running of the other perl .pm files. It outputs freex3d/lib/scenegraph/generatedCode.c and freex3d/lib/vrml/structs.h and freex3d/libeai/GeneratedCode.c and GeneratedHeaders.c So these output files should never be editied directly (although I have for a throw-away proof-of-concept test before editing the perl) > - How do you validate that it's producing the right thing ? > - How could one test the result of this codegen process ? first, change them very carefully so you never break them. second, try building and running freewrl on functional tests. If you break something, rollback your changes. Third use a diff tool to see if your changes make sense in each file. > - Consider moving to at least SVN preferably Git|Mercurial > - CVS is old, cumbersome and hard to enable collaboration of multiple > people, basically everything is hard with CVS... Agreed. Next time we change repositories. Q. which is easier for newbies to learn? SVN or Git? I've never used git but it seems more complicated, with local and branches and main repositories. Which do you recommend for us? Why do you use Git? Is there a Git client for all desktop platforms: osx,linux,win32? Are all git tools compatible? Does sourceforge support Git, or is Git a commercial effort in competition with sourceforge - would we be forced to move? >- Roadmap > - Where is the project heading > - How much of the X3d/VRML7 spec is the project interested in > covering/implementing There is no written or dictated roadmap, other than what volunteers/contributors want to do with it. Usually there is concensus to making it a better performing and conforming web3d.org browser and library component, or perhaps going beyond specifications to something even better, depending on the imagination and initiative of the individual volunteer contributor. For example I ported freewrl to win32. Freewrl had shutterglasses type stereovision when I joined. I added side-by-side and anaglyph stereovision. I made a menu in opengl, so no platform specific GUI technology is needed, and that works on win32 and I got a varient of it working in a BB/QNX version. In win32 I made a separate launcher program, that sets up command line parameters, picks internet explorer plugin by mime type, tests a URL, and does a GoogleEarth snapshot including generating x3d file. My own current roadmap: I'm re-working parsing so it works better for nested protos. Others are working on javascript upgrades, shader program rendering and native SAI. It sounds like you are a code-structure kind of guru, so some of your wishlist and complaints could be rolled into self-initiated projects on that theme. > I have extensive experience integrating different components and writing > Modern Perl code. A funny story I heard: freewrl was originally developed in perl. It ran too slow, and was converted to C. But somewhere in all of its organization and structs are the seeds of its history. > My C/C++ skills are a bit rusty but I can get along fine. > I don't have much time in my hands but every so often I do enjoy a > detour into playing with something like FreeWRL. > If every such time I could make a positive contribution albeit small I > supposed that everyone would win ... > Hoping this is seen as positive feedback... I agree -code hard to read and understand, hard to dip into it casually, and makes me feel ill in many places- so no personal offence taken. -Doug |
|
From: Paulo E. C. <pau...@gm...> - 2013-04-22 13:48:46
|
> The win32 version builds from .sln /.vcproj build files. > I'll reserve comment on the linux build except to say recent > activities on the win32 build could have broken something. On win32 I > just build what's in freewrl/freex3d/src /lib and /bin and /libeai. Patch named "make it build 2" is related with a Win32 change that broke the Linux build. I use Linux, Fedora to be precise. > > > And you try to find some understanding to how it all fits together and > > there's none or it is so scattered that it is easy to loose track of it. > > It follows www.web3d.org <http://www.web3d.org> specs, and in general > vrml browsers work like game engines: > parse input files > fetch image resources > Loop: > - get input from mouse, keyboard > - get time delta since last frame > - run scripts based on input and time > - update geometry based on scripts, time and input > - render geometry to frame > end loop > > > - Documentation briefly ( optionally as comprehensive has possible ) > > describing the contents of each directory. > I'm not familiar with all the directories myself. > And some directories no longer adhere to their original intent - they > are what I'd call fuzzy categories, not precise. To get precise I > build and run and trace the code. > If we do a big refactoring, we can perhaps refactor into better > category directories in the process. > > Here's the ones I know: > freewrl/freex3d/codegen - perl files to generate GeneratedCode.c and > Structs.h node and field plumbing - only run perl after an infrequent > change to the node or field structs, check in the GeneratedCode.c and > Structs.h. > freewrl/freex3d/projectfiles_vc9 and _vc10 - win32 MSVC .proj and .sln > build files > freewrl/freex3d/src - cross platform source code files for: > /libeai - in web3d.org specs there's something called External > Authoring Interface EAI that allows scripting via port communications > /java - for SAI or Scene Authoring Interface writtin in java > /bin - main.c console app - calls lib > /libtess - used to tesselate (triangulate into mesh) truetype font > polygon outlines, called by /lib > /lib - libfreewrl library called by main.c and other gui apps > depending on platform > > > within /lib - the directories are fuzzy categories, not strict, and I > have only fuzzy ideas about what the cateogry was originally meant for > - so check the code to see specifically. Thanks for these. I'm collating all of these in a file to submit as a patch for documentation > > Q. If you had to decide between better documentation or better code > and directory structure which would you choose? I would chose both. They're not mutually exclusive. The point is to have things leaner so that code doesn't rot so fast ... > > The 'agile' / eXtreme programming school of thought skips the > documentation and goes for good structure. A problem with detailed > documentation: it can get stale, and keeping it up slows down > structural refactoring. And assume for a moment know one knows exactly > what a function is supposed to be doing. Then no one can properly > document it. That's pretty close to where we are with freewrl. I'm not suggesting one documents every line of code. But simple, short description of what a function is supposed to do, of it's purpose, is helpful. That documentation only rots when that function is no longer necessary in which case one should remove it from the code. > > On the other hand, before being able to wisely refactor code, you > would need to have some fuzzy idea what it is supposed to do, perhaps > through guessing or debugging sessions, and looking where and how it > is used, at least enough to form an hypothesis about what it's doing. > I'm used to this. Debugging takes a long time, and if one is only collecting that information and intuition in one's brain then that information will easily be forgotten and not shared with the project. > > The Agile school sets up lots of tests -automated, so they can run > them quickly between changes- and if they break tests when > refactoring, they roll back. When I do testing there are 50 or so > .wrl/.x3d test files I run. > http://dug9.users.sourceforge.net/web3d/tests/screenlinks.html > Plus depending on what I'm tinkering with, I'll set up special > .wrl/.x3d test files, and I've accumulated some samples people have > sent in. Can you describe your testing process a bit better ? Do you mean you manually open the files and play with them to assert the validity of the code ? Is there a specific set of validation rules you use/follow ? > I think there are different names for different levels of tests. A > Unit test is supposed to be for a small bite size module, class or > even a function, I think. Functional tests are more from the outside > looking in, as a user would see it. I think the 50 wrl tests would be > called functional tests. > A problem with unit tests: if you're going to refactor your modules > and functions, then the unit tests would need to change a lot in the > process to keep up. But functional tests as seen from the outside > should be stable. So if I was setting up automated tests before major > refactoring I'd want functional tests, especially for freewrl which is > mostly working well and free of bugs, as seen from the outside, but is > "hell's kitchen" on the inside. Or perhaps unit tests could be > generated from perl. The kind of testing I was talking about is more akin to Unit tests. But these need not be written for every single module, class or function. You can write tests at different stages of your development, a) writing a new function, b) amending an existing function c) preparing for some refactoring work d) because there are none e) because you're bored and you feel like it Unit tests can be as simple as throwing some data into a function and validate that the output conforms with whatever one should expect. This means that yes, your tests need to be tendered to but not to the extent you're talking about. If I refactor a given function to be slightly faster, or to do things differently, or use a different API, etc , All I need to validate is that in the end of my work the function is still giving me the same expected reply to a given input. If it's not, then either this rewrite is bad, or most likely this function is a totally different new thing that should have a new name, perhaps be located in some other place, and have a test of it's own. In a nutshell, I don't need to also rewrite my tests for this function. I should be able to extend them though. If I'm considerably rewriting my test for a given function that's usually a code smell indication that something is wrong. > > Having said that, some contextual and overview documentation would > likely be stable and helpful to everyone. After a major refactoring, > the code might be stable enough to make more refined granularity of > documentation useable. Documentation in my experience is usually best done as you go along... So every time you're amending some code you could check if that function is well described within your understanding of it. Please have a look here for an example http://finsframework.org/mediawiki/index.php/Short_Tutorial_on_Doxygen In the end of the document there's a link to some generated documentation. One only needs to agree a format and then add the config file to the project and include some building commads in make. After that it's only a matter of adding up to the pile... > > > - Some contextual explanation of the purpose of the codegen/ folder and > > how to run it. > > - Why it exists > > - What it generates and why > > - How it runs... it seems you're suppose to pipe something into perl > > -MVRMLC ? Is that written somewhere ? > VRML has 2 main entity types: nodes and fields. There's a lot of > repetitive plumbing for each of those types, and for each specific > node and field type. When changing the system occassionally -very > infrequently- if a generic field struct or node struct needs to be > changed, instead of changing it repetitvely in hundreds of node or > field structs, it's changed on one line in a codegen/ perl file, and > the perl is re-run to generate all the repetitive plumbing code. > To re-run the perl, in windows I put it in a .bat file in /codegen, > install perl somwhere, then run the .bat, which looks like this: > E:/Perl/bin/perl.exe VRMLC.pm > pause > That's it. It does it's own running of the other perl .pm files. > It outputs > freex3d/lib/scenegraph/generatedCode.c and > freex3d/lib/vrml/structs.h and > freex3d/libeai/GeneratedCode.c and GeneratedHeaders.c > So these output files should never be editied directly (although I > have for a throw-away proof-of-concept test before editing the perl) I'm also adding these for a documentation patch. > > > - Consider moving to at least SVN preferably Git|Mercurial > > - CVS is old, cumbersome and hard to enable collaboration of multiple > > people, basically everything is hard with CVS... > Agreed. Next time we change repositories. > Q. which is easier for newbies to learn? SVN or Git? I've never used > git but it seems more complicated, with local and branches and main > repositories. Which do you recommend for us? Why do you use Git? Is > there a Git client for all desktop platforms: osx,linux,win32? Are all > git tools compatible? Does sourceforge support Git, or is Git a > commercial effort in competition with sourceforge - would we be forced > to move? Git is all the rage these days and so is every other distributed VCS. Git only seems complicated because it's light years away from CVS and SVN given the immense power that it unleashes onto peoples hands. In fact it's not complicated at all. I use git because it's model fosters distributed development, due to its internal architecture, merge conflicts are less frequent than with CVS,SVN, also all the pain that used to come with using those tools is not there with git. Git is open source, and there are tools for all the common OSes. SourceForge supports git and there's even already a git placeholder for FreeWRL here http://freewrl.git.sourceforge.net/git/gitweb.cgi?p=freewrl/freewrl;a=summary The repo only needs to be converted and imported. I can help with that. Someone did a CVS export and git import some years ago, you can check it here for clues on how the repo, commits etc will look like -> https://github.com/cbuehler/freewrl Some reading suggestions: http://git-scm.com/book/en/Getting-Started-Git-Basics <- Very good reference https://www.kernel.org/pub/software/scm/git/docs/v1.4.4.4/tutorial.html http://byte.kde.org/~zrusin/git/git-cheat-sheet-medium.png > > It sounds like you are a code-structure kind of guru, so some of your > wishlist and complaints could be rolled into self-initiated projects > on that theme. Not at all, just learning as we go along .... Perhaps in my original post I might have come across with some bluntness... I suppose my point was one of, even though people might be pushing, heading, implementing in different direction as you say, agreeing on some consistency across the board could be a necessary good thing. > > A funny story I heard: freewrl was originally developed in perl. > It ran too slow, and was converted to C. > But somewhere in all of its organization and structs are the seeds of > its history. Yes, the first commit from rcoscali in 2000 was all about some documentation and Perl files. |
|
From: doug s. <hig...@ho...> - 2013-04-22 14:18:49
|
Paulo, > > ... When I do testing there are 50 or so .wrl/.x3d test > > files I run. > > http://dug9.users.sourceforge.net/web3d/tests/screenlinks.html > > Plus depending on what I'm tinkering with, I'll set up special > > .wrl/.x3d test files, and I've accumulated some samples people have > > sent in. > > > Can you describe your testing process a bit better ? Do you mean you > manually open the files and play with them to assert the validity of > the code ? Manually open the file, manually click/drag the mouse, visually look at the scene and compare with my memory of what the scene looked like before fhe change. One developer Michel attempted more automated testing via commandline string containing mouse input (haven't tried it, not sure if it still works or how advanced it was, would have been at least a few years ago). Recently we were wondering if it's possible/how to do more automated testing with graphical programs. We have a way to 'dump' a scene (as text, showing scenegraph) to a file. And we have a way to do a screen snapshot (to an image file). One more idea: have some way to specify the number of loops to advance (perhaps also time?) But nothing working today as automated test suite. > Is there a specific set of validation rules you use/follow ? I'm not the right one to ask, I think if a project is a member of web3d.org ($$), then there is a special suite of test files they have access to. We don't have that publicly available. So we use whatever small test files we have accumulated, to test different features. I have more than the 50 test scenes above, but not well organized/categorized, not well documented and not synchronized to web3d.org specification cateogories. A mess. I'll study your other comments on Git, doxygen. Roadmap > web3d Conformance as noted in another post, there's a scorecard for vrml browswers, and perhaps it could be used as a roadmap (or part of roadmap) for future work. "Web3D participants keep a status report on players at the following wiki site. Updates and corrections are always welcome." Don http://www.web3d.org/wiki/index.php/Player_support_for_X3D_components -Doug |
|
From: doug s. <hig...@ho...> - 2013-04-22 18:52:09
|
> > > ... When I do testing there are 50 or so .wrl/.x3d test > > > files I run. > > > http://dug9.users.sourceforge.net/web3d/tests/screenlinks.html > > > Plus depending on what I'm tinkering with, I'll set up special > > > .wrl/.x3d test files, and I've accumulated some samples people have > > > sent in. > > > > > Can you describe your testing process a bit better ? Do you mean you > > manually open the files and play with them to assert the validity of > > the code ? > > Manually open the file, manually click/drag the mouse, visually look at > the scene and compare with my memory of what the scene looked like > before fhe change. > One developer Michel attempted more automated testing via commandline > string containing mouse input (haven't tried it, not sure if it still > works or how advanced it was, would have been at least a few years > ago). > Recently we were wondering if it's possible/how to do more automated > testing with graphical programs. We have a way to 'dump' a scene (as > text, showing scenegraph) to a file. And we have a way to do a screen > snapshot (to an image file). One more idea: have some way to specify > the number of loops to advance (perhaps also time?) But nothing > working today as automated test suite. Paulo, There was also an idea of a record mode in freewrl: specifically: - number of frames - input: keystroke, mouse action - snapshot - dumpscene And perhaps put it in a special file format, for playback during testing. To make the number of frames smaller -so the tests run faster- the record mode could purposely run slow - pausing on each frame. -Doug |
|
From: doug s. <hig...@ho...> - 2013-04-29 22:42:30
|
> >- Roadmap > > - Where is the project heading > > - How much of the X3d/VRML7 spec is the project interested in > > covering/implementing Here's some roadmap categories and ideas, some things we're already doing, brought up lately or have on our wish list, and I threw in a few I've been incubating. Feel free to vote 1 to 10 on your need, and add more categories and ideas. Roadmap categories: FreeWRL and libfreewrl user uptake - web3d.org feature set conformance and extension - quality and performance of features - platforms - ease of installation, learning and use - complementary tools and example content developer uptake - platforms - modern languages and tools - good code and folder structure - developer guidance / insight / code documentation - testing > tools and test data - interesting connections to other projects, spinoffs, opportunities - social-media-like communication between developers . Related projects - other web3d tools - web3d content - combinations of web3d with other projects Roadmap ideas: FreeWRL and libfreewrl user uptake - web3d.org feature set conformance and extension -- http://www.web3d.org/wiki/index.php/Player_support_for_X3D_components -- background node that takes mobile front-facing camera snapshot or stream - quality and performance of features -- rendering speed > collision & gravity, worker threads, CPU profiling tests -- parsing > nested protos > brotos -- stereovision -- input devices -- multiple-screen/window rendering -- multiple scenes in one html page -- SAI: browser-native FF, Chrome, Safari, IE, Java -- EAI: C, python, other examples, MVIP - platforms -- OSX, win, linux, iPhone, Android, Blackberry, ?? - ease of installation, learning and use -- Gui, Help, automatic updates/notification -- easy way to report bug, suggestion, some way to Like/vote for a proposed new feature -- easy way to connect with other users for tips, content -- complementary content site - complementary tools and example content -- GoogleEarth snapshot, pluginPicker, URL tester, Gui Launch parameter setter, ??? developer uptake - platforms -- OSX, windows, linux (multiple) - modern languages and tools -- Git, OO language, memory management, Visual Studio, Eclipse/CDT, gnu autotools - good code and folder structure - developer guidance / insight / code documentation -- doxygen, folder .txt - testing > tools and test data -- automated testing framework -- functional test recording and playback system -- thorough suite of functional test files - interesting connections to other projects, spinoffs, opportunities - social-media-like communication between developers . Related projects - other web3d tools -- WhiteDune_Cloud - web-app authoring tool -- SSR - server-side rendering system - web3d content -- CloudVR content website - combinations of web3d with other projects -- x3d over collada - animatable content in web3d layer, connect-by-position x3d node |
|
From: doug s. <hig...@ho...> - 2013-04-29 23:59:33
|
http://www.sciencedaily.com/releases/2013/04/130429114826.htm Progrmmers age > From: hig...@ho... > To: fre...@li... > Date: Mon, 29 Apr 2013 16:42:23 -0600 > Subject: [FreeWRL-develop] Roadmap > add, like? > > > >- Roadmap > > > - Where is the project heading > > > - How much of the X3d/VRML7 spec is the project interested in > > > covering/implementing > > Here's some roadmap categories and ideas, some things we're already doing, brought up lately or have on our wish list, and I threw in a few I've been incubating. Feel free to vote 1 to 10 on your need, and add more categories and ideas. > > Roadmap categories: > > FreeWRL and libfreewrl > user uptake > - web3d.org feature set conformance and extension > - quality and performance of features > - platforms > - ease of installation, learning and use > - complementary tools and example content > developer uptake > - platforms > - modern languages and tools > - good code and folder structure > - developer guidance / insight / code documentation > - testing > tools and test data > - interesting connections to other projects, spinoffs, opportunities > - social-media-like communication between developers > . > Related projects > - other web3d tools > - web3d content > - combinations of web3d with other projects > > Roadmap ideas: > > FreeWRL and libfreewrl > user uptake > - web3d.org feature set conformance and extension > -- http://www.web3d.org/wiki/index.php/Player_support_for_X3D_components > -- background node that takes mobile front-facing camera snapshot or stream > - quality and performance of features > -- rendering speed > collision & gravity, worker threads, CPU profiling tests > -- parsing > nested protos > brotos > -- stereovision > -- input devices > -- multiple-screen/window rendering > -- multiple scenes in one html page > -- SAI: browser-native FF, Chrome, Safari, IE, Java > -- EAI: C, python, other examples, MVIP > - platforms > -- OSX, win, linux, iPhone, Android, Blackberry, ?? > - ease of installation, learning and use > -- Gui, Help, automatic updates/notification > -- easy way to report bug, suggestion, some way to Like/vote for a proposed new feature > -- easy way to connect with other users for tips, content > -- complementary content site > - complementary tools and example content > -- GoogleEarth snapshot, pluginPicker, URL tester, Gui Launch parameter setter, ??? > developer uptake > - platforms > -- OSX, windows, linux (multiple) > - modern languages and tools > -- Git, OO language, memory management, Visual Studio, Eclipse/CDT, gnu autotools > - good code and folder structure > - developer guidance / insight / code documentation > -- doxygen, folder .txt > - testing > tools and test data > -- automated testing framework > -- functional test recording and playback system > -- thorough suite of functional test files > - interesting connections to other projects, spinoffs, opportunities > - social-media-like communication between developers > . > Related projects > - other web3d tools > -- WhiteDune_Cloud - web-app authoring tool > -- SSR - server-side rendering system > - web3d content > -- CloudVR content website > - combinations of web3d with other projects > -- x3d over collada - animatable content in web3d layer, connect-by-position x3d node > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > FreeWRL-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freewrl-develop |
|
From: Ian S. A. <ia...@ae...> - 2013-04-30 01:11:53
|
On 29/04/13 07:59 PM, doug sanden wrote: > http://www.sciencedaily.com/releases/2013/04/130429114826.htm > Progrmmers age > Woo! there's still hope for me next year! |
|
From: doug s. <hig...@ho...> - 2013-04-30 14:25:58
|
> > Roadmap categories: > > FreeWRL and libfreewrl > user uptake > - web3d.org feature set conformance and extension we need the zipped form of x3d, for large files > ..extension but the specs have a funny kind of zip working per-field. I think it should be a standard .zip of a folder/directory with image resources, extern protos and .x3d scene, like googleEarth's .kmz. This would allow the x3d-over-dae (collada) idea to jive with kml-over-dae of googleEarth. > Related projects > - web3d content The international space station ISS has a lot of twitter followers. Here's an X3D model of ISS http://dug9.users.sourceforge.net/web3d/tests/NASA/ISS.x3d To make it I downloaded a .3ds model from NASA http://www.nasa.gov/multimedia/3d_resources/ and converted it by importing into Blender and exporting to .x3d If someone is doing some kind of follow-the-astronaut website, web3d could be used, perhaps with SSR (server-side rendering) for mobile and x-platform no-installation viewing. |
|
From: doug s. <hig...@ho...> - 2013-04-30 17:10:22
|
-> > FreeWRL and libfreewrl > > user uptake > > - web3d.org feature set conformance and extension > we need the zipped form of x3d, for large files > > ..extension > but the specs have a funny kind of zip working per-field. I think it should be a standard .zip of a folder/directory with image resources, extern protos and .x3d scene, like googleEarth's .kmz. This would allow the x3d-over-dae (collada) idea to jive with kml-over-dae of googleEarth. > There is a gzip mimetype for x3d .x3dz that will hold 1 x3d scene file (no .tar of folder). . > > Related projects > > - web3d content > The international space station ISS has a lot of twitter followers. Here's an X3D model of ISS > http://dug9.users.sourceforge.net/web3d/tests/NASA/ISS.x3d > To make it I downloaded a .3ds model from NASA > http://www.nasa.gov/multimedia/3d_resources/ . The ISS .x3d model has no external resources, so here it is gzipped: http://dug9.users.sourceforge.net/web3d/tests/NASA/ISS.x3dz . I would still like a way to zip or tar.gz a folder with scene file, extern protos, /imaages /dae and have freewrl download and handle it. This mimetype list shows .x3dz http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/docs/conf/mime.types?view=annotate model/x3d+binary x3db x3dbz model/x3d+vrml x3dv x3dvz model/x3d+xml x3d x3dz . Since .x3dz has already been taken, I propose model/x3d+xml+zip .x3z for a (tar.gz or) .zip of a directory containing main.x3d scene, extern protos, anchor-to scenes, inlines, /images /dae -Doug |
|
From: Paulo E. C. <pau...@gm...> - 2013-05-02 10:33:50
|
On 29/04/13 23:42, doug sanden wrote: >> >- Roadmap >> > - Where is the project heading >> > - How much of the X3d/VRML7 spec is the project interested in >> > covering/implementing > Here's some roadmap categories and ideas, some things we're already doing, brought up lately or have on our wish list, and I threw in a few I've been incubating. Feel free to vote 1 to 10 on your need, and add more categories and ideas. > > Roadmap categories: > > FreeWRL and libfreewrl > user uptake > 10 - web3d.org feature set conformance and extension > 10 - quality and performance of features > - platforms > 10 - ease of installation, learning and use > 10 - complementary tools and example content > developer uptake > - platforms > 9 - modern languages and tools > 9 - good code and folder structure > 10 - developer guidance / insight / code documentation > 9 - testing > tools and test data > 7 - interesting connections to other projects, spinoffs, opportunities > 6 - social-media-like communication between developers > . > Related projects > - other web3d tools > - web3d content > - combinations of web3d with other projects > > Roadmap ideas: > > FreeWRL and libfreewrl > user uptake > - web3d.org feature set conformance and extension > -- http://www.web3d.org/wiki/index.php/Player_support_for_X3D_components > -- background node that takes mobile front-facing camera snapshot or stream > - quality and performance of features > -- rendering speed > collision & gravity, worker threads, CPU profiling tests > -- parsing > nested protos > brotos > -- stereovision > -- input devices > -- multiple-screen/window rendering > -- multiple scenes in one html page > 10 -- SAI: browser-native FF, Chrome, Safari, IE, Java > 10 -- EAI: C, python, other examples, MVIP > - platforms > 9 -- OSX, win, linux, iPhone, Android, Blackberry, ?? > - ease of installation, learning and use > -- Gui, Help, automatic updates/notification > -- easy way to report bug, suggestion, some way to Like/vote for a proposed new feature > -- easy way to connect with other users for tips, content > 8 -- complementary content site > - complementary tools and example content > 10 -- GoogleEarth snapshot, pluginPicker, URL tester, Gui Launch parameter setter, ??? > developer uptake > - platforms > -- OSX, windows, linux (multiple) > - modern languages and tools > 10-- Git, OO language, memory management, Visual Studio, Eclipse/CDT, gnu autotools > 10- good code and folder structure > 10- developer guidance / insight / code documentation > 11 -- doxygen, folder .txt > 9 - testing > tools and test data > 9 -- automated testing framework > 9 -- functional test recording and playback system > 9 -- thorough suite of functional test files > - interesting connections to other projects, spinoffs, opportunities > - social-media-like communication between developers > . > Related projects > - other web3d tools > -- WhiteDune_Cloud - web-app authoring tool > -- SSR - server-side rendering system > - web3d content > -- CloudVR content website > - combinations of web3d with other projects > -- x3d over collada - animatable content in web3d layer, connect-by-position x3d node > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > FreeWRL-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freewrl-develop > |
|
From: doug s. <hig...@ho...> - 2013-05-03 13:48:03
|
> > Roadmap ideas: > > FreeWRL and libfreewrl > > user uptake > > 10 -- GoogleEarth snapshot, pluginPicker, URL tester, Gui Launch parameter setter, ??? . Win32 > Freewrl_Launcher These -GE snapshot, pluginPicker, URL tester, gui launch parameter setter - are in a separate C# app freeWRL_Launcher on win32 only, installed with the .msi installer. The C# source code is in the support files section of the download page. https://sourceforge.net/projects/freewrl/files/freewrl-win32/SupportFiles/ . 1. launch parameters - when I started out in windows, there was just a command line .exe. I started the win32 Launcher because freeWRL takes command line parameters -which I'm too lazy to type- and I was too lazy to do an MFC gui for freewrl. So a separate launcher program was a quick hack. Then it grew with a few more panels. . Meanwhile I also put a statusbarHud.c in win32 freewrl -and used it a modification of it on a blackberry qnx playbook version- that also allows setting some parameters at runtime, so it can be used on various platforms but I don't know which distros use it . 2. GoogleEarth snapshot - you point down in GoogleEarth then hit the Launcher's snapshot button and the ground image and elevationGrid are captured in .x3d format. I suspect the googleEarth's snapshot interface doesn't exist in linux - it's a COM interface in win32 and they are retiring it: http://googlegeodevelopers.blogspot.ca/2010/08/sunset-for-google-earth-com-api.html . I have no idea if or how to use their javascript interface to do something equivalent. https://developers.google.com/earth/documentation/ . 3. plugin picker - works just for Internet Explorer, and works by tinkering in windows registry on mime and filetype handlers. I have a number of web3d browsers installed, and Internet Explorer figures out which one to use based on windows registry, so when I'm comparing for testing, I'll quickly switch plugins this way. I don't know how to do the equivalent for Firefox in win32 -something I'll need- or how to do anything equivalent in linux. Perhaps modern versions of IE and FF have panels for selecting a plugin handler? . 4. url tester - just a handy gui panel where I can type an http:// url, hit a button and get all the hidden junk displayed that's sent from the server, such as mimetype, error codes, server type. . -Doug |
|
From: Paulo E. C. <pau...@gm...> - 2013-05-17 13:17:29
|
> > Recently we were wondering if it's possible/how to do more automated
> > testing with graphical programs. We have a way to 'dump' a scene (as
> > text, showing scenegraph) to a file. And we have a way to do a screen
> > snapshot (to an image file). One more idea: have some way to specify
> > the number of loops to advance (perhaps also time?) But nothing
> > working today as automated test suite.
> Paulo,
> There was also an idea of a record mode in freewrl: specifically:
> - number of frames
> - input: keystroke, mouse action
> - snapshot
> - dumpscene
> And perhaps put it in a special file format, for playback during testing.
> To make the number of frames smaller -so the tests run faster- the
> record mode could purposely run slow - pausing on each frame.
> -Doug
I've written a small perl test script that's using a library that I'm
currently maintaining that allows keyboard and mouse interactions when
running on a X11 env, it currently does the following:
- Opens freewrl with a given test wrl file.
- Takes a snapshot
- Goes to the next file
I have the following problems:
- Sometimes freewrl takes some time to load and gives no indication of
when it has finished rendering. We could use such hint in order to
trigger a snapshot after rendering rather than "sleeping" and hope it's
enough....
- Currently the snapshot only seems to work with PNG which has a file is
not suitable for comparison with for instance a previous master version.
- It would be interesting to know how to move to a specific viewpoint
say 45 degrees to the left,right, up, down... without having to manually
do so by means of keyboard/mouse
I'm not entirely sure that comparing image snapshots with a previous
known good image is the right way to do it but at least it exercises
some of the points you where making above.
My idea based on your comments is somehow similar to this; If we imagine
a cylinder around the main item of a given test file perhaps we could do
the following....
- Open a test file
- Wait for rendering to finish.
- Take a snapshot
- Move to a different viewpoint coordinate on the cylinder and take a
snapshot. and so on
- North, South, East, West, Above, Below
- Compare those snapshots with previously good known ones.
*This would obviously not cope well with moving objects in the scene but
that's a different ball game.
What do you guys think about this ?
I've pushed my test script to github and it lives in the branch called
testing-freewrl.
More details about it here
https://github.com/pecastro/freewrl/commits/testing-freewrl
|
|
From: doug s. <hig...@ho...> - 2013-05-17 14:33:27
|
Paulo,
>
>>> Recently we were wondering if it's possible/how to do more automated
>>> testing with graphical programs. We have a way to 'dump' a scene (as
>>> text, showing scenegraph) to a file. And we have a way to do a screen
>>> snapshot (to an image file). One more idea: have some way to specify
>>> the number of loops to advance (perhaps also time?) But nothing
>>> working today as automated test suite.
>> Paulo,
>> There was also an idea of a record mode in freewrl: specifically:
>> - number of frames
>> - input: keystroke, mouse action
>> - snapshot
>> - dumpscene
>> And perhaps put it in a special file format, for playback during testing.
>> To make the number of frames smaller -so the tests run faster- the
>> record mode could purposely run slow - pausing on each frame.
>> -Doug
> I've written a small perl test script that's using a library that I'm
> currently maintaining that allows keyboard and mouse interactions when
> running on a X11 env, it currently does the following:
> - Opens freewrl with a given test wrl file.
> - Takes a snapshot
> - Goes to the next file
>
> I have the following problems:
>
> - Sometimes freewrl takes some time to load and gives no indication of
> when it has finished rendering. We could use such hint in order to
> trigger a snapshot after rendering rather than "sleeping" and hope it's
> enough....
.
Perhaps for both fixture creation and later comparision testing the main program could be different or go into a different loop, holding off rendering until parsing is finished, or not counting frames until it's finished. A commandline parameter might put it into fixture mode or testing mode.
.
> - Currently the snapshot only seems to work with PNG which has a file is
> not suitable for comparison with for instance a previous master version.
.
Because of compression? Is there a way to turn off compression? If so then it switch on a global testing mode parameter. Or is there more saved, such as the date and timestamp in the .png, causing a generic binary file compare to fail?
(win32 saves .bmp which has no compression -great for testing- but it's a pain then emailing a screenshot because I have to use another tool to convert it to .png for cross-platform consumption)
Q. instead of saving to any standard file format, don't we first get a binary blob from opengl somehow, and could we just save the blob and use it for comparison? Perhaps store widthxheight in another file (playback file?) in case someone wants to visually check a failed comparison? Or would we always know the widthxheight by setting the opengl window to a standard size for testing?
.
> - It would be interesting to know how to move to a specific viewpoint
> say 45 degrees to the left,right, up, down... without having to manually
> do so by means of keyboard/mouse
>
> I'm not entirely sure that comparing image snapshots with a previous
> known good image is the right way to do it but at least it exercises
> some of the points you where making above.
>
> My idea based on your comments is somehow similar to this; If we imagine
> a cylinder around the main item of a given test file perhaps we could do
> the following....
> - Open a test file
.
Good. Right now there are separate threads for reading/parsing the file, and the rendering loop. Perhaps in test mode there would need to be some counting of frames after load is finished.
For example if just parsing is being tested, then the 1st frame after parsing is complete.
> - Wait for rendering to finish.
Some tests are needed for things like animation and routing, which happens over multiple frames. Some animation things are simple interpolators with a time or delta-time input.
One idea is to save both frames-after-parsing and the double dtime value to go with it, during the test fixture generation:
{int frame, double dtime, ?other?}
then during test run, instead of using clock time substitute the saved dtime, to match the fixture run.
.
> - Take a snapshot
.
During fixture generation save the {snapshot, iframe#, dtime} (or else perhaps save the snapshot command keystroke?) and during testing save the snapshot on iframe#, then do a binary file compare
.
> - Move to a different viewpoint coordinate on the cylinder and take a
> snapshot. and so on
> - North, South, East, West, Above, Below
> - Compare those snapshots with previously good known ones.
.
Some scenes and things you want to test are not single objects but rather spread out scenes, and sometimes the things being tested are not even graphical - such as routing and script tests that show up in the text console. So not every test could benefit from this exact sequence.
The graphics window is a proxy for the scenegraph state. So one way to test the non-graphical stuff is by saving the scenegraph state. Except a problem: it's full of memory pointers, which aren't the same between runs (malloc creates them different each time), and we may be trying to change the scenegraph storage - the subject of our tests. And not all things are stored in the scenegraph. But for some tests some kind of pointer-neutralized dump of the scenegraph might make a good test fixture.
.
So I think we would need general / flexible approach to testing to cover all cases. I kind of like what Michel had been attempting, saving the mouse coordinates for playback.
Perhaps what's needed is a playback file that records a lot of things, per post-parse frame#
playback[i] = {iframe, dtime, keystrokes or NULL, mouse (xy,button sequence) or NULL, snapshot URL or NULL, scenegraph_dump URL or NULL, ?other?}
.
>
> *This would obviously not cope well with moving objects in the scene but
> that's a different ball game.
.
Perhaps the above detailed playback file approach would/could be made to cover the moving objects scenario?
.
>
> What do you guys think about this ?
>
> I've pushed my test script to github and it lives in the branch called
> testing-freewrl.
> More details about it here
> https://github.com/pecastro/freewrl/commits/testing-freewrl
Thanks Paulo, great work - I'll check it out this weekend.
-Doug
|
|
From: Luca C. <ce...@sy...> - 2013-05-17 16:16:32
|
Hi, I've noticed that the initialization process of the EAI through \src\libeai\EAI_C_Control.c -> X3D_Initialize only print error messages on the standard output if the initialization goes wrong. Since the same function could be used from a non-console application or library, wouldn't it be better if it returns a boolean value or, even better, an int error code? If you value it useful I could make the upgrade. -- =============================================================== Luca Cerutti Profutura s.r.l. - Corso Tortona 17 - 10153 Torino phone: +39 (0)11 8392363 - fax: +39 (0)11 837802 e-mail: ce...@sy... http://www.synarea.com Le informazioni, i dati e le notizie contenute nella presente comunicazione e i relativi allegati sono di natura privata e come tali possono essere riservate e sono, comunque, destinate esclusivamente ai destinatari indicati in epigrafe. La diffusione, distribuzione e/o la copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita, sia ai sensi dell’art. 616 c.p., sia ai sensi del D.Lgs. n. 196/2003. Se avete ricevuto questo messaggio per errore, vi preghiamo di distruggerlo e di darcene immediata comunicazione anche inviando un messaggio di ritorno all’indirizzo e-mail del mittente. This e-mail (including attachments) is intended only for the recipient(s) named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not the named recipient, please contact (ce...@sy...) and delete the e-mail from your system. Rif. D.L. 196/2003. =============================================================== |
|
From: doug s. <hig...@ho...> - 2013-05-17 16:33:38
|
> > Hi, > I've noticed that the initialization process of the EAI through > \src\libeai\EAI_C_Control.c -> X3D_Initialize > > only print error messages on the standard output if the initialization > goes wrong. > Since the same function could be used from a non-console application or > library, wouldn't it be better if it returns a boolean value or, even > better, an int error code? > > If you value it useful I could make the upgrade. > Luca, I haven't looked at the code but here's some thoughts that popped to mind: instead of printf() you could call ConsoleMessage() which is meant to show the message on non-console configurations (and default to printf on console configurations). Some configurations use statusbarHud.c which has a [!] menu button which then renders the messages as pixel text over the scene window. I think John gave the Android version a separate text window. If a return value would break something, could you do something like this: make that change but also change the name to int X3D_Initialize0() with a 0 in the name, and then make a function X3D_Initialize() with the old signature (that returns no value) and calls the 0() function? Then whoever can use the return value calls the 0 function and all the old code keeps calling the old way. -Doug |
|
From: Luca C. <ce...@sy...> - 2013-05-17 16:49:34
|
Doug, I did not know of the ConsoleMessage() function. As of now the code calls the X3D_error function that uses the perror function. I thought of the return value because I'd like the caller application to manage the missing socket comunication (e.g. by trying a "server" restart if it knows how to do it... which is my case). I'll apply your suggestion. Il 17/05/2013 18:33, doug sanden ha scritto: >> Hi, >> I've noticed that the initialization process of the EAI through >> \src\libeai\EAI_C_Control.c -> X3D_Initialize >> >> only print error messages on the standard output if the initialization >> goes wrong. >> Since the same function could be used from a non-console application or >> library, wouldn't it be better if it returns a boolean value or, even >> better, an int error code? >> >> If you value it useful I could make the upgrade. >> > Luca, > I haven't looked at the code but here's some thoughts that popped to mind: > instead of printf() you could call ConsoleMessage() which is meant to show the message on non-console configurations (and default to printf on console configurations). Some configurations use statusbarHud.c which has a [!] menu button which then renders the messages as pixel text over the scene window. I think John gave the Android version a separate text window. > If a return value would break something, could you do something like this: make that change but also change the name to int X3D_Initialize0() with a 0 in the name, and then make a function X3D_Initialize() with the old signature (that returns no value) and calls the 0() function? Then whoever can use the return value calls the 0 function and all the old code keeps calling the old way. > -Doug > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > FreeWRL-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freewrl-develop > -- =============================================================== Luca Cerutti Profutura s.r.l. - Corso Tortona 17 - 10153 Torino phone: +39 (0)11 8392363 - fax: +39 (0)11 837802 e-mail: ce...@sy... http://www.synarea.com Le informazioni, i dati e le notizie contenute nella presente comunicazione e i relativi allegati sono di natura privata e come tali possono essere riservate e sono, comunque, destinate esclusivamente ai destinatari indicati in epigrafe. La diffusione, distribuzione e/o la copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita, sia ai sensi dell’art. 616 c.p., sia ai sensi del D.Lgs. n. 196/2003. Se avete ricevuto questo messaggio per errore, vi preghiamo di distruggerlo e di darcene immediata comunicazione anche inviando un messaggio di ritorno all’indirizzo e-mail del mittente. This e-mail (including attachments) is intended only for the recipient(s) named above. It may contain confidential or privileged information and should not be read, copied or otherwise used by any other person. If you are not the named recipient, please contact (ce...@sy...) and delete the e-mail from your system. Rif. D.L. 196/2003. =============================================================== |
