Nabble has removed Mailing-list integration.
Posts created here DO NOT GET SENT TO THE MAILING LIST.
Mailing-list emails DO NOT GET POSTED TO THE FORUM.
So basically the Forum is now out of date, we are looking into migrating the history.
For now you should send emails, people will see them, discuss@lists.openscad.org.
Lua luau.
Locked
12
12
 
|
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:
_______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
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:
_______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
On 3/19/2021 2:58 PM, Whosawhatsis
wrote:
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] |
|
|
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:
_______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
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
_______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
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. _______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
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:
Damien Towning _______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
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:
Damien Towning _______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
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:
_______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
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] |
|
|
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] |
|
|
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] |
|
|
In reply to this post by Whosawhatsis
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] |
|
|
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:
_______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
Administrator
|
In reply to this post by RevarBat
Sorry, buy we have been here.
Yes. here After 7 pages on the forum it broke down to In there was 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 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. |
|
|
In reply to this post by RevarBat
Revar said:
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.
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] |
|
|
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
|
|
|
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.
Sent from the OpenSCAD mailing list archive at Nabble.com. _______________________________________________ OpenSCAD mailing list To unsubscribe send an email to [hidden email] |
|
|
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] |
|
|
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
|
«
Return to OpenSCAD
|
1 view|%1 views
| Free forum by Nabble | Edit this page |