🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
lizmat Files=1353, Tests=117175, 295 wallclock secs (36.02 usr 10.15 sys + 4147.73 cusr 346.82 csys = 4540.72 CPU) 08:20
[Tux] Rakudo v2022.04-70-g73b43e5f9 (v6.d) on MoarVM 2022.04-3-ga9fcd5a74
csv-ip5xs0.891 - 0.918
csv-ip5xs-205.750 - 5.818
csv-parser3.642 - 3.811
csv-test-xs-200.416 - 0.430
test6.650 - 7.556
test-t1.573 - 1.594
test-t --race0.983 - 1.091
test-t-2021.937 - 22.41
test-t-20 --race7.168 - 7.353
08:26
Geth rakudo: bea597626a | (Elizabeth Mattijsen)++ | 2 files
Update BUILDPLAN helper module to uint renumbering
08:51
rakudo: 9fd893f74c | (Elizabeth Mattijsen)++ | lib/BUILDPLAN.rakumod
Some more BUILDPLAN helper tweaks
09:41
Kaiepi m: say Buf ~~ Blob 14:06
camelia True
Kaiepi i'm a bit confused by this kind of typecheck, where a role group checks a role group as a supertype of its nonsignatured candidate 14:07
because to my knowledge, that should imply that all candidates of the group have it 14:08
but a bunch of tests depend on this being true 14:09
s/should/would/ 14:10
m: role Buf[::T, :::U] { }; say Buf ~~ Blob; say Buf[1, 2] ~~ Blob 14:13
camelia False
False
Kaiepi m: role Buf[::T] does Blob[::T] { }; role Buf[::T, :::U] { }; say Buf ~~ Blob; say Buf[1, 2] ~~ Blob 14:14
camelia False
False
Kaiepi m: role Buf[::T] does Blob[T] { }; role Buf[::T, :::U] { }; say Buf ~~ Blob; say Buf[1, 2] ~~ Blob
camelia False
False
Kaiepi m: role Buf[::T] does Blob[T] { }; say Buf ~~ Blob; say Buf[1, 2] ~~ Blob
camelia ===SORRY!===
No appropriate parametric role variant available for 'Buf':
Cannot resolve caller (Buf[Int,Int]:U, Int:D, Int:D); none of these signatures matches:
(::$?CLASS ::::?CLASS Mu, ::T Mu)
Kaiepi m: role Buf[::T] does Blob[T] { }; say Buf ~~ Blob; say Buf[1] ~~ Blob
camelia False
True
Kaiepi argh, i'll get what i'm going for elsewhere 14:15
m: role Foo[::T = Mu] does Positional[T] { }; role Foo[::T, ::U] { }; say so all Foo, Foo[0], Foo[0, 1] X~~ Positional 14:17
camelia True
Kaiepi ^
releasable6 Next release in ≈4 days and ≈23 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 19:00
Geth rakudo: vrurg++ created pull request #4934:
Get back to using Lock in Stash and CompUnit
20:47
Kaipei so now that i have that weirdness figured out, roast passes again w/ generic/role changes 21:07
need to give nqp its once over before i can put up a draft 21:08
Geth rakudo: ddef646171 | (Vadim Belman)++ | 9 files
Get back to using Lock in Stash and CompUnit

Use of `Lock::Soft` caused some expected, though not critical, performance regression. Yet, in the light of a recent discussion on IRC, the non-blocking locking doesn't outweight the regression. Therefore it is considered reasonable to get back to use of `Lock`.
  `Lock::Soft` as such remains in place though as it might be useful in
applications where `Lock::Async` cannot serve as a `Lock` replacement due to its specifics.
22:15
rakudo: 1c46805449 | (Vadim Belman)++ (committed using GitHub Web editor) | 9 files
Merge pull request #4934 from vrurg/problem-solving-323-back-to-lock

Get back to using Lock in Stash and CompUnit