<teepee>
yeah, would be great if the first PR could be brushed up for the midterm
<teepee>
kintel: I also hope to find some time for the python PR. with all the switches and guards, it should be fine. the builds will be a concern, but I suppose it will start out on Linux and we'll see how it goes on other platforms later
<kintel>
Heh, yeah, I don't really know where to start with python on the other platforms. But as an experimental feature it doesn't need to be complete on all platforms
<teepee>
yep, plus maybe find someone who can help
<kintel>
in other news, I managed to build an EGL-based OpenSCAD without resorting to the custom docker build
<kintel>
Requires an OpenCSG patch, but it's a good proof-of-concept
<teepee>
nice, via GLAD?
<kintel>
yup
<kintel>
I just had to remove OpenGL 1.x support from OpenCSG :)
<teepee>
yeah, part of that even conflicted with GLX + EGL
<guso78>
Of course i am there for Instant fixes once i learn about issues.
<teepee>
\o/
mmu_man has joined #openscad
<kintel>
hm, yeah, some people don't find the snapshots. The good news is that they managed to build OpenSCAD from source on macOS without needing help from us :)
<teepee>
indeed, that was my thought too :)
<teepee>
plus we may need to rephrase the "and M1" support
<kintel>
right, s/M1/Apple Silicon/ I guess
<kintel>
In terms of OpenCSG/GLAD; I fear we won't be able to upstream the changes due to how GLAD vs. GLEW works
<kintel>
..GLAD being generated on demand meaning it won't make it into distros as a shared library
<kintel>
Not sure what common strategies are for libraries and GL wrangling. We can perhaps let OpenCSG dlopen/dlsym its own symbols, but that's a larger change. Right now I just expect the host application to offer GL headers, but that won't work if OpenCSG is a shared lib
<teepee>
ah, I see. I've not seen any discussion ralated to that so far
<kintel>
I haven't spent too much time on it yet, as I want to see if our other necessary patches to OpenCSG will ever be upstreamed. Otherwise, we just have to live with a fork
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aiyion has quit [Ping timeout: 240 seconds]
aiyion has joined #openscad
Guest18 has joined #openscad
snaked has joined #openscad
Guest18 has quit [Quit: Client closed]
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
drfff has joined #openscad
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
kintel has joined #openscad
anonymous has quit [Ping timeout: 246 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
guso78 About PolySetIndexed - I've attempted to start on that a number of times, but always ended up identifying some other prerequisite refactoring. Things have changed quite a bit since last I tried though, so it's worth a try
<kintel>
..with the usual request that green refactoring is submitted as smaller/trivial individual PRs, to avoid ending up with a hard-to-review monster PR :)
teepee_ has joined #openscad
teepee has quit [Ping timeout: 240 seconds]
teepee_ is now known as teepee
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<latex>
Does openscad have a grid feature?
<teepee>
grid doing what?
<latex>
grid like on librecad
<latex>
over the whole screen
<latex>
instead of just teh axes
<J23k39>
nah you have to make that by yourself
<teepee>
no, it's also a bit more difficult in 3d
<teepee>
peeps showed how it looked like and it's probably quite difficult to not make it too messy
peeps[work] has quit [Ping timeout: 246 seconds]
<InPhase>
I remember that being quite ugly. :) But it was a noble attempt.
<teepee>
something in that direction seems useful, but difficult to find a balance between making the screen horribly busy and having no benefit
kintel has joined #openscad
<kintel>
I was testing some grids a long time ago, this one is pretty nice, but a main challenge is getting good labels and good positions of labels: https://codepen.io/kintel/pen/eprzyx