[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:
https://stackoverflow.com/questions/1988016/named-parameter-idiom-in-java
I'm not sure if we're looking for alternate Java builders at this point.
John
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