<peeps[zen]>
tcurdt: looke like that wiki page is just out of date. we moved from qmake (openscad.pro) to cmake since the last release
<ccox>
the directions on the github readme are more accurate and up to date than the wiki, WRT macos builds
<teepee>
no idea why someone copied the text into the wiki, I've removed that
<tcurdt>
I just got a build working a few seconds ago :)
<tcurdt>
and just updated the github issue
<JakeSays>
openscad builds with cmake now?
<tcurdt>
it does :)
<JakeSays>
that's nothing to smile about.
<JakeSays>
i can't stand cmake. i'd take bash scripts over it.
<teepee>
good luck with those across mutiple platforms
ferdna has quit [Quit: Leaving]
<teepee>
I'm not a huge fan of cmake, but it does cover at least some of the platform/compiler stuff
<JakeSays>
cmake just sucks. pisses me off that qt moved to it
<tcurdt>
I mean - I left that world of pain quite a while ago. But is there anything that doesn't suck in that realm?
<teepee>
no, that's impossible
<JakeSays>
yes. GN. i use it extensively.
<teepee>
is that the google thing?
<JakeSays>
yes
<teepee>
that is not coming near any of the projects, end of story
<JakeSays>
have you ever used gn?
<teepee>
there is *no* build system coming out of google that will be of any use somewhere in the real world that is not google
<JakeSays>
huh. that's awfully short-sighted.
<dalias>
cmake is worse than everything except qmake, so ... ¯\_(ツ)_/¯
<teepee>
reality
<ccox>
according to goggle engineers, their build systems aren't even of much use INSIDE google. It's just the "flavor of the month" as new hires discover new toys and projects bigger than they can understand.
<JakeSays>
teepee: it's not reality. not at all.
<JakeSays>
ccox: well, most of google's public projects use gn, so not sure what that engineer was talking about
<teepee>
I maintain stuff across multiple platforms and maybe 20 linux distros of different age going back maybe 5 years
<tcurdt>
what's the project page of "GN"? it isn't very search friendly.
<teepee>
that is absolutely impossible to do with anything google designs
<JakeSays>
tcurdt: lol it's not.
<JakeSays>
teepee: well, i don't envy you having to do all that maintenance, for sure.
<ccox>
JakeSays: public != internal. I know more than a few Fellow and Senior Developers at Google.
<teepee>
yeah, and the last paragraph clearly explains why it's incompatible at least with the linux distro world
<JakeSays>
teepee: yeah that part is annoying. i've been working on the gn folks to fix that
<teepee>
I don't know if that strategy is good or bad, maybe their "we always rebuild the world" is a better approach
<teepee>
but it's inherently incompatible with other existing stuff
<JakeSays>
not sure what you mean
<teepee>
a linux distro ships libraries as separate packages
<JakeSays>
right
<teepee>
there's no "i have all the source repos and just build main branch" possible
<teepee>
it's even forbidden by rule for some packages
<teepee>
lib3mf includes a private copy of libzip and zlib
<teepee>
at least one of those is flagged by the debian linter and will prevent the package to be shipped that way
<JakeSays>
i'm not sure why that's an issue. gn isn't for building packages
<teepee>
that's not the point
<tcurdt>
"i have all the source repos and just build main branch" worked just fantastic for the go eco system (sarcasm)
<teepee>
I'm say the google philosopy is "build the world from source for every app"
<JakeSays>
why is that an issue?
<teepee>
because it does not work outside google
<JakeSays>
i dont understand how. i know many projects that work that way.
<JakeSays>
what's wrong with building from source?
<teepee>
again, it's incompatible with distro packaging, I can't just pull in library source from everywhere
<ali1234>
nothing wrong with building from source, but the typical dumb CI pipeline that builds an entire VM then compiles every dependency from source then builds your app every time you make commit is just bad
<JakeSays>
well, i understand it's not compatible with distro packaging, but that's not something most people have to deal with
<teepee>
also for build time reasons it's a no-go, but that's just a minor point
<teepee>
if you build your own stuff, that's fine
<teepee>
I'm providing application builds for people to use in lots of different platforms, so people have a choice
<teepee>
as I said, I'm not really saying one or the other is better
<teepee>
but the google way is incompatible with pretty much any build environment I can use
<JakeSays>
well, gn has nothing to do with how things are actually built.
<JakeSays>
or which philosophy, etc.
<teepee>
the official page says I have to download the build binaries from the google site
<teepee>
OBS has NO network access at build time whatsover
<JakeSays>
only if you dont want to build your own
<JakeSays>
google just provides binaries if you want to use them
<ccox>
^ all this nonsense is why I stick with simple Makefiles and sometimes CMake (when it has to fit into another build system).
<teepee>
and don't care about packaging in distros
<ali1234>
all build systems currently in existence are terrible
<JakeSays>
teepee: so your issue is it's not available in a distro?
<teepee>
so to build on OBS I would need to maintain a gn package myself there so it can be installed in the build process
<JakeSays>
or as a pkg
<ali1234>
every single one is over-engineered
<teepee>
one of the many points
<JakeSays>
ok well i see your point, and for what you do it's an issue, but i don't limit myself to what is or is not available in a distro.
<JakeSays>
ali1234: and yes, they are. lol. but that's to be expected
<JakeSays>
i'll tell ya what's a real pain in the ass - un-twisting and stripping cat5 cables
<teepee>
yeah, even with hands that's already annoying ;-)
<teepee>
hmm, no response from CircleCI, I guess that means no answer this week
<teepee>
oh, oops, missed the calendar door opening, did it work?
<teepee>
whew
<tcurdt>
so - I just realized my homebrew based build has references to those libs in homebrew ... that's not great :-/
<tcurdt>
how is this done for the official release?
* tcurdt
checks an official binary
<ccox>
also beware: homebrew likes to install QT6, which will hose your build (multiple versions of Qt = pain)
<tcurdt>
@rpath
<tcurdt>
I know @executable_path and @loader_path - what is @rpath?
<tcurdt>
ah ... define via LC_RPATH?
<teepee>
that's the point, the simple homebrew build just builds with the homebrew dependencies which is fine for local use
<teepee>
for distribution the script builds the dependencies with min-macos-version=10.13
<tcurdt>
not even for that
<teepee>
hm?
<tcurdt>
"which is fine for local use" me: "not even for that"
<teepee>
why not?
<tcurdt>
that means the app is completely dependant of my homebrew libs ... that's not a great place to be at
<teepee>
of course, if you build via homebrew, it uses the libraries installed that way, how else would that work?
<tcurdt>
well, it could still bundle these up, no?
<teepee>
I suppose you could, but that's not something provided by openscad build scripts
<tcurdt>
what does the bundling via @rpath?
<teepee>
it defines where the libraries are searched by default
<tcurdt>
right - but the bundle needs to build for that as well
<tcurdt>
hence my wondering
<teepee>
the process would be the same as for the dependency build I would assume
<teepee>
yes, but the bundle also needs builds with a sdk version range, not tied to the "whatever the build machine has"
<tcurdt>
it seems the homebrew build references the libs in place, while a release build creates a bundle and references them in there
<teepee>
yes, there's just too much point for bundling the homebrew dependency build as we can't distribute that anyway
<teepee>
we could add some build script for that to the contrib folder, but there's no point in maintaining yet another build version
<tcurdt>
sure ... right now I am just wondering where this happens in the build ... call it curiosity - for now :)
<teepee>
I've tried to maintain and release the macos builds without having any reasonable access to a machine, so I really don't need more variations
<teepee>
luckily kintel had some time to dust of some of the macos build stuff
<teepee>
but that now means I can't even run the builds anymore, previously I could not build but run the bundles coming from the CI systems
<tcurdt>
maybe back to the idea of a mac mini m1 as a ci runner? :)
<tcurdt>
just need to find a sponsor for that
<teepee>
if you find one, send it over :P
<tcurdt>
:)
<teepee>
in theory it would not need a M1 I think, it should be possible to cross build for both Intel+M1
<teepee>
github might add M1 at some point, people asking like every 5 days or so
<tcurdt>
but then github macos runner would already be enough
<tcurdt>
tbh I never tried to build a cross platform build before getting a m1
<teepee>
in theory yes, but getting all the dependency builds working via remote CI is not the amount of time I'm willing to spend
<tcurdt>
well, at least not since powerpc+intel
<tcurdt>
yeah, the feedback loop is not quite the same :)
<tcurdt>
on the other hand - if one would get all to build on a real intel machine ... it should also work on the ci runner
<tcurdt>
so if intel => intel+arm would work ... it might help with the ci situation
<teepee>
depends
<teepee>
right now there's also a struggle with build times, if that would go to twice the compilation time, that would be an issue too
<teepee>
we'll see what the options at CircleCI are, github limits are quite generous still I think, but I'm not holding my breath that this goes forever
<Zauberfisch>
but I don't have the motivation to try and mess around with this svg thing right now
<teepee>
whew and we are green on macOS again
<teepee>
that is really cutting it close
<teepee>
build limit = 1h, build time for Qt5 = 56 min
<teepee>
Zauberfisch: doing just the fun part is certainly the better option
<Zauberfisch>
oh, unless someone wants to build $fn for svg import for like 50$
<Zauberfisch>
I'd be willing to put that up as a bounty. but it's probably ridiculously low compared to the effort
<teepee>
that's fine, that's why it's called bounty not full payment
<teepee>
I would *want* to regardless of money, but I don't see the time for that
<teepee>
2 month vacation would help :)
<InPhase>
teepee: I grant you permission to take a 2 month vacation from work!
<teepee>
yeah, I know, I just have to take it before december 6th
<teepee>
on the plus side, projects for next year seem to be stable, so hopefully no panic approaching ;-)
<teepee>
which might be enough to eventually get something done
<InPhase>
:) I wish you a peaceful time with good balance.
<InPhase>
I'm entering a slightly more intense stretch of work for a little bit. It comes in waves at times.
<teepee>
I've seen that. projects with big companies are always a bit fuzzy at the end of the year. on one side they tend to go into freeze mode with people in vacation, but also may want to spend some money to keep budget or need something quick to deliver for years revenue
<teepee>
not sure how it will go this year with mostly a different big company in the picture :)
<teepee>
normal plan for after christmas days would be CCC watching, which did not happen last year
<teepee>
current estimation for this year... 50:50
<lf94>
InPhase: Curv is kind of stepping on its own toes: if I used GLSL directly I could do those thousands of unions.
<lf94>
I was able to render Day 2 with r = 5
<lf94>
with Curv still - I was able to optimize it a few magnitudes
<lf94>
I just don't feel like it but curv can do it
<lf94>
you just specify `colour <thing>`
<lf94>
I mainly don't care because I can only 3D print in one color ;p
<InPhase>
I was mostly wondering if the approach to color makes certain things tricky.
<InPhase>
Like when you start coloring unions or differences, the rules are less clear.
<InPhase>
Oh, and side tip.. OpenSCAD for loops are end-point inclusive, which is why the top block is out of alignment.
<InPhase>
You're short one block.
<InPhase>
I'd rather OpenSCAD loops not be inclusive, but alas, this is baked in hard by now.
<lf94>
So are Curv actually, I went out of my way to make it exclusive XD
<InPhase>
:)
<lf94>
It's ok, doesn't change much.
<lf94>
coloring the unions would be the same as in openscad
<lf94>
essentially im coloring each cube and then unioning
<InPhase>
The resulting code for this one looks pretty comparable.
<lf94>
if I did do it
<lf94>
yeah.
<lf94>
Remember, Doug comes from an OpenSCAD background
<lf94>
So there will be influence there :)
<lf94>
(Influence in the language coming from openscad)
<lf94>
I'm finding it easier to think in terms of "generate points", "generate rotations", etc, and then combining it all.
<InPhase>
Or, could. Jack212 used a gratuitous module recursion there in what could have been a for loop, but probably mostly for demo purposes on how the rotations and translations stack.
<lf94>
I could've stacked it for curv as well, using recursion
<lf94>
Maybe I should try it
<InPhase>
Tomorrow's should be pretty straightforward for you. The one after that I'm waiting eagerly to see you attempt. :)
<lf94>
We're building up a nice test suite for Curv.next XD
<lf94>
(Doug's next iteration of the language)
<InPhase>
:)
<lf94>
It's too bad you've seen them all
<lf94>
Would've been nice for just teepee to know
<lf94>
Is there /anyone/ else doing the calendar publicly?
<teepee>
that would have been tricky considering I only did the html and admin part :)
<teepee>
what do you mean?
<teepee>
there lots of calendars like fpga, university doing physics videos, ...
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
<InPhase>
I see. You need a blue checkmark to be important.
<InPhase>
Click some buttons and get a blue checkmark! :)
<teepee>
haha, not in 1000 years
<InPhase>
Is there an openscad@openscad.org or something?
<InPhase>
Looks like the requirement is either domain email address that looks official, or the website mentioning the twitter account.
<lf94>
teepee I mean anyone else doing the scadvent calendar you made
<lf94>
teepee I only meant InPhase not knowing :)
ferdna has quit [Quit: Leaving]
<teepee>
if it would be "the calendar I made" it would be just: return "" this year
<teepee>
so much better result via teamwork
<InPhase>
teepee: Looks like the notability requirement is easy to hit. OpenSCAD is all over the news in outlets with blue twitter checkmarks, so that should meet their standard.
<Jack212>
zauberfisch just use the path tool and mark all knots - then click the +Add knot symbol (first one on the bar) this will add knots between the existing and so double them .. (you also can selectively adding them by just double clicking on the path. ( if it is an Object you have to hit ctrl shift c to convert into a path)
af has quit [Ping timeout: 252 seconds]
af has joined #openscad
arebil has joined #openscad
pa has quit [Ping timeout: 245 seconds]
pah has joined #openscad
lastrodamo has joined #openscad
TheAssassin has quit [Remote host closed the connection]
TheAssassin has joined #openscad
Guest828 has joined #openscad
Guest828 has quit [Client Quit]
arebil has quit [Quit: My keyboard has gone to sleep. ZZZzzz…]
arebil has joined #openscad
pah is now known as pa
TheCoffeMaker has quit [Ping timeout: 252 seconds]
Jack212 is now known as Jack21
TheCoffeMaker has joined #openscad
TheCoffeMaker has quit [Ping timeout: 256 seconds]
TheCoffeMaker has joined #openscad
ferdna has joined #openscad
la1yv_b has quit [Ping timeout: 256 seconds]
la1yv_b has joined #openscad
<InPhase>
Jack21: I bet a building following that sort of design would also be very earthquake and high wind resistant. The only challenge would be the elevator layout. :)
<Jack21>
didn't califa looks a bit like that
<InPhase>
Plus, every floor gets its own observation deck, which is kind of nice.
<Jack21>
InPhase if you change the angle you also have to change the size factor as these are linked so every 3rd floor is not piercing through the wall of the first
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
<InPhase>
Jack21: 34 degrees has that problem, but 35 doesn't, as it rotates a notch faster.
<InPhase>
Jack21: I took special notice of the 137.5/4 because I first, in tribute to lf94's efforts, tried to guess the angle by inspection and got 35 degrees. Then I did a top level view and intuitively felt like this was one of those golden angle things. Then I checked the code and saw the one you used, and tried switching it up to my guess of 35. :) The side view looks fine, but the top is just... off
<InPhase>
somehow.
<InPhase>
Perhaps that is the scaling factor though, and shrinking it slower would make 35 look better from the top by almost aligning those vertices to the edge.
<Jack21>
right i also put in the rough number .. else would be 34,3769....
<InPhase>
I suppose rotate(35) and s=s*0.882 works alright visually.
<Jack21>
360/ϕ²
<Jack21>
yeah the changes are usualy not that much - you get a steeper helical angle or shallower
<Jack21>
with 35 it is likely that after some floors it will repeat but no one would notice that
<Jack21>
wait with twist=180 that looks like the other with twist=60
<peepsalot>
no idea what i'm looking at there
<Jack21>
this is the same code .. one with the old one with the current version
<Jack21>
and with the rounded edges this goes awry as the first edge is now sharp and the following round
<Jack21>
anyway i was just making use of some weird behavior so it is good that it is fixed now .. but we should mention the segments in the cheat sheet and documentation
<peepsalot>
except your picture now only shows a single side instead of a hexagon. its really hard to follow what you are doing without any code to reference
<Jack21>
linear_extrude(50,twist=60,slices=1,segments=1)offset(3,$fn=36)circle(10,$fn=3);// and with rounded edges this getting worse when twisting more
<peepsalot>
yes, so for a triangle adding (360/n)=120 makes it act the same as before (60 vs 180 as you noted)
<Jack21>
yes without the rounded edges this works
<Jack21>
but with segments this is also looking nice
<Jack21>
ok tried minkowski instead -- doesn't work well it is now frozen
<Jack21>
with twist 179 minkowski is giving a similar result
<Jack21>
so this is looking nice now but took over 30sec to preview https://bpa.st/ZWWQ
<Jack21>
but i assume it is now without faulty edges
<peepsalot>
also you could probably speed things up with a cylinder minkowski instead of sphere
<Jack21>
the moment i pass the threshold like twisting the hexagon over 60° the minkowski need a long time
<Jack21>
cylinder was ¾ faster
<Jack21>
probably as the polyhedron is going from convex to concave so minkowski need more time
<Jack21>
and shouldn't use segments - Ü
<Jack21>
but looks funny
<peepsalot>
yes i think minkowski requires convex decomposition internally
<Jack21>
it is nice that you get now proper antiprism with twisting
<peepsalot>
Jack21, also, maybe somewhat inconsenquential, but the old behavior was not necessarily always split along the longer side, but i think was tied to twist direction. you might even be able to emulate new behavior on previous release by negating the twist angle
ferdna has joined #openscad
<Jack21>
in my case i used the superposition of negative and positive twist - they looked the same so far
<ccox>
Just created a pull request for SVG import to use $fn, $fs, $fa (the changes went much faster than I expected).
<teepee>
nice!
<Jack21>
i assume for converting the curves they already used those internally
<teepee>
no, it had just some hard coded values
<teepee>
a bit like prototypes last for years in production systems :)
<Jack21>
yes that is what i meant you just need to put variables instead of the hardcoded numbers
<teepee>
ah, right, yeah, that quite possible, for sure for elipse/circle which I looked at yesterday
<teepee>
still as the PR shows, quite some places to work through
<Jack21>
hmm yeah i forgot it is not everything a path
<Jack21>
wonder if the b-spline and bezier are different in SVG .. probably they are
<teepee>
different?
lastrodamo has quit [Quit: Leaving]
<Jack21>
you can have the same curve as b-spline and bezier so just the control points change - and i wasn't sure if that is within the svg format or just something inkscape simulates
<ccox>
I think it is simulated, because I don't see SVG supporting anything other than Bezier
<ccox>
(SVG is basically Illustrator files as XML)
<Jack21>
ah ok
<teepee>
yes, SVG has cubic and quadratic splines, the path does support control point mirroring though, so they connect multiple splines
<teepee>
cubic and quadratic beziers I shold say
<Jack21>
so inkscape has some tag to know what it used to create it
<Jack21>
like "spiro path" - wonder why you can't switch that later
<Jack21>
wasn't aware that quadratic and cubic are different - thought they use cubic and just link 2 control points
<Jack21>
maybe i should add this in my module .. so if p2 is missing p1 is used
ferdna has quit [Quit: Leaving]
<ccox>
Now LGTM analysis is taking longer than the builds...
<teepee>
yeah, it's a bit annoying, and it does not seem too useful either
<teepee>
I do have a question about the CalcFn, it seems to ignore the fa/fs values
<ccox>
yep, because in the cases that use it, we have no angles (just bezier curves)
<ccox>
I couldn't think of a reasonable way to apply fa or fs in that situation.
<ccox>
but improvements could be made in the future, now that the values are available.
<teepee>
yeah, angle is a problem, $fs would be possible
<teepee>
text has some heuristics based on the font size
<ccox>
well, the function of $fs is a whole nother issue (either misdocumented, or mathematically useless based on the get_fragments_from_r code that uses fmax(fmin()) instead of fmax(fmax()) )
<ccox>
And right now, the SVG import ignores text (text::set_attrs does not create any geometry)
<teepee>
yep, only started to collect the data but it's not finished