<kintel>
peepsalot I noticed that you did a "dynamic precision" hack by dynamically creating a format string. Did you look into supporting dynamic precision according to the regular format spec?
<peepsalot>
kintel: yes just below that, are various examples commented out that all failed
<kintel>
yeah, you'd have to write a parser that can handle inner `{}` pairs
<kintel>
..or find a way of delegating the format string parsing to the default one
<kintel>
Looks like your current parser just exist on the first `}` character
<kintel>
*exits
Guest75 has joined #openscad
Guest75 has quit [Client Quit]
<peepsalot>
its not clear which parts of the format string are meant to be handled by fmt internals, and which are passed in to the formatter. i thought that precision being an int meant that its out of my hands to format the inner braces
<peepsalot>
it must have to parse the innermost braces first
<kintel>
hm,. Your workaround works though, at the expense of format strings not being constexpr, so we can't compile-time check them
<peepsalot>
the whole interface still seems like a big black-box
<peepsalot>
i guess logging from each parse() function might help to sort out what's going on with the format strings
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
J2356 has quit [Quit: Client closed]
J2356 has joined #openscad
kintel has joined #openscad
<kintel>
heh, but good luck logging from a constexpr function ;)
<kintel>
g++ may have some extensions though
kintel has quit [Client Quit]
califax has quit [Remote host closed the connection]
califax has joined #openscad
J2356 has quit [Quit: Client closed]
J2356 has joined #openscad
juri_ has quit [Ping timeout: 260 seconds]
kintel has joined #openscad
<kintel>
peepsalot For your fmt::formatter<VectorType> : fmt::formatter<Value>
<kintel>
you use the fmt::join() workaround due to not getting the formatting string right
<kintel>
If you, instead of inheriting from Value, implement parse() and add another ':' character, it works as expected with:
use-value has quit [Remote host closed the connection]
<peepsalot>
kintel: I was trying that in the #else alternative formatter<VectorType> implementation
use-value has joined #openscad
<peepsalot>
kintel: but i was adding: "{::{" <parse_context contents> "}}", so the inside braces are not needed there?
<peepsalot>
ok, yeah that seems to work, and I re-checked the ranges example and I don't know why i added the extra braces
J235657 has joined #openscad
J2356 has quit [Ping timeout: 260 seconds]
epony has joined #openscad
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kintel has joined #openscad
<kintel>
peepsalot Cool, that sounds like the main libfmt challenges are under control?
<kintel>
I guess one missing thing is how to approach configuring anything not a float
<kintel>
One idea: If we can enumerate _why_ we want to print out a recursive Value, we could potentially define a custom format string, and simply not expose low-level formatting to the call site at all, e.g. fmt::format("{:compact}", myValue) fmt::format("{:precise}", myValue) etc.
<InPhase>
I have to significantly rearrange that CMakeLists.txt. I cannot even understand this merge diff. It has done a very poor job of diffing.
<InPhase>
Good grief git.
GNUmoon has quit [Remote host closed the connection]
<InPhase>
Somebody must have added a RNG to git to decide what line numbers to merge things at.
GNUmoon has joined #openscad
<InPhase>
I'm literally sitting here with a completely separate copy of the file using old-school diff just to get visibility into what git actually thought was supposed to be changed.
<guso78>
its impressive. how "water tight" is it (between in and out) ? and which plastic do you reccommend for best performace ?
<J23>
i used PETg - tough bit elastic and cheap. For best performance POM (Delrin) would be good
xxpolitf has quit [Ping timeout: 260 seconds]
<J23>
and you sure could add seals and ballbearings
<guso78>
back to cpack ... in Linux cpack for openscad works right out of the box, but when i try in MSYS2, the setup appears to be missing.
califax has quit [Remote host closed the connection]
califax has joined #openscad
<guso78>
When looing into the CMakeLists.txt i cannot find the CPack module added (manual page tells to put it there)
teepee has quit [Remote host closed the connection]
<guso78>
so am really wondering that it does so well in linux and so "not" in MSYS2
teepee has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
xxpolitf has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
ur5us has quit [Ping timeout: 256 seconds]
ccox_ has joined #openscad
ccox has quit [Ping timeout: 260 seconds]
<greenbigfrog>
Inphase: > In socket.scad you also appear to have used ScrewThread where you intended to use ScrewHole (presumably, because it is applied to a cylinder). But don't I want screwthreads on the socket, and then screwhole on the lid? a screwhole on the socket would cut away everything I just added :)
<guso78>
openscad-appimage-64bit is linux, tight ?
<guso78>
right ?
<teepee>
yes
<guso78>
this is what passed right now in my CI build.
<guso78>
i cant find all these 1500 test input samples. where are they stored?
<teepee>
tests/data
<teepee>
it's not 1:1, most input files are used for a couple of test runs, e.g. for preview, mesh render, echo output, ...
snaked has quit [Remote host closed the connection]
xxpolitf has quit [Ping timeout: 260 seconds]
snaked has joined #openscad
xxpolitf has joined #openscad
<InPhase>
kintel: Yeah, looks like pip is currently missing from the Windows build platform, which will block the rest from working.
snaked has quit [Ping timeout: 255 seconds]
<InPhase>
I am not sure what the process is for adjusting that.
snaked has joined #openscad
<InPhase>
greenbigfrog: Well it sure looks better by eye. :) Good luck on the print. If there's an issue after printing, you'll have to explain in detail where. Maybe with help from a photo demonstrating the issue posted to imgur.
<guso78>
teepee, thank you, found it now!
snakedGT has joined #openscad
snaked has quit [Ping timeout: 255 seconds]
<guso78>
in my latest version in branch python, i include "core/node.h" instead of "node.h" in many cc files to make sure the compiler does not get the python version of node.h
snakedGT has quit [Quit: Leaving]
<guso78>
finally got cpack running in my MSYS2 environment! Realized that i really use an outdated CMakeLists.txt. after install nsis packacke i got an installation exe file!
<guso78>
when trying it however, installation succeeds, but the openscad.exe will not. it reports QT and qscintalla libs missing.
Guest27 has joined #openscad
xxpolitf has quit [Read error: Connection reset by peer]
<InPhase>
teepee: Thanks. I'll give that a try this evening.
<InPhase>
Although if anyone else wants to try pushing fixes to the build system for that while I'm busy at work, I would take no offense. :)
Guest28 has joined #openscad
<JordanBrown[m]>
teepee: I assume that current gcc is C++20; are there really platforms that we care about where you can't get current gcc?
<JordanBrown[m]>
Or is the issue more the availability of the associated libraries, so a run time issue rather than a build time issue?
<peepsalot>
we build for distros based on compiler available on their distro. so Ubuntu 18.04 LTS is still technically supported for 3 more months. I doubt even Ubuntu 20.04 has full c++20 support
<peepsalot>
also some versions have c++ standards partially implemented anyways, its not as simple as c++20 support or not. for example the c++17 is supposed to include filesystem headers, but that isn't supported on 18.04's compiler
<JordanBrown[m]>
Is that a build-time dependency, or a run-time dependency?
<peepsalot>
build-time
<JordanBrown[m]>
So we can't install a modern compiler on our build systems?
<JordanBrown[m]>
I understand the desire to target an older environment, but that doesn't necessarily mean that we have to build on that environment.
<JordanBrown[m]>
Requiring users to upgrade their environment might not be reasonable, but requiring developers to upgrade their compiler seems entirely reasonable.
<JordanBrown[m]>
Hmm. I guess part of the equation is whether an appropriate compiler is available for the environment *from the distribution*, versus being available if you download and build it yourself.
aiyion has quit [Remote host closed the connection]
aiyion has joined #openscad
<peepsalot>
yeah, i think we have always stuck to what is provided in official distro repos. not sure about installing our own compiler versions, that's more a teepee question
<JordanBrown[m]>
I wouldn't be surprised if there's also a run-time dependency, if gcc version X requires glib version X.
<peepsalot>
there's also technically the option to switch to clang if the provided version has better support than gcc's. i think we only use clang on mac builds at the moment.
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
guso7861 has joined #openscad
J23 has quit [Ping timeout: 260 seconds]
guso7861 has quit [Ping timeout: 260 seconds]
Guest28 has quit [Quit: Client closed]
Lagopus has quit [Quit: q]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<teepee>
c++20 is not just gcc it's also libc++
<teepee>
it's probably possible to get things compiled on all the older platforms, but I'm not going to maintain that and I'm not even sure there's a simple way to distribute the packages then
<teepee>
anyway, if that's about the multithread comments, I don't see adding a core dependency to a library that's 3 month old and has no releases
<teepee>
it does seem to have some interesting things, but so has Manifold
<teepee>
of course I can't see into the future so who knows, maybe that kigumi would be a good choice even over Manifold but from the visible metrics it's not scoring too high (yet?)
<JordanBrown[m]>
Right, a run-time library dependency is much harder than a build-time dependency.
<peepsalot>
the problem with multithreading CGAL is that it still has a memory bandwidth bottleneck as far as I can tell
<peepsalot>
the amount of malloc and free done is insane, twice (numerator, denominator) for every component (X,Y,Z[,W]) of every point or vector etc, even temporary ones for every algebraic operation on geometry data
Bocaneri has joined #openscad
Bocaneri is now known as Guest5498
<InPhase>
peepsalot: Is that still true with the fastcsg stuff? I thought big chunks of that were using doubles.
<peepsalot>
i would really like if there were a way to control whether GMP variables went on stack or heap
Sauvin has quit [Ping timeout: 256 seconds]
<InPhase>
Well you can't do stack for arbitrary fractions.
<peepsalot>
InPhase: i think if fast-csg-exact is enabled? AIUI the exact requires multiprecision rationals from GMP
<InPhase>
Has fast-csg-exact actually turned out important in any real world testing?
<peepsalot>
yeah, maybe something like a small buffer optimization though
<InPhase>
Yeah, that would probably be a big asset for this type of work.
<peepsalot>
i don't know, i haven't done a comprehensive analysis of all the options
<InPhase>
Maybe it doesn't align with what most other people use GMP for.
<InPhase>
You probably have to be pretty crazy to try to use a hundred thousand GMP values at once.
<InPhase>
There are very few use cases where that should matter. (And I'm not convinced this is one of them.)
<peepsalot>
the vast majority of values fit into 24bytes iirc (mimalloc stats can show total allocations of each size on a debug build)
<peepsalot>
and I think max i saw was still only 128 or 256 bytes. granted that was just from one or two samples (my usual go-tos are menger sponge and the rounded cube die example)
<peepsalot>
InPhase: i made malloc wrapper for just GMP's malloc/realloc/free calls, and here is one of the outputs I got for it: https://bpa.st/QF7TY
<peepsalot>
the numbers in parenthesis are (from, to) bytes of memory allocated. and the big number on the right is how many times it happened for rendering the geometry
<peepsalot>
5.8 billion allocations of 8 bytes, where more than half of those end up being reallocated to larger sizes
<peepsalot>
i guess it should be possible to make a c++ wrapper class over GMP's C interface. try making the SBO version exactly 64bytes on stack (size of a cache line), possibly representing both numerator and denom in that one object.
<InPhase>
lol, 5 billion
<InPhase>
I usually tell people to not stress over allocation unless you're doing something silly, because it's only about 50ns!
<InPhase>
But I multiplied that 50ns estimate out, and that's about 5 minutes just to allocate those 8 byte chunks.
castaway has quit [Ping timeout: 256 seconds]
<InPhase>
I particularly like how the number of allocations, reallocations, and frees of the 8 byte chunks don't match up to the same number.
<InPhase>
valgrind should be throwing a fit if those values are correct. :)
<InPhase>
And yes, I agree that it seems a 64B SBO would probably speed that up by multiples. That could be a major performance change for CGAL.
ur5us has quit [Remote host closed the connection]
ur5us has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<greenbigfrog>
so I printed the parts earlier. I've confirmed that I'm screwing them on straight, by measuring the height all around. the first half turn is easy, after that it gets hard, and I can't get it any farther then this. https://owo.whats-th.is/AYGSHPE.jpghttps://owo.whats-th.is/5ZF9UX5.jpg
<greenbigfrog>
I guess I should just increase the tolerance parameter? it's printing dimensionally accurate and the threads are well formed
snaked has joined #openscad
<teepee>
what layeer height is that? maybe reducing that would already help
<InPhase>
Hmm, yeah, those sure do look like some fat layers.
Lagopus has joined #openscad
<InPhase>
greenbigfrog: ScrewHole and ScrewThread both come with a tolerance parameter, which is set to 0.4 by default. The easy thing to try is just increase it. You could maybe bump it to 0.8 and try again.
<InPhase>
greenbigfrog: Try out as many parts as you can to see how good they are.
<InPhase>
greenbigfrog: Alternatively, you can try calibrating your printer with some thin wall prints (like a tiny [20,20,10] cube printed in vase mode), and adjust print settings until you get it to actually be the right thickness.
<InPhase>
greenbigfrog: But if your printer is as good as you can get it, or you don't want to mess with it, or your printer is not the type that's suitable for calibrating, then tweak the tolerance of the model.
<teepee>
for just printing I use just non-standard easy to print values @ 0.15mm layer
<teepee>
thread_pitch = 2.5;
<teepee>
thread_tooth_angle = 50;
<teepee>
even with my not so perfectly calibrated printer that ususally is ok with even tolerance 0.3
<greenbigfrog>
haven't calibrated flowrate with this exact filament yet, but I printed it from known filament just before, and I'm printing as accurate as I can. But yeah, 0.25 layer might be the issue.
<InPhase>
greenbigfrog: Inside threads.scad I think I wrote some sort of note that the optimal tolerance is probably related to extruder nozzle size and layer height. Although I didn't test a bunch before theorizing that. :)
<InPhase>
Oh, maybe I did not put that in the file.
<InPhase>
Well, I wrote that somewhere...
<InPhase>
This is the reason I adjusted the value relative to 0.4, however.
<greenbigfrog>
oh, you're the author? *runs and hides*
<InPhase>
Oh. Yeah, that's one of mine. :)
<InPhase>
That's how I remember all the details of the parameters off the top of my head. :)
<InPhase>
Well, some of the details anyway. Most of that was written in 2016 and 2017, so the memories are aging.