Geth Terminal-Widgets/main: 0ca143f026 | (Geoffrey Broadwell)++ | docs/concurrency-model.md
First two sections of new concurrency-model doc
05:16
japhb Starting work on explaining the concurrency model of T-W and its dependency stack ^^ 05:17
Geth Terminal-Widgets/main: a4c9cec38f | (Geoffrey Broadwell)++ | docs/concurrency-model.md
Add note about safe reuse of Cell objects
05:28
11:17 librasteve_ joined 14:06 librasteve_ left
patrickb Fun fact: I've been pretty ignorant about concurrency issues in the debugger until recently. Now it's deadlocking and racing all over the place. :-P 14:57
I do believe to have gained an idea on how the design is flawed and an idea on how to fix it. 14:58
We'll see how it goes.
[Coke] good luck. :) 15:04
patrickb It slowly starts to look like an actual debugger. Here's a quick recording: asciinema.org/a/cGSTbOTPj0dY0xKS 15:09
15:18 librasteve_ joined
nemokosch very curious about this debugger, it would be invaluable to have some tools to introspect runtime behavior 16:04
[Coke] I assume no audio on that clip 16:29
japhb wonders why there are line height gaps in the asciinema recording 17:37
patrickb you mean little spaces between the horizontal and vertical divider chars? 18:31
japhb The vertical ones, yeah. Properly set line height for monospace art leaves no gaps. (And in fact modern terminal emulators don't even leave it up to often-broken fonts -- they generate the box drawing characters internally with exactly the right size.) 20:57
I would assume the asciinema folks are well aware of this, so I'm honestly curious what is going wrong here. In-browser terminal emulator wonkiness? 20:58
librasteve Coincidentally I have been toying with asciinema for simple terminal session demos (ie to showcase App::Crag). The only suggestion I have is to look at the .cart source as it is pretty clear what is going on… 21:35