califax has quit [Remote host closed the connection]
califax has joined #openscad
LordOfBikes has quit [Ping timeout: 252 seconds]
Jack21 has quit [Ping timeout: 256 seconds]
LordOfBikes has joined #openscad
<InPhase>
Aww crap, windows strikes again.
<InPhase>
*sigh* Apparently the standard system() error handling is not supported in our Windows build...
Guest6294 has joined #openscad
Guest6294 has quit [Client Quit]
califax- has joined #openscad
<dalias>
?
<dalias>
system() is a really bad idea to call, ever
<InPhase>
I didn't do it.
califax has quit [Ping timeout: 276 seconds]
califax- is now known as califax
<dalias>
it's thread-unsafe and has unwanted side effects on the process (poking at signal dispositions etc.)
<InPhase>
Although in this case it actually makes sense, because this is basically an integrated Makefile step for command-line calls.
<dalias>
in addition to safety issues with constructing the command line
<InPhase>
It is one of the really old command line options, -m make_cmd, where for example if the scad file depends on special.png and that special.png is not present, it runs system("make_cmd 'special.png'");
<InPhase>
I don't really know why this was implemented long ago, but it's there. I also security-checked it, and it's fine for that workflow.
<dalias>
it's not
<dalias>
unless it has escaping code for the filename
<dalias>
for example
<dalias>
foo'& rm -rf / '.png
<InPhase>
It does.
<InPhase>
I checked that carefully.
<dalias>
replacing all ' with '\'' or something ?
<InPhase>
Correct.
<dalias>
what about newlines?
<dalias>
actually they're ok in ''
<dalias>
so nm
<dalias>
in that case it's probably safe. not a very good way to do it, but not catastophic
<InPhase>
Should be fine, but I'll explicitly test that as well.
<InPhase>
Yeah, would not have been my approach. My goal was simply to fix that there has never been error handling on the system call return value.
<InPhase>
And it's yelling at us with warnings. Which is fair.
<dalias>
i'd still prefer posix_spawn, fork+exec, or whatever cross-platform wrapper (Qt?) has for that
<InPhase>
Yeah. It would just require careful thought about what that changes. If people are using this at all, it would be part of some automated systems, which might count on certain properties of how system launches in a shell, or environment-specific things that get passed along wildly to system().
<InPhase>
So I didn't want to break a usage pattern just to fix up a warning, since it does appear securely locked down. The command to run is provided directly on the command line, so it's equivalent to running it from the same command line.
<InPhase>
A different approach would have been nicer if starting from scratch.
<InPhase>
For an example of its wild behavior, it does not put quotes around the "make_cmd" provided.
<InPhase>
So you can do things like: -m "echo Hi there" and it will print out: Hi there /the/missingfile.png
<InPhase>
This is ridiculous, but might be in use as things like -m "/usr/bin/python3 somefile.py"
<InPhase>
So it's tricky to not break once it's in place. :)
<InPhase>
Anybody doing: -m "My Command.exe" would have it break, but they would have already noticed the problem and adjusted for this. But you can't fix that without breaking the other usage example.
<InPhase>
Honestly, what happened to me is I thought, "Why is this warning still here? How hard can it be to check a return value?" Then I discovered it was a bit of a design mess... So, I am trying to resolve it without breaking it.
drew has quit [Read error: Connection reset by peer]
drew has quit [Read error: Connection reset by peer]
drew has joined #openscad
ferdna has joined #openscad
drew has quit [Read error: Connection reset by peer]
drew` has joined #openscad
drew` is now known as drew
Teslamax has joined #openscad
Teslamax_ has joined #openscad
linext__ has joined #openscad
Scopeuk9 has joined #openscad
obriencj has joined #openscad
la1yv_a has joined #openscad
Teslamax has quit [*.net *.split]
TheCoffeMaker has quit [*.net *.split]
linext_ has quit [*.net *.split]
Scopeuk has quit [*.net *.split]
siege has quit [*.net *.split]
gbruno has quit [*.net *.split]
gbruno_ has joined #openscad
gbruno_ is now known as gbruno
linext has joined #openscad
Scopeuk has joined #openscad
L29Ah has quit [Ping timeout: 252 seconds]
Scopeuk9 has quit [Quit: Ping timeout (120 seconds)]
Teslamax_ has quit [Ping timeout: 252 seconds]
linext__ has quit [Ping timeout: 252 seconds]
little_blossom has quit [Ping timeout: 252 seconds]
la1yv_b has quit [Read error: Connection reset by peer]
TheCoffeMaker has joined #openscad
little_blossom has joined #openscad
Teslamax has joined #openscad
peeps[zen] has joined #openscad
peepsalot has quit [Read error: Connection reset by peer]
snakedGT has joined #openscad
berndj-blackout has joined #openscad
EkpyroticFrood8 has joined #openscad
berndj has quit [Ping timeout: 252 seconds]
knielsen_ has quit [Ping timeout: 252 seconds]
snaked has quit [Ping timeout: 252 seconds]
kanzure has quit [Ping timeout: 252 seconds]
EkpyroticFrood has quit [Read error: Connection reset by peer]
EkpyroticFrood8 is now known as EkpyroticFrood
kanzure has joined #openscad
knielsen has joined #openscad
Zauberfisch has quit [Ping timeout: 252 seconds]
Zauberfisch has joined #openscad
berndj-blackout is now known as berndj
noonien4 has joined #openscad
noonien has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 252 seconds]
noonien4 is now known as noonien
pie_ has joined #openscad
Alexer- has quit [Ping timeout: 252 seconds]
Alexer has joined #openscad
Scopeuk has quit [Quit: Ping timeout (120 seconds)]
TheCoffeMaker has quit [Ping timeout: 252 seconds]
Azelphur has quit [Ping timeout: 252 seconds]
Scopeuk has joined #openscad
TheCoffeMaker has joined #openscad
Azelphur has joined #openscad
milkandtang has joined #openscad
fardog has quit [Ping timeout: 252 seconds]
arebil has joined #openscad
ur5us has joined #openscad
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
ferdna has quit [Quit: Leaving]
ur5us has quit [Ping timeout: 260 seconds]
L29Ah has joined #openscad
LordOfBikes has quit [Remote host closed the connection]
LordOfBikes has joined #openscad
<JakeSays>
why is cgal so slow at rendering?
<teepee>
because it's trying to be perfect
<JakeSays>
can it not take advantage of multiple cores and/or a gpu?
<teepee>
it could not in the past, I'm not sure if that changed
<teepee>
there's some opportunity from openscad side, but that's a bit of work and so far nobody managed to get things to the end
arebil has joined #openscad
<InPhase>
JakeSays: The last I looked (within a year maybe?), multithreaded processing for CGAL was under active development and looked like it might be close. But from experience with the CGAL library that is not a library to ride really close to the cutting edge on. But it means, soon.
<InPhase>
The corefinement updates (we have a PR) appear that they will do more for performance than multithreading though. There just needs to be some more work done on that to handle edge cases.
<dalias>
more like because it's C++ template hell
<dalias>
if it were designed around good data representations rather than abstracting to support arbitrary representations via templates, it would likely be a lot faster
<InPhase>
Templates don't usually slow things down, they usually speed things up as a zero-cost abstraction feature.
<dalias>
leaving aside the general reasons that's wrong.. :)
<dalias>
here what i meant is not that templates slow it down vs "doing the same thing without templates"
<dalias>
what i meant is that code that's data representation agnostic tends to be a lot slower than code working with a known representation designed to be efficient to work with
<dalias>
i haven't dug into CGAL myself but my understanding, from ppl i spoke to in the past who worked with it, is that it's designed specifically so that you can easily integrate it with whatever data representations you're using, at the cost of having to be a lot more abstract than it otherwise would need to be
<InPhase>
Jelbert: That forf function was my attempt to design a streamlined imperative-like way to do it. It relies on the fact that C-style for loops will update values iteratively in the third for loop slot. Although recursive functions are the more standard way to write this sort of thing.
califax has quit [Remote host closed the connection]
califax has joined #openscad
<InPhase>
Jelbert: The forf design logic is to focus on an updated state vector, taking three function literals: The first generates the initialized vector, the second performs the conditional check for termination, and the third updates the vector. Then it returns the final vector at the end. So all you have to decide then is what to change in the vector.
<InPhase>
That test example is doing fibonacci iteratively.
<teepee>
InPhase: I'll try to catch up with your messages later today, too many distractions the last days :)
califax has quit [Remote host closed the connection]
<gbruno>
[github] ChrisCoxArt opened issue #3917 (MacOS CI builds are showing success, despite dependencies being unavailable (Qt 5.9.9 missing)). https://github.com/openscad/openscad/issues/3917
<InPhase>
Oh, macs...
<teepee>
does that only sound rude to me what's written in those tickets?
<teepee>
also "no longer available" is obviously wrong, they just have moved it to a different folder, not sure that's something we should be blamed for :(
ferdna has quit [Quit: Leaving]
<JakeSays>
InPhase: ah there's hope then:) cool
ur5us has joined #openscad
<Scopeuk>
teepee its not just you he comes across rather entitled and cocky
<Scopeuk>
And complaing that you didn't say i needed to update my respo when the changes are on a pr shows a lack of understanding how git works
<teepee>
Interesting argument tho, if the demand is we always need to build test Qt, where does it stop? Do we need to build Debian distro from scratch? The Linux Kernel? The BIOS?
<teepee>
I guess we could have some download validation, but doing the builds is just not possible on macOS at least
<Scopeuk>
Essentially we know there is a blind spot on osx limited by access to hardware to build and test, much the same driver behind not generating m1 builds
<Scopeuk>
It is a shame qt is so large to build which makes it prohibitive
<teepee>
well, partially, that lacks someone to set it up, if we get the M1 dependencies built, it would hopefully be fine
<teepee>
I have no idea how much time it takes to do a fat binary with both x86 and M1 builds for OpenSCAD only
<teepee>
I would assume less than 2x, so that would barely be possible but still doable
<teepee>
but someone needs to setup all the external builds with the M1 flags first
<Scopeuk>
It seams largely that he wanted to declare a problem and have someone declare him an eminent in field expert and jump to fixing it. (This comment may contain some poetic licence)
<teepee>
:)
<Scopeuk>
Esentially osx needs someone to adopt it
<Scopeuk>
And that needs to be someone on osx who wants to develop and use to really get and maintain the build
<teepee>
at some point I may try to get the macbook working without a battery - big question, will all the screws still be there and all the parts fit where they need to go
<Scopeuk>
I've not had one appart myself but an old house ate swapped a hdd in.a 2005 and the screws my goodness it was madness
<teepee>
I need to get the batteries out as they are puffed up which caused the normal operation to fail
<teepee>
obviously it's apple so they are glued in :(
<teepee>
also, lol, now I'm being reminded of the community guidelines, very funny :/
califax has quit [Remote host closed the connection]
califax has joined #openscad
<Scopeuk>
Yeh i saw that. Wasn't impressed but decided to let it lie. What i didn't check was if they stated just becouse something is your opinion does not immediately make it fact or above challenge or discord. I shouldn't have but looked at other issues he has posted. His opinion being absolute and correct is a recurring theme. Thats style of feedback
<Scopeuk>
might work in a corporate environment where you have seniority (although i personally consider it toxic) but with collaborative development you have to listen and take criticism as many things are in part opinion and subject to differentiation between people
<Scopeuk>
To give the benifit of the doubt perhaps considerable effort and time was expended before discovering the break and we are seeing frustration written
<Scopeuk>
Time will clarify that one way or the other
<teepee>
yep
<teepee>
and I totally agree with that happening in corporate, but it's not something I would want to see either
<peepsalot>
teepee: his attitude/tone have been combative and disrespectful from the start. that community guidelines link is ironic and seems like he's projecting (psychology) to me. i thought about tearing into him in some comments a few times but it probably wouldn't be productive.
<peepsalot>
respect is a 2-way street imo
<InPhase>
teepee: I think that falls under "I found the Arch user." ;)
<InPhase>
teepee: I tried a response, polite but with firm pushback on that mindset.
<teepee>
peepsalot: yeah, I don't think that would help, it's likely to just escalate which is not useful
<teepee>
I suppose the polite pushback once and then just ignoring that part is the best option
<InPhase>
lol. I just found the "a misinformed developer" about teepee.
<teepee>
if it still goes on, there's always the block button ;-)
<teepee>
at least the build now works or at least goes further
<InPhase>
Yeah. Some people just show up after screaming at their computer for a while and they don't recognize the helping humans on the other end before posting.
<teepee>
it really just was that Qt decided to move the older version to "archive" which is slightly annoying but not a huge deal in the end
<InPhase>
teepee: Do you mind if I delete his last comment on #3916? I would do this on any other moderated forum.
<InPhase>
Good human-checking policy says a person involved in an argument should not do a deletion, but I'm not involved there, and I think it should go.
<InPhase>
I've never had to delete anything on github before, but that seems unfruitfully escalated in tone.
<teepee>
I don't mind either way, as the version is not actually gone, just moved and the script seems to work now this ticket could probably be closed anyway
<InPhase>
I added those to the manual after having to explain it a bunch of times. :)
<JakeSays>
hmm.
<JakeSays>
would not being manifold impact rendering performance?
<JakeSays>
ah. i use epsilon everywhere.
<JakeSays>
apparently not everywhere though
<InPhase>
Yes, overlap issues can substantially slow down the render sometimes.
<InPhase>
Sometimes you get lucky and it just works, which causes a lot of forgetting about it.
<JakeSays>
hmm. i have a rotate_extrude circle that is supposed to touch connect with a cylinder to form a bent tube. that might be it.
<InPhase>
That can do it. On rotate_extrude note also that you are not permitted to touch the y-axis with a single point, nor cross the y-axis.
<InPhase>
You must either not intersect the y-axis, or touch it with a non-zero width.
<InPhase>
Actually, I wonder if anyone added that to the manual...
<JakeSays>
it's based on code i found on the site. iirc an example that makes a hook
<InPhase>
Ah yes, that's correctly described there.
<JakeSays>
so that hook example - it looks like it intersects the y axis
<JakeSays>
so i'm not entirely sure what 'intersect the y-axis' means in this context
<JakeSays>
if i remove one of the translates before the circle() i get an error about x-axis sign mismatch. i assume that's the cross the y axis error?
<InPhase>
Oof. So the hook example is an invalid example.
<InPhase>
Not because of anything to do with the y-axis, but because it does not overlap.
<InPhase>
How shameful for our ancestors that we have an invalid example in the manual...
<JakeSays>
lol but i dont think it's supposed to be an example of what doesn't work
<InPhase>
Note that the above fails to render. But this one DOES render. https://bpa.st/VJ6A This is a sort of quick test I do for overlap failures. You trigger the failure by introducing an irrational number.
ur5us has quit [Ping timeout: 252 seconds]
<InPhase>
What it basically means is that it can look like it's working, until you make some adjustments, or move it around in a specific manner, or the piece rendering gets reorganized by something like a lazy union in the process, and then it fails.
<peepsalot>
i think our biggest issue right now with non-manifold geometry stems from the grid snapping and removal of vertices, which tends to result in "T" edges
<InPhase>
It just happens to be easy to trigger those failures with rotate by 17 degrees.
<JakeSays>
what does the rotate do to cause it to trigger?
<JakeSays>
to me it looks like it's affecting the y-axis in a similar way as the original hook
<InPhase>
JakeSays: After rotating, the coordinates for the intersecting planes are no longer axis aligned, but in fact all have coordinates which are irrational numbers, which are impossible to represent finitely as floats or fractions. That in turn means that the intersecting plane cannot be exactly represented correctly as an exactly intersecting plane, and so it becomes mathematically impossible for the
<InPhase>
library to figure out what's inside or outside.
<JakeSays>
ah ok
<InPhase>
Which is a heavy thing to be happening after a rotate. :)
<JakeSays>
so would it be enough to shift everything to the right along the x axis?
<InPhase>
Yes.
<InPhase>
JakeSays: I plan to update the library with this. Two eps's are needed. https://bpa.st/CU4A
<InPhase>
JakeSays: In practice I just throw in some 0.01's usually, but I've been putting "eps" in the manual so people can find them and interpret them in the examples.
<InPhase>
s/update the library/update the manual/
ferdna has joined #openscad
<InPhase>
Not "everything" to the right, but the one piece.
<InPhase>
I did not do this fix right.
<InPhase>
I'm feeling a little tired... This should not be hard.
<JakeSays>
heh. shifting the whole model to the right fixed it. now the imported stl renders
<JakeSays>
which is good enough for now. i'll fix the root cause later
<JakeSays>
InPhase: hey thanks for your help:)
<JakeSays>
i'm hoping that by importing stls in to a larger model will speed up the larger model's rendering time