[x3d-public] X3DPSAIL no need to wrap simple types; PyJNIus issues isolated; work next on native Python package

[John Carlson]

After removing SFNode, MFNode:

$ python HelloWorld.future.py
Traceback (most recent call last):
  File "HelloWorld.future.py", line 36, in <module>
    .addChild(x3d.Viewpoint().setDEF("ViewUpClose").setCenterOfRotation([0,-1,0]).setDescription("Hello world!").setPosition([0,-1,7]))
AttributeError: 'org.web3d.x3d.jsail.X3DConcreteNode' object has no attribute 'setCenterOfRotation'

coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/www.web3d.org/x3d/stylesheets/java/src/python/pyjnius
$ grep Node HelloWorld.future.py

coderextreme at DESKTOP-DOPK2VD MINGW64 /c/x3d-code/www.web3d.org/x3d/stylesheets/java/src/python/pyjnius
$ grep Node x3dpsail.py

For the minimal.py, this was to show that I was not including abstract classes, interfaces in my test.  That’s all.  I am not sure if I changed it in any significant way.

Suggest we sent PythonPipeliningSerializer.js to legacy.

Please see if:

https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/packageGenerator.py

is usable by you.  That’s where X3Dpackage.py comes from.

We don’t need pythonnet.  That was an early attempt at doing SAI over the network.

John

Sent from Mail for Windows 10

From: Brutzman, Donald (Don) (CIV)
Sent: Saturday, July 6, 2019 11:56 AM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: X3DPSAIL no need to wrap simple types; PyJNIus issues isolated;work next on native Python package

1. Pyjnius/X3DJSAIL mapping simplifications.

Thanks for brief discussion yesterday and for removing extraneous type-wrapper constructs in your testing build.

On 7/5/2019 6:17 PM, John Carlson wrote:
>   * I believe I have removed all references to sai (search for .sai.) and abstract classes (search for X3D).

Yes, am seeing that now:
https://github.com/carlsonsolutiondesign/x3dpsail/blob/master/x3dpsail.py
	import jnius_config
	jnius_config.set_classpath('.', 'c:/Users/coderextreme/x3dpsail/X3DJSAIL.3.3.full.jar', '../../../../stylesheets/java/jars/X3DJSAIL.3.3.full.jar', './X3DJSAIL.3.3.full.jar')
	from jnius import autoclass
	CommentsBlock = autoclass('org.web3d.x3d.jsail.Core.CommentsBlock')
	Anchor = autoclass('org.web3d.x3d.jsail.Networking.AnchorObject')
	Appearance = autoclass('org.web3d.x3d.jsail.Shape.AppearanceObject')
	Arc2D = autoclass('org.web3d.x3d.jsail.Geometry2D.Arc2DObject')
	# ...
	SFBool = autoclass('org.web3d.x3d.jsail.fields.SFBoolObject')
	MFBool = autoclass('org.web3d.x3d.jsail.fields.MFBoolObject')
	SFColor = autoclass('org.web3d.x3d.jsail.fields.SFColorObject')
	MFColor = autoclass('org.web3d.x3d.jsail.fields.MFColorObject')

> Verified by me, but do it yourself as well.

Confirmed.

Cleanup steps follow for preserving this work properly.

a. Recommendation: add documentation to the top of this file describing it's purpose and design, e.g.
	# Configuration file for Pyjnius to map X3DJSAIL concrete classes to native Python classes
	# Note that no abstract base classes are included, only nodes and simple types

b. Suggestion: comment out the SFNode and MFNode definitions since they are probably not needed by model authors and might be confusing Pyjnius.  Might be worth one last test.

c. Request: integrate these latest/best mappings back into the X3DJSAIL python tree:

https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pyjnius/

d. Do we need the adjacent code subtree pythonapi ?  Looks like this is your native Python package... naming is not clear.

https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pythonapi

e. Do we need the adjacent code subtree pythonnet ?  Am thinking it is experimental, not clear.

https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pythonnet

f. Once your work is stable, I can then update our README.md documentation in that tree, especially at

https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/README.md

> Also see minimal.py I suggest we work with the in short term.

Looks like you changed it... as discussed, use of an invalid fragment and focusing on IS with ProtoInstance leaps right to the more-obscure boundaries of the language.  This raises more questions than answers and is not good for design checks.  If you ever want a super-simple test scene, just excerpt X3D-Scene-Shape-Sphere from HelloWorld.x3d as a minimalist valid model.

--------------------------------------------------
2. Pyjnius/X3DJSAIL HelloWorld tests.

Thanks for confirming that the baseline single-setter example works:
https://github.com/carlsonsolutiondesign/x3dpsail/blob/master/HelloWorld.py
	head1.addMeta(meta2)
	meta3 = x3d.meta()
	meta3.setContent("Simple X3D scene example: Hello World!")
	meta3.setName("description")

For pipelined version (multiple setters) thanks for stripping the simple-type wrappers:
https://github.com/carlsonsolutiondesign/x3dpsail/blob/master/HelloWorld.future.py
       .setHead(x3d.head()
         .addMeta(x3d.meta().setContent("HelloWorld.x3d").setName(("title")))
         .addMeta(x3d.meta().setContent("Simple X3D scene example: Hello World!").setName(("description")))

Reportedly you were still getting the python traceback exceptions related to incorrect use of abstract classes.

Since you have gotten rid of any references to abstract classes in the Pyjnius mappings, and since X3DJSAIL Java library works, this finally isolates the problem to the pyjnius mapping being flawed.

On 7/5/2019 6:42 PM, John Carlson wrote:
> The only thing I can figure is PyJNIus, JNI or Java’s search for interfaces is bad?  IDK. In one case, it finds interfaces, and in another, it doesn’t?  That would be an avenue to pursue..

Not Java.  JNI is very unlikely the problem.  As ever, the likely culprit is that PyJNIus is not able to correctly map an involved class library using Java reflection.

Perhaps we can fix this someday by going into pyjnius and changing how it does reflection... but does not seem worth further pursuit at this stage.  Thanks for finally isolating the cause.

Since the problem relates to pipelined set methods, and since Loren has been very clear that we should not use set methods, we should now pursue a different line of approach.

--------------------------------------------------
3. Native Python package.

Design sessions with Loren emphasized the "keyword argument" (kwarg) approach for initializing simple-type attribute values.

Very interesting to look closely at your example expressed in this fashion, specifically

https://github.com/carlsonsolutiondesign/x3dpsail/blob/master/HelloWorld.kwargs.py
	from X3Dpackage import *
	X3D0 = X3D(profile="Immersive", version="3.3",
	    head1 = head(
		   meta2 = meta(content="HelloWorld.x3d", name="title"),
		   meta3 = meta(content="Simple X3D scene example: Hello World!", name="description"),

with corresponding native Python package you devised at
https://raw.githubusercontent.com/carlsonsolutiondesign/x3dpsail/master/X3Dpackage.py

I'll work on the design that the diagram described earlier this week, trying to stick to python "first principles" and best practices, rather than attempting to align with existing patterns.  No doubt your code will provide helpful comparisons as that proceeds.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190706/26dbc58e/attachment-0001.html>