<othx>
linext linked to "Epitrochoid Quad Planter by jesse" on thingiverse => 1 IRC mentions
fling has joined #openscad
erectus has joined #openscad
teepee has joined #openscad
auctus has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
Another flaky test: opencsgtest_transform-insert seems to be flaky, but only on Windows. It crashes from time to time (return code 3221225477). Only CI tested.
<JordanBrown_>
teepee you said that for my Life video I used img2webp, but I don't find a script for that in my records - what I find is generating a .gif. Did I generate the webp, or did you?
<JordanBrown_>
Looks like you, based on the modified scripts in the repo that refer to Debian.
<guso78k>
pca006132 i did not look into it yet, but my 1st suspect is that its missing the the python installation. python-openscad only works if python 3.11.5 is installed in the same system. it will provide python.dll and python runtime files.
<guso78k>
not sure if there are available in the CI system
<pca006132>
probably not the specific version
JakeSays has quit [Ping timeout: 252 seconds]
<pca006132>
the msys2 build failed due to linker error at first, but after I add the glib2 dependency to OpenSCADPy it fail with runtime error
<guso78k>
hmm, its another different. i believe test suite in MINGW64 ...
<guso78k>
now it would be very interesting to me to download the actual MSYS2 openscad.exe and test it locally. is that possible ?
<pca006132>
no, but I think you can also just follow the same procedure as in the CI, it should reproduce
<guso78k>
ok i have seen the section "Running CI workflows locally" in the github homepage
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
JordanBrown has quit [Ping timeout: 240 seconds]
fling has quit [Remote host closed the connection]
fling has joined #openscad
JordanBrown has joined #openscad
<teepee>
CI could add the binaries as artifcats for later download, just the EXE would miss all the DLLs though, so I don't know how to easily package everything needed to run it
<guso78k>
teepee i think the reason why its not working is: exe does not see python3.11.dll . can it be ?
<J23k85>
doesn't only the exe misses the folder for templates and color schemes (and examples)
<guso78k>
J23k85 the situation with the folder, templates and color schemes did not change and it was fine before.
<guso78k>
new is the need for python.dll and error 0xc0000135 suggest a dll file is missing.
<guso78k>
teepee i have the missing dll file. being able to download the exe only is fine for me.
guso78k52 has joined #openscad
fling has quit [Remote host closed the connection]
<pca006132>
and I can join the discussion if performance is a concern, I have some experience writing interpreters and optimizing performance (not for openscad though)
<pca006132>
I don't have particular stance on this because I don't use libraries that often, but I do want to help to find something that most people can agree on...
<pca006132>
IMO I don't think the lexical + dynamic scope behavior to be very weird, openscad has much more weird stuff and this behavior seems to be helpful and will not cause confusion to new users either (if they hit this case, they are already violating the dynamic scope)
<JordanBrown>
pca006132 the lexical+dynamic scope thing is not too weird once you understand it, but the interaction with file-scope stuff in "use"d files is ... not obvious.
<JordanBrown>
But I need to try to sleep.
fling has quit [Remote host closed the connection]
JordanBrown has quit [Ping timeout: 245 seconds]
fling has joined #openscad
fling has quit [Remote host closed the connection]
misterfish has joined #openscad
fling has joined #openscad
guso78k has quit [Quit: Client closed]
auctus has quit [Read error: Connection reset by peer]
fling has quit [Remote host closed the connection]
fling has joined #openscad
auctus has joined #openscad
<InPhase>
pca006132: nophead produced an error output of is_undef not existing, which doesn't make sense as a related issue. If that's happening from properly structured code it sounds like a different bug. But I don't see the example code that produces this problem and has the issue reported.
<InPhase>
pca006132: As I originally emphasized, this will need to be a fact-based resolution with real world examples of code that has specific issues that we can examine and address. That was where the prior effort to resolve it kind of fell apart.
<InPhase>
The only example we found in the prior efforts was the one library where the issues were addressable without altering the code using the library. And it seems no other examples are available yet for a proper evaluation of what's allegedly going wrong.
<InPhase>
pca006132: I don't consider CSG-modules.scad an example of a problem. CSG-modules.scad works fine as is.
<InPhase>
Being able to use the modules inside of CSG-modules.scad in other code and alter the resolution of those modules is not a bug, but a known feature. The $fa and $fs variables follow call stack paths by design unless this is specifically overridden, which allows project-level definition of these.
<InPhase>
I'm happy to contribute to the discussion later (a bit busy right at this moment), but I just want to emphasize that it needs to be better grounded on evidence and actual real world examples of problems in the wild for it to progress forward.
<pca006132>
yes this is why I want you both to list some pros and cons, and probably provide some examples
<pca006132>
the is_undef not existing is probably a bug in my fix
<pca006132>
I think he means if you use CSG-modules.scad within another module, it will be problematic
mmu_man has joined #openscad
To_Aru_Shiroi_Ne has quit [Ping timeout: 268 seconds]
ToAruShiroiNeko has joined #openscad
<pca006132>
> follow call stack paths by design unless this is specifically overridden, which allows project-level definition of these.
<pca006132>
I think what he wants is the ability to have a default value for things that he defined, but still allow users overriding it
<pca006132>
if user provided the value in the call stack path or outer most module, that value will be used
<InPhase>
Well BOSL2 is not written to be use<>'d, and they highly discourage it, because of the issues in PAST releases. If we gave BOSL2 a consistent, sensible, and performant behavior for use<>, I'm pretty sure they'd make the library work with it.
<InPhase>
I also have one library that you cannot make use of with a use<>, and this is documented in its instructions (and has been so for very many years). So not everything can be use<>'d by specification.
<pca006132>
hmmm
<InPhase>
revarbat (main author of BOSL2) has his chief concern being issue #782, which requires removing the reevaluation to fix.
<InPhase>
I demonstrated in #782 that you can have wildly different performance changes with use, and some of them can actually be very very extreme.
<pca006132>
yes I understand
<InPhase>
Like, taking things from O(N) to O(N^2) or worse.
<pca006132>
but what I don't understand is, the behavior of checking file scope for $variable does not seem to harm anything
<pca006132>
if you want to fix #782, just add a dependency graph
<InPhase>
Well the problem is the behavior nophead wants fundamentally requires re-evaluation of the entire file's top level variables at every singe outside-to-in function or module call.
<InPhase>
Because he wants these values to be dynamically processed, and not just accessed.
<pca006132>
no? at least the solution he proposes is not
<InPhase>
It is what he has asked for in his past examples.
<InPhase>
Hence needing real world examples. ;)
<InPhase>
Yeah, but that's not what is required to make his examples work.
<pca006132>
can you point to the example?
<pca006132>
I am confused right now
Non-ICE has quit [Quit: Screw you guys, im going home!]
<InPhase>
$_bom = is_undef($bom) ? 0 : $bom;
<InPhase>
$_bom does not update from $bom in dynamic scope paths unless it is reevaluated. It's at the very top of that #3781.
<pca006132>
as I have said you can just use a dependency graph
<pca006132>
and only re-evaluate when $bom is changed
<InPhase>
I need to run and get the kid to school.
<pca006132>
yeah we can talk about it later
<pca006132>
I want to understand the semantics, so I can help fixing the re-evaluation problem... (and probably modify the architecture so things can run faster)
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
fling_ has joined #openscad
fling has quit [Ping timeout: 240 seconds]
L29Ah has joined #openscad
fling_ is now known as fling
<InPhase>
pca006132: And heading out to work, but I just wanted to add that the dependency graph solution creates some pretty wacky cases where you get lexical scope variables being part of a dependency graph to be re-evaluated dynamically at each function call, which breaks the core promises of the declarative language.
<InPhase>
pca006132: I think it's pretty easy to create examples where this creates shocking surprises upon activating it. And because of a path of use/include/include/include, these changes could trigger deep down into code that does not expect to be re-evaluated dynamically.
<InPhase>
pca006132: You also have the question of whether the dependency graph needs to evaluate function calls as well, because you get cases like: foo = bar(); where you might have: function bar() = $_bom + 5;
<InPhase>
We could also have: function bar() = echo("Running bar()") $_bom + 5;
<InPhase>
Now we have an echo of "Running bar()" every time any function or module is called inside the used module? Or is it going to run only in functions and modules that use lexical value "foo"?
fling has quit [Remote host closed the connection]
<InPhase>
Accessing a lexical scope value inside of a function or module really shouldn't be a thing that the language can cause to output an echo statement from a completely different function at the top of the invocation of said function or module.
<InPhase>
The layers of absurdity get deep...
<InPhase>
Can you imagine trying to explain this sort of insane language behavior to a beginner trying to learn the language?
<pca006132>
yeah, dependency graph should deal with function calls
<pca006132>
ideally, I think a purely functional language should allow for caching function evaluations... this is what I hoped for modules
<pca006132>
but this kind of caching will change code that are not strictly pure
<pca006132>
from my understanding languages like nix, which is pure and lazy, also provides something like echo which allows tracing messages, does not guarantee when those effects will be evaluated and in what order
<pca006132>
anyway I should summarize my points in the thread, irc is not really a good place to discuss complex issues
<InPhase>
pca006132: Well, past experience leads me to expect the issue thread to spiral out of control if it's not grounded on specific examples. These should really come first so that everything is in a realistic context regarding outcomes.
<pca006132>
I actually have an example showing the current behavior in master is broken as well
<InPhase>
If it's just a discussion about "should" it's already solved. Deviations from what should happen for specific cases need a good justification, and then the specifics allow us to find where to thread the needle to not cause too much chaos like the things I mentioned above.
<InPhase>
A full dependency graph re-evaluation is probably a deeply broken approach because it will cause much chaos in outcomes, so it would require a pretty serious justification I think.
<InPhase>
Or at least be locked behind an option marked off. But that sounds like complicated code to keep behind a default off option.
<InPhase>
There are future maintenance burdens to such a choice as well.
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
cart_ has joined #openscad
fling has quit [Ping timeout: 240 seconds]
fling has joined #openscad
Non-ICE has joined #openscad
erectus has quit [Remote host closed the connection]
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
<teepee>
pca006132: what's the problem with the first example in that link?
<pca006132>
if you are the author of library2.scad, you need to set $a = 2 in foo1 and bar1, so the calls to foo and bar can have $a = 2
<teepee>
yes
<teepee>
or actually no, as you prevent the user from ever overwriting it
<teepee>
so you should *only* overwrite it in library2 if the library needs to force the behavior, otherwise leave it to the user
<pca006132>
ah, but what if you really want to force that?
<teepee>
then you have to set it *dynamically* because it's a dynamically scoped variable
<pca006132>
yes but here is the problem: if you have 100 such modules and 20 such variables, you will need to add 2000 lines and duplicate the same 20 lines of code 100 times
<teepee>
with dynamically meaning somewhere on the current call stack starts from the top level user file
<teepee>
you can then just write a wrapper around that single function, or we may want to check if there are other means to simplify what the user needs to write
<teepee>
e.g. value_or_default_if_undefined(v,, 3)
<teepee>
that is supposed to be 1 , not two
<pca006132>
the wrapper should accept a lambda I guess
<pca006132>
oh, I never tested the behavior of lambda
mmu_man has joined #openscad
<teepee>
I can totally see how the magic "mostly-dynamic-but-in-this-special-case-also-a-bit-static" scope is useful for setting defaults
<teepee>
but it would be much better finding a cleaner way of how to specify this
<pca006132>
with a wrapper it is a bit nicer, at least you don't have to duplicate the same set of assignments many times...
<pca006132>
but thinking about it, if library writers do this, does it matter if file level variables got re-evaluated each them they use it? they have to re-assign those variables every call now...
<pca006132>
not sure if it is better from a performance perspective
<pca006132>
if they are file-level, at least you have ways to cache them
<pca006132>
I will leave this here, time to sleep...
fling has quit [Remote host closed the connection]
fling has joined #openscad
<linext>
is there an equivalent program to openscad for STEP?
misterfish has joined #openscad
snaked has quit [Ping timeout: 268 seconds]
<teepee>
linext: anything using opencascade I guess, e.g. cadquery
Non-ICE has quit [Quit: Screw you guys, im going home!]
<JordanBrown_>
IMHO a dependency graph "answer" would be a horrible idea, tons of complexity to solve some very narrow problems.
juri_ has joined #openscad
snaked has quit [Ping timeout: 255 seconds]
misterfish has quit [Ping timeout: 256 seconds]
Non-ICE has joined #openscad
<JordanBrown_>
I think the two sides are "top level variables should be evaluated on each call into the file" and "top level variables should be evaluated once, at use time (with the disposition of $ variables unclear)".
<JordanBrown_>
I don't think there's really a reasonable way to achieve the "each-call" semantic in a "once" implementation; it would require adding all of those assignments to each function and module in the file.
<JordanBrown_>
At the same time, I don't think there's a reasonable way to achieve the "once" semantic in an "each-call" implementation; there's no place to set those "static" variables.
<JordanBrown_>
And backward compatibility certainly leans toward the "each-call" semantic.
<JordanBrown_>
I have two tentative ideas that might help.
<JordanBrown_>
Both of them rely on #4478 objects.
greenbigfrog has joined #openscad
<JordanBrown_>
First, add a new function import("foo.scad") which returns the evaluated contents of the file as an object. (Exact details handwaved.) This addresses a number of namespace issues and as a new mechanism can have whatever semantics are desired - presumably "once" semantics. Calls into functions and
<JordanBrown_>
modules in the object would (somehow) get the top
<JordanBrown_>
-level variables interposed into both their call-stack and lexical context lists.
pca006132 has quit [Quit: pca006132]
pca006132 has joined #openscad
<JordanBrown_>
Second, to achieve "each call" semantics, the library could have a "get_defaults()" function that calculates all of the desired dynamic values and returns them in an object. Each function or module that wants the defaults would need to add "d = get_defaults();" and refer to "d.somedefault". (But
<JordanBrown_>
would not have to have N duplicated assignments.)
<JordanBrown_>
That said, shooting a hole in that idea: done in its obvious way, that scheme would lead to re-evaluating the defaults on each intra-file call, which I bet the 2021.01 "each call" semantic does *not* do.
<JordanBrown_>
But even if that problem isn't readily solvable, those wanting "each call" semantics could continue to use "use".
L29Ah has joined #openscad
snaked has joined #openscad
snaked has quit [Quit: Leaving]
fling has quit [Remote host closed the connection]
erectus has quit [Remote host closed the connection]