[x3d-public] X3D python language binding, pyjnius validation

[John Carlson]

I see you are modifying this as I email.  4:50am?  Make sure the output filenames from the serializers are different filenames, unless of course, you don’t want to.  I like your RoundTrip name. Maybe we could squeeze _py or _future (for pipelining serializer) in there?  Not really sure about that. Use good judgement.

$ grep toF Python*js                                                            
PythonPipeliningSerializer.js:          str += "\n"+element.nodeName+stack[0]+".
toFileX3D(\""+clazz+"_RoundTrip.x3d\")\n";                                      
PythonSerializer.js:            str += element.nodeName+stack[0]+".toFileX3D(\""
+clazz+"_RoundTrip.x3d\")\n";                                                   
Old message, but some of it still applies, sorry if I see steamed. I’m actually laughing:

My mailer doesn’t seem to be quoting properly, so I have this “new style” quoting.

Don wrote:

‘Was surprised by your change to ".newf" file suffix and so changed that to ".newFile" for searchability and clarity.

I write:

I didn’t change to *.newf.x3d. That what I originally had it at. “f” for future.  You just didn’t see many of the files before because of errors. The errors I have no clue how to fix, except perhaps by casting or enhancing X3Dautoclass.py.  But, ahem, “good” idea.  See below for issues I have with it, that need to be improved. I would be very keen on knowing if you had a configuration where many *.newf.x3d files appeared.  That may be our solution!!!!!!!!!!!!!!!!

Don wrote:

Then realized that one major difference between your working script and my X3D Example Archives script was that you were running in the pyjnius directory, which could account for why some files were not being seen.  In other words, perhaps PYTHONPATH wasn't enough?

I write:

Running in the pyjnius folder allowed me to find the X3DJSAIL jar in the classpath. That is all. You may need to change the classpath in autoclass.py near the bottom. I hope you get this email.

Don wrote:

Sure enough, modifying the execution directory in the Ant target led to the right validation occurring of ModelName.newFile.x3d models generated from ModelName.py and ModelName.future.py conversions.  Presence of the naming-convention warning indicates that X3DJSAIL has fully validated the result file, and has no other warnings or reports.’

My reply:

Yeah, you’re going to see *.newFile.x3d file outputs from *.future.py if you call the outputs by the same name in both serializers.  Please modify one of the serializers to a different file output name.

Evidence:

$ grep new Python*                                                              
PythonPipeliningSerializer.js:          str += “\n”+element.nodeName+stack[0]+”.
toFileX3D(\””+clazz+”.newFile.x3d\”)\n”;                                        
PythonSerializer.js:            str += element.nodeName+stack[0]+”.toFileX3D(\””
+clazz+”.newFile.x3d\”)\n”;                                                     

I am fairly sure that the *.future.py file (most of them) do not generate output, despite your attempt to cloud my keen sight |). (does that smilie look like the blind engineer on star trek: the next generation)?  Note that you forgot to tell me that you also changed the output filenames that were “*.new.x3d” as well?  Please clean up the abox.new.x3d when you choose a new output file extension for PythonSerializer.js

We should make it more evident which serializers generate which .x3d files.   Please try again!

Onward through the mud of Spring!

It would be very cool if you made two .’s acceptable in an standard X3D filename. But be what it may.  Perhaps we should make the first . a _?  Please proceed as you feel best.  I will adapt as long as the serializers output to different filenames.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190409/f45f83b5/attachment.html>