Extending OpenSCAD from assembler to C or Perlish language and adding standard library

classic Classic list List threaded Threaded
110 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

JordanBrown
On 9/17/2019 5:51 PM, MichaelAtOz wrote:
I have not detected hostility [ towards libraries ], and I don't think views of roll their own are trying to discourage developments.

Right.  I think it's all "well, OK, but why bother?".

My big project is a 1:25.4 scale model of my house.  It's about 7500 lines, mostly in modeling the furniture.  I just walked through the "library" files, the files that have functionality that I thought was sort of common.  Much of that was "common" to my particular problems - like defining a generic cabinet with drawers.  I tallied maybe 300 lines that I thought would be of sort-of-general use.

In skimming through BOSL, at a guess it would replace half of those.  (And, notably, *not* the single most difficult trig problem - finding parameters of a segment of a circle given other parameters.)  It would have given me the Bezier functions that I had to steal from somewhere else.

So, BOSL would give me *at best* a 2-5% reduction in the number of lines I had to write.  That's better than zero, but it's not exactly life-changing.

Maybe (but only maybe) some of my modeling would have been easier if it had been cast in terms of, say, its path manipulation, but that would have then required learning how and when to use that feature to achieve a particular goal.

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Robin2
In reply to this post by lostapathy
lostapathy wrote
>> I think the reason they don't gain the same traction as conventional
>> programming languages is that a vocal population here on the forum thinks
>> they are unnecessary because the things *those*people*want*to*do* are
>> easy.
>> And for some reason some of these people *vocally*oppose* libraries
>> instead
>> of just ignoring them.  

I have no objection to that approach.

But what I do object to are demands for changes to the Openscad core that
are unlikely to be useful for more than a handful of users.

If something can be achieved with a module built on the existing Openscad
core then I can't see any reason to include that capability in the core.

I don't see the library "problem" being resolved without some leadership
(and I am not volunteering, I don't know enough about it). Someone (or some
small group) needs to pick one or more libraries and make them the primary
libraries. Then a case could be made that other libraries should be
compatible. I don't think this is a simple process.

I am more familiar with the Arduino system. It includes a group of basic
libraries - each with very limited functionality. However some of them are
very far from "best in class". Then there are hundreds of 3rd party
libraries most with almost no documentation apart from the source code. And
the two that I am familiar with that do have extensive documentation have
some substantial gaps in the documentation.

I suspect where the Arduino system differs is that some of its libraries are
very widely used and have become de-facto standards because of that. I get
the impression that none of the Openscad libraries has floated to the top of
the charts in the same way, perhaps because the scope of Openscad usage is
much broader.

Maybe there is also a sense in which some of the Openscad libraries set out
to be "swiss army knives" whereas the Arduino libraries are more focused.

...R



--
Sent from: http://forum.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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

nophead
I think the difference is Arduino libraries and most other software libraries are just libraries that add some specific functionality but OpenSCAD libraries like Relativity and BOSL are actually frameworks that totally change the way objects are coded. They change the look of the code entirely so it starts to look like a different language.

I have no objection to people writing libraries. I just try to explain why they don't gain traction like they do for other languages. I use Python libraries all the time but I just add an import and use some functions. It doesn't change the way I code the rest of the project. Even adding something a big as a Web server with Flask doesn't change the basic language or how I code the rest of the project. And Python's super flexible import mechanism avoids any name clashes and the package manager pip makes them trivial to include. OpenSCAD would need those two facilities to make libraries practical.

On Wed, 18 Sep 2019 at 09:24, Robin2 <[hidden email]> wrote:
lostapathy wrote
>> I think the reason they don't gain the same traction as conventional
>> programming languages is that a vocal population here on the forum thinks
>> they are unnecessary because the things *those*people*want*to*do* are
>> easy.
>> And for some reason some of these people *vocally*oppose* libraries
>> instead
>> of just ignoring them. 

I have no objection to that approach.

But what I do object to are demands for changes to the Openscad core that
are unlikely to be useful for more than a handful of users.

If something can be achieved with a module built on the existing Openscad
core then I can't see any reason to include that capability in the core.

I don't see the library "problem" being resolved without some leadership
(and I am not volunteering, I don't know enough about it). Someone (or some
small group) needs to pick one or more libraries and make them the primary
libraries. Then a case could be made that other libraries should be
compatible. I don't think this is a simple process.

I am more familiar with the Arduino system. It includes a group of basic
libraries - each with very limited functionality. However some of them are
very far from "best in class". Then there are hundreds of 3rd party
libraries most with almost no documentation apart from the source code. And
the two that I am familiar with that do have extensive documentation have
some substantial gaps in the documentation.

I suspect where the Arduino system differs is that some of its libraries are
very widely used and have become de-facto standards because of that. I get
the impression that none of the Openscad libraries has floated to the top of
the charts in the same way, perhaps because the scope of Openscad usage is
much broader.

Maybe there is also a sense in which some of the Openscad libraries set out
to be "swiss army knives" whereas the Arduino libraries are more focused.

...R



--
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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

alexgibson
In reply to this post by Robin2
I wonder if there would be any value in creating and maintaining a central
list of the most widely used OpenSCAD modules/libraries.

Perhaps we could ask people in this forum to submit their top 10, and I
suspect we would rapidly discover a 'core' set of modules which cross over
multiple people, and a long tail of modules used by multiple people, but
nowhere near universal.  There would likely be a lot of redundancy, and
little standardisation between them - but we could at least take an overview
and see whether strong patterns emerge.  

From this, we could more easily begin to sort them into meaningful types,
and work out  a minimum standard for compatibility, which could then be
published and module/library owners can decide whether to bother to adapt
their code to meet it.

...or has someone already done all this?

Alex Gibson

admg consulting

edumaker limited

. Project management
. Operations & Process improvement
. 3D Printing


-----Original Message-----
From: Discuss [mailto:[hidden email]] On Behalf Of
Robin2
Sent: 18 September 2019 09:30
To: [hidden email]
Subject: Re: [OpenSCAD] Extending OpenSCAD from assembler to C or Perlish
language and adding standard library

lostapathy wrote
>> I think the reason they don't gain the same traction as conventional
>> programming languages is that a vocal population here on the forum thinks
>> they are unnecessary because the things *those*people*want*to*do* are
>> easy.
>> And for some reason some of these people *vocally*oppose* libraries
>> instead
>> of just ignoring them.  

I have no objection to that approach.

But what I do object to are demands for changes to the Openscad core that
are unlikely to be useful for more than a handful of users.

If something can be achieved with a module built on the existing Openscad
core then I can't see any reason to include that capability in the core.

I don't see the library "problem" being resolved without some leadership
(and I am not volunteering, I don't know enough about it). Someone (or some
small group) needs to pick one or more libraries and make them the primary
libraries. Then a case could be made that other libraries should be
compatible. I don't think this is a simple process.

I am more familiar with the Arduino system. It includes a group of basic
libraries - each with very limited functionality. However some of them are
very far from "best in class". Then there are hundreds of 3rd party
libraries most with almost no documentation apart from the source code. And
the two that I am familiar with that do have extensive documentation have
some substantial gaps in the documentation.

I suspect where the Arduino system differs is that some of its libraries are
very widely used and have become de-facto standards because of that. I get
the impression that none of the Openscad libraries has floated to the top of
the charts in the same way, perhaps because the scope of Openscad usage is
much broader.

Maybe there is also a sense in which some of the Openscad libraries set out
to be "swiss army knives" whereas the Arduino libraries are more focused.

...R



--
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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

G. Wade Johnson
In reply to this post by lostapathy
On Tue, 17 Sep 2019 19:12:52 -0500
Joe Francis <[hidden email]> wrote:

> On 9/17/19 6:28 PM, nop head wrote:
> > > many people seem to think that the burden of learning a new
> > > command  
> > is quite overwhelming.
> >
> > OpenScad is a tiny language and can be learned in its entirety in
> > about a day, which I did many years ago. Libraries are much larger
> > things to learn, and if I can write everything I use myself, why
> > would I spend time learning somebody else's library?
> >
> > I think the reason why they don't gain the same traction as
> > conventional programming languages is most things are very easy to
> > do in OpenSCAD with a few lines of code, whereas most libraries for
> > other languages are a lot bigger and more complicated.  
>
> I wish we would quit repeating this like it's the whole truth.  This
> type of talk derails discussions that might lead to a decent library
> ecosystem.
>
> Yes, it's "easy" to do many things quickly.  It's also very easy to
> end up with a "library" that's not actually very reusable, or
> hopelessly slow, or fails to handle edge cases, or fails to provide
> reasonable validation/assertions (making it easy to have problems
> using it).
>
> Making good, reusable, documented libraries is *hard*.  Both because
> of the nature of the work, but also because there are *very few*
> great examples of libraries for OpenSCAD.  There's little work to
> borrow from, so users tend to fall into the same beginner traps and
> either call it "good enough for today's project" or give up on
> OpenSCAD entirely.

Thank you for saying this. Writing libraries is not easy. Writing
(re)usable libraries is very hard. I have written and maintained code
in various languages for decades. For every good library I've seen
there have been several that are more trouble than they are worth.

Programmers generalize too soon (hey I did this once, maybe it would
make a good library). They don't think about re-use (this makes my one
case easier, but will be a bear to use for anything else). They don't
document (it's obvious, really). Add to that, the fact that naming is
hard.

This should not prevent the writing of libraries, but it does mean that
it requires more work than some seem to think.

There's also the tension between big "do everything" libraries that
take more time to learn than to use and small, easy-to-learn libraries
that don't do enough.

When someone manages to build a library that gets enough of this right,
it will catch on. We need to keep experimenting to get there.

G. Wade

> I have talked to many people off-list who were discouraged by this
> "OpenSCAD doesn't need libraries" talk and just gave up rather than
> contributing.  I really wish the negativity around libraries and
> package managers would stop.


--
90% of coding is debugging. The other 10% is writing bugs.
                                                       -- Bram Cohen

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Ronaldo

From Wade Johnson signature:

90% of coding is debugging. The other 10% is writing bugs.
                                                       -- Bram Cohen  

With the current error/warning messages and the echo() in functions abilities, it has been less painful to debug OpenSCAD codes. But it is not an easy task  anyway. One of the problems I see with current libraries, and BSOL is not an exception, is the lack of argument value checks and error/warning messages. Presumably the functions and modules in libraries take care of some corner cases but they usually assume the input arguments are consistent ( a list of vectors is in fact a list of vectors). If by mistake I code a 2D point in a list of 3D points as an input vector of a library function I will get an error somewhere. If the error occurs inside a library function either I stop my work to understand what it does or I changed it introducing echos to trace the error. This is far from easy and probably I will discard the library altogether.

Besides good documentation, clever written libraries functions/modules should include parameter checking and user friendly error/warning messages. Asserts are mandatory.

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

adrianv
Ronaldo wrote
> Besides good documentation, clever written libraries functions/modules
> should include parameter checking and user friendly error/warning
> messages.
> Asserts are mandatory.

I agree.  I always try to do this, 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.   Is there some way to force an assertion to
run first?  




--
Sent from: http://forum.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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

lar3ry
In reply to this post by adrianv
Perhaps we need a 'single step" functionality.

Only half kidding.




--
Sent from: http://forum.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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Robin2
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/

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

tjhowse
In reply to this post by Troberg
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 <[hidden email]> 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
[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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

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


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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

RevarBat
In reply to this post by doug.moen
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 <[hidden email]> 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
>> [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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

RevarBat
In reply to this post by Robin2
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 <[hidden email]> 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
> [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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

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

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

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

3. The work I've seen on passing functions as a first class object has been excellent.  Good job there!

4. The ability to rename built-in and existing modules/functions would allow for extending functionality on things like `linear_extrude()`, `polygon()`, and `polyhedron()`.

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

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

7. 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++:

8. built-in `rotate(a=SPIN_ANGLE, from=VECTOR1, to=VECTOR2)` which is effectively `rotate(v=cross(VECTOR1,VECTOR2),a=angle_between(VECTOR1,VECTOR2)) rotate(SPIN_ANGLE) ...`

9. built-in functions for rotate/translate/scale/mirror that can manipulate lists of 2D/3D points.

10. 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()` or `skin()`.  Having built-in functions for `square()` and `circle()` 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

11. 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()`, then `linear_extrude()`d or `rotate_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

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

13. 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 <[hidden email]> 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
> [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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

RevarBat
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 <[hidden email]> 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.
>
> 1. 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.
>
> 2. 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
>
> 3. The work I've seen on passing functions as a first class object has been excellent.  Good job there!
>
> 4. The ability to rename built-in and existing modules/functions would allow for extending functionality on things like `linear_extrude()`, `polygon()`, and `polyhedron()`.
>
> 5. 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.
>
> 6. 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.
>
> 7. 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++:
>
> 8. built-in `rotate(a=SPIN_ANGLE, from=VECTOR1, to=VECTOR2)` which is effectively `rotate(v=cross(VECTOR1,VECTOR2),a=angle_between(VECTOR1,VECTOR2)) rotate(SPIN_ANGLE) ...`
>
> 9. built-in functions for rotate/translate/scale/mirror that can manipulate lists of 2D/3D points.
>
> 10. 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()` or `skin()`.  Having built-in functions for `square()` and `circle()` 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
>
> 11. 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()`, then `linear_extrude()`d or `rotate_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
>
> 12. 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.
>
> 13. 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 <[hidden email]> 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
>> [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: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

Robin2
In reply to this post by RevarBat
RevarBat wrote
> I have a long wishlist,
>
> [......]
>
> 6. 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/

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

Re: Extending OpenSCAD from assembler to C or Perlish language and adding standard library

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

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