<teepee>
in <> the type to produce, in () only the parameters to the constructor
<lf94>
i want to stop looking at c++ as fast as possible
<lf94>
i will stay up until 3am to finish this today
<lf94>
as you see, we're not far
<lf94>
it'd be nice if someone explained how to use the evaluator with the Value (FUNCTION) while I do the quick code to turn the libfive_mesh into PolySet
<lf94>
/home/lee/other/openscad/src/core/SdfNode.cc:108:105: error: no matching function for call to ‘libfive::Tree::Tree(<brace-enclosed initializer list>)’
<kintel>
lf94 The step from "C++ is insane; I'll never touch it again" to "C++ is the shit" can be quite small. I recommend reading https://www.stroustrup.com/tour2.html
<kintel>
..but you kind of have to be above average concerned about performance
<lf94>
Zig is where it's at
<InPhase>
lf94: That sounds like you just need a single libfive entry somewhere in the CMakeLists.txt file.
<lf94>
I did Rust for 3 years, it was nice, but it has its own issues too
<InPhase>
lf94: Did Curve use cmake?
<lf94>
iirc yes, curv did
<lf94>
we are now stretching my brain
<lf94>
real good
<InPhase>
lf94: To save time you can check how Curve did the library linking in the cmake file.
ur5us has quit [Ping timeout: 250 seconds]
<lf94>
oh god please
<InPhase>
lf94: Possibly a "target_link_libraries" entry.
<lf94>
the cmake file doug wrote is... not pretty
<lf94>
I feel like it's Enterprise CMake
<InPhase>
Hold on, I already have this repository.
<lf94>
no that's right. doug builds libfive like it's part of curv.
<lf94>
i think it's beer time
<InPhase>
Yes, he does build it.
<InPhase>
What approach were you taking?
<lf94>
link it to libfive.so
<lf94>
in /usr/local/lib/
<JordanBrown[m]>
InPhase: yes, sort of. Got a few days behind.
<lf94>
that's the approach i'd like to take
<lf94>
Because with my node-libfive bindings, and then openscad, it will make sense for distro packagers to start packaging libfive.
<JordanBrown[m]>
Thanks for the complement, but to be clear my professional life for the last 29 or so years is Solaris.
<InPhase>
lf94: And now you're into one of the tricky parts. We'll need to think for a moment about what the optimal approach is to get libfive included so that it will build across all the platforms and on the CI's and so on.
<JordanBrown[m]>
I am a Windows user but only do hobby development there.
<InPhase>
lf94: It's an opportune moment to ping kintel and teepee and say, "Help advise!"
<lf94>
not really, im at the point where i need to just get this it build without thinking about that
<lf94>
> get this it
<lf94>
my brain right now
<JordanBrown[m]>
Anyhow, WRT running the tests… I haven’t done much recently, and I haven’t run them in a long time.
<InPhase>
lf94: Pending that, for testing purposes locally, you can just toss this into a target_link_libraries line as "libfive" and it should work. Put a TODO comment above the entry that this is a quick entry for local testing.
<JordanBrown[m]>
I can certainly clone a repo and build and try.
<InPhase>
target_link_libraries(OpenSCAD PRIVATE libfive) Under the assumption that /usr/local/lib will already be in your search path.
<lf94>
ok, nice
<InPhase>
lf94: There's a possibility it needs to actually be: target_link_libraries(OpenSCAD PRIVATE five)
<lf94>
ill try both
<InPhase>
lf94: We don't usually have "lib" in the proper name of libs, but Linux has a convention that the resulting g++ parameter -lfive means "libfive.so"
<InPhase>
Or, ld parameter, ultimately.
<lf94>
yeah. it's a weird one
<InPhase>
So I think "five" will map to "-lfive" which will map to "libfive.so".
<lf94>
trying now
<lf94>
then the final thing is to get the evaluator on the function.
<lf94>
do I have to rerun the cmake machinery
<InPhase>
Yes.
<lf94>
:(
* lf94
sheds a tear
<InPhase>
And it doesn't hurt to do a clean build when you mangle a bunch of things like that.
<lf94>
oh thank god i didnt lose the already built stuff
<lf94>
it takes so long to build
<lf94>
:ooo
<InPhase>
Are you doing parallel?
<lf94>
it built!
<lf94>
ok. i wonder what happens if i try it lmfao
<InPhase>
Dibs on segfault.
<lf94>
./openscad: error while loading shared libraries: libfive.so: cannot open shared object file: No such file or directory
<lf94>
interesting
<InPhase>
Hmm.
<lf94>
ill bring it into the directory
<lf94>
a copy of it
<teepee>
export LD_LIBRARY_PATH=/usr/local/lib
<lf94>
hm, nope
<teepee>
or wherever the file is
<InPhase>
teepee: You'd think it would pick that up...
<teepee>
it may need to re-config still if a new file appears
<lf94>
next hand. minimums now raised to 0.001 mBTC.
<InPhase>
teepee: Ah, yeah.
<lf94>
ok so seg fault...why
<InPhase>
lf94: So before you panic and start hunting for bugs, do a clean build.
<lf94>
most likely, parameters is freed?
<lf94>
for what it's worth the window started
<lf94>
i saw the viewer
<lf94>
augh, i really dont want to
<lf94>
im gonna waste like 30 minutes waiting for build
<InPhase>
lf94: I have spent WAY too many hours of my life hunting for bugs that were just failure to build properly that should have been a clean build.
<InPhase>
lf94: Hold on.
<lf94>
if you really think this is the case... ok
<lf94>
I would rather, at this point, you guys just review what's there
<JordanBrown[m]>
InPhase: the fact that -lfoo gets you libfoo is not a Linuxism. It dates back to at least UNIXv7.
<InPhase>
lf94: I call it "oscadcleanbuild" It will give you a reproducible build, and it tries to do it in parallel.
<lf94>
it's gonna eat my memory
<lf94>
better stop chromium and spotify
<InPhase>
How much RAM?
<lf94>
8gb
<InPhase>
lf94: Drop the -j8 to... 4?
<teepee>
with 8gb I'd say 3 max
<lf94>
ok, running
<lf94>
too late, at 4
<lf94>
I closed everything but my terminal windows
<teepee>
then hope it's not going 4 way on cgal :)
<InPhase>
So 8 minutes if you're lucky and the system can handle it.
<InPhase>
teepee: We should really try to force those to be spaced out...
<lf94>
scary how it jumps from 1GB to 4GB in like 1 second
<InPhase>
I don't hit this problem, but it would really speed up things for a lot of people.
<lf94>
Ive had openscad build process swap kill my machine so many times
<InPhase>
If it swaps too heavily then this will not speed it up.
<lf94>
I know I know
<InPhase>
But, good luck. :)
<lf94>
After this I should make the fork or PR
<teepee>
safe bet is 4g per compiler, absolute minimum 2g for gcc
<JordanBrown[m]>
If you want to improve the performance of your system, your first step should be to add RAM. On a consumer system, you probably want to max it out.
<teepee>
using clang helps
<lf94>
so you guys can start to poke at it
<lf94>
I feel like I was pretty useless for this whole thing but at least I got it going
<InPhase>
I see we have a: set(CGAL_DO_NOT_WARN_ABOUT_CMAKE_BUILD_TYPE TRUE) Next we need a: set(CGAL_DO_NOT_BUILD_ALL_AT_ONCE TRUE)
<lf94>
48%
<JordanBrown[m]>
InPhase: did you see my messages above?
<lf94>
ok next: the evaluator. anyone know where i can start quickly
<InPhase>
JordanBrown[m]: It kind of scrolled past in a blur, but I caught them now. :)
<InPhase>
JordanBrown[m]: Yeah, it'd be a great test to see if the tests will run for you on a recent master.
<teepee>
lf94: with the two lines above creating the Builtin-Context you should have most of the preconditions already
<InPhase>
JordanBrown[m]: And ping kintel on the result. (Even if kintel is offline. He's good about checking the log.)
<InPhase>
JordanBrown[m]: You are msys2, right?
<JordanBrown[m]>
Yes, I do my OpenSCAD builds with MSYS2.
<InPhase>
Excellent.
<teepee>
lf94: getExpr() is the function body, and getArgs() has the default values (maybe ignore for now)
<JordanBrown[m]>
InPhase: kintel: cmake failed
<InPhase>
Log details?
<teepee>
lf94: CallableFunction might be the one to look at
<JordanBrown[m]>
hold
<JordanBrown[m]>
CMake Error at submodules/manifold/src/third_party/CMakeLists.txt:8 (add_subdirectory):
<JordanBrown[m]>
directory.
<JordanBrown[m]>
add_subdirectory given source "clipper2/CPP" which is not an existing
<JordanBrown[m]>
I think that if you have a Value::FUNCTION you will want to do a new FunctionCall(...) to get an Expression.
<lf94>
I think teepee said this
<lf94>
and then ... awawww yeeeaaaa ... we call FunctionCall::evaluate and we're done
<lf94>
Get the Value, toDouble(), give it to libfive.
<JordanBrown[m]>
But then that problem recurses, because you would need an Expression that returns the Value::FUNCTION.
<InPhase>
JordanBrown[m]: I decided after my last comment I should probably make sure it still works on Linux. :) But it does. Fresh pull, clean build, and test run passes.
<lf94>
ok, holy moly, openscad is rebuild. lets see if it still segfaults
<lf94>
(most likely)
<InPhase>
kintel: Although for some reason we have a whole lot more tests marked "Disabled" now than I remember. Do you know if someone was turning some off recently?
<lf94>
what was the LD magic again? LD_PRELOAD_something
<JordanBrown[m]>
cmake overall succeeded(?) but it looks like something bad happened in your Python setup.
<JordanBrown[m]>
It's bothersome that it claims it succeeded when something in the middle failed.
<InPhase>
JordanBrown[m]: I intentionally made that a warning and not a failure, because it only prevents testing.
<lf94>
I think I may be part of the openscad group still
<JordanBrown[m]>
Mixed feelings.
<InPhase>
JordanBrown[m]: But, uh... where are the lines for actually executing python?
<lf94>
Can I just push this branch
<InPhase>
JordanBrown[m]: Yeah, I was worried about exactly this situation. I didn't want it to block people who just wanted to build, and weren't trying to do development.
<JordanBrown[m]>
InPhase: I don't understand what you mean by "the lines for actually executing python"?
<InPhase>
JordanBrown[m]: Well this line runs: message(STATUS "Setting up testing venv for image comparison")
<lf94>
may lf94 push branch "libfive" to openscad/openscad? y/n
<InPhase>
JordanBrown[m]: And then there are 3 executes after it, which produce a bunch of output normally.
<JordanBrown[m]>
bash: C:/msys64/home/Jordan/openscad/master/b/DELETEME_LATER/Scripts/python.exe: No such file or directory
<JordanBrown[m]>
MSYS2 is only vaguely Windows.
<JordanBrown[m]>
It's bash.
<InPhase>
Can we hunt for where python.exe went inside of the DELETEME_LATER directory?
<JordanBrown[m]>
First we have to hunt for where DELETEME_LATER went.
<InPhase>
Oh. Well, that should be in the directory you were in when you ran that command.
<InPhase>
I was assuming /master/b
<JordanBrown[m]>
yes, which is the top of the OpenSCAD repo.
<JordanBrown[m]>
yeah, no, I never cd into the build directory. That's what scripts are for :-)
<InPhase>
Okay, well adjust those for the right location I guess, and try those two in sequence.
<InPhase>
They should be noisy with either success or failure.
<InPhase>
BUT, if "Scripts" or something has changed, this is a serious issue.
<JordanBrown[m]>
It dropped python into DELETEME_LATER/bin.
* InPhase
sighs.
<InPhase>
Okay, so "bin" is standard, but our CI version of python was dropping them into Scripts under Windows.
<JordanBrown[m]>
Which, perversely, seems like a lot more UNIX-y directory than "Scripts".
<InPhase>
But now your version on Windows is using bin. What am I supposed to do, search for it?
<teepee>
lf94: ok, try again please
<lf94>
roger
<InPhase>
The Python docs still say, "A virtual environment may be “activated” using a script in its binary directory (bin on POSIX; Scripts on Windows)."
<lf94>
success
<JordanBrown[m]>
MSYS2 is in many ways more POSIX than Windows.
<InPhase>
JordanBrown[m]: The 2007 commit with 2022 and last week review comments is mildly amusing.
<InPhase>
JordanBrown[m]: I guess I can do like an if exists check...
<JordanBrown[m]>
I don't know how all of the components (cmake, python) fit together, but there is a good argument that MSYS2 is *not* a Windows platform.
<JordanBrown[m]>
And presumably that's what Python thinks, since it's using "bin".
<JordanBrown[m]>
So it seems like for this purpose our cmake stuff needs to treat MSYS2 more like POSIX than like Windows.
<JordanBrown[m]>
But I am afraid I have not tried to understand how cmake works, so I am not immediately helpful in doing that.
J236146 has joined #openscad
<teepee>
lf94: I'll probably have a look, not now though, should be in bed at least before the sun goes up again :)
<InPhase>
JordanBrown[m]: I cannot bpa.st the updated tests/CMakeLists.txt, but here's a diff: https://bpa.st/UBWPG
<InPhase>
JordanBrown[m]: I "think" this should correctly switch over to bin if Scripts is empty, and warn out if both fail.
<InPhase>
JordanBrown[m]: Oops, I'll change that to a warning instead of a status. But that's not relevant for the purpose of you testing.
J2361 has quit [Ping timeout: 260 seconds]
<InPhase>
JordanBrown[m]: If you give me a green light on this fixing it I can PR it.
<InPhase>
Although this was not kintel's issue, so we'll have to get past this to see if you have the other one. :)
<lf94>
teepee: jesus lol.
<JordanBrown[m]>
Haven't tried it yet, but it looks like you want to do something at around line 65 so that it will find the venv if it already exists.
<lf94>
teepee: ill try to finish the functioncall bit now
<lf94>
teepee: to the point of it at least compiling
<lf94>
ill leave the rest for you and friends
<lf94>
*maybe* ill get lucky and resolve the segfault
<lf94>
maybe InPhase is feeling extra helpful
* lf94
nudge
<JordanBrown[m]>
InPhase: Can't say that I'm happy with the cmake downloading and installing things, even into some local directory. I would think in terms of considering those things to be build environment prerequisites.
<JordanBrown[m]>
InPhase: it blew up complaining that "VC 6.0 is not supported by this module": https://bpa.st/JGQ5C
<lf94>
building on windows? you're a mad man
<JordanBrown[m]>
BTW:
<JordanBrown[m]>
:: Replace mingw-w64-x86_64-qscintilla with mingw64/mingw-w64-x86_64-qscintilla-qt5? [Y/n]
<JordanBrown[m]>
Doing a full msys2 upgrade just in case.
<JordanBrown[m]>
Not that I deeply know the boundaries between MSYS2 and MINGW to know if it's the exact right test.
<kintel>
it's a hack, there might be a cleaner way
<JordanBrown[m]>
Yes, you might think that there would be a way to ask Python where it's going to put stuff.
<kintel>
The above PR also fixes the test issue, but only on my local machine, because FindPython3 prefers the native Windows Python on the CI machine
<kintel>
...modulo fast-csg crashing : /
<JordanBrown[m]>
I dimly remember issues where something was finding the Windows Python install in preference to the MSYS2 Python, but I don't remember any details.
<lf94>
why does FunctionCall need a location when location is already supposedly in Expression
<JordanBrown[m]>
I expect that theoretically they can be on different lines.
<lf94>
they're one of the same
<InPhase>
kintel: Welcome back. I suspect that "try both" solution is more robust than the "AND NOT MINGW". But, a frustrating inconsistency.
<lf94>
How do I pass values to FunctionCall, doesnt seem obvious
<InPhase>
kintel: And I guess you've seen JordanBrown[m] gets the same "VC 6.0" error indicative of some sort of wheel or setup issue causing it to try to fall back to the build.
<InPhase>
kintel, JordanBrown[m]: I'm not really sure what to do to resolve it.
<JordanBrown[m]>
lf94: the arguments are the arglist argument to the FunctionCall constructor.
<InPhase>
Someone with the issue will probably have to poke at things. I tried google a bit.
<JordanBrown[m]>
But I am not sure that FunctionCall is what you really want; I suspect that you need something one layer lower.
<lf94>
Hm, I figured this - I was thinking why teepee told me to use getParameters()
<lf94>
no no, this is good
<lf94>
I need to construct the arg list, you're right
<JordanBrown[m]>
What worries me about FunctionCall is that it wants an Expression that evaluates to the Value::FUNCTION, and you already *have* the Value::FUNCTION.
<lf94>
erm, "AssignmentList"
<lf94>
erm, does it not evaluate when called ?
<lf94>
how do I evaluate Value::FUNCTION
<lf94>
someone help me
<lf94>
sorry, this is me getting cranky
<JordanBrown[m]>
In C terms, the Value::FUNCTION is a function pointer.
<lf94>
was teepee wrong then
<JordanBrown[m]>
The argument to the FunctionCall is an expression that evaluates to that function pointer.
<JordanBrown[m]>
yeah, I was looking at that and do not understand it yet.
<teepee>
you don't call tht
<lf94>
teepee you gotta pull an all nighter with me
<lf94>
we will be code brothers
<kintel>
InPhase In my case, the solution was to install msys2 versions of all python packages we need. Not a great solution, but fine as long as nobody uses any Python libraries not packaged by msys2
<teepee>
constructor checks if the expression is of type FUNCTION
<JordanBrown[m]>
Right, but he doesn't (or shouldn't) have an expression. He has a Value.
<lf94>
teepee: what should i call
<JordanBrown[m]>
The expression should already have been evaluated to yield the Value::Type::FUNCTION.
<lf94>
snip snap snip snap snip snap
<teepee>
FunctionCall->evaluate(context)
<teepee>
I would hope
<lf94>
that's what i thought too
<lf94>
is "simplify_function_body" the actual eval you think
<lf94>
or simplified expression
<lf94>
whatever
<lf94>
I'm surprised AssignmentList doesnt have a nicer interface
<teepee>
no, that's mostly for the tail-recursion-elimination
<teepee>
it should mostly be ignored in our case
<JordanBrown[m]>
Yeah, but evaluate_function_expression seems like the only place that does the right calls, and it's only called from there.
<teepee>
and the evaluate_function_... thing will just notice it's already a FUNCTION value and return that wrapped in a CallableFunction which is just a variant combining the various callable things we have
<lf94>
I need to do { Assignment("x", SomeExpressionThatCapturesTheXValueIWantToPass, params["x"].location(), ... }
<lf94>
I just have to pass these values and we're home free
<JordanBrown[m]>
optimist
<lf94>
gotta be
<lf94>
pessimism never got anyone anywhere :)
<JordanBrown[m]>
I expect that when you get the values passed you will have achieved the "works in the lab" state, which is usually ~10% of the project.
<lf94>
that's great, we were at 0% for a long time
<lf94>
thankfully percentages are not a measure of time to completion :)
<lf94>
with these great people on it, I'm sure 90% is not far ahead of us.
<kintel>
lf94: If you just get it running on Windows, we'll do the rest ;)
<lf94>
libfive builds on windows
<lf94>
you just gotta build libfive on the side and you're good
<lf94>
teepee: doesnt help :(
<lf94>
new AssignmentList is just std::vector
<lf94>
Ah, Jordan hinted at it
<teepee>
yes, of Assignment
<JordanBrown[m]>
lf94: Were you asking what the purpose of AssignmentList() with no arguments is?
<lf94>
Literal(Value val, const Location& loc = Location::NONE)
<lf94>
that's how we get a literal as an expression to pass...!
<lf94>
Wouldve been nice to have "fromDouble".
<teepee>
yes Assignment("name", new Literal(Value)))
<JordanBrown[m]>
teepee: argument list is actually at 644.
<kintel>
JordanBrown[m] If you have a fresh Windows build, does this work for you? ./build/openscad.exe examples/Basics/logo.scad --enable=fast-csg -o out.stl
<teepee>
value should have a constructor for that
<lf94>
Value(int v)
<lf94>
that sucks
<teepee>
why, there's one with double too
<lf94>
im blind to it
<JordanBrown[m]>
kintel: I don't have a current build - the ones that I've been playing with before this evening are not current, and the one I cloned this evening has not yet been built because we've been looking at cmake issues.
<teepee>
might be some auto-conversion stuff
<kintel>
JordanBrown[m] Could you check your old build? This breaks from me on master; I suspect it's been a while since anyone ran self-built binaries on msys2
<JordanBrown[m]>
lf94: teepee I am not sure, but I don't think you need or want a Value in creating that argument list.
<JordanBrown[m]>
You need an Expression.
<lf94>
You need an expression...
snakedGT has quit [Quit: Leaving]
<lf94>
and the Literal is an expression
<lf94>
and the Literal takes a Value
<lf94>
etc
<lf94>
ok, done!
<lf94>
compile time
<JordanBrown[m]>
Ah. The parser makes it look like Literal takes a double, but I guess there's automagic conversion to Value in there.
<JordanBrown[m]>
kintel: Happy to, but I'm upgrading MSYS2 at the moment and it seems best not to try to do that kind of thing while it's upgrading.
<JordanBrown[m]>
kintel: What is it that you expect not to work?
<lf94>
JordanBrown[m]: I'm not even reading the parser, seems to hide a lot
<JordanBrown[m]>
lf94: Yeah, it can be hard to follow because the parser turns text into a data-structure version of the program, and then you execute that program as another step.
<lf94>
/home/lee/other/openscad/src/core/SdfNode.cc:134:33: error: incomplete type ‘FunctionCall’ used in nested name specifier
<lf94>
134 | auto fc = FunctionCall::FunctionCall(
<lf94>
=_= wat
<JordanBrown[m]>
kintel: Hmm. Well, will try as soon as my MSYS2 upgrade completes.
<lf94>
oh lol i should maybe use it like a constructor.
<lf94>
there we go.
<kintel>
JordanBrown[m] I suspect debug binaries are currently broken; it works in release omde
<kintel>
*mode
<JordanBrown[m]>
kintel: but I think I have tried running models with fast-csg turned on.
<lf94>
location stuff is failing, setting it all to Location::NONE
<JordanBrown[m]>
Ah. Last time I tried, debug builds didn't work on MSYS2.
<JordanBrown[m]>
I don't remember why.
<kintel>
oh, ok, that all I need to give up for now ;)
<JordanBrown[m]>
I think they didn't even build.
<kintel>
I bet there is WIndows vs. cygwin-style resource paths which get messed up somewhere
<lf94>
http://0x0.st/HH45.txt "rror: invalid use of incomplete type ‘class FunctionCall’"
<lf94>
seems perfectly fine
<JordanBrown[m]>
kintel: No, I think it was more a "program got too complex" kind of problem.
<teepee>
lf94: means header is not included
<JordanBrown[m]>
I very very dimly think it may have run into a number-of-symbols limit in Windows binaries.
<lf94>
ok
<lf94>
error: no matching function for call to ‘Assignment::Assignment(const char [2], Literal*, const Location&)’
<lf94>
damn what, thought that was fine
<JordanBrown[m]>
The expression argument needs to be a shared_ptr.
<kintel>
JordanBrown[m] I got most tests running in debug mode, but 20 or so crashed. In release model, I just got them all to pass.
<kintel>
It's nice to do in 4 minutes what the CI spends 42 minuted on ;)
<JordanBrown[m]>
Which I think you get with shared_ptr<Expression>(Literal *)
<lf94>
trying
<JordanBrown[m]>
kintel: so you got it to build in debug mode under MSYS2?
<lf94>
ah ha, well that solved a bunch
<kintel>
Yeah, it builds and runs with a handful of crashes
<lf94>
last error!
<lf94>
error: no matching function for call to ‘FunctionCall::FunctionCall(Expression*&, <brace-enclosed initializer list>, const Location&)’
<kintel>
Caveat: I don't know if there are more than one debug mode on Windows. "debug mode" for me is the default cmake build
<lf94>
AssignmentList is a std::vector<shared_ptr<Assignment>>
<lf94>
I guess I have to be explicit
* lf94
does the same
<JordanBrown[m]>
kintel: Do you do something to select debug mode? I know that the default build is a release build.
<JordanBrown[m]>
lf94: You should definitely be working in terms of AssignmentList, not std::vector.
<lf94>
why, when it is
<JordanBrown[m]>
Abstraction.
<lf94>
we can worry about abstraction after it works
<lf94>
is the issue my Expression*& doesnt match Expression*...
<lf94>
oh no, it says.. it's the assignmentlist
<lf94>
okie dokie then
<JordanBrown[m]>
What does the call look like? I'm afraid my C++ starts getting really weak when there's an & in the type.
<lf94>
no known conversion for argument 2 from ‘<brace-enclosed initializer list>’ to ‘AssignmentList’ {aka ‘std::vector<std::shared_ptr<Assignment> >’}
<lf94>
i guess too much abstraction there doesnt let me use brace syntax
<kintel>
JordanBrown[m] Default is "unspecified", which for msys2 seems to be "release without -DNDEBUG"
<lf94>
oh wow ok
<lf94>
weird, the service is down ol.
<JordanBrown[m]>
kintel: Hmm, because on one of my projects there was an assertion failure that wasn't tripping for me on MSYS2, but was tripping on Linux... and there was no reason to expect a platform difference.
<JordanBrown[m]>
kintel: on my most recent build - which is not very recent - that command completes fine.
<kintel>
JordanBrown[m] Thx. Oliver recently cleaned up some fast-csg stuff
<lf94>
ok guys
<lf94>
im done
<JordanBrown[m]>
Building today's clone. Slow system, will be a while.
<lf94>
while teepee and crew fix that up, I'll port my flower over from curv to openscad tomorrow
<InPhase>
kintel: Yeah, but we should really be able to rely on venv creation. That's supposed to be a standard reliable thing, and it's possible a bunch of other packages could be useful in the future.
<JordanBrown[m]>
InPhase: "installing" stuff in the build directory does not give me warm fuzzy feelings.
<lf94>
I'm excited guys. I really want to see this attract more code cad users.
<kintel>
InPhase Yeah, agreed. Another approach could be to remove msys2 Python and find a clean way of managing a native install?
<lf94>
I want to see some crazy organics made in OpenSCAD now
<lf94>
New code cad techniques
<InPhase>
kintel: I think ideally we would have python packages validating most of the output formats, for example.
<JordanBrown[m]>
Oh, I don't think you want to mix the native Windows Python with the MSYS2 environment.
<JordanBrown[m]>
Don't cross the streams.
<JordanBrown[m]>
It would be bad.
<InPhase>
JordanBrown[m]: I'd probably be happier if we broke that off into a separate cmake action for the testing step only.
<kintel>
Python is just surprisingly complicated to get right : (
<InPhase>
JordanBrown[m]: But I think setting up a venv for testing is pretty reasonable.
<JordanBrown[m]>
Whatever make tool we end up using does not give me warm fuzzy feelings when its parallel processing causes multiple messages to be displayed at the same time, interleaved character by character.
<InPhase>
JordanBrown[m]: And, the build directory is the least disruptive place to do that. It guarantees it gets cleaned up, for example.
<JordanBrown[m]>
I don't know enough about Python to have a solid opinion. But "installing" is for build prereqs, not for builds.
<InPhase>
kintel: Well, usually pip is super reliable. This is the first time I've encountered such an issue.
<kintel>
Heh, yeah, multi-platform OSS is the hardest environment to live in. ..plus we don't have a separate team managing build systems and platforms : /
<kintel>
At least we have a reproducible problem now
<lf94>
multiplat is hard when the build deps build up!
<InPhase>
kintel: It might be worth consulting more minds in #python.
<kintel>
lf94 yeah, managing "leaf node" libraries is easy in comparison
<lf94>
I imagine openscad could be like, just sdl, cgal or similar, and a "libopenscad", if the man power were available
<InPhase>
kintel: It's kind of an unusual use case for pip from an msys2 installed copy of python, but other people must do that.
<InPhase>
After all, the packages ARE there.
<kintel>
yeah, for a reason I guess; but I haven't found any docs explaining why
<InPhase>
Python is common infrastructure for development. It's kind of important to have in such a system.
<kintel>
My assumption is that it's not sustainable to get upstream maintainers to manage msys2 wheels in pypi
<kintel>
..but it feels like the workaround would be to patch pip to pull pacman packages in a transparent way. ..but then again, a massive hack...
<InPhase>
But how did the CI ever work?
<kintel>
It uses native Windows Python, not msys2
<InPhase>
I see the old log from the PR. I knew I had seen it finding the msys64 one. Which it does, right above where it then turns around and finds the native one.
<InPhase>
This is why you went down that rabbit hole of PythonInterp vs Python3.
aiyion has quit [Ping timeout: 255 seconds]
<InPhase>
Ah. This is probably why I needed to do that ensurepip extra step in the first place.
<InPhase>
Maybe that sequence of nested ifs could be tweaked a bit. But something like that.
<InPhase>
It's a little awkward that it notices it fails and then continues to fail on actually running the file that doesn't exist.
<InPhase>
But there are a lot of conditions there. :)
<kintel>
yeah, smth. like that sounds reasonable given venv won't tell us that
teepee_ has joined #openscad
<kintel>
Ideally, the venv stuff should be extracted into some nice CMake utility functions
<JordanBrown[m]>
I thought that kintel had already worked around that problem with a diff that he mentioned above.
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<kintel>
My hack was too much of a hack
<InPhase>
JordanBrown[m]: I think that'll be unreliable.
<InPhase>
JordanBrown[m]: We can't prove all cases of mingw use bin instead of Script.
<kintel>
I'm checking the CMake environment, but we really need to check the Python environment
<InPhase>
JordanBrown[m]: Because... no Windows cases are supposed to use bin according to the specification.
<InPhase>
JordanBrown[m]: So we're basically working around a bug, I think.
<InPhase>
A bug that accidentally makes things make more sense in a way that they're not supposed to.
<kintel>
We haven't yet touched the beast which is WSL. I'm not going to touch that one with a ten foot pole ;)
<JordanBrown[m]>
But an MSYS2 environment is *not* Windows, and I fear that Bad Stuff will happen if you treat it like one.
<JordanBrown[m]>
Stuff like having problems with VC6.0 :-)
<InPhase>
VC6 was probably the last time people tried to build pip packages without using wheels. ;)
<kintel>
I have nightmares about VC6 from the 90s
<InPhase>
Oh, no. I guess that's more recent.
<JordanBrown[m]>
But there should be no VC in an MSYS2 picture.
<InPhase>
Yeah, that's not really what's happening. It's just a fallback script in the package setuptools process that is hunting for a Windows compiler.
<kintel>
We might be able to work around the building issues by helping Python find gcc
<InPhase>
It's, apparently, not a very robust process.
<kintel>
..but that's still very suboptimal
<InPhase>
Building numpy can take a while.
<InPhase>
But it should definitely not be necessary. It obviously exists for Windows.
<InPhase>
Really all we need is for it to, somehow, recognize what architecture it is on and grab the right thing.
<InPhase>
I think it is probably going to bin instead of Scripts because it has failed that check for win32 in the Python code.
snaked has joined #openscad
<InPhase>
And... that's probably the same check that would be used to figure out what sort of package to download.
<JordanBrown[m]>
You do not want it "for Windows". You want it "for MSYS2".
<InPhase>
We really don't.
<JordanBrown[m]>
Why do you think that?
<InPhase>
For these python packages, it should be normal windows code.
<JordanBrown[m]>
Why do you think that?
<InPhase>
They simply have to be importable by Pthon.
<InPhase>
It's still the same OS under the hood.
<JordanBrown[m]>
Only sort of.
<kintel>
I have this feeling that msys2 Python cannot use win32 Python wheels; they probably link in some interesting Unix-compatibility C library layers to e.g. deal with windows vs. Unix paths etc.
<JordanBrown[m]>
MSYS2 paths are not the same as Windows paths, for instance.
<InPhase>
JordanBrown[m]: Actually, can you do a check? Run that msys2 python, and then run "import sys" and "print(sys.platform)"
<JordanBrown[m]>
win32
<JordanBrown[m]>
already did it :-)
<JordanBrown[m]>
which surprised me and I am now looking at virtualenv to see how it decides which directory to use.
<InPhase>
Yeah... Exactly that.
<JordanBrown[m]>
BTW in the REPL you don't need the print() :-)
<JordanBrown[m]>
The snippet from that PR appears to be long gone.
<InPhase>
Really?
<JordanBrown[m]>
Really.
<InPhase>
Hmm.
<InPhase>
Ah, found it.
<InPhase>
On my system. /usr/lib/python3.10/venv/__init__.py
<kintel>
msys2 maintains 138(!) patches against upstream Python, phew
<JordanBrown[m]>
InPhase: I am not sure, but I think that's from core Python, not from virtualenv.
<JordanBrown[m]>
"We couldn’t find any code matching 'binname' in pypa/virtualenv"
<InPhase>
Maybe they need 139. We could report this if we actually knew what needed reporting.
<JordanBrown[m]>
But what kintel found suggests that this is deliberate.
<InPhase>
JordanBrown[m]: Yes, virtualenv and venv are actually two separate things.
<JordanBrown[m]>
+ if sys.platform == 'win32' and not _POSIX_BUILD:
<InPhase>
JordanBrown[m]: Which was my bad, leading you astray on the previous link hours back. I was not paying close attention.
<InPhase>
JordanBrown[m]: Although one was sort of based on the other I think.
<JordanBrown[m]>
>>> from sysconfig import _POSIX_BUILD
<JordanBrown[m]>
>>> _POSIX_BUILD
<JordanBrown[m]>
True
<JordanBrown[m]>
OK, so I will flush the cache of all the stuff I've found looking at virtualenv :-)
<InPhase>
:)
<InPhase>
Same idea, but it was an older thing from python2 days that is sort of deprecated but still around and used.
<JordanBrown[m]>
But anyhow, kintel found the operative part: MSYS2 deliberately patches Python so that it acts like POSIX here.
<kintel>
Btw. one question: When we build OpenSCAD under msys2, are we building a standard win32 OpenSCAD, or are we building some sort of win32+Posix OpenSCAD?
<JordanBrown[m]>
MSYS2. I don't think it can run outside an MSYS2 environment.
<JordanBrown[m]>
Is that truly the right answer? Perhaps not, but I believe it's the state today.
<InPhase>
Sure it does. We distribute it to people who don't have msys2 all the time.
<InPhase>
The CI is using msys2 for the distributables.
<JordanBrown[m]>
Production builds are not done using MSYS2.
<kintel>
The distributed packages are all build on MXE though
<JordanBrown[m]>
They are done using some cross-compile from Linux.
<kintel>
I guess we must do a Posix build, since we link against a whole ton of msys2-installed libraries
<InPhase>
Do we distribute an msys-2.0.dll with it?
<JordanBrown[m]>
kintel do you mean for the MXE build?
<JordanBrown[m]>
which it wouldn't, if it was a native Windows app.
<JordanBrown[m]>
Because there is no /home on my Windows drive.
<kintel>
JordanBrown[m] yup, that the Posix proof :)
<JordanBrown[m]>
It is perhaps (probably) bad that our production Windows builds are not built the same way as our "so you want to do development on Windows" builds, but it's the way it is.
<InPhase>
JordanBrown[m]: Does that work when you use the exe files from the download page?
<JordanBrown[m]>
I can't see how it could, but i'll try.
<kintel>
InPhase It cannot, since it would have no idea in which folder a non-existant msys2 installation would live
<InPhase>
I have not tried actually using msys2 locally, but I did not imagine it as such a bubble.
<kintel>
In the end, msys2 is really just a way of making Windows pretend it's Unix for developer convenience
<kintel>
..but it's like a complete, closed ecosystem which happens to be able to call out into Windows
<InPhase>
That's unfortunate. msys2 looks like the only sensible way to manage a lot of package dependencies for Windows.
<JordanBrown[m]>
Ohhhhh.... kay
<JordanBrown[m]>
I don't know how, but when I run a distribution OpenSCAD against that path... it works.
<kintel>
JordanBrown[m] uh, that's ...odd
<InPhase>
JordanBrown[m]: Did you "run" it inside an msys2 shell?
<InPhase>
JordanBrown[m]: How about from cmd?
<JordanBrown[m]>
yes
<JordanBrown[m]>
and now I just ran it from cmd
<JordanBrown[m]>
and it did not work from cmd.
<InPhase>
Perhaps the shell is morphing filenames before passing them along?
<JordanBrown[m]>
I mean, it started, but didn't load anything.
<InPhase>
They might patch bash too. :)
<JordanBrown[m]>
It's really hard to see how the shell could do that, since it doesn't know what arguments are file names.
<JordanBrown[m]>
Oh, I expect that they do.
<JordanBrown[m]>
More likely, I suspect, is that they somehow interpose on some of the Windows DLLs so as to get Windows tools to accept POSIX paths.
<InPhase>
That wouldn't explain it depending on how you launched it.
<InPhase>
You think they change the dlls grabbed when things are launched inside the msys2 shell?
<JordanBrown[m]>
and it successfully opened the file.
<JordanBrown[m]>
yes
<kintel>
WIndows does have the concept of "current drive letter", which they may use to create the illusion of a virtual root folder
<JordanBrown[m]>
could be.
<kintel>
I seem to remember there being a cmd-line tool in cygwin for converting between unix and windows paths
<kintel>
..and I remember we having to use that to convert everything going in and out of cygwin environments, to write portable shell scripts
<InPhase>
JordanBrown[m]: Okay... Make a badscad.scad that has garbage text in it. Then do a command line: openscad /home/Jordan/whatever/badscad.scad -o test.png
<JordanBrown[m]>
MSYS2 can do something that I don't think Cygwin can do: UNIX tools can use C:/foo style paths.
<JordanBrown[m]>
InPhase: from which shell?
<InPhase>
JordanBrown[m]: You should get an error like: "Can't parse file '/home/Jordan/whatever/badscad.scad'~"
<JordanBrown[m]>
and running which OpenSCAD?
<InPhase>
JordanBrown[m]: Except the text of that should match the string OpenSCAD is actually processing.
<InPhase>
JordanBrown[m]: Well, some combinations.
<InPhase>
JordanBrown[m]: This will tell us what they are actually seeing inside in the various conditions.
<InPhase>
i.e., what does the C++ code think the filenames are.
<JordanBrown[m]>
From the MSYS2 shell, running an MSYS2 openscad:
<InPhase>
JordanBrown[m]: Yeah, and that comes from a string parse of the command line. Confirmed that.
<InPhase>
kintel: Good confirmation.
<kintel>
Anyway, what all of this says is that it _may_ be somewhat kosher to call pure Windows programs (like Python) from msys2
<InPhase>
I am getting the sense that msys2 is a very bold pile of mutations of expected behavior, but they've modified so much of the expected behavior that it mostly works. Until it breaks pip. :)
<kintel>
..so the question is if we should try to standardize all Python stuff on Windows Python and use msys2 for everything else
<InPhase>
kintel: Yeah, maybe.
<JordanBrown[m]>
Running a production OpenSCAD from an MSYS2 shell gives the same result.
<JordanBrown[m]>
kintel that's terrifying.
<JordanBrown[m]>
but it agrees with what we're observing.
<InPhase>
kintel: We would then just need to make sure the CI still works.
<JordanBrown[m]>
Big downside: means that you have dependencies on what's installed on the Windows system.
<JordanBrown[m]>
Where previously I believe we're only dependent on what's installed in the MSYS2 pocket universe.
<kintel>
yeah, it's not ideal to manage system packages separately. Makes it a lot harder to establish somewhat similar build environments
<InPhase>
Or we could try to convince the msys2 people to fix this.
<InPhase>
It really does feel like they have a bug.
<kintel>
yeah, there is also that 5-year plan :)
<InPhase>
But maybe it needs to be distilled down into a simpler failure example that's not bundled with all of our extra baggage.
<JordanBrown[m]>
The code execution cannot proceed because lib3mf.dll was not found. Reinstalling the program may fix this problem.
<InPhase>
JordanBrown[m]: You should be able to run "windeployqt.exe --release openscad.exe" from within the msys2 shell and get the dlls copied into that directory.
<JordanBrown[m]>
I assumed that the path magic was down at the simulated-system-call layer, or perhaps at the libc layer... putting it in argv processing is madness.
<InPhase>
Sometimes that misses some stuff though.
<InPhase>
Oh, nevermind. That's only for the Qt dependencies.
<JordanBrown[m]>
InPhase's test-python stuff only generates warnings when it fails; it doesn't fail the cmake build.
<JordanBrown[m]>
At least that's what I think I did, let me check.
<JordanBrown[m]>
Ah, that was with a version of the files that did not fix the Scripts / bin mismatch, and so it couldn't find Python for InPhase's stuff.
<JordanBrown[m]>
But now I am confused because I made that change and I don't know what would have undone it.
<JordanBrown[m]>
And indeed it has not been undone. So now I don't know how I got that failure with the big Python stack trace and the VC6.0 error.
<JordanBrown[m]>
So this is the error message from InPhase's work:
<JordanBrown[m]>
-- Could not find python.exe in C:/msys64/home/Jordan/openscad/master/b2/tests/venv/bin/python.exe o
<JordanBrown[m]>
r in corresponding Scripts directory. venv creation failed.
<JordanBrown[m]>
And here is that directory from a newly created build directory:
<JordanBrown[m]>
so indeed there is no python.exe, only a bare python.
<kintel>
Yeah, that's expected. InPhase's patch was just an untested sketch
<JordanBrown[m]>
But I got a different failure earlier... I got a big Python stack trace, and the VC6.0 error.
<kintel>
yeah, that happens when you do find msys2 python, and it tries to `pip install numpy`
<JordanBrown[m]>
I think that was before I upgraded my msys2, so maybe the venv directory behavior was different, or maybe it found the python3.11.exe.
<kintel>
huh, yeah, it could be that the .exe behaves differently.
<JordanBrown[m]>
never mind behaving differently
<JordanBrown[m]>
it *exists*, where python.exe does not.
<JordanBrown[m]>
For whatever reason, that venv/bin directory has python, python3, and python3.11.exe.
<JordanBrown[m]>
The first two do not have ".exe"; the third does.
<kintel>
and they are different binaries?
<JordanBrown[m]>
no
<kintel>
Perhaps msys2 looks at the suffix to decide on posix vs. win32 behavior?
<JordanBrown[m]>
no... InPhase's patch was specifically looking for python.exe, and that file does not exist.
<kintel>
I suspect that was just a typo in his patch
<JordanBrown[m]>
Maybe, for whatever reason, when I got the VC6.0 error it was looking for python3.11.exe instead of python.exe.
<kintel>
I also get the VC6 error using venv/bin/python
<JordanBrown[m]>
Or maybe the venv stuff changed when I upgraded so that python and python3 don't have ".exe".
<JordanBrown[m]>
But InPhase's patch is looking for python.exe, not python, and doesn't find it, so gives up.
<kintel>
yeah, but he never ran that patch, it was just a sketch
<JordanBrown[m]>
He may not have run it... but I have.
<JordanBrown[m]>
and that's clearly why my build is OK at the moment: his pip stuff just isn't running, because it can't find a Python.
<JordanBrown[m]>
The mystery is why, a couple of hours ago, it *did* end up running.
<kintel>
it's very possible that msys venv changed, and that previously there were more .exe files
<JordanBrown[m]>
yes, looking again at his patch, it very specifically looks for python.exe; there is no way it could have accidentally found python3.11.exe.
<JordanBrown[m]>
It sure seems wrong that it generates two files without .exe and one file with.
<JordanBrown[m]>
"it" being the venv stuff.
<JordanBrown[m]>
Presumably the version before this upgrade generated all three with .exe.
<kintel>
Anyway, I'm signing off for tonight. Thx for helping solving some of the mysteries
<JordanBrown[m]>
Sure thing, happy to help. Puzzles are always fun.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JordanBrown[m]>
Aren't you in Germany?
<JordanBrown[m]>
kintel^
stefanct has quit [Ping timeout: 256 seconds]
stefanct has joined #openscad
stefanct has quit [Ping timeout: 255 seconds]
stefanct has joined #openscad
guso78 has joined #openscad
castaway has joined #openscad
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #openscad
actiondave has joined #openscad
admin__ has quit [Ping timeout: 248 seconds]
castaway has quit [Ping timeout: 265 seconds]
castaway has joined #openscad
L29Ah has quit [Read error: Connection reset by peer]
fedorafan has joined #openscad
kintel has joined #openscad
<kintel>
JordanBrown[m]: Canada
L29Ah has joined #openscad
<kintel>
JordanBrown[m]: One curious thing. In my up-to-date msys2, when I create a venv I get this in the bin folder: activate Activate.ps1 pip.exe pip3.10.exe pip3.exe python.exe python3.10.exe python3.exe python3w.exe pythonw.exe
castaway has quit [Ping timeout: 255 seconds]
castaway has joined #openscad
castaway has quit [Ping timeout: 252 seconds]
<InPhase>
kintel: Does this alter the resulting behavior of the pip install? Or same failure there?
<InPhase>
I did find the "python without .exe" in JordanBrown[m]'s previous description troublingly inconsistent.
<InPhase>
Either it's a script, which is abnormal, or an exe not labeled as an exe, which I suspect doesn't work reliably in Windows.
<InPhase>
It'd be easier to just target a platform that has differences, than to target platforms that are the same and different plus one halfway in between.
<InPhase>
What I really want in a Windows build system is package management, Linux style build management, and Windows native results.
castaway has joined #openscad
<kintel>
InPhase there is always vcpkg + microsoft's git cmd-line package which I believe has the most common tools, llike bash
<teepee>
depending on the languages you know, you may need to ignore some of the approaches ;-)
<tfrank7>
Is it safe to use the latest DEV version?
<teepee>
openscad is more like CSS or hardware description languages
<tfrank7>
good to know
<teepee>
yes, pretty safe, if you can handle the addiction to cool new features others may not have who stick to the release version
<tfrank7>
Haha, I like the new interface and instantly switched to the dark mode.
<InPhase>
Right. I need to PR my superior color themes so others can use them.
<InPhase>
I keep forgetting to do that.
<teepee>
:)
<teepee>
maybe we can get an auto-reminder feature into the bot if it ever comes back :D
<tfrank7>
I just used the 'BeforeDawn' theme, but happy to try yours.
<InPhase>
!remind InPhase EveryWeekend Do stuff!
<lf94>
morning
<lf94>
kintel: ah, fellow Canadian :)
kintel has quit [Ping timeout: 250 seconds]
tfrank7 has quit [Quit: Client closed]
tfrank7 has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
castaway has quit [Ping timeout: 248 seconds]
castaway has joined #openscad
kintel_ has joined #openscad
<kintel_>
lf94 Where in Canada? Toronto here
<lf94>
Montreal
<lf94>
brother lives in TO though
<lf94>
teepee: you checking out the segfault issue today? :o
<teepee>
there is some evaluation issue I don't understand yet. it's expanding the expression into something recursive which makes no sense
<lf94>
hmmm
tfrank7 has quit [Quit: Client closed]
redlizard has joined #openscad
redlizard has quit [Remote host closed the connection]
redlizard has joined #openscad
<kintel_>
teepee How do we actually build and upload docker images these days?
<teepee>
kintel_: so far locally on my good old server machine
<kintel_>
ah, that explains why I cannot find any CI for it :)
<teepee>
once the open source project is through, we may be able to get this automated again
<kintel_>
We got approved a day or two ago
<teepee>
I saw that, but I'm not sure it's active already
<teepee>
with CircleCI introducing the 1h timeout, there was not a huge list of options and we don't need to rebuild that often, so I did not spend a huge amount of time thinking about that
<kintel_>
Looks active
<teepee>
I'm really not a fan of putting everything into the github basket
<teepee>
ahh, cool so "free docker builds" now?
<kintel_>
15 concurrent builds
<kintel_>
I don't know if they have a timeout
<teepee>
I would not care too much about concurrent, but MXE took about 6h per arch
<kintel_>
I think there are two things to worry about; docker Hub enforcing a max. runtime, and Docker itself killing containers which haven't produced output in a while
<kintel_>
oh, and I haven't found any docs on CPU and RAM on the builders
<teepee>
as long as they have at least 4gb ram, we should be fine if there's no time limit
<kintel_>
I asked support to provide some info
<kintel_>
Their previous free tier limit was 1 CPU/2GB/2 hours
<juri_>
that's pretty small.
<kintel_>
yeah, not very useful to us, but now we're "paying" customers, so I expect more :)
<guso78>
lf94, can you tell me: which libfive functions do you use to create a mesh from an oracle ?
<guso78>
i could not find a matching function in libfive.h
fedorafan has quit [Ping timeout: 248 seconds]
<lf94>
guso78: you have to use the C++ stuff
<lf94>
teepee: did you figure it out
<lf94>
guso78: did you see we created the oracle yesterday?
<guso78[m]>
Lf94 i have realizes the discussion but die Not watch the result
<lf94>
so far no results to show other than we have the scaffolding in place
<lf94>
teepee is working on fixing the segfaut
<guso78[m]>
Wo will Werk c++ instead
<guso78[m]>
Today finsished an algorith to create a sdf function from an existing polyset.
<lf94>
:o interesting
<lf94>
From what I understand this is quite hard
<guso78[m]>
Challenging IS to find the correct face to measute distance . But i have a beautiful divide & conquer 😀
<InPhase>
guso78[m]: For a fixed polyset and many points to evaluate, you could pre-sort min/max vertex for each facet along at least 3 dimensions, and this would quickly exclude a massive number of facets from consideration on high facet count models.
<guso78[m]>
Inphase i presort the Points by building trees. Each Branch IS a half space in an optimal Position . Ideally my trees are optimally balanced
<guso78[m]>
If you want to know Details, Look into the libfive Branch in my Fork. frepnode.cc
<InPhase>
guso78[m]: Are you excluding paths along the tree that move away from the target point?
<InPhase>
guso78[m]: Does your algorithm work for a candycane model where the tip of the curved part is near the target point? It must move away from the target location along the surface before it gets back close to it, but this information will not be locally available along a surface traversal.
<guso78[m]>
Inphase No: this IS Not consideres. I am sure thosr Points will BE unattraktive to my Algorithm very fast
<guso78[m]>
I Tested ob a Cube. Bücher Tests to follow
<guso78[m]>
Bigger Tests to follow
<InPhase>
Ok. :)
<guso78>
lf94, is it possible to find your recent code in github ?
<juri_>
typically, an automated system for running tests when people file PRs.
fedorafan has quit [Ping timeout: 246 seconds]
guso78 has quit [Ping timeout: 260 seconds]
fedorafan has joined #openscad
<joseph_>
teepee kintel: I just published a draft of my project proposal at https://github.com/jbinvnt/gsoc-2023-proposal-public. Like I did last year, this version has all the project description sections, but leaves out my personal information so that anyone in the community can read it and offer feedback if they want. My full document with all the sections will get submitted as a PDF on the GSoC dashboard.
<teepee>
lf94: not yet, family visit. so coffee + cake :)
<teepee>
but I have a theory, I said use the expression from the FunctionType as 1st argument to the FunctionCall
<teepee>
but that's not what happens in the parser. The expression there is a Literal containing the FunctionType
<teepee>
testing that now...
<teepee>
joseph_: yep, that's fine, no personal info needed to be public
kintel_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<teepee>
also just upload every time you have some sort of stable PDF, you can re-upload till the deadline and better safe than sorry :)
fedorafan has quit [Ping timeout: 265 seconds]
fedorafan has joined #openscad
<lf94>
teepee: damn, coffee and cake sounds delicious right now.
<teepee>
right, it seems to evaluate and create a mesh, but crashing after that
<lf94>
:o already it gets this far?
<teepee>
I would not call it far yet :)
ur5us has joined #openscad
<teepee>
is that callback coming from a different thread?
<lf94>
InPhase: you may want to get some sdf ideas out now B)
<lf94>
This is exciting stuff !
<InPhase>
lf94: It's working?
<InPhase>
lf94: Also, keep the sdf first in the parameter list. I'm convinced the other two can end up optional.
kintel has joined #openscad
<InPhase>
lf94: Resolution should end up $fs, and the bounding box I think we can auto-detect with high reliability.
fedorafan has quit [Ping timeout: 246 seconds]
<kintel>
joseph_: One thing I'd add to the proposal, just as a clarification: VBO usage is one part of GL modernization, but we have a bunch of various OpenGL calls considered legacy in various places. One way of measuring success could be to successfully build and run OpenSCAD against the OpenGL 3+ Core Profile. Obtaining such a context should hopefully soon be possible.
fedorafan has joined #openscad
<teepee>
InPhase: I would not call it working yet, but it seem to be able to produce spheres and an ugly torus :)
<InPhase>
Well that's something.
<teepee>
also only commandline png, still crashing in gui mode
<teepee>
well, it never going to be as fast as native unless we get a faster evaluation going
<lf94>
True
<teepee>
but I suppose there's quite some things to gain using a more specialized FunctionCall
<lf94>
But this is why I was originally pushing for openscad to be converted to libfive trees
<teepee>
I know, we'll see, maybe both ways have their place
<teepee>
on the other hand a faster evaluation would be nice on it's own too
<lf94>
yeah. It's in your guy's hands now - really anything else is beyond me I think
<lf94>
I hope those pictures are enough to now motivate InPhase too :)
<InPhase>
teepee: lol. "flength"
<InPhase>
Pretty nice torus.
<teepee>
keeping the spirit :)
<InPhase>
teepee: I caught that. :)
<lf94>
In my side, all I can do is start producting SDFs that work in OpenSCAD
<lf94>
On my side
<teepee>
go go go
<teepee>
base sdf library coming up
<InPhase>
Hmm. This have me a build error on libfive not existing.
<lf94>
You need to build and install it
<lf94>
on the side
Alexer has quit [Ping timeout: 240 seconds]
<lf94>
teepee: yeah exactly. might be a good idea to make it part of this pr
Alexer has joined #openscad
<InPhase>
Is libfive not a submodule?
<teepee>
no
<InPhase>
Ok. So how do I tell it where libfive is?
<teepee>
I have not looked what the cmake stuff does
<InPhase>
I have libfive (recompiling it fresh right now). I do not run silly things like "make install" though.
castaway has quit [Ping timeout: 252 seconds]
<InPhase>
It's the include files that it's not finding at this stage.
<InPhase>
I could symlink it somewhere.
<InPhase>
(For now.)
<teepee>
I'm using stow for that so install to /opt/stow/library-version
<teepee>
and stow creates symlinks to /opt/bin /opt/lib and such
<teepee>
but libfive make install is strange
<teepee>
it wanted to install the pkgconfig stuff into the root folder
fedorafan has quit [Ping timeout: 265 seconds]
fedorafan has joined #openscad
<InPhase>
Symlinking libfive/include/libfive.h and libfive/include/libfive in the libfive repository into OpenSCAD's src directory did the trick as a quick hack for the include step.
<InPhase>
Next to let it fail on the linking so I can see the full error.
<InPhase>
Well that's quite a long command.
<teepee>
pushed the changes, including hack to disable the stack check as libfive runs the callback in a thread