github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:01 MasterDuke left 00:15 sena_kun joined 00:17 Altai-man_ left, sena_kun left, sena_kun joined
timotimo annoyingly, creating dtrace probes at runtime is a bit funky 00:22
there's a bunch of trace points i could imagine could be interesting to have 00:23
around module loading and precompilation for example? 00:26
gist.github.com/timo/498426619ac7d...0f69cd3f71 - does this seem interesting at all? 00:42
(have to run trace with -Z256 to get full paths for all the precomp paths) 00:45
256 isn't enough lol 00:46
but using 512 gets a compilation error for the bpf program, because it has a stack size limit of 512 bytes apparentl
02:14 Altai-man_ joined 02:17 sena_kun left 03:42 Kaiepi left 03:44 Kaiepi joined 03:45 Kaiepi left, Kaiepi joined 04:14 Kaiepi left 04:15 sena_kun joined 04:16 Altai-man_ left 04:18 Kaiepi joined 06:14 Altai-man_ joined 06:17 sena_kun left 06:49 leont joined
nwc10 good *, #moarvm 07:14
when is the next release, and where should I have looked to find that out without asking a human? 07:16
Altai-man_ nwc10, moarvm release or rakudo release? 07:24
nwc10 MoarVM release. 07:25
Altai-man_ Go to moarvm.org/ and it should be pretty straightforward. 07:26
nwc10 actually, I thought that both happened about the same time, and "not breaking Rakudo" tends to be more important :-)
Altai-man_ Another page is github.com/MoarVM/MoarVM/releases
With those you can get them without asking anyone. :)
nwc10 I can't spot any planned date for the next release, and it's not obvious that it's (say) "every month about the 20th" because there are gaps 07:29
Altai-man_ nwc10, there are planned dates for rakudo, see github.com/rakudo/rakudo/blob/mast..._guide.pod but they are floating in general, because things.
So I wouldn't bet my money on next release date, but I can say "It is very likely and we will really try our best to deliver it". 07:30
nwc10 ah "things". Yes, sigh, I seem to know about "things". 07:31
But thanks - make sure things are in a "safe releasable state before 2020-08-22" is a very useful answer
Altai-man_ I mean, people can discover tricky bugs a day before release and we won't ship something broken because release date. 07:32
afk&
s/something broken/something known to be broken/ 07:34
nine releasable6: status 07:37
releasable6 nine, Next release in ā‰ˆ26 days and ā‰ˆ11 hours. There are no known blockers. Changelog for this release was not started yet
nine, Details: gist.github.com/f9dceb16782c6d69f4...9cd3790224
nine nwc10: ^^^
We almost always release them in tandem
07:47 zakharyas joined 08:02 MasterDuke joined 08:15 sena_kun joined 08:16 Altai-man_ left
MasterDuke nwc10: you might find github.com/senderista/hashtable-benchmarks interesting 08:46
Geth MoarVM/new-disp: fda7058dda | (Daniel Green)++ | 2 files
Lego JIT implementation of sp_getlexstatic_o

Manually inline MVM_disp_inline_cache_get_spesh because it's small.		 08:56
MasterDuke uh
that was supposed to be an update to my fork to fix the merge conflict in github.com/MoarVM/MoarVM/pull/1286 08:57
$work for a bit, but i
'll try to undo that after
09:48 Geth_ joined 09:54 Geth_ left
MasterDuke hm. looks like i'd have to rewrite history for everybody to undo that. guess i'll let jnthn decide whether to just leave as is or do a revert commit and merge it in again at some later point 09:55
09:55 raku-bridge left, Geth__ joined
nwc10 MasterDuke: jnthn is on holiday for the next week and a bit 09:56
MasterDuke .tell jnthn i accidentally pushed github.com/MoarVM/MoarVM/commit/fda7058dda when trying to fix a conflict with github.com/MoarVM/MoarVM/pull/1286 in my fork. i don't want to rewrite history for others, so please feel free to revert if you want 09:57
tellable6 MasterDuke, I'll pass your message to jnthn
MasterDuke nwc10: yeah, but i don't think there's any urgency, that was to a branch, not master, so hopefully shouldn't cause any problems until he resumes new-disp work 09:58
nwc10 oh, I missed the "branch" part.
clearly this new coffee isn't quite good enough :-)
MasterDuke apparently mine isn't either. i'm not quite sure how that happened, i usually need to explicitly mention "upstream" (which i definitely didn't) or stuff goes to my fork 10:00
10:00 Geth__ left 10:01 raku-bridge joined, Geth___ joined 10:14 Altai-man_ joined 10:17 sena_kun left, raku-bridge left 10:24 raku-bridge joined, raku-bridge left, raku-bridge joined 10:31 Geth___ left 10:32 raku-bridge left 10:41 Geth_ joined 10:47 raku-bridge joined, raku-bridge left, raku-bridge joined 11:07 zakharyas left 11:33 patrickb joined 11:36 Geth left 11:40 Geth_ left, raku-bridge left 11:41 Geth joined, raku-bridge joined, raku-bridge left, raku-bridge joined 11:50 raku-bridge left 11:52 raku-bridge joined, raku-bridge left, raku-bridge joined 12:05 Geth left, raku-bridge left 12:06 Geth joined, raku-bridge joined 12:08 patrickb left 12:09 Geth_ joined, raku-bridge1 joined, raku-bridge1 left, raku-bridge1 joined, raku-bridge1 left 12:10 Geth_ left 12:15 sena_kun joined 12:16 Altai-man_ left 12:27 zakharyas joined 14:00 raku-bridge left 14:02 raku-bridge joined, raku-bridge left, raku-bridge joined
timotimo Found sha1 prefix `d72ace000' 14:08
with sha1 `d72ace000bc651f4a30bde931e5b5af770c4d876'
Using 000000275546D960
had i not pushed the commit to master yet, that would be perfect
14:14 Altai-man_ joined 14:16 sena_kun left
nwc10 \o/ 14:45
15:03 raku-bridge left 15:09 raku-bridge joined, raku-bridge left, raku-bridge joined 15:38 MasterDuke left 16:15 sena_kun joined 16:16 Altai-man_ left 16:36 Kaiepi left 16:38 Kaiepi joined 16:44 MasterDuke joined 16:45 Kaiepi left 16:49 Kaiepi joined 17:31 zakharyas left 18:08 MasterDuke left 18:14 Altai-man_ joined 18:16 sena_kun left 18:37 lucasb joined 18:42 zakharyas joined 20:14 sena_kun joined 20:17 Altai-man_ left
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/07/27/2020-...t-on-time/ 20:50
20:52 zakharyas left
timotimo findmethod on the debugserver ... what fun 22:13
needs to allocate an MVMString to function 22:14
22:14 Altai-man_ joined 22:15 leont left 22:17 sena_kun left
timotimo welp, gen2 always has space for you 22:17
gist.github.com/timo/d84b2ea40ac0e...b4c01c8a44 22:47
currently does it the same way spesh does, i.e. if there's no cache, or if there's a need to run code to find the method, it'll just return null for now 22:48
Geth MoarVM: b78b523d61 | (Timo Paulssen)++ | 2 files
debugserver: add "name" field for FindMethod

adds it to the protocol doc, and implements it on the server side.
I've decided against upping the protocol version, since nothing used FindMethod so far (as it was completely NYI, and wasn't implementable sensibly)		 23:10
MoarVM: 2a9f0f06f7 | (Timo Paulssen)++ | src/debug/debugserver.c
debugserver: actually react to FindMethod

if finding the method requires any code to be executed, that'll require the target thread to cooperate, and that'll be a bit more work in more places ...
timotimo .o( i wonder if p6-moar-remote and/or p6-app-moarvm-debug should report commits here ) 23:15
do i put in a new message type "code outer request" to get from an MVMCode to its outer, or should Outer Context Request continue giving an MVMContext's outer, but if passed an MVMCode, it'd return an MVMCode outer instead 23:36

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!