|
🦋 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. |
|||
|
06:56
leont left
06:57
leont joined
06:58
camelia left
07:43
sena_kun joined
07:49
camelia joined
|
|||
| nine | I wonder if throws-like should pass if we're looking for an X::Comp exception and don't get that directly but instead get an X::Comp::Group exception that contains the one we're looking for. | 07:54 | |
| On the one hand, changing Test's semantics has wide reaching implications, considering that it's probably used by just about all Raku code out there. On the other hand, I doubt that there are many places outside of Rakudo where tests expect compilation errors to occur. | 07:59 | ||
| And even where they do, it might actually be helpful to be more lenient regarding groups as we are getting better at reporting all the compile time errors instead of just the first one. | 08:00 | ||
| lizmat | that's problem resolving stuff :-) | 08:15 | |
| nine | I think I'll just go for it | 08:26 | |
|
08:30
camelia left
|
|||
| Geth | rakudo/main: 43af30aab0 | (Stefan Seifert)++ | lib/Test.rakumod Have throws-like if the expected compile time exception is part of a group The compiler will throw an X::Comp::Group exception when there are multiple compile time problems. With time, the compiler gets better and will report more problems and will also get better at reporting those problems at the end of compilation instead of right away. ... (13 more lines) |
08:44 | |
| rakudo/main: 09deed5de4 | (Stefan Seifert)++ | 2 files RakuAST: ensure we always report usage of placeholders in pointy blocks Pointy blocks always have an explicit signature, even if the block does not take any parameters at all. Thus pointy blocks must never use any placeholder parameters. |
|||
|
08:55
camelia joined
|
|||
| Geth | rakudo/main: 99c530a048 | (Stefan Seifert)++ | src/Raku/Grammar.nqp RakuAST: make YOU_ARE_HERE reserved syntax YOU_ARE_HERE is a marker that must only be used by the setting. |
08:59 | |
| nine | 1087 | ||
| lizmat | I see 1086: t/spec/S19-command-line-options/05-delimited-options.rakudo.moar fails for me, but not when run as a single file | 09:16 | |
| nine | repeatedly? | 09:17 | |
| lizmat | yes... I wonder if this is an OS difference | ||
| "Could not open ++FOO. Failed to stat file: no such file or directory\n" | 09:18 | ||
| nine | I see t/spec/S29-os/system.t failing somewhat reliably when running with my usual TEST_JOBS=40 but succeed when reducing that to 16 | ||
| That file contains only a single test and that's TODOed | |||
| lizmat | yeah, that's the odd thing about it | 09:19 | |
| perhaps we should just delete that file | |||
|
09:19
sena_kun left
|
|||
| nine | > rakudo '++FOO' '--bar' '++/FOO' '-e' 'say %*OPTS<FOO>' | 09:20 | |
| Could not open ++FOO. Failed to stat file: no such file or directory | |||
| Let's delete that test. It seems quite rakudo specific anyway | 09:21 | ||
| lizmat | S19 mentions "New C<++> metasyntax allows options to be passed through to subsystems" | ||
| so looks like a NYI indeed, maybe it's a WNBI ? | 09:22 | ||
| nine | probably | ||
| Geth | roast: ae61355101 | (Elizabeth Mattijsen)++ | S19-command-line-options/05-delimited-options.t Remove dodgy test that will probably be never implemented |
09:24 | |
| lizmat | notable6: weekly | 13:31 | |
| notable6 | lizmat, 1 note: 2024-08-12T12:56:32Z <lizmat>: dev.to/lizmat/the-end-of-p6c-2868 | ||
| lizmat | notable6: weekly reset | ||
| notable6 | lizmat, Moved existing notes to “weekly_2024-08-12T13:31:57Z” | ||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/08/12/2024-...6c-ending/ | 13:38 | |
| Geth | rakudo/main: 6e253ef59f | (Stefan Seifert)++ | 2 files RakuAST: fix regex thunks not getting block thunked Some operators require their operands to be block thunked, i.e. not just turned into code objects but turned into full code blocks with their own lexical scopes. While regex thunks are code objects, they do not produce their own lexical scope. Thus even though they are already a kind of thunk, we need to wrap them again with BlockThunks. |
14:52 | |
| rakudo/main: e6c6f5c080 | (Stefan Seifert)++ | src/Raku/ast/scoping.rakumod RakuAST: fixes declarations from thunked code objects missing Even code objects can get (block)thunked, so we still have to check whether they are expressions and add thunk declarations to the scope if they have them. Fixes (S/a/A/ andthen S/b/B/ given "ab") (together with the previous commit) |
|||
| nine | m: my @seen; for any 1 { dd .^name } | 15:20 | |
| camelia | "Junction" | ||
| nine | Ok, that's just what the spec test expects, too. | 15:21 | |
| m: my @seen; for any 1 { dd .^name; LAST { } } | |||
| camelia | "Int" | ||
| nine | trolollol | ||
| So this specced behavior actually depends on an optimization of for loops with "simple" bodies. | 15:24 | ||
| timo | this would be a surprise for any 1 | 15:28 | |
| Geth | rakudo/fix-looping-over-junction: fde5d87fe9 | (Stefan Seifert)++ | 3 files Fix iterating over Junction with non-simple loop bodies say .^name for any 1; should print "Junction" as we are iterating over a single Junction item. This already worked but only because of an optimization for loop bodies without any phasers or other complications. for any 1 { say .^name; LAST { } } printed "Int" indicating that the loop body got auto-threaded. That's because Junction objects don't ... (6 more lines) |
17:59 | |
| rakudo: niner++ created pull request #5620: Fix iterating over Junction with non-simple loop bodies |
|||
| nine | I'd like to get a review for ^^^ before pushing to main. Question really is "is it worth the hassle?" | 18:00 | |
|
18:39
sena_kun joined
|
|||
| ab5tract | I’ll have to double check because it’s been a while and I’m not at a computer, but I think we might have moved past using p6setfirstflag for FIRST… but I might have a wire crossed and it was a different extop / phaser combo that was, erm, phased out | 21:05 | |