New follower and question about script flow

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

New follower and question about script flow

schulzeg
Hi,

I’m Gunnar and I recently stumbled across OpenSCAD during a discussion on
the reprap forum (http://forums.reprap.org/read.php?1,71740). Let me first
say, that I think that OpenSCAD is really a great idea and that I would
like to participate in the project as my (unfortunately limited) time
allows. I have some experience with numerical and analytical mathematics
and C/C++ coding and I already work on a project related to 3D objects.

Yesterday I gave it a first trial and constructed a test object for 3d
printers (the resulting mesh: http://www.trinckle.com/object.php?id=37).
During this, I encountered some questions about the whole system that I
would like to address and maybe we can discuss this a bit.

The first thing that I am wondering about is the unusual way of script
interpretation regarding the assignment of memory objects as variables. It
seems to me that the script is not parsed in a progressive way but rather
sets all variables in one instance. In addition there seems to be no
differentiation between local living spaces of variables and the global
one. Commands like the assign() command are available to circumvent some
of the problems that result from that but this makes it difficult to give
a good structure to the code. Besides that, the "for()-assign()"
construction makes some goals pretty hard to achieve as e.g. the
computation of a sum whose partial sums cannot be expressed in a closed
form. Is there a reason for this behavior or would it be better to rebuild
the script compiler in a way that allows the progressive assignment of
variables and that differentiates between different living spaces?

I have a couple of questions and ideas more, but I will post them at a
later time. Until then I will have a look at the code and try to get into
it a bit, if you don’t mind.

I thank all of you for your attention,
Gunnar

---------------------------
Gunnar Schulze
Berlin, Germany
[hidden email]
---------------------------


Reply | Threaded
Open this post in threaded view
|

Re: New follower and question about script flow

schulzeg
Giles, thank you for your answer. I had a look at the RapCAD page and on
the grammar for the bison parser. I think you're on the right way.

> What you are talking about here is essentially variables that can
> vary.... and a procedural syntax rather than a declarative one. I
> looked at how this might be implemented in OpenSCAD and realised that
> it might need quite a major rewrite.

Is this because of the exact computing paradigm of the underlying CGAL
library? In any case I see one possibility to introduce a procedural
syntax without touching too much of the code: one could introduce an
initial processing step that parses the procedural code, runs it
"virtually" (without generating the solids) and expands it to a
declarative code script, maybe comparable to the "unroll loop" procedure
of some compilers. Then the "normal" compilation and generation can be
applied on the newly created declarative code. It may sound a bit like a
work-around but it should be implementable without destroying the whole
OpenSCAD-code. What do you think?

Maybe one should first finish the RapCAD code compiler and then plug these
parts into OpenSCAD. In any case it would be desirable to have the same
(procedural) script language running on both programs. Giles, how is the
state of the RapCAD compiler? Can you give me a link to the code and is
there a way for me to contribute? As I already stated, I don't have too
much time, but maybe I find a way to add a little bit. I think that the
OpenSCAD project should be opened for the advanced possibilities of
procedural programming as soon as possible.

Greetings,
Gunnar

---------------------------
Gunnar Schulze
Berlin, Germany
[hidden email]
---------------------------



Reply | Threaded
Open this post in threaded view
|

Re: New follower and question about script flow

Giles Bathgate-2
On 8 April 2011 14:03,  <[hidden email]> wrote:

> Is this because of the exact computing paradigm of the underlying CGAL
> library? In any case I see one possibility to introduce a procedural
> syntax without touching too much of the code: one could introduce an
> initial processing step that parses the procedural code, runs it
> "virtually" (without generating the solids) and expands it to a
> declarative code script, maybe comparable to the "unroll loop" procedure
> of some compilers. Then the "normal" compilation and generation can be
> applied on the newly created declarative code. It may sound a bit like a
> work-around but it should be implementable without destroying the whole
> OpenSCAD-code. What do you think?

I think you have hit on a similar idea to that which Marius and I have been
discussing over the last few weeks. Some of the details about this
and his suggestion can be seen on my blog post just published today
http://www.rapcad.org/?p=145

> Maybe one should first finish the RapCAD code compiler and then plug these
> parts into OpenSCAD. In any case it would be desirable to have the same
> (procedural) script language running on both programs. Giles, how is the
> state of the RapCAD compiler? Can you give me a link to the code and is
> there a way for me to contribute? As I already stated, I don't have too
> much time, but maybe I find a way to add a little bit. I think that the
> OpenSCAD project should be opened for the advanced possibilities of
> procedural programming as soon as possible.

The code is here http://git.rapcad.org/cgit.cgi/rapcad/ for collaboration
you can clone and do merge requests with the gitorious repository
http://gitorious.org/rapcad

Regards

Giles Bathgate

Reply | Threaded
Open this post in threaded view
|

Re: New follower and question about script flow

Clifford Wolf
In reply to this post by schulzeg
Hi,

On Thu, Apr 07, 2011 at 10:19:12AM +0200, [hidden email] wrote:
> During this, I encountered some questions about the whole system that I
> would like to address and maybe we can discuss this a bit.

marius pointed out in a private mail that I might be the right person to
answer some of your questions as I am the one who originally designed
openscad. (however: he might be the better person to talk to when it comes
to change the way openscad will work in the future as I passed project
maintainership to him)

> The first thing that I am wondering about is the unusual way of script
> interpretation regarding the assignment of memory objects as variables. It
> seems to me that the script is not parsed in a progressive way but rather
> sets all variables in one instance.

Openscad parses the input in a progressive order - but the relative order
of module instances and variable assignment inside a module is not
preserved inside the resulting module object (the openscad AST is a tree of
module objects).

The important thing to understand here that the Openscad language is a
computer language but not a programming language. With your code you do not
describe a computer program but a CAD object. (Of course this is something
that might be open to discussion: I just state the current situation.)

So the term "variable" in openscad does _not_ refer to the concept of a
variable in programming: something that can re assigned and re-assigned at
will -- but instead refers to the concept of a variable in mathematics:
something that is left open when a formula is written and assigned exactly
once each time the formula or sub-formula is used.

The openscad language never was intended to be a turing complete
programming language. It always was only ment as a way to descibe an object
in a convinient way.

I realize that somethimes the convinient way to descibe an object is using
a real program. The idea here is to write a program in a real programming
language that can generate openscad code.

Simmilary it might sometimes be convinient to use a CAS to describe an
object (e.g. for determining the value for some variables). OpenSCAD is not
a CAS but you can use one along with OpenSCAD to create your design.

> In addition there seems to be no differentiation between local living
> spaces of variables and the global one. Commands like the assign()
> command are available to circumvent some of the problems that result from
> that but this makes it difficult to give a good structure to the code.
> Besides that, the "for()-assign()" construction makes some goals pretty
> hard to achieve as e.g. the computation of a sum whose partial sums
> cannot be expressed in a closed form.

I see what you are trying to do but somwthing like that is simply not
possible with this for statement. This for statement is only ment for
generating CAD objects in a loop - not execute calculations.

The right way to do what you are trying to do is (imo) to extend openscad
to have functions like sum() that can evaluate a sum that can't be
expressed using a closed form or write a script that generates openscad
code.

If the sum can be expressed in a closed form I'd recommend using a CAS
(e.g. maxima) to find this closed form (if the help of a CAS is needed)
and use this expression instead.

> Is there a reason for this behavior or would it be better to rebuild
> the script compiler in a way that allows the progressive assignment of
> variables and that differentiates between different living spaces?

sure - it would be possible to do that. But it would go far beyond simply
"extending" the engine to do somewithg differently - it would be replacing
the current openscad frontend engine (the input to "module" parser and
"module" to "node" evaluator) by a different kind of engine.

For me - as I know what the openscad engine is intended to do and what I
always intended to be done in outside scripts that generate openscad code -
some of the feature requests for converting openscad to a full featured
programming language are like complaints that it is so hard to solve
systems of differential equations directly in LaTeX for a paper that
contains such systems and the solutions. Sure: it might be possible. But
LaTeX is ment to generate a nice printable representation of the paper -
not to actually do the scientific work behind it.

Likewise OpenSCAD was intended to generate 2D and 3D objects using a tree of
primitive objects, CSG operations and other 2D/3D operations - but not for
solving complex problems that lead to this tree of geometric primitives and
geometric operations.

> I have a couple of questions and ideas more, but I will post them at a
> later time. Until then I will have a look at the code and try to get into
> it a bit, if you don?t mind.

Dont get me wrong: I don't say that I'm against extending openscad to
become a full featured programming language. I just say it was never my
intention to do so - maybe marius and the other "actives" think differently
about it now -- and if so it's all fine with me.

My original idea was to let people choose their own prgogramming languages
(they all have their preferences and each language has it ups and downs)
for doing things that need a real programming language and just use
openscad as backend for fiddling with the polyhedrons.

yours,
 - clifford

--
there's no place like 127.0.0.1
until we found ::1 -- which is even bigger