🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
jdv doin the blin run now. sorry bout the last minuteness. 00:51
01:30 nine left, nine joined
releasable6 Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
08:18 finanalyst joined 08:26 sena_kun joined 08:59 kjp_ left
gfldex m: sub { return-rw(:1a) } 08:59
camelia WARNINGS for <tmp>:
Useless use of anonymous sub, did you forget to provide a name? (line 1)
gfldex m: sub { return-rw(:1a) }.();
camelia Cannot resolve caller return-rw(:a(Int)); none of these signatures matches:
( --> Nil)
(Mu \x --> Nil)
(**@x is raw --> Nil)
in sub at <tmp> line 1
in block <unit> at <tmp> line 1
gfldex Well
09:01 kjp joined
lizmat would you expect that to return a container with a Pair ? 09:07
gfldex I do. 09:15
lizmat m: sub a() { return-rw(42) }; my $b := a; $b = 666 09:19
camelia Cannot assign to an immutable value
in block <unit> at <tmp> line 1
lizmat return-rw is not supposed to create a container out of thin air
m: sub a() { return :foo }; say a 09:20
camelia foo => True
lizmat but it returning a Pair looks like it should :-)
m: sub a() { return-rw :foo }; say a 09:21
camelia Cannot resolve caller return-rw(:foo); none of these signatures matches:
( --> Nil)
(Mu \x --> Nil)
(**@x is raw --> Nil)
in sub a at <tmp> line 1
in block <unit> at <tmp> line 1
lizmat looks like this is a grammar thing
the signatures on return and return-rw are identical
feels like it is worth an issue 09:22
ab5tract Containers seem confusing enough without adding automatic containerization into the mix? 09:25
Though it’s still an LTA regardless 09:26
lizmat perhaps return-raw would have been a better name 09:27
because that's what it essentially does 09:28
ab5tract In looking back at some old IRC logs, it seems that the is raw trait arrived later than is rw, so probably it wasn’t part of the lexicon when return-rw was implemented 09:30
lizmat feels right
ab5tract Probably return is very special in that it could never be sensibly adverbed 09:31
lizmat ?
ab5tract return:raw $foo
There are other ops and methods that probably would have been implemented differently if adverbs were available though (sorry, somehow it popped into my brain) 09:32
lizmat m: sub a() { :foo }; say a 09:34
camelia foo => True
lizmat m: sub a() { return :foo }; say a
camelia foo => True
ab5tract What I mean is that return couldn’t have a multi candidate specifying :$raw! Because then no one could ever return a :raw pair in their return statement. It would get matched by the candidate, whose semantics wouldn’t make sense to pass it along 09:38
Anyway, it’s just the way my brain works. When I see ‘name-*’ in subs/methods, I see an opportunity to condense into a multi with adverbs. But I don’t see return as a viable candidate 09:40
11:29 lizmat_ joined 11:33 lizmat left 12:05 lizmat_ left 12:06 lizmat joined 14:00 finanalyst left
jdv got a few:( github.com/rakudo/rakudo/issues/5584 14:07
ab5tract: blin thinks one is yours 14:08
lizmat: the rest might be yours
ab5tract Interesting 14:10
[Tux] Rakudo v2024.04-135-g5fb665ba2 (v6.d) on MoarVM 2024.04-8-gf1173cb26
csv-ip5xs0.264 - 0.265
csv-ip5xs-201.137 - 1.139
csv-parser1.536 - 1.635
csv-test-xs-200.142 - 0.142
test2.014 - 2.015
test-t0.431 - 0.431
test-t --race0.275 - 0.278
test-t-205.132 - 5.170
test-t-20 --race1.239 - 1.253
 15:01
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
15:05 finanalyst joined 15:24 finanalyst left 15:35 Geth left, Geth joined 16:12 finanalyst joined
lizmat greppable6: copy-to-carray 17:22
greppable6 lizmat, 19 lines, 7 modules: gist.github.com/e65f7561b1aed3ecfa...cc442f3c72
lizmat jdv: I think I've done all I can about the blin fails 17:34
ab5tract looking into my share of it now 17:44
gfldex lizmat: I changed my mind about return-rw. This is more of an ENODOC. Easy to fix with a better example. 18:24
lizmat looking forward to a doc PR / commit
18:34 sena_kun left
lizmat m: my @a; @a[9]="foo"; dd @a[*]:k 18:34
camelia (9,)
lizmat m: my @a; @a[9]=9; dd @a.keys(:v)
camelia (0, 1, 2, 3, 4, 5, 6, 7, 8, 9).Seq
18:34 sena_kun joined
lizmat I wonder whether .keys should accept a :v argument to be compatible with the [*]:k semantics 18:35
jdv lizmat: thanks! 19:52
I guess some day we could handle abandoned dists better but that would require tuits 19:53
jdv wonders what percentage of the "always fails" is just that 19:54
so, afaik, we have just the 1 blocker for the release
ab5tract yeah.. I don't know if I'm going to get it fixed tonight 20:05
jdv it just needs to be "handled" before thursday 09:00 ET or so:) 20:10
21:24 nine left, nine joined
Geth rakudo/main: 45966a8cd0 | ab5tract++ | src/core.c/Main.rakumod
Additional guard when selecting the type for MAIN args

This is required to fix the situation where ::('a') and CORE::('a') are the same, but GLOBAL::('a') doesn't match CORE::('a') by virtue of being `Nil` -- the intent of the guard is to use GLOBAL::('a') when it is "in front" of CORE::('a') by virtue of being part of a user-defined ... (21 more lines)		 21:46
ab5tract jdv: I managed to get to it after all 21:47
22:04 sena_kun left 22:10 finanalyst left 22:17 [Tux] 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!