00:00
dalias has joined #openscad
00:08
dalias has quit [Ping timeout: 256 seconds]
00:23
kintel has joined #openscad
00:33
snaked has joined #openscad
02:23
<
kintel >
Has anyone built on Windows/msys2 lately and found the build to be really slow?
02:24
<
InPhase >
JordanBrown_? You're a frequent msys2 builder, right?
02:28
<
pca006132 >
iirc gcc is slower than clang and uses more memory
02:30
<
kintel >
I could try clang, but since this is Windows it will likely turn into a 2-week wild goose chase : /
02:30
<
kintel >
It's weird though, the CI is faster than building on a modern 10-core CPU
02:31
<
pca006132 >
are you using a VM?
02:31
<
pca006132 >
and what is the memory usage? is it using a swap/compressing RAM?
02:32
<
pca006132 >
gcc is a bit slower but it should not be much slower...
02:33
<
kintel >
ssh'ing into the actual machine, got 128GB RAM. Should be very fast
02:36
<
kintel >
yeah, I haven't booted this machine into Windows in months, but I cannot remember it being this bad. Perhaps go through the regular dance of reinstalling
02:38
<
pca006132 >
maybe it is doing some windows updates (TM) in the background?
02:38
<
pca006132 >
+ antivirus checking
02:39
mmu_man has quit [Ping timeout: 255 seconds]
02:39
<
pca006132 >
not sure if there is a way to disable the antivirus with command line
02:58
LordOfBikes has quit [Ping timeout: 256 seconds]
02:59
dalias has joined #openscad
03:03
<
kintel >
Good idea will try. ..but it feels like some msys2 libraries are causing issues. It took 30 minutes to link openscad.exe, and it failed with hundreds of CGAL missing symbol errors
03:08
dalias has quit [Ping timeout: 255 seconds]
03:10
LordOfBikes has joined #openscad
03:21
<
kintel >
Unrelated to my build issues: Has anyone noticed dumptest_rotate_extrude-tests being flaky on Windows on the GitHub CI?
03:29
<
teepee >
no, I have not noticed that
03:45
teepee_ has joined #openscad
03:48
teepee has quit [Ping timeout: 240 seconds]
03:48
teepee_ is now known as teepee
04:21
guerd87 has quit [Remote host closed the connection]
04:21
guerd87 has joined #openscad
04:28
J23k15 has joined #openscad
04:32
J23k62 has quit [Ping timeout: 250 seconds]
04:56
zauberfisch_ has quit [Quit: No Ping reply in 180 seconds.]
04:57
zauberfisch has joined #openscad
05:24
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
05:35
foul_owl has quit [Ping timeout: 268 seconds]
05:36
TheAssassin has quit [Remote host closed the connection]
05:36
TheAssassin has joined #openscad
05:48
foul_owl has joined #openscad
06:03
dalias has joined #openscad
06:12
dalias has quit [Ping timeout: 256 seconds]
06:58
guso78k has joined #openscad
07:28
dalias has joined #openscad
07:48
<
guso78k >
@kintel any idea, which part of openscad is not functioning ?
07:53
arebil has quit [Quit: arebil]
08:00
dalias has quit [Ping timeout: 276 seconds]
08:15
<
pca006132 >
looks like something related to stl
08:29
<
guso78k >
I believe its a CGAL bug which was fixed before and is back now ...
08:36
GNUmoon has quit [Remote host closed the connection]
08:36
GNUmoon has joined #openscad
08:48
arebil has joined #openscad
08:53
<
guso78k >
when allocating an array of 0 elements probably its an error in windows whereas its not in linux ?
09:04
<
pca006132 >
well it is undefined behavior
09:14
pca006132 has quit [Remote host closed the connection]
09:25
pca006132 has joined #openscad
09:28
dalias has joined #openscad
09:46
misterfish has joined #openscad
10:03
dalias has quit [Ping timeout: 268 seconds]
10:14
misterfish has quit [Ping timeout: 276 seconds]
10:30
misterfish has joined #openscad
10:33
mmu_man has joined #openscad
11:19
guso78k has quit [Quit: Client closed]
11:23
mmu_man has quit [Ping timeout: 252 seconds]
11:27
J23k15 has quit [Quit: Client closed]
11:28
J23k15 has joined #openscad
11:28
pca006132 has quit [Remote host closed the connection]
11:28
pca006132 has joined #openscad
11:39
mmu_man has joined #openscad
11:41
dalias has joined #openscad
11:59
dalias has quit [Ping timeout: 260 seconds]
12:00
dalias has joined #openscad
12:11
dalias has quit [Ping timeout: 256 seconds]
12:23
dalias has joined #openscad
12:43
dalias has quit [Ping timeout: 252 seconds]
12:56
misterfish has quit [Ping timeout: 252 seconds]
13:01
dalias has joined #openscad
13:08
pca006132 has quit [Remote host closed the connection]
13:08
pca006132 has joined #openscad
13:14
misterfish has joined #openscad
13:14
<
teepee >
pca006132: I sent you an invite from github. I think the branch logic only works if the acatual branch is in the repo itself, not in the forked repo via PR
13:14
little_blossom has quit [Quit: little_blossom]
13:15
<
teepee >
that me pretending to undertstand the gitub access controls ;-)
13:17
dalias has quit [Ping timeout: 276 seconds]
13:22
little_blossom has joined #openscad
13:27
<
pca006132 >
make sense, otherwise people can just open PRs with the specific branch name
13:37
pca006132 has quit [Remote host closed the connection]
13:41
pca006132 has joined #openscad
13:46
dalias has joined #openscad
14:08
dalias has quit [Ping timeout: 268 seconds]
14:12
dalias has joined #openscad
14:12
kintel has joined #openscad
14:15
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:18
dalias has quit [Ping timeout: 264 seconds]
14:25
mmu_man has quit [Ping timeout: 260 seconds]
14:30
kintel has joined #openscad
14:31
Guest27 has joined #openscad
14:33
Guest27 has quit [Client Quit]
14:34
<
kintel >
guso78 Did you find the cause of the bad allocation?
14:40
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:00
mmu_man has joined #openscad
15:07
guso78k has joined #openscad
15:09
<
guso78k >
kintel sorry, i dont know. all my trials to catch bad stuff in linux which might happen in the MXE build did not come true. I wished openscad would output a stacktrace ....
15:10
<
guso78k >
I could yet try to manually run the built mxe-openscad and try one of the failed tests manually ?
15:15
<
teepee >
I don't know yet how do do a full debug build in MXE, but I guess we could try with OpenSCAD debug and if that breakpad stuff compiles there
15:18
<
pca006132 >
I think you should build it with CMAKE_BUILD_TYPE=RelWithDebInfo or Debug
15:18
<
pca006132 >
otherwise even if you have a stacktrace it will be useless
15:19
<
pca006132 >
you can probably use gdb on msys2 to debug the MXE build? not sure about that.
15:29
<
guso78k >
teepee, there are very few code lines necessary to activate breakpad. i have created a small of it.
15:29
<
teepee >
well, activate is one thing, we first have to get it to compile too
15:29
<
guso78k >
i think main effort to get this running is compile break[ad lib for MXE, right
15:30
<
teepee >
with some luck its as easy as the new tbb version, but hard to tell upfront
15:30
<
guso78k >
in general i believe many people not only me would benefit from detailed stacktrace ...
15:36
<
teepee >
yes, it's still going to be limited if only the openscad code is compiled in debug mode
15:36
<
teepee >
so it depends on the actual case if it's going to help or just list empty stack frames
15:38
<
pca006132 >
RelWithDebInfo works
15:39
<
pca006132 >
btw I now have some time and can help look into the windows crash
15:39
<
guso78k >
pca006132 this is great
15:40
<
guso78k >
let me know if i could tell you some required info ...
15:40
<
pca006132 >
installing windows on VM now...
15:40
teepee_ has joined #openscad
15:41
teepee has quit [Ping timeout: 240 seconds]
15:41
teepee_ is now known as teepee
16:00
guso78k has quit [Quit: Client closed]
16:05
dalias has joined #openscad
16:05
kintel has joined #openscad
16:07
guso78k has joined #openscad
16:07
<
guso78k >
teepee, the windows binary which crashed is from MXE or from MSYS ?
16:08
<
kintel >
guso78k If it crashes on the CI, it's msys
16:08
<
kintel >
If you have access to a Windows machine or VM you could try building and testing on msys to make iterations faster
16:09
<
guso78k >
yeahh, but then we need to focus on MSYS, i once compiled the index in MSYS and could not reproduce the crash
16:09
<
guso78k >
probably did i did not use exact sam,e settings
16:09
<
guso78k >
how can i download the actual recent msys binary which created the crash ?
16:10
<
kintel >
You can't right now - we don't export the binary as an artifact
16:11
<
guso78k >
kintel can you supply me with a copy /download link ?
16:12
<
guso78k >
general question: do we actually improve test coverage when we test an msys binary which is mainly used by jordan ?
16:14
<
kintel >
guso78k To run locally you'd need to install msys first
16:15
<
kintel >
..in which case it's a much better approach to reproduce the build than trying to run binaries, IMO
16:15
<
guso78k >
i use msys sometime, so i have that installed
16:15
<
kintel >
Jordan just happens to be our biggest Windows user. We really need more people who know about Windows : /
16:16
<
guso78k >
yeah, but when i compiled my indexed2 in msys2 then, i did not see the crash even when using the 3 main debugging guards
16:17
<
guso78k >
probably was using wrong cmake options. can someone send me definite cmake options for msys build to get same binary as in the CI ?
16:17
<
kintel >
That should show you how the binary was built
16:18
<
pca006132 >
cmake .. -G"Ninja" -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DEXPERIMENTAL=ON -DSNAPSHOT=ON
16:18
<
guso78k >
yes i see it now in the windows.yml,. thx
16:19
<
pca006132 >
I tried building with RelWithDebInfo but it failed with some weird linker error
16:20
<
pca006132 >
missing symbols to some CGAL stuff
16:20
<
kintel >
It would be awesome if we had a way of reproducing the CI setup!
16:21
<
kintel >
pca006132 I got tons of CGAL error too, when trying a Windows build yesterday.
16:21
<
kintel >
Perhaps there's a discrepancy between our msys2 packages and the ones available on the CI?
16:21
<
pca006132 >
probably not, iirc the release build works
16:21
<
pca006132 >
let me check, it is slowly building
16:22
<
kintel >
I only tried without setting -DCMAKE_BUILD_TYPE
16:22
<
pca006132 >
what is the default build type for openscad? Debug?
16:22
<
pca006132 >
because there is some ancient symbol number limit on windows
16:22
<
guso78k >
cmake in my msys2 succeeded but make does not find a Makefile ?
16:22
<
pca006132 >
65536 or something
16:22
<
pca006132 >
I think it use ninja?
16:23
<
peeps >
cmake build type is undefined by defult
16:23
<
kintel >
and ninja is default on msys
16:23
<
kintel >
..but that's all configurable with cmake -G
16:23
<
guso78k >
ahh ninja
16:23
<
guso78k >
how can i start the compilatrion process with ninja ?
16:23
<
kintel >
In theory, ninja should automatically use the best amount of CPU
16:24
<
kintel >
just type ninja
16:24
<
pca006132 >
just call ninja
16:24
<
pca006132 >
if you do not have enough RAM, limit the number of jobs by $ ninja -jN
16:24
<
peeps >
i got around the symbol limit and file size issue on MXE Debug build by adding compile flag in CMakeLists -Og (debug level optimization)
16:24
<
kintel >
^ yes. ninja will probably do -j20 or equivalent if it can
16:25
<
guso78k >
hmm, some errors found in clipper lib, but its still continuing ...
16:25
<
pca006132 >
interesting
16:25
<
pca006132 >
never tried -Og before
16:26
<
pca006132 >
I will soon stop
16:26
<
pca006132 >
are you using clang or gcc? what is the gcc version?
16:26
<
pca006132 >
I remember I got clang compilation error with clipper on msys2
16:26
<
peeps >
that was using the mxe setup which was on gcc11, now its on gcc13 i think
16:26
<
pca006132 >
sorry I mean guso78k
16:27
<
pca006132 >
the clipper lib compiler error
16:28
<
guso78k >
setting up workspace again cleanly
16:29
dalias has quit [Ping timeout: 255 seconds]
16:31
<
guso78k >
using gcc 13.2.0
16:33
<
pca006132 >
can you post the clipper compilation error?
16:33
<
guso78k >
sorry with new setup i have problems even before
16:33
<
guso78k >
[0/2] Re-checking globbed directories...
16:33
<
guso78k >
[17/278] Building CXX object submodules/manifold/src/manifold/CMakeFiles/manifold.dir/src/properties.cpp.obj
16:33
<
guso78k >
FAILED: submodules/manifold/src/manifold/CMakeFiles/manifold.dir/src/properties.cpp.obj
16:33
<
guso78k >
C:\msys64\mingw64\bin\c++.exe -DLIB3MF_API_2 -IC:/msys64/home/guenther.sohler/openscad/build/submodules/manifold/src/manifold -IC:/msys64/home/guenther.sohler/openscad/
16:33
<
guso78k >
submodules/manifold/src/manifold -IC:/msys64/home/guenther.sohler/openscad/submodules/manifold/src/manifold/include -IC:/msys64/home/guenther.sohler/openscad/submodules
16:33
<
guso78k >
encies/libcudacxx/include -IC:/msys64/home/guenther.sohler/openscad/build/_deps/glm-src/glm/.. -IC:/msys64/home/guenther.sohler/openscad/submodules/manifold/src/cross_s
16:33
<
guso78k >
ection/include -IC:/msys64/home/guenther.sohler/openscad/submodules/manifold/src/third_party/clipper2/CPP/Clipper2Lib/include -IC:/msys64/home/guenther.sohler/openscad/
16:33
<
guso78k >
submodules/manifold/src/collider/include -IC:/msys64/home/guenther.sohler/openscad/submodules/manifold/src/polygon/include -IC:/msys64/home/guenther.sohler/openscad/sub
16:34
<
guso78k >
modules/manifold/src/third_party/quickhull -frounding-math -Wno-attributes -O3 -DNDEBUG -Werror -Wall -Wno-sign-compare -Wno-unused -Wno-array-bounds -Wno-stringop-over
16:34
<
guso78k >
flow -O3 "-DMANIFOLD_PAR='T'" -DTHRUST_DEVICE_SYSTEM=THRUST_DEVICE_SYSTEM_TBB -MD -MT submodules/manifold/src/manifold/CMakeFiles/manifold.dir/src/properties.cpp.obj -M
16:34
<
guso78k >
F submodules\manifold\src\manifold\CMakeFiles\manifold.dir\src\properties.cpp.obj.d -o submodules/manifold/src/manifold/CMakeFiles/manifold.dir/src/properties.cpp.obj -
16:34
<
guso78k >
c C:/msys64/home/guenther.sohler/openscad/submodules/manifold/src/manifold/src/properties.cpp
16:34
<
guso78k >
cc1plus.exe: out of memory allocating 65536 bytes
16:34
<
guso78k >
[18/278] Building CXX object submodules/manifold/src/manifold/CMakeFiles/manifold.dir/src/boolean_result.cpp.obj
16:34
<
guso78k >
FAILED: submodules/manifold/src/manifold/CMakeFiles/manifold.dir/src/boolean_result.cpp.obj
16:34
<
guso78k >
i think the problem is the 64kB
16:34
mmu_man has quit [Ping timeout: 256 seconds]
16:34
<
guso78k >
sorry, need to leave now, driving home
16:35
<
kintel >
sounds like a memory bound VM -> ninja -j1
16:35
<
pca006132 >
never saw this happen
16:42
guso78k has quit [Ping timeout: 250 seconds]
16:52
misterfish has quit [Ping timeout: 264 seconds]
17:12
<
pca006132 >
OK I found the cause of the bad allocation, at least bad-stl-tardis somehow cause OOM
17:15
<
pca006132 >
I guess there is something wrong with the stl import or conversion to nef polyhedra? idk
17:19
<
kintel >
pca006132 This is the OOM in the indexed polyset branch, right?
17:21
<
pca006132 >
but I am not entirely sure how I triggered it... was using the GUI
17:21
<
pca006132 >
unable to trigger it with cmd
17:21
<
pca006132 >
let me try harder
17:22
<
kintel >
The tricky piece of the changed code is the quantization + removal of degenerate polygons
17:22
<
kintel >
..which we could probably kill if using Manifold?
17:23
<
kintel >
There were some potentially simpler test cases failing too
17:23
<
pca006132 >
ah it is not OOM, just heap corruption
17:23
<
pca006132 >
let me try to build a debug build with -Og
17:24
<
kintel >
e.g. cgalstlcgalpngtest_issue13c
17:26
<
pca006132 >
yes, got a bad alloc error as well
17:32
<
kintel >
Perhaps bit the bullet and rewrite that function, even though it's hard to understand :)
17:34
<
pca006132 >
it failed at the second run of export_import_pngtest.py
17:34
<
kintel >
makes sense; it exports to STL and re-imports it
17:35
<
kintel >
..so my guess is it exported a degenerate triangle
17:36
<
kintel >
pca006132 oh, btw., I wanted to ask you something a bit unrelated:
17:36
<
kintel >
I was playing around with the new manifold triangulator
17:37
<
kintel >
..and it seems to work great, even with very complex polygons with holes etc.
17:37
<
kintel >
However, one of our use-cases is this:
17:38
<
kintel >
Take a polygon, triangulate it into a set of outlines
17:38
<
kintel >
..then feed these outlines back into the triangulator (as a set of outlines)
17:39
<
kintel >
If I do this with manifold, the triangulator explodes (doesn't crash, but generates a spectacular mess of triangles)
17:39
<
kintel >
Does that sound familiar?
17:41
<
pca006132 >
it depends on which kind of mess I guess
17:42
<
pca006132 >
we have many failure cases :)
17:42
<
pca006132 >
feel free to open an issue about this
17:43
<
kintel >
I'll ask you again next time I try. It's a bit hard to explain
17:43
<
kintel >
Basically, I rewrote our usage of the CGAL Constrained Delaunay Triangulator to use Manifold, and two of OpenSCAD's 2D tests broke
17:44
<
kintel >
This was just some opportunistic refactoring, which was very premature as I have too much other stuff to clean up :)
17:44
<
kintel >
..but it broke when exporting to SVG, and then re-importing the SVG
17:45
<
pca006132 >
our triangulator is not really constrained delaunay, it is quite specific to our usecase (doesn't add more vertices, try to handle slight self-intersection, etc.)
17:46
<
kintel >
constrained delaunay doesn't technically add vertices either. I use hole vertices as constraints
17:47
<
kintel >
I think you might be able to reproduce by just feeding triangles from one run back as separate outlines.
17:47
mmu_man has joined #openscad
17:49
<
pca006132 >
will try
17:59
<
pca006132 >
btw #4855 is relatively simple and seems to fix a long standing issue of importing non-manifold STLs
18:00
<
pca006132 >
should work with manifold, not sure if it will work with fastcsg (definitely not working for nef polyhedron)
18:00
dalias has joined #openscad
18:02
RichardPotthoff has quit [Ping timeout: 264 seconds]
18:05
RichardPotthoff has joined #openscad
18:06
<
kintel >
pca006132 I'll take a look. Btw. re. PMP::repair_polygon_soup() and PMP::orient_polygon_soup() - does manifold have similar tools internally?
18:08
dalias has quit [Ping timeout: 256 seconds]
18:10
RichardPotthoff has quit [Ping timeout: 268 seconds]
18:23
misterfish has joined #openscad
18:34
peepsalot has quit [Quit: Leaving]
18:35
peepsalot has joined #openscad
18:42
dalias has joined #openscad
18:48
<
kintel >
pca006132 Good timing with your smart pointer question :)
18:50
mmu_man has quit [Ping timeout: 246 seconds]
18:53
dalias has quit [Ping timeout: 255 seconds]
19:01
mmu_man has joined #openscad
19:06
arebil has quit [Quit: arebil]
19:31
<
pca006132 >
I found that msys2-clang64 pretty good
19:32
<
pca006132 >
I can use -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_CXX_FLAGS="-Og -fsanitize=address"
19:33
<
pca006132 >
with address sanitizer and debug info I caught the std::bad_alloc, this is due to stl_import with wrong size
19:48
guso78k has joined #openscad
19:49
dalias has joined #openscad
19:51
<
pca006132 >
guso78k I found the issue with std::bad_alloc and commented in your PR
19:51
<
guso78k >
hey great!
19:51
<
guso78k >
look after kids then work on it
19:52
<
pca006132 >
but I found another problem, render tests/data/scad/misc/bad-stl-tardis.scad in the GUI will crash it
19:52
<
pca006132 >
render using the command line seems fine
19:52
<
pca006132 >
and not clicking render (just preview) is also fine
19:52
<
pca006132 >
should sleep now, will try to debug tmr if the bug is still there
20:50
<
guso78k >
pca006132 i understand the error. i was too optimistic . of course coordinates could exist twice ...
20:50
<
guso78k >
i have worked on not-rendexing your manifold output, too.
21:24
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:00
misterfish has quit [Ping timeout: 255 seconds]
22:21
<
guso78k >
kintel i still hope that the PR with the smart pointers will prevent openscad ever access freed memory and thus improve stability
22:41
<
peepsalot >
guso78k: is that a big issue currently?
22:42
<
peepsalot >
i don't recall anything like that
22:43
<
guso78k >
peepsalot, no its not. but even main openscad is at most 99.99% stable, not 100%. Very good tough ...
22:45
bozo16 has joined #openscad
22:47
dalias has quit [Ping timeout: 256 seconds]
23:46
qeed has joined #openscad