I think you need another language to do those things. They are never going to be efficient in OpenSCAD, they would need to be added as C++ primitives. To do geometry with Python you just need bindings to Clipper, OpenCSG and GCAL or Carve, plus a few others. They you would be able to code whatever you wanted. That is another project. Fortunately I don't need advanced geometry to make my functional objects, so I don't regard it as a toy but I do think perhaps you have outgrown it. Its main advantage to me is that it is simple. If you extend it to something as powerful and complicated as Python, why not just use Python and some libraries? On the other hand if offset, etc, was added as a built in function I see no problem. On Sat, 28 Nov 2020 at 01:25, Revar Desmera <revarbat@gmail.com> wrote: > Thing is, I’m not just trying to update a variable in a loop. I can do > that awkwardly with C-style for(). > > I’m writing a library to do the hard things like make solids built from > Bezier patches, or calculate path offsets, or calculate Voronoi regions so > that I can do more complicated geometry. And I cannot feasibly implement > some of the needed efficient algorithms because the language cannot make > the data structures without being extremely inefficient. > > If OpenSCAD even had a mutable dictionary type, I could make most the > needed structures, but it doesn’t. And variables aren’t truly mutable. > > And saying that that is not what OpenSCAD is designed for, sounds to me > like saying “OpenSCAD is just a toy, and you shouldn’t try making it > better.” > > -Revar > > > > On Nov 27, 2020, at 4:48 PM, Ethan Dicks <ethan.dicks@gmail.com> wrote: > > > > On Fri, Nov 27, 2020 at 4:38 PM David <ainut@hiwaay.net> wrote: > >> Blender is HARD, with a tough, steep, and long learning curve. Wish I > was fluent with it. <sigh> > > > > I first fiddled with Blender in 2010. I wanted to edit a bracket for > > a Mendel printer to remove 3 holes from the STL. I spent 2.5 hours > > trying to figure out how to use Blender, how to navigate in Blender, > > or how to do any single damn thing in Blender. It was the most > > non-intuitive piece of software I had ever encountered (I later found > > out that using Blender from a laptop without a numeric keypad makes it > > _much_ harder to use). At the point I gave up, I went back to > > Thingiverse and grabbed the DXF file and the OpenSCAD script that made > > the STL in the first place, and in *seconds* figured out what the > > program was doing and commented out three lines that made the holes I > > wanted to not be there. F6 and export and I was *done*! I have been > > a happy user of OpenSCAD ever since. Blender still pisses me off (the > > last time I worked with it was to orchestrate some animation to, > > effectively, drive a pre-rendered car around a virtual racetrack - it > > did that fine, but it was animation, not object creation, in the > > Python I was hacking). > > > > With that, from what I'm reading in this thread, it sounds like a case > > of "OpenSCAD isn't a procedural language and I don't like that" that > > comes up pretty much every time someone wants to fiddle with variables > > inside loops. I've been programming (professionally) for decades. > > OpenSCAD is the only Functional Language that I've learned and, yes, > > it was a bit of an adjustment coming from C and Perl, etc., but it's > > not like OpenSCAD is the only Functional Language ever created. It's > > a different category and in the specific case of twiddling things > > inside and outside loops, it differs from a Procedural Language. > > > > I'm not in favor of $SUBJECT. I've been working in OpenSCAD for over > > 10 years at this point and I don't see Functional vs Procedural as > > something that needs to be "fixed". If someone wants to go make > > Python into an object creation platform, that sounds like a different > > project. > > > > -ethan > > > > _______________________________________________ > > OpenSCAD mailing list > > Discuss@lists.openscad.org > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

That is one of the reasons why I suggested javascript, it is easy to add new primitives to both the Squirrel Monkey and the V8 engine. and then embed the resulting language capability into a C++ based application, it was designed for that, that's how it ends up in browsers and has access to the HTML DOM. It's also why node js exists and is so popular. I use V8 a lot inside PHP applications, the V8 interpreter is embedded in PHP via a C++ based extension, it offers up hooks that allows values, constants, functions and objects to be injected into the language VM on startup. It should be "relatively" simple to inject the openSCAD backend objects and functions into the V8 instance, so it avoids the "library" approach, it has an "execution context" that serves as a "session" object to allow execution lifecycle data to be cached, i'm not sure how to add cache with longer lifecycle, i have never needed it before. We use JS as a scripting language inside other applications, to provide customizations to our apps' behaviour that are stored in the apps database, we find that the vast majority of developers can hack JS even if it is not their primary language, as it is ubiquitous in web development. we allow fragments to be executed at various points in the app, with the context passed as a javascript object with its invocation parameters, and the "return" object having the data that is needed by the customization. its possible to do any builtin actions like file io, but its also possible to restrict that to a sandbox like the current folder the script is executing in to prevent security issues. https://v8.dev/docs/embed On Sat, Nov 28, 2020 at 4:51 PM nop head <nop.head@gmail.com> wrote: > I think you need another language to do those things. They are never going > to be efficient in OpenSCAD, they would need to be added as C++ primitives. > > To do geometry with Python you just need bindings to Clipper, OpenCSG and > GCAL or Carve, plus a few others. They you would be able to code whatever > you wanted. That is another project. > > Fortunately I don't need advanced geometry to make my functional objects, > so I don't regard it as a toy but I do think perhaps you have outgrown it. > Its main advantage to me is that it is simple. If you extend it to > something as powerful and complicated as Python, why not just use Python > and some libraries? On the other hand if offset, etc, was added as a built > in function I see no problem. > > On Sat, 28 Nov 2020 at 01:25, Revar Desmera <revarbat@gmail.com> wrote: > >> Thing is, I’m not just trying to update a variable in a loop. I can do >> that awkwardly with C-style for(). >> >> I’m writing a library to do the hard things like make solids built from >> Bezier patches, or calculate path offsets, or calculate Voronoi regions so >> that I can do more complicated geometry. And I cannot feasibly implement >> some of the needed efficient algorithms because the language cannot make >> the data structures without being extremely inefficient. >> >> If OpenSCAD even had a mutable dictionary type, I could make most the >> needed structures, but it doesn’t. And variables aren’t truly mutable. >> >> And saying that that is not what OpenSCAD is designed for, sounds to me >> like saying “OpenSCAD is just a toy, and you shouldn’t try making it >> better.” >> >> -Revar >> >> >> > On Nov 27, 2020, at 4:48 PM, Ethan Dicks <ethan.dicks@gmail.com> wrote: >> > >> > On Fri, Nov 27, 2020 at 4:38 PM David <ainut@hiwaay.net> wrote: >> >> Blender is HARD, with a tough, steep, and long learning curve. Wish I >> was fluent with it. <sigh> >> > >> > I first fiddled with Blender in 2010. I wanted to edit a bracket for >> > a Mendel printer to remove 3 holes from the STL. I spent 2.5 hours >> > trying to figure out how to use Blender, how to navigate in Blender, >> > or how to do any single damn thing in Blender. It was the most >> > non-intuitive piece of software I had ever encountered (I later found >> > out that using Blender from a laptop without a numeric keypad makes it >> > _much_ harder to use). At the point I gave up, I went back to >> > Thingiverse and grabbed the DXF file and the OpenSCAD script that made >> > the STL in the first place, and in *seconds* figured out what the >> > program was doing and commented out three lines that made the holes I >> > wanted to not be there. F6 and export and I was *done*! I have been >> > a happy user of OpenSCAD ever since. Blender still pisses me off (the >> > last time I worked with it was to orchestrate some animation to, >> > effectively, drive a pre-rendered car around a virtual racetrack - it >> > did that fine, but it was animation, not object creation, in the >> > Python I was hacking). >> > >> > With that, from what I'm reading in this thread, it sounds like a case >> > of "OpenSCAD isn't a procedural language and I don't like that" that >> > comes up pretty much every time someone wants to fiddle with variables >> > inside loops. I've been programming (professionally) for decades. >> > OpenSCAD is the only Functional Language that I've learned and, yes, >> > it was a bit of an adjustment coming from C and Perl, etc., but it's >> > not like OpenSCAD is the only Functional Language ever created. It's >> > a different category and in the specific case of twiddling things >> > inside and outside loops, it differs from a Procedural Language. >> > >> > I'm not in favor of $SUBJECT. I've been working in OpenSCAD for over >> > 10 years at this point and I don't see Functional vs Procedural as >> > something that needs to be "fixed". If someone wants to go make >> > Python into an object creation platform, that sounds like a different >> > project. >> > >> > -ethan >> > >> > _______________________________________________ >> > OpenSCAD mailing list >> > Discuss@lists.openscad.org >> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

PS: i have always thought of OpenSCAD as "3d javascript" and that's how i describe it to people who have never seen it before so they understand the concept. On Sat, Nov 28, 2020 at 11:00 PM Tim Hawkins <tim.thawkins@gmail.com> wrote: > That is one of the reasons why I suggested javascript, it is easy to add > new primitives to both the Squirrel Monkey and the V8 engine. and > then embed the resulting language capability into a C++ based application, > it was designed for that, that's how it ends up in browsers and has access > to the HTML DOM. It's also why node js exists and is so popular. > > I use V8 a lot inside PHP applications, the V8 interpreter is embedded in > PHP via a C++ based extension, it offers up hooks that allows values, > constants, functions and objects to be injected into the language VM on > startup. It should be "relatively" simple to inject the openSCAD backend > objects and functions into the V8 instance, so it avoids the "library" > approach, it has an "execution context" that serves as a "session" object > to allow execution lifecycle data to be cached, i'm not sure how to add > cache with longer lifecycle, i have never needed it before. > > We use JS as a scripting language inside other applications, to provide > customizations to our apps' behaviour that are stored in the apps database, > we find that the vast majority of developers can hack JS even if it is not > their primary language, as it is ubiquitous in web development. we allow > fragments to be executed at various points in the app, with the context > passed as a javascript object with its invocation parameters, and the > "return" object having the data that is needed by the customization. its > possible to do any builtin actions like file io, but its also possible to > restrict that to a sandbox like the current folder the script is executing > in to prevent security issues. > > https://v8.dev/docs/embed > > On Sat, Nov 28, 2020 at 4:51 PM nop head <nop.head@gmail.com> wrote: > >> I think you need another language to do those things. They are never >> going to be efficient in OpenSCAD, they would need to be added as C++ >> primitives. >> >> To do geometry with Python you just need bindings to Clipper, OpenCSG and >> GCAL or Carve, plus a few others. They you would be able to code whatever >> you wanted. That is another project. >> >> Fortunately I don't need advanced geometry to make my functional objects, >> so I don't regard it as a toy but I do think perhaps you have outgrown it. >> Its main advantage to me is that it is simple. If you extend it to >> something as powerful and complicated as Python, why not just use Python >> and some libraries? On the other hand if offset, etc, was added as a built >> in function I see no problem. >> >> On Sat, 28 Nov 2020 at 01:25, Revar Desmera <revarbat@gmail.com> wrote: >> >>> Thing is, I’m not just trying to update a variable in a loop. I can do >>> that awkwardly with C-style for(). >>> >>> I’m writing a library to do the hard things like make solids built from >>> Bezier patches, or calculate path offsets, or calculate Voronoi regions so >>> that I can do more complicated geometry. And I cannot feasibly implement >>> some of the needed efficient algorithms because the language cannot make >>> the data structures without being extremely inefficient. >>> >>> If OpenSCAD even had a mutable dictionary type, I could make most the >>> needed structures, but it doesn’t. And variables aren’t truly mutable. >>> >>> And saying that that is not what OpenSCAD is designed for, sounds to me >>> like saying “OpenSCAD is just a toy, and you shouldn’t try making it >>> better.” >>> >>> -Revar >>> >>> >>> > On Nov 27, 2020, at 4:48 PM, Ethan Dicks <ethan.dicks@gmail.com> >>> wrote: >>> > >>> > On Fri, Nov 27, 2020 at 4:38 PM David <ainut@hiwaay.net> wrote: >>> >> Blender is HARD, with a tough, steep, and long learning curve. Wish >>> I was fluent with it. <sigh> >>> > >>> > I first fiddled with Blender in 2010. I wanted to edit a bracket for >>> > a Mendel printer to remove 3 holes from the STL. I spent 2.5 hours >>> > trying to figure out how to use Blender, how to navigate in Blender, >>> > or how to do any single damn thing in Blender. It was the most >>> > non-intuitive piece of software I had ever encountered (I later found >>> > out that using Blender from a laptop without a numeric keypad makes it >>> > _much_ harder to use). At the point I gave up, I went back to >>> > Thingiverse and grabbed the DXF file and the OpenSCAD script that made >>> > the STL in the first place, and in *seconds* figured out what the >>> > program was doing and commented out three lines that made the holes I >>> > wanted to not be there. F6 and export and I was *done*! I have been >>> > a happy user of OpenSCAD ever since. Blender still pisses me off (the >>> > last time I worked with it was to orchestrate some animation to, >>> > effectively, drive a pre-rendered car around a virtual racetrack - it >>> > did that fine, but it was animation, not object creation, in the >>> > Python I was hacking). >>> > >>> > With that, from what I'm reading in this thread, it sounds like a case >>> > of "OpenSCAD isn't a procedural language and I don't like that" that >>> > comes up pretty much every time someone wants to fiddle with variables >>> > inside loops. I've been programming (professionally) for decades. >>> > OpenSCAD is the only Functional Language that I've learned and, yes, >>> > it was a bit of an adjustment coming from C and Perl, etc., but it's >>> > not like OpenSCAD is the only Functional Language ever created. It's >>> > a different category and in the specific case of twiddling things >>> > inside and outside loops, it differs from a Procedural Language. >>> > >>> > I'm not in favor of $SUBJECT. I've been working in OpenSCAD for over >>> > 10 years at this point and I don't see Functional vs Procedural as >>> > something that needs to be "fixed". If someone wants to go make >>> > Python into an object creation platform, that sounds like a different >>> > project. >>> > >>> > -ethan >>> > >>> > _______________________________________________ >>> > OpenSCAD mailing list >>> > Discuss@lists.openscad.org >>> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >

Tim Hawkins <tim.thawkins@gmail.com> wrote: >PS: i have always thought of OpenSCAD as "3d javascript" >and that's how i describe it to people who have never seen >it before so they understand the concept.  Does OpenJSCAD not work for what you want? https://openjscad.org/ William

On 11/28/2020 12:50 AM, nop head wrote: > To do geometry with Python you just need bindings to Clipper, OpenCSG > and GCAL or Carve, plus a few others. They you would be able to code > whatever you wanted. That is another project. Yes, it's another project, but no, it's not all you need.  To fit in the same niche as OpenSCAD (but offer more) you also need an integrated environment and a Python environment that's tuned for simple representation of CSG.  The target is "cube(10);" as the minimal program.

I have a few "metrics" I use to judge how close a programming language is to my ideal language (which I think is an ideal which can not be reached, but one can get closer to it). These are (some of the) qualities of an ideal language for me: * Every single line should directly address the problem you are solving. No bureaucracy. * The code should reference objects in the domain of the problem you are trying to solve. So, the user didn't click on "item with index 23 in lit lstStreetnames", the user "selected Main street". * As close to natural human language as possible. For me, with a good parts library, OpenSCAD comes pretty close to these, much closer than a Python, Java or VBA solution would. -- Sent from: http://forum.openscad.org/

Troberg wrote > I have a few "metrics" I use to judge how close a programming language is > to > my ideal language (which I think is an ideal which can not be reached, but > one can get closer to it). These are (some of the) qualities of an ideal > language for me: > > * Every single line should directly address the problem you are solving. > No > bureaucracy. > > * The code should reference objects in the domain of the problem you are > trying to solve. So, the user didn't click on "item with index 23 in lit > lstStreetnames", the user "selected Main street". This is one of the biggest failures of OpenSCAD. Since there's no way to create structures with named fields and no way to return multiple values from a function one is forced to return multiple values as a list, which means you have a list where you have to refer to "the item at index 2" instead of "length". > * As close to natural human language as possible. This seems to be somewhat in conflict with your first item. Human language is redundant, with extra verbiage. It is not succinct and may not be precise. (I personally think human language is a terrible model for a computer language, with so much unnecessary complexity and variability.) I also think that OpenSCAD is pretty far from natural human language by any metric. What would that look like? "Put a cylinder from (3,4,5) to (9,10,12)" "Turn this cube 75 degrees to the right" "Move it up by 10" -- Sent from: http://forum.openscad.org/

'This is one of the biggest failures of OpenSCAD. Since there's no way to create structures with named fields and no way to return multiple values from a function one is forced to return multiple values as a list, which means you have a list where you have to refer to "the item at index 2" instead of "length".' I'd agree that some of the limitations can be a big pain. Could users get the same end results (varied data-structures, known language to use) if, instead of replacing the core OpenSCAD, either one made calls to it from inside another language (python, javascript, java, whatever), or had a code generator in those languages to generate the corresponding OpenSCAD? On Tue, Dec 1, 2020 at 1:58 PM adrianv <avm4@cornell.edu> wrote: > Troberg wrote > > I have a few "metrics" I use to judge how close a programming language is > > to > > my ideal language (which I think is an ideal which can not be reached, > but > > one can get closer to it). These are (some of the) qualities of an ideal > > language for me: > > > > * Every single line should directly address the problem you are solving. > > No > > bureaucracy. > > > > * The code should reference objects in the domain of the problem you are > > trying to solve. So, the user didn't click on "item with index 23 in lit > > lstStreetnames", the user "selected Main street". > > This is one of the biggest failures of OpenSCAD. Since there's no way to > create structures with named fields and no way to return multiple values > from a function one is forced to return multiple values as a list, which > means you have a list where you have to refer to "the item at index 2" > instead of "length". > > > > * As close to natural human language as possible. > > This seems to be somewhat in conflict with your first item. Human language > is redundant, with extra verbiage. It is not succinct and may not be > precise. (I personally think human language is a terrible model for a > computer language, with so much unnecessary complexity and variability.) > I > also think that OpenSCAD is pretty far from natural human language by any > metric. What would that look like? "Put a cylinder from (3,4,5) to > (9,10,12)" "Turn this cube 75 degrees to the right" "Move it up by 10" > > > > > > > -- > Sent from: http://forum.openscad.org/ > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

On 1 Dec 2020 at 11:57, adrianv wrote: > > * As close to natural human language as possible. > > This seems to be somewhat in conflict with your first item. Human language > is redundant, with extra verbiage. It is not succinct and may not be > precise. (I personally think human language is a terrible model for a > computer language, with so much unnecessary complexity and variability.) I > also think that OpenSCAD is pretty far from natural human language by any > metric. What would that look like? "Put a cylinder from (3,4,5) to > (9,10,12)" "Turn this cube 75 degrees to the right" "Move it up by 10" Perhaps he's advocating the use of COBOL. :-)

> Since there's no way to create structures with named fields > and no way to return multiple values from a function one is > forced to return multiple values as a list, which means you > have a list where you have to refer to "the item at index 2" > instead of "length".' The infrastructure for that already exists by now which I have shown in an example that imports a JSON file as data structure with named fields. ciao, Torsten.