<peeps[zen]>
kintel: i am guessing that without clang-tidy, the build uses gcc though?
<kintel>
No, this is on a clang-only system (macOS)
<peeps[zen]>
is this your local dev box
<kintel>
yup
<kintel>
Anyway, I can dig deeper, was just hoping it was obvious to you :)
<peeps[zen]>
but regarding the header filter, the comments above that line try to explain, its doing the equivalant of a negative lookahead, to say "exclude headers under /src/ext "
<peeps[zen]>
the way that clang-tidy interfaces with projects is frustrating. header-filter only acts as a whitelist, there is not a straightforward way to exclude subdirectories
<peeps[zen]>
and then i forget how source files (as opposed to headers) are handled, but there's essentially no control over that
<linext>
any update on the WASM build
<kintel>
peeps[zen] Yeah, that ext header filter just looks scary : /
<peeps[zen]>
kintel: glad to see you refactoring the OffscreenContext code btw. i was thinking about refactoring it a while back, but kinda froze up on the objective-c code as I am mostly clueless to all things apple
<kintel>
peeps[zen] It's slow process, but I think I'm getting there. Will also rewrite ObjC to C++ soon
<kintel>
..and Real Soon Now, I can request OpenGL 3 context :)
<peeps[zen]>
nice!
<peeps[zen]>
coincidentally it was a clang-tidy check that led me to want to refactor that in the first place.
<peeps[zen]>
src/glview/OffscreenContextGLX.cc:224:3: warning: Potential leak of memory pointed to by 'ctx' [clang-analyzer-cplusplus.NewDeleteLeaks]
<lf94>
I know it's not with OpenSCADs intepreter but still
<lf94>
It's a great step
<guso78>
next step is to set up the utilty library. so many things which can leverage from curv
<guso78>
actually it was me who ported quite some blenders to curv
fedorafan has joined #openscad
<lf94>
guso78: it'd be incredible if you got the integration working with OpenSCAD language too
<lf94>
it's already amazing now, but just saying
<lf94>
you have some experience now dealing with the codebase
<guso78>
i dont know ANYTHING about openscad before the parser function :(
fedorafan has quit [Ping timeout: 252 seconds]
<lf94>
ah
use-value has quit [Remote host closed the connection]
<lf94>
well one of these days im looking into it, because i think the more people doing code cad = the more great things ill see in my lifetime come from it :D
<pa>
https://i.imgur.com/0dAsCp4.png so in the end i went rambo, and printed without testing the sockets.. Turns out they are a tad too fit and bump slightly. How can i "file" that tpu surface to even it? if i go on with a hot air station, do i risk to melt down everyting? ideally a disc of metal sligtly larger, and hot, to press on each bump?
<InPhase>
pa: Sub-layer tweaks, sand paper. Tweaks on the scale of one layer or so can be made effectively with a sharp knife, preferably a quality carbon steel blade so you're slicing smoothly and not peeling or hacking. If you need more than your outer layer count minus 1, then a reprint is usually mandatory. :)
<InPhase>
For internal rounded sanding, I've achieved success by wrapping sand paper around an appropriately sized bolt.
<InPhase>
The sharp knife can also do a slight post-print chamfer if a printing defect gave you a bit of an issue at an opening (like overextrusion on the bottom layer on a design that you didn't leave enough clearance for this).
<InPhase>
You can ultimately build any shape out of plastic using epoxy, a knife, and patience. But the goal here is to make the printer do most of the work. :) So I try to leave the adjustments to quick hack fixes to save time, or for scenarios where higher accuracy is needed than printing tolerances can achieve.
<pa>
InPhase: so heat-based tweaks not recommended?
<kintel>
InPhase I've finally circled back to running tests under Windows, and it looks like the venv stuff behaves slightly differently between plain win32 and msys2
<teepee>
joseph_: turns out the GSoC app does not like just any google account, it only works with some specific ones, not the one I tried to use first.
<kintel>
-> the python executable is in venv/bin/python.exe, not venv/Scripts/python.exe
<kintel>
Did you happen to bump into that, or am I on my own?
<teepee>
I seem to remember that difference caused some trouble earlier
<kintel>
Yeah, I'm a bit scared to touch it ;)
<kintel>
Not sure if it matters, since our build script cannot install PIL under Windows anyway : /
<kintel>
oh, and our Windows cmake Find macros are not very well behaved; I have to remove CMakeCache.txt and re-configure between each build, as there is some broken cmake cache stuff going on.
<kintel>
I guess I'm the first to run tests under msys2. Not sure if I can fit into that rabbit hole ;)
<kintel>
InPhase Btw., do you actually have a way of running tests locally, or do you just CI do the job?
<kintel>
(all tests run in 1 minute here, so it would be awesome if it worked)
<InPhase>
kintel: Maybe if you skipped that you have an msys2 that has a python but no pip. The error message does not reveal no pip, but instead was something else more obscure that is actually due to a missing dependency that is bundled into python-pip. Maybe something about wheels missing or something?
<InPhase>
It took me a little googling, thinking, and guesswork to put that together that day. It was not an obvious failure pattern.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ur5us has joined #openscad
guso7841 has joined #openscad
<joseph_>
teepee: So were you able to successfully get added as a mentor?
<teepee>
yes
snaked has joined #openscad
Guest87 has joined #openscad
Guest87 has quit [Client Quit]
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
ur5us has quit [Quit: Leaving]
ur5us has joined #openscad
kintel has joined #openscad
<kintel>
InPhase It looks like the problem may be that it cannot install the binary wheel for PIL, and it tries to compile it, but PIL doesn't support building on Windows using gcc.
<kintel>
On the CI, it uses a pre-built non-msys2 version of Python, which seems to be able to download pre-built packages