omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
kintel has joined #openscad
<kintel>
peepsalot: With "submodules" do you imagine building these libs using our own CMake? If yes, I wouldn't mind using these for macOS as well, as it's a pain to maintain separate build scripts.
teepee_ has joined #openscad
<peepsalot>
kintel: yes, as a git submodule, and then in cmake: add_subdirectory(fmt)
<kintel>
I'm all for that :)
<peepsalot>
similar to what I did with mimalloc
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<InPhase>
I didn't realize debian frowned on submodules. That's inconvenient. I guess this is based on their desire to have a complete self-contained deb-src repository?
linext_ has joined #openscad
linext_ has quit [Read error: Connection reset by peer]
linext has quit [Ping timeout: 260 seconds]
<teepee>
it's not the submodule being a problem, having to rebuild potentially hundreds of apps for a single security issue
<teepee>
I suppose the more common the library the more it's a problem, libraries like libz are specifically checked by automation
linext has joined #openscad
Lagopus has quit [Read error: Connection reset by peer]
Lagopus` has joined #openscad
<kintel>
Huh, I didn't realize that Qt6 supports building Qt apps for WASM and running them in a browser: https://doc.qt.io/qt-6/wasm.html
Lagopus` has quit [Read error: Connection reset by peer]
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
xloem[m] has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
califax has quit [Remote host closed the connection]
califax has joined #openscad
kintel has joined #openscad
Guest43 has joined #openscad
Guest43 has quit [Client Quit]
<kintel>
..and for some reason macOS tests now also fail on GitHub: Tests hang until the process gets killed after 3h
<kintel>
That also feels like a regression caused by a changed build environment. Perhaps GitHub pushed out new build images and upgraded a bunch of stuff?
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kintel>
For the Windows build, the runner wasn't changed. The only relevant change could be that MPFR was upgraded from 4.1.1 to 4.2.0. ..and we did encounter an MPFR bug recently, so that could be worth looking into
<kintel>
JordanBrown[m]: You're using MSYS2, right? Are you able to reproduce the Windows issue if updating your MSYS install?
<teepee>
hmm, we only install icu, maybe that icu-devel is new and needed?
<teepee>
nope, icu-devel looks unchanged since at least january 2021
<xloem[m]>
hi #openscad … does any know whether openscad can directly generate slicing gcode for a 3d printer?
<teepee>
xloem[m]: it can't and it's not supposed to
<teepee>
there's various slicers you can use depending on the printer type you have
<xloem[m]>
thank you i think … do any register as local services to use from openscad’s menu?
<teepee>
I don't know what that means
<teepee>
you mean integrate the slicer into the menu of openscad?
<xloem[m]>
with the other integrated 3d printing services
<peepsalot>
octoprint
<teepee>
yeah, there's 2 options for print services currently, octoprint (likely local) and a cloud service
<teepee>
in both cases it would upload the STL/3MF and gcode would be generated there
<xloem[m]>
thank you, it didn’t occur to me i could run octoprint locally
<teepee>
I use a local Cura which also integrates with octoprint, so my flow is
<teepee>
save 3mf in openscad -> Cura sees the file is changed and offers a button for reload -> slice -> "print in octoprint" -> click print on the octoprint webpage
<xloem[m]>
i like to imagine the steps could be all automated together somehow
<xloem[m]>
such that a larger project generator could run them
<teepee>
they could, but that would need some effort across the various apps
<teepee>
which basically would need someone organizing that, sort of a "project manager" :)
<xloem[m]>
if the protocols are normative it can be easier to factor larger systems in. octoprint sounds normative (haven’t looked)
<kintel>
teepee: FYI: I killed your stuck macOS tests
<teepee>
ah, thanks
<peepsalot>
anyone have previous experience with libfmt? it looks like fmt::memory_buffer would be the preferred replacement for ostream/ostringstream ?
<peepsalot>
i'm still trying to figure out which parts of the api I should use
<JordanBrown[m]>
I used it in trying to create a printf-like function for OpenSCAD, but I can't say that I got deeply familiar with it.
<InPhase>
peepsalot: Does it support internationalization?
<JordanBrown[m]>
I got something sort of working, but failed when I got to supporting variable lengths (like %*s in printf) because it really wanted that argument to be an integer and OpenSCAD numbers are doubles.
<peepsalot>
i don't think its meant to be a replacement for (gettext?)
<InPhase>
peepsalot: If you're just handling doubles, nevermind. If you're thinking of a big swap, we should keep in mind the opportunity to slip in support for this.
<InPhase>
peepsalot: Maybe not the right time or place for this. Just a thought.
<peepsalot>
InPhase: its mostly for doubles, but ends up affecting a lot of other printing code. basically everywhere I ended up using `scad::ostringstream` in PR #4384
<lf94>
(wouldnt be surprised if it already exists lol)
<peepsalot>
fmt seems stateless AFAICT, and the state I want to store is basically how much precision to output (so keep echo's the same for now, while letting .csg output use full precision)
<InPhase>
lf94: It would require some restructuring.
<InPhase>
lf94: The notion has certainly been discussed before, however.
<lf94>
does openscad work on cpu only
<peepsalot>
lf94: better start figuring out the API
<lf94>
or can it use gpu
<lf94>
for computations
<InPhase>
But yeah, the primary goal of libopenscad would be forcing some API discipline. I don't think we're super far from a structure that could do that.
<peepsalot>
currently cpu only
<peepsalot>
i was actually reading a bit and watching some talks about SYCL, which is a c++ interface for heterogeneous computing. looks pretty interesting
<InPhase>
Currently we have a sort of hacky slap-together of command-line and gui modes. They should be more cleanly distinct as two operating modes using a well-defined API.
<peepsalot>
anyone else looked at SYCL?
pah has joined #openscad
<teepee>
I've seen a talk about it, so just a glimpse :)
<InPhase>
peepsalot: I see you requested a review on that PR that I never got around to giving. But I suppose you'd need some WIP time yet.
<peepsalot>
yeah i decided to set it back to WIP after I had requested review
<InPhase>
We'll pretend I forgot to do that on purpose then.
<peepsalot>
the problem with doing stuff on GPU is that multiprecision rationals required by CGAL means the length of numeric values is indeterminate, which i don't think GPU would handle very well if at all
<lf94>
well there'll be a tradeoff
<peepsalot>
lf94: lately we are struggling just to keep the continuous integration servers running properly. so not a lot of development going on with GPU compute or separating into a library
<lf94>
roger
<lf94>
concerning cgal + precision: just a tradeoff we gotta accept for speed
<lf94>
everything must become f32
<lf94>
I wanna see openscad handle millions of polygons no problem
<peepsalot>
there is no tradeoff to be made as long as we continue to use CGAL. it **requires** exact rational number inputs. it won't function without them
<teepee>
the best option is probably trying Manifold
<peepsalot>
so that means converting to a new geometry library and/or developing our own implementations for some of the operations
<teepee>
and it might be possible to plug it into the fast-csg stuff, we probably still need CGAL for a while for some special stuff
<peepsalot>
yep, Manifold looks nice, there was another similar one that popped recently called MCUT which could be promising
<JordanBrown[m]>
kintel: I'm upgrading my MSYS2 install and will try a build.
<peepsalot>
probably the big one that will still require CGAL being 3D minkowski, which is a shame since it is one of the biggest pain points
<peepsalot>
i don't think manifold mentions support for that
<teepee>
we can always ask if the decompose could be put into manifold :)
<peepsalot>
yeah, that would be great
<peepsalot>
i would still like to redo the core of how we handle various geometry types and converting between them, before attempting to support manifold
<peepsalot>
i was discussing it a few months back in IRC, been meaning to put into a proposal or discussion/issue of some sort.
<teepee>
similar to how fast-csg does?
<peepsalot>
kinda, but not really :P
<teepee>
haha, ok
<peepsalot>
i saved ~500 lines of scrollback of related discussion for it, and have a partial write-up which summarizes the idea
<peepsalot>
but right now i'm just trying to focus on fmt stuff
<teepee>
good plan, too many things at the same time usually means nothing happens
<teepee>
does godbolt support fmt well now?
<teepee>
could be useful to share some examples
<peepsalot>
yeah, i was playing with that a bit
<teepee>
cool, some time ago I had some issues with it only working for some things even though it was in the library selection
<teepee>
well, the execution failed as it could not link
<teepee>
did you see some option that would restrict to the std::fmt features?
<teepee>
but then, there's probably no problem just keeping the lib :)
califax has quit [Remote host closed the connection]
<peepsalot>
i had a different more involved example I was playing with, but I think my browser got restarted and I hadn't saved it to a link
pah is now known as pa
<teepee>
oh, nice, so it does automatic max precision
<teepee>
I know it supports extensions via templates, if we could plug that together with our internal data types, that would be very nice
califax has quit [Remote host closed the connection]
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
califax has joined #openscad
<peepsalot>
InPhase: there's some stuff about locales, but i think that's just for setting a "thousands separator", radix point character, etc. not sure if that's what you meant
ali1234 has quit [Remote host closed the connection]
<InPhase>
peepsalot: I was thinking more broadly than doubles. Like, someday we should probably support having language translations for every error message.
ali1234 has joined #openscad
<InPhase>
peepsalot: There is a whole world of people out there unable to use a 3D modeling program that only spits out messages in English. We as a pile of people don't know enough languages to reach most of them. But, eventually we could put in place the infrastructure to let other people maintain language translation files.
<teepee>
but that's gettext?
<teepee>
or do you mean in the scad script itself?
<InPhase>
Are we actually using it for anything?
<teepee>
most of the GUI is translated, just the core stuff currently is not
<peepsalot>
see the locale dir under our project root
<teepee>
at least for our own messages, I don't see a technical reason preventing us from doing those too
<InPhase>
I'm envisioning for all the warnings and errors and such. Where it ties into the formatting.
<teepee>
it should not, it just defines how the format strings look like
<InPhase>
It has to be called before the variables are put into place.
<InPhase>
And thus the usage is decentralized.
<teepee>
that's the point, if done right, it's not an issue
<teepee>
basically good use of format strings vs. coding some sort of concatenation
<InPhase>
A way to make it centralized, is to have whatever function does the formatting, do the language lookups.
<InPhase>
Which could be a small templated custom function that calls gettext plus any formatter chosen.
<teepee>
it's really just that _() macro allowing the gettext tools to discover it for extraction
<teepee>
and at runtime it does the lookup / translation with that text as key
<teepee>
right now it's boost, using the %.2f but for gettext it does not matter at all if that would be something like {int:.2} or whatever
<InPhase>
So if we just threw that in at all the core messages, there is a gettext tool that will extract all of these messages and indicate that someone should add a translation?
<teepee>
so for error translation right now we just would need to add the _() around the string
<teepee>
yes
<InPhase>
Okay. That sounds good enough. :)
<teepee>
it might not be perfect, but it would be a start
<teepee>
the "good" translation would require everything as sensible parameters, so even the order can be swapped if the language grammer needs that
<teepee>
plus gettext has support for plural suffixes, but I don't think we've used that
<InPhase>
I bet we could even make chatgpt do most of the translation work to save some drudgery.
<teepee>
I think you can do things like 1 error / 2 errors - with the s depending on the actual value
<InPhase>
I tested. It seemed to actually be pretty good at naturalistic translation.
<teepee>
I'm not sure, usually those translations have not a lot of context, so it's even difficult for manual translation
<InPhase>
We can feed it context.
<InPhase>
This is one of the things it's good at.
<InPhase>
But then we'd need to start with a language where we have someone to fact check this theory.
<teepee>
I'm not going to stop anyone from doing it :D
<teepee>
I usually cross check translation patches via google translate :)
<JordanBrown[m]>
polygons per se won't help you with the 3D curves involved.
<JordanBrown[m]>
I should note that working with 3D curves is not beginner stuff.
<JordanBrown[m]>
The Bezier surface tools from BOSL2 will probably be useful in modeling the hull shape. I expect that you would have to piece together between two and six surfaces, plus something on the top, maybe plus something on the bottom.
<warship>
i working but how can i use bezier curve , code??
<peepsalot>
i would start with trying to define a function that describes the profile of the hull (viewed from above), and another function for the profile viewed from the side. then you could combine those into triangular cross sections and literally combine them with the hull() operation
<warship>
ah is very difficult so , well
<warship>
can i make 3 solid from pront and back part and centrale??
<warship>
ok is hard for beginners
<peepsalot>
yes you can define polygon() for 3 cross-sections, and linear_extrude() each one by a small amount to make it 3d, then translate each one along z axis, and hull() around the lot of them
<peepsalot>
then probably rotate([-90,0,0]) to put that in a regular orientation
<warship>
do you think openscad is too difficult ??
<peepsalot>
warship: openscad can definitely be challenging for some kinds of shapes. especially if you are new to the language. see the tutorial in the channel topic for a beginner intro
<warship>
ok i look at tutorial
<JordanBrown[m]>
https://bpa.st/AUN36 is a slightly cleaned-up version of what I posted earlier.
<JordanBrown[m]>
But if you don't understand Bezier curves it will be very hard to understand, and if you don't understand Bezier patches it will be a little hard to understand.
<warship>
i am beginner on openscad i have started to work 1 day ago
<JordanBrown[m]>
There will be two difficult parts: (1) tweaking the parameters to get the shape you want, and (2) piecing several curves together to get the overall shape.
<JordanBrown[m]>
This is, alas, *not* a beginner project.
<JordanBrown[m]>
For a beginner version, consider using cylinders and cones that you stretch in various ways.
<JordanBrown[m]>
But that won't get you the 3D curves that the real hull has.
<warship>
do you have make:calculus book ??
<JordanBrown[m]>
no
<JordanBrown[m]>
Here's a version that is in some ways simpler...