OpenSCAD language - replace it with Python3
I don’t feel that any change in syntax is going to provide any substantial improvement to modelling expressions of openscad.
While I’m no expert, OpenSCAD has the look and feel of a macro assembler and for any design I’ve tackled it seems suited to the task. I do find however, that a design of any complexity brings processing to a crawl, and that (as I understand it) is due to the unthreadable nature of CSG. I don’t imagine grafting OpenSCAD onto a Python or C++ or Pascal syntax is magically going to make that problem go away.
On the other hand, the extensible nature of OpenSCAD allows for the developer to make OpenSCAD as sophisticated as one might like… at least from the standpoint of expressive power (although it would be REALLY nice if there was a mechanism to call the overridden module/function rather than a forced recursion).
Rather than change the syntax, I would rather see something like a OpenSCAD API or compiler that would allow for one to translate source into compiled code and link it into the OpenSCAD engine. Many of us implement functionality in “user space” that has to be abandoned simply because the performance hit becomes too severe.
Perhaps what I’m really saying is I’d like to contribute to the core development but the current repository is too daunting. Perhaps an attractive approach would be for the existing source to be arranged in such a way that newbie contributors could provide extensions to core functionality without having to understand the entire github source. I appreciate that something like that is asking for effort from already extended volunteers… but a gentler path for newcomers might have payback in an easier load for developers to carry.
Like OpenSCAD itself, it’s easy to write a “Hello World” with cubes and cylinders etc… perhaps even a “hello world” tutorial for newbie developers would work.
Alan Cox-2 wrote
the threshold for a model being "wrong" for OpenSCAD? Note that OpenSCAD
certainly is a language in the classical sense. It's got functions and
recursion and can theoretically do anything. It's just that doing things
is
not always easy, or efficient. The code is harder to write. Of course,
once it's written then the complexity is hidden, and the actual models
are
easy to construct.
It's not a programming language in the classic iterative sense because it
has no external inputs or behaviour changes. It's just a data structure
encoding. There is a fixed mapping between an openscad file and an STL
file so they are basically the same thing. One happens to be easier
to write.
Not sure what you mean. It's not iterative---it's a functional language,
using recursion instead of iteration. Still a programming language. It's
Turing complete. Every programming language is a fixed mapping between its
inputs and its outputs, unless you introduce a source of random bits. I
mean, only certain types of I/O are possible in OpenSCAD, but that doesn't
make it not a programming language.
--
Sent from: http://forum.openscad.org/
Openscad is a fairly pure functional programming language, which makes it
somewhat hard to get used to if all you have used is procedural languages.
It is fairly unique amongst functional languages in that functions are not
passable as arguments, however (unless that has changed, I remember there
has been much discussion of the subject)
On Thu, 26 Nov 2020, 21:15 adrianv, avm4@cornell.edu wrote:
Alan Cox-2 wrote
the threshold for a model being "wrong" for OpenSCAD? Note that
OpenSCAD
certainly is a language in the classical sense. It's got functions and
recursion and can theoretically do anything. It's just that doing
things
is
not always easy, or efficient. The code is harder to write. Of course,
once it's written then the complexity is hidden, and the actual models
are
easy to construct.
It's not a programming language in the classic iterative sense because it
has no external inputs or behaviour changes. It's just a data structure
encoding. There is a fixed mapping between an openscad file and an STL
file so they are basically the same thing. One happens to be easier
to write.
Not sure what you mean. It's not iterative---it's a functional language,
using recursion instead of iteration. Still a programming language. It's
Turing complete. Every programming language is a fixed mapping between
its
inputs and its outputs, unless you introduce a source of random bits. I
mean, only certain types of I/O are possible in OpenSCAD, but that doesn't
make it not a programming language.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 27.11.20 03:30, A. Craig West wrote:
functions are not passable as arguments, however (unless that has
changed, I remember there has been much discussion of the subject)
They are for about a year now (in the snapshot version with the
feature enabled).
https://github.com/thehans/funcutils
ciao,
Torsten.
In the dev version there is an experimental feature you can turn on called
"function literals" that allows functions to be passed.
acwest wrote
Openscad is a fairly pure functional programming language, which makes it
somewhat hard to get used to if all you have used is procedural languages.
It is fairly unique amongst functional languages in that functions are not
passable as arguments, however (unless that has changed, I remember there
has been much discussion of the subject)
On Thu, 26 Nov 2020, 21:15 adrianv, <
avm4@
> wrote:
Alan Cox-2 wrote
the threshold for a model being "wrong" for OpenSCAD? Note that
OpenSCAD
certainly is a language in the classical sense. It's got functions
and
recursion and can theoretically do anything. It's just that doing
things
is
not always easy, or efficient. The code is harder to write. Of
course,
once it's written then the complexity is hidden, and the actual models
are
easy to construct.
It's not a programming language in the classic iterative sense because
it
has no external inputs or behaviour changes. It's just a data structure
encoding. There is a fixed mapping between an openscad file and an STL
file so they are basically the same thing. One happens to be easier
to write.
Not sure what you mean. It's not iterative---it's a functional language,
using recursion instead of iteration. Still a programming language.
It's
Turing complete. Every programming language is a fixed mapping between
its
inputs and its outputs, unless you introduce a source of random bits.
I
mean, only certain types of I/O are possible in OpenSCAD, but that
doesn't
make it not a programming language.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
That explains it then, I thought it was available, but for compatibility
reasons I limit myself to release versions
On Thu, 26 Nov 2020, 21:38 adrianv, avm4@cornell.edu wrote:
In the dev version there is an experimental feature you can turn on called
"function literals" that allows functions to be passed.
acwest wrote
Openscad is a fairly pure functional programming language, which makes it
somewhat hard to get used to if all you have used is procedural
languages.
It is fairly unique amongst functional languages in that functions are
not
passable as arguments, however (unless that has changed, I remember there
has been much discussion of the subject)
On Thu, 26 Nov 2020, 21:15 adrianv, <
avm4@
> wrote:
Alan Cox-2 wrote
the threshold for a model being "wrong" for OpenSCAD? Note that
OpenSCAD
certainly is a language in the classical sense. It's got functions
and
recursion and can theoretically do anything. It's just that doing
things
is
not always easy, or efficient. The code is harder to write. Of
course,
once it's written then the complexity is hidden, and the actual
models
are
easy to construct.
It's not a programming language in the classic iterative sense because
it
has no external inputs or behaviour changes. It's just a data
structure
encoding. There is a fixed mapping between an openscad file and an STL
file so they are basically the same thing. One happens to be easier
to write.
Not sure what you mean. It's not iterative---it's a functional
language,
using recursion instead of iteration. Still a programming language.
It's
Turing complete. Every programming language is a fixed mapping between
its
inputs and its outputs, unless you introduce a source of random bits.
I
mean, only certain types of I/O are possible in OpenSCAD, but that
doesn't
make it not a programming language.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@.openscad
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I honestly don’t care whether we go to Python or Ruby or Javascript. I just want a well developed, well designed scripting language, with proper data structures and classes, that is at least somewhat C-like.
I can care less if it has indentation as a syntax or not. I used to hate the idea of Python’s indentation requirements. Then I found that said requirements were pretty much how I wanted to indent naturally anyways.
Ruby’s syntax, as I recall, has the nice feature that function return values are implied as the last calculation, which could shorten syntax for SCAD-like scripts.
JavaScript, while not my favorite syntax, can be securely embeddable, and can have Just In Time compilation. There’s ALREADY a JavaScript OpenSCAD-a-like called OpenJSCAD, that can read OpenSCAD source files. However, it lacks some functionality (hull, minkowski, projection), hasn’t been updated in 3 years, only really runs in a web browser, and isn’t command-line scriptable.
I dunno. I could be all for piling onto OpenJSCAD and fixing it’s limitations. Packing it up as a standalone app.
- Revar
On Nov 26, 2020, at 2:36 AM, Tim Hawkins tim.thawkins@gmail.com wrote:
I would rather we used JavaScript instead of python, V8 has extension mechanisms that would allow it to be embedded inside the existing app, and have the openscad objects and backend plugged in. Plus JS is block structured rather than indent structured, which is the same as the current implementation, which minimizes impact on people.
There are 1000's of JavaScript embeddable editors that do full syntax highlighting, folding and dynamic formatting, there are very few for python.
On Thu, Nov 26, 2020, 14:34 MichaelAtOz <oz.at.michael@gmail.com mailto:oz.at.michael@gmail.com> wrote:
One unique aspect of OpenSCAD is preview.
Having a usually snappy visualisation of your geometry is invaluable.
This is where enhancements come in conflict.
Because preview does not actually make geometry you can't have features
which require the geometry to be calculated, it will kill the advantage of
preview.
Like getting a vector of the points of an object.
g = render() { someObjects(); } // caching may help, but it would be
painful.
extremely simple programs. The simplest program in OpenSCAD is
"cube(10);".
That plus Preview, is OpenSCAD.
If OpenSCAD did not have Preview, I doubt it would have the uptake it has.
Thus anything without both will no longer be OpenSCAD. It is a niche.
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/ 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
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2020-11-27 03:11, Hugo Jackson wrote:
I do find however, that a design of any complexity brings processing
to a crawl, and that (as I understand it) is due to the unthreadable
nature of CSG.
That's wrong. You can perfectly well do threading with CSG, and AngelCAD
does it. That is part of the reason it is much faster than OpenSCAD,
even when processing .scad scripts. Why OpenSCAD doesn't is purely
related to implementation issues, it is not a nature of CSG. Yes, there
are some limitations that will give diminishing returns late in the
processing, but in sum you can increase performance by at least an an
order of magnitude using threading.
Rather than change the syntax, I would rather see something like a
OpenSCAD API or compiler that would allow for one to translate source
into compiled code and link it into the OpenSCAD engine.
That was my proposal earlier also. I think it is a bad mistake to put in
the subject of this thread "OpenSCAD language - replace it with
Python3". It seems like an initiative to shut the discussion down,
because that proposal will for sure end in a "No".
Obviously, providing some other language interface, like Python or
whatever should not mean to abandon, deprecate or "replace" the OpenSCAD
.scad language. Anyone serious in software maintenance knows that you
have have backwards compatibility. So instead of saying the language
will be "replaced" one should declare that it will be supported. But
that does not preclude progress using other languages.
Offering another language therefore requires the language to be
separated from the boolean algorithms and an API provided.
The first milestone of such work should be to implement and document the
API, and then re-implement the existing .scad language on top of it,
using the existing examples as proof that it works. Once that is
complete, then the API can be offered to others to implement their
Python, Javascript, AngelScript ... or whatever ... language front ends.
Carsten Arnholm
Not sure what you mean. It's not iterative---it's a functional language,
using recursion instead of iteration. Still a programming language. It's
Turing complete. Every programming language is a fixed mapping between its
inputs and its outputs, unless you introduce a source of random bits. I
mean, only certain types of I/O are possible in OpenSCAD, but that doesn't
make it not a programming language.
That was sort fo the point I was trying to make - if you just plug
it into python it is not a functional language/data structure any more.
Everything in the way openscad works is built around that model. Try
adding random() to OpenSCAD and watch the world fall apart around you.
All the caching and other things it does stop working.
If you try and use python as the openscad language you'd have to rewrite
a lot of the core of the program. At that point you might as well just
use the libraries that OpenSCAD does and chunks of the OpenSCAD object
manipulation code to write something different, that was a proper python
library for manipulating 3D constructive geometry - like Blender has.
Alan
On 11/26/2020 4:43 PM, adrianv wrote:
I asked about libraries when I first encountered OpenSCAD a couple years ago,
I think. And I got a remarkably negative reception, with hostility to
libraries. A vocal group seemed to oppose the idea that libraries should
exist---everybody should design their own code in private from the ground
up. Maybe things have improved a bit, but there's still no good mechanism
for managing them, or dealing with them, and we have the bug with "use" that
creates big performance issues, which is apparently seen as very low
priority. (The issue for this bug was first opened in 2012, I think, by
someone who thought the fix was not hard.)
I don't remember so much hostility as apathy and disinterest. I know
that was my reaction. I reviewed my ~10K line project and came to the
conclusion that only a few percent of it could reasonably be replaced by
generic libraries. I simply don't spend enough time reinventing that
stuff to even make it worth the effort to go find what exists, much less
to spend any time building up a library/package infrastructure.
The vast majority of my work has been in modeling - not in the computer
sense of creating a 3D representation of something, but in the generic
sense of producing a duplicate of an existing physical object. I'm not
doing mechanical design, so I look at screw-and-gear libraries and say
"that's nice, but I don't have any use for it". I look at "up", "down",
"xscale", "triangle", and similar, and say "uh, what's wrong with
translate, scale, and circle?". None of the libraries that I've looked
at have provided enough value to me for me to spend the effort to adopt
them.
Libraries are fine. Libraries are great. By all means, write them. By
all means, build dependency/version trackers and packaging systems. But
so far I don't have any interest in using them or working on them.