[x3d-public] X3D meeting minutes 20 AUG 2021, C C++ C# and Mantis
John Carlson
yottzumm at gmail.com
Mon Aug 30 22:41:17 PDT 2021
Note: I'm more used to Chrome behavior, getting used to Firefox.
John
On 8/31/21 12:37 AM, John Carlson wrote:
>
> Note, you'll have to log into GitHub first. I would go to the main
> github page to login, not somewhere I send you, because there's
> credential stealing happening.
>
> On 8/31/21 12:30 AM, John Carlson wrote:
>>
>> Examples from Dr. Lee's work here (My private repo, NOT THE MAIN X3D
>> STANDARDS REPO. This repo may go away soon):
>>
>> https://github.com/coderextreme/X3D/tree/master/ISO-IEC19777/ISO-IEC19777-4/ISO-IEC19777-4v3.3/ISO-IEC%2019777-4%20V3.3%20WD/Part04/Examples
>>
>> https://github.com/coderextreme/X3D/tree/master/ISO-IEC19777/ISO-IEC19777-3/ISO-IEC19777-3v3.3/ISO-IEC%2019777-3%20V3.3%20WD/Part03/Examples
>>
>> https://github.com/coderextreme/X3D/tree/master/ISO-IEC19777/ISO-IEC19777-5/ISO-IEC19777-5v3.3/ISO-IEC%2019777-5%20V3.3%20WD/Part05/Examples
>>
>> (these do no include the .h files from the WD, go up a level and look
>> at abstracts.html and concretes.html)
>>
>> I've used importer/exporters on one Java project. They weren't
>> perfect, thus I am looking for a preferred idea.
>>
>> Please examine! Should we also discuss in a meeting with someone
>> taking notes?
>>
>> I'm going to start examine the C WD a bit.
>>
>> 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/f18a46f6/attachment-0001.html>
More information about the x3d-public
mailing list