Actually, I’m trying to save the thousands of future hours of effort spent on working around this language. I’ve already spent hundreds of hours on that just by myself. I’m trying to fix most of the issues all at once by replacing the language with a well tested and designed language that is ANOTHER dedicated group’s responsibility to maintain. Frees devs on this project up to work on the editor and the GUI itself.

Now at this point I HAVEN’T put serious work into any BetterSCAD. I’ve written many thousands of lines of OpenSCAD code. I just keep getting so very frustrated that I start dreaming about something better, then have to reel myself back in because I have no interest in having to support another project for the next 20 years. I've written and submitted PRs to implement improvements in OpenSCAD.  Not a single one has been accepted yet. All I can do at this point is TRY to convince devs to let logic prevail.  PLEASE.

What I really want is for the OpenSCAD devs to FIX OpenSCAD. And I just haven’t been seeing that, and my attempts to help appear unwanted.

This is how forks happen. This is how forks have already happened to this project.

• Revar

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

On 25.11.2020 03:59, Revar Desmera wrote:

Separating functionality from language interpreter is in my opinion a
good idea. Now, which language to replace the OpenSCAD language with is
a matter of preference. There are many good arguments in support of
using Python, but there are also many good arguments against it.

My advice to OpenSCAD would be to make an OpenSCAD API with the boolean
engine etc. (but no scripting language features) and implement the
OpenSCAD language by using the API. The test for true separation would
be if someone could implement a Python or other language interpreter
using the same API

I guess the above is hypothetical. For comparison, in current OpenSCAD:

difference() {
union() {
translate([0,0,5]) sphere(d=10);
rotate([0,0,45])
translate([0,0,-1])
cube(size=10,center=true);
}
cylinder(d=5,h=5);
}

In non-hypothetical AngelCAD (using AngelScript) it could written in
different ways, for example

solid@ u =
   translate(0,0,5)
     *sphere(r:10./2)
 + rotate_z(deg:45)
     *translate(0,0,-1)
        *cube(size:10,center:true);
 return  u - cylinder(r:5./2,h:5);

Or alternatively

return
difference3d(
   union3d(
      translate(0,0,5)
        *sphere(r:10./2),
      rotate_z(deg:45)
        *translate(0,0,-1)
           *cube(size:10,center:true)
    ),
    cylinder(r:5./2,h:5)
);

Yes, also true in AngelCAD

Yes

You mean Python import. The main thing is using a standard language
feature. In AngelScript you have #include without the issues related to
include<> and use<> in OpenSCAD

available.

Yes. Writing your own classes in the scripting language is very powerful.

Yes.

In theory. I have worked a lot with Fortran and developed a way to
interface it with C++. It is not trivial. I also worked with ClipperLib
and it has its quirks too. But I agree using a n existing language
supported by someone else opens up many new possibilities.

I use Boost.Python when interfacing python with C++

This is the best argument in favour of Python.

One argument against python is in my opinion that the language
interpreter is somewhere else on the system and not embedded in the
application like it is in today's OpenSCAD and also in AngelCAD. With
these applications you just install and run scripts. That is a good thing.

With Python you have to have a working Python installation separate from
the application and it has to be compatible with the expectations of the
application. I have managed to almost trash my entire windows and linux
installations, because I did things I should not be doing with Python
because I had issues getting things to work. Granted, most people can
use Python just fine but I think it is an extra hurdle for a lot of people.

Carsten Arnholm

On 25.11.2020 07:08, Revar Desmera wrote:

I agree with this line of thinking.

Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "

Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.

Carsten Arnholm

OpenSCAD is a language for describing objects, not a programming language.
That makes it much simpler than Python and more concise for describing
geometry. It also means it doesn't need mutable variables as it is a static
description, not a program that runs, so no values need to change over time.

On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm arnholm@arnholm.org wrote:

The only reason I specify Python is my personal familiarity with it. Making an API for arbitrary languages to use would also be a great idea.

On the Mac you can embed the python interpreter libraries in the .app itself. Under windows you can install it with specific python DLLs. Under Linux it’s preferable to use the system python installation, but you can use a virtualenv instance.

• Revar

What I read from that comment is that OpenSCAD is not currently a proper language, and it should just be treated like Display Postscript. Which ironically is actually a more capable language, if a lot more of a pain to write in.

• Revar

Have you checked out https://github.com/SolidCode/SolidPython ?

In my opinion Openscad is just OK as it is... solidpython is doing a
good job too, what might be needed is more libraries written for
solidpython, taking advantage of the power of python. Openscad
libraries can already be wrapped and addressed, but the results
returned by such a library are opaque (being calculated at OpenScad
run-time), while python funtions can return python objects useful for
further processing in the solidpython code. For example it's much
easier to write libraries for connecting objects if you actually have
encapsulated objects with known interfaces to address. It's a
completely different way of doing things than the OpenScad philosophy,
less precise and sloppier perhaps, but it comes down to the compromise
you want to take - have some immediately working code you can play
around with, or plan everything from the beginning and only have it
properly working at the end. With OpenScad you need proper planning,
python invites you to play, pick yours.

As environment I use IntelliJ PyCharm, which allows me to set up
shortcuts to run the solidpython code at the press of a button, then
the OpenScad widnow will refresh automatically. I'm perfectly happy
with that... From a speed perspective it seems workable too, have some
bigger models which run quite reasonably. At the moment solidpython
will generate code where lots of repetition of the same OpenScad code
can occur (if you re-use the same SolidPython object multiple times),
but that seems to not be a problem.

If it would be a help for anybody, I could create a tutorial on how to
set up PyCharm to comfortably work with SolidPython, anybody interested
?

Cheers,
Csaba

On Wed, 2020-11-25 at 09:40 +0100, Carsten Arnholm wrote:

If you have to drop to the command line to install it, you’ve already declared that newbie users need not apply. That’s a losing position for a project that intends to ever expand.

• Revar

On Wed, 2020-11-25 at 01:49 -0800, Revar Desmera wrote:

Well for linux users I don't think that applies, and for windows it can
be bundled, possibly with python included too... that would need to
happen for OpenScad too (bundling python, to avoid the command line).

OpenScad (with or without python) appeals more to the programmer type
of users, so I would say those who have issues with the command line
will likely have issues with OpenScad proper too.

Cheers,
Csaba

On 25.11.2020 10:43, Csaba Nagy wrote:

Yes, as has been mentioned earlier here it is simply an OpenSCAD .scad
code generator. That is sort of similar to the state of AngelCAD anno 2015.

If you like Python, I guess SolidPython can be great thing. I happen to
be less of a fan of Python myself, because I don't like the dynamic
typing and I am no fan of indentations as a replacement for {} brackets.

I am however well aware that others feel differently about Python, plus
it is a genuinely good thing to have all the libraries that Python can
offer. I have made several non-open source C++ libraries with Python
APIs for others to use, and that has worked well so I have some
practical experience.

One can still use AngelCAD as an OpenSCAD code generator in much the
same way as SolidPython, but there are also other scenarios now:

a) Use it as OpenSCAD code generator
b) Use it as stand alone "native"
c) Use it to process OpenSCAD scripts

Because CGAL is kind of resource hungry, a) does not make a lot of sense
if you have a workable alternative for boolean processing. c) Can make a
lot of sense because of the large amount of .scad scripts already in
circulation, if the processing is faster.

Carsten Arnholm

I often introduce new people to OpenSCAD and try to describe .scad files as ‘script’ rather than ‘code’ for this reason.  Hopefully I’m getting that terminology right, it seems to get the correct understanding from programmers (and nobody else cares!)

I understand your motivation to free constraints – but I’d see the text editor and GUI as much less intrinsic than the language.  I could cope with relearning the GUI much better than even small changes to the language!  But making all of these things more modular would be great!

Lots of people use programs in other languages to generate OpenSCAD script.  OpenSCAD can then be run from the command prompt – so you can essentially make your own abstraction layer if motivated enough!

Alex Gibson

admg consulting

edumaker limited

·        Project management

·        Operations & Process improvement

·        3D Printing

From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of Revar Desmera
Sent: 25 November 2020 09:38
To: OpenSCAD general discussion
Subject: Re: [OpenSCAD] OpenSCAD language - replace it with Python3

What I read from that comment is that OpenSCAD is not currently a proper language, and it should just be treated like Display Postscript. Which ironically is actually a more capable language, if a lot more of a pain to write in.

• Revar

On Nov 25, 2020, at 1:30 AM, nop head nop.head@gmail.com wrote:



OpenSCAD is a language for describing objects, not a programming language. That makes it much simpler than Python and more concise for describing geometry. It also means it doesn't need mutable variables as it is a static description, not a program that runs, so no values need to change over time.

On Wed, 25 Nov 2020 at 08:51, Carsten Arnholm arnholm@arnholm.org wrote:

On 25.11.2020 07:08, Revar Desmera wrote:

I agree with this line of thinking.

Here is what I said in this forum 13. May 2015: "I think it is a mistake
that OpenSCAD spends time on defining the syntax of a language. All of
the resources should be spent on improving modelling features. I realise
this is much too late given the user base of the .scad files, but it
strikes me as odd anyway. "

Five years later the .scad language oddities still take a lot of focus.
If a third party language was used it would offer more flexibility,
easier recognition and would free up resources to focus on modelling
features.

Carsten Arnholm

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient

Virus-free.  http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com

I would say "script" and "code" is not a useful distinction.  People refer to
python programs as "scripts" or perl programs, or shell (/bin/sh) programs,
and the word "script" doesn't imply that you can't redefine variables.

My observation is that for laying out some geometry, you can understand
OpenSCAD as a "description" language.  It is describing geometry.  And I
think that's a reasonable understanding of basic OpenSCAD where you use
modules. But contrary to what nophead said, that would only be sufficient if
native OpenSCAD were powerful enough to do the things I wanted to do.  But
when it comes to anything that isn't flat, that's not the case, so I've had
to write a bunch of functions to do computations in OpenSCAD to provide the
missing functionality.  Once you've written this missing functionality you
can use it and think of your OpenSCAD file as a description.  One such basic
missing function that everybody seems to write at some point is sweep, to
give a simple example.  And when you are writing things like this, you're no
longer "describing" you're now programming.  And denying that OpenSCAD has
this capability and can be used for programming is a strange position to
take.  Because of OpenSCAD's language design it's quirky and it's difficult
to program, but programming is both possible...and necessary for more
sophisticated models.

I understand that not everybody wants to do these kind of models and for
these people perhaps a description of boolean operations on cubes and
cylinders suffices.  But for me a driving issue is that I think no edge in
any model I make should be sharp: every edge needs to be rounded over or
chamfered or treated in some other way.  This seems like a kind of simple
expectation, but is very difficult to achieve in OpenSCAD.  I've written
thousands of lines of OpenSCAD programs to enable my models to have
rounded edges.  Consider the recent request for a way to produce the outline
of an object.  It's impossible in OpenSCAD unless you follow the approach of
working in userspace with functions (programs) that implement the
functionality you need to describe the model you want the outline of.

alexgibson wrote

--
Sent from: http://forum.openscad.org/

On 25.11.20 14:47, adrianv wrote:

Interesting definition of "simple" ;-). But anyway, so would
there be anyone interested in looking at one or more of those
proposals listed below to get them into shape to be included:

Straight skeleton based roof
https://github.com/openscad/openscad/pull/3486

Implement offset_extrude
https://github.com/openscad/openscad/pull/2079

RFC: New general-purpose extrusion mechanism
https://github.com/openscad/openscad/pull/2796

ciao,
Torsten.

Yeah, I think sweep, if you do it like in list-comprehension-demos, is
simple.  About as simple an extension as you can come up with.  Sweeping
along a path (instead of just with a transform list) is much trickier.  But
my offset_sweep() userspace module is much more complex still, since it
requires a userspace implementation of offset(), which is really hard.  I
also have a module for making rounded edge holes in tubes.  Again,
significantly more complicated than a simple sweep.

The problem I see with getting involved in actual OpenSCAD code is two
things:

1. How do I learn enough about the OpenSCAD internals to do things that are
   actually good.

2. Why should I believe anybody would ever incorporate my pull request?  It
   seems likely the effort is just wasted.  Or I end up writing my own fork of
   OpenSCAD.

tp3 wrote

--
Sent from: http://forum.openscad.org/

On 25.11.20 16:53, adrianv wrote:

It's not even about OpenSCAD/C++ code. It's much more about
using the proposed feature, finding corner cases, discussing
how it might be changed to compose better with existing
features. Or maybe also suggesting algorithms that could help
problems mentioned in the discussion.

https://github.com/openscad/openscad/graphs/contributors?from=2020-01-01&to=2020-12-31&type=c

If that looks hostile to PRs to you, I don't know what to
say anymore. If there's a bigger language change without
even having a discussion upfront, then things will indeed
end in tears. It's much less complex than bigger languages
that have a long formal RFC process with lots of people
asking for changes though.

ciao,
Torsten.

Hmm, you are actually missing the point here :-)

First of all, you're right: "Building an OpenSCAD-esque infrastructure
in Python is not difficult".

That will however not solve the issues Openscad have: lack of some of
the more difficult to implement operations (like sweep, fillet,
buffering, etc.), good (stable/versionable/central/etc.) library
management, and the one I find the most annoying but nobody talks about
is: handling parameters (complex 3D models tend to have a huge amount
of tunable parameters, which are hard to pass around in a functional
context).

So you can have another language/framework for defining 3D models, with
the same issues popping up as soon as you hit the more difficult parts
(and they are difficult, that's why OpenScad doesn't have them solved
already).

SolidPython did not go the way of implementing things from scratch
(reinventing wheels ?) but chose to wrap the existing OpenScad
primitives. I bet you can implement your version of the syntax in those
300 lines of code, with SolidPython doing the "render" part... the
syntax of how you build the 3D model is frankly not that relevant in my
opinion. If you start creating complex models with the syntax you
proposed, it will choke too on the amount of parameters you will have
to pass around. It will also not directly give you a sweep operation
for example, basically because it is a hard problem to solve, and you
focused on something else (syntax, which you could have implemented
even as an afterthought in a few lines of code, as you demonstrated).

Regarding the missing primitives, I have my own code to do the sweep
for example (generates a polyhedron, vertices and faces and all that
calculated in python). Still works fine with SolidPython as a rendering
engine.

The most important part of my own SolidPython based framework is how I
handle parameters: each "Part" I define can get a JSON based
configuration, with a default one defined in the code, and any number
of overrides (json or named params) in the constructor. That allows me
to configure real complex Parts and still have an overview of what
params were changed from default in different instances. It also makes
calls easier to follow (only need to override things that are not
default, less parameters in the call) and parameters to be verbosely
documented while still in a nice format (as JSON in the code).

Rendering is one key-combination away in PyCharm (and the result pops
up in an OpenScad window). If I wanted, STL rendering too. I have code
to render the Part subclass under the caret in the editor with it's
default parameters, and would be easy to write code to render a part
based on json config (also at the press of a key-combo in PyCharm). My
IDE integration works already, no need to reinvent wheels here either
;-)

All that is fairly random rambling, with one single point: creating a
different syntax is not what your problem should be, SolidPython does a
good job as a rendering engine, and any syntax you desired can be
wrapped on it in a few hundred lines. IDE integration can be achieved
with PyCharm pretty easily too.

What is missing are good and manageable libraries, more of the complex
operations (built in or as library), and a framework which actually
makes large 3D model design easier. The parameter problem for example
is solved by the OpenScad customizer at top level, but it really
doesn't solve problems in case of libraries of parts. I have models
where the top level assembly has a few hundreds of parameters,
configuring each of it's parts/sub-assemblies which also have lots of
params on their own. That kind of issues need solving, and can be done
better in python than OpenScad, and the rendering engine used is
totally irrelevant for them while they define how complex really is to
design a model.

If we do not want to re-invent the already working wheels, better focus
on what is missing than on the fitness of the syntax of what we have...

Cheers,
Csaba

On Wed, 2020-11-25 at 18:41 +0000, Jordan Brown wrote:

I'd certainly be interested in participating in discussions about new
features, though it's not really very clear when (if) these discussions are
going on.  I already did make some remarks about the offset_extrude
PR---once I learned about it.  I use my offset_sweep function in nearly
every model I make, and I ran into a variety of tricky issues with its
implementation, so I may have some insights.  But I also don't understand
how something like this is handled internally, which matters.  In my
implementation I associated vertices between layers by knowing where they
came from in the offset.  This has some disadvantages but I also don't know
if it's possible in OpenSCAD.  If it's not you have a much harder problem
for how to align 2d shapes.  If that problem needs to be addressed
generically then it should be addressed separately, because the same issue
arises with the "skin" process of making a solid given a set of cross
sections.  The vertex matching problem is hard: there doesn't seem to be
one algorithm that always produces a good result.

The question of incorporation of work is not about counting PRs (which might
be trivial bug fixes) but more about the general attitude towards change,
which seems to be that we shouldn't have any.  And I emphasize SEEMS TO BE.
This is how I have been struck and how I feel from interactions I've had in
the forum.  I don't feel like I can make a contribution or should try.
Maybe I have misunderstood....but if I don't FEEL like I can make a
contribution then obviously I'm not going to make one.  That's why I've been
writing library code so I can get my models done rather than trying to make
changes to OpenSCAD itself: it appears to be impossible.  (Or perhaps in 5
years some change can occur?)

tp3 wrote

--
Sent from: http://forum.openscad.org/

On 25.11.20 22:38, adrianv wrote:

The main place is github. I'm following projects I'm interested
in by just watching the repository. That sends out mail for
pull requests and comments. I think it's also possible to not
enable mails and just check the https://github.com/notifications.

Specific for OpenSCAD, more direct discussion is possible in
the IRC channel. Discussing ideas upfront in chat can help
quite a lot.

The channel is usually open without registration:
https://webchat.freenode.net/?channels=openscad

I have not followed the code changes but I think that's exactly
one big topic in the discussion. And this was renewed with
someone looking at the straight skeleton feature CGAL provides
which to my understanding provides the connectivity of vertices
too - leading to the specialized roof() PR.
For the roof() PR I'm wondering if there's some way of not only
making it 2D -> 3D but also attach it to a side of some existing
3D shape. If there's a good way to do that, I don't know yet,
but it might be a nice feature for adding fillets.
Another open discussion just happening is if the proposed
roof() is and will be a special case of the offset_extrude()
work. So the question is if it can or should be combined.

My point of view is that without change, OpenSCAD will be dead.
So there needs to be change (and also releases which is one of
the current struggles again).
There is certainly a graduation between changes. Things that
modify the GUI are certainly not so critical as it's not ideal,
but still possible to change things back. Language changes are
much more critical as if features are released it's difficult
to change without breaking all the code using it. For adding
things there is the experimental flag which allows the new
feature to grow in the snapshot versions while still being
disabled for release builds. I think it would make sense to
make more use of that.

Contribution can start way before sending code via PR.
Maybe just follow the discussion on github and/or the IRC
channel for a bit. As it's spare time project for everyone,
the traffic is not exactly huge. There's even an offline
chat log at https://freenode.logbot.info/openscad/

ciao,
Torsten.

On 11/25/2020 12:29 PM, Csaba Nagy wrote:

Well, maybe.  But the meta-point is that like the elephant
https://en.wikipedia.org/wiki/Blind_men_and_an_elephant, there  are
many views of what "the problem" is.

I started out writing something about that, but wasn't able to make it
coherent enough that I thought it contributed value.  But I'll take
another stab:

Things I think are arguments for a different base language:

• Language familiarity.  The absolute best that OpenSCAD can achieve
  is that it's a unique language, with its own quirks.  Nobody can
  step into it with experience in another language, learn only about
  the geometry mechanisms, and write programs.  If the language was
  based on Python or JavaScript, there are lots of people who already
  know all of the non-geometry parts of the language.
• Non-geometry features.  Data structures, I/O, OO, string libraries,
  first class functions, et cetera.  This is where the "parameter
  management" stuff you're talking about comes in.  Any answer based
  on a general-purpose language is going to get you this stuff.
• Library management tools.  Download/install libraries and their
  dependencies.  Python's pip, Node.js's npm, et cetera.
• Export both metadata and geometry from the same function.
• Extract geometry information from a geometric object.  Start with
  extracting the bounding box.

Things I think are not arguments for a different base language:

• Geometry features.  Sweep, fillet, chamfer, et cetera.  These are
  all hard no matter what your language is.  Some may benefit from
  language features like first-class functions, but mostly not.
• Mesh problems:  manifold problems, self-intersection problems. 
  These too are hard no matter what your language is.

Things I think are arguments against a different base language:

• Security and sandboxing.  It's pretty safe to run a random
  downloaded OpenSCAD program.  Not so with a random Python program.
• Simplicity.  The minimum program needs to be not much more
  complicated than "cube(10);", and that's tricky in most languages.

In my opinion, it's not everything, but it's very very important. 
People use OpenSCAD because relative to other programming environments
it's easy to use for 3D modeling.

If one wants to replace OpenSCAD with an architecture that has
full-featured data handling, file I/O, OO, a library manager, and all of
those other non-geometry things that we keep wishing for, it's got to
retain that ease of use for 3D modeling.  It can't sacrifice the simple
cases to support the more complex ones.

I'm confused.  You're saying "people should use Python because xxx is
impossible in OpenSCAD".  But then you say that we shouldn't talk about
the fitness of the syntax that we have.  Are you saying that the base
OpenSCAD language is fine, that it just needs a few more built-in modules?

In my mind the goal should be to produce an environment with the
geometry power of OpenSCAD, the geometry simplicity ("cube(10);") of
OpenSCAD, the UI simplicity (one key render and view, one key
save-as-STL) of OpenSCAD, the installation simplicity (one install) of
OpenSCAD, and the programming power of a general-purpose language.

And somehow get it to a critical mass of users and developers - again,
that's the truly difficult part.

[ Migrated from the static analysis thread ]

On 11/25/2020 3:33 PM, nop head wrote:

There are, I think, two big tricks:

(1) The language and library need to cooperate to allow for extremely
simple programs.  The simplest program in OpenSCAD is "cube(10);".  A
new environment needs to support programs that are that simple.

(2) The environment needs to be described using "progressive
disclosure".  A programmer might think that data types, expressions, and
functions are core concepts, but for modeling ... they aren't.  Look at
the OpenSCAD tutorial at
https://en.wikibooks.org/wiki/OpenSCAD_Tutorial/Chapter_1 .  If you
present this hypothetical Python-based language in that way, it doesn't
need to appear to be way more complex than OpenSCAD.

If you can do those two things, I think a hypothetical Python-based CAD
environment could be not much harder to get started in than OpenSCAD
is.  Once you get past those basics, yes, there's a lot more that you
can learn, but that's true in OpenSCAD as well as Python - think of
children, $ variables, recursion, et cetera.  The Python universe is
much larger than the OpenSCAD universe, but that's OK as long as you can
consume it one bite at a time.

I admit the sandboxing issue really IS a worrisome problem.  I’m not sure we can have both sandboxing security and a robust language.  There ARE some iffy sandboxing solutions mentioned for Python at https://wiki.python.org/moin/Asking%20for%20Help/How%20can%20I%20run%20an%20untrusted%20Python%20script%20safely%20%28i.e.%20Sandbox%29 https://wiki.python.org/moin/Asking%20for%20Help/How%20can%20I%20run%20an%20untrusted%20Python%20script%20safely%20(i.e.%20Sandbox)

• Revar

One unique aspect of OpenSCAD is preview.
Having a usually snappy visualisation of your geometry is invaluable.

This is where enhancements come in conflict.
Because preview does not actually make geometry you can't have features
which require the geometry to be calculated, it will kill the advantage of
preview.

Like getting a vector of the points of an object.

g = render() { someObjects(); }  // caching may help, but it would be
painful.

That plus Preview, is OpenSCAD.

If OpenSCAD did not have Preview, I doubt it would have the uptake it has.

Thus anything without both will no longer be OpenSCAD. It is a niche.

OpenSCAD Admin - email* me if you need anything,  or if I've done something stupid...

• on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

I would rather we used JavaScript instead of python, V8 has extension
mechanisms that would allow it to be embedded inside the existing app, and
have the openscad objects and backend plugged in. Plus JS is block
structured rather than indent structured, which is the same as the current
implementation, which minimizes impact on people.

There are 1000's of JavaScript embeddable editors that do full syntax
highlighting, folding and dynamic formatting, there are very few for
python.

On Thu, Nov 26, 2020, 14:34 MichaelAtOz oz.at.michael@gmail.com wrote:

BUT -- no one uses Java or Javascript anymore.  Everyone hates it but
just a few people.  If there is no one to support it, especially for
FREE! then it is doomed as a target.

On 11/26/20 4:36 AM, Tim Hawkins wrote:

Java isn't javascript...
Also, most professional programmers I know still work in Java. Most of us
still hate javascript, although since nodejs is a thing I have found it to
be useful...
Personally I like the openSCAD language, but do support adding a few
things...

On Thu, 26 Nov 2020, 11:37 David, ainut@hiwaay.net wrote:

The OpenSCAD scripting language is fine. It works, don't fix it!

There has been and are many similar "issues" in other domains, e.g. CSOUND (for sound synthesis), PostScript... What I find important is to have a stable and reliable scripting langue. Then we can design and write any kind of high-level tool that outputs, for example, OpenSCAD script. If you want a quick preview at the high-level stage, then you'll have to generate that separately yourself.

I find OpenSCAD extremely useful and attractive. It has exactly the functionality that some of the early (1980s) CAD systems had, that focused on specifying geometries by text that then rendered graphically and/or converted to Gerber code (and other formats).
/mikael

On 26 Nov 2020, at 16:49, acraigwest@gmail.commailto:acraigwest@gmail.com wrote:

EXTERNAL EMAIL: This email originated from outside of the University of Limerick. Do not click on links or open attachments unless you recognize the sender's email address and know the content is safe.

Java isn't javascript...
Also, most professional programmers I know still work in Java. Most of us still hate javascript, although since nodejs is a thing I have found it to be useful...
Personally I like the openSCAD language, but do support adding a few things...

On Thu, 26 Nov 2020, 11:37 David, <ainut@hiwaay.netmailto:ainut@hiwaay.net> wrote:

BUT -- no one uses Java or Javascript anymore.  Everyone hates it but just a few people.  If there is no one to support it, especially for FREE! then it is doomed as a target.

On 11/26/20 4:36 AM, Tim Hawkins wrote:
I would rather we used JavaScript instead of python, V8 has extension mechanisms that would allow it to be embedded inside the existing app, and have the openscad objects and backend plugged in. Plus JS is block structured rather than indent structured, which is the same as the current implementation, which minimizes impact on people.

There are 1000's of JavaScript embeddable editors that do full syntax highlighting, folding and dynamic formatting, there are very few for python.

On Thu, Nov 26, 2020, 14:34 MichaelAtOz <oz.at.michael@gmail.commailto:oz.at.michael@gmail.com> wrote:
One unique aspect of OpenSCAD is preview.
Having a usually snappy visualisation of your geometry is invaluable.

This is where enhancements come in conflict.
Because preview does not actually make geometry you can't have features
which require the geometry to be calculated, it will kill the advantage of
preview.

Like getting a vector of the points of an object.

g = render() { someObjects(); }  // caching may help, but it would be
painful.

That plus Preview, is OpenSCAD.

If OpenSCAD did not have Preview, I doubt it would have the uptake it has.

Thus anything without both will no longer be OpenSCAD. It is a niche.

OpenSCAD Admin - email* me if you need anything,  or if I've done something stupid...

• on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

--
Sent from: http://forum.openscad.org/

OpenSCAD mailing list
Discuss@lists.openscad.orgmailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

OpenSCAD mailing list
Discuss@lists.openscad.orgmailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

OpenSCAD mailing list
Discuss@lists.openscad.orgmailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

EXTERNAL EMAIL: This email originated from outside of the University of Limerick. Do not click on links or open attachments unless you recognize the sender's email address and know the content is safe.

OpenSCAD mailing list
Discuss@lists.openscad.orgmailto:Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

If you think the OpenSCAD language is "fine" then probably you're not trying
to do anything nontrivial.  I mean, if you want to throw a few cubes and
cylinders out somewhere it's fine.  But if you want to write nontrivial
geometric algorithms (to fill in the missing functionality) then challenges
quickly mount.  Algorithms in the literature may be O(N*log(N)) but that
assumes you have actual data structures.  In OpenSCAD it may turn out to be
O(N^3) instead.  In many cases it just doesn't seem practical to implement
efficient algorithms.  My offset() code for example (which computes the
offset to a polygon defined by a point list, similar to the offset module)
doesn't always work because I couldn't find a way to implement a robust
algorithm in OpenSCAD, and it can be slow.  When you need 50 offset calls to
make a shape that adds up.

The lack of data structures can be a significant source of frustration just
in general, and in terms of code readability and maintainability.  (And if
you implement data structures in OpenSCAD they end up horribly inefficient
and clumsy due to the immutability of data, which mean that every change to
a data structure requires completely rewriting the data.)

If libraries supply functionality then users can use them without having to
understand the internals.  But trying to write the libraries can be a
challenge given the limitations of OpenSCAD.

Mikael at UL wrote

--
Sent from: http://forum.openscad.org/

missing functionality) then challenges quickly mount.

Yes no doubt they would but I can make everything I need without nontrivial
geometric algorithms. I do just compose cube and cylinders in the main plus
a few sweeps, isn't that what CSG is? If you don't want to make
geometry with CSG then OpenSCAD doesn't seem to be the right tool. It is
certainly not a good language for coding algorithms.

On Thu, 26 Nov 2020 at 18:29, adrianv avm4@cornell.edu wrote:

On 11/26/2020 10:31 AM, jon wrote:

I wouldn't characterize a Python (or JavaScript or Forth or FORTRAN or
TECO) based tool as OpenSCAD.

I would characterize it more as an alternative that people might choose
to move to.

In a sense, the OpenSCAD community is also the "I want to write a
program to generate geometry" community, and so starting a discussion
here makes some sense, but if it goes much beyond a "what if" discussion
then it needs to split into a different project.

On Thu, 26 Nov 2020 11:28:44 -0700 (MST)
adrianv avm4@cornell.edu wrote:

Or you are using it as intended - it's not a "language" in the classic
interpretive sense - it's a data structure with some compression features.

My tools output OpenSCAD, it's great for that. I think it's kind of
meaningless to talk about replacing OpenSCAD's language with python
because they are just not the same thing. OpenSCAD is a definition,
python would produce a program which instantiated and bound objects to
some kind of scene. By all means go and build that - but you will end up
working at the library level with csg libraries, or outputting an openscad
file of the resulting construct. The former means you can query internal
state more easily, the latter is easy to do and has been done many times
already.

Either way you don't end up with anything connected to OpenSCAD beyond
perhaps being able to recycle code.

Alan

Note that I'm not taking a position on the OpenSCAD language being replaced.
I'm just making observations about challenges and limitations.

What does it mean to use a language "as intended"?  You can only model
things the original designer imagined?  Seems like a weird way to think
about things.  When computer languages are released into the wild users will
use them to do what they want, not what the designers imagined.  Where's
the threshold for a model being "wrong" for OpenSCAD?  Note that OpenSCAD
certainly is a language in the classical sense.  It's got functions and
recursion and can theoretically do anything.  It's just that doing things is
not always easy, or efficient.  The code is harder to write.  Of course,
once it's written then the complexity is hidden, and the actual models are
easy to construct.

The question about what OpenSCAD is "for" I think leads to the question of
whether it's a toy environment or an environment for real design.  The
driving problem I generally struggle with is that every edge and corner in
my 3d printed models should be filleted or rounded, and this tends to be
very difficult, even though my models are pretty simple.  I think I may have
this problem mostly solved, but it wasn't easy.  Is there a better tool for
this, for constructing simple models with specified parametric dimensions,
where parts can have roundovers applied without a struggle?

Alan Cox-2 wrote

--
Sent from: http://forum.openscad.org/

On 11/26/2020 11:31 AM, Alan Cox wrote:

I don't really understand this assertion.

Here's a simple OpenSCAD model:

// Curtain rod screw base
//
//            |d4|
//           |<d3>|
//          |<-d2->|
//
//  --      |      |
//  h3      |      |
//  --      ||    ||
//  |       ||    ||
//  h2      ||    ||
//  |       ||    ||
//  --  ================
//  h1  ================
//  --  ================
//
//      |<----d1---->|
$fs = 0.5;

d1 = 16.8;
d2 = 9.5;    // 10 is too big, 9 is a little too small
d3 = 6.5;
d4 = 4.5;
nub = 0.5;

h1 = 2;
h23 = 16.5;
h3 = 5;
h2 = h23 - h3;
h123 = h1 + h2 + h3;
h12 = h1 + h2;

difference() {
    union () {
        cylinder(h=h1, d=d1);
        cylinder(h=h123, d=d2);
        cylinder(h=h123, d=d2+nub*2, $fn=3);
    }
    cylinder(h=h123*3, d=d4, center=true);
    translate([0,0,h12]) cylinder(h=h3*3, d=d3);
}

Here's that same model (modulo that I don't have a trivial way to make
equilateral triangles) expressed in my Python-based prototype:

# Curtain rod screw base
#
#            |d4|
#           |<d3>|
#          |<-d2->|
#
#  --      |      |
#  h3      |      |
#  --      ||    ||
#  |       ||    ||
#  h2      ||    ||
#  |       ||    ||
#  --  ================
#  h1  ================
#  --  ================
#
#      |<----d1---->|

d1 = 16.8
d2 = 9.5    # 10 is too big, 9 is a little too small
d3 = 6.5
d4 = 4.5
nub = 0.5

h1 = 2
h23 = 16.5
h3 = 5
h2 = h23 - h3
h123 = h1 + h2 + h3
h12 = h1 + h2

Difference(
    Union(
        Cylinder(d1/2, h1),
        Cylinder(d2/2, h123),
        # I don't have a trivial way to do a triangle yet
        # cylinder(d2/2+nub, h123)
    ),
    Cylinder(d4/2, h123*3, True),
    Cylinder(d3/2, h3*3).translate([0,0,h2])
).add()

Sure looks awfully similar to me.

(I think I could have it do keyword-based arguments, so have "r=xxx,
h=yyy" style arguments.  I just haven't.)

I'm not saying that this particular library is the greatest possible
answer, just that you can have a Python-based infrastructure that looks
a lot like OpenSCAD.  Most OpenSCAD constructs would translate across
pretty directly.  Same for JavaScript.  (Maybe just for fun I should
translate my Python infrastructure over to run under Node.js.)

For practical purposes, what's the difference?  (And yes, one answer is
"in Python you could XXX", but the responses to that are "but you don't
have to" and "yes, you can, and that's the point".)

(If you're wondering, this is a curtain-rod mounting part.  You screw it
to the wall, and then you mash the wooden curtain rod holder down onto
it.  We lost one of the plastic pieces that came with the curtain rod
holder.)

Design note:  I'm torn between Union(a, b), a.union(b), and a+b as ways
to represent "union", and similarly for the other operators.  Right now
I've implemented the first two.

I think the point of the discussion is that at the moment, OpenSCAD is a
great tool but, like any tool, it has it's limitations.

Where I, as a newbie, would like to get is more 'programmatic' structure
in the building of our tools.  That is, for example, 'includes' that
don't eat it's young while trying to be parsed. More streamlined
lexicology.  Variables that can be either global or local, depending
upon the particular syntax the designer/programmer declares. 
Implementation of 'libraries' that we can share with each other, like
the parametric design of screws and nust, or 3D printable items that can
be called as assemblies or subassemblies.    And suchlike.

Am I the only one?

David

On 11/26/20 2:03 PM, adrianv wrote:

MichaelAtOz oz.at.michael@gmail.com
wrote:

An excellent point and one which I agree w/ wholeheartedly, and it is why I use OpenSCAD and BlockSCAD (and wanted to be successful w/ OpenJSCAD when I thought learning JavaScript was a good idea).
What is the internal model used?
One of the big things for TeX/LaTeX is that a PDF is generated and then displayed interactively and for the various editors one can switch between different compilers and even different scripting languages.
Would it be possible to have OpenSCAD preview languages such as:
http://www.plasm.net/
The page I linked before lists a number of such tools.
I suspect that there's some internal representation of the 3D object for performance reasons and that generating and viewing an STL to preview is not workable since it would be too slow?
William

I have a library that has parametric screws and nuts and 3D printable items
that can be called as assemblies or subassemblies.

https://github.com/nophead/NopSCADlib#Screws
[image: image.png]
https://github.com/nophead/NopSCADlib#Nuts
[image: image.png]
https://github.com/nophead/NopSCADlib#Camera_housing
[image: image.png]
https://github.com/nophead/NopSCADlib#Butt_box
[image: image.png]

Variables prefixed with a $ are global.

On Thu, 26 Nov 2020 at 20:57, David ainut@hiwaay.net wrote:

OUTSTANDING!  Thanks.

On 11/26/20 3:17 PM, nop head wrote:

I asked about libraries when I first encountered OpenSCAD a couple years ago,
I think.  And I got a remarkably negative reception, with hostility to
libraries.  A vocal group seemed to oppose the idea that libraries should
exist---everybody should design their own code in private from the ground
up.  Maybe things have improved a bit, but there's still no good mechanism
for managing them, or dealing with them, and we have the bug with "use" that
creates big performance issues, which is apparently seen as very low
priority.  (The issue for this bug was first opened in 2012, I think, by
someone who thought the fix was not hard.)

There are tons of OpenSCAD files on thingiverse that implement a variety of
interesting and useful things.  If you need a particular thing it's
certainly a good place to start.  But hunting around on thingiverse can be
pretty frustrating as a way to find libraries, and quality is variable.
Screw libraries abound if you want screws.

In addition to nopscadlib you might take a look at BOSL2.  There's also
dotSCAD, though I think it provides basic modeling commands rather than
parametric parts.  The BOSL2 library does both.

https://github.com/revarbat/BOSL2/wiki

If you're specifically looking for parts scroll down to the "Miscellaneous
Parts" section, which includes:

Miscellaneous Parts

polyhedra.scad: Modules to create various regular and stellated

polyhedra.
walls.scad: Modules to create walls and structural elements for 3D
printing.
cubetruss.scad: Modules to create modular open-framed trusses and
joiners.
involute_gears.scad: Modules and functions to make involute gears and
racks.
joiners.scad: Modules to make joiner shapes for connecting separately
printed objects.
sliders.scad: Modules for creating simple sliders and rails.
screws.scad: Functions and modules to make metric and UTS screws and
nuts.
metric_screws.scad: Functions and modules to make metric screws, nuts,
and screwholes.
linear_bearings.scad: Modules to make mounts for LMxUU style linear
bearings.
nema_steppers.scad: Modules to make mounting holes for NEMA motors.
phillips_drive.scad: Modules to create Phillips screwdriver tips.
torx_drive.scad: Functions and Modules to create Torx bit drive holes.
wiring.scad: Modules to render routed bundles of wires.
hingesnaps.scad: Modules to make foldable, snap-locking parts.
bottlecaps.scad: Modules to make standard beverage bottle caps and
necks.

skypuppy wrote

--
Sent from: http://forum.openscad.org/

I need the algorithms to build the missing primitives so I can compose things
with CSG.  If you're doing sweep then that means you're also coding a
missing primitive.  A full path sweep implementation is an algorithm.  You
need to make decision about how you're going to manage the twist of the
sections as you move along the path, and it's not obvious how to do this in
general.

nophead wrote

--
Sent from: http://forum.openscad.org/

People objected to sharing their creations?  Sounds kinda small minded. 
I understand protectionism, esp of work stuff, but object to SCREWS and
NUTS?  That's nuts (if you'll pardon the pun.)

Adrianv, some of the items in your list I actually recognize and I'm not
a machinist.  :)  With the parametric abilities of OpenSCAD, I think
it's wonderful that we can have libraries like these.  Common and not so
common everyday stuff that -everyone- uses routinely are prime
candidates for saving repetitive donkey labor.  If made available in the
form of 'libraries' will make OpenSCAD MUCH more useful, thereby also
growing the user base.

Aside: how does one find these existing libraries in thingiverse?  I've
looked but I'm not using the correct magic incantations.

Aside thought #2: OpenSCAD is a prime candidate for getting tough
concepts across to other people visually and when animated, improves
understanding by leaps and bounds.  Calc III, anyone? :)  :)

David

On 11/26/20 6:43 PM, adrianv wrote:

I know when I made my own parametric bezier sweep, accounting for twist
along the path was most vexing

On Thu, 26 Nov 2020, 20:02 adrianv, avm4@cornell.edu wrote:

You are using python to encode the data structure in this exmple rather
than doing anything truely programmatic.

The moment you add any input, output or other externally conditional
behaviour they diverge completely. The python one becomes a program not a
data structure expression. That has enormous consequences for efficiency
if parallelism was supported which in the OpenSCAD case it isn't but in
other SCAD systems is. It also becomes a completely different beast to
work with using tools.

Alan

The easiest way to find a library on thingiverse is to have someone give you
a link to it or mention its name and then you are able to find it with
google.  If you have a specific thing you want to make you can try searching
for it, e.g. "gears"

I tried searching thingiverse for "gears" and looked through about 5 screens
of hits and found this library:

https://www.thingiverse.com/thing:1604369

Like I said, stuff is there on thingiverse, but not necessarily easy to
find.  It's a terrible method for distributing library code.  Other
libraries are on github.  Maybe you can stumble across them.

There is this list:  https://www.openscad.org/libraries.html

People are not obligated to share their creations.  One person complained
quite aggressively that sharing work creates the burden of maintenance.
That is fine.  I agree, that if you share something people may bug you about
it, and maybe you don't want to deal with that.  So again, nobody should be
expected to share their work.

What I found puzzling was that people objected to others sharing
libraries.  They argued that libraries served no purpose, they weren't
desirable or necessary, and we shouldn't try to support them, or develop
capabilities to make it easier to use them in OpenSCAD.  This group
apparently thought that everybody should just write their own stuff, alone.
That was how they worked, and it was how everyone should work.
Unfortunately, based on private emails I had, this hostility seemed to be
driving away people who might have been interested in making contributions.
:(

Another issue with libraries is how you actually use the objects in the
library.  For example, BOSL2 has an attachment mechanism that can make it
easy to stick library objects onto other objects (similar to the Relativity
library).  But this type of feature is by no means universal.  The question
I guess is whether any library can become sufficiently adopted as to be seen
as a standard.  (There is a "standard" library called MCAD.  I don't
recommend it.)

skypuppy wrote

--
Sent from: http://forum.openscad.org/

I think this is the reason why it's frustrating to see that everybody writes
their own library.  Some of these issues are pretty tricky...and they've
also been discussed at great length for years on this forum or in other
places.  Instead of building on previous work, everybody just reinvents the
wheel.  Again and again and again.

When I implemented path sweep I took a look at those discussions and prior
work and I concluded that you need multiple options for handling twist
because no one method works for all cases.  There is a method that is robust
and will work for any path, but it tends to produce mysterious and often
obnoxious twisting.  There are other methods that control the twist, but
they can fail if the path has certain properties.  There's also the case
where you actually know what twist you want, such as putting an object onto
the surface of another object.

I wonder how many people realize that the fastest way to compute beziers in
openscad is using matrix products instead of the recursive casteljau method.
Again, the constant reinvention of the wheel really stands in the way of
progress.

acwest wrote

--
Sent from: http://forum.openscad.org/

It's not a programming language in the classic iterative sense because it
has no external inputs or behaviour changes. It's just a data structure
encoding. There is a fixed mapping between an openscad file and an STL
file so they are basically the same thing. One happens to be easier
to write.

There is at least one OpenSCAD relative that can do rounding nicely, but
it lacks the nice UI which is a key bit of OpenSCAD.

What I was trying to say though is

If you wanted to write a python library for working with openscad models
or using python syntax for it you can trivially write it so that the
python just outputs an openscad syntax file. In fact it's been done -
several times.

If you want to be able to manipulate the object through python
effectively though you end up with something that looks very different to
OpenSCAD because to provide useful extra power you need access to the
underlying data structures. Take a look at the python bindings to blender
and the access you have. Without that level of access and the ability to
mix in conditional behaviour and impure calculations you are just writing
openscad in a different format. With that, you don't actually want it
to look like OpenSCAD IMHO because you want to be able to do stuff like
reach into the vertex lists.

A good example would be creating a flat 2D object, extruding it and then
bending it. It's a classic problem when moving flat media model designs
to 3D print. OpenSCAD can't do it. You can take the flat 2D object, give
it thickness but you can't then bend it. A python syntax openscad would
be the same. Blender can do it because you can reach into the data
structures to do the bend in python. IOW to make a meaningfully better
programming language interface you need to be able to reach into objects
and directly manipulate them so you can write stuff like bend(),
centreof(), volumeof() etc.

If you are a programmer then that blender like interface is powerful. If
you are a non programmer then you want a primitive that bends an object
along a vector so you don't have to be a programmer.

Alan

Alan Cox-2 wrote

Not sure what you mean.  It's not iterative---it's a functional language,
using recursion instead of iteration.  Still a programming language.  It's
Turing complete.  Every programming language  is a fixed mapping between its
inputs and its outputs, unless you introduce a source of random bits.    I
mean, only certain types of I/O are possible in OpenSCAD, but that doesn't
make it not a programming language.

--
Sent from: http://forum.openscad.org/

Openscad is a fairly pure functional programming language, which makes it
somewhat hard to get used to if all you have used is procedural languages.
It is fairly unique amongst functional languages in that functions are not
passable as arguments, however (unless that has changed, I remember there
has been much discussion of the subject)

On Thu, 26 Nov 2020, 21:15 adrianv, avm4@cornell.edu wrote:

On 27.11.20 03:30, A. Craig West wrote:

They are for about a year now (in the snapshot version with the
feature enabled).

https://github.com/thehans/funcutils

ciao,
Torsten.

In the dev version there is an experimental feature you can turn on called
"function literals" that allows functions to be passed.

acwest wrote

--
Sent from: http://forum.openscad.org/

That explains it then, I thought it was available, but for compatibility
reasons I limit myself to release versions

On Thu, 26 Nov 2020, 21:38 adrianv, avm4@cornell.edu wrote:

I honestly don’t care whether we go to Python or Ruby or Javascript.  I just want a well developed, well designed scripting language, with proper data structures and classes, that is at least somewhat C-like.

I can care less if it has indentation as a syntax or not.  I used to hate the idea of Python’s indentation requirements. Then I found that said requirements were pretty much how I wanted to indent naturally anyways.

Ruby’s syntax, as I recall, has the nice feature that function return values are implied as the last calculation, which could shorten syntax for SCAD-like scripts.

JavaScript, while not my favorite syntax, can be securely embeddable, and can have Just In Time compilation.  There’s ALREADY a JavaScript OpenSCAD-a-like called OpenJSCAD, that can read OpenSCAD source files. However, it lacks some functionality (hull, minkowski, projection), hasn’t been updated in 3 years, only really runs in a web browser, and isn’t command-line scriptable.

I dunno.  I could be all for piling onto OpenJSCAD and fixing it’s limitations.  Packing it up as a standalone app.

• Revar

On 2020-11-27 03:11, Hugo Jackson wrote:

That's wrong. You can perfectly well do threading with CSG, and AngelCAD
does it. That is part of the reason it is much faster than OpenSCAD,
even when processing .scad scripts. Why OpenSCAD doesn't is purely
related to implementation issues, it is not a nature of CSG. Yes, there
are some limitations that will give diminishing returns late in the
processing, but in sum you can increase performance by at least an an
order of magnitude using threading.

That was my proposal earlier also. I think it is a bad mistake to put in
the subject of this thread "OpenSCAD language - replace it with
Python3". It seems like an initiative to shut the discussion down,
because that proposal will for sure end in a "No".

Obviously, providing some other language interface, like Python or
whatever should not mean to abandon, deprecate or "replace" the OpenSCAD
.scad language. Anyone serious in software maintenance knows that you
have have backwards compatibility. So instead of saying the language
will be "replaced" one should declare that it will be supported. But
that does not preclude progress using other languages.

Offering another language therefore requires the language to be
separated from the boolean algorithms and an API provided.

The first milestone of such work should be to implement and document the
API, and then re-implement the existing .scad language on top of it,
using the existing examples as proof that it works. Once that is
complete, then the API can be offered to others to implement their
Python, Javascript, AngelScript ... or whatever ... language front ends.

Carsten Arnholm

That was sort fo the point I was trying to make - if you just plug
it into python it is not a functional language/data structure any more.

Everything in the way openscad works is built around that model. Try
adding random() to OpenSCAD and watch the world fall apart around you.
All the caching and other things it does stop working.

If you try and use python as the openscad language you'd have to rewrite
a lot of the core of the program. At that point you might as well just
use the libraries that OpenSCAD does and chunks of the OpenSCAD object
manipulation code to write something different, that was a proper python
library for manipulating 3D constructive geometry - like Blender has.

Alan

On 11/26/2020 4:43 PM, adrianv wrote:

I don't remember so much hostility as apathy and disinterest.  I know
that was my reaction.  I reviewed my ~10K line project and came to the
conclusion that only a few percent of it could reasonably be replaced by
generic libraries.  I simply don't spend enough time reinventing that
stuff to even make it worth the effort to go find what exists, much less
to spend any time building up a library/package infrastructure.

The vast majority of my work has been in modeling - not in the computer
sense of creating a 3D representation of something, but in the generic
sense of producing a duplicate of an existing physical object.  I'm not
doing mechanical design, so I look at screw-and-gear libraries and say
"that's nice, but I don't have any use for it".  I look at "up", "down",
"xscale", "triangle", and similar, and say "uh, what's wrong with
translate,  scale, and circle?".  None of the libraries that I've looked
at have provided enough value to me for me to spend the effort to adopt
them.

Libraries are fine.  Libraries are great.  By all means, write them.  By
all means, build dependency/version trackers and packaging systems.  But
so far I don't have any interest in using them or working on them.