Show/find dead/bogus connections

[rickmcgeer]

I just spent several hours trying to run down a null-pointer bug, imagining that the central issue was that a widget's state was being queried before it was instantiated. It turned out that the problem was that setting the widget's state was causing a connection to fire, and that was invoking a method on another instance of the component (one that hadn't been instantiated) and as a result the state of a non-instantiated widget was being queried.
There are probably best practices which can deal with this, which don't need to be enforced, but tooling to help a programmer track down connections would be appreciated.

[merryman]

It is not only that, we have yet to come up with tooling in general which allow us to monitor/inspect the resulting object graph. There are a couple rudimentary tools but as of now the following issues persist: We can not reliably collaborate asynchronously in teams because of object graphs. Also the object graph itself easily overwhelms the programmer as soon as the app grows to a certain extent. I dont know if best practices are a good idea if the underlying system constantly generates the issues.

I am currently working on a new idea that may resolve the issue above. Will post more on that in the coming months.

[linusha]

@merryman I do not know whether you have some form of roadmap in another form, but, regardless of solving underlying issues that cause problems such as the described one in the original post, I still think additional tooling for connections would be a good idea.

I would still need to think about how that should look like, but in any case connections are a very powerful tool but imo are always hard to keep track of. Something like a connection-view, i.e. some kind of diagram generated from code containing connections could be interesting. I think there is also still code for a "connection profiler", but I could not figure out how to use it when I stumbled across it. Might be a bit dated.

Long story short - could you maybe jot this down on a list or we reopen this until we have tooling for roadmaps, etc. set up?

[rickmcgeer]

Maybe this will help your considerations, @merryman. Historically, REAL languages like lively ***@***.***: REAL is the acronym I've been selling as the successor to REPL, since we do much more than print now; and I like REAL) can't do large programs. That's why these complex toolchains are popular; they're needed for large-scale system building. I think the mistake the REAL community (Lisp, APL, Smalltalk, Prolog, Self, Squeak, Scratch) has made in the past has trying to add the support needed to build big systems; IOW, either try to get away without the complex toolchain OR try to replicate it in the REAL language. Alan always complained that we had to drop into the system implementation layer at some point (and he was complaining about dropping from eToys into Smalltalk!). But I don't think we have to be all things to all people. *Almost all programs are small!* If we make it really easy for people to do useful things in < 1000 lines of code, but everything gets complex and hairy beyond that, that's a win I'll take any day. So my point is, don't worry about solutions that are great for small programs that won't scale. *No REAL language or system has ever scaled, and I don't think we'll be the very first*. And I don't think we should try. We've built a wonderful Swiss Army Knife. It doesn't need to be a welding-gun too. Just my $.02

…

On Sun, Nov 21, 2021 at 6:44 AM linusha ***@***.***> wrote: @merryman <https://github.com/merryman> I do not know whether you have some form of roadmap in another form, but, regardless of solving underlying issues that cause problems such as the described one in the original post, I still think additional tooling for connections would be a good idea. I would still need to think about how that should look like, but in any case connections are a very powerful tool but imo are always hard to keep track of. Something like a connection-view, i.e. some kind of diagram generated from code containing connections could be interesting. I think there is also still code for a "connection profiler", but I could not figure out how to use it when I stumbled across it. Might be a bit dated. Long story short - could you maybe jot this down on a list or we reopen this until we have tooling for roadmaps, etc. set up? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFAHAYZ2WJWEJ3AZRZ2Q53UNEATVANCNFSM5IOWWHSA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- Rick McGeer ***@***.*** +15103346004