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

Mon Aug 30 21:46:33 PDT 2021

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> 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 <yottzumm at gmail.com>
> *Sent: *Monday, August 30, 2021 6:31 PM
> *To: *Myeong Won Lee <myeongwonlee at gmail.com>; Richard F. Puk
> <puk at igraphics.com>
> *Cc: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; Nicholas Polys
> <npolys at vt.edu>; 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>
> 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> 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%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854783384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FdxJ0uvHzdL0trwWw7PmZjS8gh5hhYQ5hmX0N3ZVGss%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
>
> 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%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854783384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=a2kbNlGgRnfyzq2vIRTCskJZJ86AIkW4FjlWvGDuh7s%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%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854793322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Ia6pbyNz4IS4sNkF5Z0nBhmjoaMTARX6RRfivxzGKdY%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
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
>
>
> *From: *John Carlson <yottzumm at gmail.com>
> *Sent: *Friday, August 20, 2021 12:36 PM
> *To: *Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>;
> x3d-public at web3d.org; Myeong Won Lee <myeongwonlee at gmail.com>; GPU Group
> <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%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854793322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8tYOmA5FuhO9WJVbL6hWoq4FYDLei3F7ow9hWLLMdf0%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%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854803280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cMJMC%2FwdzHqgHMa%2BChxhHJFHfqeoG0AXx3mgJdvov6E%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%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854803280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=aX4r%2FxVhW3U%2BqomrVVvztrz8zCv9bLLa7cA3ny3Cry0%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%7C5c8fa760fe724ed4a28708d96c1ed524%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637659702854813255%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=UadYVe93UvlWPFaN9Z4Ez19GcEIZeDcVtCLNpVrtwyk%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
>
>
>
> 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
>
>
>
> 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
> *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> <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
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
>
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
>
>
>
>
> _______________________________________________
>
> x3d-public mailing list
>
> x3d-public at 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, mwlee at suwon.ac.kr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20210830/61c8e0a6/attachment-0001.html>