Lua luau.
I do not think I have ever come across a geometrical language which was
more parametric in nature and that adhered to ( and of course just my
opinion ) a more consistent functional implementation. OpenSCAD is not
functional enough for me. Imperative bits about the edges like for loops
bug me. Also rather than the core hanging off the fundamentals of the
boolean it would be sketches and planes and such like for me. FreeCad has
some sort of python API bolted on it doesn't it?
Am 19.03.21 um 22:26 schrieb Revar Desmera:
Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!).
And a great standard library and easy accessibility. Lua is even easy to learn even for beginners and useful also in other domains. I've written Lua bindings to a large C++ program a while ago and can only say that it was a very good experience. I also have several friends with 3D printers and a good technical interest, motivation and understanding. They all shy away from OpenSCAD due to the inaccessibility imposed on it by its niche language.
Others have mentioned the concern of backwards-compatibility. Of course this should not and does not need to be broken at all: Lua could simply co-exist with the OpenSCAD language, without breaking anything. This would initially introduce a double load on e.g. documentation, but it would allow to shape the future of the language bindings independent of each other. I would not be surprised if the interest in the OpenSCAD language quickly faded out.
Also, when things get difficult, it is often said that the language is not the real problem and that the goal can as well be reached with the OpenSCAD language. Well, of course it can. I guess there is no problem that could eventually not be solved in OpenSCAD. However, at what cost?
I've recently implemented a few shapes that are still relatively simple and which I could have completed in an imperative language in a short time. But even with the great help I've gotten here, I still have to sit down and spend much extra time for making the algorithmic solution fit the language, foregoing program design and code maintainability.
Best regards,
Carsten
Whosawhatsis wrote
Changing OpenSCAD to use a different language is a terrible idea, because
you would break compatibility with all of the existing OpenSCAD code, and
force the people who know how to use it to re-learn it. The python 2.x to
python 3.x changed enough to make existing projects and libraries
incompatible, and it's taken over 10 years to get people to use the new
system. Trying to rip out the core of the language syntax and replace it
would be even worse.
I strongly agree. I probably have in excess of a million lines of OpenSCAD
code, and no one else will rewrite them for me...
Improve the existing language, instead of replacing it with something new.
Bring in needed features, not a dump and rewrite.
Also, there is a benefit of having a language designed for the purpose,
instead of some framework on top of a generic language with all the extra
baggage which comes with that.
--
Sent from: http://forum.openscad.org/
With the exception of function literals, which are nice, and lazy unions, which seems not quite ready yet, I’ve seen little effort put into missing functionality. Things like:
- mutable variables
- better data structures (tables, structures, etc)
- multiple assignment (ie:
a,b,c = foo()) - threadability
- File IO
- geometry data access
- better library management.
Hell, you can do tables and structures immutably if you absolutely must, and it’d still be a big win.
But nobody seems to be doing these things, and my own code submissions have not been approved.
Fine. Keep the original OpenSCAD language for backwards compatibility. But grafting in a well developed language can solve so very many problems in one stroke.
I’ve designed and implemented four domain specific languages in the last 30 years. It is almost never a better idea than using a well developed existing language.
-Revar
On Mar 20, 2021, at 2:35 AM, Troberg troberg.anders@gmail.com wrote:
Whosawhatsis wrote
Changing OpenSCAD to use a different language is a terrible idea, because you would break compatibility with all of the existing OpenSCAD code, and force the people who know how to use it to re-learn it. The python 2.x to python 3.x changed enough to make existing projects and libraries incompatible, and it's taken over 10 years to get people to use the new system. Trying to rip out the core of the language syntax and replace it would be even worse.
I strongly agree. I probably have in excess of a million lines of OpenSCAD code, and no one else will rewrite them for me...
Improve the existing language, instead of replacing it with something new. Bring in needed features, not a dump and rewrite.
Also, there is a benefit of having a language designed for the purpose, instead of some framework on top of a generic language with all the extra baggage which comes with that.
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
/Sorry, buy we have been here./
RevarBat wrote
Okay, everyone remember when I proposed ripping the OpenSCAD language out
of OpenSCAD and replacing it with Python?
Yes. here
http://forum.openscad.org/OpenSCAD-language-replace-it-with-Python3-td30692.html#a30696
After 7 pages on the forum it broke down to
OpenSCAD: You point the gun at your foot, and shoot twice. Since you
let the two bullet holes just barely touch, you get a CGAL error.
Having actually tried it and refreshed my memory on the behavior:
OpenSCAD: You point the gun at your foot, and shoot twice. Since you let
the two bullet holes just barely touch, you get a warning that your foot
may not be a valid 2-manifold and may need repair!
In there was
RevarBat wrote
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
OpenSCAD IS the language. Without the language it is a bunch of open
source libraries.
OpenSCAD is non-imperative. It is NOT "somewhat C-like".
It IS what it is, OpenSCAD, you obviously want NOT-OpenSCAD.
(Not speaking as the Forum-Admin) Please go and create your NOT-OpenSCAD, it
doesn't look like those here who want to evolve OpenSCAD, want to drop it
and radically transform it to Python, Lau, Java*, Ruby, Haskell, or
whatever.
Sorry, but
RevarBat wrote
I honestly don’t care whether we go to
You seem to get frustrated once a quarter. Unless you go and lead a new
project (and forum/mailing-list) start designing it and recruit a community,
you have reliable (mostly) evolving non-imperative, really good...
/it is something like a 3D-compiler that reads in a script file that
describes the object and renders the 3D model from this script file/
http://forum.openscad.org/file/t359/Capture-about-openscad.jpg
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/
Revar said:
Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?
Yeah, well Python isn’t easily embeddable, and has security implications.
Libfive Studio (which has an OpenSCAD-like GUI) has recently been changed to support Python, in addition to the previous language, Guile Scheme. So that is a new option for somebody looking for an OpenSCAD-like experience, except with Python. Libfive uses signed distance fields to model 3D solids, instead of triangle meshes, so you are using a somewhat different set of primitives. https://github.com/libfive/libfive
So I guess Python is embeddable. As for the security implications, yes this is a concern for libfive, although the author is considering mitigations.
For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on.
My project, Curv, is about developing a new geometric modelling language. Apart from the fact that it's a fun project, one reason for not using Python or Lua or whatever is performance. Curv compiles into either C++ or GPU shader code (GLSL) for performance reasons. I can already generate a million or so triangles in a few seconds using C++ as a JIT compiler, much faster than OpenSCAD for the kinds of models I care about. One goal for this year is to be able to generate triangle meshes using the GPU, which should be a hundred times faster than that. I plan to be able to do this either in a native application or inside a web browser. There aren't any existing languages with the kind of GPU code generation that I need. The other reason for a new language is that I want to use a simple declarative language when I'm designing a model (no boilerplate or bureaucracy, like OpenSCAD), and I want to use an imperative language with modern features when I'm implementing a performance critical graphics algorithm. Curv is kind of unique in supporting both styles of programming in a single language. So that's the reason. Curv isn't like OpenSCAD, it's not a wrapper around CGAL.
BTW I'm not soliciting new users on this list. Curv is still a research project, and can't yet do a lot of what OpenSCAD does.
I wonder if all that energy going in circles could be
channeled into something that could lead to some actual
OpenSCAD improvement.
What about dictionaries, how could a minimal solution
look like?
Which features are at least required to cover some of
the use cases where currently awkward constructs are
needed and how could those look from language user
perspective?:
-
define a fixed set of key value pairs (should key be
limited somehow, e.g. strings only?) -
access value via key
-
allow iteration of key, values
Anyone interested in having this discussion in a new
forum thread? If I can find some more spare time, I
might try to get that started in a new post, but I'm
happy if someone else wants to share ideas first.
ciao,
Torsten.
I'm not sure what specific problems dictionaries would solve. There is this
https://github.com/openscad/openscad/pull/3087 which is structs rather than
dicts. I have used dictionary type things occasionally in OpenSCAD, using
the search() function to handle the lookup. Not particularly efficient, but
what is the application for dicts with huge lists of keys? Structs would
make for more readable code and easier to use functions, because multiple
returns could be labeled instead of appearing as mysterious lists of
objects. But these don't seem like fundamental changes.
It seems like if you want to think about what the problems are that limit
implementation of real algorithms it probably comes down to the efficiency
of making small changes to large objects. If an algorithm requires
maintaining a large data structure of some kind and inserting/deleting items
in it, that means, in OpenSCAD, constantly copying a huge list to make each
small change, which means performance will likely be poor. So even if I can
contrive a way to write my algorithm recursively, I'm likely to run into
trouble with performance. Basically to implement an algorithm efficiently
it needs to be possible to conceptualize the algorithm as a list
comprehension rather than a recursion, so that you can rewrite the data
structure en-masse, so to speak, rather than rewriting it a piece at a time.
tp3 wrote
I wonder if all that energy going in circles could be
channeled into something that could lead to some actual
OpenSCAD improvement.
What about dictionaries, how could a minimal solution
look like?
Which features are at least required to cover some of
the use cases where currently awkward constructs are
needed and how could those look from language user
perspective?:
-
define a fixed set of key value pairs (should key be
limited somehow, e.g. strings only?) -
access value via key
-
allow iteration of key, values
Anyone interested in having this discussion in a new
forum thread? If I can find some more spare time, I
might try to get that started in a new post, but I'm
happy if someone else wants to share ideas first.
ciao,
Torsten.
OpenSCAD mailing list
To unsubscribe send an email to
discuss-leave@.openscad
--
Sent from: http://forum.openscad.org/
On 3/20/2021 1:41 PM, Torsten Paul wrote:
What about dictionaries, how could a minimal solution
look like?
I'm starting (just barely) to work on structure/dictionary/object
support, based on your object work, primarily to support complex return
values from functions like my text metrics functions. I might make some
progress this weekend. The first round would allow only
internally-generated values, but a subsequent round could introduce
syntax for creating them from OpenSCAD expressions.
Most languages I'm aware of do provide both dictionaries
and objects/structs. The obvious difference is that the
dictionaries are much more limited but allow access via a
dynamically produced key where objects usually only allow
statically defined names for access (needing some kind of
runtime reflection to make it dynamic).
So while I would like to see the objects proposal move
ahead, that one might take a while at the current pace.
As multiple mentions of a dictionary type data structure
happened lately and there's a couple of implementations
around, I was wondering if that could be an easier way
of covering some common use cases.
But then, if the outcome of the discussion is just again
"we need lots of new stuff" but every specific answer to
any proposal is "no, not that one", that's fine too. It's
not like I personally have lots of spare time to fill.
ciao,
Torsten.