🦋 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.
Nemokosch bisectable6: say(1 S+ 2 S+ 3) 09:02
bisectable6 Nemokosch, Will bisect the whole range automagically because no endpoints were provided, hang tight
tellable6 2023-04-08T07:42:01Z #raku-dev <nine> Nemokosch: no?
2023-04-08T07:42:35Z #raku-dev <nine> Nemokosch: disregard, ENOCOFFEE
2023-04-13T11:04:46Z #raku <patrickb> Nemokosch: v36 only contains the fix for updating ARM MacOS. But since the code for the update process is run in the installed version and not in the new version one needs to do this one update manually.
2023-04-13T11:54:04Z #raku <Voldenet> Nemokosch: in fact I wonder why Positional role isn't iterable, which is a lot wider than Blob (and is supported by Blob)
bisectable6 Nemokosch, Output on all releases: gist.github.com/2f6230393d0b914f11...dfc5b36278 09:03
Nemokosch, Bisecting by output (old=2016.02 new=2016.03) because on both starting points the exit code is 1
Nemokosch, bisect log: gist.github.com/b81e5e9d52c6ecd922...1ade6716b0
Nemokosch, (2016-03-14) github.com/rakudo/rakudo/commit/42...1294ecddc1
Nemokosch, Output on all releases and bisected commits: gist.github.com/87a454b7069d68b2be...9bb976df51
Nemokosch docs.raku.org/language/operators.h..._operators how is this supposed to work? 09:04
The example actually just yields an empty all junction 09:05
lizmat notable6: weekly 10:21
notable6 lizmat, 1 note: 2023-04-01T14:13:25Z <lizmat>: gist.github.com/FCO/def7e030c05d72...c4b8fce0e4
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2023-04-17T10:21:58Z”
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/04/17/2023-...udent-win/ 10:26
Geth rakudo/main: f31a6d56dc | (Elizabeth Mattijsen)++ | 3 files
Move the fix to Range.Bool to 6.e

There appears to be modules in the ecosystem that depend on the old behaviour (0..-1).Bool returning True, when it should be False. So make this corrected behaviour part of 6.e		 11:21
roast: e196a929ec | (Elizabeth Mattijsen)++ | S02-types/range.t
Mark tests that need 6.e as todo
lizmat jdv ^^ 11:23
afk& 11:47
|Tux| Rakudo v2023.02-328-gf31a6d56d (v6.d) on MoarVM 2023.02-3-g6adfc376c
csv-ip5xs0.904 - 1.016
csv-ip5xs-205.467 - 5.673
csv-parser3.677 - 3.746
csv-test-xs-200.397 - 0.424
test6.418 - 6.576
test-t1.582 - 1.724
test-t --race0.981 - 1.188
test-t-2020.695 - 21.738
test-t-20 --race6.428 - 6.846
 11:51
Hmm. I'm not even working on the box currently
nine T-30 min on the Starship launch for those who are interested! 12:50
And it's a scrub 13:13
jdv lizmat: thanks 13:48
i guess friday is a go for release, so far 13:49
[Coke] jdv++ 14:35
releasable6 Next release in ≈4 days and ≈3 hours. 1 blocker. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 15:00
Nemokosch m: say Rakudo::Metaops.MapperForOp(&[+]) 16:18
Raku eval -> \list { #`(Block|4656272394000) ... }
Nemokosch so this does work
github.com/rakudo/rakudo/blob/f31a...ps.pm6#L86
I'm trying to trace down the calls being made 16:19
m: say &[+].associative
Raku eval Exit code: 1 No such method 'associative' for invocant of type 'Sub+{is-pure}+{Precedence}' in block <unit> at main.raku line 1
Nemokosch how can it find that when invoking that method but not here on its own?
damn, wrong example: &[+] actually has a preset value in the hash 16:39
but the behavior is the same for all operators
m: say &[^].associative
Raku eval Exit code: 1 No such method 'associative' for invocant of type 'Sub+{is-pure}+{Precedence}' in block <unit> at main.raku line 1
Nemokosch m: say Rakudo::Metaops.MapperForOp(&[^])
Raku eval -> \list { #`(Block|4814984857432) ... }
lizmat m: =head1 E<zzz> 17:45
camelia Potential difficulties:
"zzz" is not a valid HTML5 entity.
at <tmp>:1
------> =head1 E<zzz>⏏<EOL>
"zzz" is not a valid HTML5 entity.
at <tmp>:1
------> =head1 E<zzz>⏏<EOL>
"zzz" is not a vali…
lizmat three for the price of one!
Nemokosch so the way I understand it, reduction makes no conceptual sense for list associative operators 19:26
and if && is really list associative, its sub form should have infix:<&&> (1, 2, 3, 4) return 4, not the list again 19:27
m: say infix:<&&> (1, 2, 3, 4)
Raku eval (1 2 3 4)
Nemokosch github.com/rakudo/rakudo/issues/5227
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 20:39

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!