Xliff Is this known?: [OO::Monitors] Could not find Test::Counter 01:27
Is there a workaround> 01:28
s/</?/
Oh, ffs... you know what I mean.
lizmat Files=1294, Tests=109644, 209 wallclock secs (28.48 usr 8.04 sys + 2946.76 cusr 275.59 csys = 3258.87 CPU) 09:14
|Tux| Rakudo version 2019.11-411-g5d8ef435d - MoarVM version 2020.01-15-g1fa9764bf
csv-ip5xs0.725 - 0.725
csv-ip5xs-206.252 - 6.261
csv-parser22.527 - 22.696
csv-test-xs-200.417 - 0.428
test7.566 - 7.569
test-t1.734 - 1.736
test-t --race0.806 - 0.808
test-t-2029.418 - 29.879
test-t-20 --race9.043 - 9.489
 10:28
0.002 diff between low and high
Geth rakudo: ccb92df2f0 | (Elizabeth Mattijsen)++ | src/core.c/Str.pm6
Also include "_" in Str.raku fastpath
 10:47
AlexDaniel Xliff: yeah… fix the module? 12:02
Xliff: this line is wrong probably github.com/jnthn/oo-monitors/commi...f14c6a41R3 12:03
japhb I was able to do a full build (rakudo + all my modules) post-bump, so it looks like nine++'s fix worked for me too. Time to point release moarvm for packagers, bump to that, and release nqp/rakudo? Or are we still waiting on Blin results? 15:09
vrurg wonders what might cas to block infinitely?? 15:41
*might cause
jnthn Well, at least using cas ain't the cause ;) 15:51
vrurg jnthn: looks like blocking was cause by use of Log::Async inside cas code block. Don't know if it's legitimate, but have no time to investigate. 16:19
jnthn Well, you are always vulnerable to live lock if you use cas
That's just the nature of the thing 16:20
It's a global progress bound, but not a local one
patrickb .tell Xliff Did you try nuking your zef Repo store? I seem to recall this is another instance of the infamous ecosystem-doesn't-support-real-versions problem. 16:51
tellable6 patrickb, I'll pass your message to Xliff
patrickb .tell Xliff You zef most probably still has the OO::Monitor repo checked out on a 2017 something commit in its repo store. I think the commit AlexDaniel linked is actually the fix for your problem. Zef does not update, because there was no version bump in the repo yet and thus you are stuck with your 2017 checkout. 16:55
tellable6 patrickb, I'll pass your message to Xliff
patrickb jnthn: Can you version bump OO::Monitors?
jnthn ah, I was going to release it via CPAN instead for the next release... 17:00
patrickb That's the future-proof alternative. 17:04
lizmat bisectable6: class A { method f() { ENTER say "foo" } }; A.f 17:07
bisectable6 lizmat, On both starting points (old=2015.12 new=ccb92df) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «foo␤foo␤»
lizmat wow
m: class A { method f() { ENTER say "foo" } }; A.f
camelia foo
foo
AlexDaniel` m: class A { method f() { ENTER say "foo" }; say 42 }; A.f 17:08
camelia 42
foo
foo
AlexDaniel` * m: class A { method f() { ENTER say "foo"; say 42 } }; A.f
jnthn patrickb: Done now. 17:25
patrickb jnthn: That was fast. Thank you!
.tell Xliff: jnthn++ has just uploaded a new version. When you try again it should just work. 17:26
tellable6 patrickb, I'll pass your message to Xliff
jnthn Welcome; meant to do it before, but forgot.
Geth rakudo: 8ad3d2440a | (Elizabeth Mattijsen)++ | src/core.c/Map.pm6
Save one scalar allocation per Map.raku
 21:16
rakudo: 66cf6f811f | (Elizabeth Mattijsen)++ | src/core.c/TypedArray.pm6
Make Array[Int].raku at least 5% faster

  - at least one scalar allocation less
  - call Type.raku only once
  - better optimized at handling "holes" in the array		 21:34
lizmat if you profile: <foo bar baz>.map: {.raku} for ^1000000 21:41
versus: <foo bar baz>.map: *.raku for ^1000000
you will see that the *.raku case is a slower than the {.raku} case 21:42
7110.48ms vs 7352.94ms
sena_kun lizmat, ooc, is there any special meaning in optimizing .raku? from the user point of view, it doesn't seem to me like a highly hot code, but I wonder if that's the other case for the internals. 21:43
lizmat while debugging stuff with dd, it adds up :-)
this particular case is just an example using .raku
it could have been any method 21:44
the above {.raku} code created 1M Block and 1M Int objects 21:46
the *.raku case created 1M WhateverCode blocks 21:47
yet the *.raku case has more GC runs (367 vs 363) 21:48
so it looks like the {.raku} case is about 3% faster, and has 1% fewer allocations 21:49
now, there are many cases in the core that use the WhateverCode version in .map e.g. 21:50
so I'm wondering whether it would make sense to change all of those?
or that the WhateverCode version is just under-optimized
and should leave it until that is optimized 21:51
jnthn ^^^
lizmat sena_kun: also, the default .gist is calling .raku 22:00
tellable6 lizmat, I'll pass your message to sena_kun
lizmat Altai-man_ ^^^
Altai-man_ ...sorry for my connection...
yes, read that, thanks for the explanation. :) 22:01
Geth rakudo/release-2020.01: f60c538d5f | Altai-man++ | docs/release_guide.pod
Update new release date
 23:52
rakudo/release-2020.01: 0266ddd890 | Altai-man++ | 2 files
Log all changes (+ announcement)

Deliberately not logged:
7f15a57 2c5c013 3802cdf 1ec69e1 654d6a1 aa06d32 044b339 88db15f 1d84c64 1d84c64 726c38f d36c2e5 a62d9c7 bbcc342 e03f013 830400f 9528bd0 da03d10 9fa4396 f608a7a 82bd9c2 ... (22 more lines)
rakudo/release-2020.01: e8cd0d4462 | Altai-man++ | 2 files
Remove reverted commit

Deliberately not logged: [c63d8a87]

Powered by Cro and the Raku® Programming Language.

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

Thank you!