<gbruno>
[github] ChrisCoxArt opened issue #4061 (OpenSCAD crashes on MacOS if a file is opened but the application is denied access to the folder). https://github.com/openscad/openscad/issues/4061
<gbruno>
[github] ChrisCoxArt edited issue #4061 (OpenSCAD crashes on MacOS if a file is opened but the application is denied access to the folder). https://github.com/openscad/openscad/issues/4061
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]
ochafik has joined #openscad
ochafik has quit [Ping timeout: 256 seconds]
<Scopeuk>
havinga look at the actions for the above pull github are about to switch the os image on the windows build chain https://github.com/actions/virtual-environments/issues/4856 so it might be worth keeping a careful eye on if anything goes odd on us over the next couple of weeks, it might not be us
ochafik has joined #openscad
ochafik has quit [Ping timeout: 268 seconds]
ochafik has joined #openscad
ochafik_ has joined #openscad
ochafik has quit [Ping timeout: 240 seconds]
ochafik_ has quit [Remote host closed the connection]
ochafik has joined #openscad
arebil has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik_ has joined #openscad
ochafik has quit [Ping timeout: 268 seconds]
TheAssass1n has joined #openscad
TheAssassin has quit [Ping timeout: 276 seconds]
ochafik_ has quit [Remote host closed the connection]
ochafik has joined #openscad
ochafik_ has joined #openscad
ochafik has quit [Read error: Connection reset by peer]
ochafik has joined #openscad
ochafik_ has quit [Ping timeout: 240 seconds]
TheAssass1n is now known as TheAssassin
<peepsalot>
hrm, not good. for some reason the nightly build is 2x slower than before with mimalloc in there
<peepsalot>
i think its making the debug version of mimalloc, which does some much slower detailed accounting
<peepsalot>
teepee: what script do the ubuntu OBS builds use exactly? do you get a build log from them?
<teepee>
it's probably better to just add the value we want in the rules file (1st link)
<peepsalot>
here's how I can tell it built the full debug version of mimalloc: https://bpa.st/YSGQ first run is AppImage direct from the CI server on my PR, then the nightly from apt repo
<teepee>
we'll know in a couple of minutes
<peepsalot>
that MIMALLOC_SHOW_STATS gives a ton more info, but slows things down pretty badly
<peepsalot>
... i mean, being built with the debug version slow things down badly, not that the presence of that env var slows anything down
<teepee>
you can follow the new build with the log link above :)
<teepee>
still installing the build system
<peepsalot>
i am kind of concerned that debug versions will be unnecessarily slow with mimalloc, not sure if I should add some extra setting to try to avoid that even with a legit Debug build type
<teepee>
[ 527s] -- CMAKE_BUILD_TYPE: Release
<peepsalot>
debug builds aren't expected to be fast, but 2x slowdown from before mimalloc is pretty bad
<teepee>
there's already a disable switch, so should be fine for now
<peepsalot>
ok
<teepee>
hmm, strange, it shows an empty DEFINES line
<teepee>
[ 528s] -- DEFINES =
<teepee>
nope, compile flags look ok, maybe some html confusion
<teepee>
and we have O3 -DNDEBUG
kyki has quit [Quit: Leaving]
<peepsalot>
teepee: do those debian.rules get used for the fedora builds etc too?
ochafik_ has joined #openscad
ochafik has quit [Read error: Connection reset by peer]
<teepee>
ah, which already has -DCMAKE_BUILD_TYPE=RelWithDebInfo
<teepee>
I suppose I should do that in debian too
<InPhase>
peepsalot: There's no point running debug builds anyway unless you are stack tracing something really tricky. For pretty much all other purposes, RelWithDebInfo is better, as then you are testing and debugging the same sort of code you plan to release, with all those optimization bugs possible.
<InPhase>
I've basically excised debug builds from my C++ development workflow except for those exceptional cases where I need to specially make one.
<InPhase>
I didn't specifically measure, but I might go as much as 2 years on average in between intentionally doing a debug build. (Now accidentally doing it, that's far more common.) So I would say no decisions need to ever rest on the performance consequences to a debug build. In the rare cases it's needed, it needs to be as identical as it can get, in case there is actually a debug-build-type problem with
<InPhase>
the allocation.
<InPhase>
teepee: On that line though, NDEBUG needs to not be there for RelWithDebInfo on a nightly. assert should not exist in C++ code, but it's all OVER this code base, so these checks need to run at some point.
<InPhase>
These should probably almost all be exception throws.
<InPhase>
I don't know if a nightly is the right place to do that, but somewhere it needs to happen if people while implementing decided these checks should exist.
<InPhase>
Courtesy of stackoverflow, but not tested.
<InPhase>
Wait, that's MSVC.
<InPhase>
Copy paste fail I guess, but same logic.
<InPhase>
I suppose run that and then run the proper one if we're trying to support MSVC as a target as well.
<teepee>
wait, so you say assert() should *not* be active in the nightly builds?
<teepee>
doesn't that mean we do want to have NDEBUG defined?
<teepee>
peepsalot: looks like it's installing the mimalloc header files which makes the rpm build angry
<teepee>
can we suppress that?
<InPhase>
I'm saying assert should be active somewhere if it exists, but I was also side-ranting that we should purge assert from the codebase and replace it with exceptions to join the 21st century. :)
<InPhase>
Separate issues. But if there are asserts, that code needs to run at some point to make sure we don't trip one of those conditions.
<teepee>
right, I guess that would be the test suite. ideally running that against both debug and release build (not actually sure about all the current setups)
ochafik_ has quit [Remote host closed the connection]
Jack225 has quit [Quit: Client closed]
Jack225 has joined #openscad
<peepsalot>
teepee: installing the header files where? i'm more or less just doing add_subdirectory
Guest8 has joined #openscad
Guest8 has quit [Client Quit]
<peepsalot>
does the rpm build run make install on overall openscad? i'm not very familiar with cmake install stuff, so not sure if that would automatically install subprojects like that
<InPhase>
teepee: The test suite will miss all those gui-based asserts.
<InPhase>
teepee: Tab Manager for example has 11 of them.
<InPhase>
mainwin has one.
<InPhase>
VBO Renderer is gui only too, right? That has 3.
<peepsalot>
pretty sure VBO can run from command line too, for png preview export
<InPhase>
Although maybe just those 15 asserts could be converted to exceptions as a low inertia start. Nothing there has anything to do with performance, and choosing assert was premature optimization. The VBO cases for example are assert(false), so the check is already performed.
<InPhase>
peepsalot: Ok.
<teepee>
peepsalot: yes, I think both build variants do make install, but the debian tools might be a bit more relaxed with extra files
<peepsalot>
wow those builds take some time eh? still going on the xubuntu 20.04
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<teepee>
yeah, it's a huge amount of parallel builds going on always, so I guess it's taking a bit of time for each build
<teepee>
not sure if I specified the -j1 somewhere but I also want to be a bit polite to the system
<teepee>
that is 42 parallel builds every checkin triggers
<peepsalot>
i think that would exclude it from "make install", but also just plain "make", so i don't quite understand the purpose
stonkey has quit [Read error: Connection reset by peer]
ochafik has joined #openscad
<teepee>
sounds like it's meant for IDEs for explicit build
<peepsalot>
i was just testing it out, and i think that EXCLUDE_FROM_ALL is the right way to do it. it builds fine, and the resulting cmake_install.cmake file no longer does include("[...]/submodules/mimalloc/cmake_install.cmake")
<peepsalot>
the cmake docs are just too cryptic to me
<teepee>
ah, cool
<teepee>
yeah, I've read that part of the docs and it did not sound like it would work this way
<teepee>
but good if it is I suppose :)
<peepsalot>
should I make it a PR or just commit straight to master?
ochafik has quit [Remote host closed the connection]
<teepee>
hmm, maybe PR is still useful in case some of the older platforms could cause build problems?
<teepee>
we still build back to 18.04 :)
<teepee>
which can be annoying in that respect
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<teepee>
the build-type change is certainly effective, menger sponge (example 024) before 65 seconds, now 40
<teepee>
I've switched to RelWithDebInfo for the debian builds too, I hope that's going to produce the same result
arebil has joined #openscad
ochafik has joined #openscad
ochafik has quit [Remote host closed the connection]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
<peepsalot>
teepee: no complaints from build servers :)
<teepee>
cool, OBS is updated, so we should be back to green with Release mode soon(-ish)
snaked has joined #openscad
stonkey has quit [Remote host closed the connection]
fmlatghor has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
la1yv has quit [Remote host closed the connection]
la1yv has joined #openscad
Guest2731 has joined #openscad
<teepee>
nice, some builds are still running, but looks quite green all over the place already
<teepee>
oi!
Guest2731 has quit [Client Quit]
<teepee>
5 seconds after typing that, a failure mail came in :)
<teepee>
but, I think we are not going to count that one: [ 348s] qemu-system-aarch64: terminating on signal 15 from pid 51009 ()
snaked has quit [Quit: Leaving]
snaked has joined #openscad
snaked has quit [Client Quit]
<JakeSays>
i want a cnc machine
<ccox_>
Do you have a lot of space and like living with fine dust and swarf everywhere? If not, then you do not want a CNC machine. (they are great when they work, but need more maintenance than most 3D printers, and make a MESS)
<JakeSays>
it's worth the pain
<teepee>
I want a laser cutter :)
<ccox_>
Unless, of course, you have the money and space for a Tormach machine with it's own enclosure.
<teepee>
true, or a workshop shed around the corner
<JakeSays>
i have a whole garage that i can fill
<ccox_>
Sadly, I have a garage that is filled.
<ccox_>
(and a living room, and a dining room overflowing with tech)
<teepee>
if I'd had a garage, it would be filled too :D
<JakeSays>
i also have three empty bedrooms
<teepee>
works out nicely in addtion to the cnc in the garage: 1) 3d printers 2) laser cutter 3) soldering/workplace