<kintel>
AzAv8r If you're interested in helping, we're starting to identify which larger pieces are needed for the next release, but there are probably a lot of smaller pieces.
<kintel>
The big topic is to get Manifold out of experimental mode, and there is a need to go through other issues, tag them for triage and collect them into blockers vs. wishes.
<TylerTork>
Question: I need to take an irregular shape and cut a slope-sided hole whose bottom is that shape and whose sides slope at a given angle. I can use offset to get the shape of the top of the hole, but how do I connect the top and bottom with sloped little segments?
<TylerTork>
I thought about using linear_extrude with scaling, but that doesn't work so great because some of the edges may be perpendicular to the direction of shrinkage, resulting in no slope or even negative slope
<TylerTork>
The shape comes from an SVG file, if that matters.
<TylerTork>
Actually no, hull doesn't work because it also takes out the concavities of the flat shapes I'm starting with. Ideas?
<TylerTork>
I see roof suggested. Will look
<InPhase>
TylerTork: It's unclear what you mean by "slope sided", and the answer hinges on that.
<TylerTork>
well... I was hoping to be able to choose the angle. Also the shape I'm given is the shape of the smaller end of the hole, so I would have to use offset to expand it to the top opening and roof that shape, which I _don't_ think would give me the original shape back.
<InPhase>
Do you want them sloping up at an angle always inward from the tangential perimeter of the starting shape?
<TylerTork>
Think of a countersunk hole, only the bottom shape is specified and can be any shape
<TylerTork>
sloping up and outward from the starting shape
<InPhase>
That's achievable with roof at an arbitrary angle by starting from the larger shape, using roof, scaling the z dimension to change the angle as desired, and then mirroring and cropping the shape with intersection.
<TylerTork>
I suppose I could make a flat shape with a hole in it for the bottom opening, roof that, then add material where needed. However, it WOULD be nice to have a non-45 degree angle
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<J24k45>
roof is now also active on makerworlds customizer - Ü
<TylerTork>
Yes I noticed that. Nice!
<TylerTork>
I don't see that Makerworld will let me import an SVG file, however.
<J24k45>
I adressed that issue but not sure they allow multi scad and import files option soon
<J24k45>
but you can convert svg and put into the code - not nice but for a final version would work
mmu_man has joined #openscad
TylerTork has quit [Quit: Client closed]
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #openscad
extor has quit [Ping timeout: 256 seconds]
L29Ah has left #openscad [#openscad]
fling has quit [Read error: Connection reset by peer]
aiyion3 has quit [Read error: Connection reset by peer]
califax has quit [Read error: Connection reset by peer]
erectus has quit [Read error: Connection reset by peer]
califax_ has joined #openscad
erectus has joined #openscad
aiyion3 has joined #openscad
fling has joined #openscad
califax_ is now known as califax
L29Ah has joined #openscad
RichardP_ has joined #openscad
RichardPotthoff has quit [Ping timeout: 268 seconds]
extor has joined #openscad
mmu_man has quit [Ping timeout: 246 seconds]
extor has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
extor has joined #openscad
mmu_man has joined #openscad
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
mohammad1722 has joined #openscad
paulftw has joined #openscad
paulftw has quit [Changing host]
paulftw has joined #openscad
<paulftw>
Morning everyone!
<paulftw>
Noticed the following behavior:
<paulftw>
x = v5();
<paulftw>
echo(x1=x);
<paulftw>
y = 5;
<paulftw>
function v5() = y;
<paulftw>
x = v5();
<paulftw>
echo(x2=x);
<paulftw>
/ Output:
<paulftw>
/ ECHO: x1 = undef
<paulftw>
/ ECHO: x2 = undef
<paulftw>
But if I comment out the first line - first call to v5(), output becomes:
<paulftw>
Can't figure out why reading a function/variable before initialization affects behavior *after* initialization. I've read the docs on how vars are actually constants and the last write wins, probably a dozen times at least. I understand individual words, but can't make sense of the big picture. Can someone please explain this example or point out a good writeup on the topic?
Guest31 has joined #openscad
Guest31 has quit [Client Quit]
mohammad1722 has quit [Quit: Client closed]
<InPhase>
paulftw: It's a declarative language, not an imperative language.
<InPhase>
paulftw: Which means within a scope like that, there does not exist an execution order, only an order in which definitions are made.
<paulftw>
yes, but second assignment x=v5() should override the first assignment, shouldn't it?
<paulftw>
> In other words OpenSCAD variables are more like constants, but with an important difference. If variables are assigned a value multiple times, only the last assigned value is used in all places in the code.
<teepee>
they are variables as in math
<InPhase>
paulftw: Something a little weird is happening because of the undefined function call. I'm not sure entirely what, but at least it's consistent since the last release.
<InPhase>
paulftw: I don't think we have any sort of extensive test suite for these edge cases of all the ways you can do things wrong by redefining things that are not allowed to be redefined.
<InPhase>
paulftw: Really only a single case of redefining variables is considered well defined, and that's using -D on the command line to override top level variables.
<InPhase>
paulftw: Other cases throw a warning, meaning "Don't do this", and so the behavior of this "don't do this" think has not been very carefully tested for all the edge cases. I think what you are showing as an example seems inconsistent with the behavior described in the documentation.
<InPhase>
paulftw: I also think we should strive to make things consistent and clear, but that we should have broad latitude in how we fix up "do not do this" aspects of the language.
<InPhase>
paulftw: But I also know that inevitably someone will come out of the woodwork and demand we reenable spacebar heating. :)
<t4nk_fn>
WHAT!?!?!? there is no heating right now!!?!?
<t4nk_fn>
:((
<t4nk_fn>
you sickos :|
<teepee>
yeah, that's also the reason why the reassignment can't easily be changed to an error
<InPhase>
I used to use a bit of reassignment out of laziness, just to skip the key presses of commenting out configuration lines. But I patch that up every time I load one of those older files, since we added the warning.
<teepee>
the issue with x being still undefined is that repeated variable assignments virtually move to the place where the first assignment lives
<paulftw>
ok, so basically redefining a variable doesn't "crash" the program but shouldn't be done nonetheless. that's fine. if you chose to do it -- expect unexpected behavior. also ok with me.
<teepee>
no idea why it was done that way, but it's misused for adding defaults on top, var = 3; and allowing var = 50; at the end overwriting the first value
<paulftw>
what's the expected interaction between a declared function and variables it uses?
<teepee>
"in the same scope!"
<InPhase>
teepee: Ah. Moving y=5 above the first x = v5() does indeed change the output to 5.
<InPhase>
Moving y=5 right below the first x = v5() puts it back as undef.
<teepee>
if you have something like if () { x = 3; } that x lives inside that scope of braces and can overlay the outer one
<paulftw>
I've seen others declare a function and then use that function to initialize variables. but I think my example shows that those functions really shouldn't read other variables in scope?
<teepee>
they *should* see the associated variable in static scope if it's not a $ variable
<teepee>
and lambdas should capture the correct value
<teepee>
I would not say I'm 100% confident there's no glitches, but I don't know any right now
<paulftw>
in case that came out wrong - I'm really not here to complain or demand to change things. just trying to understand what is recommended and what isn't, so I don't write code that works in a way I didn't intend.
R2robot has joined #openscad
<InPhase>
teepee: I guess this is a bug then, because this particular scenario fails to pick up -D specification of y, even if the y definition is removed.
<teepee>
hmm, I guess that's because function calls are alwaxys after the assignment
<InPhase>
I wonder how far back this bug goes. :)
<teepee>
so function evaluation will alwas see the "final" assignment
<teepee>
no idea, but my guess is it's pretty much part of the way function evaluation is implemented
<InPhase>
2019 still fails to pick up the -D of y.
<teepee>
or maybe more exact how assignments are ordered already when parsing the file
<teepee>
oh, are you saying that changed?
<InPhase>
teepee: No, I mean same behavior back to 2019.
<teepee>
ah, ok. docker goes back to 2015.03 :)
<InPhase>
2015 release gives me other issues.
<InPhase>
It won't load testme.scad :(A
<teepee>
you have that still running. impressive :)
<InPhase>
Well, not well...
<InPhase>
Every once in a while I can get 2015 to do a command line thing, but not today.
<InPhase>
The gui does not load properly for 2015, being upset about some gtk issues.
<paulftw>
so: 1) functions and lambdas *should* capture last assigned variable value in the same scope. 2) if function is invoked while variables are still being initialized there may be unspecified behavior. does this sound accurate?
<InPhase>
paulftw: Seems correct, yes.
<InPhase>
paulftw: But I don't think that was ever fully that way... There's another edge case I noticed.
<InPhase>
paulftw: If you are in a module, define a variable outside of the module, grab the value of that named variable inside the module, and then define it in the module BELOW that grab, the usage at the top of the module does not pick up the later defined value in the module.
<InPhase>
paulftw: This behavior lets one do things like x = x+5; inside of a module, and it adds 5 to the outer defined x and assigns it to x. Or you can do x = is_undef(x) ? 5 : x;
<paulftw>
what do you mean by "grab"? read it and assign to a local var?
<InPhase>
So it's a benefit that variables are used this way. But it also fails to meet that assumption of "last value".
<InPhase>
Probably we should update the documentation that speaks about this last value thing, but I'm not sure what it should actually be updated to say.
<InPhase>
The most important thing is that variables are single-valued, and should be defined before use. Everything else is probably undefined, except for the special case of -D overriding, which then apparently has this bug.
<InPhase>
While writing code I never have any issues at all, because I follow those two rules.
<InPhase>
paulftw: And yes, that's what I meant by "grab".
<paulftw>
I've been trying to write a snippet to test grabbing, and got another question - is echo executed when modules are evaluated, or when variables are assigned? I always imagined there are two (maybe more) passes in the interpreter
<paulftw>
InPhase: what you said about grabbing/redefining in a submodule doesn't sound like an edge case to me - sub module should not be able to change parent's constants. It's sounds as a logical consequence of not allowing imperative code.
R2robot has left #openscad [See ya'll later. o/"]
<InPhase>
paulftw: A module does not change parent constants. It shadows them within the module.
L29Ah has left #openscad [#openscad]
paulftw has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snakedLX has joined #openscad
snakedGT has quit [Ping timeout: 268 seconds]
<J24k45>
inPhase a=1;b=0;a=b?1:2;
<J24k45>
but define b before a works
<teepee>
because the 2nd a= is moved to the place of the first one
<teepee>
so the actually evaluated code is: a=b?1:2b=0;;
<J24k45>
this only gets annoying if a is defined in your library
<kintel>
Speaking of old versions: Surprisingly enough I can still run OpenSCAD 2010.05 on my mac. We must have done something right :)
kintel has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
L29Ah has joined #openscad
RoyK has joined #openscad
RoyK^ has quit [Ping timeout: 256 seconds]
<teepee>
kintel not bad. looks like runtime compatibility is much much better than supporting compilation on older system
<teepee>
which is probably makes sense from a company perspective, just annoying for developers not fully inside the cult of always having the latest hardware
<teepee>
I never really tried, but maybe it's possible to compile in older docker images too. not hugely useful, more interesting software archeology :)
kintel has joined #openscad
<kintel>
..or deep regression hunting :)
<kintel>
I expect the Windows binaries to still be working too
<InPhase>
Finally we can track down the typos kintel made in 2011!
TheCoffeMaker has quit [Quit: So long and thanks for all the fish]