RevarBat wrote > replace it with Python3 Please use a new topic if you want to discuss this further. https://pypi.org/project/pysolid/ There are others. ----- OpenSCAD Admin - email* me if you need anything, or if I've done something stupid... * on the Forum, click on my MichaelAtOz label, there is a link to email me. Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. -- Sent from: http://forum.openscad.org/

Pysolid has a good syntax, but it’s implementation is to output OpenSCAD language source code. I mean, you COULD go this way and use OpenSCAD’s language as if it were Display PostScript, but that seems non-optimal. - Revar > On Nov 24, 2020, at 7:17 PM, MichaelAtOz <oz.at.michael@gmail.com> wrote: > > RevarBat wrote >> replace it with Python3 > > Please use a new topic if you want to discuss this further. > https://pypi.org/project/pysolid/ > There are others. > > > > ----- > OpenSCAD Admin - email* me if you need anything, or if I've done something stupid... > > * on the Forum, click on my MichaelAtOz label, there is a link to email me. > > Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above. > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Well, there's already dozens of projects on github which replace OpenSCAD with a better language, including my own project Curv. For some reason, none of them are as popular as OpenSCAD. Translating idiomatic OpenSCAD to idiomatic, maintainable Python is ridiculously hard. If you want 100% backward compatibility, then you basically have to embed an OpenSCAD interpreter in Python to handle all the weird language semantics, such as: override semantics of multiple variable assignments to the same name (which is important when including a file and then overriding some of its variable definitions); dynamic scoping of $ variables; tail recursive functions; the fact that each call to children() re-evaluates the actual parameter using the current values of $ variables; and so on. If you instead translate to idiomatic, maintainable Python, then you'll only get an approximation, some OpenSCAD idioms won't work, and manual fixup will be required. If you implement this idea as a new project, then the translator will be a major effort, and will require a lot of ongoing work to track new language features. Take a look at SolidPython. <https://github.com/SolidCode/SolidPython>https://github.com/SolidCode/SolidPython It's not everything you asked for, but it exists, and it lets you write your models in Python. On Tue, Nov 24, 2020, at 9:59 PM, Revar Desmera wrote: > I have a semi-radical idea that I've been thinking of for a while now: Rip the problematic OpenSCAD language out of OpenSCAD and replace it with Python3. Provide backwards compatibility with a translator written in a Python parser. > > The syntax would be different, but would not have to be very alien: > >> difference( >> union( >> translate([0,0,5]) (Sphere(d=10)), >> Cube(10,CENTER).down(1).rotate(z=45) >> ), >> Cylinder(d=5,h=5) >> ).show() >> > Or: > >> Cube(100,CENTER).minkowski(Sphere(d=10)).show(); > > Modules would become functions or methods, where you just have to explicitly return the geometry. > >> def tube(id, od, l, children=None): >> return union( >> difference( >> Cylinder(d=od, l=l, CENTER), >> Cylinder(d=id, l=l+1, CENTER) >> ), >> children >> ) > > The benefits could be massive: > * Variables are mutable. > * You can store geometry in a variable. > * use/include gets replaced by import, which is less buggy. > * Efficient data structures like Dictionaries and Classes are available. > * You can assign multiple variables from a tuple returned from a function/module. > * You can actually read and parse files from disk. > * You can import C and Fortran based geometry libraries like ClipperLib and use them directly. (Via Cython if needed) > * You can use Cython for code speed-ups. > * There’s a massive pre-existing set of libraries available for all kinds of things. > * You would be able to force-render some geometry early to get bounds, vertices, faces, etc. > * The Python language has had built-in support for function literals for a long time now. > * And much more. > > It should be fairly easy to make Python equivalents of all the OpenSCAD language functions and modules, and have them use Cython to call into the same back-end calls that the OpenSCAD language currently calls into. You can keep the current Scintilla editor and rendering GUI. > > I would already have written this, except I KEEP swearing to myself that I am NOT going to take on yet another project that I need to support for 20 years. > > - Revar > > > > >> On Nov 24, 2020, at 2:36 AM, nop head <nop.head@gmail.com> wrote: >> >> It is easy to handle OPENSCADPATH in Python, including the platform difference: >> >> os.environ['OPENSCADPATH'].split(os.pathsep) >> >> Gives you a list of paths to look in for libraries. >> >> os.pathsep is ';' for Windows and ':' for others. >> >> To remove some of the warnings about argument tokens I factored out some common sub-expressions into variables. So perhaps there should be a warning about repeated subexpressions. >> >> >> On Tue, 24 Nov 2020 at 00:40, julianstirling <julian@julianstirling.co.uk> wrote: >>> "Correct. But then, there's the option to just not use those. " - I can make >>> the linter shouty if you use them :D. I plan eventually to have a >>> configurable regex for nice variable names/module names/function names. >>> >>> @nophead >>> I did not push out the promised fix today. Busy busy busy. Still working at >>> past midnight on something else. >>> >>> Thanks for the double loop bug. Yeah I treat them the same as I would key >>> word arguments. I can fix that. >>> >>> Ah I do not check "OPENSCADPATH". I shall look into this. Will probably be >>> weird to get it platform independent, but I am on linux you are on windows >>> so I may have to carry on using you as an alpha tester. >>> >>> Totally agree about the token counting being dumb. It is in there for my own >>> purposes as I am cleaning up messy code and so it gives me a sniff of where >>> to look. But yeah, need to think about complexity in a more intelligent way. >>> Especially as any decent size list gets flagged! I was thinking of adding >>> the complexity largest two elements in the list. This way it represents a >>> list being more complex than a single token, but doesn't scale stupidly. >>> >>> >>> >>> -- >>> Sent from: http://forum.openscad.org/ >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

I don't think the language is the main issue. The amount of developer time spend in the project is. You are trying to solve that problem by creating another project dividing developer time? If all that time spent on all those BetterSCADs (https://github.com/albinoBandicoot/BetterSCAD) could have been joined to improve on OpenSCAD itself, most of the problems might not exist anymore. Now there is a place for new projects of course and it's up to everyone to decide how to spend their time. I don't believe the OpenSCAD language is the best thing invented. If I would start something like that, I would likely do it quite differently too. But is JavaScript the perfect language? It's still used by a couple of people. Time and time again in different variations I have seen how people throw things away to create something new based on "new technology" because the existing stuff looks old and boring. Just to find out a couple of years later they are the legacy project now fighting the same issues they thought to solve by starting from scratch. Yes evolving an existing project used by many people is much more complicated then just changing doing something new, but at some point that's going to happen (Python3, Perl6, ...?). I'm massively impressed by C++ in that regard. It was sort-of dead for decades, but started moving and now evolves with massive and also surprising pace while still keeping the legacy working. Is it the neat modern lean language? No, far from it. Can you write neat modern code? Yes, well, maybe to 98% by using just the new style and accepting a couple of warts that are there due to backward compatibility reasons. And OpenSCAD is not just the code, it's also the documentation, the books, the people who do packaging for various platforms and distros, the people who help others and the not so small number of people just using it for fun from time to time. Well, coming back to the original topic of this thread I think tools like the static code analyzer can help with things like spotting code that could be written in a newer style, a more performant way or at some point maybe even point to libraries that would help simplifying models. It could be one puzzle piece for helping the OpenSCAD language to evolve. ciao, Torsten.

Ahem, where is that thread in the forum?

In my experience, the biggest failing of almost other projects is this space is extremely simple… they expect you to run it from a command-line. This is a non-starter for 95% of users on Windows, and far less than optimal on OS X. It needs to have an GUI application you can download and run without going to cmd.exe or Terminal.app. Another frequent flailing is that documentation is often an afterthought. As far as writing a parser to translate OpenSCAD to Python, that’s actually not that hard, especially if you make the Python SCAD syntax similar enough. You do need to have it run all the variable assignments before doing modules at each level, but that’s actually easy. The list comprehensions will even be easy to translate. The unshared namespaces for variables, functions, and modules can be dealt with via namespace prefixes. I think the only “feature” that would even maybe be annoying to translate is how “use <file>” works. This thread started with someone writing most of the needed parser already, which is why I posted it here. I once wrote a C-style language to Forth style language translator in Python before, so I know this is not really rocket science. It’s just quirky. SolidPython is the notional inverse of what I’m suggesting. It runs Python code and outputs OpenSCAD language as if it were Display Postscript. - Revar > On Nov 24, 2020, at 8:00 PM, Doug Moen <doug@moens.org> wrote: > > Well, there's already dozens of projects on github which replace OpenSCAD with a better language, including my own project Curv. For some reason, none of them are as popular as OpenSCAD. > > Translating idiomatic OpenSCAD to idiomatic, maintainable Python is ridiculously hard. If you want 100% backward compatibility, then you basically have to embed an OpenSCAD interpreter in Python to handle all the weird language semantics, such as: override semantics of multiple variable assignments to the same name (which is important when including a file and then overriding some of its variable definitions); dynamic scoping of $ variables; tail recursive functions; the fact that each call to children() re-evaluates the actual parameter using the current values of $ variables; and so on. If you instead translate to idiomatic, maintainable Python, then you'll only get an approximation, some OpenSCAD idioms won't work, and manual fixup will be required. > > If you implement this idea as a new project, then the translator will be a major effort, and will require a lot of ongoing work to track new language features. > > Take a look at SolidPython. <https://github.com/SolidCode/SolidPython>https://github.com/SolidCode/SolidPython <https://github.com/SolidCode/SolidPython> > It's not everything you asked for, but it exists, and it lets you write your models in Python. > > On Tue, Nov 24, 2020, at 9:59 PM, Revar Desmera wrote: >> I have a semi-radical idea that I've been thinking of for a while now: Rip the problematic OpenSCAD language out of OpenSCAD and replace it with Python3. Provide backwards compatibility with a translator written in a Python parser. >> >> The syntax would be different, but would not have to be very alien: >> >> difference( >> union( >> translate([0,0,5]) (Sphere(d=10)), >> Cube(10,CENTER).down(1).rotate(z=45) >> ), >> Cylinder(d=5,h=5) >> ).show() >> >> Or: >> >> Cube(100,CENTER).minkowski(Sphere(d=10)).show(); >> >> Modules would become functions or methods, where you just have to explicitly return the geometry. >> >> def tube(id, od, l, children=None): >> return union( >> difference( >> Cylinder(d=od, l=l, CENTER), >> Cylinder(d=id, l=l+1, CENTER) >> ), >> children >> ) >> >> The benefits could be massive: >> Variables are mutable. >> You can store geometry in a variable. >> use/include gets replaced by import, which is less buggy. >> Efficient data structures like Dictionaries and Classes are available. >> You can assign multiple variables from a tuple returned from a function/module. >> You can actually read and parse files from disk. >> You can import C and Fortran based geometry libraries like ClipperLib and use them directly. (Via Cython if needed) >> You can use Cython for code speed-ups. >> There’s a massive pre-existing set of libraries available for all kinds of things. >> You would be able to force-render some geometry early to get bounds, vertices, faces, etc. >> The Python language has had built-in support for function literals for a long time now. >> And much more. >> >> It should be fairly easy to make Python equivalents of all the OpenSCAD language functions and modules, and have them use Cython to call into the same back-end calls that the OpenSCAD language currently calls into. You can keep the current Scintilla editor and rendering GUI. >> >> I would already have written this, except I KEEP swearing to myself that I am NOT going to take on yet another project that I need to support for 20 years. >> >> - Revar >> >> >> >> >>> On Nov 24, 2020, at 2:36 AM, nop head <nop.head@gmail.com <mailto:nop.head@gmail.com>> wrote: >>> >>> It is easy to handle OPENSCADPATH in Python, including the platform difference: >>> >>> os.environ['OPENSCADPATH'].split(os.pathsep) >>> >>> Gives you a list of paths to look in for libraries. >>> >>> os.pathsep is ';' for Windows and ':' for others. >>> >>> To remove some of the warnings about argument tokens I factored out some common sub-expressions into variables. So perhaps there should be a warning about repeated subexpressions. >>> >>> >>> On Tue, 24 Nov 2020 at 00:40, julianstirling <julian@julianstirling.co.uk <mailto:julian@julianstirling.co.uk>> wrote: >>> "Correct. But then, there's the option to just not use those. " - I can make >>> the linter shouty if you use them :D. I plan eventually to have a >>> configurable regex for nice variable names/module names/function names. >>> >>> @nophead >>> I did not push out the promised fix today. Busy busy busy. Still working at >>> past midnight on something else. >>> >>> Thanks for the double loop bug. Yeah I treat them the same as I would key >>> word arguments. I can fix that. >>> >>> Ah I do not check "OPENSCADPATH". I shall look into this. Will probably be >>> weird to get it platform independent, but I am on linux you are on windows >>> so I may have to carry on using you as an alpha tester. >>> >>> Totally agree about the token counting being dumb. It is in there for my own >>> purposes as I am cleaning up messy code and so it gives me a sniff of where >>> to look. But yeah, need to think about complexity in a more intelligent way. >>> Especially as any decent size list gets flagged! I was thinking of adding >>> the complexity largest two elements in the list. This way it represents a >>> list being more complex than a single token, but doesn't scale stupidly. >>> >>> >>> >>> -- >>> Sent from: http://forum.openscad.org/ <http://forum.openscad.org/> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>

On Tue Nov 24 21:34:14 PST 2020 revarbat@gmail.com said: >In my experience, the biggest failing of almost other projects is this space is extremely simple? they expect you to run it from a command-line. This is a non-starter for 95% of users on Windows, and far less than optimal on OS X. It needs to have an GUI application you can download and run without going to cmd.exe or Terminal.app. Another frequent flailing is that documentation is often an afterthought. I'm still of the opinion that you get a LOT of capability for free if you write a language parser for Eclipse. It has all the editor features you can want, just needs to know the syntax of the language. -- Bobcats and Cougars, oh my! http://john.casadelgato.com/Pets

That’d not a bad idea. Has anyone’s BetterSCAD project integrated with Eclipse or Atom with a preview window? - Revar > On Nov 24, 2020, at 9:42 PM, John Lussmyer <Cougar@CasaDelGato.com> wrote: > > On Tue Nov 24 21:34:14 PST 2020 revarbat@gmail.com said: >> In my experience, the biggest failing of almost other projects is this space is extremely simple? they expect you to run it from a command-line. This is a non-starter for 95% of users on Windows, and far less than optimal on OS X. It needs to have an GUI application you can download and run without going to cmd.exe or Terminal.app. Another frequent flailing is that documentation is often an afterthought. > > I'm still of the opinion that you get a LOT of capability for free if you write a language parser for Eclipse. > It has all the editor features you can want, just needs to know the syntax of the language. > > > -- > > Bobcats and Cougars, oh my! http://john.casadelgato.com/Pets_______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

There are so many 3D programming things for Python, most of them intended to be OpenSCAD replacements that I had to give them their own section at: https://wiki.shapeoko.com/index.php/Programming#Python to wit: https://github.com/wovo/psml [12] https://pypi.org/project/pygcode/ [13] https://github.com/arcadeperfect/svg2gcode_grbl [14] https://www.codelv.com/projects/declaracad/ --- language and application to build 3D models using a subset of the python language called enaml https://github.com/orbingol/NURBS-Python [15] http://www.pyxplot.org.uk/ http://savannah.nongnu.org/projects/soya3d/ http://pythoncad.sourceforge.net/dokuwiki/doku.php?id=program_code_description [16] https://vpython.org/ Python stuff to add for OpenSCAD from the mailing list (find link in forum for footnote) ...and https://github.com/SquirrelCZE/pycad/ ...and https://github.com/vishnubob/pyscad ...and https://github.com/bjbsquared/SolidPy ...and https://github.com/acrobotic/py2scad ...and https://github.com/TheZoq2/py-scad ...and https://github.com/defnull/pyscad ...and https://github.com/jed-frey/CNC3018 ...and https://sourceforge.net/projects/elcad/ OpenSCAD interface extensible with Python[edit] http://graphscad.blogspot.com/ Plus there's the Python interpreter in FreeCad.... Cue relevant XKCD: https://xkcd.com/927/ That said, if one of these is clearly better, preferable and usable, I'd like to know which it is. William ______________________________________________ OpenSCAD mailing list Discuss@lists.openscad.org http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Okay, of those, only DeclaraCAD and possibly ElCAD/Fandango are viable looking OpenSCAD type projects. The rest are either CNC focused, or are designed to just output OpenSCAD code. ElCAD/Fandango hasn’t been updated in 13 years. DeclaraCAD looks viable, but has no installer. I cannot state this emphatically enough… If you force your users to compile the SCAD program, it’s NOT a viable work environment for anyone but experts. And you shouldn’t be forcing THEM to compile it either. Otherwise, DeclaraCAD seems viable, but it’s using Enaml. It’s unclear to me if that’s a superset or a subset of Python, or if it loses the benefits of full Python. The SCAD specific syntax is a bit too verbose as well. - Revar > On Nov 24, 2020, at 10:28 PM, William F. Adams via Discuss <discuss@lists.openscad.org> wrote: > > There are so many 3D programming things for Python, most of them intended to be OpenSCAD replacements that I had to give them their own section at: > > https://wiki.shapeoko.com/index.php/Programming#Python > > to wit: > > https://github.com/wovo/psml <https://github.com/wovo/psml> [12] <https://www.reddit.com/r/openscad/comments/fb0fhj/and_another_python_library_that_generates_openscad/> > https://pypi.org/project/pygcode/ <https://pypi.org/project/pygcode/> [13] <https://www.reddit.com/r/CNC/comments/ewp3lp/extract_data_from_gcode_using_python/fg3ix2d/> > https://github.com/arcadeperfect/svg2gcode_grbl <https://github.com/arcadeperfect/svg2gcode_grbl> [14] <https://www.reddit.com/r/hobbycnc/comments/eiook0/svg2gcode_grbl/> > https://www.codelv.com/projects/declaracad/ <https://www.codelv.com/projects/declaracad/> --- language and application to build 3D models using a subset of the python language called enaml > https://github.com/orbingol/NURBS-Python <https://github.com/orbingol/NURBS-Python> [15] <https://www.sciencedirect.com/science/article/pii/S2352711018301778> http://www.pyxplot.org.uk/ <http://www.pyxplot.org.uk/> > http://savannah.nongnu.org/projects/soya3d/ <http://savannah.nongnu.org/projects/soya3d/> > http://pythoncad.sourceforge.net/dokuwiki/doku.php?id=program_code_description <http://pythoncad.sourceforge.net/dokuwiki/doku.php?id=program_code_description> [16] <http://libregraphicsworld.org/blog/entry/pythoncad-gets-revival-releases-r38-alpha4> > https://vpython.org/ <https://vpython.org/> > Python stuff to add for OpenSCAD from the mailing list (find link in forum for footnote) > ...and https://github.com/SquirrelCZE/pycad/ <https://github.com/SquirrelCZE/pycad/> > ...and https://github.com/vishnubob/pyscad <https://github.com/vishnubob/pyscad> > ...and https://github.com/bjbsquared/SolidPy <https://github.com/bjbsquared/SolidPy> > ...and https://github.com/acrobotic/py2scad <https://github.com/acrobotic/py2scad> > ...and https://github.com/TheZoq2/py-scad <https://github.com/TheZoq2/py-scad> > ...and https://github.com/defnull/pyscad <https://github.com/defnull/pyscad> > ...and https://github.com/jed-frey/CNC3018 <https://github.com/jed-frey/CNC3018> > ...and https://sourceforge.net/projects/elcad/ <https://sourceforge.net/projects/elcad/> > OpenSCAD interface extensible with Python[edit <https://wiki.shapeoko.com/index.php?title=Programming&action=edit&section=7>] > > http://graphscad.blogspot.com/ <http://graphscad.blogspot.com/> > > Plus there's the Python interpreter in FreeCad.... > > Cue relevant XKCD: > > https://xkcd.com/927/ > > That said, if one of these is clearly better, preferable and usable, I'd like to know which it is. > > William > > > ______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org <http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org