[x3d-public] Results for today with x3d.py, _X3DField
John Carlson
yottzumm at gmail.com
Wed Dec 8 18:49:27 PST 2021
Slept all day. I probably will have some time tonight.
On Wed, Dec 8, 2021 at 9:59 AM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> We’re up to 4.0.45 now, propagated.
>
>
>
> The way to test is to
>
> 1. look at the examples and find a flaw
> 2. then try to deduce cause of flaw,
> 3. then find offending block in x3d.py and consider fix, possibly
> testing locally
> 4. then confirm whether or not this is part of a recursive pattern (as
> are all the exports)
> 5. then I apply corrected code pattern in the autogenerator for X3DUOM
> to x3d.py
>
>
>
> First steps are most important. I recommend not trying to fix any of the
> export recursion patterns, it requires close debugging across
> autogeneration/inspection/debugging/generation with version-control
> comparison throughout.
>
>
>
> 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 https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* John Carlson <yottzumm at gmail.com>
> *Sent:* Monday, December 6, 2021 12:27 AM
> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>;
> vmarchetti at kshell.com
> *Cc:* X3D-Public <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] Results for today with x3d.py, _X3DField
>
>
>
> NPS WARNING: *external sender* verify before acting.
>
>
>
> Apparently the package/module hasn't propagated yet, because it said I had
> 4.0.43 up-to-date. But I got x3d.py from sourceforge:
>
> The follow diff allowed me to export JSON as found in a previous
> attachment. Perhaps we should add indent and syntaxs to all JSON def
> methods? Also, the str I adding I think prints out NoneType...not desired
> in JSON, perhaps we need to throw an exception? if each.JSON() returns None
> or NoneType? I will review particulars you have changed.
>
> $ diff /c/x3d-code/www.web3d.org/x3d/stylesheets/python/x3d.py x3d.py
> 12286c12286
> < result += each.JSON(indentLevel=indentLevel+1,
> syntax=syntax)
> ---
> > result += str(each.JSON())
> 42390c42390
> < result += each.JSON(indentLevel=indentLevel+1,
> syntax=syntax)
> ---
> > result += each.JSON()
> 77395c77395
> < result += self.geometry.JSON(indentLevel=indentLevel+1,
> syntax=syntax)
> ---
> > result += self.geometry.JSON()
> 89045c89045
> < result += each.JSON(indentLevel=indentLevel+1,
> syntax=syntax)
> ---
> > result += each.JSON()
>
> On 12/6/21 00:36, Brutzman, Donald (Don) (CIV) wrote:
>
> I think it cleaned up OK. Changes tested and checked in, now version
> 4.0.44 on PyPi.
>
>
>
> 1. https://pypi.org/project/x3d
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpypi.org%2Fproject%2Fx3d&data=04%7C01%7Cbrutzman%40nps.edu%7Cb52539c9cf264ecdf4e808d9b8923579%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637743760828837395%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=LMPMZa6twQZYSAEc1eiWcIQyv14AtGuoZCYns8ROHm4%3D&reserved=0>
>
>
>
> 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 https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> <brutzman at nps.edu>
> *Sent:* Sunday, December 5, 2021 10:09 PM
> *To:* vmarchetti at kshell.com; John Carlson <yottzumm at gmail.com>
> <yottzumm at gmail.com>
> *Cc:* X3D-Public <x3d-public at web3d.org> <x3d-public at web3d.org>; Brutzman,
> Donald (Don) (CIV) <brutzman at nps.edu> <brutzman at nps.edu>
> *Subject:* RE: [x3d-public] Results for today with x3d.py, _X3DField
>
>
>
> Thanks for reports and correct diagnosis. I did take out the three
> “object” inheritances earlier today, pylint says it is no longer required
> in Python 3, no ill effects noted.
>
>
>
> I have tried to follow X3D4 Architecture exactly, and am keen to avoid
> overwriting! Hopefully tonight’s build looks a bit better.
>
>
>
> The specification does not show X3DField inheriting from anything.
>
>
>
> 1. X3D4 Architecture, 5.2.3 X3DField
> 2.
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/fieldTypes.html#X3DField
>
>
>
> 1. X3D4 Architecture, 54.4.2.3 Interface hierarchy
> 2. (looks like first line of Figure 4.2 needs more whitespace)
> 3.
> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#InterfaceHierarchy
>
>
>
> Sure enough, searching for “class _ X3DField” in x3d.py reveals two
> abstract class definitions, ouch! That’s more like multiple personalities
> that multiple inheritance…
>
>
>
> Will work on fixing the autogeneration of offending version.
>
>
>
> 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 https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* vmarchetti at kshell.com <vmarchetti at kshell.com>
> *Sent:* Sunday, December 5, 2021 3:59 AM
> *To:* John Carlson <yottzumm at gmail.com>
> *Cc:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>; X3D-Public <
> x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] Results for today with x3d.py, _X3DField
>
>
>
> Python does support multiple inheritance, but these fragments are not an
> example of a multiple-inheritance situation -- rather, the later class
> definition -- where _X3DField is a subclass of _X3DNode, overwrites the
> earlier class definition.
>
>
>
> In the x3d.py file, only three classes are defined as direct subclasses of
> object:
>
>
>
> class _X3DField
>
> class _X3DNode
>
> class _X3DStatement
>
>
>
> So I think the operative question is whether it is a design intent that
> _X3DField also should be a subclass of _X3DNode. I judge the answer is no,
> since that would include support for DEF, USE, and metadata. In that light,
> the second class defintion for _X3DField would be regarded as a bug, to be
> corrected by modifying the X3duomToX3dPythonPackage.xslt stylesheet.
>
>
>
> On Dec 4, 2021, at 11:40 PM, John Carlson <yottzumm at gmail.com> wrote:
>
>
>
> Two declarations of _X3DField?
>
> $ grep "class _X3DField" x3d.py
>
>
>
> *class _X3DField*(object):
>
> *class _X3DField*(_X3DNode):
>
> Is there a pylint?
>
> Isn't multiple inheritance possible?
>
> Thanks!
>
> John
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20211208/8cfcc8bc/attachment-0001.html>
More information about the x3d-public
mailing list