03:00 <gbruno> [github] inks007 opened issue #4732 (Manifold - Minkowski fails on concave polyhedron with render mode (but works if you preview first)) https://github.com/openscad/openscad/issues/4732

03:00 <gbruno> [github] inks007 edited issue #4732 (Manifold - Minkowski fails on concave polyhedron with render mode (but works if you preview first)) https://github.com/openscad/openscad/issues/4732

03:01 <gbruno> [github] inks007 edited issue #4732 (Manifold - Minkowski fails on concave polyhedron with render mode (but works if you preview first)) https://github.com/openscad/openscad/issues/4732

09:01 <guso78k> today when compiling master branch of openscad with MXE , i get this error:

09:01 <guso78k> https://bpa.st/NKDDQ

09:02 <guso78k> why is python interpreter/executable needed in master for compiling openscad. missing any dependency?

09:44 <guso78k> i just realized that ENABLE_PYTHON is active :')

12:45 <guso78k> whenever i compile openscad with MXE i get a linking error: all symbols of libdoubleconversion are double defined in libdoubleconversion.a and  libQt5core.a and, sso I  manually remove libdoubleconversion.a from the library list. is there a better option ?

13:05 <gbruno> [github] kintel synchronize pull request #4585 (Test using msys2 python for tests) https://github.com/openscad/openscad/pull/4585

13:05 <gbruno> [github] kintel pushed 1 additions 1 modifications (time) https://github.com/openscad/openscad/commit/61fe9a2e651dc5077da521517077ff7e98a5c568

13:11 <Scopeuk> Looks like it might be a recent addition to qt https://doc.qt.io/qt-5/qtcore-attribution-doubleconversion.html, I guess at that point a full solution is to have the build system if it has double conversion and only link double conversion if not

13:20 <teepee> I've never seen that with our builds, but we build a static version, so maybe you just need to switch to that

13:25 <buZz> how can i force QT to draw openscad's menubars at smaller sizes?

13:26 <buZz> i guess.. the menubar is GTK? hmm

13:27 <guso78k> Scopeuk, i am talking about recent master and i suppose that there are still daily builds. i am wondering, how these are different from my setup.

13:30 <guso78k> https://bpa.st/VDLYO

13:31 <guso78k> this is my quick fix and it compiles fine. however its very ugly.  i want to resolve the absolute path

13:34 <guso78k> IST(FILTER TARGET_LIBRARIES EXCLUDE REGEX .*libdouble-conversion.a )

13:35 <guso78k> LIST ... does the job

13:38 <Scopeuk> guso78k it looks like it is a qt build option

13:38 <Scopeuk> Used in Qt Core. Configure with -system-doubleconversion or -no-doubleconversion to avoid.

13:39 <Scopeuk> Where is your qt from?

13:51 <guso78k> no special qt version. i just run the ./scripts/mingw-x-build-dependencies.sh 64 as documented.

15:18 <teepee> this is how the official builds run https://github.com/openscad/docker-openscad/blob/main/mxe/mxe-x86_64-openscad/Dockerfile

15:20 <teepee> https://github.com/openscad/openscad/blob/master/scripts/release-common.sh#L124-L125

15:22 <teepee> and MXE_TARGETS=x86_64-w64-mingw32.static.posix

15:23 <teepee> the build-depends should take care of the needed flags

19:19 <kintel> This may be an existing issue; have anyone seen flaky behavior with fast-csg on Windows?

19:19 <kintel> The following design segfaults _most_ of the time on a local msys2 build:

19:19 <kintel> difference() { cylinder(r=1, h=1, center=true); cylinder(r=0.5, h=2, center=true); }

19:28 <ndnihil> https://goo.gl/maps/fiuzwuk1XJ8jXR1P9

19:29 <ndnihil> found your headquarters

19:32 <J23k51> https://www.scad.edu/

19:35 <J23k51> Savannah College of Art and Design

19:37 <kintel> ^ To make it more interesting, it doesn't fail under gdb and doesn't dump core when crashing

19:37 <InPhase> ndnihil: This is the better perspective: https://goo.gl/maps/AF2M98mePg5v1jFb9

19:37 <kintel> I guess this is Windows' way of saying welcome back.

19:37 <InPhase> ndnihil: It emphasizes our excellent UX design. :)

19:38 <InPhase> kintel: Perhaps library or compiler version specific optimization-triggered UB.

19:39 <kintel> Possible, I upgraded all packages in msys2 and built with -DCMAKE_BUILD_TYPE=Debug though

19:39 <InPhase> Does our Debug disable optimization?

19:40 <InPhase> And you mean it still crashed under a Debug build outside of gdb?

19:40 <kintel> yup, crashed in debug mode under gdb

19:40 <kintel> *outside gdb

19:40 <kintel> I can look into optimization flags, that's a good idea

19:41 <kintel> CI is green though, so it feels related to my system

19:57 <kintel> argh, after updating msys2, I'm back to pillow not installing

19:59 <InPhase> For the record, you also voted for the python testing thing being a good idea. ;) *dodges-blame*

20:00 <InPhase> It sure has been dodgy under msys2 though.

20:03 <kintel> Yeah, I had no idea how badly msys would misbehave : (

20:04 <kintel> ..but we have -DENABLE_TESTING=0 ;)

20:04 <kintel> I pledge to uninstall Windows as soon as my WGL patch is tested

20:08 <kintel> Looks like manifold build flags overrides my attempts at building without optimizations..

20:08 <kintel> I probably need to slow down, clear my desk, and strap in for the long one : /

20:46 <teepee> kintel: the manifold update branch has some manifold fixes including at least leaking -Werror into our flags. that might solve the optimization flags to

20:46 <teepee> *too

20:46 <InPhase> kintel: Hopefully you're still habitually checking logs. If you want to get extra hacky in attacking this problem, you can try duct-taping in this segfault stack dumping code of mine. You can just brutally slap it above main, and then call RCdbg::Segfault::SetHandler(); like done in the example. An example of what you can get out of it after demangling is shown. https://bpa.st/IMTDS

20:47 <teepee> I have not merged yet as for some strange reason the 2 "invalid stl" tardis door test cases broke after forcing predictible STL output, not sure yet why

20:48 <InPhase> This slightly thwarts usage of debuggers for segfault tracking, but if things are working right on that trace, you get a view of where you were in the code, which makes up for it. I think with msys2/mingw you also need the -rdynamic flag on the compile line to make this work.

20:48 <teepee> oh, that looks useful

20:49 <InPhase> If you want to leave it in all the time, you also can. I ship code with segfault dumps like this in routinely. Although I also try very hard to not have segfaults. :)

20:50 <teepee> :)

20:50 <InPhase> The caveat is that you sometimes DON'T get a trace like this under Windows in certain conditions where the segfault happened within some library, due to an architectural choice of how those signals are handled in a memory block specific manner.

20:50 <teepee> having it available, maybe with a command line flag to activate might be good

20:51 <InPhase> teepee: Well, if one is going to put it in, the smarter choice is probably a flag to remove it.

20:51 <InPhase> For users of compiled code, there are no good outcomes after a segfault other than information that can be reported.

20:52 <teepee> hmm, not so sure, at least on Linux some distros have those automatic bug reporters

20:52 <InPhase> It's developers who would sometimes not want it.

20:52 <InPhase> teepee: Does anybody actually use those or find them ever useful?

20:52 <teepee> no idea

20:54 <teepee> in general I like it better to keep system functions in place, not force overriding them

20:56 <teepee> but it might be true this is not used much anymore, I suppose that would mean poking distro people about their bugtracker statistics

20:56 <InPhase> A reasonable principle. Although there's no actionable data other than the segfault exit code (which this also returns), or a core dump if those are enabled, which this would block.

20:57 <InPhase> So it's really the core dumps that it prevents.

20:57 <teepee> oh, they do collect backtraces if available and also execute ldd for lib dependencies and installed version of those

20:57 <InPhase> Although I suppose you could try to trigger another segfault at the end of the handler if you wanted. ;)

20:58 <InPhase> Although that might loop... Maybe turn the handler off first. Which is getting hacky on hacky.

20:58 <teepee> but yeah, I would not be opposed to just have a --disable-our-segfault-handler first and see if anyone complains :)

20:59 <InPhase> Also, technically calling fprintf inside of a segfault handler is both undefined behavior AND a POSIX violation. But it works, usually.

20:59 <InPhase> And I don't care about standards post-segfault. I do these things only to maximize the chances of returned information from users.

21:00 <teepee> especially on Windows that could be a huge win as usually there's not really any information other than "it crashed"

21:00 <InPhase> I do alternate versions of this where I log the information to a file with datetime stamps. That tends to be more valuable for windows users who never launch from a terminal.

21:01 <InPhase> The example in the pastebin uses a single fprintf call to output to stderr, so the conversion to a file output is obvious.

21:09 <guso78k> i have seen some projects on github which do backtraces on several systems but i did not have time to look into that closely.

21:10 <guso78k> having this in place would help me to debug my indexed-pr error

21:15 <teepee> as for a totally different topic, any pointers to self-hosted CI system? I do want to have something on the new file server, specifically first for auto-deploying the WASM playground

21:16 <teepee> I know the obvious candidates like gitlab and jenkins

21:16 <teepee> I looked at flow.ci but could not get that to work, it looks not bad, but it just threw an error without any text so not too helpful

21:17 <teepee> so far I'm impressed by concourse

21:17 <teepee> slightly unusual that one

21:19 <teepee> I did not look closer at Abstruse CI but the name is already the strangest of the bunch ;-)

21:19 <teepee> pluse 1 commit in the last 2 years

21:56 <InPhase> teepee: I never dabbled in that. Maybe #C++-General would have someone with a suggestion? (Just ignore the harsh retorts about all your life choices being wrong.)

21:58 <teepee> like that? https://assets.chaos.social/cache/media_attachments/files/110/996/760/051/992/845/original/6ab26457f1c482dd.png

22:06 <InPhase> It's probably a bad sign that my first reaction to that image was, "Looks like a normal lab except for them wearing safety goggles."

22:09 <teepee> :)