21 Jul 2024
evalable6 23:20
timo evalable: my $t = IO::Socket::Async.listen("0.0.0.0", 5000).tap: -> $conn { }; my $conn = await IO::Socket::Async.connect("127.0.0.1", 5000); $conn.close; say $conn.Supply.list; $t.close;
evalable6 (exit code 1) ()
MoarVM panic: non-AsyncTask fetched from eventloop active work list
timo there, this reliably reproduces the bug
now we can pepper the code with fprintf and see if we can see something :D 23:21
22 Jul 2024
lizmat timo++ MasterDuke++ 08:54
timo who doesn't love a good trampoline? 09:54
lizmat FWIW, confirmed on MacOS as well 09:56
timo randomly thinking about exploitability of moarvm when someone gets some shellcode smuggled into it somehow 11:43
it'd be swell to have all jitted frames in a special area of memory so a tool could just by looking at the $rip tell if it's looking at a jitted frame or something else 11:44
but if the $rip for all jitted frames becomes too regular, an attacker could guess the location of the common jit prologue for example
wow spesh dump is kinda slooow 13:14
looks like we sometimes compile an nqp edge "charlist" for single characters. there's probably a more efficient way to have that 18:14
lizmat perhaps that could be handled at RakuAST opt time? 18:18
timo moar can handle it, i've got a prototype patch, but it could also be possible to do it before optimization time. if not, then at optimization time, yeah 18:26
MVM_string_index_of_grapheme goes from 0.62% to 0.5%, barely noticeable (core setting compilation) 18:33
since it started at 0.62% in the first place, barely much win to be had even if it were completely gone from the profile now
oh it gets better when you recompile Raku/Grammar.nqp because the optimization makes it into the serialized blob 18:38
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/07/22/2024-...e-toolbox/ 19:31
24 Jul 2024
MasterDuke anyone else read people.kernel.org/gustavoars/how-t...-and-linux ? wonder if we could use it in moarvm 01:23
Geth MoarVM: MasterDuke17++ created pull request #1823:
Silence a bunch of valgrind errors
01:56
timo do we have any reason for using #define MVM_BLABLA 1 and such instead of enums? 17:19
lizmat the same reason we have #?if moar in nqp / rakudo? 17:21
timo web.archive.org/web/20170120021505...akudo.html 17:29
web.archive.org/web/20150204073833...o_opt.html
if someone wants to dig into the source of these html files and fix them up to render again using maybe the current source of p6bench or code from Back Then :D 17:30
lizmat: in C we can also have #if and #ifdef inside of enums and such
25 Jul 2024
Geth MoarVM/2024.07: d5058c66dc | (Justin DeVuyst)++ | 2 files
Update changelog and version
18:22
MoarVM: jdv++ created pull request #1824:
Update changelog and version
18:35
MoarVM/main: d5058c66dc | (Justin DeVuyst)++ | 2 files
Update changelog and version
18:36
MoarVM/main: 83c8567a7b | (Justin DeVuyst)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1824 from MoarVM/2024.07

Update changelog and version
jdv done here 18:38
timo m: say 2053552.5 * 100 / 2052982 23:34
camelia 100.02778885
timo m: say 100 * 2053552.5 R/ 2052982 23:35
camelia 99.9722189
26 Jul 2024
MasterDuke are those numbers for nfa improvements? 00:47
there's definitely something going on with t/spec/S12-construction/destruction.t. running with --configure=0 may throw some red herrings in the mix, but it pretty regularly will fail with `Parse errors: Bad plan.  You planned 6 tests but ran 5.` 01:17
hm. but valgrind doesn't report anything when that happens 01:37
timo i got a small decrease in the maxresidentk from a change in the nfa memory stuff 11:24
from surveying the structure of the NFAs present in core setting compilation, i could see that the majority of states only have one or two outgoing edges 11:29
m: say 100 * 2050532 / 2053552.5 13:58
camelia 99.8529134