[x3d-public] Sample X3D Python API; examplespublishedforcontinuing improvement

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Mon Apr 22 22:49:52 PDT 2019


Thanks for look at all this John.  Here are some touchpoints.

- Do not use abstract classes.
- Do not provide references to abstract classes (X3D*Node, X3D*Object) in any of your mappings.
- Do not provide references to the .sai.* package, they too are all abstract interfaces with no concrete classes.

Next:
- quit worrying about autogeneration for a while.  That is what i was trying to say before.. just get the mapping right for HelloWorld.py
- once we have patterns that work for HelloWorld, and only then, do we worry about autogeneration of everything.
- steer far clear of prototypes and special edge cases until we have the basics working for HelloWorld.  They really don't matter in comparison, any solution to that is pointless if we can't do Shapes well.
- our goal is _not_ to choose between one .py or .future.py python style or another, rather get them both working compatibly just like we did in Java.

Further relaxations:
- we are not trying to re-implement all of X3DJSAIL, or all of the abstract interfaces provided in Java,
- we are simply trying to come up with a working syntax for X3D language binding to python, that is the goal.


On 4/22/2019 10:11 PM, John Carlson wrote:
> Do you plan on removing X3D*Node.class from the X3DJSAIL jar?  This is far too much work and is leading in the WRONG direction. If I don’t import the class in Python application, I’m not using it, as far as I know. I will try to mess with leaving out the from in the import for each class at some point, and just use import as if that sounds like a good plan.
> 
> Set you teeth on this problem, which I can’t solve, last I checked (found in pyjnius folder):
> 
> $ python abox.future.py
> 
> Traceback (most recent call last):
> 
>    File "abox.future.py", line 64, in <module>
> 
>      .setProtoField(SFString("myShape")) \
> 
>    File "jnius\jnius_export_class.pxi", line 760, in jnius.JavaMethod.__call__
> 
>    File "jnius\jnius_conversion.pxi", line 78, in jnius.populate_args
> 
>    File "jnius\jnius_utils.pxi", line 205, in jnius.check_assignable_from
> 
> jnius.JavaException: Invalid instance of 'org/web3d/x3d/jsail/X3DConcreteNode' passed for a 'org/web3d/x3d/sai/Core/X3DNode'
> 
> Make sure your up to date with the latest org version (does not use  X3Dautoclass.py).
> 
> John
> 
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
> 
> *From: *Brutzman, Donald (Don) (CIV) <mailto:brutzman at nps.edu>
> *Sent: *Monday, April 22, 2019 10:57 PM
> *To: *John Carlson <mailto:yottzumm at gmail.com>
> *Cc: *X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] Sample X3D Python API; examplespublishedforcontinuing improvement
> 
> Our messages crossed but are quite similar... we might have the problem surrounded I hope...
> 
> On 4/22/2019 8:45 PM, John Carlson wrote:
> 
>  > This is a more broad problem than pyjnius, and is likely a Java problem that is letting things past the interface contract.  Okay, I will try to explain what the bug is:
> 
>  >
> 
>  > setDEF in X3DViewpointNode returns an X3DViewpointNode (interface)
> 
>  >
> 
>  > public X3DViewpointNode setDEF(String newValue);
> 
> [...]
> 
> Please make sure that you have _no_ references to abstract class X3DViewpointNode anywhere in your code.
> 
> The Java source for concrete class ViewpointObject specifically overrides its abstract parent superclass with an @Override annotation.  Inside X3DJSAIL the setDEF() method correctly returns type ViewpointObject.
> 
> If we remove all references to X3D*Node abstract classes everywhere and the problem still occurs, then
> 
> - perhaps not all of those definitions are removed, or
> 
> - perhaps an old file in the path is somehow visible, or
> 
> - we have isolated a bug in Pyjnius that we can ask them to fix.
> 
> Good luck sir.
> 
> 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
> 


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


More information about the x3d-public mailing list