00:45 <teepee> argh

00:46 <teepee> someone stole the dir index on the fileserver ;-)

01:02 <ndnihil> stole?

01:03 <teepee> well sort-of, overwriting via ansible with a file where the setup is missing

01:09 <ndnihil> when in doubt, turn it off and back on again

01:13 <teepee> yep, fileserver is fine, not sure why https://ci.openscad.org/ did not come up again too

01:29 <teepee> ahh, there it is

01:29 <teepee> strange stuff

07:31 <guso78> Teepee These days WE are changing Python Operators to more "logical/boolean" ones

13:23 <teepee> guso78: I don't know what that means, do you have an example code snippet?

13:46 <guso78> Using | instead of + Operator and & instead of * IS more logical. Also Syntax for Csg Ops IS Now (arg1, arg2) instead of ([arg1, arg2 ])

13:55 <Scopeuk> + and * are the boolean algebra operators in it's rawist (pure maths) form but I have to admit explicit logical operators better convey intent particularly when types are fluid

14:02 <guso78k> yes it is, this is why laurent proposed to change it.

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

14:02 <guso78k> i am absolutely happy that i found yet another guy which is willing to contribute to the python branch. two people have almost double amount of ideas ...

14:03 <teepee> ah, I see

14:03 <guso78k> this fix does the ([]) -> () transformation

14:03 <guso78k> laurent wanted to contribute with he operator change

14:04 <guso78k> also we plan to use solid * vector for scaling and solid + vector for translation

14:05 <teepee> what's the idea regarding customizer, there was some discussion on how to do that in python related to cadhub.xyz

14:05 <teepee> which seems mostly dead currently :(

14:16 <teepee> hmm, does not look like much of the discussed stuf was implemented https://github.com/CadQuery/cq-cli/blob/b87a0f1394812a2fda023b050c903079d4eab6b0/tests/testdata/cube_params.py

14:21 <guso78> William asked the customizer. to Work with Python, which dies Not Work: without Parser() and yacc No Automatic Parameters. So i helped myself by regexing the Python source Code.

14:52 <guso78k> somethging is wrong with clipper lib in windows build.

14:57 <guso78k> teepee, do you think, compiling python openscad for windows is a clean solution ? MXE does not support python, butr instead i use headers and static library stub of mingw64 instead. this works with python dll installed by python installation.

14:58 <guso78k> as for mac i cant help out as i dont own one. not sure if our mac guru has extra time, though ...

15:04 <teepee> guso78: that should not be needed, manually parsing python

15:04 <teepee> I'm pretty sure python actually has that information

15:05 <teepee> having one comments parser is bad enough - it does has the reason of compatibility with thingiverse

15:06 <guso78> Yes you are right. I believe i can extract and Filter Python global vatiablea

15:06 <teepee> at minimum you can collect annotations which may be needed to pass additional information anyway

15:07 <teepee> I'm sure that works for methods, as I have actually worked on code like that - I did not try with variable assignments though

15:19 <teepee> as for building, I certainly would prefer a different solution, but in the end we need to find something that works

15:19 <teepee> with MXE not directly supporting python and no solution for distributing MSYS2 standalone apps, that may be the solution for now

15:25 <guso78> Maybe have a Look into my branch python-pr3-win and Tell me what you think

15:30 <teepee> that one? https://github.com/openscad/openscad/pull/4736

15:31 <teepee> that seems to have bad issues compiling Manifold on windows for some reason

15:34 <kuro> Is there a way to write tests that are independent of original .scad file that verify that certain critical dimensions are being met?

15:38 <teepee> tests as in reading the STL file and measuring that?

15:47 <kuro> Yes. Or alternatively, some way of measuring within OpenSCAD.

15:48 <teepee> I hope there's going to be built-in measurement at some point, but right now I don't think there's anyone working on that

15:49 <teepee> some in-between solution would be a script generated ruler - while not 100% separate, it's trivial-ish to convince the ruler size it what it says :)

15:49 <ndnihil> should be able to parse the stl for its extremes in a given axis and compare

15:49 <ndnihil> but yeah, I do the ruler thing

15:50 <kuro> That makes sense. Yeah, I agree it is trivial enough to trust.

15:50 <kuro> Thanks.

17:40 <J23k> until  the  ruler issue with zooming is not fixed to use $vpt instead of [0,0,0] for the scale .. i now have added this level staff https://imgur.com/a/lS2s0Uh

20:43 <joseph__> teepee: I thought I'd check in again quickly with a status update summary. I'm in the process of taking a broader look at what in the code needs to change for removing client-side vertex arrays. This seems entirely concentrated in code by obliviand from a few years ago. Absent the ability to ask him directly, I'm continuing to comb through the commit history to find what still needs to be done

20:44 <teepee> joseph__: are there any smaller steps that could be taken in code already? it's google summer of *code* after all ;-)

20:47 <joseph__> That leads into my next point. This stems from the previous goal of using a core profile. I'm beginning to wonder if doing that can only happen after I prepare and merge last year's feature additions. Because without them there isn't actually a shader being used for rendering. And when using modern arrays, the data needs to get bound to an actual shader attribute

20:48 <joseph__> So I think this investigation work is going to have to happen eventually anyway, because the current method of defining arrays is only workable with a compatability profile

20:50 <teepee> right, sounds plausible. so what's your suggestion for the next steps

20:52 <teepee> brush up / update the exiting PR and see that we can get that merged?

20:54 <teepee> *existing

21:20 <joseph__> That sounds good to me. The process will involve double-checking what code paths are used during rendering, which I think might help answer some of my questions about how the shader attributes would be assigned to arrays in the ultimate fully modern approach

23:45 <kintel> joseph_ I believe last year's PR still requires upstream changes to OpenCSG to be mergeable, as we'd need OpenCSG to also use shaders to produce vertex positions.

23:48 <kintel> I cannot remember the details atm., but there are very slight differences in vertex positions, depending on how they are transformed, causing OpenCSG rendering to cause crazy z buffer tearing

23:49 <ndnihil> kintel: https://www.youtube.com/watch?v=Ixh3ksPbZD4

23:49 <othx> ndnihil linked to YouTube video "Linear Actuator in OpenSCAD" => 2 IRC mentions

23:49 <ndnihil> bawmp chicka boww

23:51 <kintel> pretty neat!

23:53 <kintel> joseph_: See https://github.com/floriankirsch/OpenCSG/issues/8

23:55 <teepee> oh, kintel do you have the ci docker acount for me? that would better fit for pushing stuff https://ci.openscad.org/teams/wasm/pipelines/wasm-playground-base/jobs/build-and-push/builds/5

23:55 <teepee> wait, that one is not public ;-)

23:56 <teepee> that one is, no docker push though - https://ci.openscad.org/teams/appimage/pipelines/appimage-arm64v8-base/jobs/build/builds/1

23:58 <kintel> teepee I'm a bit out of the loop. Not sure I understand your question :)

23:58 <teepee> there's a docker ci user

23:59 <teepee> I hope you still have that, well, or we could just kick it and create a new one I suppose

23:59 <kintel> On docker.com?