JordanBrown has quit [Read error: Connection reset by peer]
JordanBrown has joined #openscad
<JordanBrown>
I had blissfully forgotten #3781, the behavior of top-level $ variables in "use" files.
JordanBrown_ has joined #openscad
JordanBrown_ has quit [Client Quit]
JordanBrown_ has joined #openscad
<teepee>
yes the 2 issues I have in mind is that one and the reevaluation one - the last one not *that* critical but would be a nice speed update along with Manifold
<JordanBrown>
which "reevaluation" one?
fling has quit [Remote host closed the connection]
fling has joined #openscad
<teepee>
there's probably an issue on github too, I'll try to find later
<JordanBrown>
OK.
<teepee>
it's about things getting re-evaluated when crossing file boundaries IIRC
<JordanBrown>
Sounds closely related to #3761.
<teepee>
I'm on my way back home in a couple of minutes so afk for a while
<JordanBrown>
ok
<oldlaptop>
InPhase: AIUI enough that it took over drh's whole business some time ago
<JordanBrown_>
teepee did you ever really understand Nophead's desired scoping rules for top-level $ variables in use-d files?
<JordanBrown_>
actually I should say scoping and evaluation, since I think both were relevant.
<teepee>
well, "don't change anything" pretty much
<teepee>
which is a no-go in my view, but I gave up trying to discuss as there was nothing going forward, InPhase even submitted patches to solve the specific issues but those were rejected
<teepee>
I see 2 options at this point
<teepee>
1) document behavior and that's it
<teepee>
2) find a way of flagging old-style files so they can work with the broken behavior
<teepee>
I'd like 1) but 2) is probably the better choice
<JordanBrown>
Without having dug into the details, it seemed like that change was intended to at least partially address the recomputation issue from #782.
<JordanBrown>
Another idea that is tantalizingly close to practical is to build something atop #4478's objects.
<teepee>
well, I just added a couple of "Prio" labels :)
<JordanBrown>
The idea would be that you would import a file, and the whole file - all variables, function, and modules - would appear as members of that object.
<teepee>
so I suppose one of the next steps is going through issues and looking what should be assigned to the release and what prio
<teepee>
yes, that would likely solve a huge amount of namespace issues, maybe even all of them
<JordanBrown>
Do you mean of the not-yet-done stuff, going back to the existing changes and pulling some out, or going back to the existing changes and marking some as experimental?
<teepee>
I would start with issues only first, code discussion comes next
<JordanBrown>
Also, as a new mechanism, it can have new evaluation semantics. It might be more practical to restore the old $ semantics, and say that new software should use this new mechanism.
<teepee>
but I don't the anything that should get new experimental flags
<teepee>
no, the old semantics make no sense
<JordanBrown>
Yeah, but being stuck with legacy is being stuck with legacy.
<teepee>
they introduce a random scope of "crossing into a new file"
<JordanBrown>
If there's a new mechanism that just works better and avoids the problem, it's not awful to leave old legacy that doesn't behave well.
<teepee>
yes, we may need to keep the legacy, but for new stuff I don't think we want to keep it
<JordanBrown>
the idea would be that you would say something like "bosl2 = import("BOSL2.scad")"
<JordanBrown>
and then "bosl2.some_bosl2_module(args)".
<teepee>
yes
<JordanBrown>
Makes the file name be almost the only namespace issue.
<JordanBrown>
I say almost because $ variables passed into the library might be a namespace issue.
<JordanBrown>
e.g. more than one library might define a $trace variable.
<JordanBrown>
That mechanism was one of the reasons that I was interested in the "hybrid" object model, where the definition of an object looked like an OpenSCAD program instead of having its own sub-language.
<JordanBrown>
That would fit well with the notion of sucking up a more-or-less-standard OpenSCAD file and importing it as an object.
<JordanBrown>
But at this point I think that the problems with that model - in particular, being unclear how you would do computed keys and no obvious way to do object comprehensions -
<JordanBrown>
outweigh its benefits.
<JordanBrown>
But then with the "independent" model, where dictionary-like objects and geometry objects are two entirely separate things,
<JordanBrown>
it is not clear how you would fold in the "import a file" concept.
<JordanBrown>
Maybe there would be a magic-named variable, e.g. "export", and the value of that one variable would be the value returned by the import() function.
<JordanBrown>
So the library would say "export = { someconst: 5, somemodule: module (args) { body } };"
<JordanBrown>
or the equivalent using intermediate variables.
<JordanBrown>
I don't like the magic-name scheme, but it would work.
<JordanBrown>
Would still have to figure out how top-level $ variables would fit in. Which might be "they don't".
<teepee>
yes, I'm sure they don't
<teepee>
they start in the dynamic execution context, not the static code file
<JordanBrown>
Yeah, but the "static" code file is only sort of static. It (and in particular its assignments) get executed once, at import time.
<JordanBrown>
and maybe that's the answer, that top-level $ variable assignments are evaluated once, at import time. Which makes them not very useful.
<JordanBrown>
I'd be interested in working on that concept, but I don't want to invest energy in it until we have the stuff in #4478 reasonably settled.
<teepee>
file based they still don't make sense as they would not be overwritable from outside
<teepee>
$x = 3; i = import("file.scad");
<JordanBrown>
That value of $x would be visible during the evaluation of the top level of file.scad.
<JordanBrown>
so for instance, file.scad might say "export = { value = $x };"
<JordanBrown>
and then i = import("file.scad"); echo(e.value); would yield 3.
<teepee>
yes, but the expectation of the file level is very likely to be a default
<teepee>
and that's not working
<JordanBrown>
indeed.
<JordanBrown>
Would have to figure out an idiom for having the file supply defaults.
<JordanBrown>
but that might be as simple as if_undef($foo) ? default_foo : $foo.
<JordanBrown>
I do wish that I was happier with the Python integration, because then I would just abandon all of this language design in favor of the mature language.
<JordanBrown>
But the security thing still bugs me, and the fact that the minimum program is more complicated than "cube();" bugs me.
<teepee>
as far as I understand that might be coming for python too
<teepee>
well, without the ; of course :D
<JordanBrown>
Hmm. I'm not sure how. But maybe.
<JordanBrown>
The trick, I think, is that "cube()" should add to the model (or to the current subassembly), but "x = cube()" should not.
<JordanBrown>
While language design is fun, it's also usually an exercise in reinventing wheels, poorly.
lastrodamo has quit [Quit: Leaving]
<JordanBrown>
Changing gears for a moment, what do you know about the Matrix integration no longer working?
<teepee>
they disconnected the bridge but I did not understand the details as the old style connection is not supposed to be back but something might
<JordanBrown>
Do you have any references or contact points?
<teepee>
there was a blog post, let me see if I can find that again
<JordanBrown>
Oh, and back on the Python thing for a moment... I do not mean to disparage the Python integration work that's been done. Those two concerns are pretty intrinsic to how Python works.
<teepee>
iI have no idea if that portal vs. plumbing is somehow still possible, it's all a bit fuzzy to me
<teepee>
I only found that after some sort of deadline, so the initial "you have to do that..." did not work anymore
<JordanBrown>
(reading)
<JordanBrown>
So they're saying that there's still a way to connect the two (via "plumbing") and they they're going to put together a guide... but at least as of that post, they didn't have that guide or give any hints.
<teepee>
so now we are somehow floating without a clear status
<JordanBrown>
I'm not sure, but I think it's saying that you have to do this before July 31 *to maintain uninterrupted service*.
<JordanBrown>
I don't think it's saying that the procedure described won't work after July 31st.
<JordanBrown>
Random tidbit: there seems to be a bridge from Freenode's #openscad to Matrix.
<JordanBrown>
Are you a channel operator on libera.chat:#openscad?
<teepee>
no
<teepee>
wait, you mean IRC? yes
<teepee>
but not the matrix channel
<JordanBrown>
Yes, that's what I was asking.
<teepee>
that's owned by the appservice I think, so I'm not sure there's an actual human as owner right now
<JordanBrown>
Hmm. #openscad:matrix.org is apparently an alias for #freenode_#channelname:openscad.
<JordanBrown>
That's kind of unfortunate.
<teepee>
I wonder if there's some way to contact matrix.org about that, I have not looked yet
<teepee>
like if there's a way of getting actual ownership of that room
<JordanBrown>
Well, hmm. I created a new #openscad_libera and tried to follow the instructions for setting up plumbing, but there's no "IRC Bridge (libera.chat)" choice in the list of extensions.
<JordanBrown>
There are a couple of other IRC bridges, but not that one.
<JordanBrown>
I'm asking in one of the Matrix rooms.
JordanBrown has left #openscad [Leaving]
JordanBrown_ has left #openscad [#openscad]
JordanBrown_ has joined #openscad
JordanBrown_ has left #openscad [#openscad]
JordanBrown_ has joined #openscad
<JordanBrown_>
And asking in Libera's Matrix-coordination room too.