Extending OpenSCAD from assembler to C or Perlish language and adding standard library
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.
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 thosepeoplewanttodo are
easy.
And for some reason some of these people vocallyoppose* 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/
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 robin@nbleopard.com 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 thosepeoplewanttodo are
easy.
And for some reason some of these people vocallyoppose* 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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:discuss-bounces@lists.openscad.org] On Behalf Of
Robin2
Sent: 18 September 2019 09:30
To: discuss@lists.openscad.org
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 thosepeoplewanttodo are
easy.
And for some reason some of these people vocallyoppose* 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Tue, 17 Sep 2019 19:12:52 -0500
Joe Francis joe@lostapathy.com 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
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.
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/
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/
Perhaps we need a 'single step" functionality.
Only half kidding.
--
Sent from: http://forum.openscad.org/
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/