00:07 vrurg left 00:13 dogbert11 joined 00:17 dogbert17 left 00:21 vrurg joined 01:09 HarmtH left 01:10 HarmtH joined 01:34 kvw_5_ joined 01:37 kvw_5 left 07:50 sena_kun joined 08:50 Xliff joined, Xliff left 09:11 squashable6 left 09:14 squashable6 joined
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
14:29 patrickb joined
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
15:54 domidumont joined 16:40 Kaiepi joined 17:49 domidumont left 19:06 patrickb left 19:09 patrickb joined 19:18 lichtkind joined
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
19:52 patrickb left
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
21:24 epony left 21:28 epony joined
MasterDuke same thing with MVM_SPESH_BLOCKING=1? 21:30
21:49 sena_kun left 22:07 HarmtH_ joined, HarmtH left 22:19 HarmtH joined, HarmtH_ left 22:22 HarmtH_ joined 22:23 HarmtH left 22:44 lichtkind left 23:22 dogbert17 joined 23:26 dogbert11 left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!