00:39 lucasb left
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.
01:43 Geth left, Geth joined 02:08 ufobat_ joined 02:11 ufobat left 05:39 releasable6 left, unicodable6 left, nativecallable6 left, bisectable6 left, quotable6 left, reportable6 left, shareable6 left, coverable6 left, statisfiable6 left, committable6 left, benchable6 left, bloatable6 left, notable6 left, squashable6 left, greppable6 left, sourceable6 left, statisfiable6 joined, bloatable6 joined 05:40 quotable6 joined, nativecallable6 joined, committable6 joined, squashable6 joined, coverable6 joined, benchable6 joined 05:41 sourceable6 joined, greppable6 joined, bisectable6 joined 05:42 notable6 joined, reportable6 joined, shareable6 joined, unicodable6 joined, releasable6 joined 07:55 stoned75 left 09:01 domidumont joined
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
09:16 sena_kun joined 09:37 squashable6 left 09:39 squashable6 joined 09:43 Merfont joined 09:44 Kaeipi left 09:52 Altai-man_ joined 09:55 sena_kun left
|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
11:25 domidumont left 11:53 sena_kun joined 11:54 Altai-man_ left
AlexDaniel Xliff: yeah… fix the module? 12:02
Xliff: this line is wrong probably github.com/jnthn/oo-monitors/commi...f14c6a41R3 12:03
12:39 Voldenet left 12:44 Voldenet joined, Voldenet left, Voldenet joined 13:01 lucasb joined 13:21 AlexDaniel left 13:30 domidumont joined 13:52 Altai-man_ joined 13:55 sena_kun left
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
15:53 sena_kun joined 15:55 Altai-man_ left
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
16:32 domidumont left 16:49 patrickb joined
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.
17:37 patrickb left 17:52 Altai-man_ joined 17:55 sena_kun left 18:02 squashable6 left 18:03 squashable6 joined 18:18 moon-child left 18:34 moon-child joined 19:25 MasterDuke joined 19:37 MasterDuke left 19:42 MasterDuke joined 19:53 sena_kun joined 19:55 Altai-man_ left 20:52 dogbert11 left
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 ^^^
21:52 Altai-man_ joined 21:54 sena_kun left
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]
23:53 sena_kun joined 23:55 Altai-man_ 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!