<J2343>
is there a trick to filter the edits or did you crawled through them to narrow this edit down?
oieieio has quit [Ping timeout: 260 seconds]
<InPhase>
Binary search algorithm.
<InPhase>
It's efficient even by hand.
<JordanBrown[m]>
Yep, I do it frequently. But it's kind of surprising that Wikipedia doesn't have a "blame" mechanism.
<InPhase>
It would require a bit of word/character nuance rather than line-based, but yeah, that could be pretty handy.
<InPhase>
A hover-popup strategy might be the only way to pull it off.
<JordanBrown[m]>
Though I just did a linear quindecadal search to find that it took six months for somebody to fix the its-it's error.
<JordanBrown[m]>
(Which is surprising because in that time there were two *other* copy-edit changes to that paragraph.)
<JordanBrown[m]>
You could do straight line-by-line blame if you did it on the source text. You'd really want to do that anyway, for some changes, since some changes aren't directly visible in the rendered version.
sauce has quit [Remote host closed the connection]
fury999io has quit [Quit: Konversation terminated!]
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
guso7847 has joined #openscad
<guso7847>
BTW: I appreciate the persistant cache and editor autocomplete PR. Whats the latest progress/status of it ?
guso7847 has quit [Client Quit]
califax has quit [Remote host closed the connection]
califax has joined #openscad
guso7889 has joined #openscad
<guso7889>
and what happened to the "convex" primitive. Also I do like it very much but as of 2023 i don't see it there(and i have studied the code quite a bit already)
califax has quit [Remote host closed the connection]
califax has quit [Remote host closed the connection]
califax has joined #openscad
califax has quit [Remote host closed the connection]
califax has joined #openscad
Trieste has quit [Ping timeout: 252 seconds]
<JordanBrown[m]>
(BTW, I do not know who BonyJordan is. I'm Jordan, and I'm kind of bony, but it's not me.)
milza has joined #openscad
<peepsalot>
I'm stuck on another libfmt problem. the recommended way to format user-defined types is the template specialization, but I'm not sure how to combine that with virtual dispatch
<peepsalot>
i.e. shared_ptr<Expression> and all of its the derived classes
Trieste has joined #openscad
milza has quit [Quit: milza]
guso78 has joined #openscad
<guso78>
JordanBrown[m], yes, is there a "convex" available. i never noticed and i would often use it , if it was there
<guso78>
or is it possible to specify a single point inside union ?
<guso78>
sorry:inside hull
<teepee>
not yet
<JordanBrown[m]>
There is no single-point mechanism.
<JordanBrown[m]>
No, there isn't a specific convex function, though I think some people have found that building a totally bogus polyhedron from the points, and then calling hull() on that. I haven't tried.
<JordanBrown[m]>
make that "found that it works to"
<JordanBrown[m]>
or something like that
<guso78>
ahh,i tought it was working already ...
<JordanBrown[m]>
Other than that, if the PR's open then that's a good indication that the feature isn't there yet.
<JordanBrown[m]>
And if the PR has no activity in the last five years, that's a good indication that nobody is working on it.
<guso78>
haha. got it
<peepsalot>
oops, meant to elaborate on the template specialization: that of struct fmt::formatter<UserType> which has interface of a constexpr parse method and format method https://en.cppreference.com/w/cpp/utility/format/formatter
<JordanBrown[m]>
peepsalot: Did you look at the work that I did? I think I used something in that area.
<JordanBrown[m]>
I don't remember any of the details, so you probably know more than I do about how that stuff works.
<guso78>
i would never ever even consider to raise a PR if it was not totally convinced, that the changes are working. apparently others have different strategies ..
<peepsalot>
JordanBrown[m]: I can't remember, what was the branch for that?
<JordanBrown[m]>
guso78: There are many strategies, and just because the original author thinks it's done and appropriate to merge in doesn't mean that other people do.
<peepsalot>
i'm starting to wonder if Expression inheritance hierarchy should be made replaced with a variant instead
<JordanBrown[m]>
My impression is that variants should be replaced by inheritance :-)
<JordanBrown[m]>
I think that printf branch has two implementation variations with different strategies. Neither ever worked well enough for me to propose as a PR, but I think I got past the basic "feed Value into the formatter" part of the puzzle.
<JordanBrown[m]>
I think the last one stalled on support for variable widths, where the library really wanted those values to be integer types and we don't have integer types.
<JordanBrown[m]>
that is, being able to say the equivalent of format("%*s", len, str)
<peepsalot>
guso78: the first reply to that shows an example of abusing polyhedron/hull to do what is wanted. the polyhedron just defines all the points, and a single face which consists of every point
<guso78>
haha, this is intelligent. is it efficient ?
teepee_ has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee_ is now known as teepee
<teepee>
it's a bad idea
<JordanBrown[m]>
Well, I just tried it for 21 random points, and it took 0.036 seconds.
<peepsalot>
guso78: yes, i think it should be pretty efficient. hull only concerns itself with vertices, and discards face information
<JordanBrown[m]>
p = [ for (i=[0:20]) rands(0,100,3) ];
<JordanBrown[m]>
f = [ for (i=[0:20]) i ];
<JordanBrown[m]>
hull() polyhedron(points = p, faces = [ f ]);
guso78 has quit [Ping timeout: 260 seconds]
<teepee>
moot point, garbage-in garbage-out applies
<teepee>
that the current garbage-out is useful does not imply that's always going to be the case
<JordanBrown[m]>
Which part is moot? If you feed in a collection of sensible points, you'll get a sensible answer.
<teepee>
no
<JordanBrown[m]>
RIght.
<teepee>
you are *not* feeding points to hull()
<JordanBrown[m]>
*Today* you'll get a sensible answer.
<teepee>
you create an invalid polyhedron()
<JordanBrown[m]>
But since it *is* garbage input, it's not guaranteed that *tomorrow* you'll get a sensible answer.
<JordanBrown[m]>
Though at this point I suspect that enough people know the trick that it may have to keep working.
<teepee>
if we get more validation for polyhedron to help people with errors this may break the random broken use case
<JordanBrown[m]>
Indeed. Suggests that we can't add more validation until we have an official replacement for this trick.
<teepee>
I'm very much for backward compatibility
<teepee>
that case is not covered in my view
<JordanBrown[m]>
I'd agree that we can break it, but we'd need to supply a replacement for this real-world case.
<teepee>
we really should, yes. but I would not see that as complete showstopper
<JordanBrown[m]>
That replacement might be convex(points) or hull(points) or polyhedron(..., validate=false).
<JordanBrown[m]>
It appears that it would be easy enough that we should do it, if anybody ever gets around to doing more polyhedron validation.
<JordanBrown[m]>
I think we should do at least "all faces connected and wound consistently", because that's pretty easy.
<teepee>
I think more matching would be hull() { point(); point(); }
<JordanBrown[m]>
Though I would want a "validate=false" mechanism (maybe just not setting stop-on-warning), because while I am developing a polyhedron I usually do it incrementally, one set of faces at a time.
<JordanBrown[m]>
Sure, points would be OK too, but then we need a zero-D subsystem.
<teepee>
and 2.5 ideally
<teepee>
so you can move 2d shapes in 3d space and hull those
<JordanBrown[m]>
yes
<JordanBrown[m]>
and whatever you want to call a variation that would allow a collection of lines that do not form closed polygons.
<JordanBrown[m]>
The laser cutter folks would really like that.
<teepee>
I'm not sure that's on the plate any time soon
<teepee>
but maybe there's a way to keep that as option as long as everything stays 2d or something
ur5us has joined #openscad
<JordanBrown[m]>
polyhedron(..., validate=false) would address the need, without being unwanted future baggage.
califax has quit [Remote host closed the connection]
califax has joined #openscad
<teepee>
what need? polyhedron() and lasercut seems to have not much overlap
<teepee>
I would assume lasercutters are pretty much fixed for 2d input
J2350 has quit [Quit: Client closed]
J2350 has joined #openscad
Lagopus has joined #openscad
Bocaneri has joined #openscad
Bocaneri is now known as Guest857
Sauvin has quit [Ping timeout: 248 seconds]
Trieste has quit [Read error: Connection reset by peer]
Trieste has joined #openscad
Trieste has quit [Remote host closed the connection]
Trieste has joined #openscad
<J2350>
the hobby cutter sure . .but there are multi axis laser cutter that can do chamfer and helical cuts
ToAruShiroiNeko has joined #openscad
To_Aru_Shiroi_Ne has quit [Ping timeout: 268 seconds]
Trieste has quit [Quit: Be well!]
Guest857 is now known as Sauvin
snaked has joined #openscad
Guest23 has joined #openscad
<peepsalot>
teepee, InPhase: any thoughts about potentially converting Expression into a variant, like Value, rather than the current inheritance hierarchy?
<teepee>
I'm not attached to any structure, if it works that fine :)
<teepee>
what would be the benefit in this case?
<peepsalot>
teepee: i think it would make it easier to implement custom fmt::formatter<T>
<teepee>
that sounds useful
<peepsalot>
i don't really see how that interface is meant to combine with virtual dispatch
<JordanBrown[m]>
Do look at the work that I did, because I think I made it work.
Guest23 has quit [Quit: Client closed]
<JordanBrown[m]>
teepee: polyhedron(..., validate=false) would address two needs that would be in trouble if we added polyhedron validation: (1) today's desire to construct a convex polyhedron out of a point cloud, to eventually be replaced by a real answer, and (2) an ongoing desire to be able to build a polyhedron incrementally, one set of faces at a time.
<peepsalot>
JordanBrown[m]: I looked at it, but I just saw formatting of Value, which I already have an implementation of. the current issue is with class Expression, where many types derived types contain shared_ptr<Expression> for their sub-expressions
<peepsalot>
its a different kind of problem
<peepsalot>
from Value's variant. so that's why i wanted to make it more like that
<JordanBrown[m]>
Is the problem that you are trying to format *the expression itself*, or the result of evaluating it? The result of evaluating it is, of course, a Value.
<JordanBrown[m]>
I'm dubious of the value of "formatting" an expression, other than calling toString on it.
<peepsalot>
the Expression itself
<peepsalot>
which can contain a Literal Value
<JordanBrown[m]>
So what value do you expect to add by "formatting" it? Yeah, it probably needs to fit into an overall output architecture, but if you just called toString then what would be missing?
castaway has quit [Ping timeout: 252 seconds]
<JordanBrown[m]>
ISTM that the only use cases for "formatting" an Expression are str(function), echo(function), and AST dump, and none of those seem like they need anything more than toString.
<peepsalot>
so that AST or CSG dump can use full precision, without changing echo's behavior (which is basically equivalent to {:.6g} iirc)
<JordanBrown[m]>
Does it really make sense to "pass down" number formatting from some high level? Does it make sense to say "format this expression with one digit after the decimal of any numbers that it might or might not contain"? I would say not, that if you want to do something better about how those numbers are formatted, you'd do that in Literal.toString().
<peepsalot>
... and with possibility of having some printf user function that could eg print a vector of points to a specific precision