[Coke] ⏳ 1382 out of 2288 modules processed (60.4%) 05:14
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
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
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
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
[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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!