[x3d-public] updates to X3DJSAIL, plus python and java versions ofX3DExamples,X3DPSAIL; let Python be Python
John Carlson
yottzumm at gmail.com
Wed Jun 26 05:53:32 PDT 2019
I’m now having problems with “set Proxy” called twice in generated python scenegraph. Checked in:
data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54 = Collision()
data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54.proxy = Shape55
data/X3dHeaderPrototypeSyntaxExamples.assign.py:Collision54.proxy = Group59
data/X3dHeaderPrototypeSyntaxExamples.assign.py:Scene17.addChildren([Collision54])
data/X3dHeaderPrototypeSyntaxExamples.kwargs.py: Collision54 = Collision( Shape55 = Shape( # note that Collision proxy Shape is not rendered
data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54 = Collision()
data/X3dHeaderPrototypeSyntaxExamples.serial.py:Shape55 = Shape(proxy = Collision54)
data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54.setProxy(Shape55)
data/X3dHeaderPrototypeSyntaxExamples.serial.py:Collision54.setProxy(Group59)
data/X3dHeaderPrototypeSyntaxExamples.serial.py:Scene17.addChildren(Collision54)
Sent from Mail for Windows 10
From: John Carlson
Sent: Wednesday, June 26, 2019 7:39 AM
To: Brutzman, Donald (Don) (CIV)
Cc: X3D Graphics public mailing list; Peitso, Loren (CIV)
Subject: RE: updates to X3DJSAIL, plus python and java versions ofX3DExamples,X3DPSAIL; let Python be Python
Don, read this.
My response:
1 a) mapToMethod.js is overridden by mapToMethod2.js. You need to study JavaScript objects, and how values are written over by keys and values appearing later in a file. Two equal keys ends up as a single key, and the last value that appears in order in the file takes.
I know this isn’t ideal, which is why I created mapToMethod2.js for a fallback.
For example, print out this object:
{ " a": 1, " a" : 2 }
As far as I know, the mapToMethod*.js files only affect the Serializers.
The best way to think of JavaScript Objects is as arrays with a non whole number indexes and interned keys (a la Java) I think. Now you *will* understand that there are no double entries left once the whole file is read in the JavaScript? You can also combine an array with an object in JavaScript, last I’ve heard (probably not a good idea).
We can easily remove the abstract classes by modifying what gets sent to the ClassPrinter in packagemaker.py and avoiding going up the hierarchy into interfaces and abstract classes. (Search for Abstract to begin)
I don’t have a good methods for fixing this yet, and I have tried different things in mapToMethod.py, like not traversing to parents or children, but haven’t found a good solution.
b) We can remove abstract classes, unless there some implementation in the abstract class we need to access??? I didn’t know whether I should follow the parent chain up the inheritance hierarchy or not? Are there concrete classes which inherit from concrete classes? Show me an example of a Python file where the translation from XML was wrong, and we can work on an example. I don’t want to work without an example at this point, unless you want me to get rid of the interfaces and abstract classes. Since we’re converting to Python from X3D scenegraphs, there won’t be interfaces or abstract classes in the generated Python, because they aren’t in X3D XML scenegraphs. If we’re talking methods that are abstract, that’s a different story. Those shouldn’t appear in mapToMethod.js, so the methods won’t be used in the generated scenegraph in Python. The key is to find out what method should be used, and put that in mapToMethod2.js in the short term. Ideally, we’d have a single file with correct entries.
c) I’m waiting for you to show me something that has fewer errors than using the wrappers, like use a different serializer.
2) Welcome aboard. We can leave the pyjnius version available to Java programmers who want to use a “Java-like” syntax for ease of porting, but we should get to X3DJSAIL production of Python scenegraphs soon. I suggest using PythonSerializer.js output, if it’s in good shape for the “set API” so we don’t get a bunch of errors. Let’s toss Pipelining/Chaining altogether, then the user can make a choice as to what they want to program, instead of us ruling what they have to do. They are better to decide how to work around the error, but we can make suggestions, like don’t use Pipelining.
That said, there are 3 left over styles we can use instead of the pipelining. Examples of different styles can be found in the data folder under pythonapi on sourceforge. I suggest using the PythonAssignSerializer.js. But we may need to do something for initializeOnly, in which case, I recommend the Kwargs serializer.
3) A word:
https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/packagemaker.py
created the X3DPackage.py file, so probably the packagemaker.py file would be a good launching point. No need to make your changes to X3DPackage.py file if they’re going to be overwritten in the next build.
I am thinking we need a RDF to X3DPackage.py converter? Is that the mad science Loren was talking about?
Here’s where I gave up on the pythonapi. I was able to generate classes from X3DUOM, but I was unable to generate XML from the generated classes. Perhaps that’s the best place to start on the new effort.
I think the best thing we can do is work with RDF to generate the appropriate classes that generate XML during run-time. But we will need to generate documentation for these “shadow” classes that don’t appear in any source code. Perhaps Loren has a solution? Hmm! My brain is foggy. I will get a frappe and take a nap.
John
Sent from Mail for Windows 10
From: Brutzman, Donald (Don) (CIV)
Sent: Tuesday, June 25, 2019 9:39 PM
To: John Carlson
Cc: X3D Graphics public mailing list; Peitso, Loren (CIV)
Subject: Re: updates to X3DJSAIL, plus python and java versions ofX3DExamples, X3DPSAIL; let Python be Python
Hi John, hope you are well. Am busy for the next week but here is some more detail for you.
1. Found some possible problems with X3DPSAIL that might be provoking the problem with incorrect node types.
a. mapToMethod.js has a lot of duplication in it in the left-hand side of the associative arrays. This is probably confusing the heck out of the Java reflection methodology inside pyjnius. For example, note the repeated entries of "X3DMetadataObject" in the first example, then multiple duplications in the second example:
////////////////////////////
"X3DNode" : {
"X3DMetadataObject" : "setMetadata",
"MetadataBoolean" : "setMetadata",
"MetadataDouble" : "setMetadata",
"MetadataFloat" : "setMetadata",
"MetadataInteger" : "setMetadata",
"MetadataSet" : "setMetadata",
"MetadataString" : "setMetadata",
"X3DMetadataObject" : "setMetadata",
},
////////////////////////////
"Appearance" : {
"FillProperties" : "setFillProperties",
"FillProperties" : "setFillProperties",
"X3DConcreteNode" : "setFillProperties",
"X3DChildNode" : "setFillProperties",
"X3DNode" : "setFillProperties",
"X3DAppearanceChildNode" : "setFillProperties",
"X3DNode" : "setFillProperties",
"X3DNode" : "setFillProperties",
"LineProperties" : "setLineProperties",
"LineProperties" : "setLineProperties",
"X3DConcreteNode" : "setLineProperties",
"X3DChildNode" : "setLineProperties",
"X3DNode" : "setLineProperties",
"X3DAppearanceChildNode" : "setLineProperties",
"X3DNode" : "setLineProperties",
"X3DNode" : "setLineProperties",
"X3DMaterialNode" : "setMaterial",
"Material" : "setMaterial",
"TwoSidedMaterial" : "setMaterial",
"X3DMaterialNode" : "setMaterial",
"X3DAppearanceChildNode" : "setMaterial",
"X3DNode" : "setMaterial",
"X3DNode" : "setMaterial",
"X3DMetadataObject" : "setMetadata",
"MetadataBoolean" : "setMetadata",
"MetadataDouble" : "setMetadata",
"MetadataFloat" : "setMetadata",
"MetadataInteger" : "setMetadata",
"MetadataSet" : "setMetadata",
"MetadataString" : "setMetadata",
"X3DMetadataObject" : "setMetadata",
"PointProperties" : "setPointProperties",
"PointProperties" : "setPointProperties",
"X3DConcreteNode" : "setPointProperties",
"X3DChildNode" : "setPointProperties",
"X3DNode" : "setPointProperties",
"X3DAppearanceChildNode" : "setPointProperties",
"X3DNode" : "setPointProperties",
"X3DNode" : "setPointProperties",
"X3DShaderNode" : "addShaders",
"ComposedShader" : "addShaders",
"PackagedShader" : "addShaders",
"ProgramShader" : "addShaders",
"X3DShaderNode" : "addShaders",
"X3DAppearanceChildNode" : "addShaders",
"X3DNode" : "addShaders",
"X3DNode" : "addShaders",
"X3DTextureNode" : "setTexture",
"X3DEnvironmentTextureNode" : "setTexture",
"ComposedCubeMapTexture" : "setTexture",
"GeneratedCubeMapTexture" : "setTexture",
"ImageCubeMapTexture" : "setTexture",
"X3DTexture2DNode" : "setTexture",
"ImageTexture" : "setTexture",
"MovieTexture" : "setTexture",
"PixelTexture" : "setTexture",
"X3DTexture3DNode" : "setTexture",
"ComposedTexture3D" : "setTexture",
"ImageTexture3D" : "setTexture",
"PixelTexture3D" : "setTexture",
"MultiTexture" : "setTexture",
"X3DTextureNode" : "setTexture",
"X3DAppearanceChildNode" : "setTexture",
"X3DNode" : "setTexture",
"X3DNode" : "setTexture",
"X3DTextureTransformNode" : "setTextureTransform",
"MultiTextureTransform" : "setTextureTransform",
"TextureTransform" : "setTextureTransform",
"TextureTransform3D" : "setTextureTransform",
"TextureTransformMatrix3D" : "setTextureTransform",
"X3DTextureTransformNode" : "setTextureTransform",
"X3DAppearanceChildNode" : "setTextureTransform",
"X3DNode" : "setTextureTransform",
"X3DNode" : "setTextureTransform",
},
////////////////////////////
I believe you create this via mapToMethodGenerator.js - might you be able to filter duplicates?
------
b. Additionally, *all of the X3D node types on the left-hand side above are suspect* because X3DJSAIL only uses node types as a Java-based shorthand. I am wondering if all are eliminated completely, that might force Pyjnius into only using methods for concrete nodes, as we wish.
------
c. Python describes how we can "import as" to change package names when appropriate. This capability is in most Python books too. Reference:
Python Language Reference, 7.11. The import statement
https://docs.python.org/3/reference/simple_stmts.html#the-import-statement
Also note that simple Python data types are supported by X3DJSAIL, so we don't have to wrap non-node values with SFString SFFloat etc. I think this might let us change our file syntax as follows:
http://x3dgraphics.com/examples/X3dForAdvancedModeling/HelloWorldScenes/HelloWorld.py
============================================================
import x3dpsail
X3D0 = (x3dpsail.X3D().setProfile(x3dpsail.SFString("Immersive")).setVersion(x3dpsail.SFString("3.3"))
.setHead(x3dpsail.head() # etc.
============================================================
to
============================================================
import x3dpsail as x3d
X3D0 = (x3d.X3D().setProfile("Immersive").setVersion("3.3")
.setHead(x3d.head() # etc.
============================================================
Nodes would need the "x3d." prefix so that they were package specific and not clobbered by user-defined name collisions.
2. Looking ahead.
So far our strategy has been to implement X3D Python via pyjnius and X3DJSAIL, expecting to work on a C-based Cython implementation in the future when the C-based SAI open source is available.
Not a bad plan, but maybe we can make things much easier. Loren, Jakub and I spent three hours tearing everything apart and putting it back together last week. We came to the realization that we were working awfully hard and still having difficulties getting different languages aligned... when a much simpler approach was possible.
We might do far better by implementing an X3D package for python in python. That would make X3D support independent of any other language bindings.
This would enable us to be far more "pythonic" and mainstream in all our constructs, rather than worrying about other programming-language implementation dependencies. In other words, let Python be Python!
Looks like you might have already been hard at work on such an alternative:
https://sourceforge.net/p/x3d/code/HEAD/tree/www.web3d.org/x3d/stylesheets/java/src/python/pythonapi/X3Dpackage.py
Next week, Loren and I will take a clean white board and attempt to design a type-aware X3D package that allows careful terse construction of correct X3D scene graphs. We will simply apply X3D data model to best Python package practices. No doubt Loren will banish "set" and "get" from our lexicon, and other java/javascript idioms will be avoided. We'll then compare diffs with yours X3Dpackage.py, should be interesting. Onward we go.
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/20190626/9e32f4ff/attachment-0001.html>
More information about the x3d-public
mailing list