|
00:07
ShimmerFairy left
00:36
ShimmerFairy joined
05:24
ShimmerFairy left,
ShimmerFairy joined
06:24
hurufu joined
07:16
[TuxCM] left
07:20
[Tux] joined
08:29
finanalyst left
08:35
finanalyst joined
08:36
hurufu left,
hurufu joined
08:56
sivoais left
08:57
sivoais joined
09:29
donaldh joined
09:47
finanalyst left
09:49
sergot joined
|
|||
| lizmat | notable6: weekly | 10:43 | |
| notable6 | lizmat, 9 notes: gist.github.com/7068c966fd23d468d5...c61c075098 | ||
| lizmat | notable6: weekly reset | 10:55 | |
| notable6 | lizmat, Moved existing notes to “weekly_2026-07-27T10:55:04Z” | ||
| lizmat | And another Rakudo Weekl;y hits the Net: rakudoweekly.blog/2026/07/27/2026-...thank-you/ | 12:55 | |
| [Coke] | lizmat++ lizmat++ lizmat++ | 12:56 | |
| One nice feature that wasn’t really mentioned in the Rakudo 2026.07 announcement, were the general GDB plugin improvements for low-level (core) debugging, contributed by Timo Paulssen. Exciting stuff! | 12:58 | ||
| ... oops | |||
| lizmat | yeah, shit happens... it was a last minute addition :-) | ||
| [Coke] | Reading this - it was because we didn't do a separate bump so the commit showed up in rakudo *before* I started the release. | ||
| Sorry. Was not intentional, timo. | 12:59 | ||
| (and I remember saying "don't do a bump or revert" because I was still thinking about it a few days pre. | |||
| timo | I really should have waited until after the release to merge that. i'm not sure in retrospect why i thought it would be NBD | 13:12 | |
|
13:17
hurufu left
20:08
finanalyst joined
21:08
nine left
21:33
finanalyst left
|
|||
| japhb | ... because hope springs eternal? :-) | 22:10 | |
| timo | my foolishness is boundless | 22:14 | |
| japhb | My cat's foolishness does a lot of bounding | 22:23 | |
| timo | yo japhb what would you have me put into the "omniscient debugger" parts of moar rrdb? | 22:28 | |
| Voldenet | yay new weekly | 22:33 | |
| japhb | timo: Hmmm, good question. Maybe some way to track the movement of data through the moar-level pieces of Supplies and Channels? I would think each would be interesting for different reasons: Supplies turning into a tree traversal, Channels involving task switches, and both involving the scheduler. | 22:37 | |
| Part of the problem is (Supplies and Channels) feeding (Supplies and Channels). | 22:38 | ||
| If I'm tracing something backwards I'd like to follow it backwards through a Channel or Supply to where it was created, follow back whatever middleware computation is happening, and then back into the next Channel or Supply in the link. | 22:39 | ||
| With the problem that it's not entirely obvious what to do about the fact that running a Supply in reverse turns a 1:N traversal into an N:1 merge. | 22:40 | ||
| timo | right, yeah stuff for debugging async data flows and control flows is super interesting | 22:43 | |
| the "put object into ConcBlockingQueue" and "get object out of CBQ" functions are good candidates for breakpointing when going forwards through time to track what happens to an object | 22:46 | ||
| do you happen to have some little program that shoves values around through a few supplies and/or channels or something? | 23:08 | ||
| Voldenet | not sure if related, but my approach to debugging supplies is to alter add-whenever so that I can see what transforms the block is performing glot.io/snippets/hjzcs17o93 | 23:21 | |
| maybe some sort of value processing graph could be constructed by holding gigantic hash inside global variable | 23:22 | ||
| or dynamic variable so it could be on-demand | 23:23 | ||
|
23:23
sjn left
|
|||
| timo | i think i saw that, it's pretty cool | 23:23 | |
| unfortunately it requires you to already have added the debug stuff before you are looking for something | |||
| Voldenet | indeed, it's good if you can reproduce the problem somehow | 23:24 | |
| japhb | timo: Cro is crazy Supply-heavy. That would be my starting point. | 23:25 | |
| timo | makes sense | ||
| japhb | (And has the advantage that it's already got examples and tests and a lot of community usage, so you can do some "real world but contained" sort of experimentation) | 23:26 | |
| timo | I randomly chose to use a call to `zef install` and uhhh i'm stuck in a forest of parse-string, parse-thing, parse-string-slow, unjsonify-string, parse-array, ... | 23:31 | |
|
23:33
sjn joined
|
|||
| japhb | Oh dear. | 23:35 | |
| "You are in a maze of twisty passageways, all alike." | |||
| timo | i really need a "seek where this frame was entered" :D | ||
| japhb | Oh yeah, that's definitely a good idea | 23:38 | |
| Voldenet | it'd be nice if emit could silently turn supplies or channels tree into stack by passing block locations with past values (also including blocks) | ||
| so that 'emit' or 'send' could behave like method call | |||
| timo | aha, the "env" of a frame is maybe a good field to watch to get close to a frame's creation ... frames are a little special since the frames themselves can live on a stack region instead of being allocated on the heap, and on the stack (not the machine stack), things get overwritten easily when stuff moves around | 23:43 | |
| Voldenet | it is a thing that annoys me a bit in debugging .net's async as well - usual stack trace is completely useless | 23:46 | |
| it's possible to cheat by passing some sort of dynvar, debuggers are also able to do this | 23:47 | ||
| but there's nothing built-in like Environment.LogicalStackTrace | 23:48 | ||
| timo | > # 0 0x49c081f08a0 send args=(P6opaque#Channel.new(0x49bfc665258), P6opaque#Rakudo::Internals::HyperWorkBatch.new(0x49c08110f40)) SETTING::src/core.c/Channel.rakumod:43 | 23:52 | |
| well, this could be an interesting spot to start looking maybe | |||
| Voldenet | also, dotnet debuggers have this thing called parallel stack traces, that show you all the "async" running processes | 23:54 | |
| i'm just throwing in the ideas others had though, I've never used it | 23:55 | ||