[01:26] <japhb> timo: Have you been able to find bugs from fuzzing that have reasonably obvious patches?

[01:30] <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:31] <timo> 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:33] <timo> 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:34] <timo> fuzzing the only-parts-inside-moarvm target from before was fruitful for figuring the utf8-c8 crash out, though

[01:57] <timo> there. nfa state transitions now go into coverage numbers

[02:30] <[Coke]> https://github.com/rakudo/rakudo/issues/6109 - thought we had a ticket for this, but tripped over it again on LLM::Functions

[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
[14:21] <[Coke]> my weird junction failure on windows... only fails on the old compiler. AST works.

[14:22] <[Coke]> Should RAKUDO_RAKUAST also enable AST when it is falsy?

[14:22] <[Coke]> e.g. setting it to 0 turns it on, which was briefly surprising.

[15:06] <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:07] <timo> to be fair, you're really supposed to build a dictionary for this kind of fuzzing target

[16:27] <[Coke]> https://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:33] <[Coke]> Any suggestions on how to golf <a b c>.all ~~ Str:D more?

[16:35] <[Coke]> might be specific to the type, as '<a>.all.chars ~~ 1' works on both.

[16:36] <[Coke]> (as does == 1)

[16:38] <[Coke]> both mac/win: 'all(Str:D)' -> 'all((Str:D))' but 'all(3)' is just 'all(3)'

[16:49] <[Coke]> lizmat: is it tied to ~~ since the .ACCEPTS call works?

[16:50] <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?

[17:06] <[Coke]> it happens in a .raku file also

[17:23] <timo> ok good to know

[17:23] <timo> have you tried with spesh disabled yet? unlikely to make a difference

[17:25] <[Coke]> nope.

[17:28] <[Coke]> same failing response with JIT and SPESH disabled.

[18:18] *** sjn joined
[21:50] <lizmat> well.. we actually have a smartmatch dispatcher

[21:50] <lizmat> I wonder if that has something to do with it

[21:51] <[Coke]> there was a lot of dispatcher work that month.

[21:51] <[Coke]> ugexe is doing some digging with current rakudo, I'm trying to bisect between 2023.12/2024.01

[21:52] <timo> the moar remote debugger can step through dispatchers you know

[21:53] <timo> but they mostly have local variables rather than lexicals so you won't see terribly much

[21:53] <timo> line numbers would still be helpful for figuring out what paths it takes though

[21:54] *** japhb left
[21:56] *** japhb joined
[22:10] <[Coke]> "12 revisions left"