08:58 <kintel> teepee: Can we (and should we) build OpenSCAD on the CI server on bare metal? .. or is it better to set up docker also for interactive build jobs?

09:13 <guso78k> kintel trying to build openscad for MAC without a mac.  could it be an option to virtualize it somehow ?

09:16 <kintel> guso78: You cannot legally virtualize a Mac, but it's technically possible to install a "Hackintosh" on an Intel VM I think. Never tried though

09:17 <kintel> Getting it to build on one of the CI services may be the easiest option, perhaps with ssh option enabled so you can do short interactive sessions too

09:17 <cart_> Something that I have been wondering. Is it hard to have OpenSCad run on multiple threads? I read a really brief explanation somewhere on why that is the case. But I can not remember

09:23 <kintel> cart_ This was mostly an issue of the geometry library (CGAL) not being parallelizable. Should be a lot better now with the new Manifold backend

09:25 <cart_> kintel: The Manifold backend? In latest version of OpenSCad or? What is that though?

09:26 <J23k79> cart_ a feature you need to activate in version 2023

09:34 <Scopeuk> specifically it is an experimental feature available in the nightly builds which enables the manifold engine in place of the openCSG engine traditionally used by openscad. it can have significant performance gain and has multithreading

09:39 <guso78k> kintel, i believe i would feel most convenient having ssh access to an mac account to collect experience compiling my fork on MAC.  Doubt that it will be  a walk-through ...

09:43 <kintel> guso78k Yeah, macs are annoying that way that you need a physical mac. However, if you open a PR on GitHub, it's possible to modify the CI setup to allow you to ssh into the build machine. That would give you a few hours (I think) per session to play around on a real Mac: https://github.com/marketplace/actions/debugging-with-ssh

09:43 <kintel> (I haven't looked into the ssh stuff in detail though, but it looks reasonable)

09:44 <guso78k> kintel, thank you for the link. this sounds like an option.  let me elaborate it ...

09:46 <kintel> guso78k Another option could be to rent a cloud VM. I see pricing down to 0.11 EUR per hour for a M1 Mac: https://www.scaleway.com/en/hello-m1/

09:48 <kintel> Challenge with Cloud VMs is that I don't know how long it takes to bootstrap; install compilers etc., and if they allow creating backup images

09:51 <gbruno> [github] kintel pushed 1 modifications (Update wrangler for manual build) https://github.com/openscad/openscad/commit/a8602dad913518b405d4f29022c134e51ec1a63d

09:51 <gbruno> [github] kintel synchronize pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

09:51 <kintel> guso78k A more long-term viable version of the ssh option could be to create a Mac version of the manual GitHub CI build: https://github.com/openscad/openscad/actions/workflows/manual.yml

09:52 <kintel> ..and add an ssh option to that config. That would allow anyone to spin up an ssh'able CI runner

09:54 <gbruno> [github] kintel edited pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

09:54 <gbruno> [github] kintel edited pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

09:57 <teepee> kintel: I guess we *could* build OpenSCAD directly on the server, but I'm not sure we should

09:57 <teepee> seems better separated via docker or the CI containers

09:58 <teepee> e.g. I'm test-building the MXE stuff via our mxe-requirements container

09:58 <kintel> ..by just spinning up an interactive docker session on the container?

09:58 <teepee> yep

09:59 <kintel> I was hoping to connect it to a remote VS Code session, but I guess that's also doable with some tunneling..

09:59 <gbruno> [github] lkarthee opened issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

09:59 <teepee> the vscode stuff via github has a docker container as backend anyway

09:59 <teepee> so that might work even easier with docker

10:00 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

10:00 <kintel> right, so there might be some VS Code extensions for this anyway :)

10:00 <kintel> but then again, I want to test EGL, so perhaps I should wait until I can access my own HW..

10:05 <gbruno> [github] kintel synchronize pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

10:05 <gbruno> [github] kintel pushed 1 modifications (Update sanitizers for manual build, to reduce # of options) https://github.com/openscad/openscad/commit/65ef6f093d138c30a4c95c74020960d4fb83acd7

10:06 <gbruno> [github] kintel pushed 1 modifications (Update sanitizers for manual build, to reduce # of options) https://github.com/openscad/openscad/commit/61213ed9b998f08443a234f2258d33717ebdffc1

10:06 <gbruno> [github] kintel synchronize pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

10:07 <gbruno> [github] kintel pushed 1 modifications (Update sanitizers for manual build, to reduce # of options) https://github.com/openscad/openscad/commit/8cb8db6e665504d88e012cdded2de1316d3694fb

10:07 <gbruno> [github] kintel synchronize pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

10:09 <gbruno> [github] kintel pushed 1 modifications (Update sanitizers for manual build, to reduce # of options) https://github.com/openscad/openscad/commit/eda762248d48aa206e3964a985e3f1c82234add5

10:09 <gbruno> [github] kintel synchronize pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

10:25 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

10:28 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

10:29 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

10:32 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

10:33 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

10:46 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

10:50 <Scopeuk> we might need to throttle the single issue edits

11:00 <gbruno> [github] lkarthee edited issue #4747 (Discussion Python language support -) https://github.com/openscad/openscad/issues/4747

11:26 <teepee> yep that would be useful

11:27 <teepee> I wonder if that irccat already does that

11:27 <teepee> but first I need to figure out how to handle credentials for installation

12:13 <gbruno> [github] lkarthee edited issue #4747 (Discussion - Python language support) https://github.com/openscad/openscad/issues/4747

14:10 <Joel> Today's stupid question, there's no way to specify what a "unit" of size is, right? inches? mm? cm? etc.

14:10 <Scopeuk> openscad has no concept of units

14:11 <Scopeuk> most of the export formats don't either

14:11 <Scopeuk> stl does not have units (there are some stl models out there in inches rather than mm's) it's just by convention in 3d printing we use mm's

14:13 <Joel> I figured, so when I run it through a slicer I probably have to tell it what units I'm in

14:14 <teepee> in theory yes, so far I've seen all slicers I used just default to mm

14:15 <teepee> fwiw, gcode has no units either, and there are SET-MM and SET-INCH commands in Marlin I think

14:15 <teepee> G20 - Inch Units

14:15 <teepee> G21 - Millimeter Units

14:15 <teepee> :)

14:17 <Joel> awesome, thanks so much <3

14:37 <Scopeuk> slicers have a setting for unit to use as base for stl, as teepee said it defaults to mm's

14:45 <Joel> https://docs.arduino.cc/hardware/uno-mini-le - I have this bad boy, I've been able to open the fritzing files, but wasn't able to find a way to measure the mounting hole placement. I've downloaded the cad files but haven't found anything that'll open them on linux yet, so I'm stuck doing the measure/print/test repeat cycle

14:48 <peeps[zen]> Joel: for what its worth, if you have a need to specify some dimensions in inches, feet, etc. I often define a unit near the top, in relation to mm, `in = 25.4;` then you can define a length as a multiple of that unit: `partL = 6*in;`

14:51 <Joel> peeps[zen] thankfully prusa slicer throws up a warning for me somehow, and asks if I want to convert inches to mm, no idea how it detects, but thankful it caught that with my first couple of pritns

14:51 <Joel> I guess 4" -> 4mm is pretty small lol

14:58 <Scopeuk> looks like the "cad" files are some weird altium format for sending to clients you want to impress without releasing their own ip back to them

14:58 <Joel> Scopeuk which is hilarious from the "open source" arduino project

15:13 <peeps[zen]> could try this https://github.com/thesourcerer8/altium2kicad

15:43 <Joel> peeps[zen] hey thanks, that might be what I do next <3

16:28 <J23k79> function inch(n)=n*25.4; ↦  length= inch(5);  .. or  you slap a scale(25.4) around

16:42 <joseph_> teepee: I know this is the last week of my extended GSoC so a bit later this evening (in your time zone) I've allocated a chunk of time to do some fixup/organization of my branches in preparation for my report submission. I think the optional compile-time macro can get merged with little review since it doesn't do anything when not specified. More experimental changes can potentially get reviewed later on

18:02 <kintel> joseph_: Just so I understand: Is your macro PR essentially a way of #ifdef'ing out most legacy OpenGL calls so that it's possible yo compile, but not run, OpenSCAD against GLES 3.2 core/GLES ?

18:08 <joseph_> Yes. And when I have a chance to try making a branch that combines this with my work last year on F6 shader rendering, the hope is that it will be able to run (render only, for now)

20:04 <gbruno> [github] kintel edited pull request #4737 (Add new, more capable, EGL offscreen support) https://github.com/openscad/openscad/pull/4737

22:05 <InPhase> Joel: Some fancier imperial unit features: https://bpa.st/E6MQ

22:06 <InPhase> Joel: Including canonical string printouts to the nearest 32nd of an inch.

22:08 <InPhase> in = 25.4; though really covers like 99% of possible need. I just felt like implementing a complete set for fun one day, so now I have it. :)

22:16 <InPhase> Also, I think "in(5, 1/4)" is a little easier on the eyes than (5+1/4)*in

22:17 <InPhase> Plus you get automatic precedence support. 50*in / ((5+1/4)*in) vs. in(50)/in(5, 1/4)

23:36 <Joel> InPhase yeah I ended up doing something like that when I was doing house framing, I think you might have helped me back then actually