<InPhase>
kintel: (I know you're gone, but you seem to do a good job of reading the log. ;) ) Yep, agreed on both counts. A lot of those "design flaws" you can really only discover and understand under heavy usage and under a growth of complexity beyond the original plan. It would be nearly impossible to get them all right on the first pass. I don't think we're actually quite ready for a version 2 of the
<InPhase>
language, but laying the infrastructure for it now, and exploring these other first class entity projects, might help us figure out what it should look like.
<InPhase>
I'm confident Python-based is not it, but the python features can have some specific utility with trusted code.
ur5us has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
snaked has joined #openscad
kintel has joined #openscad
<kintel>
InPhase Yeah, this is why I'm interested in getting the interfaces right. Then writing front-ends is much easier, whether it's a language binding or a UI. Especially interesting in the world of wasm.
guerd87 has quit [Ping timeout: 256 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest42 has joined #openscad
Guest42 has quit [Client Quit]
guerd87 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
J2325 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
<peepsalot>
i'm starting to think about splitting out headers for each of Value's held variant types, to make things more manageable
<peepsalot>
I wonder if this would exclude any optimizations though (without LTO)
epony has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<InPhase>
peepsalot: The only thing that would affect optimization would be taking things out of the translation units.
<InPhase>
peepsalot: Keeping it header though means you'd end up including it any time it's used, so it's all the same.
<peepsalot>
InPhase: hmm, well there's a fair bit of Value.cc too, you think that should not be split out along with the headers?
kintel has joined #openscad
<peepsalot>
i'm not sure if it can all be made header-only easily
<InPhase>
It probably shouldn't be, as most of that stuff in value.cc is too large to be worth packing into the header.
<JordanBrown[m]>
I would consciously move as much as possible *out* of the headers and into the C files, so that changing implementation details doesn't require rebuilding the whole universe.
<kintel>
It's worth trying to split things out though; Value kind of grew in-place way past its original implementation
<kintel>
If anything, I say strive to reduce coupling over any other optimization. Strong coupling in OpenSCAD original codebase took a lot of time to iron out
<InPhase>
peepsalot: A few things there could be considered for migrating to the header. operator<< (several of them), clone, undef, typeName, toBool, toDouble, getDouble, getFiniteDouble, toUndef, toUndefString, ... Basically, you'd only even consider it on the things that you could imagine maybe compiling down to a small bucket of assembly lines.
<InPhase>
peepsalot: I can't guarantee all the ones I listed are actually worth doing, as several call boost functions and I don't know how clunky those are.
<InPhase>
peepsalot: Or if you really want to know, you could profile with some tool that will report for you how much time is spent in any particular Value:: function, and see if any matter for real. :)
<InPhase>
Odds are good most do not matter at all. Possibly moving one or two might get you one of those 3% performance boosts or something.
<InPhase>
If it takes a while AND it's big, moving it will do nothing. The optimizer will just ignore your inline suggestion.
EkpyroticFrood has quit [Quit: So long, and thanks for all the fish.]
<InPhase>
peepsalot: Some would probably make a difference except no sane scad code would ever need it. FunctionType::operator== is an example. I write some crazy stuff, but I have trouble picturing a scad file I could write where inlining that would improve performance. :)
<InPhase>
peepsalot: But maybe that's an example where breaking it up a bit would make inlining it anyway less crazy seeming.
EkpyroticFrood has joined #openscad
LordOfBikes has quit [Ping timeout: 256 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
LordOfBikes has joined #openscad
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
ur5us has quit [Ping timeout: 260 seconds]
Teslamax has quit [Read error: Connection reset by peer]
<InPhase>
The feedback cycles are slow, but I've added python:p to the list. If that doesn't do it than I'm at a loss. ensurepip, which it is giving a missing dll exit code for, is sitting right there in the msys python package file list.
<teepee>
I think there's some way of connecting to the runner, can't find the button for this right now though
<teepee>
oh, right, that was via tmate session
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<peepsalot>
is there any kind of pattern or something to allow separating mutually recursive types? VectorType, EmbeddedVectorType, and ObjectType hold Values, which holds a variant including those types.
<peepsalot>
not sure how to avoid incomplete type errors
teepee has quit [Ping timeout: 255 seconds]
<peepsalot>
I was able to split out UndefType.h, FunctionType.h, RangeType.h, and str_utf8_wrapper.h at least
<peepsalot>
those remaining "recursive" class definitions are currently nested inside class Value { ... }
<peepsalot>
would it help to try making these recursive ones into template classes?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
teepee has joined #openscad
<peepsalot>
InPhase: when you said "It probably shouldn't be" did you mean the .cc file split out into multiple other sources, or shouldn't be attempted as header-only (or both)
<peepsalot>
*Value.cc
<InPhase>
I meant probably shouldn't be header only.
<InPhase>
And, goodnight.
<peepsalot>
goodnight
guso78 has joined #openscad
TheAssassin has quit [Quit: No Ping reply in 180 seconds.]
TheAssassin has joined #openscad
<guso78>
did i get correctly that the branched openscad works in windows, just none of the tests passed ?
<teepee>
I understood that JordanBrown[m] could compile and get it to run via msys2 but there were some strange PATH dances needed
<guso78>
Hi TeePee, Thank you for the info. If we cannot resolve the PATH dances, there is always the option to extend the installer. Big question for me is: did it run and did it properly start up outside MSYS2 environment ?
<guso78>
From the log i learned that some people believe, that python is not the right choice, but that does not stop me from pushing it further. Personally I like openscad very much and my big dream is to use it in both of my computers to develop models in (bit more flexible) way.
ur5us has joined #openscad
<teepee>
I don't think there such a thing as a right or wrong choice in that regard
<teepee>
there's use cases where Python is probably a bad choice and that's for example running it on a server as backend process
<teepee>
but other way around there's likely a number of things that are just not possible with the current description only language
<teepee>
and that's independent from the not so useful syntax discussion
<teepee>
I don't like the whitespace is important part of python, but that's not a topic that ranks anywhere else than the very bottom when selecting a language
<guso78>
teepee, i am happy to change python to any other language provided you can still save objects in variables. python was just the only liked and viable choice(did consider, perl, tkl and awk, too' ). I dont like the whitespace of python either, but it makes code more readable at least, its not an k.o. criteria for me , though ...
<guso78>
and i wondering: which things do you like to be still possible with openscad which are not possible with a "descriptive language " ?
<teepee>
reading files, saving files, any system access basically
<guso78>
ahh got it. you prefer things should "NOT" be possible. i got your statement wrong way around
<guso78>
you state " are just not possible with the current description only language " ?? i am little confused now.
<teepee>
I think there's a good justification for the option to have a (pretty) safe option
<teepee>
people have run openscad on servers allowing users to specifiy some or all input
<teepee>
allowing people to feed any input into a python interpreter needs a bit more consideration
<guso78>
Yes, the keyword is "option" . I would personally be sad to see that openscad language is REPLACED by something else. i still like the optional feature so much
<teepee>
yes, exactly
<guso78>
There are so many choices to disable Python for safe: Dont compile it in, disable it permanently with a command line option. enable/disable it somewhere where the used does not have access
<guso78>
where the "user" does not have access
<teepee>
that's why I'm very much for the integration of your solution, especially because it works with essentially no boilerplate python code
<teepee>
it's not far of from the openscad hello world: cube();
<guso78>
haha thank you t.
<guso78>
And i am still considering to get rid of final output() .. still considering the best solution.
ur5us has quit [Ping timeout: 252 seconds]
<guso78>
There are languages, which return implicitely the return result of the last statement. I believem that LISP is such a one.
<guso78>
with latest features, python-scad code can even become shorter when writing "*" ( multiplication) instead of long insersection keyword.
<guso78>
if used does not specify output(), python-scad could display the return result of the latest operation. "hello world" would be even shorter: cube() ... without semicolon, but the python integration would have to mainain a "last result" variable, not sure if this is a clean solution.
<guso78>
watching current openscad mailing list discussion, I believe when specifying a python callback function as an argument to linear_extrude and rotate_extrude instead of a 2d shape could very easily extrude irregular shapes given that the number of proved points stays constant
<guso78>
(and it could even work if not using a point-matching algorithm)
TheCoffeMaker has quit [Ping timeout: 260 seconds]
TheCoffeMaker has joined #openscad
TheCoffeMaker has quit [Ping timeout: 260 seconds]
epony has quit [Read error: Connection reset by peer]
<guso78>
teepee, there is a user 'tepee' in cults3d, but suppose its not you ...
<teepee>
probably not, at least I don't remember :)
J2325 has quit [Quit: Ping timeout (120 seconds)]
J2325 has joined #openscad
<InPhase>
guso78: Python is specifically the optimal choice, because it is the most popular open source language with strong support for matrix operations, which are a significant part of more intense computational parts of 3D modeling. Also it comes with adequate support for every file type. And third, if you do a survey of wrappers that have been written for scad, nearly all of them are in Python, which
<InPhase>
indicates an existing community demand. We just need to security guard it very well as I described earlier.
<InPhase>
guso78: You will find people coming out of the woodwork to dislike any specific language. There's always someone. :)
<guso78>
My current approach appears more promising
<guso78>
4 years back my plan was to replicate everything in python, even the 3d viewer. its was impossible to catch up on a running target ...
<InPhase>
The reality is you can teach basic OpenSCAD to people super easily, even at K12 levels. It doesn't really have advantages over Python for this, and it takes very little time to get people going with it. I taught non-programmer mostly business or accounting majors OpenSCAD and it took only about 2 hours of guided hands-on work for them to start designing their own custom rocket models, with basically
<InPhase>
everyone succeeding who kept coming to class, across multiple years of running that.
<InPhase>
So I don't think that's really a reason to prefer a Python based approach. Although if someone reaaally wants it to be Python for this, then sure, go ahead. But I think the real utility of Python has more to do with its advanced capabilities for math, and those security-breaching system integration capabilities like importing files and exporting reports.
<InPhase>
As long as people are assertively approving of those integration capabilities, this opens up the satisfaction of a large number of features that people have been asking for.
<InPhase>
I'm thinking of things like all those requests for exporting formatted parts lists, and things like that. The scad language is not even close to built for that, but Python is a perfect fit.
<InPhase>
If we can merge in Python includes with the new object literal features, I think there is going to be a lot of flexibility there.
<InPhase>
Oh, and I just had a thought. I had previously thought of active approvals as being something tied to paths. But even better would be tying it to hash sums of approved python files. That will guard people better, because it will prompt for reapproval if a python file has changed. Like say you are building a git repository of a scad library, you pull, you review a python file, later you pull again
<InPhase>
and a python file changed... it should prompt you again to approve for that run.
hrberg has quit [Ping timeout: 260 seconds]
<JordanBrown[m]>
I think that there are two big reasons to prefer a conventional language. First, they’re mature. They have the object and OO semantics that we are currently only stumbling toward; we wouldn’t be spending time inventing language features. Second, they allow for programming idioms that people are used to - how many times have people asked why they can’t say x=x+1 or a[i]=y? File I/O has real value but is also scary; I would be OK
<JordanBrown[m]>
with avoiding it.
<JordanBrown[m]>
In terms of restricting file I/O, I would think in terms of separate restrictions for read and write, and of whitelisting subtrees. Perhaps, for instance, you can read anything in any directory on $PYTHONPATH plus the directory the source file is in and its descendants. Maybe you can’t read anything outside that, or maybe reading it requires per-run per-file confirmation, or maybe you can globally whitelist directories. Having
<JordanBrown[m]>
per-program whitelists seems like an incredible pain in the neck. The biggest problem is a program that is “canned” but consumes user data, because you would want the program and data to be in different directories.
<JordanBrown[m]>
Write is harder still because almost by definition the data is not “part” of the program, and so you would want it separated. Perhaps it would be OK to have per-run per-file “save file” dialogs.
guso78 has quit [Ping timeout: 260 seconds]
<JordanBrown[m]>
Perhaps the customizer ties into the picture; the user could tell the customizer what files to read and write, and the customizer could save those choices, without the CAD program per se having any control other than perhaps supplying default names,
<JordanBrown[m]>
.
<InPhase>
JordanBrown[m]: The approval process I envision is "X is a python script and thus can potentially modify files or compromise your system [wording to be designed]. [Approve just this once.] [Save approval for future runs.] [Save approval for all files in this run.]
<InPhase>
"
<InPhase>
Something conceptually like that, so that you're not clicking approve on 50 files.
<InPhase>
But that it's explicit. And then save the hashes for everything that is instructed, so that previewing again does not request anything further.
<JordanBrown[m]>
I would prefer not to give it blanket access to the system, which is why I was thinking of approving subtrees.
<InPhase>
Maybe that first can be "Approve this session" or something.
<InPhase>
JordanBrown[m]: I don't think we want to get into the mess of trying to design a cross-platform sandbox.
<JordanBrown[m]>
Do you mean at a UI level, or at an implementation level?
<InPhase>
In terms of implementing an effective and reliable sandbox for Python without holes. This would be a nightmare. Projects that focus on this put a lot of effort into the struggle.
<InPhase>
You can't really lock Python down without kernel level support like apparmor or something.
<JordanBrown[m]>
I keep hoping that adopting an adequately restrictive model would be enough.
<InPhase>
And if we can't lock it down perfectly, we should not pretend we're doing so.
<InPhase>
That just means we're a deliverer of security holes.
<JordanBrown[m]>
Yes.
<InPhase>
So the safe strategy is just to clarify how it differs from scad. Python can do anything user beware, scad does not.
<InPhase>
And thus users need active awareness whenever python files are hidden nested within a scad repository.
<JordanBrown[m]>
But for instance totally disallowed write, and restricted read to PYTHONPATH and the source directory, it seems like stuff would work and the access would be adequately restricted.
<JordanBrown[m]>
I would say totally disallow file I/i bet that “import” is implemented at a level where it would be blocked.
<JordanBrown[m]>
Sigh DYAC disallow file I/O.
<InPhase>
I don't know how you'd totally disallow write. But screen capture? Network activity? Python executing arbitrary programs or launching dlls? Python code that creates and runs executable assembly code?
<JordanBrown[m]>
Totally disallow all of those.
<InPhase>
That's implementing a sandbox. It will be extremely non-trivial.
<JordanBrown[m]>
You’d have to block the mechanism that lets Python call arbitrary C.
<InPhase>
That would require rewriting cpython.
<JordanBrown[m]>
Other than that, you find the “open” call that’s buried somewhere, and you make it fail.
<JordanBrown[m]>
Yep.
<InPhase>
And if you tried, numpy would break, and then you lose half of the point of doing it. :)
<JordanBrown[m]>
On Solaris I could do it with our privileges, but that isn’t cross platform and I don’t know whether other platforms even have those capabilities.
<InPhase>
Python is really designed to benefit from that C integration.
<JordanBrown[m]>
I don’t know anything about numpy to know whether it would break.
<InPhase>
It would. It gets its impressive numerical performance from the C foreign function interface.
<InPhase>
You get python syntax and C speed numerical operations.
<JordanBrown[m]>
Ah. That would be unfortunate but I would sacrifice it to get the mature language.
<JordanBrown[m]>
I would be happy - well, happier - with the JS-in-browser model, where the program can say “here’s a file to save” or “please give me a file” but has no direct access to the file system.
<JordanBrown[m]>
But it does need access to its own files. For a browser they always come from the network, but I would want to support them all coming from a local constrained source.
<JordanBrown[m]>
I take it that numpy uses the “call this C function” mechanism, rather than the “write a C function that provides a Python function” mechanism?
<JordanBrown[m]>
The latter has risks but seems a lot more manageable.
L29Ah has left #openscad [#openscad]
<JordanBrown[m]>
Going back a bit and changing subjects a bit, a language with the “default return value of function is the value of the last statement” semantic would help to make programs that are simple in OpenSCAD stay simple in another language.
<JordanBrown[m]>
You would still need an explicit union if you wanted two cubes.
<JordanBrown[m]>
BTW… how did an IRC client show “two”? I typed it with asterisks around it and Element / Matrix shows it as italics.
<InPhase>
numpy basically has preoptimized C routines, and farms out to some other libraries written in Fortran, to do various array and matrix operations.
<InPhase>
But basically, "load this arbitrary shared library via extern C style binding" is the heart of it.
<InPhase>
JordanBrown[m]: IRC ate your asterisks. I see none.
<JordanBrown[m]>
Unfortunate. But I'd sacrifice it.
<InPhase>
Ironically, if *I* do it, it bolds it for me.
<JordanBrown[m]>
And that came through to me with asterisks.
<InPhase>
:)
<JordanBrown[m]>
You guys all need to move to Matrix.
<InPhase>
Or Matrix could just write a proper bridge.
<InPhase>
But I'm sure those sorts of features will get sorted out in upcoming releases.
<JordanBrown[m]>
Maybe, though I suspect that IRC doesn't have a standard for non-plain text.
<InPhase>
Correct, but there are some well established conventions.
<JordanBrown[m]>
Matrix lets you change the past, and that's sometimes nice.
<JordanBrown[m]>
(That came through on IRC as two messages, right?)
<JordanBrown[m]>
I am kind of surprised that all of the emphasis on sandboxed Python has been on pure-Python solutions. I haven't seen anything that discusses solutions with CPython support.
<Scopeuk>
given that the c bindings are used by almost every major python library and even more so by large applications it does seam an oversight
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
<InPhase>
Scopeuk: If you mean a sandbox with cpython support, that's precisely why it's not done.
<InPhase>
Scopeuk: The moment you call a single C library, you have broken out of any sandbox cpython can manage.
kintel has joined #openscad
<Scopeuk>
you can sand box a library but it's a little outside of scope I guess, and its going to wallop performance hooking all the sys calls
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
epony has quit [Remote host closed the connection]
bickelr777 has joined #openscad
bickelr777 has quit [Remote host closed the connection]
guso78 has joined #openscad
<rvt>
https://i.imgur.com/wbJZ62e.png Made this morning and printed, phone holder that fit’s on a existing iphone holder that had a crappy holder (magnetic I cannot use..), but a good platic suction cup.
<InPhase>
You made a phone holder holder?
<InPhase>
Because if so, I have an idea for what you can make next...
<InPhase>
The recursive options are wide open here.
<rvt>
InPhase: next?? I just have one phone :)
<InPhase>
Yes, but do you have a holder for your phone holder holder?