Extending OpenSCAD from assembler to C or Perlish language and adding standard library
Troberg wrote
So, whatever you do, don't break that simplicity.
Agree 100%
And I suspect that 95% of the users don't even need 50% of what is on the
cheat-sheet.
...R
--
Sent from: http://forum.openscad.org/
I've used OpenSCAD for almost a decade and I haven't seen this cheat sheet.
This is great! Thanks!
On Fri, 20 Sep 2019 at 17:36, Troberg troberg.anders@gmail.com wrote:
My short response:
This is what sold me on OpenSCAD:
http://www.openscad.org/cheatsheet/index.html
That cheat sheet contains everything you need to know, in one page. It's so
simple to get started.
So, whatever you do, don't break that simplicity.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 9/22/2019 4:28 PM, tjhowse wrote:
I've used OpenSCAD for almost a decade and I haven't seen this cheat
sheet. This is great! Thanks!
You don't even have to bookmark the URL. It's the "Cheat Sheet" option
on the "Help" menu.
It's actually not hard to replace cube(), cylinder(), sphere(), square(), and circle() by deriving the shapes using just polygon() and linear_extrude().
That still leaves polygon(), polyhedron(), linear_extrude() and rotate_extrude() as impossible to extend the functionality of, though.
A rename() function to rename built-ins would be very helpful for this.
-Revar
On Sep 17, 2019, at 4:46 PM, Doug Moen doug@moens.org wrote:
My original reason for wanting this feature is the Relativity library.
https://github.com/davidson16807/relativity.scad
Relativity extends the standard primitives cube, sphere, etc, with upward compatible new features: a system of property inheritance inspired by CSS.
But, because of the way OpenSCAD works, Relativity needs to invent new names for all of the primitives. So, cube becomes box, cylinder becomes rod, and so on.
So if you want to use Relativity in an existing project, you need to rewrite your code to replace cube with box and so on.
It would be better if Relativity could just add new features to cube, sphere and so on without requiring you to rewrite all of your code.
This would not be a problem in any modern programming language, because all modern languages support name spaces.
The underlying goal of many of the suggestions in my email was to provide tools for library writers, so that libraries can work better. And so that libraries can do things that currently require a change to the C++ core. We need a better library ecosystem. If you don't use libraries, then many of my suggested language changes won't help you.
Doug Moen.
On Tue, Sep 17, 2019, at 7:11 PM, adrianv wrote:
Robin2 wrote
Sorry, but I just can't see the point. What is so sacrosanct about the
name
"cube" that someone can't work with a derived module called (say) "myCube"
without any need for developers to waste time changing the underlying
code.
It seems to me that the main use of redefining modules is to extend
functionality somehow in a library, so the existing built-ins can behave
consistently in the context of the library with other functionality.
The argument that the name "cube" is sacrosanct appears every day on this
forum: many people seem to think that the burden of learning a new command
is quite overwhelming.
I get the impression that there is a large number of libraries with,
perhaps, a lot of close-but-not-perfect duplication amongst them. If that
is
the problem then it should be fixed by some process of getting library
developers to work to a common standard, not by changing the core code.
I would say that the situation is not so clear. There do not appears to be
very many good libraries, well documented, that you can easily find. I'm
not aware of a lot of good libraries that duplicate each other
substantially---maybe just BOSL with parts of dotSCAD. But in my efforts
to hunt for libraries I saw a lot of functionality duplicated many times by
different people, maybe not put out as a library, but code that does the
same class of basic things, written by each individual to support other
purposes, because sharing libraries seems to be, for some reason, a very
difficult thing. And if you write a library for your own use there's little
reason to bother documenting it.
The lack of a really clear mechanism for distributing libraries has been one
problem. It's pretty hard to find the various libraries that are scattered
on Thingiverse. The general hostility of people on the forum to the use of
libraries is another factor that I think has discouraged the development of
a functional approach to libraries.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Treating OpenSCAD something like old Display Postscript has a lot of merit to it. A language meant to be generated only by another more capable programming language. And I’d probably be doing just that in Python if I hadn’t already invested thousand of lines of OpenSCAD code in BOSL/BOSL2 grumble
-Revar
On Sep 19, 2019, at 1:15 AM, Robin2 robin@nbleopard.com wrote:
adrianv wrote
but it's frustrating how hard this is to
do. I have put in error checks and discovered that my code executes
non-sequentially and produces a cryptic OpenSCAD error before it hits my
assertion. I'm not sure what I can do in situations like this. I backed
out an error handling framework I was implementing for a pair of my
modules
because it just didn't work.
I know that it's possible to use Openscad as a general programming language
- but does it make sense to do so?
To my mind it is an extremely useful product that can create files for 3D
representations of objects from some simple instructions such as cube() and
cylinder()
However my inclination is to use a "regular" programming language (such as
Python) to do anything complicated. Python (or your languiage of choice)
can write the Openscad code that works using the core Openscad capabilities.
That means that the "Python" coder is freed from the complex maths needed to
create 3D files that can be interpreted by Slic3r and such like without
being restricted by the peculiarities of the Openscad interpreter.
Input data checks and exception handling are well catered for in regular
programming languages and the programmer has complete control over the order
of doing things.
...R
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 26.09.19 23:42, Revar Desmera wrote:
if I hadn’t already invested thousand of lines of OpenSCAD
code in BOSL/BOSL2 grumble
So what changes in OpenSCAD would help to take away the
grumble?
ciao,
Torsten.
I have a long wishlist, however the things that keep biting me in the keister make for a shorter list. Unfortunately they are also probably the hardest for you to implement, and I apologize in advance for that.
-
Mutable variables. I know that this is nearly impossible to implement with the current design, and I understand the reasoning, even if I don't necessarily agree with the design decisions. The thing is, it becomes much, much harder to write a lot of algorithms when you have to redesign them to use recursion. It's still doable, but it makes for an order of magnitude more frustration and effort. This is coming from someone who has written 3D Bezier patch code and union/diff/intersect for lists of points in OpenSCAD. I used to write code in an RPN stack based language. I hated tail-recursion so much I ended up adding proper loops to that language.
-
Better data structures. Classes would be beautiful. HashTables/Dictionaries, if nothing else. While it is technically possible to make immutable element data structures with lists, it is incredibly inefficient. I've had to abandon various algorithms for doing things like efficient splitting of self intersecting paths, simply because the data structures they build up would make them far less efficient than the naive algorithm. This is possible to implement immutably, but less efficiently. It would still be more efficient than using
search()on a list.
2b.Relatedly, a data structure for polyhedron vertices-and-faces, such that you can add faces to it by lists of vertices, and it will add previously nonexistent vertex points to the vertex list, and add a face indexed into that vertex list, such that it can be eventually passed to polyhedron(). I implemented this using lists in BOSL2 (calling them VNFs), but it's not fast, as it uses search() a lot, and yet still relies on polyhedron() merging duplicate vertices. It makes it far easier to create complex geometry in parts, though. This CAN be done with immutable variables. https://github.com/revarbat/BOSL2/wiki/geometry.scad#5-creating-polyhedrons-with-vnf-structures
-
The work I've seen on passing functions as a first class object has been excellent. Good job there!
-
The ability to rename built-in and existing modules/functions would allow for extending functionality on things like
linear_extrude(),polygon(), andpolyhedron(). -
Access to the bounds of 2D/3D geometry, if not access to the vertex list. Again, I know this is very difficult, and why it is difficult, but the ability to get geometry bounds would enable various functionality that I have been wanting to do, but can't.
-
Ways to call external C/C++ libraries like ClipperLib. Pie in the sky, I know, but this is something I can do in Python, Ruby, and many other languages. It would have saved me from spending dozens of hours writing boolean path code in OpenSCAD. Even just access to calls in the already included C++ geometry libraries could be very useful.
-
Ability to read a file from disk, and better string/binary processing functions. Wouldn't it be nice to be able to read height data from a Digital Elevation Model, instead of having to find or create some way to convert the file to a greyscale image first? And there are file formats where the data isn't directly convertible to a height-field, yet it would be nice to read the data from them.
I also have a wishlist of easier to implement features. In general these are already implemented in BOSL/BOSL2, but would be a lot more efficient in C++:
-
built-in
rotate(a=SPIN_ANGLE, from=VECTOR1, to=VECTOR2)which is effectivelyrotate(v=cross(VECTOR1,VECTOR2),a=angle_between(VECTOR1,VECTOR2)) rotate(SPIN_ANGLE) ... -
built-in functions for rotate/translate/scale/mirror that can manipulate lists of 2D/3D points.
-
built-in functions for union/difference/intersection/offset that can perform boolean geometry on lists on 2D points forming closed polygons. These are useful when you need to form a complex path to pass to a function like
sweep()orskin(). Having built-in functions forsquare()andcircle()that return lists of 2D points helps with this. Adrian and I implemented all these in BOSL2, but they are FAR FAR slower and less accurate than just letting ClipperLib do it in C++. https://github.com/revarbat/BOSL2/wiki/geometry.scad#4-regions-and-boolean-2d-geometry -
Adrian created a turtle-graphics type function in BOSL2 that turns out to be ridiculously useful in making pointlist paths for irregular polygons, that can be instantiated into 2D geometry via
polygon(), thenlinear_extrude()d orrotate_extrude()d. This doesn't really scream to be a built-in, but it's just so handy, it might be something to think about, especially since you can use it with the above boolean path code. https://github.com/revarbat/BOSL2/wiki/shapes2d.scad#turtle -
A way to, given a list of vertices, and a list of faces (indexed into the vertex list), triangulate any faces that have more than 3 vertices. Returns a new list of triangulated faces. Because CGAL just doesn't always realize non-triangle faces are planar. Actually, this might not be a problem any longer in recent versions of OpenSCAD. Not sure.
-
Built-in functions for calculating pointlist paths from lists of arbitrary-degree bezier control points. These can be used to built 2D paths, or, with the help of the VNF structure mentioned above, create polyhedrons from 3D bezier patches.
I'm sure I'm forgetting a lot of things, but these were what come to mind immediately as useful, but hard or inefficient to implement in libraries.
- Revar
On Sep 28, 2019, at 11:42 AM, Torsten Paul Torsten.Paul@gmx.de wrote:
On 26.09.19 23:42, Revar Desmera wrote:
if I hadn’t already invested thousand of lines of OpenSCAD
code in BOSL/BOSL2 grumble
So what changes in OpenSCAD would help to take away the
grumble?
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Actually, thinking about it, you could implement immutable dictionaries fairly efficiently via reference counting.
- Revar
On Sep 28, 2019, at 7:38 PM, Revar Desmera revarbat@gmail.com wrote:
I have a long wishlist, however the things that keep biting me in the keister make for a shorter list. Unfortunately they are also probably the hardest for you to implement, and I apologize in advance for that.
-
Mutable variables. I know that this is nearly impossible to implement with the current design, and I understand the reasoning, even if I don't necessarily agree with the design decisions. The thing is, it becomes much, much harder to write a lot of algorithms when you have to redesign them to use recursion. It's still doable, but it makes for an order of magnitude more frustration and effort. This is coming from someone who has written 3D Bezier patch code and union/diff/intersect for lists of points in OpenSCAD. I used to write code in an RPN stack based language. I hated tail-recursion so much I ended up adding proper loops to that language.
-
Better data structures. Classes would be beautiful. HashTables/Dictionaries, if nothing else. While it is technically possible to make immutable element data structures with lists, it is incredibly inefficient. I've had to abandon various algorithms for doing things like efficient splitting of self intersecting paths, simply because the data structures they build up would make them far less efficient than the naive algorithm. This is possible to implement immutably, but less efficiently. It would still be more efficient than using
search()on a list.
2b.Relatedly, a data structure for polyhedron vertices-and-faces, such that you can add faces to it by lists of vertices, and it will add previously nonexistent vertex points to the vertex list, and add a face indexed into that vertex list, such that it can be eventually passed to polyhedron(). I implemented this using lists in BOSL2 (calling them VNFs), but it's not fast, as it uses search() a lot, and yet still relies on polyhedron() merging duplicate vertices. It makes it far easier to create complex geometry in parts, though. This CAN be done with immutable variables. https://github.com/revarbat/BOSL2/wiki/geometry.scad#5-creating-polyhedrons-with-vnf-structures
-
The work I've seen on passing functions as a first class object has been excellent. Good job there!
-
The ability to rename built-in and existing modules/functions would allow for extending functionality on things like
linear_extrude(),polygon(), andpolyhedron(). -
Access to the bounds of 2D/3D geometry, if not access to the vertex list. Again, I know this is very difficult, and why it is difficult, but the ability to get geometry bounds would enable various functionality that I have been wanting to do, but can't.
-
Ways to call external C/C++ libraries like ClipperLib. Pie in the sky, I know, but this is something I can do in Python, Ruby, and many other languages. It would have saved me from spending dozens of hours writing boolean path code in OpenSCAD. Even just access to calls in the already included C++ geometry libraries could be very useful.
-
Ability to read a file from disk, and better string/binary processing functions. Wouldn't it be nice to be able to read height data from a Digital Elevation Model, instead of having to find or create some way to convert the file to a greyscale image first? And there are file formats where the data isn't directly convertible to a height-field, yet it would be nice to read the data from them.
I also have a wishlist of easier to implement features. In general these are already implemented in BOSL/BOSL2, but would be a lot more efficient in C++:
-
built-in
rotate(a=SPIN_ANGLE, from=VECTOR1, to=VECTOR2)which is effectivelyrotate(v=cross(VECTOR1,VECTOR2),a=angle_between(VECTOR1,VECTOR2)) rotate(SPIN_ANGLE) ... -
built-in functions for rotate/translate/scale/mirror that can manipulate lists of 2D/3D points.
-
built-in functions for union/difference/intersection/offset that can perform boolean geometry on lists on 2D points forming closed polygons. These are useful when you need to form a complex path to pass to a function like
sweep()orskin(). Having built-in functions forsquare()andcircle()that return lists of 2D points helps with this. Adrian and I implemented all these in BOSL2, but they are FAR FAR slower and less accurate than just letting ClipperLib do it in C++. https://github.com/revarbat/BOSL2/wiki/geometry.scad#4-regions-and-boolean-2d-geometry -
Adrian created a turtle-graphics type function in BOSL2 that turns out to be ridiculously useful in making pointlist paths for irregular polygons, that can be instantiated into 2D geometry via
polygon(), thenlinear_extrude()d orrotate_extrude()d. This doesn't really scream to be a built-in, but it's just so handy, it might be something to think about, especially since you can use it with the above boolean path code. https://github.com/revarbat/BOSL2/wiki/shapes2d.scad#turtle -
A way to, given a list of vertices, and a list of faces (indexed into the vertex list), triangulate any faces that have more than 3 vertices. Returns a new list of triangulated faces. Because CGAL just doesn't always realize non-triangle faces are planar. Actually, this might not be a problem any longer in recent versions of OpenSCAD. Not sure.
-
Built-in functions for calculating pointlist paths from lists of arbitrary-degree bezier control points. These can be used to built 2D paths, or, with the help of the VNF structure mentioned above, create polyhedrons from 3D bezier patches.
I'm sure I'm forgetting a lot of things, but these were what come to mind immediately as useful, but hard or inefficient to implement in libraries.
- Revar
On Sep 28, 2019, at 11:42 AM, Torsten Paul Torsten.Paul@gmx.de wrote:
On 26.09.19 23:42, Revar Desmera wrote:
if I hadn’t already invested thousand of lines of OpenSCAD
code in BOSL/BOSL2 grumble
So what changes in OpenSCAD would help to take away the
grumble?
ciao,
Torsten.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
RevarBat wrote
I have a long wishlist,
[......]
- Ways to call external C/C++ libraries like ClipperLib. Pie in the sky,
I know, but this is something I can do in Python, Ruby, and many other
languages.
I have read through this Post and as newish user of Openscad I must say I
understand very little of it. If these points are mainly about adding extra
functionality to Openscad then it would be very useful if someone could
explain what sort of practical things the extra capabilities might be useful
for.
On the specific point of linking with other languages it seems to me it
would make sense to turn that on its head and use another language (such as
Python) to generate Openscad code as it could then draw on all the
wide-ranging capabilities available to Python (or whatever language you
prefer) without needing to make any changes to Openscad.
...R
--
Sent from: http://forum.openscad.org/
Revar: Everything on your list is possible, given sufficient development resources,
and given the willingness to make language language changes (there's a tradeoff:
new features add complexity while making the language more powerful).
I want to mention that mutable variables are not "nearly impossible to implement
with the current design". I proposed a design for adding mutable variables while
retaining backward compatibility, years ago:
https://github.com/openscad/openscad/wiki/Mutable-Variables
The key idea is: You can't redefine the = operator as an assignment
operator for mutable variables without breaking backward compatibility, so
I introduced := as the assignment operator.
The reaction was mixed.
- One person, who has written complex algorithms using data structures in
OpenSCAD, was enthusiastic (but hated the syntax). - Another person claimed that this would destroy referential transparency
and make it impossible to use data parallelism to make OpenSCAD run
much faster. This isn't actually true, though. - Other people pointed out that the syntax is ugly and that grafting
imperative features into OpenSCAD adds too much complexity.
I implemented a simpler and more refined version of that old proposal
in Curv, which is my personal OpenSCAD successor. The syntax I use for
mutable variables could be added to OpenSCAD without breaking
backward compatibility. And it doesn't break referential transparency.
Curv is required to be referentially transparent, because I compile Curv
into data parallel code that renders quickly.
I think that the people who want mutable variables in OpenSCAD
would prefer a more Pythonic syntax: a=b is used both to define
a new variable, and to reassign an existing variable. That would make
variables easier to understand and use, but it would break backward
compatibility.
RapCAD is a fork of OpenSCAD that works this way. It has mutable variable
and various other improvements. https://github.com/GilesBathgate/RapCAD
RapCAD doesn't have most things in Revar's wishlist, and to get that, I think
you realistically need to look at doing OpenSCAD things from within a
general purpose language. I'm skeptical that OpenSCAD will ever be
extended into a GP language, and some people in this thread have already
spoken against the idea.
AngelCAD is an embedding of OpenSCAD-like features in a GP language
called AngelScript. Carsten mentions AngelCAD regularly on this forum.
https://github.com/arnholm/angelcad
If you want to use a more mainstream language, like Javascript or Python,
then you should consider using OpenJSCAD or SolidPython.
Both projects have been around for many years and are still being updated.
OpenJSCAD supports both OpenSCAD and Javascript syntax,
and it runs in a web browser. https://openjscad.org/
SolidPython lets you define models using Python, then it generates
OpenSCAD code to render the model. https://github.com/SolidCode/SolidPython
Doug Moen.