japhb timo: Have you been able to find bugs from fuzzing that have reasonably obvious patches? 01:26
timo afl hasn't been able to cause a crash in the "just parse nqp source" workload yet, only timeouts. i'm really "early days" here and before the results get much better I'll want to put more kinds of feedback to the coverage into it 01:30
one very important feature of afl and friends is the "cmplog", which collects comparisons of values from all kinds of different sources and makes them available to the mutator function 01:31
i thought MVM_string_equal_at would be a great candidate, but there's barely any matches that are longer than 1 character, I think the NFA is doing most of the selecting and then the string equals is mostly "yep we'll match the literal that the NFA selected for us", so it'd mostly just give "matched!" which is barely an information win i think? 01:33
fuzzing the only-parts-inside-moarvm target from before was fruitful for figuring the utf8-c8 crash out, though 01:34
there. nfa state transitions now go into coverage numbers 01:57
[Coke] github.com/rakudo/rakudo/issues/6109 - thought we had a ticket for this, but tripped over it again on LLM::Functions 02:30
07:07 [Tux] left 07:10 [Tux] joined 09:17 librasteve_ joined 09:43 finanalyst joined 10:44 sjn left 11:12 finanalyst left 12:46 nine left 12:48 nine joined
[Coke] my weird junction failure on windows... only fails on the old compiler. AST works. 14:21
Should RAKUDO_RAKUAST also enable AST when it is falsy? 14:22
e.g. setting it to 0 turns it on, which was briefly surprising.
timo a little disappointed with the fuzzer's results trying to explore the nqp grammar starting from just `say("hi");` - it has stumbled over "nq" after many hours, but hasn't found "nqp" yet. i thought getting coverage from NFA edges would help it stumble upon such pieces quickly 15:06
to be fair, you're really supposed to build a dictionary for this kind of fuzzing target 15:07
[Coke] github.com/rakudo/rakudo/issues/6109 - there is no different between the --target=ast on win or mac (except for the <feff> at the top of the windows file I saved 16:27
Any suggestions on how to golf <a b c>.all ~~ Str:D more? 16:33
might be specific to the type, as '<a>.all.chars ~~ 1' works on both. 16:35
(as does == 1) 16:36
both mac/win: 'all(Str:D)' -> 'all((Str:D))' but 'all(3)' is just 'all(3)' 16:38
lizmat: is it tied to ~~ since the .ACCEPTS call works? 16:49
timo it's not about cmd.exe syntax vs bash syntax right? the code that actually goes into the parser is really the same and not mangled beyond recognition by windows argument handling somehow? 16:50
[Coke] it happens in a .raku file also 17:06
timo ok good to know 17:23
have you tried with spesh disabled yet? unlikely to make a difference
[Coke] nope. 17:25
same failing response with JIT and SPESH disabled. 17:28
18:18 sjn joined
lizmat well.. we actually have a smartmatch dispatcher 21:50
I wonder if that has something to do with it
[Coke] there was a lot of dispatcher work that month. 21:51
ugexe is doing some digging with current rakudo, I'm trying to bisect between 2023.12/2024.01
timo the moar remote debugger can step through dispatchers you know 21:52
but they mostly have local variables rather than lexicals so you won't see terribly much 21:53
line numbers would still be helpful for figuring out what paths it takes though
21:54 japhb left 21:56 japhb joined
[Coke] "12 revisions left" 22:10