<teepee>
and for full disclosure, my github user name is t-paul ;-)
<spuder>
Ah ok, so you probably are already aware of the issue I'm referring to.
<teepee>
yep
<teepee>
and guilty of creating those docker containers too :)
<spuder>
I appreciate all the help.
<spuder>
What other debugging information can I provide? I'm trying to learn how to generate a core dump to see if it would be helpful in narrowing down this issue. I've got core dumps working in docker containers, but still haven't been able to capture one with the --animate crash. The command you provided is getting closer
<teepee>
I have to thank you for looking into that issue. I really know how time consuming that kind of stuff is
<teepee>
yeah, I just saw that too, it's not triggering the gdb error handling
<teepee>
there's probably some option to force that
<teepee>
the problem is that's an error response from the X server side, so maybe some parameter is wrong when sending the message and that's a bit of an annoying case
<teepee>
usually all that communication is asynchronous internally
<teepee>
some toolkits provided a --sync option to at least do everything synchronous, which is slower but helps with debugging
<teepee>
hmm, there's MESA_XSYNC
<spuder>
Hmm, looks like my debug build didn't include symbols
<spuder>
`Reading symbols from openscad...(no debugging symbols found)...done.`
<spuder>
hmm, setting those environment variables I see no difference in gdb
<teepee>
looking at the debug output it does seem to create new connections every time
<teepee>
which is probably a bad idea anyway. I wonder if changing that would help
<teepee>
it's a bit more intrusive that a dedicated bugfix (I assume, without knowing what the root cause is, that's a bit of a guessing game still)
qeed_ has joined #openscad
<spuder>
I think I was wrong about making a debug build of openscad. It looks like I may need `qmake CONFIG+=debug ${qmake_options}`
<teepee>
for the release version, yes
qeed has quit [Ping timeout: 260 seconds]
<teepee>
different for the dev snapshots as those are now cmake
SamantazFox has quit [Ping timeout: 256 seconds]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
qeed_ has quit [Ping timeout: 250 seconds]
qeed has joined #openscad
<InPhase>
Is it possible to make a docker container for which the OpenGL library set and environment is identical to the AppImage release? It seems like a reduction in the changed variables could really help pinpoint things.
<teepee>
I'm not sure, I think the AppImage mostly uses the local driver which is difficult in a container
<teepee>
InPhase: did you post some sort of circle inference pattern some time ago, e.g. what could be used as fan grill or something like that?
<InPhase>
Circle inference?
<InPhase>
Do you mean interference or something else?
<othx>
InPhase linked to "Plot Function library for OpenSCAD, with Cartesian, Polar, and Axial coordinates by rcolyer" on thingiverse => 22 IRC mentions
<InPhase>
Do you have an example picture of the fan grill pattern?
<teepee>
like having a bicycle wheel but the outer part rotated a bit
<InPhase>
Ah.
<InPhase>
Yeah, I suppose I did that at some point. How did I do that and where are the files.
<spuder>
Which opengl library set are you looking for? Could you run the official app image container? `docker run --rm -it openscad/appimage-x86_64-base /bin/bash`
<teepee>
spuder: that depends on the GPU, the container uses swrast.so which is the mesa software renderer
SamantazFox has joined #openscad
<dalias>
is there any way to get the preview ui to show coordinates of mouse pointer?
<dalias>
trying to match up locations from an imported stl and it's painful
<spuder>
I finally got a build with debug symbols running, but when trying to run a backtrace in gdb I get `No stack.` Maybe trying to get a backtrace isn't helpful and I should look elsewhere.
<teepee>
dalias: no, what might work if it's just one or 2 is to add a small colored cube and moving that around via ALT+CTRL keys
<InPhase>
teepee: Distracted by kids... I don't spot the file, it was probably a temp file throw-away. But I actually like that atomic spiral design a lot more for aesthetics if you have no purpose for a spiral. :)
<InPhase>
s/atomic spiral/atomic oval/
<dalias>
teepee, that's basically what i did :-p
<InPhase>
That looks trivial enough to do. I'd do it with: $fa=1; $fs=0.4; offset(1) resize([100, 30]) difference() { circle(100); circle(99.999); }
<teepee>
InPhase: yep, just for visuals holding the inner part, let me try to upload the current state :)
<InPhase>
We really should get ourselves some line paths at some point so I can stop faking them. :)
<teepee>
yup, and a reasonable library handling :)
<InPhase>
I made the tiny hole bits disappear by eating them.
<teepee>
ah, very tidy
<teepee>
I guess it still depends on the center hole size, but I'll probably stick to the 50mm for now
<InPhase>
Yeah, there's a bit of an interlocking dependency going on there.
<teepee>
40mm looks nice too
<InPhase>
Probably some clever math could sort that out.
<teepee>
true, but that's also a bit overkill for the use case
<InPhase>
I figured.
<teepee>
tweaking the values a bit seems fine
<InPhase>
I guess it is pretty solid across hole sizes as long as you don't change the pattern number.
<teepee>
there's some time while the base part prints
<InPhase>
5 is much harder to get working.
<Jack22>
try Rosette(20,40,ratio=-6,wall=2);
<teepee>
aha, I looked at that, but could not find a good value combination
<teepee>
the challenge is of course that it has to grab the middle part
<InPhase>
Jack22: ub.scad is broken in 2021.01 from some comma violations.
<Jack22>
again .. happens all the time
<InPhase>
Jack22: I was going to also crack a joke that you should leave some things for the rest of us to implement. ;) But I found another oddity for you. While I don't normally do it this way, and probably you don't either, by random chance I typed $fa=1; $fs=0.4; above the include for ub.scad, and it spit out 866 warnings.
<InPhase>
If I put it below the include, no warnings.
<InPhase>
Of this form: WARNING: $fa too small - clamping to 0.010000 in file ../home/sero/.local/share/OpenSCAD/libraries/ub.scad, line 4957
lastrodamo has quit [Quit: Leaving]
<InPhase>
And when I put it below (but before Rosette), it does not actually get used for Rosette.
<Jack22>
4957 is strange - there is nothing ..
<InPhase>
The other line was 4953.
<Jack22>
Rosette(fn=150);
<InPhase>
It alternates between these two lines a lot.
<Jack22>
these lines are from a triangle module
miique has quit [Read error: Connection reset by peer]
<InPhase>
Is include an acceptable usage mode, or should it always be use?
<Jack22>
2746 and 2744 is what i get
<InPhase>
I get warnings if I don't call Rosette, and just do the $fa/$fs and include, but there are fewer and they're different.
<InPhase>
And the line numbers also don't make sense for those.
<InPhase>
I don't know quite what's happening.
<Jack22>
and there is a circle ($fn=12)
miique has joined #openscad
<InPhase>
$fa=1; $fs=0.4; include <ub.scad> Like, just this.
<InPhase>
It points me to 833 and 835 which are blank.
<Jack22>
oh i got 488 and 489 where $fs=fs and it tells "ignore unknown variable fs
<Jack22>
but as ub.scad sets $fs and $fa to .4 and 1 (hires=true) there is no need to set these - Ü
<InPhase>
Not sure why my line numbers are off on this master build. It's from 2021-12-13. Maybe I need to pull? Did we fix something recently?
<Jack22>
i am using 2021.12.16
<InPhase>
I remember an include line number issue from years back, but that was fixed long ago.
<Jack22>
( fs and fa calculations for rosette would be a pain as this is a circle rotated around another circle around another circle )
<Jack22>
ok this is what i was aiming for Rosette(20,50,ratio=-2.5,wall=3,fn=50);
<Jack22>
InPhase thanks for the coma violation info btw - i never check with 21.01 as it always crashes when closing ( issue is fixed for β21.011 )
<InPhase>
Ah, that last Rosette is very nice.
<teepee>
yep, a bit difficult to control though
<teepee>
at least for the case where I need to give a specific outer and inner diameter
<InPhase>
I do find the parameters a bit mysterious, yes.
<InPhase>
It would be more applicable with some externalized constraints, precalculating these other parameters.
<InPhase>
I changed -2.5 to 2.5 and I got confused. :)
<Jack22>
yes as - would substract from the main rotation and + add to it
<Jack22>
the constraines should be something like 50+20 or 20-50 so either 60 or 70 (+ wall )
<Jack22>
Kreis(30-3/2,rand=.5);
<Jack22>
Kreis(70+3/2,rand=-.5);
<Jack22>
at least i could add this infos as echo
<Jack22>
but with inner and outer diameter r1 and r2 should be calculable
<Jack22>
.. at least for this ratio .. i assume other ratios could require a different calculation
<Jack22>
- no i was wrong all stays nice in that area ..
<Jack22>
(never realy had use for that module - was more a poc as using a polygon fails du to the intersections)