OpenSCAD language - replace it with Python3
On Wed, 2020-11-25 at 01:49 -0800, Revar Desmera 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.
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:
Have you checked out https://github.com/SolidCode/SolidPython ?
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:
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.
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
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
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@.openscad
] 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@
> 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@
> wrote:
On 25.11.2020 07:08, Revar Desmera wrote:
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.
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@.openscad
Discuss@.openscad
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
OpenSCAD mailing list
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
On 25.11.20 14:47, adrianv wrote:
One such basic missing function that everybody seems
to write at some point is sweep, to give a simple
example.
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:
-
How do I learn enough about the OpenSCAD internals to do things that are
actually good. -
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
On 25.11.20 14:47, adrianv wrote:
One such basic missing function that everybody seems
to write at some point is sweep, to give a simple
example.
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.
OpenSCAD mailing list
Discuss@.openscad
--
Sent from: http://forum.openscad.org/
On 25.11.20 16:53, adrianv wrote:
- How do I learn enough about the OpenSCAD internals
to do things that are actually good.
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.
- 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.
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.
I think about this question every once in a while. Kudos and thanks to
the OpenSCAD developers, but a depressing amount of the work that they
do and have done is to reinvent wheels. Here are some disorganized
thoughts on the subject.
Building an OpenSCAD-esque infrastructure in Python is not difficult.
I got interested in it, and spent about a day writing a Python
infrastructure that let me say things like
## create cube & sphere in default positions
d = 100
mycub = Cube(d)
mysph = Sphere(d*0.6)
## move the sphere in z-direction and subtract from cube
mycub.subtract(mysph.translate([0,0,d])).render()
That's a complete working program. If you feed it to my infrastructure,
it'll spit out an xcsg file that you can then post-process into STL or
whatever.
My intent was to design something that would let you work with geometry
in a way that was as simple as OpenSCAD, but was "natural" to Python:
geometric objects as Python objects, with methods. I'm reasonably happy
with the result.
It's less than 300 lines of Python, and it implements basic shapes
(polygons, cubes, spheres, cylinders), the basic transforms (rotate,
scale, translate), booleans (union, difference, intersection, hull), and
enough wrapping to minimize the amount of boilerplate required to
express a model. (The one piece of boilerplate that I couldn't figure
out how to eliminate was the ".render()" at the end, to actually place a
piece of geometry into the model.)
But that's the easy part. The next, harder, part is integrating such a
thing into an IDE so that you can just push a button to render your
model, and another button to spit out STL. Next is packaging, making it
so that the user can install one thing, and have a working
environment. Then the hardest part is adoption, growing a community
large enough to be interesting, so that you can get sweep functions, and
gears, and bezier curves, and so on, without having to invent
everything yourself.
And those latter parts are why I have abandoned the project. OpenSCAD
is not perfect, but the costs to make something better are higher than
I'm able to spend without adoption, and adoption is hard.
Why Python? Why not JavaScript? Why not some custom language?
The last, why not a custom language, is the easiest: the goal is to
stop inventing language wheels. You'll do a lot of work, and then
you'll end up with a language that nobody knows, that has all its own
quirks, that doesn't have any established ecosystem, doesn't have any
books written about it, et cetera.
Why Python and not JavaScript? Because everybody has a browser, but a
browser isn't the right platform for a desktop-centric IDE... and few
people have Node.js. Again, adoption. I like JavaScript more than I
like Python, and I love Node.js and use it in another project, but for
whatever reason it hasn't turned into the kind of "ad hoc project"
platform that Python has.
I should note that for "real" projects, I don't like either of
them. I'm a "strict typing" guy; real projects need the kinds of
static analysis that you can only get in strongly typed languages.
Why not do this?
One thing that concerns me about using a general-purpose language is
sandboxing. If I download an OpenSCAD program, I can be reasonably
confident that running it will not trash my system, because OpenSCAD
doesn't have the tools required to let a program trash my system. (It
might have bugs that would allow a malicious program to escape the
sandbox, but that's a lot more work for the villain than just using
built-in tools.) That sandboxing has real advantages.
Is it a library, or is it an environment?
One might notice that my example above does not include an "import"
statement. That's deliberate. It's not a library. It's not a library
that lets you do modeling in your Python program. Rather, it's a
modeling environment that lets you write Python programs. If it's going
to replace OpenSCAD, it's got to be as easy as OpenSCAD. The minimum
OpenSCAD program is "cube(10)". Anything that makes the minimum program
be more complex than that is a problem. (I spent a while trying to
figure out whether I could get rid of the ".render()", for exactly that
reason. I suspect that there's something that could be done, REPL-like,
that sucks up "orphan" objects into the model, but I wasn't able to
figure it out.) Also, the "environment" model may make sandboxing more
practical.
Why not SolidPython?
I didn't like the "emits OpenSCAD as an intermediate" model. I don't
like the OpenSCAD-style methods it uses; I want more natural Python
methods-on-objects. My goal is not to implement OpenSCAD in Python, but
rather to allow you to write simple Python programs to create models.
And of course for whatever reason I didn't look at it until after I had
a mental model of what I wanted, and it didn't match.
Why not Blender? It has Python plug-ins.
This was a real disappointment. A 3D design system with embedded
Python? How could it go wrong? Well, first, I've never been able to
wrap my head around Blender's UI. The learning curve is just too
steep. But worse, for my purposes, is that Blender's Python interface
is fantastically complex. I don't remember whether I ever even figured
out how to drop a cube into the model. I'm not sure what problems they
were trying to solve with it, but replacing OpenSCAD wasn't one of them.
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 think about this question every once in a while. Kudos and thanks
to the OpenSCAD developers, but a depressing amount of the work that
they do and have done is to reinvent wheels. Here are some
disorganized thoughts on the subject.
Building an OpenSCAD-esque infrastructure in Python is not difficult.
I got interested in it, and spent about a day writing a Python
infrastructure that let me say things like
create cube & sphere in default positions
d = 100
mycub = Cube(d)
mysph = Sphere(d*0.6)
move the sphere in z-direction and subtract from cube
mycub.subtract(mysph.translate([0,0,d])).render()
That's a complete working program. If you feed it to my
infrastructure, it'll spit out an xcsg file that you can then post-
process into STL or whatever.
My intent was to design something that would let you work with
geometry in a way that was as simple as OpenSCAD, but was "natural"
to Python: geometric objects as Python objects, with methods. I'm
reasonably happy with the result.
It's less than 300 lines of Python, and it implements basic shapes
(polygons, cubes, spheres, cylinders), the basic transforms (rotate,
scale, translate), booleans (union, difference, intersection, hull),
and enough wrapping to minimize the amount of boilerplate required to
express a model. (The one piece of boilerplate that I couldn't
figure out how to eliminate was the ".render()" at the end, to
actually place a piece of geometry into the model.)
But that's the easy part. The next, harder, part is integrating such
a thing into an IDE so that you can just push a button to render your
model, and another button to spit out STL. Next is packaging, making
it so that the user can install one thing, and have a working
environment. Then the hardest part is adoption, growing a community
large enough to be interesting, so that you can get sweep functions,
and gears, and bezier curves, and so on, without having to invent
everything yourself.
And those latter parts are why I have abandoned the project.
OpenSCAD is not perfect, but the costs to make something better are
higher than I'm able to spend without adoption, and adoption is
hard.
Why Python? Why not JavaScript? Why not some custom language?
The last, why not a custom language, is the easiest: the goal is to
stop inventing language wheels. You'll do a lot of work, and then
you'll end up with a language that nobody knows, that has all its own
quirks, that doesn't have any established ecosystem, doesn't have any
books written about it, et cetera.
Why Python and not JavaScript? Because everybody has a browser, but
a browser isn't the right platform for a desktop-centric IDE... and
few people have Node.js. Again, adoption. I like JavaScript more
than I like Python, and I love Node.js and use it in another project,
but for whatever reason it hasn't turned into the kind of "ad hoc
project" platform that Python has.
I should note that for "real" projects, I don't like either of
them. I'm a "strict typing" guy; real projects need the kinds of
static analysis that you can only get in strongly typed languages.
Why not do this?
One thing that concerns me about using a general-purpose language is
sandboxing. If I download an OpenSCAD program, I can be reasonably
confident that running it will not trash my system, because OpenSCAD
doesn't have the tools required to let a program trash my system.
(It might have bugs that would allow a malicious program to escape
the sandbox, but that's a lot more work for the villain than just
using built-in tools.) That sandboxing has real advantages.
Is it a library, or is it an environment?
One might notice that my example above does not include an "import"
statement. That's deliberate. It's not a library. It's not a
library that lets you do modeling in your Python program. Rather,
it's a modeling environment that lets you write Python programs. If
it's going to replace OpenSCAD, it's got to be as easy as OpenSCAD.
The minimum OpenSCAD program is "cube(10)". Anything that makes the
minimum program be more complex than that is a problem. (I spent a
while trying to figure out whether I could get rid of the
".render()", for exactly that reason. I suspect that there's
something that could be done, REPL-like, that sucks up "orphan"
objects into the model, but I wasn't able to figure it out.) Also,
the "environment" model may make sandboxing more practical.
Why not SolidPython?
I didn't like the "emits OpenSCAD as an intermediate" model. I don't
like the OpenSCAD-style methods it uses; I want more natural Python
methods-on-objects. My goal is not to implement OpenSCAD in Python,
but rather to allow you to write simple Python programs to create
models.
And of course for whatever reason I didn't look at it until after I
had a mental model of what I wanted, and it didn't match.
Why not Blender? It has Python plug-ins.
This was a real disappointment. A 3D design system with embedded
Python? How could it go wrong? Well, first, I've never been able to
wrap my head around Blender's UI. The learning curve is just too
steep. But worse, for my purposes, is that Blender's Python
interface is fantastically complex. I don't remember whether I ever
even figured out how to drop a cube into the model. I'm not sure
what problems they were trying to solve with it, but replacing
OpenSCAD wasn't one of them.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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
On 25.11.20 16:53, adrianv wrote:
- How do I learn enough about the OpenSCAD internals
to do things that are actually good.
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.
- 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.
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.
OpenSCAD mailing list
Discuss@.openscad
--
Sent from: http://forum.openscad.org/