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: