<joseph_>
teepee: I spent this weekend trying to get recent versions of master to work, as my goal is to apply refactoring on top. Previously I didn't exepct this to take too long. But strangely, the same Dockerfile that worked last summer (with the new dependency libtbb added) fails to build the latest master. I found that I could technically eliminate the build errors with "ln -s /bin/sh /usr/bin/sh; ln -s /usr/lib/libqscintilla2_qt5.so /
<joseph_>
Predictably, that didn't work at runtime. I get "GLib-CRITICAL: g_main_context_pop_thread_default: assertion 'stack != NULL' failed...g_main_context_push_thread_default: assertion 'acquired_context' failed". I wondered, what change to the code since last summer could have caused those path/dependency changes? For example, the libqscintilla2 library doesn't seem to get a version change other than in the Mac build script.
<joseph_>
If you happen to have an idea of what went wrong, I'd be grateful. It seems baffling that something as major as the location of /bin/sh would get affected by the changes since 841808390. Anyway, here's the status of things now. I can at least build and run (with X forwarding) inside a Debian bookworm Docker image. But that binary will not run natively on my host Debian bullseye system.
J23k17 has quit [Ping timeout: 246 seconds]
mmu_man has quit [Ping timeout: 240 seconds]
Church- has quit [Quit: Leaving]
knielsen has quit [Server closed connection]
knielsen has joined #openscad
snaked has joined #openscad
clemens3 has quit [Server closed connection]
clemens3 has joined #openscad
guso78_ has quit [Server closed connection]
guso78 has joined #openscad
little_blossom has quit [Quit: little_blossom]
berndj has quit [Server closed connection]
berndj has joined #openscad
guso53 has joined #openscad
misterfish has joined #openscad
misterfish has quit [Ping timeout: 265 seconds]
teepee_ has joined #openscad
little_blossom has joined #openscad
teepee_ has quit [Remote host closed the connection]
<kintel>
I believe most devs build locally, not using Docker. Otoh, all CI systems likely build in containers, so there shouldn't be too many surprises.
<kintel>
In my experience, unless you set up your dockerfile very very carefully, with mapped volumes for build caches etc., using docker for development causes quite large development
<kintel>
*long development cycles.
<lf94>
I find Docker is only great for deployments
<lf94>
But there are some that use it religiously as an environment isolation tool
<kintel>
Once you find a way of caching all expensive operations, including object files from previous builds, I'm sure it will work fine :)
<kintel>
joseph_ Anyway, if you figure out how to build cleanly in a bullseye docker file, it would be awesome if you could clean up that dockerfile to looks as similar as possible to the other dockerfiles and add a new folder for bullseye to https://github.com/openscad/docker-openscad
mmu_man has joined #openscad
mmu_man has quit [Ping timeout: 240 seconds]
gimzmoe_ has joined #openscad
<lf94>
Have we really not come up with a way to do universal chamfers / fillets in CSG?
<lf94>
As in: a universal technique.
<lf94>
How does BREP do it? Do they have special fillet / chamfer per shape? Surely now
<lf94>
not
<lf94>
I was thinking last night: for a box with ONLY rounded around it - you can round the full box, and then do an intersection with a "infinite box" where the top and bottom go off into infinity
<lf94>
But that's just a box. Can the same intersection technique work for everything? I really feel there is a set of operations we can combine to get fillets anywhere.
Digit has quit [Ping timeout: 268 seconds]
<lf94>
I'm increasingly frustrated we haven't "found" this solution
Digit has joined #openscad
<lf94>
There needs to be a combination of 1. selecting the "edge" to round 2. rounding it 3. merging back the round with the rest of the surrounding context
<lf94>
There's gotta be a mix of intersection/difference/union we can use
mmu_man has joined #openscad
guso53 has quit [Ping timeout: 246 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
that on the internet and a really nice person in the real world
<teepee>
even though I wonder if that supposed real world still exists ;-)
<misterfish>
oh that's really nice, thanks. looks like she does super interesting stuff.
guso9 has quit [Quit: Client closed]
misterfish has quit [Ping timeout: 240 seconds]
adigitoleo has quit [Ping timeout: 248 seconds]
adigitoleo has joined #openscad
<juri_>
I try! :)
<juri_>
I'm getting time to work on my slicer again tonight. YAAY! :)
<juri_>
(work got crazy busy, still recovering)
J23k has quit [Quit: Client closed]
J23k has joined #openscad
<joseph_>
kintel: Last summer, I made my bullseye Dockerfile based on the existing bookworm one from the openscad repo. At this point, especially considering that bullseye is now oldstable, it might be a better use of time for me to just upgrade my secondary laptop to bookworm and use that for testing graphics things that require running natively. Upgrading the OS of my main desktop is a bigger task and probably something I should wait to
<joseph_>
do until after GSoC
<joseph_>
And yes, there is a tradeoff with doing the builds inside Docker, but I find the environment isolation benefits to be worth it. Especially when having issues like this, where there is a reproducible chain of steps to see what causes dependency problems (and trivial switching between OS versions). Last summer I believe I got a build cache volume working. Even without it, on my system a full compile/link of OpenSCAD is <2min, so
<joseph_>
still not too bad IMO
Guest8432 has quit [Changing host]
Guest8432 has joined #openscad
Guest8432 is now known as gwillen
misterfish has joined #openscad
<lf94>
Yeah that's not bad at all
<lf94>
Might be the time to update the Dockerfile's to use current Debian stable yeah?
kintel has joined #openscad
<kintel>
joseph_ getting bullseye build to work in Docker is worthwhile though, and should be a reasonable effort as I'm pretty sure this is working for other people on bare metal.
<kintel>
Especially qscintilla shouldn't have changed in years.
<kintel>
Perhaps give the buster and stretch dockerfiles a spin to check if those work on your system
<kintel>
Anyway, getting those dockerfiles submitted to our docker repo would allow us to enable autobuilds, which would help fight bitrot in the future
<kintel>
I think the only caveat for building on old systems is whether any of the new dependencies (isolated to tbb I think) is available on the distro in question
<kintel>
..so if you're struggling with scintilla, perhaps build without -DEXPERIMENTAL until that works
<joseph_>
kintel: Would building without DEXPERIMENTAL disable the "experimental" VBO features too?
<kintel>
yeah, but it will leave qscintilla enabled allowing you to sort that out before moving onto the next issue
<kintel>
I'm curious though: How did you build OpenSCAD for the last 3 weeks or so? Did you work on Mac/Windows until now?
<joseph_>
kintel: I had been working off of last year's branch as a base, so the builds worked with my previous Dockerfile. Now that the goal is to apply my changes on the newest master, I'm running into these issues
gbruno has quit [Server closed connection]
<kintel>
ok, makes sense. I'd suggest copy the bookworm dockerfile and modify it to work on bullseye then. Changes should be minimal I think.
gbruno has joined #openscad
guso35 has joined #openscad
niyawe has quit []
niyawe has joined #openscad
guso35 has quit [Ping timeout: 246 seconds]
misterfish has quit [Ping timeout: 240 seconds]
guso55 has joined #openscad
<guso55>
Using python, The script can be much smaller and much more performant at the same time, than the openscad language counterpart.
<guso55>
The picture shows an 6th order 3D Hilbert curves and it rendered in few seconds on my linux virtual machine only
<guso55>
It used less than 20 lines and half of it is used for octant decoding.
<kintel>
Yeah, the goal was to push glib into a corner, as it's becoming a major pain in the ass
guso44 has joined #openscad
<kintel>
The changes are pretty clean, just moved some functions into the class
<guso44>
@kintel, thank you for your attention and for your hint!
<guso44>
right now this info is too abstract to me, but if analyse the code and the classes i will probably know, how to get it compiled.
<guso44>
I am just wondering why it does not compile as my local copy of builtin_function.cc appears to be the exact same as in master branch. i must have missed another change.
<kintel>
Did you change anything similar btw., or are you running into a compiler issue?
<kintel>
To double check, perhaps build a clean master, just to eliminate that as a problem
<guso44>
I doubt its a compiler bug. i just believe my local copy is not "consistent"
<kintel>
Kind of smells like wrongly timestamped object file issue
<guso44>
thank you for the hint. i will now try to compile my copy of master. this will help me to locate the problem.
<guso44>
still i dobt about the timestramp issue as i did a make clean
<guso44>
thank you for your hint anyway
<InPhase>
kintel: I'll try a build as a second check.
<InPhase>
guso78: I tried order 3 in scad code (a rough version, mirroring your implementation) and it was fast. order 6 sort of blew up and is running super slow.
<InPhase>
guso78: But maybe it got upset because I didn't arrange the outlines of the path properly with the direction changes, but just hacked it as a z-normal circle all the way along as a first pass.
<InPhase>
guso78: There's a little magic in your path_extrude that I don't have in OpenSCAD library form yet.
<guso44>
Inphase, order 6 rendered in less than 10 seconds in my Virtualbox emulated linux. but of course scad version involves lot of CGAL union whereas my latest version uses direc path_extrude
<InPhase>
guso44: Oh, I'm doing a singly polyhedron. So no unions.
<InPhase>
single
<guso44>
InPhase, ahh probably you are using BOSL2 ...
<InPhase>
But, still, something blew up. Maybe I made a mistake and have a bunch of undefines propagating and I'll find out at the end. ;)
<guso44>
i doubt that there is any magic in path_extrude
<guso44>
BTW: my master also compiled fine.
<InPhase>
That is an unfortunate issue in OpenSCAD yet, that accidental undefines radically increase render time, but invisibly as the gui locks up until it is done failing.
<InPhase>
We'll need to fix that with some proper threading one of these days.
<guso44>
will look into that tomorrow why my python branch does not compile as expected. it will be even easier with the change description from kintel.
<InPhase>
Yeah, master was able to compile for me as well.
<guso44>
probably the problem becomes obvious when performing git difftool master ...
<guso44>
InPhase, maybe the "magic" of my path_extrude is that it will NOT squeeze the cross-seciton profile even the angle in a corner is 179 degrees ....
<InPhase>
guso44: Oh, note that str_utf8_wrapper used to be in value.h. Most likely you did not actually have a clean build there, or for some other reason value.h did not update with your merge/pull and you are left with an extra str_utf8_wrapper without the new members.
<guso44>
Thank you for your hint. will especially look into value.h! Thx!!!!
<guso44>
InPhase, maintaining the x-section profile works without introducing any additional extra slice.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<guso44>
InPhase, for your hilbert test did you derive from my script or from original hilbert on thingiverse ?
<InPhase>
I mirrored your script.
<guso44>
wow, you translated back "def" to function
<InPhase>
And, order 5 previews in 1 second, while order 6 took more than 30 minutes before I got tired of waiting for it. It must be hitting some weird bug, because that does not make sense as a scaling factor. https://i.imgur.com/2aFKchA.png