[x3d-public] X3D meeting minutes 20 AUG 2021, C C++ C# and Mantis

John Carlson yottzumm at gmail.com
Mon Aug 30 23:03:13 PDT 2021

Basically, we have 2 approaches to programming:  Java, which uses 
setters and adders on a constructed node (the constructor has 
no-parameters...the Java default constructor), and Python, which shoves 
everything into the constructor parameters.  I suspect that many 
decisions may depend on performance in the longer term.  It's good to be 
flexible with the SAI and the SAI examples--code generate and round-trip.

I know one can initialize data members in a constructor call in C++, 
which might be another flavor of programming.

I believe that Java is becoming a bit more flexible about named 
parameters instead of positional parameters, but I'm pretty much a noob 
about that.

For Java builder pattern (simulating named parameters), see: 

I'm not sure if we're looking for alternate Java builders at this point.


On 8/30/21 11:51 PM, Brutzman, Donald (Don) (CIV) wrote:
> I expect that the majority of your points below will be answered when 
> we start looking at examples. Much easier then to compare alternatives.
> v/r Don
> *From: *John Carlson <mailto:yottzumm at gmail.com>
> *Sent: *Monday, August 30, 2021 9:48 PM
> *To: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Cc: *Myeong Won Lee <mailto:myeongwonlee at gmail.com>; Nicholas Polys 
> <mailto:npolys at vt.edu>; Richard F. Puk <mailto:puk at igraphics.com>; 
> x3d-public at web3d.org <mailto:x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] X3D meeting minutes 20 AUG 2021, C C++ C# 
> and Mantis
> Agreed on developing setters and getters for patterns previously 
> discussed on the subject.   That is, we have setters provided for 
> construction (import) of an object passed to the constructor.   At 
> that point, the object constructed by should be encapsulated. Only 
> methods passed an exporter may extract data from the constructed object.
> But OO may be a bit passé these days? I don’t know how to achieve such 
> a thing in the C SAI, but I need to look.   I was told by a patterns 
> guy that setters and getters were used for legacy systems???
> The idea of the importer/exporter pattern is to provide a class 
> hierarchy of importers:  VRMLImporter, XMLImporter, JSONImporter, 
> GenericImporter and similarly, a class hierarchy for Exporters.   
> While building such classes by hand is numbingly difficult,  I feel 
> with code generation from X3DUOM, the task could be relatively easy.  
> Again, I have not done something like this in C.
> Discussion and better solutions appreciated!
> Examples especially helpful!
> Yes, I know about JavaBeans and POJOs.
> I’m all for being overruled.  Show me something the achieves 
> encapsulation better.   I know about accessType on fields.   Is this 
> how we design the encapsulation?
> The reference I would use for Importer/exporter is “Holub on Patterns.”
> John
> On Mon, Aug 30, 2021 at 10:54 PM Brutzman, Donald (Don) (CIV) 
> <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>     John, thanks for excellent progress.  Apologies that I was unable
>     to meet today.
>     I think it is prudent for us to check in the current master copy
>     provided by Dr. Lee so that we have a baseline.  Any subsequent
>     changes will be discernible via diff comparisons.
>     Recommend that we intentionally _/not/_ look at Script nodes for a
>     while.
>      1. First we have to make sure that basic nodes (parent-children
>         relationships) and simple fields are represented
>         satisfactorily, with intuitive accessors (get and set methods.
>      2. Then look at statements.
>      3. Then look at <field> definitions, usable by both prototypes
>         and scripts.
>      4. Then contained script code within a script node (similarly for
>         shader nodes).
>      5. Then simple prototype declarations.
>      6. Then more-complex prototype declarations with IS/connect and
>         embedded Script nodes.
>     We have plenty of examples to work with.  Going from simplest
>     towards more complex (a..f above) will help us maintain clarity
>     throughout.
>     Looking forward to meeting sometime and pursuing next steps.
>     v/r Don
>     *From: *John Carlson <mailto:yottzumm at gmail.com>
>     *Sent: *Monday, August 30, 2021 6:31 PM
>     *To: *Myeong Won Lee <mailto:myeongwonlee at gmail.com>; Richard F.
>     Puk <mailto:puk at igraphics.com>
>     *Cc: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>;
>     Nicholas Polys <mailto:npolys at vt.edu>; x3d-public at web3d.org
>     <mailto:x3d-public at web3d.org>
>     *Subject: *Re: [x3d-public] X3D meeting minutes 20 AUG 2021, C C++
>     C# and Mantis MetadataDate
>     Don suggested a meeting for checking in the new 19777-{3,4,5}
>     working drafts.   If people are interested, send me times when you
>     are available.   Dick, Don, since you are the maintainers, one of
>     you should be there—I think the Mantis currently says Don.  
>     Myeong or I can make zips available.   I think they may be checked
>     into my repository.
>     I do not know if more review time is necessary before checking in?
>       I for one have not done much reviewing beyond structure.   One
>     may want to search through the folders to see if the string “Java”
>     is found within the c/c++/c# working draft files.   That is, do an
>     explorer and/or grep search.
>     From what I saw of the .h files, it looks quite excellent.   We
>     can start with any code generation.   If Myeong doesn’t give us
>     the .h files and we can’t otherwise scrape the HTML or WD, perhaps
>     code generation of SAI from X3DUOM is indicated?   We have done
>     this for Python and Java.   I don’t know if Myeong is code
>     generating the .h code or not.  I’ve laid out a couple of
>     scenarios for stylesheets, but I have not worked on making these a
>     reality yet. It would probably be good for me to lay out the
>     alternatives in a presentation so we can choose a path forward
>     which is most maintainable for second and third parties.
>     Nicholas, does your team intend to provide a full library beyond
>     the interface?   If so, will they be working on an implementation
>     stylesheet?   I guess in C/C++ the interface is separate from the
>     implementation, so it would be possible to have coordinated
>     implementation?
>     Could someone who has used Script nodes with c,c++,c# fill me in
>     on how to do it?
>     John
>     On Fri, Aug 27, 2021 at 8:50 AM Myeong Won Lee
>     <myeongwonlee at gmail.com <mailto:myeongwonlee at gmail.com>> wrote:
>         Dear John,
>         Thank you for your efforts in setting up the GitHub repository.
>         In the folders, I think that the "CD" folders may not be
>         necessary because we have restarted with WDs and the CDs are
>         old versions of the WDs.
>         I submitted the CDs last year, but they were not approved as
>         CD texts, and so I resubmitted them as WDs.
>         We should work on the WD texts.
>         How about deleting the CD folders?
>         In addition, if WD-originals are old versions, it would be OK
>         to delete them.
>         In summary, I think that the folders should be as follows:
>         ./ISO-IEC19777/ISO-IEC19777-3/ISO-IEC19777-3v3.3-WD
>         ./ISO-IEC19777/ISO-IEC19777-4/ISO-IEC19777-4v3.3-WD
>         ./ISO-IEC19777/ISO-IEC19777-5/ISO-IEC19777-5v3.3-WD
>         Sincerely,
>         Myeong
>         On Fri, Aug 27, 2021 at 6:30 AM John Carlson
>         <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>             Myeong,
>             Thanks for your efforts on the C/C#/C++ standards!
>             My understanding from Don is that we want the current WD
>             versions of the 19777-3, 19777-4 and 19777-5 standards
>             checked into GitHub, somewhere below this folder:
>             https://github.com/Web3DConsortium/X3D
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWeb3DConsortium%2FX3D&data=04%7C01%7Cbrutzman%40nps.edu%7C95c6f67a2e7f4b8a26d208d96c3a566f%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659820991840016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=knYg5J%2FS98UehWbGirNdgLSHd4Jvcvlcwqpvlq81Oys%3D&reserved=0>
>             (If you need assistance, let me know, it's quite
>             confusing. We'll probably have to do things like rename
>             the folders once unpacked from the zips and move them
>             from).  Issues with the standards should go into Mantis.
>             Google Drive/Docs, while important for private sharing,
>             are not suitable for group editing of standards.   GitHub
>             has adequate protections in the X3D repository.  With your
>             permission, I will check your Google shared zips into
>             GitHub unpacked. Probably in the folders here that you
>             identify:
>             ./ISO-IEC19777/ISO-IEC19777-4/ISO-IEC19777-4v3.3/ISO-IEC19777-4v3.3-WD
>             ./ISO-IEC19777/ISO-IEC19777-4/ISO-IEC19777-4v3.3/ISO-IEC19777-4v3.3-CD
>             ./ISO-IEC19777/ISO-IEC19777-3/ISO-IEC19777-3v3.3/ISO-IEC19777-3v3.3-CD
>             ./ISO-IEC19777/ISO-IEC19777-3/ISO-IEC19777-3v3.3/ISO-IEC19777-3v3.3-WD
>             ./ISO-IEC19777/ISO-IEC19777-5/ISO-IEC19777-5v3.3/ISO-IEC19777-5v3.3-CD
>             ./ISO-IEC19777/ISO-IEC19777-5/ISO-IEC19777-5v3.3/ISO-IEC19777-5v3.3-WD
>             ( Please confirm that the WD folders are correct).
>             These are the original folders that where already there
>             that are moved out of the way.
>             ./ISO-IEC19777-4/ISO-IEC19777-4v3.3/ISO-IEC19777-4v3.3-WD-original
>             ./ISO-IEC19777-3/ISO-IEC19777-3v3.3/ISO-IEC19777-3v3.3-WD-original
>             ./ISO-IEC19777-5/ISO-IEC19777-5v3.3/ISO-IEC19777-5v3.3-WD-original
>             I currently all these changes ready for a git add, commit,
>             push.  I have done 1) ready and a little bit of aiming.  I
>             need approval to fire.
>             I will enter a Mantis ticket for these changes.
>             ===========================================================
>             Secondly, according to Don, we need to move discussions to
>             the x3d-public mailing list.  If issues are sensitive,
>             then there's the x3d mailing list.  Here's how to
>             subscribe to x3d-public:
>             http://www.web3d.org/mailman/listinfo/x3d-public_web3d.org
>             <http://www.web3d.org/mailman/listinfo/x3d-public_web3d.org>
>             Issues with source code artifacts should be can be
>             recorded here: https://sourceforge.net/p/x3d/discussion/
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fx3d%2Fdiscussion%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C95c6f67a2e7f4b8a26d208d96c3a566f%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659820991849986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tyJHTE6gp4JZXciuX8Qa4VSw4jedCabAnzug6ArR7qc%3D&reserved=0>
>             Source code artifacts should go here in addition:
>             https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/languages/
>             <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceforge.net%2Fp%2Fx3d%2Fcode%2FHEAD%2Ftree%2Fwww.web3d.org%2Fx3d%2Flanguages%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C95c6f67a2e7f4b8a26d208d96c3a566f%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659820991849986%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=EMsac3BZDxkqddC2puA1cn797xspzZ1h7mxZWUk6p4U%3D&reserved=0>
>             I can facilitate uploads to there.  Myeong, with your
>             permission, I will archive the old code (many months old)
>             to "legacy" under the main x3d-code folder.
>             If you have any open questions, please post to the
>             x3d-public list (respond to this email).
>             I don't believe source code changes require Mantis.
>             John
>             On 8/26/21 9:34 AM, Brutzman, Donald (Don) (CIV) wrote:
>                 Again: it would be useful to have to have a design
>                 page that discussed programming patterns and open issues.
>                 Again: GitHub is master version, being aware that
>                 differences exist but are not identified isn’t very
>                 useful.
>                 Again: Hoping we can “get on the good foot” in how
>                 this effort is pursued.  This is how the Java, JSON,
>                 Python and Turtle language bindings built towards
>                 consensus and were all successfully accomplished.
>                 Thanks for all efforts, hopefully they can become
>                 productive and fruitful by working deliberately together.
>                 all the best, Don
>                 -- 
>                 Don Brutzman  Naval Postgraduate School, Code USW/Br
>                 brutzman at nps.edu <mailto:brutzman at nps.edu>
>                 Watkins 270,  MOVES Institute, Monterey CA 93943-5000
>                 USA +1.831.656.2149
>                 X3D graphics, virtual worlds, navy robotics
>                 http://faculty.nps.edu/brutzman
>                 <http://faculty.nps.edu/brutzman>
>                 *From: *John Carlson <mailto:yottzumm at gmail.com>
>                 *Sent: *Friday, August 20, 2021 12:36 PM
>                 *To: *Brutzman, Donald (Don) (CIV)
>                 <mailto:brutzman at nps.edu>; x3d-public at web3d.org
>                 <mailto:x3d-public at web3d.org>; Myeong Won Lee
>                 <mailto:myeongwonlee at gmail.com>; GPU Group
>                 <mailto:gpugroup at gmail.com>
>                 *Subject: *Re: [x3d-public] X3D meeting minutes 20 AUG
>                 2021, C C++ C# and Mantis MetadataDate
>                 NPS WARNING: *external sender* verify before acting.
>                 Don, Myeong, Doug,
>                 I noticed that there are no virtual methods in the C++
>                 spec SAI I got (examples, yes, except for
>                 ~SAIExample5()) on drive.google.com
>                 <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdrive.google.com%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C95c6f67a2e7f4b8a26d208d96c3a566f%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659820991859939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=H7KoA5KR1NhoNyZuaD3ss6WgNMCgMuXbPKXFkWKUceg%3D&reserved=0>. 
>                 I do not think they are necessary, but may be useful
>                 when defining subclasses for people who want to
>                 subclass from the SAI abstract and concrete nodes.
>                 https://www.geeksforgeeks.org/virtual-function-cpp/
>                 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.geeksforgeeks.org%2Fvirtual-function-cpp%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C95c6f67a2e7f4b8a26d208d96c3a566f%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659820991859939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Yf43CPlzZjd7dCEo%2Bbi01NMwzwux6W%2BB5QQvtN%2BV8cM%3D&reserved=0>
>                 Note that most methods are virtual in Java, without
>                 the keyword.  I think virtual methods are slower than
>                 regular methods, last I heard.  But I'm pretty sure
>                 all destructors should be virtual?  I've forgotten.
>                 Some discussion whether destructors should be present
>                 in the spec is welcome. The virtual destructor ensures
>                 that the superclass destructor is not called.
>                 I think it would be useful to have Doug Sanden review
>                 the abstract and concrete class and structs before
>                 making big decisions.
>                 I am also unsure why the first parameter to many C
>                 function pointer declarations is void* instead of
>                 passing a pointer to a struct type?
>                 In all cases, C/C++/C# it might be useful for setter
>                 functions and members to return this or *this, instead
>                 of void.   We need set functions to return this for
>                 creating builders I'm fairly sure. (In C SAI, the
>                 first parameter is called this, it's not a keyword
>                 that I know of).
>                 I'm glad I am reviewing this!  We'll see if anything
>                 else pops into my head after I send the message!
>                 Thanks,
>                 John
>                 On 8/20/21 1:46 PM, Brutzman, Donald (Don) (CIV) wrote:
>                     Attendees John Carlson, Vince Marchetti, Dick Puk,
>                     Don Brutzman
>                     1.Very useful discussion today, we reviewed
>                     proposed language bindings
>                      1. 19755- 3, C
>                      2. 19755- 4, C++
>                      3. 19755- 5, C#
>                     We discussed whether special treatment is deserved
>                     for exposing these draft specifications.  22 Web3D
>                     members have access to them now.
>                     Language bindings need compilable interfaces for
>                     ISO, and at least two implementations for Web3D.
>                     Close inspection of each shows that a handful of
>                     example programs are available for test
>                     development, and could be used as basis for
>                     X3dToCCppCsharp.xslt conversion stylesheet.
>                     Close inspection of detailed abstract interfaces,
>                     and detailed node/statement implementations for
>                     libraries are available (with some omissions).
>                     Each appears quite similar to the others.
>                     Regeneration via X3DUOM of compilable “header” or
>                     interface files matching the source code in the
>                     HTML is possible.
>                     C and C++ language compilation is easily possible
>                     using gcc compiler.  Compilation of C# is not so
>                     clear, some open-source implementations are
>                     available.  Once initial compilation of headers is
>                     accomplished, further scrutiny and possible
>                     evolution of design patterns would be
>                     straightforward.  We’ll use gcc on the next round
>                     since it is part of our build infrastructure already.
>                      1. GCC, the GNU Compiler Collection
>                         https://gcc.gnu.org
>                         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2F&data=04%7C01%7Cbrutzman%40nps.edu%7C95c6f67a2e7f4b8a26d208d96c3a566f%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659820991869895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=0oGTDshBBVtMPtuLqa%2F4Gfnhe2H2oPC8b%2BGg26%2F%2BuQg%3D&reserved=0>
>                      2. https://stackoverflow.com/questions/26078437/why-does-gcc-support-java-and-not-c-sharp
>                         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstackoverflow.com%2Fquestions%2F26078437%2Fwhy-does-gcc-support-java-and-not-c-sharp&data=04%7C01%7Cbrutzman%40nps.edu%7C95c6f67a2e7f4b8a26d208d96c3a566f%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659820991869895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=skNdk%2FZhWnvHUXUQkMj2N6By1Ug2sDhI%2BL0%2BOufPDLg%3D&reserved=0>
>                     We have enough that immediate sharing of shared
>                     specifications can be deferred until broader
>                     discussion is warranted. Sharing of generated code
>                     will help, and that does not have to be restricted.
>                     We are concerned about personnel availability, but
>                     will keep working on it step by step.
>                     We will welcome all help and participation as the
>                     work proceeds.
>                     2.Mantis issue progress is persevering steadily
>                     each week.
>                     1.Mantis 1218 for creating a MetadataDate or
>                     MetadataTime node needs to be deferred to X3D4.1.
>                     Meanwhile we might an example scene demonstrating
>                     how to do such representations with existing
>                     nodes, workably across all forms of X3D. E.g.
>                     pseudocode examples:
>                     <MetadataDouble name=”time”
>                                      value=“0.0” reference=”Unix
>                     reference of time with start at 1 JAN 1970”/>
>                     <MetadataString   name=”TuesdayLunch”
>                     value=“24-AUG-2021-1200-pacific” reference=”XSD,
>                     XML Schema Definition”/> <MetadataString
>                       name=”ThankGoodnessItsMonday”
>                     value=“23-AUG-2021-1200-pacific” reference=”ISO
>                     8601 Time standard”/>
>                     Any scene of examples would be fully detailed and
>                     cross-referenced for clarity.
>                     Mantis 1218: 07.2.4 MetadataDate - New node type,
>                     or new data type
>                     https://www.web3d.org/member-only/mantis/view.php?id=1218
>                     <https://www.web3d.org/member-only/mantis/view.php?id=1218>
>                     2.Other mantis issues are being fixed and
>                     addresses each week. Membership has value.
>                     https://www.web3d.org/member-only/mantis/view_all_bug_page.php
>                     <https://www.web3d.org/member-only/mantis/view_all_bug_page.php>
>                     Thanks everyone for a worthy effort today.  Have
>                     fun with X3D!  8)
>                     *From:* Brutzman, Donald (Don) (CIV)
>                     *Sent:* Friday, August 20, 2021 12:27 AM
>                     *To:* x3d-public at web3d.org
>                     <mailto:x3d-public at web3d.org>
>                     *Cc:* Brutzman, Donald (Don) (CIV)
>                     <brutzman at nps.edu> <mailto:brutzman at nps.edu>
>                     *Subject:* X3D meeting agenda 20 AUG 2021, C C++
>                     C# and Mantis
>                     Regular weekly call once again this week, Friday
>                     10-1100 Pacific on Web3D conference line.
>                     We will review our approach to C C++ C# encodings
>                     and also ongoing Mantis progress.  Additional
>                     topics welcome.
>                     all the best, Don
>                     -- 
>                     Don Brutzman  Naval Postgraduate School, Code
>                     USW/Br brutzman at nps.edu <mailto:brutzman at nps.edu>
>                     Watkins 270,  MOVES Institute, Monterey CA
>                     93943-5000 USA   +1.831.656.2149
>                     X3D graphics, virtual worlds, navy robotics
>                     http://faculty.nps.edu/brutzman
>                     <http://faculty.nps.edu/brutzman>
>                     _______________________________________________
>                     x3d-public mailing list
>                     x3d-public at web3d.org  <mailto:x3d-public at web3d.org>
>                 http://web3d.org/mailman/listinfo/x3d-public_web3d.org  <http://web3d.org/mailman/listinfo/x3d-public_web3d.org>
>         -- 
>     Myeong Won Lee, PhD, Professor
>     Faculty of Computer Science, U. of Suwon
>     Hwaseong, Gyeonggi-do, 18323 Korea
>     E-mail) myeongwonlee at gmail.com <mailto:myeongwonlee at gmail.com>,
>     mwlee at suwon.ac.kr <mailto:mwlee at suwon.ac.kr>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210831/7cbaa6f9/attachment-0001.html>

More information about the x3d-public mailing list