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

John Carlson yottzumm at gmail.com
Wed Sep 1 15:05:18 PDT 2021


Perhaps it would be good to express what products and standards we want 
out of the C, C++, C# work initiative.  That is, define IDE tools such 
as JavaScript or XSLT for Scripts, and Python or XSLT for SAI?

     * I see 1 to 3 products for SAI to generate SAI libraries for each 
language

     * I see 1 to 3 products for each language for generating script 
examples

     * Do we need 2 independent implementations?

I don't really mind if we choose 1 or 3, we just want to simplify 
maintenance for the long term, X3DV4, X3DV4.1, 5, 6, etc.  What will 
allow us to also support more languages like Rust, Kotlin, Scala, 
Groovy, ECMAScript, TypeScript, etc.

If we're supporting a full-on compiler framework for X3D, let's do it 
the right way and following i18n, l10n, and a11y industry practices.  I 
think the way people currently approach things with i18n and l10n are 
the "right way" and I think that a11y may fall under that.

I am of two minds.  Either we build it all ourselves (nice for knowledge 
of implementation), or we use existing tools and adopt them.  I think 
you said gcc is a good tool.  I think you meant good for compiling our 
products.  I'm more concerned about developing a compiler framework, and 
whether we should naturally latch onto gcc to develop our transformers, 
transpilers and translators.  If you haven't looked at ANTLR 4, there's 
probably a good video.  The problem is the main maintainer has moved on 
to other things.

I need to dig into NPM packages xmldom and xml2js a bit, to see if we 
can port our tools from Python to JavaScript.

John

On 8/30/21 10:54 PM, Brutzman, Donald (Don) (CIV) 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%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
>         <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 <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%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
>                 <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/20210901/9809a7aa/attachment-0001.html>


More information about the x3d-public mailing list