<JordanBrown>
I'm running a development snapshot, not my own build.
<teepee>
that submudule crazyness has to stop at some point ;-)
mmu_man has quit [Ping timeout: 252 seconds]
<pca006132>
ah interesting
<pca006132>
we use FetchContent as fallback
<pca006132>
there are three ways of supplying clipper2: pkg-config (if you installed clipper2), FETCHCONTENT_SOURCE_DIR_CLIPPER2, or it will try to automatically download clipper2
<InPhase>
JordanBrown: It failed on the latest dev snapshot for you?
<kintel>
FYI: I went through all open issues related to CGAL rendering problems, and found that 36 of the still open issues work perfectly with Manifold!
<kintel>
There are still some remaining issues failing with Manifold, mostly related to minkowski
<JordanBrown>
That (#5075) looks like Nophead's issue where the behavior of $ variables at the top level of use<>d files changed.
J24k16 has quit [Ping timeout: 250 seconds]
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
erectus has quit [Remote host closed the connection]
erectus has joined #openscad
<InPhase>
JordanBrown: Caused by the same thing, but pretty different, because that's literally just a case that should have always been a normal variable.
<InPhase>
JordanBrown: Some people use $variables because they are pretty or something I guess. :)
<InPhase>
JordanBrown: I would submit that's an additional hazard of the old buggy behavior. Some cases prevented dynamic variables from working right, blocking people using them from understanding how the dynamic part actually works.
<guso78k>
InPhase, your bezier patch matches really nicely, however the order of the input axes appears to be crucial(winding order). will need to develop a procedure to fix the order
mmu_man has quit [Ping timeout: 272 seconds]
mmu_man has joined #openscad
guso78k has quit [Ping timeout: 250 seconds]
<JordanBrown>
InPhase: The real problem is that we don't have a clear definition of the evaluation and lookup semantics of top-level variables in use<>d files.
mmu_man has quit [Ping timeout: 255 seconds]
<JordanBrown>
That problem applies to both $ variables and normal variables.
<JordanBrown>
And there are decent arguments for any of several models.
<JordanBrown>
And, without experimenting, what *does* it do?
<JordanBrown>
(It didn't do what I expected!)
<JordanBrown>
Here's a little better example (that I actually tested :-): https://bpa.st/Q7PA
mmu_man has joined #openscad
<InPhase>
JordanBrown: That's a vestigial error from the fact that we never got around to removing the constant reprocessing step.
<InPhase>
That constant reprocessing has side-effects beyond just wasting cpu load, such as opening up the window for lexical scopes to be dynamic.
<InPhase>
And... this is very bad.
<InPhase>
JordanBrown: I don't think the definitions have ever been confusing.
<JordanBrown>
As I commented in the bug report, at the moment we have the worst of all worlds: we reprocess constantly, *and* we're incompatible with 2021.01.
<JordanBrown>
I don't have a problem with the notion of considering the file scope in a use<>d file to be inserted, lexically and dynamically, between the caller and the callee.
<InPhase>
I don't consider that the worst of both worlds, since bug-for-bug compatibility is not a virtue. :)
<InPhase>
But removing the reprocessing is a logical next step.
<JordanBrown>
Bugs that people have depended on are a special case.
<JordanBrown>
Inserting the file scope that way means constant reprocessing - so if you don't want that, don't put variables at the file scope.
<JordanBrown>
Alternatively, maybe, process once at "use" time. But that leaves $ variable assignments in a totally unclear place.
<InPhase>
Once at use time is the only logical approach. If we want to support litering code with nested use calls deep inside modules so people can reprocess repeatedly within modules, I don't care if this is done. :)
<JordanBrown>
I was surprised to find that the used-file-scope assignments were in a sense processed before the arguments.
<JordanBrown>
which is why in the second example I did both before-the-call and in-the-call assignments.
<JordanBrown>
I agree that once only at use time is a reasonable model, though I am a bit unhappy that it leaves top-level $ assignments in a very unclear place.
<InPhase>
What's unclear about it?
<JordanBrown>
Well, where do they appear (if at all) in the sequence of scopes searched?
<InPhase>
Not at all when calling a use<>d function or module.
<InPhase>
They are not part of the dynamic execution path to get to them.
<InPhase>
use<> is strictly defined as NOT importing anything other than functions or modules into the using scope.
<JordanBrown>
Who said anything about importing them into the using scope?
<InPhase>
And the dynamic call stack flows down from the top of the using scope. So it is a strict error to have functions or modules able to access dynamic variables from within the use<>d file.
<JordanBrown>
Sorry, to be clear, I meant where do they appear in the sequence of scopes searched *for a module in the use<>d file*.
<InPhase>
Never. They cannot be allowed to be accessed.
<InPhase>
We defined them as not part of the call chain.
<JordanBrown>
It seems kind of disturbing that in "$a=1; b=2;" one of them is visible and the other isn't.
<InPhase>
Why? One is lexical, one is dynamic. Lexical scopes are lexically accessible. Dynamic scope must only access the dynamic call path.
<JordanBrown>
Oh, I understand the logic. It just feels uncomfortable.
<InPhase>
Well, it's what the words mean. :)
<JordanBrown>
It doesn't feel neat and tidy.
<JordanBrown>
Sigh. We have two distinct pieces of documentation that both claim to be the TOC for the language reference... and they aren't the same.
<JordanBrown>
actually, the documentation says "imports modules and functions, but does not execute any commands other than those definitions", which arguably means *no* top-level assignments should be executed, period.
<InPhase>
guso78: Well, I had fixed those by rectangular dimensionality, intending for the result to be rotated and translated into place, in order to resolve that winding order issue. It otherwise seemed complicated.
<InPhase>
guso78: But it would technically work as long as the equivalent of the original x, y, z sequence obeys the right hand rule for orientations. i.e., (x cross y) dot z must be positive.
<InPhase>
guso78: So if you want to do arbitrary vectors, calculate that sign check and use it to flip ordering if needed.
mmu_man has quit [Ping timeout: 272 seconds]
<InPhase>
guso78: Or I suppose, to swap inputs for simplicity.
<InPhase>
guso78: Swapping x and y would be almost a no-op on appearance, except in the edge case where the point counts per row drops by faster than 1, in which case there is an asymmetry in the tesselation. But if you did NxN instead of NxM as I originally had it, that won't happen.
<InPhase>
JordanBrown: One could debate what "execute any commands" means, but it is concerning that echo gets run like in your example and others.
<InPhase>
JordanBrown: Although we typically regard echo as an allowed debugging side-effect.
<InPhase>
JordanBrown: I take the spirit of use<> from this statement as the use file should not impact anything outside of it. For example, the manual explains that use<>d files can have other use<> statements within, which can import things that can be used within the topmost use<>d file, but that do not propagate upward to the top level.
<JordanBrown>
Sure, but none of that tells you about the intra-file semantics.
<JordanBrown>
The echo pseudo-function is just an easy way to see when expressions are evaluated.
<JordanBrown>
The assert pseudo-function acts similarly.
<JordanBrown>
But even without them, you can use rands() or a stopwatch to figure it out.
<JordanBrown>
If we're going to operate on the basis of exactly what the words say, then top-level assignments shouldn't be executed.
<JordanBrown>
If we're not going to operate on that basis, then the question is more "what makes sense?". And, unfortunately, "what legacy do we need to deal with?".
<JordanBrown>
One of the reasons that I would kind of like to figure out how do to an import("foo.scad") function, that returns an object with references to the contents of the file, is that we could introduce an entirely new semantic that was thought through.
L29Ah has joined #openscad
<InPhase>
JordanBrown: I'd like to remind that this entire ongoing 3 year discussion, originated in the 14 hours between these two posts, going from "When it is a $variable it has dynamic scope visible in the children of that module and the modules it calls. Surely that should override file scope definition in used modules as well?" to "I found more recently that the file scope of the using module is passed to
<InPhase>
the used module but doesn't override a definition there. So I use this in my global include" and ignoring 2 days later "That's indeed a bit odd. I wonder if there is some lookup bug which prefers a file-scoped variable to a dynamically scoped one. Needs some careful investigation." and then continuing to use this in nopscadlib, the only library that anyone who has found that made use of this bug.
<InPhase>
Furthermore, fixing that library to work the same for external projects constituted about an hour worth of work. And then the problem has no remaining impact on the world. Except we continue to treat it like some massive regression issue.
<InPhase>
JordanBrown: There were a lot of really amped up emotions on the github issues on this topic, and it resulted in a lot of things said that were as best as I can tell, factually false about the broader implications.
<InPhase>
JordanBrown: It's a colossal waste of a lot of very smart people's time to spend so much effort on what was a willful use of a declared bug, and which was actually quite fixable, and was fixed.
<JordanBrown>
I was under the impression that he *didn't* have a good fix. And note that #5075 is another person running into it, though that person worked around the breakage before even reporting it.
<InPhase>
The only thing remaining as I see it is to fix the performance issue with use<> processing. The definition of lexical variables depending on dynamic variables in this situation is not formally defined in any documentation nor historical usage, and relying on that would be a little wonky in the first place. I imagine even fewer situations rest on this than on the original bug, which was one library.
<InPhase>
So the fact that this is undefined is probably inconsequential. Perhaps a definition could be specified in the future after fixing the performance issue.
<JordanBrown>
I am not sure, but I got the impression that that one library has cases of lexical variables depending on dynamic variables.
<InPhase>
The performance issue with use<>, now that has severely impacted BOSL2, and numerous other libraries.
<JordanBrown>
My annoyance at the moment is that we seem to have broken an application, for no practical gain. I would be a lot more sympathetic if we'd gotten rid of *evaluating* those assignments, so that at least there would be a practical gain.
<InPhase>
Well I started removing that, but I got busy. And I don't exactly have time to do it right now. But it did not appear to be THAT difficult to do.
<JordanBrown>
I should perhaps note that I've spent the last 30 years steeped in a work environment where almost the #1 rule is "don't break existing applications".
<InPhase>
I think the only reason no one has worked on it is because of all that melodrama on the related issues.
<JordanBrown>
We do break applications on occasion, but if it's knowing breakage we try to supply significant advance notice.
<InPhase>
JordanBrown: In this case, it was declared a bug like 2 days after it was discovered, and then fixed 4 years later. :-P
<JordanBrown>
If you let a bug leak into a release, you're at risk.
L29Ah has quit [Ping timeout: 268 seconds]
<JordanBrown>
I'd say that the questions should be along the lines of (a) is there a compelling reason for the breaking change? (b) does the documentation make it clear that the broken behavior is wrong? (c) Is there a way to address the problem without breakage? (d) Is there a reasonable workaround for users affected by the breakage?
cart_ has joined #openscad
smeefonater has quit [Quit: (╯°□°）╯︵ ┻━━┻]
Smeef has joined #openscad
<InPhase>
JordanBrown: I consider the answers yes, yes, no, yes.
guso78k has joined #openscad
guso78k has quit [Quit: Client closed]
Guest44 has joined #openscad
Guest44 has quit [Client Quit]
J24k has joined #openscad
mmu_man has joined #openscad
<JordanBrown>
I'd say that absent fixing the "shouldn't re-evaluate" bug, the answer to the first is "no".
<JordanBrown>
"there's no benefit today, but we might some day make it better" is not compelling.
guso78k has joined #openscad
<guso78k>
InPhase, it appears to me, that its not only a matter of winding order, but rather unsymmetrical use of the axes.
<guso78k>
In my example X,Y,Z works, whereas Y,Z,X, which has exact same winding order, does not.
<guso78k>
[points_xz[i].x, points_yz[i].y, points_xz[i].z], points_yz[i]] believe this line is the culprit. In a working solution, i feel its forbidden to exact single x,y,z coordinates but I was not yet able to assemble the proper solution
hyvoid has quit [Quit: rebewt]
J24k has quit [Quit: Client closed]
J24k has joined #openscad
J24k has quit [Quit: Client closed]
J24k has joined #openscad
<JordanBrown>
guso78k I haven't been following the details, but I suspect that to be able to generate this figure in any orientation you'd need to change that to pluck out the appropriate coords for the current orientation.
<JordanBrown>
If you want it to be non-axis-aligned, I suspect it's much harder.
<guso78k>
issue is that i might get any 3 orientations. how can i classify them into one of the "known" sets ?
<guso78k>
everythign is linear here i doubt that introducing switch() statement is the right way
<guso78k>
so i have to orient the thing right onto the xy plane , do the bezier curve and put it back ?
<guso78k>
have done this before when creating paper models ...
guso78k has quit [Ping timeout: 250 seconds]
Guest55 has joined #openscad
<Guest55>
yo
Guest55 has quit [Quit: Client closed]
snaked has joined #openscad
cart_ has quit [Ping timeout: 252 seconds]
* teepee
agrees with the judgement by InPhase
<InPhase>
JordanBrown: The most compelling reason I think is basic consistency of the variable scoping definitions, so that we are working with a teachable language and a data flow that is local and makes sense.
<JordanBrown>
I'd say that it would be a whole lot more compelling if it came with not re-evaluating file-scope variables.
<JordanBrown>
On a different topic, it would be good to close out PR#4833, one way or another.
<JordanBrown>
Either accept it, reject it, or specify changes desired.
<JordanBrown>
I don't have any emotional attachment to it one way or another. I wrote it so that we could move that conversation from being hypothetical to being something that could get a clear thumbs-up or thumbs-down.
<JordanBrown>
That's the bitwise-operator / hex constant PR.
<InPhase>
JordanBrown: I mark the removal of re-evaluation as low-hanging fruit that, like, could be a small portion of a GSoC or something. I'd be shocked if it took more than 8 hours of work. All that's important to me is that it be possible to make this optimization. :) The language clarity though, that's a big thing with long ranging benefits.
teepee_ has joined #openscad
teepee has quit [Ping timeout: 260 seconds]
teepee_ is now known as teepee
teepee has quit [Remote host closed the connection]