VM ALL THE TINGS! (Was Re: elegant export to G-code from w/in OpenSCAD?)

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

VM ALL THE TINGS! (Was Re: elegant export to G-code from w/in OpenSCAD?)

Jay Vaughan

I'm de-lurking on this list from digest- mode, but I have to say that this recent thread has gotten a bit .. interesting .. shall we say.  Some of you folks are spending a lot of time writing words about making extreme direction/policy/programming changes about OpenSCAD that could actually just be programming changes, themselves, for OpenSCAD.  i.e. nice to know the thoughts about the project, but I'm with Alan on this: how 'bout some patches?

Okay, I am nothing but a dire lurker in the OpenSCAD scene, an incontrovertible wallflower, but having seen it boot up over the years among some who I consider my fellows, I feel I must now pitch in because Marius has said some interesting things that made me look at the OpenSCAD sources a-fresh, and I just had an idea:


> From: Marius Kintel <[hidden email]>
> Subject: Re: [OpenSCAD] elegant export to G-code from w/in OpenSCAD?
> My idea is to keep moving forward, while keeping front- and back-ends as separate as possible and as modular as possible, then simply rewrite the needed parts when time is right.
>

Why not keep moving forward, in fact abandon nothing, yet but stick a Lua VM in there that can be used to manage the SCAD script sandbox?  Incidentally, on the moving forward bit, i.e. please ignore all calls to abandon OpenSCAD by the cognescenti, but ..

> In terms of syntax - it that's really the problem (I feel it's not, syntax got us where we are today), we can re-invent a new, clean syntax from scratch and write a converter. That would be some work, and I feel it shouldn't be done in C++ this time ;)

.. well, the C++ that is there would support a pretty nice little VM stack, to be honest.  Leave all the code where it is, just get access to it from a VM-based environment; use Lua to solve all language/programmer problems (because, frankly, its just a great language to use for a lot of things, whereas Python and Javascript .. well .. aren't.  JUST IMHO, *ducks a shoe* ..)

If the OpenSCAD engine had at least a Lua VM that allowed the sandboxing of the SCAD script process/flow/control, then it opens the door for a great deal of easy User Interface advances.  Other, Lua-based environments could be used to generate the user interface for the OpenSCAD pipeline, better implement new features without heavy platform/lib dependency, and so on.  There is no reason not to add features to the SCAD script, also; I'm advocating a Lua-based VM approach, because well I'm also a bike-shedding wallflower, to boot!  ;)

> Technical discussions on where to go next is welcome!
>


So the reason I feel compelled, at great personal risk, to recommend a fresh look at Lua, is that in terms of the kind of coding style which the Lua language allows, its very compatible with what you've got already.  i.e. src/openscad.cc - looks already very Lua'ish to me, as do many other of the existing OpenSCAD project source files, to be honest..

;)

;
--
Jay Vaughan




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: VM ALL THE TINGS! (Was Re: elegant export to G-code from w/in OpenSCAD?)

Taylor Alexander

Lua certainly would work. I favor Python for its extensibility though. Python can zip and unzip files, parse XML documents like eagle board files, talk to 3D printers (or invoke pronterface), etc. And it can do so in a platform agnostic way.

Lua can't do those things nearly as easily as far as I know. I've used it and it works, but having spent several weeks on Lua in the past and just few days so far writing Python scripts, I'm already more comfortable writing in Python than in Lua.

And again, lots of people are learning python, and learning it teaches newbies super useful skills. Lua is used less often, so fewer people know it and fewer people would benefit from making the effort to learn it.

And for reference, I know plenty of other languages: C, C++, Java (android), C# (windows), processing/wiring (Basically java), so I'm not just suggesting python because I just learned it - I've been looking for a good clean cross platform script-like language and python is really looking pretty good. Its popular, easy to learn, extensible, and well supported.

But then, I don't have much time to work on this kinda thing at the moment so maybe I shouldn't be talkin.

On Apr 17, 2013 1:04 AM, "Jay Vaughan" <[hidden email]> wrote:

I'm de-lurking on this list from digest- mode, but I have to say that this recent thread has gotten a bit .. interesting .. shall we say.  Some of you folks are spending a lot of time writing words about making extreme direction/policy/programming changes about OpenSCAD that could actually just be programming changes, themselves, for OpenSCAD.  i.e. nice to know the thoughts about the project, but I'm with Alan on this: how 'bout some patches?

Okay, I am nothing but a dire lurker in the OpenSCAD scene, an incontrovertible wallflower, but having seen it boot up over the years among some who I consider my fellows, I feel I must now pitch in because Marius has said some interesting things that made me look at the OpenSCAD sources a-fresh, and I just had an idea:


> From: Marius Kintel <[hidden email]>
> Subject: Re: [OpenSCAD] elegant export to G-code from w/in OpenSCAD?
> My idea is to keep moving forward, while keeping front- and back-ends as separate as possible and as modular as possible, then simply rewrite the needed parts when time is right.
>

Why not keep moving forward, in fact abandon nothing, yet but stick a Lua VM in there that can be used to manage the SCAD script sandbox?  Incidentally, on the moving forward bit, i.e. please ignore all calls to abandon OpenSCAD by the cognescenti, but ..

> In terms of syntax - it that's really the problem (I feel it's not, syntax got us where we are today), we can re-invent a new, clean syntax from scratch and write a converter. That would be some work, and I feel it shouldn't be done in C++ this time ;)

.. well, the C++ that is there would support a pretty nice little VM stack, to be honest.  Leave all the code where it is, just get access to it from a VM-based environment; use Lua to solve all language/programmer problems (because, frankly, its just a great language to use for a lot of things, whereas Python and Javascript .. well .. aren't.  JUST IMHO, *ducks a shoe* ..)

If the OpenSCAD engine had at least a Lua VM that allowed the sandboxing of the SCAD script process/flow/control, then it opens the door for a great deal of easy User Interface advances.  Other, Lua-based environments could be used to generate the user interface for the OpenSCAD pipeline, better implement new features without heavy platform/lib dependency, and so on.  There is no reason not to add features to the SCAD script, also; I'm advocating a Lua-based VM approach, because well I'm also a bike-shedding wallflower, to boot!  ;)

> Technical discussions on where to go next is welcome!
>


So the reason I feel compelled, at great personal risk, to recommend a fresh look at Lua, is that in terms of the kind of coding style which the Lua language allows, its very compatible with what you've got already.  i.e. src/openscad.cc - looks already very Lua'ish to me, as do many other of the existing OpenSCAD project source files, to be honest..

;)

;
--
Jay Vaughan




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566
Reply | Threaded
Open this post in threaded view
|

Re: VM ALL THE TINGS! (Was Re: elegant export to G-code from w/in OpenSCAD?)

kintel
Administrator
In reply to this post by Jay Vaughan
Lots of discussion here - I barely have time to read it all ;)

Regarding scripting languages, the discussion is really twofold:

When I mentioned Javascript, I was really pointing to the fact that the world seems to be powered by Javascript these days, and that eventually means that the OpenSCAD engine (or at least the front-end) should run on a Javascript VM. That doesn't necessarily mean that Javascriptiness sneaks into the OpenSCAD language itself, although I can see why that's tempting (ref. OpenJsCad). Now that you can actually run LLVM-compiled code on Javascript, this would be achievable in more or less any language.

In terms of the OpenSCAD language itself, the two strong forces are pushing it more in the direction of a pure functional language vs. allowing people to insert code snippets (with no side effects) in some other language as helper functions. Lua and Javascript are the two primary languages on my radar for imperative snippet writing (due to the shear popularity and simplicity of them). For extending into the functional domain, the choice would be to extend what we have today, or to chose an existing execution environment and make OpenSCAD be an API/DSL on top of that one.

For using OpenSCAD with Python, I believe the best way would be to write a Python library supplying the various OpenSCAD modules, and have that library generate an (exploded) OpenSCAD file (aka .csg) which can be fed to the backend. I think one of the OpenSCAD-python projects at least started on that.

Lots of room for work here ;)

 -Marius

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://rocklinux.net/mailman/listinfo/openscad
http://openscad.org - https://flattr.com/thing/121566