<JordanBrown>
One sort-of argument against the find() function that I just proposed is that maybe we should move toward type-specific methods.
<JordanBrown>
Thus, e.g., [1,2,3].find(2) would return 1, while "aardvark".find("dv") would return 3.
<JordanBrown>
Maybe that last isn't a good example; maybe it should be a different verb. But the idea would be that we move toward namespace that is tied to the particular type and so does not conflict with either other types or with user functions.
dustinm` has quit [Quit: Leaving]
dustinm` has joined #openscad
peeps has quit [Remote host closed the connection]
peeps has joined #openscad
peeps has quit [Quit: Connection reset by peep]
peepsalot has joined #openscad
arebil has joined #openscad
epony has joined #openscad
epony has quit [Remote host closed the connection]
JordanBrown has quit [Read error: Connection reset by peer]
JordanBrown1 has joined #openscad
fling_ has joined #openscad
fling has quit [Ping timeout: 255 seconds]
fling_ has quit [Remote host closed the connection]
fling has joined #openscad
<InPhase>
JordanBrown1: That would open up more options. For example, lists really need a .findf that takes a comparator function.
<InPhase>
JordanBrown1: It kind of needs that because you might have a list of function references to search by equality (regular .find) or a list of other elements you'd want to apply a comparator too (float values with range check, or a list of strings to do search-within)
<InPhase>
JordanBrown1: I see you attempted to address that with your free function proposal with a hackier list of function references proposal, but that again goes down the search rabbit hole of magic type-specific behaviors.
<InPhase>
And then suddenly you can't find a list of function references in a list of lists of function references.
<InPhase>
And granted, that's maybe a rare thing to want to search, but it'd be better to take the opportunity to do this right and clean and consistent this time.
<InPhase>
Also .findall would be an option, for returning a list of result indices.
ToAruShiroiNeko has quit [Ping timeout: 264 seconds]
linext_ has joined #openscad
linext has quit [Ping timeout: 240 seconds]
To_Aru_Shiroi_Ne has quit []
arebil has joined #openscad
ToAruShiroiNeko has joined #openscad
linext_ has quit [Ping timeout: 255 seconds]
linext has joined #openscad
ToAruShiroiNeko has quit [Ping timeout: 268 seconds]
R2 has joined #openscad
To_Aru_Shiroi_Ne has joined #openscad
R2robot has quit [Ping timeout: 268 seconds]
teepee has quit [Remote host closed the connection]
teepee has joined #openscad
<JordanBrown1>
InPhase Maybe I'm not following, but the only magic type-specific behavior in the find() proposal is that a pattern that is a function is called, not searched for.
<JordanBrown1>
Yes, that means that you can't search for a function in a list of functions, but that seems like a really narrow case.
<JordanBrown1>
You (the caller, not the implementation) can work around that, if you really want to, by wrapping both the pattern and the search list entries in arrays.
<JordanBrown1>
That is, find([f], [for (f=flist) [f]])
<JordanBrown1>
then you are searching for a list of one function, in a list of lists of one function, and don't get the magic function behavior.
<JordanBrown1>
So the rabbit hole doesn't get any deeper.
<JordanBrown1>
If one thought that was a real problem, the signature could change to find(list, val, f), where you are expected to supply either val or f and would supply f as a named parameter.
<JordanBrown1>
(We really need a better way to describe function signatures.)
L29Ah has left #openscad [#openscad]
<JordanBrown1>
for my find() example above, I probably shouldn't have reused "f": find([f], [for (e=flist) [e]])
<InPhase>
JordanBrown1: Yeah, I stipulate it's a lot less magic behavior, and thus better.
<InPhase>
But I think zero magic behavior would probably be best for this, considering the past experiences. A separate function parameter could work, if we wanted the free function.
<InPhase>
I see an appeal though to an object call version of this. Maybe we'd even want different find parameters for different input types.
<InPhase>
e.g., case_insensitive=true
<InPhase>
Or ignore_case
<InPhase>
v.findall(is_nan) would be pretty cool. :)
L29Ah has joined #openscad
<linext>
is there a version of minkowski that keeps the bounding box of the larger shape?
epony has quit [Remote host closed the connection]
epony has joined #openscad
<InPhase>
linext: No, but it's trivial to do for simple shapes.
<InPhase>
Like, on cube you just do resize afterward.
<InPhase>
Although I typically do everything by precalculating the dimensions to use.
<InPhase>
Also 2D has negative offset, which achieves this.
<linext>
yea, for a cube and sphere it's not hard to calculate
<linext>
but for combinations of odd shapes it might be nice to have
<InPhase>
It's just really hard to implement that sort of thing for 3D, as it doesn't have obvious definitions in all cases. But offset3d is probably achievable.
L29Ah has left #openscad [#openscad]
<linext>
maybe it could be done with scale()
<InPhase>
For 2D the offset capabilities are pretty potent. e.g., random demo shape: $fs=0.4; $fa=1; rotate_extrude() intersection() { square(20); translate([5,0]) offset(3) offset(-6) offset(3) { square([15, 8]); square([8, 20]); } }
<linext>
instead of scale by a factor, scale to a dimension
<InPhase>
That's what resize is, scaling to a dimension.
<InPhase>
But this does not always have the desired effect, especially on non-convex shapes.
<InPhase>
e.g., if you have two cubes 20 units apart inside of a box forming the outer parts of the bounding box, minkowski by 5, and then resize back down to the original bounding box, and those cubes are not 20 units apart anymore.
<linext>
ah
<linext>
i didn't know about resize
<InPhase>
The core problem is that minkowski is in the direction of the normals, while resize is with respect to absolute coordinate position.
L29Ah has joined #openscad
To_Aru_Shiroi_Ne has quit [Ping timeout: 272 seconds]
guso78k has joined #openscad
guso78k has quit [Client Quit]
hyvoid has joined #openscad
omegatron has joined #openscad
teepee has quit [Ping timeout: 255 seconds]
teepee has joined #openscad
<JordanBrown1>
InPhase, linext: note also that resize() has an implied render() and so is not as performant as scale. It also loses color.
<JordanBrown1>
Performant in preview, that is.
<InPhase>
Hmm, that does a render? I never noticed...
<JordanBrown1>
it's got to
<InPhase>
I guess I almost never use it on anything big.
<JordanBrown1>
you can't calculate the bounding box of a general geometric object without rendering.
<JordanBrown1>
In union the bounding box of the result is always the union of the bounding boxes of the children, so is easy.
<JordanBrown1>
But not so with difference and intersection; there you have to actually do the work.
<JordanBrown1>
I suspect that the bounding box of a minkowski sum is the minkowski sum of the bounding boxes of the children, but I'm not absolutely sure.
ToAruShiroiNeko has joined #openscad
<JordanBrown1>
I wasn't sure that it lost color, because it doesn't need to - it could render, get the bounding box, discard the render result, and then preview the children, but I confirmed that it does lose color.
J24k50 has quit [Quit: Client closed]
J24k50 has joined #openscad
peeps[work] has quit [Quit: Leaving]
peeps[work] has joined #openscad
<linext>
it would be nice if there was a button in openscad next to STL export that could launch a slicer with the file as the argument
<linext>
there's a button that says "3D Print"
<linext>
i have to keep saving to STL, switch to slicer, reimport STL file
<linext>
takes about 15 seconds
mmu_man has joined #openscad
epony has quit [K-Lined]
<J24k50>
you can setup the 3D print button with the command you need linext
<J24k50>
including direct slicing and printing
<linext>
does it require restarting after editing the preferences?
little_blossom has joined #openscad
<teepee>
3d print button only supports octoprint and a 3d printing service of which I forgot the name