00:00 <Friithian> although I do have a friend who has one of these and has access to their company's inspection machines…

00:02 <InPhase> I just made sure to grab myself some good spec tools so that I can handle measuring at the full precision levels that the printers can be impacted by. And that I found was a good move. I use them quite a lot.

00:03 <InPhase> They more than paid for themselves by now, as I end up using them for more than printing stuff.

07:27 <J23k75> imho this looks much more complicated as it is https://www.printables.com/model/539348-panzerkette

10:16 <gbruno> [github] nathanpc opened issue #4710 (OpenSCAD 2021.01 won't open in Mac OS X 10.9) https://github.com/openscad/openscad/issues/4710

11:56 <gbruno> [github] gsohler synchronize pull request #4702 (Python pr3) https://github.com/openscad/openscad/pull/4702

15:44 <Friithian> mac OS X 10.9‽‽ damn that's old

16:14 <teepee> indeed

17:09 <gbruno> [github] gsohler synchronize pull request #4702 (Python pr3) https://github.com/openscad/openscad/pull/4702

17:35 <guso48> i believe that either the compiler version or the compiler settings were changed for the macos build.

17:35 <guso48> in some places code: for(auto &x : list)

17:35 <guso48> needs to be rewritten as:

17:35 <guso48> for(const auto &x : list)

17:35 <guso48> to compile

17:37 <gbruno> [github] gsohler synchronize pull request #4702 (Python pr3) https://github.com/openscad/openscad/pull/4702

17:54 <teepee> yeah, something change, I did compare compilers and versions looked same

19:22 <guso48> CGAL::SNC_FM_decorator is not defined anymore. did CGAL version change ?

19:25 <teepee> where, most builds should have it fixed

19:26 <guso48> i see it in

19:26 <guso48> https://github.com/openscad/openscad/actions/runs/5707549500/job/15464332866?pr=4702

19:26 <guso48> is there a known fix ?

19:28 <guso48> i test by ciommenting the line ;()

19:28 <guso48> ;)

19:31 <gbruno> [github] gsohler synchronize pull request #4702 (Python pr3) https://github.com/openscad/openscad/pull/4702

19:58 <gbruno> [github] gsohler synchronize pull request #4702 (Python pr3) https://github.com/openscad/openscad/pull/4702

19:59 <gbruno> [github] gsohler synchronize pull request #4702 (Python pr3) https://github.com/openscad/openscad/pull/4702

20:30 <teepee> hmm, we need those fixes separately. not sure where the difference is coming in though. I could not find a version difference for the macos build yet. but something must have changed in the environment obviously

20:34 <gbruno> [github] gsohler synchronize pull request #4702 (Python pr3) https://github.com/openscad/openscad/pull/4702

20:34 <gbruno> [github] t-paul pushed 3 modifications (Build fixes.) https://github.com/openscad/openscad/commit/ad88763495c2a7f2bbe57dbedc45515657614223

20:34 <gbruno> [github] t-paul opened pull request #4711 (Build fixes.) https://github.com/openscad/openscad/pull/4711

20:37 <guso48> exactly my finding teepee. thank you for confirmation

20:38 <teepee> I've pulled your fixes into a separate PR, lets see if that catches everything.

20:38 <teepee> and thanks for digging into that, I'm still fighting with MXE also throwing build errors

20:39 <teepee> I've finally gotten the latest MXE building with gcc-13 but it now fails building openscad itself

20:39 <teepee> will be interesting to see if that even makes it runnable on win7 again :)

20:40 <guso48> Haha, suppose i have learn much more GIT magic "moves" ....

20:40 <teepee> not that I personally need that, but I believe there's still a number of people who would be happy about that

20:48 <teepee> pfff

20:48 <teepee> /openscad/submodules/manifold/src/third_party/thrust/thrust/system/detail/sequential/malloc_and_free.h:37:21: error: argument 1 range [16140901064495857664, 18446744073709551612] exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]

20:49 <guso48> hmm ...

20:49 <teepee> who is setting -Werror, that is rude ;-)

20:50 <guso48> looks like there is a type mismatch in argument 1

20:51 <guso48> hmm maybe there were numbers in the alloc-size but some shell variables were not set ?

20:53 <teepee> not sure where it's getting those values from. at any rate, it's originally a compiler warning

20:53 <teepee> and so far the other builds have no issue

21:03 <teepee> uh, nice, build success

21:03 <teepee> hmm, how do I get that out of the docker container :D

21:05 <guso48> yes, those 3 changes makes it build again

21:06 <guso48> i hope you wait little bit so my build can finish and does not get restarted :')

21:07 <teepee> no problem, I'm trying to fix the MXE build, temporarily removing the -Werror seems to make it build at least

21:07 <teepee> interestingly without those 3 fixes

21:08 <guso48> yeah, only mac compiler got sensible to "bad code quility"

21:08 <guso48> quality

21:08 <teepee> just for fun, let me see if that actually made it win7 compatible

21:09 <guso48> i think i have windows xp run on the hard disk in the shelf right to me ...

21:10 <teepee> the MXE wiki entry even mentions XP

21:10 <teepee> not sure if it's a good idea to even boot that :)

21:12 <guso48> yeah microsoft support to fixes cve has expired  long time back and viruses might have evolved haha

21:15 <teepee> I did not boot that win7 VM for a long time, I suppose that wants to do again something like 3 days of update cycles

21:16 <guso48> it might find files in the desktop which appear "unused" for a long time

21:20 <guso48> yes, my PR is in sync again. ready to receive new challenges

21:21 <guso48> need to finish, tomorrow is a special day ...

21:23 <teepee> so I can merge the build fix?

21:24 <teepee> nope

21:24 <teepee> still no win7, ah well