OpenSCAD language - replace it with Python3

classic Classic list List threaded Threaded
140 messages Options
1234 ... 7
Reply | Threaded
Open this post in threaded view
|

OpenSCAD language - replace it with Python3

MichaelAtOz
Administrator
This post was updated on .
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.
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

RevarBat
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

skypuppy

That's really not a bad idea!


On 11/24/20 8: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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

MichaelAtOz
Administrator
In reply to this post by RevarBat
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

RevarBat
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 <[hidden email]> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

doug.moen
In reply to this post by RevarBat
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
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 <[hidden email]> 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 <[hidden email]> 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.



--

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

tp3
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

RevarBat
In reply to this post by doug.moen
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 <[hidden email]> 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
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 <[hidden email]> 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 <[hidden email]> 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.



--

_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list
_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Static Code Analysis for OpenSCAD

CasaDelGato
On Tue Nov 24 21:34:14 PST 2020 [hidden email] 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

MichaelAtOz
Administrator
In reply to this post by MichaelAtOz
Posts moved. Please reply to this to continue on this topic.



-----
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

RevarBat
Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.

Now at this point I HAVEN’T put serious work into any BetterSCAD. I’ve written many thousands of lines of OpenSCAD code. I just keep getting so very frustrated that I start dreaming about something better, then have to reel myself back in because I have no interest in having to support another project for the next 20 years. I've written and submitted PRs to implement improvements in OpenSCAD.  Not a single one has been accepted yet. All I can do at this point is TRY to convince devs to let logic prevail.  PLEASE.

What I really want is for the OpenSCAD devs to FIX OpenSCAD. And I just haven’t been seeing that, and my attempts to help appear unwanted.

This is how forks happen. This is how forks have already happened to this project.

- Revar


> On Nov 24, 2020, at 9:13 PM, Torsten Paul <[hidden email]> wrote:
>
> 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.
>
>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

RevarBat
In reply to this post by CasaDelGato
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 <[hidden email]> wrote:
>
> On Tue Nov 24 21:34:14 PST 2020 [hidden email] 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

OpenSCAD mailing list-2
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://www.codelv.com/projects/declaracad/ --- language and application to build 3D models using a subset of the python language called enaml
Python stuff to add for OpenSCAD from the mailing list (find link in forum for footnote)

OpenSCAD interface extensible with Python[edit]


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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

RevarBat
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 <[hidden email]> 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:


to wit:

https://www.codelv.com/projects/declaracad/ --- language and application to build 3D models using a subset of the python language called enaml
Python stuff to add for OpenSCAD from the mailing list (find link in forum for footnote)

OpenSCAD interface extensible with Python[edit]


Plus there's the Python interpreter in FreeCad....

Cue relevant XKCD:


That said, if one of these is clearly better, preferable and usable, I'd like to know which it is.

William


______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

cacb
In reply to this post by MichaelAtOz
On 25.11.2020 03:59, 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.

Separating functionality from language interpreter is in my opinion a
good idea. Now, which language to replace the OpenSCAD language with is
a matter of preference. There are many good arguments in support of
using Python, but there are also many good arguments against it.

My advice to OpenSCAD would be to make an OpenSCAD API with the boolean
engine etc. (but no scripting language features) and implement the
OpenSCAD language by using the API. The test for true separation would
be if someone could implement a Python or other language interpreter
using the same API

 > 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()


I guess the above is hypothetical. For comparison, in current OpenSCAD:

difference() {
    union() {
       translate([0,0,5]) sphere(d=10);
       rotate([0,0,45])
          translate([0,0,-1])
             cube(size=10,center=true);
    }
    cylinder(d=5,h=5);
}

In non-hypothetical AngelCAD (using AngelScript) it could written in
different ways, for example

    solid@ u =
       translate(0,0,5)
         *sphere(r:10./2)
     + rotate_z(deg:45)
         *translate(0,0,-1)
            *cube(size:10,center:true);
     return  u - cylinder(r:5./2,h:5);

Or alternatively

    return
    difference3d(
       union3d(
          translate(0,0,5)
            *sphere(r:10./2),
          rotate_z(deg:45)
            *translate(0,0,-1)
               *cube(size:10,center:true)
        ),
        cylinder(r:5./2,h:5)
    );


 > The benefits could be massive:
 >
 >   * Variables are mutable.

Yes, also true in AngelCAD

 >   * You can store geometry in a variable.

Yes

 >   * use/include gets replaced by import, which is less buggy.

You mean Python import. The main thing is using a standard language
feature. In AngelScript you have #include without the issues related to
include<> and use<> in OpenSCAD

 >   * Efficient data structures like Dictionaries and Classes are
available.

Yes. Writing your own classes in the scripting language is very powerful.

 >   * You can actually read and parse files from disk.

Yes.

 >   * You can import C and Fortran based geometry libraries like
 >     ClipperLib and use them directly. (Via Cython if needed)

In theory. I have worked a lot with Fortran and developed a way to
interface it with C++. It is not trivial. I also worked with ClipperLib
and it has its quirks too. But I agree using a n existing language
supported by someone else opens up many new possibilities.

 >   * You can use Cython for code speed-ups.

I use Boost.Python when interfacing python with C++

 >   * There’s a massive pre-existing set of libraries available for all
 >     kinds of things.

This is the best argument in favour of Python.

One argument against python is in my opinion that the language
interpreter is somewhere else on the system and not embedded in the
application like it is in today's OpenSCAD and also in AngelCAD. With
these applications you just install and run scripts. That is a good thing.

With Python you have to have a working Python installation separate from
the application and it has to be compatible with the expectations of the
application. I have managed to almost trash my entire windows and linux
installations, because I did things I should not be doing with Python
because I had issues getting things to work. Granted, most people can
use Python just fine but I think it is an extra hurdle for a lot of people.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

cacb
In reply to this post by RevarBat
On 25.11.2020 07:08, Revar Desmera wrote:
> Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
>

I agree with this line of thinking.

Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "

Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

nophead
OpenSCAD is a language for describing objects, not a programming language. That makes it much simpler than Python and more concise for describing geometry. It also means it doesn't need mutable variables as it is a static description, not a program that runs, so no values need to change over time.

On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm <[hidden email]> wrote:
On 25.11.2020 07:08, Revar Desmera wrote:
> Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
>

I agree with this line of thinking.

Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "

Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

RevarBat
In reply to this post by cacb
The only reason I specify Python is my personal familiarity with it. Making an API for arbitrary languages to use would also be a great idea.

On the Mac you can embed the python interpreter libraries in the .app itself. Under windows you can install it with specific python DLLs. Under Linux it’s preferable to use the system python installation, but you can use a virtualenv instance.

- Revar


> On Nov 25, 2020, at 12:40 AM, Carsten Arnholm <[hidden email]> wrote:
>
> On 25.11.2020 03:59, 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.
>
> Separating functionality from language interpreter is in my opinion a good idea. Now, which language to replace the OpenSCAD language with is a matter of preference. There are many good arguments in support of using Python, but there are also many good arguments against it.
>
> My advice to OpenSCAD would be to make an OpenSCAD API with the boolean engine etc. (but no scripting language features) and implement the OpenSCAD language by using the API. The test for true separation would be if someone could implement a Python or other language interpreter using the same API
>
> > 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()
>
>
> I guess the above is hypothetical. For comparison, in current OpenSCAD:
>
> difference() {
>   union() {
>      translate([0,0,5]) sphere(d=10);
>      rotate([0,0,45])
>         translate([0,0,-1])
>            cube(size=10,center=true);
>   }
>   cylinder(d=5,h=5);
> }
>
> In non-hypothetical AngelCAD (using AngelScript) it could written in different ways, for example
>
>   solid@ u =
>      translate(0,0,5)
>        *sphere(r:10./2)
>    + rotate_z(deg:45)
>        *translate(0,0,-1)
>           *cube(size:10,center:true);
>    return  u - cylinder(r:5./2,h:5);
>
> Or alternatively
>
>   return
>   difference3d(
>      union3d(
>         translate(0,0,5)
>           *sphere(r:10./2),
>         rotate_z(deg:45)
>           *translate(0,0,-1)
>              *cube(size:10,center:true)
>       ),
>       cylinder(r:5./2,h:5)
>   );
>
>
> > The benefits could be massive:
> >
> >   * Variables are mutable.
>
> Yes, also true in AngelCAD
>
> >   * You can store geometry in a variable.
>
> Yes
>
> >   * use/include gets replaced by import, which is less buggy.
>
> You mean Python import. The main thing is using a standard language feature. In AngelScript you have #include without the issues related to include<> and use<> in OpenSCAD
>
> >   * Efficient data structures like Dictionaries and Classes are available.
>
> Yes. Writing your own classes in the scripting language is very powerful.
>
> >   * You can actually read and parse files from disk.
>
> Yes.
>
> >   * You can import C and Fortran based geometry libraries like
> >     ClipperLib and use them directly. (Via Cython if needed)
>
> In theory. I have worked a lot with Fortran and developed a way to interface it with C++. It is not trivial. I also worked with ClipperLib and it has its quirks too. But I agree using a n existing language supported by someone else opens up many new possibilities.
>
> >   * You can use Cython for code speed-ups.
>
> I use Boost.Python when interfacing python with C++
>
> >   * There’s a massive pre-existing set of libraries available for all
> >     kinds of things.
>
> This is the best argument in favour of Python.
>
> One argument against python is in my opinion that the language interpreter is somewhere else on the system and not embedded in the application like it is in today's OpenSCAD and also in AngelCAD. With these applications you just install and run scripts. That is a good thing.
>
> With Python you have to have a working Python installation separate from the application and it has to be compatible with the expectations of the application. I have managed to almost trash my entire windows and linux installations, because I did things I should not be doing with Python because I had issues getting things to work. Granted, most people can use Python just fine but I think it is an extra hurdle for a lot of people.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

RevarBat
In reply to this post by nophead
What I read from that comment is that OpenSCAD is not currently a proper language, and it should just be treated like Display Postscript. Which ironically is actually a more capable language, if a lot more of a pain to write in. 

- Revar

On Nov 25, 2020, at 1:30 AM, nop head <[hidden email]> wrote:


OpenSCAD is a language for describing objects, not a programming language. That makes it much simpler than Python and more concise for describing geometry. It also means it doesn't need mutable variables as it is a static description, not a program that runs, so no values need to change over time.

On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm <[hidden email]> wrote:
On 25.11.2020 07:08, Revar Desmera wrote:
> Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.
>

I agree with this line of thinking.

Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "

Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: OpenSCAD language - replace it with Python3

ncsaba
In reply to this post by cacb
Have you checked out https://github.com/SolidCode/SolidPython ?

In my opinion Openscad is just OK as it is... solidpython is doing a
good job too, what might be needed is more libraries written for
solidpython, taking advantage of the power of python. Openscad
libraries can already be wrapped and addressed, but the results
returned by such a library are opaque (being calculated at OpenScad
run-time), while python funtions can return python objects useful for
further processing in the solidpython code. For example it's much
easier to write libraries for connecting objects if you actually have
encapsulated objects with known interfaces to address. It's a
completely different way of doing things than the OpenScad philosophy,
less precise and sloppier perhaps, but it comes down to the compromise
you want to take - have some immediately working code you can play
around with, or plan everything from the beginning and only have it
properly working at the end. With OpenScad you need proper planning,
python invites you to play, pick yours.

As environment I use IntelliJ PyCharm, which allows me to set up
shortcuts to run the solidpython code at the press of a button, then
the OpenScad widnow will refresh automatically. I'm perfectly happy
with that... From a speed perspective it seems workable too, have some
bigger models which run quite reasonably. At the moment solidpython
will generate code where lots of repetition of the same OpenScad code
can occur (if you re-use the same SolidPython object multiple times),
but that seems to not be a problem.

If it would be a help for anybody, I could create a tutorial on how to
set up PyCharm to comfortably work with SolidPython, anybody interested
?

Cheers,
Csaba

On Wed, 2020-11-25 at 09:40 +0100, Carsten Arnholm wrote:

> On 25.11.2020 03:59, 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.
>
> Separating functionality from language interpreter is in my opinion
> a
> good idea. Now, which language to replace the OpenSCAD language with
> is
> a matter of preference. There are many good arguments in support of
> using Python, but there are also many good arguments against it.
>
> My advice to OpenSCAD would be to make an OpenSCAD API with the
> boolean
> engine etc. (but no scripting language features) and implement the
> OpenSCAD language by using the API. The test for true separation
> would
> be if someone could implement a Python or other language interpreter
> using the same API
>
>  > 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()
>
>
> I guess the above is hypothetical. For comparison, in current
> OpenSCAD:
>
> difference() {
>     union() {
>        translate([0,0,5]) sphere(d=10);
>        rotate([0,0,45])
>           translate([0,0,-1])
>              cube(size=10,center=true);
>     }
>     cylinder(d=5,h=5);
> }
>
> In non-hypothetical AngelCAD (using AngelScript) it could written in
> different ways, for example
>
>     solid@ u =
>        translate(0,0,5)
>          *sphere(r:10./2)
>      + rotate_z(deg:45)
>          *translate(0,0,-1)
>             *cube(size:10,center:true);
>      return  u - cylinder(r:5./2,h:5);
>
> Or alternatively
>
>     return
>     difference3d(
>        union3d(
>           translate(0,0,5)
>             *sphere(r:10./2),
>           rotate_z(deg:45)
>             *translate(0,0,-1)
>                *cube(size:10,center:true)
>         ),
>         cylinder(r:5./2,h:5)
>     );
>
>
>  > The benefits could be massive:
>  >
>  >   * Variables are mutable.
>
> Yes, also true in AngelCAD
>
>  >   * You can store geometry in a variable.
>
> Yes
>
>  >   * use/include gets replaced by import, which is less buggy.
>
> You mean Python import. The main thing is using a standard language
> feature. In AngelScript you have #include without the issues related
> to
> include<> and use<> in OpenSCAD
>
>  >   * Efficient data structures like Dictionaries and Classes are
> available.
>
> Yes. Writing your own classes in the scripting language is very
> powerful.
>
>  >   * You can actually read and parse files from disk.
>
> Yes.
>
>  >   * You can import C and Fortran based geometry libraries like
>  >     ClipperLib and use them directly. (Via Cython if needed)
>
> In theory. I have worked a lot with Fortran and developed a way to
> interface it with C++. It is not trivial. I also worked with
> ClipperLib
> and it has its quirks too. But I agree using a n existing language
> supported by someone else opens up many new possibilities.
>
>  >   * You can use Cython for code speed-ups.
>
> I use Boost.Python when interfacing python with C++
>
>  >   * There’s a massive pre-existing set of libraries available for
> all
>  >     kinds of things.
>
> This is the best argument in favour of Python.
>
> One argument against python is in my opinion that the language
> interpreter is somewhere else on the system and not embedded in the
> application like it is in today's OpenSCAD and also in AngelCAD.
> With
> these applications you just install and run scripts. That is a good
> thing.
>
> With Python you have to have a working Python installation separate
> from
> the application and it has to be compatible with the expectations of
> the
> application. I have managed to almost trash my entire windows and
> linux
> installations, because I did things I should not be doing with
> Python
> because I had issues getting things to work. Granted, most people
> can
> use Python just fine but I think it is an extra hurdle for a lot of
> people.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
1234 ... 7