<kintel>
-> I'm considering generating GLAD source at build time, but I then need another venv setup, and it could be worth abstracting away the machinery a bit
<InPhase>
kintel: Looks like a similar mindset, and the OUTPUT trigger is kind of nice, except it leaves a weakness I tried to work around. My trigger for "try to make the environment" is actually checking whether or not the target script actually passes its import statements.
<InPhase>
I added an "everything's good" command into the target script.
<InPhase>
So it will build the environment if python is missing OR if any of the libraries failed to install.
<InPhase>
A requirements file is the way to go if we pick up a larger pile of python packages. I skipped it for now because we only have two.
<kintel>
Gotcha
<InPhase>
Now if we could make it only run when we try to do ctest...
<kintel>
What I liked was the idea of CreateVirtualEnvironment(venv <some args>) followed by add_dependencies(MyAwesomeExecutable venv)
<InPhase>
I wonder if the add_custom_command can get picked up by ctest like that as a dependency, and run THEN.
<InPhase>
Because I'd toss out my superior library checks if we could move that out of the regular cmake call into the ctest call.
<InPhase>
I feel better about adding this directly where it's needed.
<kintel>
you mean building the venv when running ctest?
<JordanBrown[m]>
Don't forget that sometimes you want to run ctest against one test case, over and over again as you try to debug something.
<JordanBrown[m]>
(drive-by comment, about to be AFK for an hour or so)
<JordanBrown[m]>
I don't have a problem with saying that the test infrastructure is a prerequisite for building OpenSCAD. Anybody doing development should run the tests, and building for a non-standard platform seems like a miniscule slice of the audience.
ur5us has quit [Ping timeout: 250 seconds]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
SamantazFox has quit [Remote host closed the connection]
SamantazFox has joined #openscad
epony has joined #openscad
<guso78>
kintel, probably i w as one of the firsts to realize with 18.04.
<InPhase>
JordanBrown[m]: My ideal approach to that would build the venv upon running ctest if and only if the venv does not yet exist.
<teepee>
guso78: that was a PR, I just merged it, so master should not try to build 18.04 on github anymore
castaway has joined #openscad
<guso78>
must have been an alpha particle X-P
ubitux has quit [Ping timeout: 252 seconds]
ubitux has joined #openscad
ubitux has quit [Ping timeout: 255 seconds]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
snaked has quit [Quit: Leaving]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
guso78 has quit [Quit: Client closed]
Virindi has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
Virindi has joined #openscad
kintel has joined #openscad
<kintel>
InPhase It feels a bit messy to build the test env at test time, this feels more like a build activity
<kintel>
..but we do have a template which generates a cmake file for stuff which needs to run last minute: CTestCustom.cmake
<JordanBrown[m]>
Feels like build environment setup time to me.
<kintel>
I feel build time since it may invoke a compiler to build native python libs
<kintel>
But yeah, these are all external dependencies
<JordanBrown[m]>
Or if one really wanted, have a separate test environment dependencies script so that you don’t have to install the test environment if you don’t ant to.
<kintel>
question is really if the environment is subject to change between setup, build and test
<JordanBrown[m]>
ant -> want
<kintel>
We do have -DENABLE_TESTS
<kintel>
Anyway, none of this solves the msys2 python issue..
<JordanBrown[m]>
But that’s at build time, when I think that download/install stuff should be earlier than that.
<kintel>
wait, when is environment setup time in your book?
<JordanBrown[m]>
For MSYS2, there’s a “get dependencies” script. I don’t happen to remember its name.
<kintel>
It's tricky for venv stuff though, as you need the source tree and some build folder to determine which venvs to build, where to place them and what deps.
<kintel>
We currently only have one venv, but we'll need a few more for other Python programs
<kintel>
I'd love to see good examples of this in the wild
<JordanBrown[m]>
I am not entirely sure what the rationale is for the venv. (Partly that is because I am not entirely certain what a venv is.) It seems like it is an attempt to isolate the Python-library dependencies from the system, probably both to control the exact version used and to avoid requiring having those dependencies formally installed on the system.
<lf94>
Doesnt WSL work for stuff like this
<lf94>
Why not just suggest "build with WSL"
<kintel>
Yeah, you don't want to pollute the system with project-specific dependenciea
<kintel>
..except if it's a throwaway CI VM
<JordanBrown[m]>
But we require that you install cmake and gcc and a ton of libraries.
<kintel>
WSL isn't Windows, it's some weird Linux VM running on Windows. I haven't heard great things about it, except as a Linux Playground for Windows users
<guso78[m]>
Kintel, does my latest PR Match your expectation ? Quite some refactoring, but No effect.
<JordanBrown[m]>
This is a variant of what at work we call the Common Build Environment problem, the CBE.
<kintel>
JordanBrown[m] We do, but we can handle a long range of versions for such common tools
<Scopeuk>
J23 neat, looks like the wheels you get on heavy plant at a land fill
<JordanBrown[m]>
There we keep around many build systems at various frozen versions, to support the various historical builds that we need to be able to recreate for updates.
<JordanBrown[m]>
It’s a horrible thing to do.
<kintel>
Yeah, so we try to do some reasonable middle ground, for stuff that would require a team of people in a company :)
<JordanBrown[m]>
So it’s OK to require the system to have a long list of build dependencies, and to require that we work with a wide range of versions, but it is not ok to do the same for test dependencies.
<JordanBrown[m]>
?
<Scopeuk>
I think it's more, we already have one mess, we are in a position to try and get the testing up without creating a second equally large mess
<kintel>
JordanBrown[m] It's not only us, if you've worked on multiple projects on the same machine, and they all want to install various versions of Python dependencies -> it's a disaster.
<kintel>
Ideally, apt-get would have venvs too, but ala
<kintel>
On macOS, I build an entirely separate tree of dependencies, for this exact reason
<JordanBrown[m]>
Yeah, I’m draconian about that. Work with the latest version, or quit. And if you are the supplier for such a component, and you don’t keep it compatible, you’ve failed.
<kintel>
at least on Linux, we could use Docker for everything.
<Scopeuk>
that is rapidly tending towards containers/chroots/jails/whatever the "light and fast" option of the day is
<JordanBrown[m]>
Which in turn means that five years from now we’re building on today’s environment, because it’s too hard to update,
<JordanBrown[m]>
.
Virindi has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<InPhase>
kintel: Well I'd also appreciate the notion of a completely separate cmake for testing. Although it would be troubling to mismatch the -D parameters. I wish there were a way to pass them but run test setup separately.
<JordanBrown[m]>
Using version-frozen environments for a current build means deferring the inevitable.
epony has quit [Ping timeout: 268 seconds]
<kintel>
In terms of Python, one reasonable idea could be to create a master venv for OpenSCAD at setup time (the script Jordan mentioned), and install everything any Python tools inside our repo would need, and just get CMake to find that venv
<InPhase>
JordanBrown[m]: My idea of "current" is generally "whatever the latest Ubuntu LTS has". :)
<InPhase>
JordanBrown[m]: But I do okay with this definition because these tend to be popular choices.
<JordanBrown[m]>
Creating a venv at setup time would be OK, though there is the question of what to populate it with. Do you try to populate it with particular versions of the dependencies (if they are available), or with the current version?
<InPhase>
I have it set to current at the moment because I'm not doing anything that should change in the foreseeable future.
<JordanBrown[m]>
“Whatever the latest Ubuntu LTS has” doesn’t really scale to other platforms, especially if you are sensitive to the exact version of the dependencies, since everybody’s LTS will have picked different versions. If they have an LTS at all - I’ve seen no evidence that MSYS2 does.
<kintel>
python packages sometimes break when they update, so I's prefer to lag a few weeks at least
gunnbr has quit [Ping timeout: 268 seconds]
epony has joined #openscad
<JordanBrown[m]>
If they break more than very infrequently, maybe it means that they are a poor choice of dependency.
<InPhase>
JordanBrown[m]: Our CI for Linux aligns with my choices, so that helps.
<kintel>
..or generate a pull request upon release, so we can gate it on our CI
<InPhase>
JordanBrown[m]: I think it is important to have one target build method per platform that we make easy and we work on keeping well supported, and then it most of the time will only take a little attention to find solutions here and there for build system specific differences. Usually it's not a huge problem.
<InPhase>
This recent Windows issue with Python is just msys2 being weirdly non-standard about Python environments.
<InPhase>
Mixed with cmake being weirdly inconsistent with its python finding, which let the initial solution slip by.
<lf94>
WSL.
<lf94>
You guys gotta draw the line somewhere, this is bananas
<kintel>
lf94 WSL isn't Windows
<InPhase>
We knew from the moment I first proposed a Python solution for testing that the one platform that would be tricky would be Windows. I went for it after confirming Python was in msys2, and then we accepted it when it passed the CI testing with a few extra steps added in.
<kintel>
if anything avoid WSL like the plague as it's yet another non-standard env
<lf94>
I know it isnt Windows :p
<lf94>
Ok how about just cross compiling for Windows?
<InPhase>
So it's a little frustrating that it turns out the msys2 solution was not actually why it passed the CI. I consider this at the moment a bug in msys2.
<InPhase>
lf94: Well we want to support people who run Windows building on Windows. :)
<kintel>
lf94 Our release binaries are cross-compiled. This is for development
<lf94>
WSL -> cross compile for Windows -> bam. B)
<InPhase>
lf94: I start out convinced this is a good idea for me, if I were stuck for some reason using Windows. :) But I suspect it would be less popular for most Windows-based programmers who want to contribute.
<lf94>
fair
<JordanBrown[m]>
I would really rather not have to maintain a Linux VM for routine work. Though, admittedly, MSYS2 is a lot like one.
<lf94>
time to file an msys bug
<lf94>
maybe file an msys pr :p
<InPhase>
JordanBrown[m]: It would be nice to have the benefits of pacman or similar without all the modifications of msys2. Is that... a thing? Is there an alternate system which does this with a more native Windows like approach using mingw?
<InPhase>
Really we just want library management made simpler.
<JordanBrown[m]>
My impression is that MSYS2 tried to be that thing, more Windows-y than Cygwin.
<JordanBrown[m]>
Um… don’t you also want things like compilers?
kintel has quit [Ping timeout: 250 seconds]
<JordanBrown[m]>
And build tools?
<InPhase>
JordanBrown[m]: Well, cmake and mingw basically.
<JordanBrown[m]>
And gcc. And bison. And whatever the lever generator is called (flex?).
<JordanBrown[m]>
Lexer DYAC
Virindi has joined #openscad
<InPhase>
git, make, bison, flex, cmake, and somthing called "toolchain" are the msys2 items that are not libraries.
<JordanBrown[m]>
I don’t know offhand whether bash is required, but I suspect that it is.
<JordanBrown[m]>
Maybe I am not understanding your point.
<JordanBrown[m]>
They are all build dependencies for us.
<InPhase>
Yeah. I'm updating my point. I forgot those were in the list, because they are to my mind background content.
<Scopeuk>
there is also vcpkg which does dependencies on windows with visual studio integration it's entirely source based though so setup time is huge, I think that is the way ochafik did the last windows build on windows setup. I did have it working for a while but changed machines and never set it up again
<InPhase>
I spend about 5 seconds thinking about needing those items every few years with a new computer.
<JordanBrown[m]>
What is it about those things that makes them require very little attention, where apparently numpy requires much more?
<InPhase>
I don't usually pay attention to either. It's Windows where we're needing attention on them.
<InPhase>
Locally I'm running a 2021-12 release of numpy, installed by apt, and numpy changes slowly enough that this requires no attention.
<JordanBrown[m]>
Is that because Windows/MSYS2 is somehow fundamentally different, or is it just that it’s a different platform and we haven’t ironed out all of the platform differences?
<InPhase>
If I setup a venv I get a newer version, but it's the same. There's one "breaking" change I'm aware of recently involving the deprecation of np.float and np.int, where you're supposed to just use float and int. So image_compare.py uses float instead of np.float for the one dtype where that is present.
kintel has joined #openscad
<InPhase>
JordanBrown[m]: Well I don't have clarity on exactly why the msys2 platform is not working for venv setup. It'll come down to one of our msys2 devs to figure that out. But from the collected information it seems that msys2 has mangled something to the point that it simply is not grabbing the correct Windows wheels from pypi.
<lf94>
probably some env var has to be set
<JordanBrown[m]>
Or worse, it is grabbing *Windows* components when it needs to grab *MSYS2* components.
<InPhase>
JordanBrown[m]: Intuitively I'm interpreting that as a byproduct of it trying to pretend it's not Windows. But... it's Windows. If it grabbed Windows wheels, everything should work fine. The Python code itself is trivially cross-platform. So this is a bug in msys2.
<InPhase>
JordanBrown[m]: Nah, when it goes to that VC6 thing, that's because it actually couldn't find a package matching its infrastructure.
<InPhase>
JordanBrown[m]: But... there are Windows packages for this. So it looked wrong if it didn't find it.
<InPhase>
It's 100% certain it works if it grabs the right ones for Windows. kintel confirmed this, and the CI confirmed this, by using non-msys2 python.
<lf94>
How do you specify Windows python vs Msys2 python
<JordanBrown[m]>
I don't truly understand how MSYS2 works, so I am deeply superstitious about it - it make me very nervous to mix MSYS2 components with Windows components.
<JordanBrown[m]>
lf94: from an MSYS2 bash prompt, if you say "python" you get the MSYS2 Python.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JordanBrown[m]>
Unless you've mucked with $PATH to put the Windows one first, of course.
<InPhase>
lf94: The simplest way is just not installing msys2 python. Although there is a bug in cmake that picks one versus the other based on whether or not you call the deprecated command for finding Python. kintel used that. :)
<JordanBrown[m]>
If we're ending up with the Windows one, it means that some component got confused about which platform it was on, thought it was on Windows, and looked in Windows places for it.
<InPhase>
But yeah, it will find the one first in the path, generally.
<lf94>
could you temporarily modify PATH for cmake operations
<InPhase>
Sure.
<lf94>
then do that
<lf94>
It's a priority issue. Make it highest priority.
<InPhase>
It's not "can't" it's "what is sensible as a dev environment".
<InPhase>
This is "Install all these things with msys2, but then separately setup non-msys2 python, and force it to use that.
<InPhase>
That's what kintel has done to get it working for himself. It's a bit ugly. It would be good if we understood it more clearly as something like, "This version of msys2 python has a bug, so we're working around it" versus "we're doing something wrong with msys2 that we don't understand" or "msys2 will never work for this".
<JordanBrown[m]>
So it seems like the two basic options are (a) figure out how to work with pure msys2, or (b) figure out how to do a truly Windows-native build.
<InPhase>
It feels like it's an msys2 bug, but I don't understand how this bug exists when it should be a huge problem for anyone trying to use python in it, yet I don't see it when I google for the bug.
<lf94>
beauty is in the eye of the beholder.
<JordanBrown[m]>
Which exact problem is it?
<JordanBrown[m]>
Is this the bin / Scripts problem?
<InPhase>
JordanBrown[m]: The problem as I would define it is: msys2 python does not find Windows wheels when pip installing.
<JordanBrown[m]>
I don't know if I can help with that, because I don't even know what a wheel is. And while I know a little what a pip is, only a little.
<JordanBrown[m]>
But I would also wonder why we are using two different install technologies - the system-native install technology, and pip.
<JordanBrown[m]>
If we want numpy, why aren't we installing mingw-w64-x86_64-python-numpy?
<JordanBrown[m]>
With pacman?
<lf94>
InPhase: that sounds like... expected behavior
<lf94>
Why would it ever use Windows wheels in that case? It'd use msys2 wheels
<lf94>
You have to pick a system I'd expect.
<lf94>
Mixing the two is asking for pain
use-value has quit [Remote host closed the connection]
use-value has joined #openscad
kintel has joined #openscad
<lf94>
I get it, you want to use best of both worlds. Unfortunately it seems the worlds do not want to collide.
<JordanBrown[m]>
Worlds colliding is generally bad for children and other living things.
agnes_de_lion[m] has quit [Quit: You have been kicked for being idle]
<kintel>
Sometimes I do wonder how people do native Windows development? Are they all just downloading a magic zip file with dependencies and hope that the person who created the zip file doesn't drop off the planet?
<lf94>
kintel: that was beautiful.
<JordanBrown[m]>
I am not sure, but I think the answer is that they use an entirely different ecosystem centered around Visual Studio.
<JordanBrown[m]>
Other than OpenSCAD, my small amount of Windows development is actually Node.js development - and there npm is the center of the universe. (And there was a huge and ugly setup involved in getting npm working, though it was mostly just following a long checklist.)
ubitux has joined #openscad
<InPhase>
lf94: Because msys2 is NOT a separate platform. It runs Windows binaries just fine.
<JordanBrown[m]>
But it's also not NOT a separate platform :-)
<lf94>
Yeah like... how can you say it's not? "platform" is not the right word here.
<lf94>
Windows is a set of tools; Msys2 is a set of tools. The sets cannot overlap without pain.
<lf94>
completely unrelated
<lf94>
how would you model a duck bill in csg
<JordanBrown[m]>
Bezier patches.
<lf94>
_csg_ :)
<JordanBrown[m]>
What, exactly, does CSG mean?
<lf94>
constructive solid geometry...
<JordanBrown[m]>
is polyhedron() not CSG?
<lf94>
describing the surface with patches is like saying "just draw it"
<InPhase>
"Use msys2 shell for running pacman, makepkg, makepkg-mingw and for building POSIX-dependent software that you don't intend to distribute. Use mingw shells for building native Windows software and other tasks." https://www.msys2.org/wiki/MSYS2-introduction/
<InPhase>
JordanBrown[m], kintel: Have either of you two tried using msys2 and building from the mingw shell instead?
<JordanBrown[m]>
lf94: Well, kind of, yes.
<JordanBrown[m]>
I don't know what "the mingw shell" is.
<InPhase>
Basically just a bash shell that doesn't try to pretend it's a posix environment.
<JordanBrown[m]>
The icon that I click on is called "MSYS2 MinGW 64-bit".
<kintel>
I used mingw to build native stuff back in the dark ages, before I uninstalled Windows for what I hoped was the last time : /
<JordanBrown[m]>
And what does "doesn't try to pretend it's a posix environment" mean?
<kintel>
..but it was a crazy mess to set up a build environment
<JordanBrown[m]>
Does "cat" work? That's pretending that it's a POSIX environment.
<lf94>
it doesnt try to not be windows.
<InPhase>
JordanBrown[m]: You don't get the whole virtual posix filesystem thing going on.
J23 has quit [Quit: Client closed]
<lf94>
InPhase: this sounds like the right path.
J23 has joined #openscad
<InPhase>
JordanBrown[m]: Instead you're just in a bash shell on Windows, and you can still run stuff like cmake, git, make, gcc, etc.
<JordanBrown[m]>
I don't know how to find a shell that doesn't have the virtual file system.
<kintel>
InPhase mingw shell only supports msvcrt, according to docs. I'm not sure I want to open that can of worms again..
<lf94>
Isnt msvcrt *the* way to build windows stuff
<kintel>
It's the legacy way, AFAIU. UCRT is the new eway
<JordanBrown[m]>
My MSYS2 install came with four icons (MSYS, MinGW 32-bit, MinGW 64-bit, MinGW UCRT 64-bit). I use "MinGW 64-bit". They all present the virtual file system.
<lf94>
> mingw ucrt
<lf94>
maybe the docs are outdated
<kintel>
oh, nice.
<lf94>
JordanBrown[m]: maybe there's some confusion? I think a VFS would have additional directories that are necessary in a POSIX system
<lf94>
Just because it presents the FS like /some/stuff insntead of \Some\Stuff, I think doesnt make it POSIX
<kintel>
I feel what OpenSCAD really needs is someone who wants to own Windows builds, and is intrinsically motivated to fix broken stuff, and ideally spend their time in Windows because they like it :)
<JordanBrown[m]>
Yep. They all have, say, /usr.
<lf94>
kintel: yes.
<lf94>
kintel: also is there user stats on who uses openscad on windows
<JordanBrown[m]>
And /dev and /etc and all of those UNIX-y directories.
<lf94>
"the majority probably do"
<JordanBrown[m]>
And they do not have /Program Files.
<kintel>
Anyway, next time I boot into Windows, I can try to the mingw-ucrt stuff
<lf94>
JordanBrown[m]: ah ok. Then ... no idea
<kintel>
lf94 We don't collect user stats, but download stats show a lot of Windows binary downloads
<lf94>
sufficient enough
<lf94>
is there really no windows lovers here that are devs that use openscad?
<lf94>
that's nuts
<JordanBrown[m]>
I wouldn't say that I'm a Windows *lover*. But I'm a Windows *user*.
<kintel>
The running theory is that Windows dev is so annoying that people only do it for sufficient $$ ;)
<JordanBrown[m]>
The problem is that I'm really not a Windows *developer*. My professional life is all UNIX.
<kintel>
We do have one, who we could try to motivate further though
<kintel>
.but they kind of lost steam because CMake setup is so complicated to pull off correctly
<kintel>
I wouldn't hesitate throwing a few thousand $ towards this, if we find a trustworthy dev
<kintel>
It's always hard though, to transition from being paid to volunteering afterwards. GSoC was supposed to facilitate that, but I think we see very little activity afterwards
<kintel>
..or we do it the other way; go all-out fundraising and get enough donations to pay everyone by the hour :)
<InPhase>
JordanBrown[m]: Okay, I happen to be at work instead of at home, where I actually have a non-msys2 mingw shell on one system. It too has /etc and /usr/lib
<JordanBrown[m]>
Speaking for myself... the problem is that a few thousand dollars isn't enough to get my attention. Figure out how to give me another few hours per day.
<kintel>
Yeah, I don't expect anyone here to be too motivated by $
<lf94>
OpenSCAD Patreon would help us.
<lf94>
I'm highly motivated by money to work on OpenSCAD
<lf94>
I will gladly boot up my Windows PC and grind this shit out
<lf94>
if it were paid
<lf94>
:^)
use-value has quit [Quit: use-value]
<lf94>
I mean I think any of us would.
<lf94>
Working on OpenSCAD full time sounds like a dream
<lf94>
(or anything code cad related, for me)
<JordanBrown[m]>
Not for a few thousand dollars. Sure, pay my regular salary (or maybe even half my regular salary; I'm thinking of retiring and it would be a good retirement job) and we can talk. But until I can quit my day job I don't have the time and energy.
<kintel>
I was thinking about this quite a bit in the past, and one if the blockers for pulling this off is that managing a fundraised project is a fair bit of work in itself, and I'd rather spend my small amount of spare time to write code, not managing people.
<kintel>
..and we do live in a very expensive part of the world : /
<JordanBrown[m]>
You live in a frozen wasteland :-)
<kintel>
haha, yeah, heating cost is half my wage :)
<JordanBrown[m]>
Need an apartment over a data center.
<kintel>
I just got a PC; I just leave it on; heat is covered now
<lf94>
yeah. Canada living standards became bonkers after covid.
<kintel>
heh, yeah, if I didn't have a family I'd definitely just eat all my meals at the office and save crazy $
<lf94>
do you think the economy will collapse
<lf94>
or we're far from it
<lf94>
sorry, crazy off topic lol.
<lf94>
I think it won't, but people are feeling the strain for sure
<JordanBrown[m]>
Speaking of $$$, it's time for me to pretend to do the stuff they pay me for.
<lf94>
Im building a large system by myself, so I see these conversations are just preventative for burnout
<juri_>
this will end after there has been a lot of fire.
<kintel>
a lot of fire, where the rich get richer and everyone else get poorer
califax has quit [Remote host closed the connection]
califax has joined #openscad
<peepsalot>
linext, J23: that's a whole lot of non manifold geometry. all the bottom edges of pyramids share more than 2 faces. you would need a cube() base that extends some non-zero amount below z=0 to make it right
<J23>
yes just add some spacing
<guso78>
same as as klein bottle. it only appears tight to the viewer,but when just unioning with somesthing unrelated, far too much gets filled.
b34r_dev has quit [Quit: Client closed]
J23 has quit [Quit: Client closed]
J23 has joined #openscad
<joseph_>
teepee: The GSoC proposal deadline is now past, so what I most recently uploaded is locked in. I'll await the May 4th announcement of decisions
<joseph_>
I do find it interesting that (at least in terms of GitHub comments) the STEP support seems to be what the fewest number of potential contributors want to work on. It does seem like that would be a very useful feature to have
<lf94>
J23: challenge: duck bill.
<lf94>
joseph_: we're all motivated by different things
<Scopeuk>
joseph_ I think the problem is that whilst valuable it's not an interesting technical problem
<lf94>
STEP is a very enterprise format
<lf94>
and not useful to most of (probably all) us
<Scopeuk>
Additional compatibility is always beneficial but there are few packages that will read a step but nothing else
<teepee>
it's asked for quite a bit, mostly people trying to send designs for fabrication instead of self printing
<kintel>
guso78 Re. printutils: Yes, looks like a leftover variable. Ideally, all such local stuff should be moved to an anonymous namespace to ensure it's not used outside the compilation unit
<kintel>
^ if we do, we should be able to trigger some compilation or lint warning
<guso78>
kintel, i actually found it when *also* adding a debugging "count" variable and got an unexpected linker collision
<guso78>
Rabbit turns into a lamb by offsetting . Happy easter ...
<joseph_>
guso78: I haven't been completely following the progress on this feature, but I've done a bit with SDFs due to their popularity in research. Is OpenSCAD using marching cubes to produce a mesh?
<guso78>
joseph,i have thought about a process calculate an SDF value from a given polyset(the reverse way), this is why i "label" it "reverse SDF"
<guso78>
normallyou calculate polygons from SDF
<kintel>
Does anyone here happen to know a quick way of porting an old ARB vertex program to GLSL?
<kintel>
It's probably easy, but I want to avoid analyzing it ;)
<kintel>
Context: Kill the really old legacy stuff in OpenCSG (OpenGL 1.x stuff), to prepare for modernization
<guso78>
Does anybody know, how well libfive can handle discontinuity in the SDF function ? this can hardly happen with equations, but much more likely in my case.
<kintel>
It's gonna be fun to get manifold into Debian : /
Guest9137 is now known as Sauvin
<teepee>
yep, just commented that on the PR
<kintel>
That is the Google approach though: Submodule every possible dependency, including the compiler
<guso78>
will manifold become available as "package" to the distros ?
<teepee>
yes, works for google with lots of people with few apps
<teepee>
totally impossible in the "real" world
<kintel>
yeah, just seeing the mentality leak through here, since it's so much easier for a single dev to manage
<teepee>
I thought about getting some library build of Manifold. looking at all the recursive submodules I just threw in the towel after 10 minutes
<teepee>
I'd extend that to "... manage when ignoring security issues"
<teepee>
I get notifications from Ubuntu for rebuilding the Snap package about every 2 weeks
<kintel>
heh, yeah. There are two types of developers: The ones who focus on writing beautiful code and those who focus on delivering a product
<kintel>
We need both, but it's way more fun to belong to the first group
<kintel>
I've been thinking though: Perhaps the right balance in such cases is to do include manifold as a non-recursive submodule, write our own build system for it, and manage dependencies as first-class OpenSCAD dependencies
<lf94>
"discontinuity" as in, random pieces broken all over
<lf94>
The marching cubes needs enough "material" to make a manifold object
<lf94>
if there's way too much "jank" in the model, it wont turn out well
<lf94>
like something that is twisted like crazy
<guso78>
lf94, thanks, skeleton is done. improvement position located. now investigating
<guso78>
lf94 my algorithm turns an polyset into a program once before running the meshing. this program is about 1000 LOC for the rabbit. each Line of code checks the testpoint against a test plane and then decides whether to branch left or right.
<guso78>
for the rabbit about 10 decisions are taken, than my algorithm can calculate the SDF distance right away
<lf94>
interesting :o
<lf94>
what's the SDF perf ? pretty good or expensive?
<guso78>
now i am using an orcacle instead of an SDF tree and it fells way slower.
<lf94>
it certainly will be
<lf94>
I think the oracle is not the way to go. Especially with Fidget being JIT, speed on par with GPU interpreted.
<lf94>
I left OpenSCAD because its speed stopped me from doing more interesting models
<guso78>
did some test with a simple cube with resolution is about 1/3 of the object size and the eval distance function was called about 5000 times. this is INSANE!
<lf94>
well, that's the case... it has to eval for each point in space
<guso78>
i suggest to use TREES at ANY cost. its way faster!(plus it can be outsourced to GPU)
<lf94>
libfive does use trees doesnt it?
<lf94>
it also does computation reduction ("tape shortening")
<guso78>
libfive can do both
<guso78>
to use oracle you need to use c++. trees are possible in c and in c++_
<lf94>
Could you explain your usage of trees a bit more to me, maybe in a PM?
<lf94>
Or maybe write it out in a text file
<guso78>
lf94, probably best documenation is my branch 'libfive' in my openscad fork
<guso78>
i will prepare a snipped of code, give me few mins
<lf94>
code isnt the easiest way to understand things a lot of the time for me, especially when im pressed for time ^^ Id just like to get the general idea!
<lf94>
I find code has a lot of nuances that aren't necessary to understand the bigger picture
<lf94>
(It's good to mention the naunces in passing, but not in the explanation)
<lf94>
(It's then useful to see the nuances in actual code after understanding the bigger picture)
<InPhase>
"<kintel> haha, yeah, heating cost is half my wage :)" The key is for us to invest in a build-server / bed combo unit.
<InPhase>
Like the Matrix, but backwards. Human heat fins.
<lf94>
this is the type of stuff sdf() would be fantastic at
<lf94>
You create an infinite field of diamonds on all directions
<lf94>
and then you difference out what you need
<lf94>
B)
<lf94>
linext: I think you have to define a bezier patch and lay out your knurls on it.
<lf94>
Alternatively if you cut out a cylinder it'd be easier, I think
<lf94>
(Easier to layout on a cylinder than a bezier patch I think)
<lf94>
(lots of I thinks...)
gknux has quit [Quit: ....and i am outta here....]
gknux has joined #openscad
<Lagopus>
what was more processing cost intensive, intersection() or difference() ?
omegatron has joined #openscad
<lf94>
I think difference
<lf94>
Because I think difference uses intersection
<lf94>
trying to recreate it in my head :p
<juri_>
they're both 'just' math functions, but intersection should take less, as the bounding box can be shrank.
<lf94>
juri_: I think one can implement the other
fedorafan has quit [Ping timeout: 248 seconds]
<lf94>
but not the other way around
<juri_>
lf94: have we been 'formally introduced'? :)
<lf94>
dont think so
<juri_>
lf94: so, i'm julia longtin. i'm the maintainer of implicitcad, and author of hslice.
<lf94>
ah
<juri_>
i'm not going to say i'm right by power of authority, because gods know i'm wrong a lot...
<lf94>
oh im not saying difference can be its own thing btw
<juri_>
but i know a thing or two about SDF systems, if you ever want to discuss them.
<lf94>
cannot be*
<lf94>
i think maybe we have chatted here in the past lol
<juri_>
including: if you have a rotate function, its possible to have a bounding parallelogram that is not box-shaped. ;)
fedorafan has joined #openscad
<lf94>
see the sdf stuff we did over the weekend?
<juri_>
yep. i've been watching. mildly interested, to see someone else doing the same thing, but differently. always good to crib what notes i can. :)
<juri_>
i've been writing a slicer as of late, so pretty stretched. having a one-person SCAD system was bad enough, but now i also have a slicer.. so i am a one person 3d printing stack, that sucks! :)