🦋 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:14 MasterDuke joined
MasterDuke what tests did 4d4ac9fce3103821d25d1678154b6a29018ad7a7 break? 00:14
tellable6 2025-04-05T07:09:54Z #raku <librasteve> MAsterDuke: thanks - now merged
00:35 MasterDuke left
[Coke] ugexe: docs.raku.org/type/IO/Socket/Async...hod_listen describes how. I'll fix the roast test 00:44
actually, I think we still need the random port for test #2. 00:47
it tries to connect before the server runs to verify the failure.
ugexe wouldnt you just use the port from the first test? i'm presuming the first listening socket will be closed and thus the port should be free 00:49
i guess that doesn't take the host/address into account
[Coke] right, it's two different hosts. 00:53
just like the first hostname is unlikely to match, I think we need a similar port choice. 00:54
then for the "happy" path we can do it the right way.
this is a little harder, will report back tomorrow 01:34
01:37 RakuIRCLogger left
jdv faster 01:39
04:23 lizmat_ left 04:43 guifa left 06:07 lizmat joined
Geth nqp/main: a890b03cf0 | (Stefan Seifert)++ | src/vm/moar/QAST/QASTCompilerMAST.nqp
Ensure we declare our dynamics even when there's no compunit

Naughty users (like Rakudo's ProxyReaderFactory dispatch helper) might compile a block without enclosing it in a compunit. In that case we wouldn't declare the %*BLOCKS_DONE and $*BLOCK dynamic variables which may lead to them getting auto-vivified in the package (and exported) and may pick up confusing values from outside. Better declare them in a place that's harder to avoid.		 07:19
rakudo/main: 690370ad50 | (Stefan Seifert)++ | tools/templates/NQP_REVISION
Bump NQP to get a fix for misbehaving compiler
 07:22
rakudo/main: 00aa9b8f38 | (Stefan Seifert)++ | t/packages/Test-Helpers/lib/Test/Helpers/QAST.rakumod
RakuAST: fix tests failing when compiler doesn't have stage optimize
 07:29
ab5tract nine: looking at d47c8febdd817089f75602617051f40d296731c7 now 07:37
linkable6 (2023-11-05) github.com/rakudo/rakudo/commit/d47c8febdd RakuAST: Make multi subs check for re-declaration of signatures
ab5tract I'm a bit surprised that there is an issue, as it wasn't an issue when I added it
nine I don't see how t/02-rakudo/12-multi-revision-gated.t could have passed back then 07:38
Geth rakudo/main: 76951f3e6a | (Stefan Seifert)++ | t/08-performance/02-qast-rewrites.t
RakuAST: todo optimizer tests

Note that even some of the passing tests are wrong because they look for p6for which the RakuAST frontend doesn't generate ever.		 07:50
nqp/main: d9cf3a92ea | (Stefan Seifert)++ | 2 files
Reapply "Use correct typed accessors where able"

This reverts commit 703149cbb3d67fc73c0d2b879ab7009509aea01e.
07:53 sena_kun joined
nine Turns out that commit was innocent after all. The actual problem is a miscompile of the NativeCall module with RakuAST. In my test I simply forgot to clear .precomp, so even my test on non-RakuAST used the RakuAST compiled module. 08:02
Reverting that commit then triggered a recompile and that gave me fresh precomp files which looked liked it would have fixed the issue.
Geth rakudo/bootstrap-rakuast: 20 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/d...1f9915bcd0		 08:24
rakudo/main: 12 commits pushed by (Stefan Seifert)++
review: github.com/rakudo/rakudo/compare/7...8c5ef25c73		 08:28
08:29 sena_kun left
nine A bisect of the problem revealed the actual source which luckily already had a fix on the bootstrap branch. So I cherry picked all fixes from that branch that are clearly compatible with the non-RakuAST frontend 08:29
Geth rakudo/bootstrap-rakuast: 8 commits pushed by (Stefan Seifert)++ 08:31
08:45 finanalyst joined 08:54 sena_kun joined 10:03 donaldh joined 10:09 donaldh- joined
Geth rakudo/main: 52658b94e7 | (Stefan Seifert)++ | src/Raku/ast/statements.rakumod
RakuAST: fix bogus warnings about unused values in if statements with KEEP/UNDO phasers
 10:17
rakudo/main: ef3950464a | (Stefan Seifert)++ | t/05-messages/10-warnings.t
RakuAST: make warnings test more lenient

In the old frontend the optimizer collects warnings about unused values, groups them by message and appends the list of line numbers for each. All of this is manual code just dealing with message strings. The RakuAST frontend however builds an exception for each occurence and adds them to an X::Comp::Group which is arguably the more structured ... (6 more lines)
nine t/05-messages/10-warnings.t passes now
rakudo/main: f0e8b57168 | (Stefan Seifert)++ | t/05-messages/10-warnings.t
RakuAST: todo a macro test
10:23 donaldh left 10:26 donaldh- is now known as donaldh
Geth rakudo/main: 8d0fe4d4f7 | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: fix error trying to report keyword used as listop error
 10:42
rakudo/main: fc01dfd6fa | (Stefan Seifert)++ | src/Raku/ast/expressions.rakumod
RakuAST: complain about &function in a feed
 11:07
rakudo/main: edc7ae9701 | (Stefan Seifert)++ | src/Raku/Actions.nqp
RakuAST: throw appropriate exception for invalid language version
 11:20
rakudo/main: f59944b1bf | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: bring back suggestions for private method not found
 11:30
rakudo/main: cbb2eb1d0d | (Stefan Seifert)++ | src/Raku/Grammar.nqp
RakuAST: bring back specific messages for errors in declarations
 11:35
nine t/05-messages/01-errors.t passes now
lizmat nine: there are 2 "method apply-sink" in Raku/ast 12:06
and one of them is not accepting: :$okifnil
and it's causing t/12-rakuast/var.rakutest to break 12:07
should I just add a dummy :$okifnil to the one that hasn't got it, or is there something deeper afoot ?
nine Please don't
$okifnil is only for Expressions. If there's an error because of it, that means that a non-expression appears in a place where there must only be expressions 12:08
lizmat ok, I will research that avenue then :-)
nine See the various fixes where I turned things into terms
lizmat could be the test, haven't look at that yet
nine A Blockoid is certainly not an Expression, so the test is wrong 12:10
lizmat but a PointyBlock is, right? 12:11
nine yes 12:13
12:14 guifa joined
Geth rakudo/main: 726864bb4b | (Elizabeth Mattijsen)++ | t/12-rakuast/var.rakutest
RakuAST: fix fault RakuAST::Var test
 12:16
12:31 guifa left
Geth rakudo/main: 42197d93cc | (Stefan Seifert)++ | src/Raku/ast/signature.rakumod
RakuAST: fix order of post constraints on parameters

There's (error reporting) code that relies on a specific orders in which post constraints get added on a parameter. While this is horribly fragile, for now we just match the incidental order that the old frontend produces.		 12:37
nine At least this order is very clear as it's coming from a single place in the RakuAST code where it's spread around a lot in the old actions
Actions and grammar. It also depends on parse order.
lizmat: what do we do? A test is failing because it's expecting an X::Comp::AdHoc but it's getting an X::QuoteWords::Missing::Closer instead. 12:42
lizmat X::QuoteWords::Missing::Closer is more specific than just a BEGIN die 12:43
so I'd say, change the test to either just check for dying, or for the more specific error (provided it's not implementation dependent?) 12:44
nine Well you didn't change the old frontend to use the new exception type when you introduced it, so it would fail that test if I changed it.
The test also tests the message which we would lose if I just changed it to expect the code to die. 12:45
lizmat I have no active recollection from that :)
nine After all the point of the test *is* checking that message for being helpful on a parse error.
lizmat and the X::QuoteWords::Missing::Closer is more helpful, I gather > 12:46
?
nine It's exactly the same message. Just a more tightly typed exception.
12:46 JimmyZhuo joined
lizmat wouldn't then just testing for Exception and the message be a solution? 12:47
Geth rakudo/main: eac975fb91 | (Stefan Seifert)++ | t/05-messages/03-errors.t
RakuAST: defuse overly specific test

The RakuAST frontend throws a more tightly typed exception (with exactly the same message). As the important part is the message and to keep the old frontend passing the test also, reduce the constraint to just any exception. Expecting an AdHoc specifically doesn't make sense anyway as it's preventing us precicely from introducing a more targeted type.
  lizmat++ for the suggestion		 12:49
nine Good thing I asked you :) 12:50
lizmat hehe glad to have been of service :-)
notable6: weekly 12:53
notable6 lizmat, 3 notes: gist.github.com/efb989c42a8c09a60c...98d03b3a00
lizmat notable6: weekly reset 12:54
notable6 lizmat, Moved existing notes to “weekly_2025-04-08T12:54:08Z”
nine m: class Foo { method foo() { $^a } } 13:03
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variables (eg. $^a) cannot be used in a method.
Please specify an explicit signature, like method foo ($a) { ... }
at <tmp>:1
------> class Foo { method foo() { <HERE>$^a } }
nine Oh, ok, so placeholder variables cannot be used in a method? Good to know. Thanks for the clear message!
m: class Foo { method foo { $^a } }
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variables (eg. $^a) cannot be used in a method.
Please specify an explicit signature, like method foo ($a) { ... }
at <tmp>:1
------> class Foo { method foo { <HERE>$^a } }
nine Really, placeholders would be one of the first things I'd just remove from the language :) 13:04
There's so many exceptions to where they can be used anyway 13:05
lizmat m: class Foo { method foo { @_ } }
camelia ===SORRY!=== Error while compiling <tmp>
Placeholder variables (eg. @_) cannot be used in a method.
Please specify an explicit signature, like method foo (*@_) { ... }
at <tmp>:1
------> class Foo { method foo { <HERE>@_ } }
lizmat he
JimmyZhuo m: say { * * * }(2,5); 13:06
camelia ===SORRY!=== Error while compiling <tmp>
Malformed double closure; WhateverCode is already a closure without curlies, so either remove the curlies or use valid parameter syntax instead of *
at <tmp>:1
------> say { * * * }<HERE>(2,5);
expe…
lizmat notable6: weekly reset 13:09
notable6 lizmat, Moved existing notes to “weekly_2025-04-08T13:09:50Z”
JimmyZhuo looks like a lots of special rules makes it hard to optimize, to read, and torture the implementors? 13:10
Geth rakudo/main: d475334c9b | (Stefan Seifert)++ | src/Raku/ast/variable-declaration.rakumod
RakuAST: prohibit placeholders %_ in methods
 13:15
nine t/05-messages/03-errors.t passes now
lizmat hmmmm... not sure what to make of ssojet.com/escaping/regex-escaping-in-raku/ 13:18
similarly ssojet.com/encryption-decryption/r...8-in-raku/ 13:19
nine The words/information ratio and the wording itself suggests these articles being AI generated 13:20
lizmat yeah.... :-( 13:21
lizmat plonks ssojet 13:22
nine So I gave it a try and asked ChatGPT to "Please write an article about how to escape regex characters in Raku". The result is almost identical 13:23
lizmat thanks for the confirmation
13:35 donaldh left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/04/08/2025-14-diving/ 13:39
nine m: (:::[]) 13:43
camelia ===SORRY!=== Error while compiling <tmp>
No such symbol ':<>'
at <tmp>:1
------> (:::[]<HERE>)
nine I kinda doubt that an error message about ":<>" is more helpful here than the "Empty name lookup not possible as a constant" that RakuAST gives 13:44
lizmat yeah, it feels like one of those tests from the mists of time that used to crash the parser, and then got enshrined with a particular error message 13:46
rather than just testing that the parser lived
nine That's exactly what it is. On this particular one jnthn even wrote "My motivation to fix these things, or have them clutter RT, is
relatively low, fwiw." 13:47
Well the parser does die, just no longer with a "ResizablePMCArray​: index
out of bounds!" 13:48
lizmat suggest then replacing it with a lives-ok { q/(:::[])/.EVAL }
ah...
nine This code is so non-sensical, I don't even have a clue what the intended one could have been :)
lizmat fwiw, there appear to be 15 references to PMC still in roast 13:49
all in comments though, afaics
13:57 donaldh joined
lizmat afk for a few hours& 14:00
jdv is make test failing with and without rakuast for anyone else?
[Coke] Was for me, yes. 14:01
14:01 sena_kun left
[Coke] (yesterday, haven't tried the flurry of updates from today!) 14:01
jdv just wanted to make sure it wasn't something i did locally. ok.
14:02 sena_kun joined
lizmat aaah... it looks like .rakutest files are not getting fudged 14:04
if someone with knowledge about fudging could have a look at that, that would be great :-) 14:05
nine lizmat: there's no fudging in make test in general 14:07
It wouldn't make sense anyway since fudging exists to allow for different compiler implementations having different levels of language support. make test is for one specific compiler implementation 14:08
14:10 JimmyZhuo left
[Coke] nine - any thoughts on unTODOing roast tests that are passing (on master, and -errata?) 14:11
(or, as probably is the case, unfudging, haven't look at the files, only at the test results) 14:12
lizmat nine: fudging to handle #?rakudo skip I mean
e.g.: raku t/13-experimental/macros-opaque-ast.rakutest 14:13
fails and: make t/13-experimental/macros-opaque-ast.rakutest passes with # SKIPs
[Coke] the equivalent of rakudo skip in make test is probably wrapping it in a pod comment.
(if you're trying to avoid some compiler error) 14:14
jdv i unTODO'd a bunch not that long ago. it was too much noise. 14:16
14:17 leont left, leont joined 14:19 ab5tract left 14:20 ab5tract joined
Geth rakudo/main: f7369d34fb | (Elizabeth Mattijsen)++ | 3 files
Remove skipped macro tests

On the assumption that they won't get implemented anyway in that way, and because they are no longer fudged, produce errors otherwise		 14:21
rakudo/main: 0bf9e87e93 | (Elizabeth Mattijsen)++ | t/12-rakuast/xx-fixed-in-rakuast.rakutest
Todo a confusing test about the repl under RakuAST
 14:28
lizmat make test clean again under legacy grammar 14:29
afk for a few hours&
timo prepares a huge stackoverflow response to the hyper/race/gather question 14:41
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 15:12
nine t/05-messages/02-errors.t fixed now
That last one was way more effort than that test deserved
16:02 sena_kun left 16:07 sena_kun joined 16:30 zostay left, tbrowder left 16:31 zostay joined, tbrowder joined
timo stackoverflow.com/a/79562603/804005 my hyper/race/gather ... "extravaganza"? 16:35
16:42 guifa joined
Geth rakudo/main: 0957a8b73a | (Stefan Seifert)++ | 2 files
RakuAST: better fix for clobbered $_ in EVAL

With commit ede438efa8e83b66e4286ab1bdff1c236e7e95c3 we started declaring a $_ in an EVAL to stop the outer $_ from getting clobbered e.g. by an exception in a smartmatch and the resulting failure to reset
  $_ to the previous value. However this meant that an outer $_ was no
longer visible in an EVAL which broke other tests. ... (5 more lines)		 17:05
nine And t/12-rakuast/regex-substitution.rakutest is back with us
m: try 1 17:09
camelia WARNINGS for <tmp>:
Useless use of constant integer 1 in sink context (line 1)
donaldh I went to go and fix the missing 'Sigils' headline text on docs.raku.org/language/variables
nine m: try +"a"
camelia ( no output )
nine m: +"a"
camelia WARNINGS for <tmp>:
Useless use of "+" in expression "+\"a\"" in sink context (line 1)
Cannot convert string to number: base-10 number must begin with valid digits or '.' in '<HERE>a' (indicated by <HERE>)
in block <unit> at <tmp> line 1
donaldh But realise I don't know what this is trying to achieve: github.com/Raku/doc/blob/f157d1b8a...oc#L14-L15 17:10
nine Can someone explain to me why we don't warn about the useless +"a" when it's in a try but we do warn about the useless 1?
lizmat nine: couldn't we make that a compilation error now, rather than a worry ? 17:12
ah, missed the "inside a try"
donaldh I can't tell the intended goal from either the source or the generated HTML: gist.github.com/donaldh/e359feedb8...75f13b62de 17:14
17:43 finanalyst left
[Coke] basically the X<> syntax there going into the search index, so we can find those items even if there isn't a header specifically for them. 17:58
Were you looking at the HTML or the source first to ask that question? 18:00
Geth rakudo/main: 211641a42a | (Stefan Seifert)++ | src/Raku/ast/statementprefixes.rakumod
RakuAST: don't warn about unused values in try statements

A try is an indicator that an expression may be executed for side-effects.		 18:06
nine t/02-rakudo/repl.t passes 18:07
With that it looks like my grant is finally done :)
[Coke] \o/ 18:16
jdv woohoo 18:34
timo whoa 18:54
amazing :)
[Coke] releasable6: next 19:54
releasable6 [Coke], Next release in ≈10 days and ≈23 hours. 2 blockers. 228 out of 231 commits logged
[Coke], Details: gist.github.com/27b45e11551d42a3ff...f31bbb6f61
[Coke] one of those blockers is the blin run (wherein the bad commit was already reverted), and updates for roast tests, which include a bunch of passing TODOs, and github.com/Raku/roast/issues/872 19:55
that roast issue is basically a cherry pick (except there's a merge conflict) 19:56
so, no really coding required, just some git maintenance.
20:38 [Coke] left 20:53 finanalyst joined 20:56 [Coke] joined 22:10 guifa left
donaldh coke: I looked at the HTML first and got confused 22:23
I _think_ the fix is just to swap the two lines so the X<...> entries are before the =head1 22:26
Updated gist.github.com/donaldh/e359feedb8...75f13b62de seems to work. 22:27
22:50 finanalyst left 22:51 sena_kun left 22:55 lizmat left, 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!