github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
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
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
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
nwc10 \o/ 14:45
lizmat and another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/07/27/2020-...t-on-time/ 20:50
timotimo findmethod on the debugserver ... what fun 22:13
needs to allocate an MVMString to function 22:14
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!