<InPhase>
kintel: Well officially according to the Python people it's supposed to be about the platform.
<InPhase>
kintel: It's just msys2 is being difficult about it and trying to be "standard" where Python officially decided to not be standard on this for Windows.
<InPhase>
But the end result is apparently yes, we need a search or something.
<InPhase>
At least if it's Windows. :)
kintel has joined #openscad
kintel has quit [Client Quit]
LordOfBikes has quit [Ping timeout: 256 seconds]
J2338 has joined #openscad
<lf94>
hm, not sure how kintel sees messages
<lf94>
kintel: that's not JavaScript, that's web browsers doing the sandboxing
<lf94>
guso78[m]: pong :p
J23 has quit [Ping timeout: 245 seconds]
<JordanBrown[m]>
Well, kind of. It helps when you have a language engine that does not rely on programs being able to do local file system operations.
LordOfBikes has joined #openscad
kintel has joined #openscad
<kintel>
I just noticed something: 'openscad /path/to/file.scad -o out.png' writes out.png to $cwd, but 'openscad /path/to/file.scad -o out.csg' writes out.csg to `/path/to/out.csg`
<kintel>
..since 2021.01
<kintel>
Does anyone know if this is intentional?
Guest3133 has joined #openscad
Guest3133 has quit [Client Quit]
tachoknight has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
kintel: I don't know if it's intentional, but I'll confidently declare the second behavior is wrong.
<InPhase>
kintel: Even worse, -o ./foo/out.csg does not look at ./foo/out.csg but at /path/to/./foo/out.csg and then complains ''Can't open file "./foo/out.csg" for export'' if there is no foo at the source.
<InPhase>
kintel: Then the behavior changes instantly if the -o starts with "/"
<kintel>
How do the test cases work?
<InPhase>
lol
<InPhase>
Asking the hard questions now.
<kintel>
I've learned a few lessons along the way :)
<kintel>
but man, I can hardly remember what I started out trying to achieve back in January or so : /
<InPhase>
Without looking, I'm going to guess someone observed this behavior, and then wrote the test processing around it.
<InPhase>
Actually, it is probably saved by cmake putting absolute paths on everything.
<InPhase>
I remember doing the image thing and copying and pasting from the test run commands. I think it was all absolute paths.
<InPhase>
Therefore at the very least, fixing this should not alter the tests!
<kintel>
I was more interested in making the test fail if this breaks again after fixing
<InPhase>
That csg thing is old, as the last release did it.
<InPhase>
That was the second thing I tried it on after you said it.
<InPhase>
Oh. Not super old though. 2021,01 does it, but 2019.05 did not, and puts them at the right location.
<InPhase>
So somewhere in that 20 month window.
<InPhase>
kintel: Ah, I see. teepee appears to have struggled in the vicinity of 2021 and a little earlier with trying to achieve balance in the force while fighting a mess of imports and exports and changes to the cwd in openscad.cc
<InPhase>
So it doesn't seem that was the actual intended result, but it was instead about other things using the path. We just need csg and ast
<InPhase>
to have absolute paths constructed earlier in the openscad.cc run.
<InPhase>
kintel: And I confirmed that .ast is indeed exhibiting the same issue.
<InPhase>
I believe the line there that avoiding CWD changes entirely is probably a much bigger refactor. But doing an absolute path transformation of the csg an ast output locations should be quite doable
<Scopeuk>
hmm turns out even with a template it can be completely ignored
<J2338>
that what i was wondering how he applied the lable
* Scopeuk
is split between adding a meaningful comment of please provide platform details etc and a description of the problem and "can we just drop the ban hammer"
<kintel>
If you change that to -j 1, you can prove that your issue is indeed related to this
<guso78>
Haha, right now the bottleneck does not appear to be the build success rate, but rather PR reviewer's time O:3
<guso78>
Your valuable proposal to split my big PR into many small ones worked very well at least initially.
rawgreaze has quit [Ping timeout: 248 seconds]
<kintel>
In terms of builds, there is always the chance that we could optimize how we organize compilation units, perhaps we include too much unnecessary stuff etc., but that requires us to profile compilers. It's doable, but not very fun on Windows until we find someone more skilled on that platform : /
<Scopeuk>
that shouldn't affect the ci, to my knowledge all of our builds are done under Linux
<kintel>
Scopeuk Not the Windows CI; it's on msys2
<kintel>
..because we want to run the tests on ~Windows proper
<Scopeuk>
I thought we only used the windows ci to do test runs
<Scopeuk>
if we are building there we are building there, msys is painful
<guso78>
openscad compiled much faster in in msys then in MXE. issue is that msys2 bindaries don't run anywhere else ...
GNUmoon2 has quit [Ping timeout: 240 seconds]
GNUmoon2 has joined #openscad
<kintel>
Yeah, we're both building and testing on msys..
<Scopeuk>
I think I spotted the source of my confusion, the msys2 build is done but it doesn't make the executable available, you have to get it from the cross compile
<kintel>
Painful indeed :) .but less painful than MXE+Wine, or Windows native. I guess pain is unavoidable..
<Scopeuk>
there was a point a short while back where we have native windows builds working under visual c++ but the dependencies support rots really fast
<Scopeuk>
I wonder if it might be possible using chained ci, build on the cross compile and then use the product of that to host the windows tests
<guso78>
I'd love to have openscad for windows built in MSYS2 instead of MXE but the binary will not run outside MSYS2 environment
<kintel>
Yeah, we could potentially chain builds, and move the MXE build to GitHub.
<kintel>
Visual C++ in itself is probably not hard. It's the dependency builds that suck
<kintel>
That said, I'm trying really hard to limit my Windows exposure : /
<Scopeuk>
yeh, I think vcpkg was used for the last attempt
<Scopeuk>
but it is source distribution and that adds huge lead time
<kintel>
we could set up caching etc., but it tends to be quite some work to iron out all the issues
<kintel>
We're doing all of that for the macOS build, but it takes constant care
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<lf94>
InPhase: teepee: what're the visitor stats for the openscad website?
<lf94>
And downloads
<InPhase>
Not sure if anyone is tracking that.
<InPhase>
It would probably require some logfile parsing on the server.
<InPhase>
And probably only goes back a month or so at best.
<lf94>
Could be interesting to check out - I'm curious
rawgreaze has joined #openscad
kintel has joined #openscad
rawgreaze has quit [Excess Flood]
rawgreaze has joined #openscad
<kintel>
lf94 It's been constant for years; I believe around 50K users/month and 30K downloads per month, not counting github
<lf94>
That's some nice constant :)
<teepee>
also not counting OBS, Flatpak, Snap :)
<kintel>
yeah, mine are just website stats
<kintel>
we're also not actively trying to grow; we just write code and let them discover it
<teepee>
ubuntu claims ~6000 "Weekly active devices" whatever that means
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<InPhase>
kintel of the sleepy mac: Do you know how many are nightly vs stable?
<teepee>
release version that is, ~2200 for the nightly
kintel has joined #openscad
<InPhase>
Ok, good. That's indicative of a stronger user base, but still a good testing cohort for following the nightly.
<kintel>
InPhase I haven't run the stats for a long time; we have server logs for the downloads, which is per-file
<InPhase>
Roughly 30k/month downloading stable means a ton of unique users.
<kintel>
the website is analytics, so it's easy
<teepee>
or a lot of bots
<InPhase>
:)
<guso78>
haha, i believe most of the bots are ChatGPT, ...
<InPhase>
guso78: Then it should be better trained on OpenSCAD!
<teepee>
training on binary downloads seems not very useful though :)
<teepee>
unless you trrain it as virus scanner
kintel has quit [Client Quit]
kintel has joined #openscad
<lf94>
I'm surprised we dont see more openscad models in the wild then. I feel there are few.
<lf94>
I guess more are users than developers
guso78 has quit [Ping timeout: 245 seconds]
<teepee>
flatpak seems to have no statistics, from the repo feedback, I'd estimate about 2-5 ;-)
_whitelogger has joined #openscad
<lf94>
InPhase: a pretty good (all) computer-tech-inclined people I talk to havent heard of it
<lf94>
im really curious how kittycad's gonna turn out
<lf94>
im pretty pessimistic
<lf94>
i dont wanna be but there's a few factors
Ekho has joined #openscad
<teepee>
considering Kurt is all vanished, it should turn out nice ;-)
peeps[work] has joined #openscad
<InPhase>
lf94: Well I don't think anybody's installing OpenSCAD by accident or by any default settings on Linux. So that would be the estimate of the number of people who have run it at least once in, say, the last 3 years (otherwise it wouldn't be on the computer for which the statistic is reported).
<InPhase>
lf94: This can notably differ a bit from people who actively use it.
<InPhase>
lf94: But I'm pretty confident that the total OpenSCAD user base it at least in the millions.
<lf94>
I think you're right
<InPhase>
As long as we are not too stringent on the amount of usage that we call "user".
<InPhase>
Power users is going to be a smaller crowd.
<joseph_>
teepee: I wanted to check in about goals for the GSoC Community Bonding Period this year. Hopefully this weekend I can carve out time to push some fixes for a few of kintel's suggestions on my PR from last year. Is there anything else you think I should work on? My availability on weekdays is going to be scarcer, at least until the semester ends in late May. Fortunately that'll still be before the beginning of the coding period.
<teepee>
joseph_: sounds good, main goal would be finding a mode to keep in touch and syncing up with kintel how to go in small steps
guso78 has joined #openscad
<teepee>
maybe even getting some small pieces separated for master instead of just extending the existing PR
<teepee>
so I'd say in short... more talk not yet too much code ;-)
guso7813 has joined #openscad
guso7813 has quit [Client Quit]
<guso78[m]>
printer repaired again. luckly anycubic kobra uses GT2 belt which i had in stock. so it was just a question to replace the broken one and tighten the new one.
<InPhase>
guso78[m]: Never had a belt break yet. I remember when I first started in 2016 I was slightly more anxious about the availability of replacement parts for printers. I actually went and printed duplicates of every part I could. And a few I actually ended up using! But now parts seem to be super easy to find, and better printers than mine are quite cheap.
greenbigfrog has quit [Ping timeout: 240 seconds]
greenbigfrog has joined #openscad
kintel has joined #openscad
<kintel>
joseph_ I'm around until June 22nd and happy to get you started until then.
rawgreaze has quit [Read error: Connection reset by peer]
<kintel>
But generally like teepee mentions, let's try to measure merged PRs more than opened PRs. Managing open PRs after the projects is over is really challenging
rawgreaze has joined #openscad
rawgreaze has quit [Excess Flood]
rawgreaze has joined #openscad
ToAruShiroiNeko has quit []
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ToAruShiroiNeko has joined #openscad
rawgreaze has quit [Read error: Connection reset by peer]