<JordanBrown[m]>
Caution: while there are no known ways to make a malicious OpenSCAD program, there is absolutely no protection against malicious Python programs - and there's some consensus that protecting against malicious Python programs is impossible.
<dTal>
if there were they could call it "mongoose"
<JakeSays>
JordanBrown[m]: ugh. why?
<JordanBrown[m]>
Why what?
<JakeSays>
why add python support
<dTal>
because OpenSCAD language is limited
<JordanBrown[m]>
Because somebody wanted to.
<InPhase>
JakeSays: Because with appropriate safeguards in place, having Python as an option provides capabilities that will not be integrated into the OpenSCAD language.
<JakeSays>
why not invest in the openscad language rather than add a giant python wart on the side of openscad?
<peepsalot>
they are not mutually exclusive
<InPhase>
JakeSays: First there is an extensive set of numerical libraries. Second there is interfacing with native code. Third there is the possibility of complicated file I/O. So all those things that we don't want to put into scad, as a model description language, could be useful in more carefully guarded components.
<JakeSays>
there are so many things i'd rather see in openscad than the addition of python
<InPhase>
JakeSays: Agreed. But the addition of Python as an option was actually not particularly complicated compared to most of those things.
<JakeSays>
i hate python. hate it with a passion.
<InPhase>
And, someone has already done this as a proof of concept, so that work is completed. So the evaluation is does it provide benefits and can it be made appropriately safe?
<InPhase>
Also can it be kept appropriately maintainable.
<JordanBrown[m]>
And the two reasons that first come to my mind are two more:
<JordanBrown[m]>
1) Because "investing" in creating a full general-purpose language is also called "reinventing the wheel". We should be spending our very limited resources on stuff related to geometry, not stuff related to programming.
<JordanBrown[m]>
2) Because the OpenSCAD language, without overhauls that would make it a different language, requires a very different style of programming than most people are familiar with, causing a great deal of trouble for newcomers.
<InPhase>
But it seems all three of those are possible (but not yet complete).
<JakeSays>
i'm forced to used that pile of shit when working with ai, and now it's creeping in to oscad.
<peepsalot>
JakeSays: so far the python branch is the sole work of one developer who is new to contributing to openscad. so it is assuredly not taking development time away from further development of OpenSCAD as a language
<JordanBrown[m]>
For better or worse, so far I suspect that the "protect against malicious programs" aspect will be insurmountable.
<InPhase>
JakeSays: Well, there will be no requirement to use Python. I will prefer .scad for making models, because it is a more safe-sharing language. Although there is potential for some small Python libraries that can be used within other scad files as components, that might let us add in interesting features as libraries that we could not otherwise build. This offers some opportunity to prototype more
<InPhase>
things and consider them for integration.
<JakeSays>
InPhase: of course there will be. it'll start making its way in to models, etc.
<JakeSays>
and libraries
<InPhase>
JordanBrown[m]: "Protect" is insurmountable, but "make sure doing the unsafe thing is intentional" is doable.
<InPhase>
JordanBrown[m]: Much like, "Are you sure you want to run this random thing you downloaded from the Internet?"
<JakeSays>
there's already a python tool for this, with much better rendering than oscad.
<JordanBrown[m]>
Maybe. Depends on where you draw the line of what the "usafe thing" is. It's clear that you can draw that line at "do you want to run a Python component", but not clear whether you can do it at any finer grain than that.
<JordanBrown[m]>
JakeSays which tool are you thinking of?
<InPhase>
JakeSays: Although in general "I hate Python" is not really a factor in whether or not we integrate it. Python is obviously quite popular, and someone dislikes any language. :)
<JakeSays>
JordanBrown[m]: i don't remember the name because it uses python:P i just remember it rendered beautifully, i think because it uses open cascade
<InPhase>
JakeSays: But in general, it's a popular language for the space of numerical computation, and also a popularly desired language for modeling purposes.
<InPhase>
JakeSays: Essentially, its features fit well with the problem domain, so it is the ideal choice if we're going to do any sort of carefully guarded general-purpose language option.
<JordanBrown[m]>
InPhase: if we could switch on and off network operations, file read, and file write, and probably some more obscure things, that'd be fine - but it isn't at all clear that we can do that, especially not for a support cost that we'd be willing to accept.
<JakeSays>
InPhase: if you want a secure general purpose language then use c++ for scripting with cling. it's very easy to andbox
<InPhase>
JakeSays: My thinking of the right way to guard it is that every single Python file should require active approval (or an "approve all remaining python files for this run"). The act of active approval will disincentivize it except when it's helpful, I think. But that's appropriate.
<InPhase>
JakeSays: Well, I actually think it's most helpful NOT sandboxed.
<InPhase>
I'm not sold on the benefits of just-another-language-option.
<InPhase>
If we wanted a new language, we could start work on scad version 2.
<JakeSays>
i've been advocating for a while now that oscad add advanced opt-in features to the language. warting it with python isn't what i had in mind.
<teepee>
InPhase: what if that python branch brings a path-extrude implementation along?
<InPhase>
But we're not ready for a scad version 2.
<teepee>
... usable via openscad script too
<InPhase>
teepee: I can write that in scad already. :)
<teepee>
sure, but it's either special case, or slow :P
<InPhase>
teepee: Except for a few problems that don't have simple solutions.
<JordanBrown[m]>
If we have a viable algorithm for some geometry feature in any language, we could translate it over into C++ for use from the OpenSCAD language.
<JordanBrown[m]>
As for an OpenSCAD 2, well, maybe, but I would push pretty hard for basing it on some established language, so that we're focusing on geometry, not language.
<InPhase>
teepee: If we had solutions to those, we could integrate them. But this is, potentially, one of the benefits to it as a feature prototyping language. Probably the primary reason Python could help over .scad for this is precisely its ability to call external libraries. Which means not sandboxed.
<JordanBrown[m]>
Inventing language features is kind of fun, but is mostly a waste of time.
<teepee>
yes, plus maybe getting some more developers that may also help with the core parts shared by good old scripting language
<JordanBrown[m]>
And time spent explaining a unique language is also time wasted.
<teepee>
hence I'm voting for geometry engine features :)
<JakeSays>
JordanBrown[m]: that depends on the goal. if you want to improve on the capabilities of the language, then it's not a waste of time
<JordanBrown[m]>
It's a waste of time because there are other languages that already have those features.
<JakeSays>
JordanBrown[m]: there are other languages and systems that do what oscad does, which by your logic makes the entire project a waste of time.
<JordanBrown[m]>
Pretty much anything we might do to the OpenSCAD language is reinventing stuff that was already done (and probably better) long ago in Python, JavaScript, et cetera.
<JordanBrown[m]>
Show me. I've looked, and I haven't found them.
<InPhase>
To "makes the entire project a waste of time". Funny only if you have seen the movie I suppose. :)
<JordanBrown[m]>
Come and see the violence inherent in the system!
<JordanBrown[m]>
Besides, WRT Camelot, it's only a model.
<JordanBrown[m]>
But AFAIK not a model developed in OpenSCAD.
<JakeSays>
i think you guys don't realize where the value in oscad lies. it's in the language, not the geometry. JordanBrown[m] your comment about basing oscad 2 on an existing language would eliminate it's value proposition.
<JordanBrown[m]>
What do you postulate its value proposition to be?
<JordanBrown[m]>
Because I see approximately one thing that the OpenSCAD language has that's uniquely valuable.
<JakeSays>
being able to describe extremely detailed designs using a simple, elegant, language that fits the problem space well.
<JordanBrown[m]>
That's an awfully abstract statement. Why is it more elegant than Python or JavaScript?
<JordanBrown[m]>
The one feature that OpenSCAD has is that statements yield geometry that contributes to the model, that you don't have to say "output(...)" to get a geometry object added to the model.
<JordanBrown[m]>
That's the *only* language feature that I can think of that is uniquely valuable. Everything else is entirely replaceable by commonly available features in other languages, or by libraries.
<JordanBrown[m]>
OpenSCAD is the only programming environment that I know of - and I've looked - where you can generate an STL of a cube in 10 keystrokes. But a PythonSCAD, a Python embedded in the OpenSCAD UI, could do it in less than 20, and that might be OK.
<JakeSays>
honestly i'm too fucking tired to articulate the benefits. i don't have the energy.
<JordanBrown[m]>
OK
<InPhase>
JakeSays: I concur this is the benefit. This is why I don't expect the inclusion of a Python module option to disrupt the core functionality of OpenSCAD.
<InPhase>
JakeSays: I do not in any way view this as a radical change to OpenSCAD nor its project direction.
<JordanBrown[m]>
Agreed... I would think of it as a fork or maybe an option.
<JakeSays>
a fork?
<JordanBrown[m]>
It *is* a fork/option that might eventually outlast the original.
<InPhase>
There are plenty of Python approaches existing for 3D modeling, and there are reasons they have not caught on to the same degree. Most of that has to do with the code sharing issues, I think.
<JordanBrown[m]>
A fork in that there might be two separate programs that derive from the same origin and share substantial components.
<InPhase>
I view the value of putting a Python option INTO OpenSCAD over having a separate one being primarily that it can be more limited in scope, and restricted down to helpful components, prototyping, or less-shared "I have a personal code problem to solve" solutions.
<JordanBrown[m]>
InPhase I haven't seen any that have the same EOU.
<JordanBrown[m]>
Python 3D modeling options, that is.
<InPhase>
EOU?
<JordanBrown[m]>
Ease of Use. Blender lets you use Python. I looked for a long time, and I don't think I ever figured out how to create a cube.
<JakeSays>
JordanBrown[m]: your attitude is bad for the project.
<JordanBrown[m]>
What is "the project"? What is the goal?
<JordanBrown[m]>
Is the goal to push some particular design, or to come up with the best possible programmatic 3D modeling environment?
<JakeSays>
sounds like the goal is to create a fork to replace the language
<JordanBrown[m]>
If I was confident that Python *could* replace the language, yes, absolutely. But I'm not.
<InPhase>
JakeSays: No discussions about Python here have been in that direction.
<InPhase>
JakeSays: If that were a likely outcome the dozens of others who have tried it probably would have already succeeded.
<JordanBrown[m]>
Oh, I wouldn't actively move to kill the existing language. But if Python (or JavaScript or Lua) could be adequately safe, and could address the "no boilerplate required to create a minimal model" problem, I think it would eventually take over.
<JordanBrown[m]>
What I want is an environment where a programmer - whether a first-timer or highly experienced - can easily write programs to create 3D models. At the minimum, that's "I want a cube", and at the maximum it's all of the language features ever created.
<JordanBrown[m]>
That's the goal.
snaked has quit [Quit: Leaving]
<JakeSays>
JordanBrown[m]: is that your goal or the goal of the project?
<teepee>
the goal is actually to *NOT* create a fork
<juri_>
hey, a fork of openscad; something i know a lot about! </serious>
<teepee>
pff, that is not a fork :P
<juri_>
yeah. :)
<JakeSays>
juri_: hey how's the slicer coming along?
<juri_>
there was a saying at one of my old workplaces: tightly integrated, but loosely coupled. that's the general style of 3d printing tools. we each end up with our selection of tools, and having to assemble them ourselves into a workflow that works for us.
<juri_>
JakeSays: about like extracting my brain, cubeing it, and soaking it in hot sauce... but i am making progress, so.. *shrugs*
teepee_ has joined #openscad
guso78 has joined #openscad
<JakeSays>
juri_: i've been thinking a lot about building a non-planar printer, and your slicer keeps coming to mind
<juri_>
at this point, i think i need a math student to explain what i've been doing to, so they can write a paper, and maybe help me make some progress.
<juri_>
has anyone here integrated a free software 3d scanning system into their workflow?
<juri_>
I have a manufacturing problem that requires me to build a scanner, and i'd like to avoid having to write a scanner in haskell, as well. the slicer is hard enough!
<teepee>
I have one of those line laser thingies, but it never really worked well
<teepee>
at some point I might give it another try with a raspi as controller, but that might take a couple of years for collecting motivation
<juri_>
i've got to determine the precise dimensions (read: manufacturing error) on a large piece of acrylic. so, all of the difficulty points, because transparent.
<JordanBrown[m]>
JakeSays: that (easy and powerful environment for programmatic 3d modeling) is my goal. Whether it is “the project’s” goal, shrug. What is the goal of an open source project, other than the amalgam of the goals of the users and developers?
<JordanBrown[m]>
teepee: I wouldn’t push for it being a fork, but that’s one of the possible results.
<juri_>
JordanBrown[m]: trying to make something easy for everyone is a hard goal to accomplish. various people work very differently. you're best off doing what each of us do: make minimal changes so that the things you do are easy for you.
<JakeSays>
juri_: ah that sounds like a fun project!
<JordanBrown[m]>
juri_: I have used the free version of Skanect, but it looks like that may have died.
<juri_>
I'm here, because the openscad people tolerate me, but the openscad interface gives me hives. i'm an anti-graphical user, and the software i write shows it.
milza has joined #openscad
<juri_>
JakeSays: i'm trying to make mostly-functional spacesuit-style covid "masks".
<juri_>
i bought one, but its horrible.. so now i'm engineering one instead.
<JakeSays>
very cool
<JordanBrown[m]>
juri_: yes, absolutely it’s hard. Right now OpenSCAD seems to be the overall winner, but there are other options that are tantalizingly close, that are far better by many metrics but failing in critical ways.
<juri_>
JordanBrown[m]: make them work better together, then. trying to go all 'one ring to rule them all' doesn't really work. you can't tell whats easy or hard for other users.
ur5us has joined #openscad
<juri_>
an addendum: its also hard to define features well. i mean, my scad derivitive recently gained cones, torroids, and elliosoids, but i don't really understand why they're valuable. that's only something people who think in those terms can tell me. all i can do as the language architect is ensure its not breaking other stuff, and represents an exposure of higher level math, not just being a macro. some
<juri_>
limits are considered to be features, as well.
<InPhase>
juri_: ImplicitCAD is more of a spork of OpenSCAD. :)
<InPhase>
JakeSays: On my personal views of the project, I think OpenSCAD is here to stay for a while, and pretty dominant in its solution space. Long term, 10, 20, 30 years down the line, I don't know what the solution space looks like, and I'm not actually very worried about the question of whether or not OpenSCAD is part of it. The most important lasting things we're doing with OpenSCAD involve setting in
<InPhase>
place ideas, and culture, and methods of making 3D models, while exploring opportunities and issues that future start-over designs could take advantage of. That's the nature of software evolution over the very long term, and I'm okay with that. The ideas we put in place here are very likely to outlast the project's dominant usage I think.
use-value has quit [Remote host closed the connection]
<InPhase>
Principles like safe shareable code are important to that.
use-value has joined #openscad
<InPhase>
I predict any solution that does not have that feature cannot overtake OpenSCAD in its solution space.
<juri_>
InPhase: what does that make HSlice? ;P
<JordanBrown[m]>
juri_: Python seems to be doing a good job of covering a large swath of the spectrum. It doesn’t quite go down far enough into the “easy” end, and it’s missing the safety that I agree with InPhase is critical.
<juri_>
i like haskell much more. even after a decade of writing it, every day. doesn't get old. :)
<JordanBrown[m]>
I don’t know enough about Haskell to have an opinion on it technically. It doesn’t seem to be winning the popularity contest, and that’s an important consideration.
<InPhase>
JordanBrown[m]: Well hopefully you could keep Haskell based models from having side-effects...
<InPhase>
But I concur it's very unlikely to be perceived as an easy approach to modeling.
<InPhase>
The functional bits of OpenSCAD are among the most commonly complained about parts, and they don't even manifest too strongly in the language.
<JordanBrown[m]>
Right.
<juri_>
they manifest more in my version.. ;)
<InPhase>
I prefer to describe OpenSCAD as declarative more than functional, as this is the more dominant aspect. First class functions are "new", and first class modules are still a design.
<JordanBrown[m]>
But “why doesn’t x=x+1 work” might well be the number one question.
califax has quit [Remote host closed the connection]
califax has joined #openscad
<InPhase>
Hmm. I suppose the ability to embed .py files adds significantly to the list of elements that are not declarative, which previously was basically just rands.
<InPhase>
Or, not consistently declarative at least.
<InPhase>
But since we had rands already, this is not a major change.
<InPhase>
Sufficiently patient calls to rands would eventually output the product of any python component. :)
epony has quit [Quit: QUIT]
aiyion2 is now known as aiyion
epony has joined #openscad
<juri_>
good luck breaking out of the haskell jail i run things in. that's part of limits begin features. ;)
<InPhase>
Haskell jail, where monads are contraband.
<juri_>
as long as i have typeclasses, i'll be fine. me, my typeclasses, and.. uh... ;)
snaked has quit [Quit: Leaving]
<juri_>
ok, maybe just a few monads.
foul_owl has quit [Ping timeout: 246 seconds]
foul_owl has joined #openscad
hypera1r has quit [Read error: Connection reset by peer]