00:55 <gbruno> [github] t-paul pushed 1 additions 6 modifications (Add JSON import.). https://github.com/openscad/openscad/commit/461cf2a5a41a51e153814c1d2aab59e3587ce336

07:35 <gbruno> [github] martinbudden opened issue #3892 (Compatibility management). https://github.com/openscad/openscad/issues/3892

17:27 <InPhase> Well. I suppose I got nophead's issue from "broken" and "impossible" into "ugly" and "I don't like it". I can't satisfy everyone's aesthetics, but I will consider that solved from a technical and engineering perspective.

17:33 <InPhase> I happen to think the recommended solutions are much more aesthetically pleasing. I suppose a lot of that has to do with all the alarm bells I have going off whenever semantic dependencies are neither explicit nor localized.

17:48 <teepee> Yes, that's a massive achievement. Still a bit worrying that the preference is "it looks strange" vs. it's a bad bug in some scenarios but maybe we can have some improvements in the future for that - not helping for the current situation though

17:55 <InPhase> I think in terms of more ways to specify defaults, options we talked about that seem useful to me include the structured binding, object literals, and some variants of module literals that we talked about.

17:57 <InPhase> While in that discussion it occurred to me that there's, awkwardly, no good way to set a common context for functions and modules with a single call.

17:57 <teepee> yeah, Doug even tried to include the default overwrite into the object literals

17:57 <InPhase> Since functions can't call modules, and modules can't call functions, of course. And there's no way to sort of... source a context, like one would with bash.

17:58 <gbruno> [github] martinbudden closed issue #3892 (Compatibility management). https://github.com/openscad/openscad/issues/3892

17:59 <teepee> what do you mean with common context?

17:59 <teepee> as in global variables?

18:00 <InPhase> My thoughts are a little complex. I'll type a fake example.

18:03 <InPhase> https://bpa.st/O75A

18:04 <InPhase> I'm not proposing that "source " syntax, but as a bash-stolen placeholder for my thoughts.

18:05 <teepee> that sounds pretty much like https://github.com/doug-moen/openscad2/blob/master/rfc/Objects.md#customization

18:05 <teepee> with the SetDefaults being the unchanged literal

18:08 <InPhase> First I'll note I never liked the file-based nature of that proposal. But to this question, it differs because you can't set the built-ins like $fa and $fs in one call without a system to bring values back a level.

18:09 <InPhase> Although I realize it's a bit convoluted, and peepsalot is probably going to raise an eyebrow about non-computability. :)

18:09 <teepee> :)

18:09 <InPhase> So I don't have a sense for how to do it yet. I'm just noting there's an opportunity for some method which is explicit, local, and also works identically between functions and modules.

18:10 <teepee> being able to compute values would be nice

18:11 <teepee> I guess the current hack is using include<> but that's not really a good solution

18:11 <InPhase> Well the importance of a more flexible approach is it doesn't need to be file level. You can cherry pick defaults deeper in the hierarchy of calls.

18:13 <teepee> I don't think the object literals as proposed are obvious enough, but I'm relatively sure it's not tield to file level

18:13 <teepee> it's more the other way around. there's object literals that are inline and it's possible to get the same variable value by importing as script from a separate file

18:14 <InPhase> Oh. Well, I guess that's okay then.

18:15 <InPhase> Maybe that combined with structured binding would solve this cleanly enough.

18:16 <InPhase> Then you explicitly declare what you're ripping from the object literal.

18:16 <teepee> but what it can't do I think is directly assigning $variables as it's always a new object with a new scope

18:16 <InPhase> Or... I'm actually not sure how to do that with structured binding. But, something binding like that means "rip these variables from the literal."

18:17 <teepee> ah, right, that would be able to extract the values from inside the object and store in the current scope

18:17 <InPhase> [$fa, $fs, bunny_count] = from(DefaultBonnyObj);

18:17 <InPhase> Or some similar magic.

18:19 <InPhase> That keeps debugging straightforward. You know where to look for the values obtained. Also you don't have collisions between identically named variables, so you don't get a dependency clash.

21:49 <teepee> interesting... https://twitter.com/adrianbowyer/status/1439583095984902144

22:32 <dTal> interesting and highly dubious

22:35 <teepee> yeah, maybe. there's been earlier efforts but that did not produce anything other than some promising youtube videos

22:36 <teepee> I'm not sure it will be possible to produce results good enough to base additional work on - which is at least in my mind the whole benefit of something like that

23:44 <InPhase> The old polyhedron call generator is pretty easy to write. I could probably make a full-featured one in under an hour. The meat of a useful one is compositional shape recognition.

23:47 <InPhase> I've convinced myself that doing the composition shape recognition satisfactorially requires some decent AI.

23:57 <teepee> it's not just that. to make it useful when the output is OpenSCAD, it needs to be at least reasonably editable, otherwise there's not really any benefit compared to just using import("STL")

23:58 <teepee> I can imagine it a bit easier for GUI CAD where it could provide some base shape that is then manually updated (e.g. fix size of holes, add chamfers, ...)