<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style></head><body lang=EN-US link=blue vlink="#954F72"><div class=WordSection1><p class=MsoNormal>I suggest we try to track down the existing AttributeError’s without reintroducing more AttributeError’s.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I’ve checked in the pipelining serializer with TODO, so you can pursue removing unwrapping SFString.   Then we can pursue fixing X3DJSAIL as you say.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>As far as more readability, that’s a good idea.  I just need like a 1 week break before I try again.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I don’t do casting, I do wrapping, just like the Java code used to do.  There’s a jnius.cast (I think this is right spelling) that is available. I think casting would make the code super ugly and bring us back to the other style of code from the other serializer (which works just fine without casting or wrapping).   But casting may be required to smash the remaining errors.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>John</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">Mail</a> for Windows 10</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='border:none;padding:0in'><b>From: </b><a href="mailto:brutzman@nps.edu">Brutzman, Donald (Don) (CIV)</a><br><b>Sent: </b>Thursday, May 9, 2019 11:31 AM<br><b>To: </b><a href="mailto:yottzumm@gmail.com">John Carlson</a><br><b>Cc: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>X3D to .py conversion refinement, continued: wild duck chase</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi John, thanks for checking in your useful improvements .x3d -> python conversion into our pyjnius subversion directory.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>                Diff log: Moved sets to same line as constructor</p><p class=MsoNormal>                https://sourceforge.net/p/x3d/code/28428/</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The latest version (fewer line breaks) runs without problems and looks good for me too.  Example of current output (both python and java) attached.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Suggestion #1: for readability, don't skip lines when only a single close-parenthesis appears, simply append to end of line.  See .java as an example:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>     .setAppearance(new AppearanceObject()</p><p class=MsoNormal>       .setMaterial(new MaterialObject().setUSE("MaterialLightBlue")))))));</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Suggestion: also please check in your removal of all of the X3D type casting (SFString) (SFFloat) (SFInt32) etc. for further testing.  Let's chase Duck Typing.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>                https://en.wikipedia.org/wiki/Duck_typing</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>You reported encountered a few problems with the SFString casting... OK, am thinking it would be best to grasp those nettles, look at all of the exceptions closely, and (hopefully) fix each.  We've already made great progress on that score.  Often the full fix is pretty simple, i.e. adding another utility method to X3DJSAIL that might have been previously overlooked.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>It typically takes a while (all night) to run the full set of .x3d -> .py conversions on all X3D Examples Archives, and so will wait for when you are ready (tonight, tomorrow night, whenever).  That next build will give us another round of diffs to review and issues to diagnose/fix.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>In the meantime, I will also try to reduce the repetitive/excessive number of "regex failed due to insufficient memory" provoked during pyjnius invocation of X3DJSAIL. If those can be silenced (for now) then I think the build log will again be manageable.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hope this finds you well.  Thanks as ever for the excellent steady progress!  8)</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>all the best, Don</p><p class=MsoNormal>-- </p><p class=MsoNormal>Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman@nps.edu</p><p class=MsoNormal>Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149</p><p class=MsoNormal>X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>