[00:06] *** Altai-man_ joined
[00:08] *** sena_kun left
[00:50] *** harrow left
[02:07] *** sena_kun joined
[02:08] *** Altai-man_ left
[04:06] *** Altai-man_ joined
[04:08] *** sena_kun left
[04:22] *** squashable6 left
[04:24] *** squashable6 joined
[06:07] *** sena_kun joined
[06:08] *** Altai-man_ left
[06:29] <nwc10> good *, #moarvm 

[07:32] *** zakharyas joined
[07:40] *** harrow joined
[07:48] *** zakharyas left
[07:52] *** zakharyas joined
[08:06] *** Altai-man_ joined
[08:09] *** sena_kun left
[08:25] *** leont joined
[10:07] *** sena_kun joined
[10:08] *** Altai-man_ left
[11:34] *** zakharyas left
[11:40] *** patrickb joined
[12:06] *** Altai-man_ joined
[12:08] *** sena_kun left
[12:28] <nine> Turns out, MoarVM kinda assumes in some places that we're only serializing once in a program run. E.g. when serializing closures we may encounter outer contexts that are not claimed by any SC and claim them for the current one. But if the same outer context is reference by another compilation, it's already claimed and we fail with "reference to context outside of SC for"

[12:29] <nine> The context in question is Hash::^parameterize's outer, i.e. the Hash class' block, triggered by precompiling two modules that are using parameterized Hashes in the same process.

[12:30] <nine> With the reference to the method coming from the method cache.

[12:51] *** zakharyas joined
[13:04] *** patrickb left
[13:20] <nwc10> does anything use HashAttrStore any more?

[13:26] <jnthn> No, I don't believe so

[13:27] <jnthn> nine: Parameterize is interesting also because 6pe merges them on deserialize...at least, if that's involved here

[13:33] *** MasterDuke left
[13:59] <jnthn> Hm, curious, I'm seeing a load of `MVMArray: atpos expected int register` on my new-disp branch...

[13:59] *** [Coke]_ joined
[13:59] *** [Coke]_ left
[13:59] *** [Coke]_ joined
[14:02] *** [Coke] left
[14:07] *** sena_kun joined
[14:07] <jnthn> bah, my own silly fault, it seems

[14:08] *** Altai-man_ left
[14:08] <nwc10> insufficient coffee?

[14:09] <jnthn> I had quite a bit of that today...

[14:09] <jnthn> Already onto tea

[14:28] *** [Coke]_ is now known as [Coke]

[14:46] *** patrickb joined
[15:25] <Geth_> ¦ MoarVM/new-disp: b58a201743 | (Jonathan Worthington)++ | 32 files

[15:25] <Geth_> ¦ MoarVM/new-disp: Remove spesh plugin mechanism

[15:25] <Geth_> ¦ MoarVM/new-disp: 

[15:25] <Geth_> ¦ MoarVM/new-disp: All usages of it in the Rakudo new-disp branch have now been replaced

[15:25] <Geth_> ¦ MoarVM/new-disp: with usages of the new dispatcher mechanism.

[15:25] <Geth_> ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/b58a201743

[15:40] <Geth_> ¦ MoarVM/new-disp: b079a52e8b | (Jonathan Worthington)++ | 7 files

[15:40] <Geth_> ¦ MoarVM/new-disp: Rename repurposed plugin guard spesh stats

[15:40] <Geth_> ¦ MoarVM/new-disp: 

[15:40] <Geth_> ¦ MoarVM/new-disp: These were used for both spesh plugins and dispatch results for a while,

[15:40] <Geth_> ¦ MoarVM/new-disp: and now are just about dispatch results, so rename them as such.

[15:40] <Geth_> ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/b079a52e8b

[15:53] <jnthn> Well, that's the first victim of new-disp... :)

[15:54] *** MasterDuke joined
[15:54] <jnthn> .oO( My brain was the zeroth... )

[15:55] <timotimo> oof

[15:55] <timotimo> "of all the things i've lost

[15:55] <timotimo> i've missed my brain the most"

[15:57] <[Coke]> ... remove enough of your brain, and that'll even rhyme.

[15:59] <timotimo> your line also almost rhymes

[16:00] <jnthn> .oO( The bridge I've crossed the most... )

[16:02] <jnthn> Turns out the update_ops script manages to segfault on the new-disp branch wish spesh enabled. Guess I'll go debug that...

[16:02] <jnthn> 0x00007ffff74ae180 in mark (tc=0x603d70, from_record=0x49b9928, worklist=0x49fc720, snapshot=0x0) at src/core/callstack.c:479

[16:02] <jnthn> 479	                        add_collectable(tc, worklist, snapshot, f_record->arg_info.source[f_record->arg_info.map[flagi]].o,

[16:02] <jnthn> hmm

[16:06] *** Altai-man_ joined
[16:08] *** sena_kun left
[16:15] *** sena_kun joined
[16:25] <Geth_> ¦ MoarVM/new-disp: fea9b14ddc | (Jonathan Worthington)++ | src/core/callstack.c

[16:25] <Geth_> ¦ MoarVM/new-disp: Use correct callsite field for loop

[16:25] <Geth_> ¦ MoarVM/new-disp: 

[16:25] <Geth_> ¦ MoarVM/new-disp: arg_count is going away as part of the calling convention changes, and

[16:25] <Geth_> ¦ MoarVM/new-disp: so is not even set by the dispatch path.

[16:25] <Geth_> ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/fea9b14ddc

[16:25] <jnthn> Was a silly one :)

[16:29] <timotimo> oops i think that may have been my mistake :D

[16:29] <timotimo> saved you five minutes by implementing it for you, then cost you half an hour to fix it :)

[16:32] <jnthn> ah, I found it quicker than that, was just distracted looking at something else along the way :)

[16:32] <timotimo> phew

[16:44] *** sena_kun left
[17:40] *** zakharyas left
[17:44] *** patrickb left
[18:07] *** sena_kun joined
[18:08] *** Altai-man_ left
[18:25] *** Altai-man_ joined
[18:27] *** sena_kun left
[18:32] *** sena_kun joined
[18:34] *** Altai-man_ left
[19:08] <nwc10> jnthn: ASAN is excited by t/04-nativecall/21-callback-other-thread.t on new-disp

[19:21] *** squashable6 left
[19:22] *** squashable6 joined
[19:27] *** zakharyas joined
[20:32] *** Altai-man_ joined
[20:33] *** zakharyas left
[20:35] *** sena_kun left
[22:33] *** sena_kun joined
[22:34] *** Altai-man_ left
[22:38] <timotimo> i think splitting our flags into "stuff useful for building moarvm on this system" and "stuff useful for building anything on this system" so that modules like LibraryMake and Distributin-Builder-MakeFromJSON can re-use the useful stuff and skip tommath, uv, etc

[23:53] *** lucasb joined