nine sena_kun: does kill.t fail consistently? Can you get some more output from the test? 09:26
sena_kun nine, I'll run the suite some more and get you more info. 09:31
nine, it has failed the second time at least, when I run it directly (the command is in the title), gist.github.com/Altai-man/8c87b45a...16537f7aa8 09:47
➜ rakudo git:(master) ✗ ./rakudo-m --version
Welcome to Rakudo(tm) v2021.03-14-g2d1f4904e
Is there a way to set make stresstest to show more tests output? 09:48
nine sena_kun: maybe the same as I'm using to get the full output of make test failures: build.opensuse.org/package/view_fi...f?expand=1 10:19
sena_kun is dumb enuogh to having difficulties with translating the command from just coretests to stresstest. To remove Make from equation I am running just "PERL5LIB=lib5 perl t/harness5 --fudge --keep-exit-code --test-from-file=t/spec/spectest.data --stress --archive=make-test.tar || { mkdir results && cd results && tar xf ../make-test.tar && find . -type f -exec echo '{}' ; -exec cat '{}' ; ; false ; }" and getting "Result: NOTESTS". 11:13
s/having/have/ 11:14
Awwww, it must be "tests-from-file", not "test-from-file".
Now it works...
And somehow 1)I don't see the test failing; 2)The archive is not created. :| 12:12
Don't have more time for it today. 12:13
nine sena_kun: do you have the TAP::Harness::Archive Perl module installed? If yes, you don't need the PERL5LIB=lib5, if no you need to put the file from the patch into lib5/ 12:19
sena_kun nine, I don't, so I applied the patch you posted and played with commands to collects logs of stresstest rather than just coretest. With coretest it seems to do the right thing (I was able to get a proper archive), but less of luck with the whole stresstest. This machine is too shitty to do so much stresstesting alas. 12:22
nine sena_kun: I just pushed a fix to MoarVM which may help 12:44
with the kill.rakudo.moar
sena_kun nine, disregard my comment about kill.t, so far I see no flappers with TEST_JOBS=20. However, there is a stable test failure for 6.c-errata and 6.d-errata. I did not cherry-pick anything, do you mind looking at them? This test has drifted too much to just cherry-pick your github.com/Raku/roast/commit/da922...f413b07d0f 15:04
[Tux] Rakudo v2021.03-17-gfe0c2daa7 (v6.d) on MoarVM 2021.03-14-g16fe88fdf
csv-ip5xs0.825 - 0.853
csv-ip5xs-207.924 - 8.234
csv-parser25.200 - 27.666
csv-test-xs-200.366 - 0.379
test7.817 - 8.157
test-t2.044 - 2.049
test-t --race0.971 - 0.992
test-t-2034.815 - 34.875
test-t-20 --race10.027 - 10.626
15:10
bartolin_ r: use nqp; my $pair := nqp::create(Pair); nqp::bindattr($pair,Pair,"\$!value",nqp::add_i(nqp::getattr(($pair := Pair.new(42,0)),Pair, "\$!value"),1)); say $pair 19:47
camelia 42 => 1
42 => 0
bartolin_ ^^ this seems to be the cause for some recent breakage on the JVM backend: github.com/rakudo/rakudo/issues/4272 19:48
it took me a while to golf it, but I think this shows the underlying problem 19:49
lizmat just pushed github.com/rakudo/rakudo/commit/dc...f2e43720df "unbreak Bags on the JVM backend" 20:27
bartolin_ ^^
bartolin_ lizmat: oh, that was fast. I'll try it out. thanks for looking! 20:30
lizmat no, thank *you* for looking and finding out the issue: it made the fix easy!
bartolin_ I've tried a couple of the failing test files and all of them are fine again. I'll run a spectest over night, but I'm pretty sure the problem is solved. :) (I'll close the issue if my spectest run looks good.) 20:44
lizmat bartolin_++ 20:47
bartolin_ is still somewhat curious what caused the different behaviour of the two backends. Hopefully it doesn't surface in other places ... 20:51
lizmat well, I guess I was trying to be too enthousiastically optimizing there 20:53
anyways, because of this, I found an interesting thing 20:54
my %b is Bag = "words".IO.slurp.comb # runs for 9 seconds on my machine
my %b is Bag = "words".IO.slurp.comb>>.lc # lowercasing *each* char makes it faster ??? because *that* runs at 6.8 seconds for me 20:55
my %b is Bag = "words".IO.slurp.lc.comb # runs 8.5 seconds 20:56
japhb OK, that's weird.
bartolin_ well, working on lowercase chars would probably avoid some type checks -- depending on the number of upper-case chars in your words file (github.com/rakudo/rakudo/blob/dc50...pm6#L588). Maybe that outweights the effort to run .lc on each char. 21:03
lizmat nah, the difference is in the *inclusive* time of push-until-lazy
something weird is indeed going on... 21:06
MasterDuke same thing with MVM_SPESH_BLOCKING=1? 21:30