🦋 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.
00:16 sena_kun left 03:16 guifa left 04:24 guifa joined
[Coke] ⏳ 1382 out of 2288 modules processed (60.4%) 05:14
05:52 guifa left 07:22 [Coke] left
Geth rakudo/main: 91e767b267 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix thunked once

The once statement prefix implicitly declares a state variable. If the expression was thunked this variable would not get added to the thunk's declarations but instead to the outer scope. The p6stateinit op would then not run in a frame that was marked as having state variables.		 07:39
nine And that's 1063. But I fear that this is not the last we hear of this. I don't like the fix. It's more of a workaround. But the problem it solves is so stupid, I can't find the motivation to spend more time on it. 07:40
It fixes once { say "hi" } for 1, 2; # Why on earth would you put a loop modifier on a once statement? It's like saying "loop this! But actually, you know, now that I'm thinking about it, maybe I'd rather you don't". That doesn't sound like sensible code. 07:42
07:49 [Coke] joined
ab5tract nine: is this behavior in roast? :O 09:10
I agree that supporting this syntax just doesn't make a whole lot of sense. But I guess I do see the utility in some other statement mods. 09:14
If the for modifier case is not explicitly engraved in roast, I would support emitting a sorry for such a combination 09:15
m: for ^5 { once { say "seen even" } if ($_+1) %% 2; say $_ } 09:20
camelia 0
1
2
3
4
ab5tract m: Q| for ^5 { once { say "seen even" } if ($_+1) %% 2; say $_ } |.AST.EVAL
camelia 0
1
2
3
4
ab5tract nine: is this supposed to work? 09:23
m: Q| for ^5 { once { say "seen the truth" } if $_; say $_ } |.AST.EVAL
camelia 0
1
2
3
4
10:25 sena_kun joined
nine This is from a roast test 10:33
m: @ = (L1: while True { while True { say "run"; last L1 } }); 10:34
camelia run
nine m: @ = (while True { while True { say "run"; last } });
camelia ( no output )
nine Why does the explicit loop label make that supposedly lazy loop run? 10:35
lizmat perhaps a git blame on the test could tell us something ? 10:37
nine Neither the commit that added the test github.com/raku/roast/commit/53d33...1a2d3318ca nor the commit that fixed the thing that the test is actually about github.com/rakudo/rakudo/pull/3623...9d926b91c7 nor the bug report github.com/rakudo/rakudo/issues/3622 mention anything about laziness 10:41
I dare say that spec tests is clearly written against an implementation and is not so much a specification. Not least because the comment hints in that same direction. 10:42
bartolin_: can you shine any light on this?
The design docs say "lazy loops can be indicated by putting the loop in parens or brackets:" with examples (... if COND for LIST), [for LIST { ... }] and (loop { ... }) or explicitly with the "lazy" prefix 10:54
lizmat TIL 11:05
11:54 lizmat left 12:18 lizmat joined 12:28 lizmat_ joined 12:30 lizmat left 12:37 sena_kun left 12:45 lizmat_ left, lizmat joined 12:54 sena_kun joined
Geth rakudo/main: d244790beb | (Stefan Seifert)++ | 2 files
RakuAST: better way to detect compile-time values
 13:32
rakudo/main: 8e095d0489 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: support lazy loops with constant conditions
rakudo/main: 318b123172 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: support labels on lazy infinite loops
[Coke] dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.17618 to fit - that's new 15:33
(from biln) 15:34
github.com/rakudo/rakudo/issues/5783 has 9 failures bisected to 5 commits 15:40
gist.github.com/coke/e04258b645f2b...1cf48c4e58 has the full output 15:41
Geth rakudo/main: 62c83711df | (Stefan Seifert)++ | tools/templates/NQP_REVISION
Bump NQP for repeat-loop fix
 16:00
nqp/main: c1e89a23ee | (Stefan Seifert)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Fix missing register initialization in repeat loops

This is finally a proper fix replacing the workaround introduced in commit 2f2ac2f0665980ef54e2bd8a634ad5ff0a590b4a.
The problem was that for loops for which we need to pass the condition to the block (think while $cond -> $foo { }) we only compile the ... (10 more lines)
nine Turns out fixing a 6 year old bug brings us to 1164 :)
lizmat nice! 16:47
timo nice, indeed 18:25
lizmat [Coke]: looking at the blin run now 19:15
19:22 rakkable left, rakkable joined 19:23 rakkable left, rakkable joined
[Coke] lizmat++ hopefully some real issues and not more flappers 19:46
lizmat yeah real issues 19:55
[Coke] \o/ I guess? :) 20:01
lizmat well, so far naughty modules 20:05
3 done so far 20:32
[Coke]: status update: basically 2 issues remain, one with its cause in MoarVM most likely, and one in coercion cause by "item" change 21:04
the former is probably easily reverted and/or fixed
looking with vrurg at the coercion one
Geth rakudo/main: d82d91e853 | (Elizabeth Mattijsen)++ | src/core.c/Iterable.rakumod
Update comment

Iterable doesn't have a dedicated .item method anymore		 21:11
22:16 sena_kun left
Geth nqp/main: 6d98d8da02 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM for syn codepoint fix, Timo++
 22:25
rakudo/main: ac06359c47 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP for syn codepoint fix, Timo++
 22:36
lizmat afk& 22:38
22:39 lizmat_ joined 22:43 lizmat left 22:57 guifa joined 23:39 lizmat_ left 23:40 lizmat joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!