ugexe i dont know that you will be able to rely on <source> though 02:58
well maybe you can -- github.com/rakudo/rakudo/blob/c5d6...n.pm6#L374 03:03
[Tux] Rakudo v2021.02.1-15-gc5d635d99 (v6.d) on MoarVM 2021.02-5-g4f99ab382
csv-ip5xs0.808 - 0.819
csv-ip5xs-207.692 - 8.053
csv-parser26.751 - 27.899
csv-test-xs-200.383 - 0.395
test7.718 - 8.146
test-t1.911 - 1.982
test-t --race0.871 - 0.902
test-t-2032.098 - 32.767
test-t-20 --race9.339 - 10.065
07:22
nine Is the files method even a public API? There's only a single use of it in a spec test and that doesn't specify much except that the return value has an .elems method (which every Any does) 09:41
ugexe How else could one find bin files? 12:30
they don’t get declared in the Meta other than the implementation detail field ‘files’
that zef sets
So you can’t just iterate all distributions looking for a specific bin file without also using that implementation detail field 12:32
.files is the thus the public api to that
Or that’s how I’ve always seen it anyway 12:33
nine isn't finding that bin file something that's mostly relevant to rakudo itself? 12:53
ugexe i've written prototype plugin code similar to what japhb suggestd using .files 14:42
one example would allow dists to provide a bin/zef-foo which would allow `zef foo ...` to call that `bin/zef-foo` but essentially via a `require $file` (similar to .run-script). this allows all the zef config stuff etc to be used in that code which wouldn't be the case with bin/zef just spawning bin/zef-foo 14:46
i realize thats a bit eccentric though 14:47
MasterDuke bisectable6: my sub foo { fail }(); CATCH { default { my $bt = .backtrace; dd $bt.list[0].code.name } } 16:40
bisectable6 MasterDuke, Will bisect the whole range automagically because no endpoints were provided, hang tight
MasterDuke, Output on all releases: gist.github.com/12a6da9f5d94c000fe...4058a72f61
MasterDuke, Bisecting by output (old=2019.07.1 new=2019.11) because on both starting points the exit code is 0
MasterDuke, bisect log: gist.github.com/a6f177c3f0fea9c949...7857b093a0 16:41
MasterDuke, (2019-07-12) github.com/rakudo/rakudo/commit/96...11ee58c65a
MasterDuke, Output on all releases and bisected commits: gist.github.com/d630e4603954c42ef0...7fa8163cdf
MasterDuke uh, does anyone else see fails in t/spec/S32-exceptions/misc.rakudo.moar? tests 157 and 158 16:43
lizmat I've seen that fail occasionally 16:45
a re-compile usually fixed it
MasterDuke those tests are just the number of frames in a backtrace, how would a recompile change anything? i thought it was my spesh changes, but it's the same even with spesh disabled 16:47
lizmat ok, then it must be another pair of tests 16:48
sorry for the noise
sena_kun MasterDuke, does it flap for you?
MasterDuke well, it was always failing each time i ran it, but those are new fails for me 16:49
recompiling
sena_kun Ah, so something which can be absent on master.
Don't forget to add it to the flappers ticket please, if you see it fitting. :)
MasterDuke well, look at the bisectable6 log above, seems it should have been failing for a while now
just switched back to moarvm master and still getting the fails 16:51
ha. on moarvm master, `make t/spec/S32-exceptions/misc.t` passes, but `MVM_SPESH_DISABLE=1 make t/spec/S32-exceptions/misc.t` has those two fails 16:58
those tests were reverted once already as dubious, and then re-reverted. maybe that needs to be looked into again 16:59
github.com/Raku/roast/commit/c37c7...6e5ddf6829 and github.com/Raku/roast/commit/81f0a...2a09dd660e 17:00
lizmat notable6: weekly 17:10
notable6 lizmat, No notes for “weekly”
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/03/01/2021-...t-of-raku/ 18:12
sena_kun lizmat++ 18:23