🦋 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.
timo twitter.com/ekuber/status/1454986910397464576 02:07
japhb That is a beautiful lint message 02:44
[Tux] Rakudo v2021.10-29-g580b3ba79 (v6.d) on MoarVM 2021.10-20-gcd809ee47
csv-ip5xs1.378 - 1.392
csv-ip5xs-2015.505 - 15.557
csv-parser4.064 - 4.203
csv-test-xs-200.373 - 0.374
test6.880 - 6.918
test-t1.549 - 1.598
test-t --race0.982 - 0.987
test-t-2022.379 - 22.722
test-t-20 --race7.589 - 7.654
11:52
lizmat still a top-tenner :-)
[Tux] github.blog/changelog/2021-10-31-w...code-text/ 11:57
[Coke] Used to work on a MOO/MUD alternative to IRC and this was one of the reasons we had a hard time getting everyone to agree to update to Unicode back in the day. (the server is still up, I don't use it any more, but I'm pretty sure they're still using ASCII). 12:14
is 'rakubrew build-zef' getting zef latest from git? If so, should it be latest release? 12:17
(just guessing based on the git output when I run that command)
lizmat And yet another Rakudo Weekly news hits the Net: rakudoweekly.blog/2021/11/01/2021-...0-rakoons/ 13:38
timo wakudo reekly?!
lizmat que? 13:40
:-)
timo lizmat: you could make the "our" also code-font in the tweet about our hash is map is export 13:41
lizmat indeed, good spot # timo++ 13:42
Altai-man weekly: twitter.com/koto_san_kana/status/1...5496607746 14:51
notable6 Altai-man, Noted! (weekly)
lizmat sena_kun: sorry, just to late for this week's weekly :-( 16:00
*too
sena_kun lizmat, yeah, too bad I was stupid enough not to fix it earlier. But now we have something for the next week. :) 16:08
lizmat indeed... it's always good to have something good waiting in the wings 16:09
[Coke] .seen [Coke] 16:14
tellable6 [Coke], I saw [Coke] 2021-11-01T12:17:37Z in #raku-dev: <[Coke]> (just guessing based on the git output when I run that command)
Kaiepi will 2 Str:D given identical graphemes always be =:=? 17:38
m: say "a" =:= "a"; say "a" =:= "$('a')" 17:40
camelia True
True
Kaiepi m: say Str.new(my str $ = 'a') =:= "a" 17:41
camelia Default constructor for 'Str' only takes named arguments
in block <unit> at <tmp> line 1
Kaiepi m: say Str(my str $ = 'a') =:= "a"
camelia Impossible coercion from 'Str' into 'Str': value is of unacceptable type BOOTStr
in block <unit> at <tmp> line 1
Kaiepi m: say Str('a') =:= "a"
camelia True
timo m: say "a" but role { } =:= "a" 17:42
camelia False
timo m: say "a" but role { } ~~ Str:D
camelia True
Kaiepi it's ok for roles to distinguish Str:D in the case i'm thinking of, since they'd need the extra check anyway 17:47
if it's not possible with Str:D alone, then there should be a means of encoding named type parameters such that they're cacheable
timo m: say "oh" ~ "what" =:= "oh" ~ "what" 17:53
camelia False
Kaiepi m: ('oh' ~ 'what') => 1 ~~ -> |args { say %(args).keys.[0] =:= 'ohwhat' } 17:56
camelia WARNINGS for <tmp>:
False
Useless use of "=>" in expression "('oh' ~ 'what') => 1 ~~" in sink context (line 1)
Kaiepi m: say (('oh' ~ 'what') => 1) ~~ -> |args { say %(args).keys.[0] =:= 'ohwhat' } 17:57
camelia False
True
Kaiepi welp
m: say ((my str $ = 'oh' ~ 'what') => 1) ~~ -> |args { say %(args).keys.[0] =:= 'ohwhat' } 17:58
camelia False
True
Kaiepi m: say ((my str $ = 'oh' ~ 'what') => 1) ~~ -> |args { say %(args).keys.[0] =:= my Str:D $ = my str $ = 'ohwhat' } 17:59
camelia False
True
Kaiepi m: say ((my str $ = 'oh' ~ 'what') => 1) ~~ -> |args { say %(args).keys.[0] =:= (my Str:D $ = my str $ = 'ohwhat')<> }
camelia False
True
notna hi dev's. who has commit and the like right on github.com/rakudo/star? 19:35
it would be great if someone looks into github.com/rakudo/star/pull/167 19:36
any feedback for that pull is highly appreciated...