<kintel>
InPhase I could use a second pair of eye on that PR btw., just in case you see something suspicious. ..but once the tests pass I think it's mergeable
bozo16 has quit [Ping timeout: 245 seconds]
<InPhase>
4585, right?
J23k26 has joined #openscad
<InPhase>
CMake Warning at tests/CMakeLists.txt:102 (message): Failed to setup the test suite venv for VENV_BIN_PATH-NOTFOUND/python See doc/testing.txt for dependency information.
<InPhase>
Not a promising start.
<InPhase>
I got a venv not found.
<InPhase>
I'm going to try a fresh master branch clone as a control here.
J23k87 has quit [Ping timeout: 250 seconds]
<InPhase>
Yeah, a fresh master clone worked, so this is the PR broken.
<InPhase>
Step 2, why...
arebil has quit [Quit: arebil]
<InPhase>
It did create a venv, but no pip packages were installed.
<InPhase>
lol, okay.
<InPhase>
kintel: So your script looks for bin and Scripts up above the python3 -m venv venv line that creates these directories...
<InPhase>
Hence it will not function on a clean build.
<InPhase>
Right approach I think, but wrong execution order.
<InPhase>
You might need to do it to see if it's there, then do it again if it was newly created.
<kintel>
InPhase: Argh, I asked too early - was too confident...
<InPhase>
Well, I bet it worked fine for you. :)
<kintel>
yeah, got tired of wiping my build directory :)
<teepee>
do they also have a python-venv package maybe?
<teepee>
on debian that's required, not sure if msys2 has the same setup
<teepee>
mingw-w64-python-virtualenv
<kintel>
My understanding is that virtualenv is just a small convenience wrapper over the built-in venv module
<kintel>
..but perhaps it offers some cross-platform query features?
<teepee>
not sure, I'm doing a bit of python stuff lately and it's still confusing
<teepee>
but on debian I had a similar issue when running in bookworm-slim docker
<teepee>
the package was called python3-venv though
<kintel>
teepee Since venv comes with python >= 3.3, we just use "python -m venv" to launch it, eliminating the need for any wrapper packages
<kintel>
(I think)
<kintel>
I still greatly prefer python as an interactive tool running only on my machine :)
<teepee>
exactly that command did not work without the package
<teepee>
with only python3-minimal installed
<kintel>
huh, that's interesting..
<teepee>
I guess it's default in "normal" installations
<kintel>
oh, python3-minimal - a minimal subset of Python :)
<kintel>
In that case we're probably talking distro-specific packages indeed
<kintel>
venv vs. virtualenv is likely smth. different - I think virtualenv predates venv, and since python 3.3, a subset of virtualenv, named venv, made it into the Python standard library
<teepee>
I have not seen a venv package in msys2, so hopefully it's in the normally installed package
<kintel>
yeah, it seems to be
<kintel>
Considering Guido came out of retirement to work for Microsoft, perhaps his new mission is to make Python behave on Windows :)
<kintel>
(at least we can dream)
<InPhase>
I've dreamed of Python being a base scripting language available on all platforms. This would make the developer life so much better.
<InPhase>
If we could just count on it always being there, we could make use of it as a portable baseline.
<InPhase>
teepee: Although without clarifying what that means for each system...
<teepee>
yeah, I assume we will get full platform abstraction as soon as we decide to have a single system only ;-)
pca006132_ has joined #openscad
<pca006132_>
note that for some build systems, e.g. nixos, the build process has to be entirely offline and the venv approach will not work
<teepee>
yes OBS is the same, prepare stage with network access, build completely offline
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
pca006132_: That's fine, because the venv is only required for the testing suite.
<InPhase>
pca006132_: I specifically made it warn but continue when it cannot build the venv.
<InPhase>
Everything will build, but then you have to address the deficit later if you want to do testing.
<InPhase>
pca006132_: The thinking was that users who just want to build their own copy do not need Python then, but developers who are going to submit code do. And this is exactly the subset of people who should have no trouble getting Python going.
<InPhase>
Or, well, at least not too much trouble... kintel did suffer a bit on a few of the Windows setups, hence the current fix in progress. :)
<InPhase>
But this is no worse than the imagemagick dependencies which seem to be growing more deprecated.
<InPhase>
I'm glad to be rid of that dependency, because it was clashing with the shift to graphicsmagick instead of imagemagick.
pca006132_ has quit [Quit: Client closed]
misterfish has joined #openscad
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
pca006132_ has joined #openscad
<pca006132_>
so imagemagick is deprecating? thought it is more popular and feature rich comparing with graphicsmagick
<pca006132_>
not familiar with this though
pca006132_ has quit [Client Quit]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<InPhase>
pca006132: The distros seem to be moving away from it toward graphicsmagick. I haven't followed it closely.
guerd87 has quit [Ping timeout: 255 seconds]
dalias has quit [Ping timeout: 255 seconds]
lastrodamo has joined #openscad
dalias has joined #openscad
bozo16 has joined #openscad
guso78k has quit [Quit: Client closed]
arebil has joined #openscad
mmu_man has joined #openscad
misterfish has quit [Ping timeout: 255 seconds]
guerd87 has joined #openscad
lastrodamo has quit [Quit: Leaving]
misterfish has joined #openscad
kintel has joined #openscad
<kintel>
Actually, in msys2 mode I opted for preinstalling the needed Python packages using pacman. Still using venv to avoid building another code path just for that :)
snaked has quit [Remote host closed the connection]
snaked has joined #openscad
J23k26 has quit [Quit: Client closed]
J23k26 has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kintel>
Could we come up with a good set of regression tests for this?
<kintel>
Happy to add them myself, but I need help finding the corner cases
<kintel>
Also, it's not clear to me if the PR fixes any regression against the last release (2021.01) or if any functionality is changed.
Lagopus has quit [Ping timeout: 256 seconds]
Lagopus has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dalias has joined #openscad
<InPhase>
Why are we preparing a PR to add a workaround for #3781 when this was an issue in a single library that already implemented a workaround for #3781 and works fine in the master branch?
<InPhase>
#3781 probably should have been closed when nopscadlib selected a way to resolve the issue.
<InPhase>
I gave one solution in a PR. nophead didn't like that one, and picked another. But it seems to be working fine when I test it.
<InPhase>
In a comprehensive search that I attempted in 2021, there appeared to be a grand total of zero other libraries or projects having the specific problem in question.
dalias has quit [Ping timeout: 246 seconds]
<InPhase>
We would be adding complexity to solve a problem that doesn't appear to exist anymore.
<InPhase>
I thought the only remaining code change to make from that line of discussion and inquiry was the re-evaluation overhead.
<InPhase>
i.e., removing the overhead of re-evaluating that is no longer required, as documented in #782
foul_owl has quit [Ping timeout: 260 seconds]
<teepee>
oh, other solution?
mmu_man has quit [Ping timeout: 260 seconds]
foul_owl has joined #openscad
kintel has joined #openscad
<kintel>
InPhase I'm confused, if this is no longer an issue why is nophead still saying "...this bug has stopped me updating for two years" ?
<kintel>
I'm more than happy to ignore all of this :) ..but it would be good to get some test coverage around this topic to avoid future regressions, unless that's also resolved by now
fling has quit [Remote host closed the connection]
fling has joined #openscad
mmu_man has joined #openscad
<teepee>
he also stopped at some point due to still using win7 and I gave up trying to support that
<InPhase>
kintel: Man, I don't even know. The whole response to that issue was more emotion than fact. But all of his examples in the repository now work with dynamic behavior in both 2021.01 and the master branch just fine. The only difference is that the master branch is much faster.
<InPhase>
They're available to test. I tested them.
<kintel>
OK, perhaps we should just close with an appropriate statement, then ask for a new ticket if stuff is still not working as expected
aiyion1 has quit [Remote host closed the connection]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aiyion1 has joined #openscad
kintel has joined #openscad
kintel has quit [Client Quit]
aiyion1 has quit [Remote host closed the connection]
aiyion1 has joined #openscad
pca006132_ has joined #openscad
<pca006132_>
ah I am confused as well, thought that issue is a major blocker for release
<pca006132_>
I think the examples I gave in the PR can be used as test cases
<pca006132_>
I am currently in hospital
<pca006132_>
so I am afraid I cannot help much for now (at least for today)
<teepee>
yeah, that was my understanding up to now too
<teepee>
wishing you all the best, get better soon
dalias has joined #openscad
pca006132_ has quit [Quit: Client closed]
<InPhase>
pca006132: I see you're checking the log, so I'll reply and hope you catch it later. I don't know if you meant you're ill or family or something, but I hope you and/or your family are well and recovering.
<InPhase>
pca006132: There was a lot of debate about how things "should" be, and some debate about efficiency. But the overwhelming consensus was a strong agreement that dynamic and lexical scopes should do the thing they're definitionally supposed to do, like described in the manual. In fact the notion of "file scope" didn't even exist as a thing in OpenSCAD except in nophead's interpretation of this bug
<InPhase>
behavior that he apparently discovered some time back. This is why no one else was using it, because there was no file scope parsing intended nor documented anywhere. So it would have only had a role as a feature to be quarantined into an option. Except this is only worth doing if there is a mass of code in the wild that requires it.
<InPhase>
There was discussion in the prior threads about how functions would be slower than the old "file scope" behavior, but that was in fact false. I actually benchmarked this, and documented that in the PR I submitted to nopscadlib, showing that there is zero overhead using functions for this purpose. Where there IS a large efficiency difference is that issue #782 which can explode into some truly gigantic
<InPhase>
computational overhead, adding massive hidden costs to every usage of anything in a use<...>
<InPhase>
I don't think nophead actually understood the function proposal I made, because he kept insisting it would change how people needed to use the library. I demonstrated that it wouldn't, and that it was only an internal change within the library, and would preserve external code using it. But he was upset at the time and didn't really want to hear it.
<InPhase>
We're talking about like 60 minutes worth of work to change the entire library over to using function calls internally, and the issue would have been completely resolved.
<InPhase>
It's pretty simple really. He was looking for dynamically adjusted lexical scope variables inside the library. All that needed to be changed was swapping any variable that needed to be dynamically adjusted within the library to a tiny function call that dynamically adjusts its return value, and then the values that need to be adjusted are recomputed within the dynamic scope provided by the caller.
<InPhase>
Nothing external needed to change.
<InPhase>
It's the same computation, just the library would be explicit about what should be dynamic and what shouldn't, rather than relying on reprocessing the entire use context (even the parts not needed) on every single function or module call into a used module.
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
kintel has joined #openscad
<kintel>
pca006132 Hope everything is or will be ok with you..
<kintel>
InPhase ok, so this sounds like there may be some weak feature request hidden in that discussion. Let's close it and deal with any of that in another topic, if needed
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
InPhase Just for my understanding: The behavior nophead discovered, which doesn't hold any longer, do you know for which version ranges of OpenSCAD this behavor existed?
<InPhase>
Followed by "That's indeed a bit odd. I wonder if there is some lookup bug which prefers a file-scoped variable to a dynamically scoped one. Needs some careful investigation.." -kintel
<InPhase>
That investigation then eventually happened in circa 2021. :)
<juri_>
languages are hard.
<InPhase>
NopSCADlib only started as a git repository in 2019, but has a copyright of 2018 in the first commit on the bits that are using this. So it seems he started using it shortly after this discussion about finding it and you mentioning that it was probably some sort of lookup bug.
<peeps[zen]>
new bug? let me base all my code on it
<InPhase>
peeps[zen]: Look, just add an option to reenable spacebar heating. :)
<InPhase>
I got linked to that xkcd so many times after the time I setup a hotkey to run a script to warm up my computer on an old computer where the "s" and "q" keys only worked when the keyboard was warm.
<buZz>
InPhase: :) reminds me of a dutch nerdcamp i was camping at, we had a pretty cold/humid tent/village , and were running perl forever loops with hard math to keep all cpus at 100% load to get temp a very tiny bit higher :D
<buZz>
worked well though
<buZz>
maybe 1° hotter per hour or something, enough for some comfort :)
<InPhase>
The farther back in time you go, the better computers worked as space heaters.
<InPhase>
Get several of them in one room, and it gets into serious business range.
<buZz>
:) this was eh, 2013 i think?
<buZz>
or 2009 perhaps
<buZz>
it was the year redhat was really amping up 'spending on community' , so we had free beer all event :D
<buZz>
while not a single pc running it
<InPhase>
Well, 23 2013 era processors, and that's a legit space heater on full blast. ;)
<pca006132_>
thanks, it is not a big deal, they just want me to stay for 2 daysto
<pca006132_>
*to make sure it is safe
<pca006132_>
InPhase: Yeah I can see why using function is ok, and the performance should be roughly the same
<pca006132_>
I was thinking that the reason he insisted on this is to make sure things are backward compatible, so users will nkt
<pca006132_>
*not have to ask about how to upgrade blablabla
<InPhase>
That problem was solved years ago as far as I'm aware.
<pca006132_>
but nophead said it blocked him from using a newer version of the library for 2 years...
<InPhase>
I think from one of his recent comments that he hasn't tried a new version since May of 2021 or so. He also said he had to stop all future releases for that library because github has blocked password authentication with https. That's just how nophead reacts to small change. :)
<pca006132_>
Won't merge because it requires all projects to be rewritten in a more ugly and bug prone form.
<InPhase>
Yes, I saw that too back then. But the whole point of that approach was that it allowed projects to be unchanged, which I explained to him.
<pca006132_>
I guess he means all projects that need this kind of access behavior have to change
<pca006132_>
From my point of view I would consider my fix to be harmless, in the sense that it does not change the behavior of well-written code, just adds a fallback for their wrong code
<pca006132_>
but should this be the default behavior is open for debate, I don't write enough openscad code to have an opinion about it :)
<pca006132_>
(and from a PL point of view openscad variables are already very weird, adding this change will not make it more weird)
<InPhase>
This was my comment to him upon providing that PR: "I prepared a pull request for your library converting extrusion_width and layer_height to functions. I used a code-wide regex to help with the conversion (then fixed up a few special cases you had that didn't fit the pattern). It appears to generate identical models in 2021.01 as in the master branch, correctly picking up special variable values set
<InPhase>
in the main file, or using defaults from global_defs when not set, and the preview and render performance times I tested were exactly identical before and after the change. I hope that demonstrates that this solution actually resolves the issue successfully and without any change in the performance or usage of the library. If you have other values in global_defs, or elsewhere, that need updating to get
<InPhase>
the same behavior, you can follow the same example as that PR"
<InPhase>
It was not a hard PR to prepare, and it made his example code work without modification.
pca006132_ has quit [Quit: Client closed]
<InPhase>
And, as said, rather than slow it down, made no performance difference at all. He thought it was "ugly", but it was a pretty modest internal syntactical change to the library, with each line looking almost identical.
fling has quit [Ping timeout: 240 seconds]
fling has joined #openscad
fling has quit [Remote host closed the connection]
fling has joined #openscad
<InPhase>
I interpreted his final rejection comment on that PR as an aggressive unwillingness to embrace small change, and in the context of his prior comments blaming the whole situation on me (which... I didn't even make the change in question, I'm just an advocate for language consistency matching the specified behavior), I decided it was best to halt trying to explain it to him any further at that time, and
<InPhase>
give him time to cool off. And I suppose he did end up making some changes of some sort that satisfied him adequately, because his library works in the master branch now.
Joel has joined #openscad
<InPhase>
I'm not sure why he continues to post about it as some sort of problem. He should probably show something that's actually broken and too burdensome to fix, because I don't see anything left.
<InPhase>
So I guess all I'm advocating for now, is let's have some fact-based solutions that start out by measuring what real problems actually exist. :)
<InPhase>
And when we have some example problems, then we can assess the most sensible way to fix them. Putting the bug back as an option without it being a real usage issue in the wild with piles of users suffering because they are depending on the bug sounds sketchy to me.