Geth rakudo/main: 0d2ab24521 | (Stefan Seifert)++ | 2 files
RakuAST: fix doc-declarator tests after Subset API change
 08:52
nine I don't think I want to fix the rest of t/spec/S12-subset/subtypes.rakudo.moar as that's the bizarre error I posted yesterday and that's clearly also in the old frontend. 09:18
One way to get that test file to pass is to simply remove the Seq:D multi candidates for is-deeply - which are note even getting called. 09:21
Oh, and I just remembered that we've had another controversial test that even carried a comment saying that side effects of where clauses are not supported. Well the subset tests do rely on such side-effects. 09:23
It *is* the exact same situation as the other test. Problems are caused by BEGIN time execution of code that modifies lexical variables outside that code. E.g.: 09:27
m: my $foo; sub foo() { $foo++ }; BEGIN foo; say $foo; foo; foo; say $foo;
camelia 1
1
nine The BEGIN time execution in the subset case is in the compile time check for whether there's a matching multi candidate for the later is-deeply call. 09:28
The test file does pass if I remove that check.
Geth rakudo/main: dfa806e6d7 | (Stefan Seifert)++ | src/Raku/ast/call.rakumod
RakuAST: avoid compile time type comparisons with subsets

Type checks involving subsets can have side-effects (i.e. the code in the subset's where clause may). Doing such checks at compile time may therefore lead to strange problems like the mere presence of some code further down the source code file screwing up an earlier type check. We already avoided such checks in other places and now we also do so in the multi dispatch compile time check.		 09:48
nine Ah, well, I fixed it after all
Though I still say that the test code is broken. 09:49
That's now 1299
JimmyZhuo nine: 'sub f(Int $, int @a) { }(1,"3");' vs 'sub f(Int $, int @a) { }; f(1,"3");' , they are different ast, and seems have to write type check system, is rw check, args nums check etc.. 10:55
nine JimmyZhuo: not sure what you're asking 11:09
lizmat notable6: weekly 11:14
notable6 lizmat, 3 notes: gist.github.com/fc4041f597b93f0629...1ed73719d7
lizmat notable6: weekly reset 11:18
notable6 lizmat, Moved existing notes to “weekly_2025-03-25T11:18:54Z”
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/03/25/2025-...n-rakuast/ 11:34
[Coke] (*@#$ 11:36
So the command in moarvm releng to generate the tar file as written generates an error for me. (but this time did not generate the bad times on the files) - I used the 030 instead of the 03 in the command and it worked *without* error... except it generated a folder with the name 030 instead of 03, which caused the issue in the rakudo/star bug opened this morning. 11:37
This is *just* an issue with the release tar ball. It is NOT an issue with git repo itself. Is it safe to replace that tarball? Or can I add a .01 *tarball* but not release? Or do I need to do a full 2025.03.1 release? 11:38
Apologies, team. :|
lizmat patrickb nine might have ideas about that 11:39
[Coke] Excellent. I have calls for a few hours this morning and will fix afternoon my time.
I feel like silently replacing a release on github with a new file sounds bad when I say it out loud. :) 11:40
nine Trust your guts. 11:43
Releases are about trust and trust requires transparency.
Geth rakudo/main: 4 commits pushed by (Stefan Seifert)++ 12:09
nine Finally 1300
JimmyZhuo nine: the second one type check codes are in RakuAST::Call::Name, the first one seems that it can't use these type check codes in RakuAST::Call::Name, have to write another code about type check etc in the RakuAST::ApplyInfix
lizmat nine++ 12:10
nine JimmyZhuo: ah, yes, that's correct. RakuAST::Call::Name really is a short-cut for ApplyInfix(Term::Name, Call). Sadly that means some code has to be duplicated 12:11
patrickb I think having a .1 tarball without a release will cause issues of some sort. Filename and content won't match up. I'd say either a full release, or fix up the tarball. 12:18
JimmyZhuo the type check system has a lot of space to improve with RakuAST(is rw, slurpy, named, etc), and there may be some refactor in the future by someone who knows the rakudo well enough. sometime I think it's too early to add some ugly check in the ast just for pass more test, and the roast has not
enough tests for the type check.
most move these type check from runtime or bootstrap.nqp to ast 12:19
to check time 12:21
nine JimmyZhuo: I agree. Nevertheless, we need a passing roast to get a reliable regression test suite. With that it's much easier to improve compile time checks, refactor, etc. 12:23
JimmyZhuo agreed
[Coke] patrickb: fixing the tarball is the easiest surgery to do. 12:51
If you don't see an issue with that, I'll do that. AND add a Readme.md as a release file that explains what happens with a link to the issue on rakudo/star
tbrowder hi, i've been using the log routine again and wonder why we don't have the 'ln' routine. i know routine 'log(x)' is really log_e x, but it seems awkward to me. 12:55
i think, for olld ppl and noobs, addin the explicit 'ln' routine is the roght thing to do 12:57
*ignore typos pls
lizmat m: my %h := :{ }; %h<a>.push: 42; dd %h 13:17
camelia No such method 'push' for invocant of type 'Mu'. Did you mean 'put'?
in block <unit> at <tmp> line 1
lizmat meh
m: my %h{Mu}; %h<a>.push: 42; dd %h
camelia Any = (my Any %{Mu} = :a($[42]))
lizmat aka: one object hash is not like another 13:18
Geth rakudo/main: 8f8b95866f | (Elizabeth Mattijsen)++ | src/core.c/Hash.rakumod
Make the :{ } object hash syntax be like my %h{Mu}

Before this commit, the :{ } object hash syntax would create containers with the default value of Mu. This caused things like:
   my %h := : { }
   %h<a>.push(42)
... (9 more lines)		 13:23
rakudo/main: 998cde58a7 | (Elizabeth Mattijsen)++ | 2 files
Make QuantHashes return proper object hash for .Hash

Commit bc05703131b66716080 added the possibility to easily create a proper object hash		 13:26
rakudo/main: bcdbbdd8bc | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Make .classify/.categorize return proper object hashes

Commit bc05703131b66716080 made this possible.
This breaks a number of .classify/.categorize spectest that are checking for improperly constructed object hashes. A fix for these tests will shortly follow		 13:28
roast: 0afb93d0f0 | (Elizabeth Mattijsen)++ | 2 files
Fix .classify/.categorize tests

These were checking for improperly constructed object hashes.
Since github.com/rakudo/rakudo/commit/bcdbbdd8bc these are now correctly constructed. Use the :{ } object hash syntax to create the expected values, and thus make it ready for any other possible future changes to object hashes		 13:30
lizmat nine: looks like we lost t/12-rakuast/subset.rakutest ? 13:37
so: should we move all roast files with "use experimental" to the rakudo repo or not? 13:39
I would be in favor of that
[Coke] +1 13:45
lizmat actually, in quite a few cases we'd just need to move some tests 13:46
gist.github.com/lizmat/34dc9b0e795...83d3377260 # files in question 13:47
afk for a few hours& 13:48
[Coke] one potential "solution" - move everything into an experimental folder and remove them from the list of files to run? 14:19
liztormato [Coke]: in quite a few cases macro tests are just a few of the tests in a file 14:39
[Coke] WHERE IS THE NQP TARBALL? 15:09
(sigh. Bad Coke) 15:10
Fixing that as well. 15:11
regenerating the tar.gz file? no error. 15:13
[Coke] github.com/MoarVM/MoarVM/releases/tag/2025.03 fixed. Added notes in the release info 15:20
I also should do a session capture when I do the release so I can say "yes, see, I *did* run this" and have backup. :) 15:23
[Coke] github.com/Raku/nqp/releases/tag/2025.03 15:28
so that was supposed to be created by github-release.p6, according to the docs. 15:29
that step also fails regularly because it can't upload files, so I probably ignored a failure about nqp that I shouldn't have.
updated github.com/rakudo/star/issues/209 15:30
Geth rakudo/main: 8a3933813e | (Will Coleda)++ | docs/release_guide.pod
Slight clarification to RELENG
 15:38
[Coke] whateverable question - I don't see any config that ties an irc bot to an executable in whateverable's xbin/ directory - is it really just "the name of the xbin file" that makes a bot? 15:40
(trying to figure out if I can temporarily add a bot with lots of extra debug output.) 15:41
[Coke] I'm going to make a change to the releaseable6 script itself and see if I can debug this issue that way. It's output will change slightly, but I will revert all debug output shortly. 15:48
Geth whateverable/main: 72768c708f | (Will Coleda)++ | xbin/Releasable.p6
Add debug output
 15:50
[Coke] (as I recall, that commit should trigger a restart of the bot, we'll see)
Geth whateverable/main: 70044973e7 | (Will Coleda)++ | xbin/Releasable.p6
add debug output
 15:52
Geth rakudo/main: eb5620f248 | (Stefan Seifert)++ | 5 files
RakuAST: fix role parameters not found in where clause in role signature

We only declared lexicals for role parameters after entering the role body. That's too late when those parameters are referenced from within the role's signature. We previously didn't declare those lexicals on parse because the resolver was still in the role's outer scope. As a workaround we declared those lexicals manually after entering the role's ... (9 more lines)		 16:08
nine 1301
Geth rakudo/main: 727b7281aa | (Stefan Seifert)++ | src/Raku/ast/package.rakumod
RakuAST: fix declarations from role signatures getting lost

Since we now enter the package's lexical scope for parsing a role's signature, it could now happen that declarations from the signature got put onto the package's scope, which does not actually generate any code.
Push those declarations out to the package's outer scope.
Fixes: role Foo[R = role { method foo() { } }] { }
[Coke] releasable6: status 16:42
releasable6 [Coke], Next release in ≈25 days and ≈2 hours. There are no known blockers. 0 out of 384 commits logged (VERSION: $version) (ACTUAL COMMIT: $actual-commit-old)
[Coke], Details: gist.github.com/0fb20aa7716fa4ef63...e9e47d3c10
[Coke] ^^ Look, debug output. (*&^(*%#@$ :) 16:43
Geth whateverable/main: c9201b54ad | (Will Coleda)++ | xbin/Releasable.p6
add debug output
 16:44
[Coke] but that is nice to know that we can tweak the bots.
Geth rakudo: 0rir++ created pull request #5833:
Eliminate magic 37 in Instant class. Modify some comments		 17:05
rakudo/main: 921be1d83f | (Stefan Seifert)++ | 3 files
RakuAST: support is-traits with types and parameters

Fixes: has $.a is foo('bar')		 17:08
nine 1303
[Coke] github.com/Raku/whateverable/blob/...ble.p6#L97 - this appears to be search for two "new in"s in a row? but github.com/rakudo/rakudo/wiki/ChangeLog-Draft/ only ever has the single one near the top? 17:16
(and that line has been like that in releasable since it was created) 17:17
Geth whateverable/main: 519bc43cda | (Will Coleda)++ | xbin/Releasable.p6
add debug output
 17:22
[Coke] coverable6: help 17:25
coverable6 [Coke], Like this: coverable6: f583f22 grep=SETTING:: say ‘hello’; say ‘world’ # See wiki for more examples: github.com/Raku/whateverable/wiki/Coverable
Geth whateverable/main: d291613688 | (Will Coleda)++ | xbin/Releasable.p6
Revert "add debug output"

This reverts commit 519bc43cdacef3c8fb5dc65d6fdc84c738cde346.		 17:26
timo [Coke]: i think the (.*?) swallows up the entire section before the next "new in" 17:29
[Coke] so how does it match?
(because it is matching, it's not printing that error) 17:30
timo were you giving it the url in the command? i'm not sure where in the log i can see the command execution that you're refering to right now 17:33
it looks like it takes the contents of the changelog draft wiki page and puts it in front of the changelog from the repository, unless you give it a url in the command 17:34
Geth whateverable/main: 6b9032a34d | (Will Coleda)++ | xbin/Releasable.p6
add debug output
[Coke] ooof. OK. thank you 17:35
AND I FOUND ANOTHER BUG I DID
[Coke] *sigh* 17:35
[Coke] timo++ 17:38
Geth rakudo/main: 4c2fa9404a | (Will Coleda)++ | docs/ChangeLog
Actually add Changelog for 2025.03
 17:39
timo debugging an irc bot could be an interesting torture-test for the debugger UI
Geth whateverable/main: e4f2155e4c | (Will Coleda)++ | xbin/Releasable.p6
remove debug output
 17:40
timo although ... you can suspend and resume individual threads, but the "whenever" that handles all incoming messages probably is blocked while you're single-stepping through one of the irc-to-me methods ... 17:40
timo on the other hand, there is awaits and such in there, and it's not supposed to be "blocking" right 17:41
timo coke, dear, what did you do? :D 17:41
[Coke] That would be less heavy handed than what I'm doing now, for sure. 17:42
timo: I made 3 big (but not unrecoverable) mistakes doing the 2025.03 release.
THAT WE KNOW OF. :)
timo the debugging commandline thingie i've built oh-so-long-ago has some difficulties
the debugger built into comma is good, since it mostly hooks up the intellij-provided debugger UI and UX with the stuff it needs from moarvm 17:43
[Coke] releasable6: next 17:51
releasable6 [Coke], Next release in ≈25 days and ≈1 hour. There are no known blockers. 1 out of 34 commits logged
[Coke], Details: gist.github.com/268f6f51ac43c6ad00...27d3e35128
[Coke] There, much better. 17:52
releasable6: next 17:56
releasable6 [Coke], Next release in ≈25 days and ≈1 hour. There are no known blockers. 30 out of 34 commits logged
[Coke], Details: gist.github.com/3d06a209aee0680b89...106e1e3755
[Coke] there, got a headstart on the rakuast commits (already 23 of them) 17:57
Geth rakudo/main: 114dafe287 | (Elizabeth Mattijsen)++ | 2 files
Move experimental :pack tests to Rakudo

And activate a new directory t/13-experimental in "make test".
Also move these tests into a single file for convenience.		 18:07
roast: b83b952d7d | (Elizabeth Mattijsen)++ | 3 files
Move experimental :pack tests to Rakudo

As long as these are marked "experimental", they shouldn't be part of roast		 18:08
nine Aw man...even t/spec/S12-construction/roles-6e.t is failing due to BEGIN time disassociation with outer lexical variables 18:09
lizmat make @order a dynvar ? 18:10
I mean, the side-effects are used to test whether something ran or not 18:11
we're not testing whether the side-effects work
nine Given how often we run into this, I wonder if there is a way to just make these tests work. At least it would be a case of a single fix for multiple test files 18:12
lizmat hmmm... making it a dynvar didn't help
nine dynvars are also lexicals 18:13
t/spec/S14-roles/versioning.t expects classes to have generated POPULATE methods
Geth roast: 3d3e966b79 | (Elizabeth Mattijsen)++ | S12-coercion/coercion-return.t
Remove unneeded "use experimental :will-complain"

And also remove all trailing whitespace		 18:17
nine lizmat: t/spec/S26-documentation/block-leading-user-format.t fails because with RakuAST the output is missing "line 4" i.e. the last #line directive that's followed only by whitespace. Could you have a look? 18:22
lizmat will do
nine ++lizmat 18:23
Geth rakudo/main: f434c4bab4 | (Elizabeth Mattijsen)++ | t/13-experimental/will-complain.rakutest
Move experimental :will-complain tests to Rakudo
 18:24
nine What the heck is this now? @array[|| @indices] = 42,666
lizmat that's flattening syntax in 6.e 18:25
multidim flattening
Geth roast: f3819842d8 | (Elizabeth Mattijsen)++ | 2 files
Move experimental :will-complain tests to Rakudo

As long as these are marked "experimental", they shouldn't be part of roast		 18:26
lizmat nine: github.com/Raku/problem-solving/issues/287 18:27
nine What does it do?
lizmat m: use v6.*; my @a = 1,2,3; my %h; %h{||@a} = 42; dd %h 18:29
camelia {"1" => ${"2" => ${"3" => 42}}}
lizmat actually, the opposite of flattening :-)
I misremembered
it codegens to HyperWhatever as the 2nd arg to postcircumfix { } 18:30
nine I don't find any such thing in the grammar
lizmat see src/core.e/hash_hyperslice.rakumod
nine There's also no prefix:<||> there? 18:31
lizmat fwiw, my recollection is that the old grammar already supported it, but the postcircumfix candidates didn't know what to do with it 18:34
nine m: use v6.e.PREVIEW; say [[1,2,3][4,5,6]][||(0,0)]' 18:35
camelia ===SORRY!=== Error while compiling <tmp>
Two terms in a row
at <tmp>:1
------> e.PREVIEW; say [[1,2,3][4,5,6]][||(0,0)]<HERE>'
expecting any of:
infix
infix stopper
postfix
statement end
st…
nine m: use v6.e.PREVIEW; say [[1,2,3][4,5,6]][||(0,0)] 18:36
camelia (Any)
nine Hm....looks like I still don't understand what this is supposed to do
lizmat m: use v6.*; my @a = 1,2,3; my %h; %h{||@a} = 42; dd %h
camelia {"1" => ${"2" => ${"3" => 42}}}
lizmat take the indices and use them as keys into a nested hash 18:37
nine But the failing test is about arrays
lizmat m: use v6.*; my @a = 1,2,3; my @b; @b[||@a] = 42; dd @b 18:39
camelia [Any, [Any, Any, [Any, Any, Any, 42]]]
nine m: use v6.e.PREVIEW; say my @a = [[1,2,3][4,5,6]]; @a[||(0,0)] = 69; say @a[||(0,0)] 18:41
camelia [(Any) (Any) (Any)]
69
nine m: use v6.e.PREVIEW; say my @a = [[1,2,3][4,5,6]]; @a[||(0,0)] = 69; say @a
camelia [(Any) (Any) (Any)]
[[69] (Any) (Any)]
nine m: use v6.e.PREVIEW; my @a = [[1,2,3][4,5,6]]; say @a; @a[||(0,0)] = 69; say @a 18:42
camelia [(Any) (Any) (Any)]
[[69] (Any) (Any)]
nine m: use v6.e.PREVIEW; say [[1,2,3], [4,5,6]][||(0,0)]
camelia 1
nine LOL what a stupid mistake on my part :)
Found it in the git log. It parses as two slip operators but then gets post-processed in the actions 18:45
lizmat that feels hacky 18:46
nine A very Hollywood thing to do: "We'll fix it in post!" 18:47
lizmat indeed
Geth roast: 50011a6efe | (Elizabeth Mattijsen)++ | integration/99problems-41-to-50.t
Remove use of "is cached"

It's not material to the testing that is done on the algorithm, and performance-wise it's not noticeable. Remove it since it is an experimental feature that shouldn't be tested on roast		 18:56
rakudo/main: b43527a6b8 | (Elizabeth Mattijsen)++ | t/13-experimental/is-cached.rakutest
Move experimental :cached tests to Rakudo
 19:02
lizmat o 19:04
Geth roast: 9b41ab3507 | (Elizabeth Mattijsen)++ | 2 files
Move experimental :cached tests to Rakudo

As long as these are marked "experimental", they shouldn't be part of roast
rakudo/main: ab34d10801 | (Elizabeth Mattijsen)++ | 2 files
Port the ":cached" precompilation test from roast
 19:26
roast: 6336804343 | (Elizabeth Mattijsen)++ | 2 files
Remove "is cached" precomilation test

As long as these are marked "experimental", they shouldn't be part of roast		 19:28
rakudo/main: fd069d6685 | (Elizabeth Mattijsen)++ | t/13-experimental/pack.rakutest
Port :pack Buf test from roast
 19:32
roast: b158c5f19c | (Elizabeth Mattijsen)++ | S03-operators/buf.t
Remove "experimental :pack" test

As long as these are marked "experimental", they shouldn't be part of roast		 19:33
rakudo/main: 067236b320 | (Elizabeth Mattijsen)++ | t/13-experimental/pack.rakutest
Only need to mention experimental :pack once

Copy pasto from the port from roast		 19:35
rakudo/main: 3c7bd84917 | (Elizabeth Mattijsen)++ | t/13-experimental/pack.rakutest
Port :pack error throwing tests from roast
 19:39
roast: c6d9d67a05 | (Elizabeth Mattijsen)++ | S32-exceptions/misc2.t
Remove "experimental :pack" throwing tests

As long as these are marked "experimental", they shouldn't be part of roast		 19:40
rakudo/main: 42557e38b5 | (Elizabeth Mattijsen)++ | t/13-experimental/pack.rakutest
Port :pack visibility test from roast
 19:43
roast: a92f20bc9f | (Elizabeth Mattijsen)++ | S32-exceptions/misc2.t
Remove "experimental :pack" visibility test

As long as these are marked "experimental", they shouldn't be part of roast		 19:44
[Coke] releasable6: next 19:49
releasable6 [Coke], Next release in ≈24 days and ≈23 hours. There are no known blockers. 35 out of 41 commits logged
[Coke], Details: gist.github.com/4ce07487498ad3d7a1...7c5d45312c
lizmat nine: re t/spec/S26-documentation/block-leading-user-format.t I will need to sleep over that: not entirely sure it's an implementation or a test issue yet 19:52
I think there are now only experimental :macros tests in roast now (no other "use experimental" ones 19:57
which I will handle tomorrow as well
afk&
Geth rakudo/main: ba9a70b162 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
RakuAST: fix BEGIN time disassociation with outer lexical variables

When code compiled at BEGIN time references variables declared in outer scopes, those scopes don't even exist yet when we compile and maybe run that code. Thus we replaced variable access with whatever compile time value we could find. This worked better than one would expect since even normal variables have compile time values, namely their containers. ... (13 more lines)		 21:56
nine 1305 :)
Realized how to fix it when I was on my rower :)
Currently covers only role bodies as only those get the benefit of LexicalFixup, but that should be easy to generalize. 21:57
timo man, i wonder what kind of fixes you could come up with if you upgraded from rower to rowest 23:14

Powered by Cro and the Raku® Programming Language.

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

Thank you!