[Coke] bisected to github.com/rakudo/rakudo/commit/95770d31 00:24
timo return 0 unless &cand.file.starts-with: 'SETTING::'; - filenames being different on windows maybe? 00:28
i guess those were already in there before the change 00:29
[Coke] timo: any pointers on how to debug raku on windows? Building a copy from HEAD with --debug right now 00:41
Or, is there some way to emit tons of debug output about the dispatchers? 00:42
wonder if dispatcher combined with RAKUDO_OPTIMIZE_NOSM helps. 00:43
timo there is. you can flip a define inside moarvm's source in disp/program.c IIRC 00:44
what's NOSM?
it can dump programs as well as recordings. not sure which one will be the interesting one, and it's really really chatty 00:45
[Coke] no smartmatch, probably
ah RAKUDO_OPTIMIZER_DEBUG=1 will give me something to work with
timo if turning the optimizer off completely, or down to 0 at least, should tell us if the optimizer has a part in the bug 00:48
[Coke] ... RAKUDO_OPTIMIZE_NOSM=0 avoids the bug, yes 00:50
timo i seem to recall you looked whether the output of --target=optimize was the same or not? 00:51
oh, you only checked --target=ast 00:52
[Coke] lovely, getting non-utf8 rendering from target=optimize. 01:02
timo isn't that just because windows terminal isn't utf8 by default? 01:04
redirect to a file, perhaps that helps?
[Coke] found the arcane output encoding invocation 01:06
here's the target=opt outputs: gist.github.com/coke/965fed0b3161b...8d52535904 01:07
they are definitely different on mac vs. win
timo can also try diffing windows with NOSM and without 01:08
the one on the top doesn't use the raku-smartmatch dispatcher, instead writing the logic out into nested ifs 01:11
[Coke] updated gist 01:12
so maybe the optimizer is broken and it's just not in use on mac? 01:14
(gist now has a run with NOSM enabled on win)
walking away from $worktop for the night.
timo ah, I guess the smartmatch part of the optimizer is also what's responsible for spitting out a dispatch op if it can't write it all out by itself?
so we kind of have three different kinds, mac, windows with nosm, and windows without nosm are all different 01:15
mac with nosm would look like windows with nosm i'd expect. just a call to &infix:<~~>
you can now ask moar to spit out covered edges as they are first hit, and also what file + frame + BB each number corresponds to so you can actually figure out what each edge it spits out refers to 03:37
except of course you would want to `moar --dump thefilename` to go to the frame by its CUID, but then you only see instructions by their index. you would have to figure out yourself where BBs go. and I could instead of the BB index spit out the PC at the start of the block but of course that's different from the instruction index because instructions are different lengths 03:40
the spesh log can give you what you need but of course it doesn't spit out every frame, just the ones that end up speshed 03:43
that also has the bb indices right there in its own output
but my dumping code and the coverage reporting spits it out as unsigned ints because negative numbers don't really make sense here, and in the spesh log output it's showing as singed so some of the numbers are negative and you wouldn't find them in the coverage log ... haha :( 03:46
patrickb Just to understand the implication: The compilation output should be the same on Win Mac Unix. But for some reason it isn't. Correct? 07:07
08:35 finanalyst joined
lizmat also for my understanding (as the author of the bisected commit): it is *tickling* an underlying bug, but the code itself is correct ? 08:43
11:19 finanalyst left 12:02 finanalyst joined
Geth roast: 90eb9e8b07 | (Elizabeth Mattijsen)++ | S32-exceptions/misc2.t
Fix .return value test
12:20
12:43 finanalyst left
Geth rakudo/main: 1d991f95fe | (Elizabeth Mattijsen)++ | src/core.c/Str.rakumod
Fix .index(@needles)

It had a (I'd say premature) optmization in it that produced the wrong results, as spotted by David Schultz++ in #6104.
On closer inspection, I'd say the overhead of creating a substring to search in, is overkill.
In any case, the code is much simpler now, has fewer moving parts and will probably inline better than before.
12:53