freewrl-help — For outside questions; open to public

[FreeWRL-help] subscribe

[Michel B. <mic...@fr...>]

[FreeWRL-help] test again

[Ian S. A. R. <ia...@ae...>]

..test test test...

[FreeWRL-help] first test message

[Ian S. A. R. <ia...@ae...>]

test test test..

Re: [FreeWRL] Suggested hidden change is EAI routines

[Ian S. A. R. <ia...@ae...>]

On 10/05/10 06:39 PM, Dave Joubert wrote:
> It would seem to called from only two places:
> ./src/lib/input/EAIEventsOut.c:74 and (EV interrupt)
> ./src/lib/input/EAIHelpers.c:594 (normal RE reply)
>
> To my eyes however, the signature is duplicated in two different header files:
>
> ./src/lib/input/EAIHeaders.h:55:void EAI_Convert_mem_to_ASCII (int id,
> char *reptype, int type, char *memptr, char *buf);
> ./src/lib/world_script/fieldGet.h:42:void EAI_Convert_mem_to_ASCII
> (int id, char *reptype, int type, char *memptr, char *buf);
> ./src/lib/world_script/fieldGet.c:859:void EAI_Convert_mem_to_ASCII
> (int id, char *reptype, int type, char *memptr, char *buf)
>
> Callers:
> ./src/lib/input/EAIEventsOut.c:74:      EAI_Convert_mem_to_ASCII
> (id,"EV", tp, EAIListenerData, buf);
> ./src/lib/input/EAIHelpers.c:594:       EAI_Convert_mem_to_ASCII
> (repno,"RE",mapEAItypeToFieldType(ctmp[0]),getEAIMemoryPointer(nodeIndex,fieldIndex),
> buf);
>
>   
The EAIHeaders.h vs EAIhelpers.h vs other headers in that directory are
a little confusing, and although i'm sure there's probably a reason for
the way they're currently structured (i'm guessing EAIHeaders.h
specifically lists all the stuffs required for libEAI, probably meant to
be an API file for the library but not necessarily used internally), I
think it could probably be cleaned up.

Re: [FreeWRL] Suggested hidden change is EAI routines

[John A. S. <ale...@cr...>]

Dave;

> void EAI_Convert_mem_to_ASCII (int id, char *reptype, int type, char
> *memptr, char *buf) {
> 
> 
> Can I please build some more flexibility into it ?

Absolutely. It was my attempt to collect bits and pieces from various routines in one place. 

That doesn't mean that it is the best way of doing things.

> ...
> Either method would mean that it could be used a a debugging tool.
> 
> Preferences ?

No; whichever suits your goals the best.
> 
> To my eyes however, the signature is duplicated in two different header files:
> 
> ./src/lib/input/EAIHeaders.h:55:void EAI_Convert_mem_to_ASCII (int id,
> char *reptype, int type, char *memptr, char *buf);
> ./src/lib/world_script/fieldGet.h:42:void EAI_Convert_mem_to_ASCII
> (int id, char *reptype, int type, char *memptr, char *buf);
> ./src/lib/world_script/fieldGet.c:859:void EAI_Convert_mem_to_ASCII
> (int id, char *reptype, int type, char *memptr, char *buf)

I'd expect that it should only be in the EAIHeaders.h. This is an artifact of the taking of one big file in Perl days and splitting it up into many.  Whenever I found these artifacts I tried to remove them.  

JohnS.

[FreeWRL] Suggested hidden change is EAI routines

[Dave J. <dav...@go...>]

While thinking in terms of debugging (and possible possible
extensions) I tracked down this routine:

./src/lib/world_script/fieldGet.c:859:
void EAI_Convert_mem_to_ASCII (int id, char *reptype, int type, char
*memptr, char *buf) {

It actually does three jobs:
Finds the location where the value is kept
Converts the value into the appropriate string representation
embeds the reply into the buffer string that is going to be returned
via the socket.

Can I please build some more flexibility into it ?

Method 1:
1) add another parameter (true/false) that controls whether the answer
is going to be embedded into the buffer
2) return a string instead of a void

Method 2:
Alternatively I could leave the call as it is, but refactor it so that
90% of the code goes into a helper function that returns a string,
The return value of the new function is used to create the reply in
the original function
The callers would then stay the same, but the debug code would call
the helper function directly

Either method would mean that it could be used a a debugging tool.

Preferences ?

It would seem to called from only two places:
./src/lib/input/EAIEventsOut.c:74 and (EV interrupt)
./src/lib/input/EAIHelpers.c:594 (normal RE reply)

To my eyes however, the signature is duplicated in two different header files:

./src/lib/input/EAIHeaders.h:55:void EAI_Convert_mem_to_ASCII (int id,
char *reptype, int type, char *memptr, char *buf);
./src/lib/world_script/fieldGet.h:42:void EAI_Convert_mem_to_ASCII
(int id, char *reptype, int type, char *memptr, char *buf);
./src/lib/world_script/fieldGet.c:859:void EAI_Convert_mem_to_ASCII
(int id, char *reptype, int type, char *memptr, char *buf)

Callers:
./src/lib/input/EAIEventsOut.c:74:      EAI_Convert_mem_to_ASCII
(id,"EV", tp, EAIListenerData, buf);
./src/lib/input/EAIHelpers.c:594:       EAI_Convert_mem_to_ASCII
(repno,"RE",mapEAItypeToFieldType(ctmp[0]),getEAIMemoryPointer(nodeIndex,fieldIndex),
buf);

Dave

Re: [FreeWRL] EAI documentation question

[Dave J. <dav...@go...>]

On 10 May 2010 19:58, Ian Stakenvicius, Aerobiology Research
<ia...@ae...> wrote:
> On 10/05/10 02:51 PM, Dave Joubert wrote:
>> On 10 May 2010 18:47, Ian Stakenvicius, Aerobiology Research
>> <ia...@ae...> wrote:
>>
>>> On 10/05/10 01:34 PM, John A. Stewart wrote:
>>>
>>>> Dave;
>>>>
>>>>
>>>>
>>>>> I would make three suggestions:
>>>>>
>>>>> a) Move the .doc files to .html files permanently
>>>>>
>> Do others have any comments about this ?
>> 1) I always have access to a text editor,but only some of the machines
>> here run a word processor (and only one of them runs MS WORD)
>> 2) CVS can genuinely track the document.
>>
>
> Oh absolutely -- Word document format is not useful imo as a general
> available-to-the-world document.
>
>> OK, tested this.
>> 1) They have closed off SSI
>> 2) PHP works OK, sample file djtest.php contains <?php include('djtest.html') ?>
>>
>> So, a simple template system will be usable by everyone.
>>
>>
> Sweet! Thanks Dave!

Sample page http://freewrl.sourceforge.net/sampledoc.php
consists of:
     1	<?php include('./fwheader.idoc') ?>
     2	
     3		<h1>FreeWRL/FreeX3D Sample Page</h1>
     4		<p>
     5		This is a sample page ....
     6		</p>
     7	
     8	<?php include('./fwtrailer.idoc') ?>

Re: [FreeWRL] EAI documentation question

[Ian S. A. R. <ia...@ae...>]

On 10/05/10 02:51 PM, Dave Joubert wrote:
> On 10 May 2010 18:47, Ian Stakenvicius, Aerobiology Research
> <ia...@ae...> wrote:
>   
>> On 10/05/10 01:34 PM, John A. Stewart wrote:
>>     
>>> Dave;
>>>
>>>
>>>       
>>>> I would make three suggestions:
>>>>
>>>> a) Move the .doc files to .html files permanently
>>>>         
> Do others have any comments about this ?
> 1) I always have access to a text editor,but only some of the machines
> here run a word processor (and only one of them runs MS WORD)
> 2) CVS can genuinely track the document.
>   

Oh absolutely -- Word document format is not useful imo as a general
available-to-the-world document.

> OK, tested this.
> 1) They have closed off SSI
> 2) PHP works OK, sample file djtest.php contains <?php include('djtest.html') ?>
>
> So, a simple template system will be usable by everyone.
>
>   
Sweet! Thanks Dave!

Re: [FreeWRL] EAI documentation question

[Dave J. <dav...@go...>]

On 10 May 2010 18:47, Ian Stakenvicius, Aerobiology Research
<ia...@ae...> wrote:
> On 10/05/10 01:34 PM, John A. Stewart wrote:
>> Dave;
>>
>>
>>> I would make three suggestions:
>>>
>>> a) Move the .doc files to .html files permanently

Do others have any comments about this ?
1) I always have access to a text editor,but only some of the machines
here run a word processor (and only one of them runs MS WORD)
2) CVS can genuinely track the document.

>>> b) Insert all the .html files into a new area in the CVS tree, say a
>>> subdir called webtree with the same tree structure as the website
>>> c) Bundle a couple of expect scripts into the CVS tree as well, to do
>>> the upload to the website (*)
>>>
>> I think Ian might have better ideas on this than I. (probably many others here, too)
>>
>
> This sounds pretty good to me.  s/expect/export/
>
>> Does the webserver where the pages currently are support Server Side
>>> Includes? If it does, then is is even easier to maintain a consistent
>>> look.
>>>
>> Unknown, but I'd expect so.
>>
No, they do not.

>
> I think probably not (iirc there were security issues with SSI that were
> never resolved and so is usually turned off on web servers), but I do
> expect that it supports either php or asp, and we can do the same thing
> with that.

Sure

> Alternatively, it's not too hard to make the export scripts
> handle inserting common header/footer/formatting info when the data gets
> published.  Alternatively (2), a properly-built CSS file can handle all
> of the look-and-feel stuff, leaving the html files essentially bare.
>

OK, tested this.
1) They have closed off SSI
2) PHP works OK, sample file djtest.php contains <?php include('djtest.html') ?>

So, a simple template system will be usable by everyone.

Dave

Re: [FreeWRL] EAI documentation question

[Ian S. A. R. <ia...@ae...>]

On 10/05/10 01:34 PM, John A. Stewart wrote:
> Dave;
>
>   
>> I would make three suggestions:
>>
>> a) Move the .doc files to .html files permanently
>> b) Insert all the .html files into a new area in the CVS tree, say a
>> subdir called webtree with the same tree structure as the website
>> c) Bundle a couple of expect scripts into the CVS tree as well, to do
>> the upload to the website (*)
>>     
> I think Ian might have better ideas on this than I. (probably many others here, too)
>   

This sounds pretty good to me.  s/expect/export/

> Does the webserver where the pages currently are support Server Side
>> Includes? If it does, then is is even easier to maintain a consistent
>> look.
>>     
> Unknown, but I'd expect so.
>   

I think probably not (iirc there were security issues with SSI that were
never resolved and so is usually turned off on web servers), but I do
expect that it supports either php or asp, and we can do the same thing
with that.  Alternatively, it's not too hard to make the export scripts
handle inserting common header/footer/formatting info when the data gets
published.  Alternatively (2), a properly-built CSS file can handle all
of the look-and-feel stuff, leaving the html files essentially bare.

Re: [FreeWRL] EAI documentation question

[John A. S. <ale...@cr...>]

Dave;

> I would make three suggestions:
> 
> a) Move the .doc files to .html files permanently
> b) Insert all the .html files into a new area in the CVS tree, say a
> subdir called webtree with the same tree structure as the website
> c) Bundle a couple of expect scripts into the CVS tree as well, to do
> the upload to the website (*)

I think Ian might have better ideas on this than I. (probably many others here, too)

> 
> Question:
> Now that I have write permission in the code area for the freewrl
> project, do I automatically have write permission for the web area ?

You should be able to. 

Try it.  Try logging in and going to the project, and creating a file "dave.txt".

(do you still have the email I sent around recently about keeping the web pages/software releases up to date?)

> 
> Does the webserver where the pages currently are support Server Side
> Includes? If it does, then is is even easier to maintain a consistent
> look.

Unknown, but I'd expect so.

-----------------------------------------------------------
John A. Stewart
ale...@cr...

Network Systems and Technologies - 
        Systemes et technologies des reseaux
Communications Research Centre Canada  |  
         Centre de recherches sur les communications Canada

3701 Carling Ave.  |  3701, avenue Carling
PO Box 11490, Station H  |  CP 11490, succursale H
         Ottawa ON K2H 8S2   |  Ottawa (Ontario) K2H 8S2

http://www.crc.ca

Re: [FreeWRL] Expanding on Dougs answer to Re: EAI documentation question

[John A. S. <ale...@cr...>]

Dave;

Looking good;

> 
> 56
> 13
> transparency d inputOutput
> specularColor c inputOutput
> shininess d inputOutput
> diffuseColor c inputOutput
> ambientIntensity d inputOutput
> _scol P inputOutput

These "starts with an underscore" ones should not be printed. 

> I think Java wants 7 transparency specularColor shininess diffuseColor
> ambientIntensity emissiveColor metadata

That would sound correct - at least it sounds reasonable.

> 
> (Unsure about metadata)

metadata is part of the X3D spec; it is there in all nodes, IIRC. I think it should be there.

-----------------------------------------------------------
John A. Stewart
ale...@cr...

Network Systems and Technologies - 
        Systemes et technologies des reseaux
Communications Research Centre Canada  |  
         Centre de recherches sur les communications Canada

3701 Carling Ave.  |  3701, avenue Carling
PO Box 11490, Station H  |  CP 11490, succursale H
         Ottawa ON K2H 8S2   |  Ottawa (Ontario) K2H 8S2

http://www.crc.ca

Re: [FreeWRL] EAI documentation question

[Dave J. <dav...@go...>]

On 10 May 2010 15:47, John A. Stewart <ale...@cr...> wrote:
> Dave;
>
> Good questions - thanks for posting them. Currently they are not in CVS. (Can you put a doc file into CVS and have it keep track of changes??)
>
AFAIK, yes one can maintain them in a sccs sytem, but purely as blobs.

I would make three suggestions:

a) Move the .doc files to .html files permanently
b) Insert all the .html files into a new area in the CVS tree, say a
subdir called webtree with the same tree structure as the website
c) Bundle a couple of expect scripts into the CVS tree as well, to do
the upload to the website (*)

Question:
Now that I have write permission in the code area for the freewrl
project, do I automatically have write permission for the web area ?

(*) would keep the usernames and passwords out of the expect scripts.

If we did this, I would be perfectly happy to take responsibility for
this, but in fact any of us could keep it up to date.

>        - a full review of pages with templates was being performed by our graphics people - cancelled. Sigh. So, we are stuck with the hand-edited ones, except for:

Hand edited is good, esp if the files are part of the CVS tree.

One of the first things we should do, is build a blank template page.
Does the webserver where the pages currently are support Server Side
Includes? If it does, then is is even easier to maintain a consistent
look.

>
> Does that help? Please feel free to go nuts on these documents, change them as you wish.
>
>
> Thanks; JohnS.

Re: [FreeWRL] Expanding on Dougs answer to Re: EAI documentation question

[Dave J. <dav...@go...>]

On 10 May 2010 16:29, John A. Stewart <ale...@cr...> wrote:
> Doug; once again you are 100% correct. You get the gold star! ;-)
>
> I'm going to add a bit to Doug's comments.
>
>
>>> So, given I know that the node type of a node is 76, how do I find out
>>> the names of all the fields for that type of node?
>
> There are some interesting tables and functions that are generated by the initial Perl code (run perl VRMLC.pm).
>
> All nodes have a node type.
>
> eg:
>
> struct X3D_Shape *myShape = (struct X3D_Shape *) createNewX3DNode(NODE_Shape);
>
> the "myShape->_nodeType" field will be the int equivalent of "NODE_Shape".
>
> The function "stringNodeType(myShape->_nodeType)" will return a pointer to a string, so you can use this in a printf ("%s",) type of call easily.
>
>> const int *NODE_OFFSETS[] = {
>> OFFSETS_Anchor,    <<<<< this is element [0] on line 5115
>> ....
>> OFFSETS_Material,  <<<<< this is element [76] on line 5115 + 76 = 5191
>>
>> I do the go-to-definition trick on OFFSETS_Material and it takes me to generatedCode.c L3653
>
>
> Yes, so, if you wanted to see what the fields of your Shape node are, as Doug notes:
>
> int * fieldOffsetsPtr = (int *) NODE_OFFSETS[myShape->_nodeType];
>
>
>> const int OFFSETS_Material[] = {
>> (int) FIELDNAMES_transparency, (int) offsetof (struct X3D_Material, transparency),  (int) FIELDTYPE_SFFloat, (int) KW_inputOutput, (int) (SPEC_VRML | SPEC_X3D30 | SPEC_X3D31 | SPEC_X3D32 | SPEC_X3D33),
>> ...
>> -1, -1, -1, -1, -1};
>>
>> It appears to be a table of field names for Material. The -1,-1,-1,-1,-1 is obviously a sentinal value so if you are looping through fields you know when you're done.
>
>
> Ok - the info for each field is grouped into groups of 5 integers.  You know when you are at the end of the fields for that node when you hit the -1, or, for readability, the macro "INT_ID_UNDEFINED"
>
> Some fields are for internal use only, these field names will start off with an underscore. I'll go through a field here for the Shape node.
>
> >From generated code.c:
>
> const int OFFSETS_Shape[] = {
>        ...
>        (int) FIELDNAMES_appearance,
>                - this is the shape "Appearance" field...
>
>        (int) offsetof (struct X3D_Shape, appearance),
>                - offset in the structure of this field; offset is in bytes;
>
>        (int) FIELDTYPE_SFNode,
>                - this is the type of the node; other types might be FIELDTYPE_SFInt32, etc.
>
>        (int) KW_inputOutput,
>                 - for routing, can we send and/or receive events to this node???
>
>         (int) (SPEC_VRML | SPEC_X3D30 | SPEC_X3D31 | SPEC_X3D32 | SPEC_X3D33),
>                - if we are interested in checking, we can see if this field exists in a specific level of X3D.
>        ....
>
>
>
>> That's what the makeFIELDDEFret() appears to be doing.
>>
>> /* now go through and get the name, type, keyword */
>> np = NODE_OFFSETS[boxptr->_nodeType];
>> while (*np != -1) {
>>  if (strcmp (FIELDNAMES[*np],"_") != 0) {
>>   sprintf (myline,"%s %c %s ",stringFieldType(np[0]), (char) mapFieldTypeToEAItype(np[2]),
>>    stringKeywordType(np[3]));
>>   strcat (buf, myline);
>>  }
>>  np += 5;
>> }
>>
>
> Absolutely correct method of accessing. Note that the strcmp in the above while loop gets rid of the internal-only fields, as mentioned briefly above.
>
> If you change the "sprintf(myLine,"  to a "printf(", you'll get the fields of the node printed out, much like you'll see in the VRML/X3D spec.


OK, a crude patch to replace boxptr = X3D_NODE(myptr); with boxptr =
getEAINodeFromTable(myptr,-1); in makeFIELDDEFret
produces: (line breaks inserted for clarity)
........
56
13
transparency d inputOutput
specularColor c inputOutput
shininess d inputOutput
diffuseColor c inputOutput
ambientIntensity d inputOutput
_scol P inputOutput
_dcol P inputOutput
_ecol P inputOutput
emissiveColor c inputOutput
metadata h inputOutput
_amb P inputOutput
__oldmetadata h inputOutput
_shin d inputOutput

I suspect this needs a bit of a cleanup to deliver what (in theory)
the SAI wants, according to the Java code in the other mail thread,
but I will look at this in more detail.

I think Java wants 7 transparency specularColor shininess diffuseColor
ambientIntensity emissiveColor metadata

(Unsure about metadata)

Dave

Re: [FreeWRL] Expanding on Dougs answer to Re: EAI documentation question

[Dave J. <dav...@go...>]

On 10 May 2010 16:29, John A. Stewart <ale...@cr...> wrote:
> Doug; once again you are 100% correct. You get the gold star! ;-)
>
> I'm going to add a bit to Doug's comments.

And this is precisely the kind of document I feel should go on the website .....

Dave

[FreeWRL] Expanding on Dougs answer to Re: EAI documentation question

[John A. S. <ale...@cr...>]

Doug; once again you are 100% correct. You get the gold star! ;-)

I'm going to add a bit to Doug's comments.


>> So, given I know that the node type of a node is 76, how do I find out
>> the names of all the fields for that type of node?

There are some interesting tables and functions that are generated by the initial Perl code (run perl VRMLC.pm).

All nodes have a node type.

eg:

struct X3D_Shape *myShape = (struct X3D_Shape *) createNewX3DNode(NODE_Shape);

the "myShape->_nodeType" field will be the int equivalent of "NODE_Shape".

The function "stringNodeType(myShape->_nodeType)" will return a pointer to a string, so you can use this in a printf ("%s",) type of call easily.

> const int *NODE_OFFSETS[] = {
> OFFSETS_Anchor,    <<<<< this is element [0] on line 5115
> ....
> OFFSETS_Material,  <<<<< this is element [76] on line 5115 + 76 = 5191
> 
> I do the go-to-definition trick on OFFSETS_Material and it takes me to generatedCode.c L3653


Yes, so, if you wanted to see what the fields of your Shape node are, as Doug notes:

int * fieldOffsetsPtr = (int *) NODE_OFFSETS[myShape->_nodeType];


> const int OFFSETS_Material[] = {
> (int) FIELDNAMES_transparency, (int) offsetof (struct X3D_Material, transparency),  (int) FIELDTYPE_SFFloat, (int) KW_inputOutput, (int) (SPEC_VRML | SPEC_X3D30 | SPEC_X3D31 | SPEC_X3D32 | SPEC_X3D33),
> ...
> -1, -1, -1, -1, -1};
> 
> It appears to be a table of field names for Material. The -1,-1,-1,-1,-1 is obviously a sentinal value so if you are looping through fields you know when you're done.


Ok - the info for each field is grouped into groups of 5 integers.  You know when you are at the end of the fields for that node when you hit the -1, or, for readability, the macro "INT_ID_UNDEFINED"

Some fields are for internal use only, these field names will start off with an underscore. I'll go through a field here for the Shape node.

>From generated code.c:

const int OFFSETS_Shape[] = {
	...
        (int) FIELDNAMES_appearance, 
		- this is the shape "Appearance" field...

	(int) offsetof (struct X3D_Shape, appearance),  
		- offset in the structure of this field; offset is in bytes;

	(int) FIELDTYPE_SFNode, 
		- this is the type of the node; other types might be FIELDTYPE_SFInt32, etc.

	(int) KW_inputOutput,
		 - for routing, can we send and/or receive events to this node???

	 (int) (SPEC_VRML | SPEC_X3D30 | SPEC_X3D31 | SPEC_X3D32 | SPEC_X3D33),
		- if we are interested in checking, we can see if this field exists in a specific level of X3D. 
	....



> That's what the makeFIELDDEFret() appears to be doing.
> 
> /* now go through and get the name, type, keyword */
> np = NODE_OFFSETS[boxptr->_nodeType];
> while (*np != -1) {
>  if (strcmp (FIELDNAMES[*np],"_") != 0) {
>   sprintf (myline,"%s %c %s ",stringFieldType(np[0]), (char) mapFieldTypeToEAItype(np[2]), 
>    stringKeywordType(np[3]));
>   strcat (buf, myline);
>  }
>  np += 5;
> }
> 

Absolutely correct method of accessing. Note that the strcmp in the above while loop gets rid of the internal-only fields, as mentioned briefly above.

If you change the "sprintf(myLine,"  to a "printf(", you'll get the fields of the node printed out, much like you'll see in the VRML/X3D spec.
 

-----------------------------------------------------------
John A. Stewart
ale...@cr...

Network Systems and Technologies - 
        Systemes et technologies des reseaux
Communications Research Centre Canada  |  
         Centre de recherches sur les communications Canada

3701 Carling Ave.  |  3701, avenue Carling
PO Box 11490, Station H  |  CP 11490, succursale H
         Ottawa ON K2H 8S2   |  Ottawa (Ontario) K2H 8S2

http://www.crc.ca

Re: [FreeWRL] EAI documentation question

[John A. S. <ale...@cr...>]

Dave;

Good questions - thanks for posting them. Currently they are not in CVS. (Can you put a doc file into CVS and have it keep track of changes??)


> Main point:
> Who do I send this documentation to?
> Who is going to maintain this EAI protocol document in the long term?


Most of the web pages are edited by hand, but note:

	- a full review of pages with templates was being performed by our graphics people - cancelled. Sigh. So, we are stuck with the hand-edited ones, except for:

	- two documents relating to the EAI are in Microsoft format.


I have put the two microsoft doc formatted documents online, look for:

        EAI_internal_Design.doc

and

        Using_the_EAI_C_interface.doc

(of course, via web browser: http://freewrl.sf.net/EAI_internal_Design.doc, etc)

What I do with these is edit them, then export them as a web page from within Word.  Anyone with the ability to write to the freewrl web page html area can update them. 

I write these documents out as:

        FreeWRL_EAI_internal_design_and_functionality.html

and

        Using_the_EAI_C_interface.html


They of course go into the "htdocs" directory; and are available from the web as http://freewrl.sf.net/Using_the_EAI_C_interface.html

I write/read them from the web site with the command:

sftp crc_canada,fr...@we...
then "cd htdocs"

Does that help? Please feel free to go nuts on these documents, change them as you wish. 


Thanks; JohnS.

Re: [FreeWRL] FreeWRL threading

[Dave J. <dav...@go...>]

2010/5/9 Michel Briand <mic...@fr...>:
> Hi all,
>
> many texture problems are related to the thread handling in FreeWRL.
>
> I'm trying to sort out all that stuff... I'm implementing a new feature
> that makes all console outputs colored :

This is useful, for another reason:

I thought it was just me getting the xfont not initialised message due
to a misconfiguration issue on my machine, but I see you get it as
well.

Dave

Re: [FreeWRL] EAI documentation question

[Dave J. <dav...@go...>]

Thanks Doug, you have rescued me.

>From you analysis, it looks like the only real bug in makeFIELDDEFret
is the initial computation of boxptr, and the rest of the code is
working.

I will give it a shot.

Dave

On 10 May 2010 14:11, doug sanden <hig...@ho...> wrote:
>
>
>>
>> The EAI code is very dense, esp to someone to whom C is not a primary language,
>>
>> I will have no problem finding things once I know their names.
>>
>> So, given I know that the node type of a node is 76, how do I find out
>> the names of all the fields for that type of node?
>>
>
> I think your hunch about EAIEventsIn.c> makeFIELDDEFret() L 884 being relevant example code is good.
>  np = NODE_OFFSETS[boxptr->_nodeType];
> Lets say _nodeType is 76. Then we need to find an array called NODE_OFFSETS[].
> To find it I do that go-to-definition trick. It puts me on line 5114 of generatedCode.c
>
> const int *NODE_OFFSETS[] = {
>  OFFSETS_Anchor,    <<<<< this is element [0] on line 5115
>  ....
>  OFFSETS_Material,  <<<<< this is element [76] on line 5115 + 76 = 5191
>
> I do the go-to-definition trick on OFFSETS_Material and it takes me to generatedCode.c L3653
>
> const int OFFSETS_Material[] = {
>  (int) FIELDNAMES_transparency, (int) offsetof (struct X3D_Material, transparency),  (int) FIELDTYPE_SFFloat, (int) KW_inputOutput, (int) (SPEC_VRML | SPEC_X3D30 | SPEC_X3D31 | SPEC_X3D32 | SPEC_X3D33),
> ...
>  -1, -1, -1, -1, -1};
>
> It appears to be a table of field names for Material. The -1,-1,-1,-1,-1 is obviously a sentinal value so if you are looping through fields you know when you're done.
> That's what the makeFIELDDEFret() appears to be doing.
>
>  /* now go through and get the name, type, keyword */
>  np = NODE_OFFSETS[boxptr->_nodeType];
>  while (*np != -1) {
>  if (strcmp (FIELDNAMES[*np],"_") != 0) {
>   sprintf (myline,"%s %c %s ",stringFieldType(np[0]), (char) mapFieldTypeToEAItype(np[2]),
>    stringKeywordType(np[3]));
>   strcat (buf, myline);
>  }
>  np += 5;
>  }
>
> So if you don't have a working function you could make one starting with this code.
> I suspect you're the only one currently using the EAI so I think you should go for it - make it work for you.
> -D
> _________________________________________________________________
> 30 days of prizes: Hotmail makes your day easier! Enter Now.
> http://go.microsoft.com/?linkid=9729710
> _______________________________________________
> FreeWRL mailing list
> Fr...@cr...
>

Re: [FreeWRL] Code overview question > Codeblocks test

[Dave J. <dav...@go...>]

On 10 May 2010 10:10, Joerg Scheurich aka MUFTI
<rus...@he...> wrote:
>
>> Not so much looking for a tool on the programming side, rather a tool
>> like graphviz that shows the big picture. In the bad old days it would
>> have been walls covered with code listings sticky-taped to them.
>
> Walls covered with code listings have been implemented in 3D in multiuser
> chats like SUN wonderland 8-)
>
Yeah, but does it give you the same feeling as reaching up holding up
the first page from a stack of good old Z-fold paper ?
And you don't get the same size, resolution and automatic zoom features!!!

Till now, did not realise what inkjet printers had robbed us of. The
thought of trying to stick hundreds of A4 pages up individually, is
terrible.

I want a 132 column lineprinter for my birthday!

Dave

Dave

Re: [FreeWRL] EAI documentation question

[doug s. <hig...@ho...>]

>
> The EAI code is very dense, esp to someone to whom C is not a primary language,
>
> I will have no problem finding things once I know their names.
>
> So, given I know that the node type of a node is 76, how do I find out
> the names of all the fields for that type of node?
>

I think your hunch about EAIEventsIn.c> makeFIELDDEFret() L 884 being relevant example code is good.
 np = NODE_OFFSETS[boxptr->_nodeType];
Lets say _nodeType is 76. Then we need to find an array called NODE_OFFSETS[]. 
To find it I do that go-to-definition trick. It puts me on line 5114 of generatedCode.c
 
const int *NODE_OFFSETS[] = {
 OFFSETS_Anchor,    <<<<< this is element [0] on line 5115
 ....
 OFFSETS_Material,  <<<<< this is element [76] on line 5115 + 76 = 5191

I do the go-to-definition trick on OFFSETS_Material and it takes me to generatedCode.c L3653
 
const int OFFSETS_Material[] = {
 (int) FIELDNAMES_transparency, (int) offsetof (struct X3D_Material, transparency),  (int) FIELDTYPE_SFFloat, (int) KW_inputOutput, (int) (SPEC_VRML | SPEC_X3D30 | SPEC_X3D31 | SPEC_X3D32 | SPEC_X3D33),
...
 -1, -1, -1, -1, -1};

It appears to be a table of field names for Material. The -1,-1,-1,-1,-1 is obviously a sentinal value so if you are looping through fields you know when you're done.
That's what the makeFIELDDEFret() appears to be doing.
 
 /* now go through and get the name, type, keyword */
 np = NODE_OFFSETS[boxptr->_nodeType];
 while (*np != -1) {
  if (strcmp (FIELDNAMES[*np],"_") != 0) {
   sprintf (myline,"%s %c %s ",stringFieldType(np[0]), (char) mapFieldTypeToEAItype(np[2]), 
    stringKeywordType(np[3]));
   strcat (buf, myline);
  }
  np += 5;
 }

So if you don't have a working function you could make one starting with this code.
I suspect you're the only one currently using the EAI so I think you should go for it - make it work for you.
-D 		 	   		  
_________________________________________________________________
30 days of prizes: Hotmail makes your day easier! Enter Now.
http://go.microsoft.com/?linkid=9729710

Re: [FreeWRL] Code overview question > Codeblocks test

[Joerg S. a. M. <rus...@he...>]

> Not so much looking for a tool on the programming side, rather a tool
> like graphviz that shows the big picture. In the bad old days it would
> have been walls covered with code listings sticky-taped to them.

Walls covered with code listings have been implemented in 3D in multiuser
chats like SUN wonderland 8-)

so long
MUFTI
-- 
Wie Office für Mac behoben werden kann, dokumentiert langsamer erwartet als
dass, wie Office für Mac behoben werden kann, zu Öffnen
                       Knowledge Base ID:892959   Revision:2.1 

Re: [FreeWRL] Gcc question - preprocessor

[Michel B. <mic...@fr...>]

Dave Joubert <dav...@go...> - Mon, 10 May 2010 09:39:02
+0100

>Hi,
>
>I want to pick the team's brains (as usual). I have RTFMed the gcc
>manual but .....
>
>How does one persuade gcc to keep a copy of the intermediate files
>that it generates ?
>
>The files I want to look at are the one where the macros have been
>substituted and the result is a file with C code (with no macros).
>
>I want to look at the intermediate files to see exactly what the
>compiler is warning me about.
>
>Dave

Gcc, invoked through make (by libtool), does not generated those files
on disk, but rather pipes them through the next stage of the compiler
that creates object files.

If you want to look at preprocessor output do like this:

$ make V=1
....blahblahblah....
make[3]: entrant dans le répertoire « /local/wk/michel/freewrl/freewrl-1.22.8/src/lib »
depbase=`echo threads.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
        /bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../..  -Wall -Wundef -Wunused-macros    -I/usr/include/freetype2    -I/usr/include/libxml2     -I/usr/include/libpng12     -DXP_UNIX -DJS_THREADSAFE -I/usr/include/mozjs -I/usr/include/nspr         -DTARGET_MOTIF   -DSTATUSBAR_STD   -g -O0  -D_GNU_SOURCE -fno-strict-aliasing -DTEXVERBOSE -DRESVERBOSE -MT threads.lo -MD -MP -MF $depbase.Tpo -c -o threads.lo threads.c &&\
        mv -f $depbase.Tpo $depbase.Plo
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wall -Wundef -Wunused-macros -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libpng12 -DXP_UNIX -DJS_THREADSAFE -I/usr/include/mozjs -I/usr/include/nspr -DTARGET_MOTIF -DSTATUSBAR_STD -g -O0 -D_GNU_SOURCE -fno-strict-aliasing -DTEXVERBOSE -DRESVERBOSE -MT threads.lo -MD -MP -MF .deps/threads.Tpo -c threads.c  -fPIC -DPIC -o .libs/threads.o
....blahblahblah....

Pick up the command line after "compile:" and replace "-c" by "-E"
which means "do not compile an object file but preprocess it only" and
replace "-o target.o" by "-o target.E". Conventionnaly .E stands for
"preprocessed C".

Cheers,
Michel

[FreeWRL] Gcc question - preprocessor

[Dave J. <dav...@go...>]

Hi,

I want to pick the team's brains (as usual). I have RTFMed the gcc
manual but .....

How does one persuade gcc to keep a copy of the intermediate files
that it generates ?

The files I want to look at are the one where the macros have been
substituted and the result is a file with C code (with no macros).

I want to look at the intermediate files to see exactly what the
compiler is warning me about.

Dave

Re: [FreeWRL] Code overview question > Codeblocks test

[Joerg S. a. M. <rus...@he...>]

> build system is central to our efficiency, and if we could have an
> unique one (managed under version control :)...) that'd be great.

Such unique build systems are built on top of the other tools like "qmake"
for qt. AFAIK "cmake" is another one.
But i never saw one, that is simple, efficent, self declaring and working 
without problems like "make" itself. 
Before giving up "make" und using scrap like "qmake" i personally prefer
to use indirect ways for the other tools.

so long
MUFTI
-- 
Wie Office für Mac behoben werden kann, dokumentiert langsamer erwartet als
dass, wie Office für Mac behoben werden kann, zu Öffnen
                       Knowledge Base ID:892959   Revision:2.1