🦋 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.
00:02 reportable6 left 00:03 reportable6 joined 00:36 Xliff joined 00:40 squashable6 left 01:40 evalable6 left, linkable6 left 01:41 linkable6 joined 01:42 evalable6 joined
Geth rakudo: vrurg++ created pull request #4487:
Re-compose native types
02:42 squashable6 joined 03:30 squashable6 left 03:32 squashable6 joined 05:32 casaca left 05:38 casaca joined 05:39 casaca left 05:42 casaca joined 06:02 reportable6 left 06:03 reportable6 joined 06:38 ilogger2 left 06:39 ilogger2 joined 06:40 patrickb joined 07:00 patrickb left 07:16 Xliff left 07:33 frost joined
Geth rakudo: a8a78132e2 | (Vadim Belman)++ | src/core.c/core_epilogue.pm6
Re-compose native types

They're created with uncomposed, incomplete parents. Thus they fail typematching against roles like Numeric, Real, Stringy.
Fixes rakudo/rakudo#4485
rakudo: 2c0343b5bb | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/core_epilogue.pm6
Merge pull request #4487 from vrurg/rakudo_4485

Re-compose native types
08:04 linkable6 left 09:04 evalable6 left 09:05 evalable6 joined 09:07 linkable6 joined 09:38 Xliff joined
gfldex github.com/rakudo/rakudo/pull/4460 could do with a review and if fine, merging 10:01
10:47 sena_kun joined
lizmat gfldex: doesn't changing the proto cause test failures ? 10:53
gfldex lizmat: not for me. I believe this is thanks to most //,&&,||,^^ in roast never call the actual operators but are handled by internal macros. 10:54
lizmat also "make test" ? 10:55
gfldex make test is fine too.
You have to use &infix:<//> to acutally use them. Hence the issue only popped up when somebody tried to .reduce(&infix:<&&>) . 10:56
The only operator that was already defined for lists of values in 6.c was infix:<^^>. 10:58
11:02 Xliff left 12:02 reportable6 left 12:05 Xliff joined 13:05 reportable6 joined 14:19 evalable6 left, linkable6 left, evalable6 joined 14:35 frost left 15:20 linkable6 joined 16:50 linkable6 left, evalable6 left 17:16 sena_kun left 17:52 linkable6 joined 17:53 evalable6 joined 18:02 reportable6 left 18:05 reportable6 joined 20:15 SmokeMachine_ left
Kaiepi i've been stuck on this sort of typecheck for a while now 20:19
m: say Buf ~~ Buf[uint8] 20:20
camelia False
Kaiepi should roles be concerning themselves with the values the body block winds up with over the arguments the user provides to begin with? 20:21
since that seems necessary for this to be true without making Buf ~~ Buf[uint16] etc. in the process 20:22
or rather, Buf.^parameterize 20:24
i'm not sure the last typecheck i mention in github.com/rakudo/rakudo/pull/4478...-888725774 is valid if it needs so much weirdness in order to work 20:26
20:42 SmokeMachine_ joined
gfldex Kaiepi: I expect that to be False. A Buf is a buf8 in potentia. Being member of the group is no the same thing as being the group. 20:46
Kaiepi gfldex, thing is role groups typecheck like their nonsignatured candidate, so 20:52
m: say Buf ~~ Blob[uint8]
camelia False
Kaiepi ahh
i diverged somewhere
wait, no 20:53
m: say Buf.^parameterize ~~ Blob[uint8]
camelia True
gfldex m: say buf8 ~~ Buf;
camelia True
Kaiepi m: say Buf.^parameterize ~~ Buf[uint8] 20:54
camelia False
Kaiepi m: say Buf.new ~~ Buf[uint8].new
camelia True
Kaiepi m: say Buf.^parameterize.new ~~ Buf[uint8].new
camelia True
Kaiepi oh 20:55
m: say Buf[uint16].new ~~ Buf[uint8].new
camelia True
gfldex the last one feels wrong 20:56
Kaiepi m: say Buf[uint16].new eqv Buf[uint8].new 20:58
camelia False
Kaiepi m: say Buf[uint8].new eqv Buf[uint8].new
camelia True
Kaiepi m: say Buf.new eqv Buf[uint8].new 20:59
camelia False
21:32 discord-raku-bot left, discord-raku-bot joined