Lua luau.

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

Lua luau.

RevarBat

Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?

Yeah, well Python isn’t easily embeddable, and has security implications.

Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!).  It lacks object orientation, but we never had that anyways. Even just having tables makes a number of algorithms far faster and easier to implement. 

This could easily become a thing. It really should. 


-Revar


On Mar 19, 2021, at 10:48 AM, Carsten Fuchs <[hidden email]> wrote:

Please forgive me, but if it was ever considered to add imperative language support to OpenSCAD: Lua (http://www.lua.org/) would be a perfect fit! (And it would open OpenSCAD to folks who don't have a degree in CS…)

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

Whosawhatsis
Changing OpenSCAD to use a different language is a terrible idea, because you would break compatibility with all of the existing OpenSCAD code, and force the people who know how to use it to re-learn it. The python 2.x to python 3.x changed enough to make existing projects and libraries incompatible, and it's taken over 10 years to get people to use the new system. Trying to rip out the core of the language syntax and replace it would be even worse.

https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

If OpenSCAD had features like true variables and OOP capabilities, would I use them? Of course I would, but they would need to be added in a way that maintained backward-compatibility and didn't fundamentally change the structure of the language. Replacing the core of the language with Python, Lua, Javascript, Haskell, FORTRAN, or native american smoke signals isn't something you can do without breaking everything.
On Mar 19, 2021, 14:27 -0700, Revar Desmera <[hidden email]>, wrote:

Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?

Yeah, well Python isn’t easily embeddable, and has security implications.

Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!).  It lacks object orientation, but we never had that anyways. Even just having tables makes a number of algorithms far faster and easier to implement. 

This could easily become a thing. It really should. 


-Revar


On Mar 19, 2021, at 10:48 AM, Carsten Fuchs <[hidden email]> wrote:

Please forgive me, but if it was ever considered to add imperative language support to OpenSCAD: Lua (http://www.lua.org/) would be a perfect fit! (And it would open OpenSCAD to folks who don't have a degree in CS…)
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

JordanBrown
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD.  It wouldn't, or at least it would need some major distinguisher in its name.  It would be PySCAD or LuaSCAD or OpenJSCAD or something.  Maybe, but probably not, OpenSCAD2.

So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter.  If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.

And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

Whosawhatsis
I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown <[hidden email]>, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD.  It wouldn't, or at least it would need some major distinguisher in its name.  It would be PySCAD or LuaSCAD or OpenJSCAD or something.  Maybe, but probably not, OpenSCAD2.

So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter.  If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.

And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

RevarBat
There’s very useful parts to OpenSCAD.  The Editor.  The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it.  I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work.  Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type.  Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.

For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on.  And absolutely no-one has a good library management system.  Something like how the Arduino app lets you search for, download, and use libraries.  File IO is another big problem.  Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things.  Being able to write even just a BOM file would make a number of people rather happy.

I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system.  Things could be SO much better than they are right now.  So much more professional.  It’s frustrating.  Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.

- Revar


On Mar 19, 2021, at 3:55 PM, Whosawhatsis <[hidden email]> wrote:

I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown <[hidden email]>, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD.  It wouldn't, or at least it would need some major distinguisher in its name.  It would be PySCAD or LuaSCAD or OpenJSCAD or something.  Maybe, but probably not, OpenSCAD2.

So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter.  If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.

And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

Whosawhatsis
Another project that might interest you, and one that should be added to the "related projects" page, is https://github.com/zalo/CascadeStudio
On Mar 19, 2021, 17:34 -0700, Revar Desmera <[hidden email]>, wrote:
There’s very useful parts to OpenSCAD.  The Editor.  The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it.  I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work.  Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type.  Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.

For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on.  And absolutely no-one has a good library management system.  Something like how the Arduino app lets you search for, download, and use libraries.  File IO is another big problem.  Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things.  Being able to write even just a BOM file would make a number of people rather happy.

I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system.  Things could be SO much better than they are right now.  So much more professional.  It’s frustrating.  Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.

- Revar


On Mar 19, 2021, at 3:55 PM, Whosawhatsis <[hidden email]> wrote:

I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown <[hidden email]>, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD.  It wouldn't, or at least it would need some major distinguisher in its name.  It would be PySCAD or LuaSCAD or OpenJSCAD or something.  Maybe, but probably not, OpenSCAD2.

So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter.  If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.

And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

mixotricha
In reply to this post by RevarBat
I've been here. I came in here years ago looking for a fight about this :)

When you start to take apart the code base unwinding the language from the code isn't impossible. The grammar is clearly defined. But is not the best way. Leave the OpenSCAD as it is.

I've got about 60% of the way through a paper on this. Covers the whole lot all the way out to the clustering. 

My code repository is here : https://gitlab.com/mixotricha/elixir-makertron

I've not updated my docs or put the paper up but in some sense Whosawwhatis is quite right.

Don't break OpenSCAD. Write something else instead. 

What one can do ( what I did ) is to write a secondary downstream source to source generator. Lots of reasons to do this. In my particular instance to do with performance. After I did this it was something of a break through for me as I was able to apply to a whole lot of optimizations and pipe line stuff. Parsing sits in the client. Hands out jobs to a cluster. At this this point hand woven metal basically. I've got all sorts going on inside FPGA. This path became fruitful and general for a lot of problems. Not just OpenSCAD.  


On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera <[hidden email]> wrote:
There’s very useful parts to OpenSCAD.  The Editor.  The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it.  I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work.  Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type.  Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.

For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on.  And absolutely no-one has a good library management system.  Something like how the Arduino app lets you search for, download, and use libraries.  File IO is another big problem.  Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things.  Being able to write even just a BOM file would make a number of people rather happy.

I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system.  Things could be SO much better than they are right now.  So much more professional.  It’s frustrating.  Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.

- Revar


On Mar 19, 2021, at 3:55 PM, Whosawhatsis <[hidden email]> wrote:

I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown <[hidden email]>, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD.  It wouldn't, or at least it would need some major distinguisher in its name.  It would be PySCAD or LuaSCAD or OpenJSCAD or something.  Maybe, but probably not, OpenSCAD2.

So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter.  If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.

And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


--
Damien Towning

 

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

mixotricha
I also want to say that OpenSCAD is not the Iranian Yogurt here. It isn't the problem. Languages are languages. If you don't like the OpenSCAD language do what I did and source to source it. To me the more important problem ( and nothing to do with OpenSCAD ) is doing the Boolean at decent speed and making really geometry. I've been quietly working away on what I am calling the 'reverse' gold feather .... 

On Sat, Mar 20, 2021 at 12:10 PM Damien Towning <[hidden email]> wrote:
I've been here. I came in here years ago looking for a fight about this :)

When you start to take apart the code base unwinding the language from the code isn't impossible. The grammar is clearly defined. But is not the best way. Leave the OpenSCAD as it is.

I've got about 60% of the way through a paper on this. Covers the whole lot all the way out to the clustering. 

My code repository is here : https://gitlab.com/mixotricha/elixir-makertron

I've not updated my docs or put the paper up but in some sense Whosawwhatis is quite right.

Don't break OpenSCAD. Write something else instead. 

What one can do ( what I did ) is to write a secondary downstream source to source generator. Lots of reasons to do this. In my particular instance to do with performance. After I did this it was something of a break through for me as I was able to apply to a whole lot of optimizations and pipe line stuff. Parsing sits in the client. Hands out jobs to a cluster. At this this point hand woven metal basically. I've got all sorts going on inside FPGA. This path became fruitful and general for a lot of problems. Not just OpenSCAD.  


On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera <[hidden email]> wrote:
There’s very useful parts to OpenSCAD.  The Editor.  The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it.  I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work.  Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type.  Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.

For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on.  And absolutely no-one has a good library management system.  Something like how the Arduino app lets you search for, download, and use libraries.  File IO is another big problem.  Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things.  Being able to write even just a BOM file would make a number of people rather happy.

I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system.  Things could be SO much better than they are right now.  So much more professional.  It’s frustrating.  Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.

- Revar


On Mar 19, 2021, at 3:55 PM, Whosawhatsis <[hidden email]> wrote:

I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown <[hidden email]>, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD.  It wouldn't, or at least it would need some major distinguisher in its name.  It would be PySCAD or LuaSCAD or OpenJSCAD or something.  Maybe, but probably not, OpenSCAD2.

So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter.  If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.

And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


--
Damien Towning

 


--
Damien Towning

 

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

nophead
In reply to this post by mixotricha
> Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type.  

Yes but I use it to model parts, not code algorithms. I find it a good language for describing objects I want to print or vitamins that interface with them, like fasteners, fans, power supplies, etc. I don't need mutable data structures for that.

On Sat, 20 Mar 2021 at 01:11, Damien Towning <[hidden email]> wrote:
I've been here. I came in here years ago looking for a fight about this :)

When you start to take apart the code base unwinding the language from the code isn't impossible. The grammar is clearly defined. But is not the best way. Leave the OpenSCAD as it is.

I've got about 60% of the way through a paper on this. Covers the whole lot all the way out to the clustering. 

My code repository is here : https://gitlab.com/mixotricha/elixir-makertron

I've not updated my docs or put the paper up but in some sense Whosawwhatis is quite right.

Don't break OpenSCAD. Write something else instead. 

What one can do ( what I did ) is to write a secondary downstream source to source generator. Lots of reasons to do this. In my particular instance to do with performance. After I did this it was something of a break through for me as I was able to apply to a whole lot of optimizations and pipe line stuff. Parsing sits in the client. Hands out jobs to a cluster. At this this point hand woven metal basically. I've got all sorts going on inside FPGA. This path became fruitful and general for a lot of problems. Not just OpenSCAD.  


On Sat, Mar 20, 2021 at 11:34 AM Revar Desmera <[hidden email]> wrote:
There’s very useful parts to OpenSCAD.  The Editor.  The general live GUI and rendering engine. The OpenSCAD language itself is reasonable for a display language, I suppose. You can do a lot with it.  I really don’t care if it’s kept around for backwards compatibility, but it sucks for doing serious work.  Writing more complex algorithms is rather difficult or extremely inefficient, given the lack of anything resembling proper data structures or a dictionary/hashtable data type.  Trust me, I’ve written tens of thousands of lines of OpenSCAD code. It has harsh limitations that, are not apparently being addressed in any apparent way, except by people forking new projects.

For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on.  And absolutely no-one has a good library management system.  Something like how the Arduino app lets you search for, download, and use libraries.  File IO is another big problem.  Being able to read an external file, even if you have to put harsh limitations on what files you can read, or where you can read them from, would allow for a lot of useful things.  Being able to write even just a BOM file would make a number of people rather happy.

I just want a programmatic parts development system with a good GUI, an actually well developed and supported language, and an expansive library management system.  Things could be SO much better than they are right now.  So much more professional.  It’s frustrating.  Right now, OpenSCAD really hovers at the edge of being a toy language, like Processing or Logo.

- Revar


On Mar 19, 2021, at 3:55 PM, Whosawhatsis <[hidden email]> wrote:

I'm fine with an "ideas for OpenSCAD-like things based on other languages" thread, but I'm sick of people talking about it as if "ripping the OpenSCAD language out of OpenSCAD and replacing it with" something else (a direct quote) made any sense at all.
On Mar 19, 2021, 15:47 -0700, Jordan Brown <[hidden email]>, wrote:
On 3/19/2021 2:58 PM, Whosawhatsis wrote:
https://www.openscad.org/about.html has a list of related projects, most of which are implementations of OpenSCAD-like functionality with other languages (and I can think of a few others that should be on that list off the top of my head). If you want OpenSCAD-like functionality in a different language, try one of those, or start another one. Maybe it will be better and eventually get more popular than OpenSCAD, but quit trying to break OpenSCAD by forcing it to be something it isn't.

I don't think anybody is trying to say that an OpenSCAD-like environment based on another language would still be OpenSCAD.  It wouldn't, or at least it would need some major distinguisher in its name.  It would be PySCAD or LuaSCAD or OpenJSCAD or something.  Maybe, but probably not, OpenSCAD2.

So yes, if you view "the community" as being people who want to maintain OpenSCAD compatibility, such an effort would be a non-starter.  If, on the other hand, you view "the community" as being people who want to write simple programs to generate geometry, and for whom OpenSCAD is simply the best answer currently available, then a transition to a different base language would make perfect sense.

And yes, this is the "OpenSCAD general discussion" mailing list, not the "3D geometry programming language" discussion list, so such discussions here should be relatively limited.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


--
Damien Towning

 
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

Carsten Fuchs
Am 20.03.21 um 02:30 schrieb nop head:
> Yes but I use it to model parts, not code algorithms.

Until the parts get complicated…   ;-)

Best regards,
Carsten
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

mixotricha
In reply to this post by nophead
I do not think I have ever come across a geometrical language which was more parametric in nature and that adhered to ( and of course just my opinion ) a more consistent functional implementation. OpenSCAD is not functional enough for me. Imperative bits about the edges like for loops bug me. Also rather than the core hanging off the fundamentals of the boolean it would be sketches and planes and such like for me. FreeCad has some sort of python API bolted on it doesn't it? 

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

Carsten Fuchs
In reply to this post by RevarBat
Am 19.03.21 um 22:26 schrieb Revar Desmera:
> Lua, however is easily embeddable, can be secure, and is easily extendable to handle a geometry data type. Lua is a well used and supported language. It has mutable variables, first class functions, tables(!), threads(!!), and multiple assignment(!!!).

And a great standard library and easy accessibility. Lua is even easy to learn even for beginners and useful also in other domains. I've written Lua bindings to a large C++ program a while ago and can only say that it was a very good experience. I also have several friends with 3D printers and a good technical interest, motivation and understanding. They all shy away from OpenSCAD due to the inaccessibility imposed on it by its niche language.

Others have mentioned the concern of backwards-compatibility. Of course this should not and does not need to be broken at all: Lua could simply co-exist with the OpenSCAD language, without breaking anything. This would initially introduce a double load on e.g. documentation, but it would allow to shape the future of the language bindings independent of each other. I would not be surprised if the interest in the OpenSCAD language quickly faded out.

Also, when things get difficult, it is often said that the language is not the real problem and that the goal can as well be reached with the OpenSCAD language. Well, of course it can. I guess there is no problem that could eventually not be solved in OpenSCAD. However, at what cost?
I've recently implemented a few shapes that are still relatively simple and which I could have completed in an imperative language in a short time. But even with the great help I've gotten here, I still have to sit down and spend much extra time for making the algorithmic solution fit the language, foregoing program design and code maintainability.

Best regards,
Carsten
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

Troberg
In reply to this post by Whosawhatsis
Whosawhatsis wrote
Changing OpenSCAD to use a different language is a terrible idea, because you would break compatibility with all of the existing OpenSCAD code, and force the people who know how to use it to re-learn it. The python 2.x to python 3.x changed enough to make existing projects and libraries incompatible, and it's taken over 10 years to get people to use the new system. Trying to rip out the core of the language syntax and replace it would be even worse.
I strongly agree. I probably have in excess of a million lines of OpenSCAD code, and no one else will rewrite them for me...

Improve the existing language, instead of replacing it with something new. Bring in needed features, not a dump and rewrite.

Also, there is a benefit of having a language designed for the purpose, instead of some framework on top of a generic language with all the extra baggage which comes with that.

Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

RevarBat
With the exception of function literals, which are nice, and lazy unions, which seems not quite ready yet, I’ve seen little effort put into missing functionality. Things like:

- mutable variables
- better data structures (tables, structures, etc)
- multiple assignment (ie: `a,b,c = foo()`)
- threadability
- File IO
- geometry data access
- better library management. 

Hell, you can do tables and structures immutably if you absolutely must, and it’d still be a big win. 

But nobody seems to be doing these things, and my own code submissions have not been approved. 

Fine. Keep the original OpenSCAD language for backwards compatibility.  But grafting in a well developed language can solve so very many problems in one stroke. 

I’ve designed and implemented four domain specific languages in the last 30 years. It is almost never a better idea than using a well developed existing language. 

-Revar


On Mar 20, 2021, at 2:35 AM, Troberg <[hidden email]> wrote:


Whosawhatsis wrote
Changing OpenSCAD to use a different language is a terrible idea, because you would break compatibility with all of the existing OpenSCAD code, and force the people who know how to use it to re-learn it. The python 2.x to python 3.x changed enough to make existing projects and libraries incompatible, and it's taken over 10 years to get people to use the new system. Trying to rip out the core of the language syntax and replace it would be even worse.
I strongly agree. I probably have in excess of a million lines of OpenSCAD code, and no one else will rewrite them for me...

Improve the existing language, instead of replacing it with something new. Bring in needed features, not a dump and rewrite.

Also, there is a benefit of having a language designed for the purpose, instead of some framework on top of a generic language with all the extra baggage which comes with that.

Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

MichaelAtOz
Administrator
In reply to this post by RevarBat
Sorry, buy we have been here.
RevarBat wrote
Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?
Yes. here

After 7 pages on the forum it broke down to
> OpenSCAD:  You point the gun at your foot, and shoot twice.  Since you let the two bullet holes just barely touch, you get a CGAL error.

Having actually tried it and refreshed my memory on the behavior:

OpenSCAD:  You point the gun at your foot, and shoot twice.  Since you let the two bullet holes just barely touch, you get a warning that your foot may not be a valid 2-manifold and may need repair!
In there was
RevarBat 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
OpenSCAD IS the language. Without the language it is a bunch of open source libraries.

OpenSCAD is non-imperative. It is NOT "somewhat C-like".

It IS what it is, OpenSCAD, you obviously want NOT-OpenSCAD.

(Not speaking as the Forum-Admin) Please go and create your NOT-OpenSCAD, it doesn't look like those here who want to evolve OpenSCAD, want to drop it and radically transform it to Python, Lau, Java*, Ruby, Haskell, or whatever.

Sorry, but
RevarBat wrote
I honestly don’t care whether we go to
You seem to get frustrated once a quarter. Unless you go and lead a new project (and forum/mailing-list) start designing it and recruit a community, you have reliable (mostly) evolving non-imperative, really good...
it is something like a 3D-compiler that reads in a script file that describes the object and renders the 3D model from this script file
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 the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

doug.moen
In reply to this post by RevarBat
Revar said:
Okay, everyone remember when I proposed ripping the OpenSCAD language out of OpenSCAD and replacing it with Python?

Yeah, well Python isn’t easily embeddable, and has security implications.

Libfive Studio (which has an OpenSCAD-like GUI) has recently been changed to support Python, in addition to the previous language, Guile Scheme. So that is a new option for somebody looking for an OpenSCAD-like experience, except with Python. Libfive uses signed distance fields to model 3D solids, instead of triangle meshes, so you are using a somewhat different set of primitives. https://github.com/libfive/libfive

So I guess Python is embeddable. As for the security implications, yes this is a concern for libfive, although the author is considering mitigations.

For some reason, most project forks of OpenSCAD either drop the immediacy of the live GUI and editor, or they go developing their own domain specific language variant, or choose a really obscure language to expand on.

My project, Curv, is about developing a new geometric modelling language. Apart from the fact that it's a fun project, one reason for not using Python or Lua or whatever is performance. Curv compiles into either C++ or GPU shader code (GLSL) for performance reasons. I can already generate a million or so triangles in a few seconds using C++ as a JIT compiler, much faster than OpenSCAD for the kinds of models I care about. One goal for this year is to be able to generate triangle meshes using the GPU, which should be a hundred times faster than that. I plan to be able to do this either in a native application or inside a web browser. There aren't any existing languages with the kind of GPU code generation that I need. The other reason for a new language is that I want to use a simple declarative language when I'm designing a model (no boilerplate or bureaucracy, like OpenSCAD), and I want to use an imperative language with modern features when I'm implementing a performance critical graphics algorithm. Curv is kind of unique in supporting both styles of programming in a single language. So that's the reason. Curv isn't like OpenSCAD, it's not a wrapper around CGAL.

BTW I'm not soliciting new users on this list. Curv is still a research project, and can't yet do a lot of what OpenSCAD does.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

tp3
In reply to this post by MichaelAtOz
I wonder if all that energy going in circles could be
channeled into something that could lead to some actual
OpenSCAD improvement.

What about dictionaries, how could a *minimal* solution
look like?

Which features are at least required to cover some of
the use cases where currently awkward constructs are
needed and how could those look from language user
perspective?:

1) define a fixed set of key value pairs (should key be
   limited somehow, e.g. strings only?)

2) access value via key

3) allow iteration of key, values

Anyone interested in having this discussion in a new
forum thread? If I can find some more spare time, I
might try to get that started in a new post, but I'm
happy if someone else wants to share ideas first.

ciao,
  Torsten.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

adrianv
I'm not sure what specific problems dictionaries would solve.  There is this https://github.com/openscad/openscad/pull/3087 which is structs rather than dicts.  I have used dictionary type things occasionally in OpenSCAD, using the search() function to handle the lookup.  Not particularly efficient, but what is the application for dicts with huge lists of keys?   Structs would make for more readable code and easier to use functions, because multiple returns could be labeled instead of appearing as mysterious lists of objects.  But these don't seem like fundamental changes.  

It seems like if you want to think about what the problems are that limit implementation of real algorithms it probably comes down to the efficiency of making small changes to large objects.   If an algorithm requires maintaining a large data structure of some kind and inserting/deleting items in it, that means, in OpenSCAD, constantly copying a huge list to make each small change, which means performance will likely be poor.  So even if I can contrive a way to write my algorithm recursively, I'm likely to run into trouble with performance.  Basically to implement an algorithm efficiently it needs to be possible to conceptualize the algorithm as a list comprehension rather than a recursion, so that you can rewrite the data structure en-masse, so to speak, rather than rewriting it a piece at a time.  

tp3 wrote
I wonder if all that energy going in circles could be
channeled into something that could lead to some actual
OpenSCAD improvement.

What about dictionaries, how could a *minimal* solution
look like?

Which features are at least required to cover some of
the use cases where currently awkward constructs are
needed and how could those look from language user
perspective?:

1) define a fixed set of key value pairs (should key be
   limited somehow, e.g. strings only?)

2) access value via key

3) allow iteration of key, values

Anyone interested in having this discussion in a new
forum thread? If I can find some more spare time, I
might try to get that started in a new post, but I'm
happy if someone else wants to share ideas first.

ciao,
  Torsten.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]


Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

JordanBrown
In reply to this post by tp3
On 3/20/2021 1:41 PM, Torsten Paul wrote:
What about dictionaries, how could a *minimal* solution
look like?

I'm starting (just barely) to work on structure/dictionary/object support, based on your object work, primarily to support complex return values from functions like my text metrics functions.  I might make some progress this weekend.  The first round would allow only internally-generated values, but a subsequent round could introduce syntax for creating them from OpenSCAD expressions.


_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
tp3
Reply | Threaded
Open this post in threaded view
|

Re: Lua luau.

tp3
Most languages I'm aware of do provide both dictionaries
and objects/structs. The obvious difference is that the
dictionaries are much more limited but allow access via a
dynamically produced key where objects usually only allow
statically defined names for access (needing some kind of
runtime reflection to make it dynamic).

So while I would like to see the objects proposal move
ahead, that one might take a while at the current pace.

As multiple mentions of a dictionary type data structure
happened lately and there's a couple of implementations
around, I was wondering if that could be an easier way
of covering some common use cases.

But then, if the outcome of the discussion is just again
"we need lots of new stuff" but every specific answer to
any proposal is "no, not that one", that's fine too. It's
not like I personally have lots of spare time to fill.

ciao,
  Torsten.
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to [hidden email]
-- Torsten
12