| 19 Feb 2026 | |||
| patrickb | For that purpose the View class has a few methods, to give a few examples: `refresh-threads-view`, `refresh-source`, `refresh-frames`, ... | 07:38 | |
| To guarantee no race between these update methods and View events, I plan to not call these update methods directly anymore, but have them perform a roundtrip through the event reactor via the newly added interface. | 07:40 | ||
| So far so good. | |||
| Implementing the Locals view via Viewer::Tree now requires me to divert from the above pattern. The Terminal::Widgets::Volatile::Tree::Parent.children() method needs to directly return it's children. So this method needs to call a method on the Controller *and await the returned Promise*. | 07:43 | ||
| This couples the T-W reactor loop to the Controller mutual exclusion which can potentially cause a deadlock should some other event currently have the Controller lock and wait to enter the Views event reactor. | 07:46 | ||
| Rephrased: There is a Controller and a Viewer lock. Up until now locking always locked the Controller first, then the View. The places where the View needed to call the Controller (and thus reversing the lock order) are resolved by the Controller being an Actor, i.e. all methods insta-returning Promises. | 07:49 | ||
| The TWVTP.c() now introduces a lock reversal. It's called from within T-W (thus holding the T-W event reactor lock) and then needs to call a Controller method *and await it's promise* (thus acquires the Controller lock). | 07:51 | ||
| Is there an easy way out? | 07:52 | ||
| Is this solvable at all? | 07:53 | ||
| Would somehow changing the TWVTP.c() possibly help? | |||
| japhb | patrickb: Saw this, but way too tired to figure it out tonight. Will take a look once tomorrow's caffeine intake is sufficient. | 09:28 | |
| patrickb | I start to suspect, it'll be necessary to allow TWVTP.c() to return a Promise. When a promise is returned, the tree is put into a stable temporary state (e.g. by adding a temporary `... loading ...` line below the to be opened parent) and refreshing continues. The promise is `.then`ed on the T-W event reactor. Once the promise succeeds, the tree view first checks if the update is still applicable | ||
| (the parent still exists and is to be expanded) and then updates. | |||
| Oh wow I didn't expect a reply in the next 8 hours or so... | |||
| Sleep well! | |||
| japhb | Just wanted to make sure you knew I was paying attention, even if I couldn't respond cogently yet. | 09:29 | |
| Thanks, see you on the flip side! | |||
| patrickb | o/ | ||
| It seems TWVT::Node.long-name() is unused. Did it get superceded by TWVT::Parent.id()? | 11:09 | ||
| 21 Feb 2026 | |||
| japhb | Ooofta. Back from a couple days away. | 04:48 | |
| So, last question first: | 04:49 | ||
| long-name was intended to be a *user-readable* name that could e.g. appear in detail text or some such. Also useful when for example a user is 6 levels deep in a dir tree and then goes "Wait, *which* config/ dir was this?" | 04:50 | ||
| It applies to *any* node. | 04:51 | ||
| Er, any Node | |||
| Parent.id was meant to be an opaque, unique, and unchanging identifier for a particular node. It just so happens that in some cases, a unique long-name happens to be usable as a unique ID as well. | 04:52 | ||
| So you can think of .short-name fulfilling a similar role to .gist in Raku, .long-name for .raku, and .id for .WHICH. | 04:53 | ||
| Previous issue: the locking inversion from TWVTP.c() ... | 04:57 | ||
| The intent of Volatile::* was to represent data structures that might get modified at any time by some other thread, or even some other process (this is the case with DirTree, for instance). It is also assumed that getting the current state might be slow (such as disk accesses, database queries, network lookups, etc.) | 04:59 | ||
| I had on my local todo to allow indicating a user-wait state for this. | |||
| For example, clicking on a DirTree node to expand it might show an hourglass where the expanded/collapsed arrow normally is, until the new entries actually appear and are visible, at which time the icon switches to an expanded arrow. | 05:01 | ||
| It is reasonable to me to implement this in terms of a promise/then, supply/act, or channel/receive model, though we might need to be clever about whether and how the reactor and event model got included in this. | 05:04 | ||
| Do you have a local diff that | |||
| 's doing what you want already? | |||
| patrickb: ^^ | |||
| Geth | Terminal-Widgets/main: 2e8e9ab96a | (Geoffrey Broadwell)++ | docs/getting-started.md Add Drawing Sequence section to getting-started doc |
05:56 | |
| patrickb | I don't have a patch for the Volatile::Parent.children() that returns a promise. Currently I just hold back on putting all my outside UI state modifications on the T-W reactor. This helps avoid the deadlock, but is obviously racy. | 06:23 | |
| Thanks for the long-name explanation. I might actually use this then. (I do have a "Details" frame showing details for the currently selected symbol.) | 06:26 | ||
| The user-wait state would fit my bill perfectly. I do have a "longish" running operation. (It's a few network requests.) One more thing to consider: The operation can possibly error. So when not getting a result it's be nice to somehow signal an error condition. (Maybe replacing the hourglass with an error marker?) | 06:31 | ||
| japhb | Oh that's an excellent idea | 06:43 | |
| Makes me wonder if DisplayNodes need a .state attribute, and whether expanded/collapsed should be part of that or separate. If part of it, we could have: Collapsed, Pending, Error, Expanded. But maybe we want to be able to poll every so often for updates, and have some way to indicate that the poll failed to get updates. So then we have expanded/collapsed orthogonal to | 06:52 | ||
| unknown/pending/error/out-of-date/current or what have you. | |||
| If anyone has any ideas or use cases that should be handled, I'm all ears. (all eyes?) | 06:54 | ||
| patrickb | I do have the case of an updated state in the debugger. When e.g. stepping, the variable's content can change and new variables can ente | 07:17 | |
| appear. | |||
| I planed to do this by diffing previous and new state and then rebuilding the tree from scratch. (Restoring selected item and topmost visible item.) Changed /new items are highlighted. | 07:19 | ||
| Speaking of such, is it currently possible to retrieve and set the topmost visible item? | 07:20 | ||
| The updated thing doesn't happen via polling, is triggered by an external event. (A step completes or a breakpoint hits, ...) | 07:24 | ||
| So at least for my usecase, combining expanded / collapsed and pending/error would work out. | 07:27 | ||
| 22 Feb 2026 | |||
| Geth | Terminal-Widgets/main: 7d9a0f9522 | (Geoffrey Broadwell)++ | docs/getting-started.md Minor getting-started doc copy editing |
05:02 | |