[Coke] started blin run to ^^ 00:23
Haven't seen any text from the RSC for the cutover to AST on the release announcement. 01:21
maybe one who is not also a core dev could take a stab at it. 01:29
(maybe one who enthusiastically voted yes)
03:24 japhb left 05:04 vrurg_ joined 05:07 vrurg left 05:41 japhb joined 12:07 Geth left, Geth joined
Geth rakudo/main: 15a9a61551 | (Elizabeth Mattijsen)++ | 6.e-release-overview.md
Initial overview of changes since 6.d

This is really just the first iteration over all of the announce files in the doc directory since 2018.12 (the first post 6.d release)		 12:08
lizmat please PR if I missed anything important 12:19
[Coke]: gave the release announcement a stab 12:44
patrickb Ist the idea to have the big RakuAST & 6.e release this weekend? 14:13
If so, could we, for the sake of more preparedness, give it another month? If I followed correctly we only today or yesterday solved the last missing bits. I would guess a month of slack to try out the finished product would help a lot. (Can we do a beta release (doing the entire release process) instead?) I would guess there are quite a few "non core, but always latest release" people that 14:20
would potentially try out such a release. I kind of fear us doing "the big release" and then doing 3 point releases to fix up afterwards.
lizmat we will *only* make RAKUDO_RAKUAST=1 default this release, *not* go toward 6.e 14:23
patrickb (I absolutely don't want do downplay the effort ugexe, Coke, lizmat and all the others spent on polishing and reliability work! I did not miss all the blin runs that happened in the last weeks.)
lizmat use of RakuAST based grammar has been opt-in for quite a while now, the only thing that really changes is that it is now opt-out 14:24
you can opt-out by specifying RAKUDO_RAKUAST=0
so, there's an escape hatch for this that find problems 14:25
apogee_ntv I'm definitely finding some problems :D 14:26
Most seem small though
lizmat well, please make issues for them... if it turns out to be a blocker, then we can postpone 14:27
otherwise a fix will be in the next release, presumablu
*y
apogee_ntv I think they're mostly me problems where it was always wrong but rakuast is stricter about it.
patrickb Hmm. I'm not entirely opposed to a normal release, but I do like the idea of a beta release. (I'm pretty late to the party to propose something like this. I'm not offended at all should I be ignored simply because it's too late to propose something like that.) 14:30
lizmat yeah, RakuAST is stricter :-)
and noisier, e.g. with useless use worries that legacy just allowed 14:31
even fez had 2 of those, and App::Rak had one :-)
(and the worries were correct, fwiw) 14:34
apogee_ntv I have a lot of pod which have = in =item and wherever it fell on a new line it was breaking the =item. 14:35
ugexe i was thinking those useless use warnings were legit
apogee_ntv So like "=item foo = bar" is fine but "=item foo \n= bar" is not.
ugexe but i didnt really think much about them
the `my @a; @a[1] [=] ā9; dd @a` one at least 14:37
apogee_ntv m: say my Int $i = 42; $i ~~ Mu:U; 14:38
camelia 42
apogee_ntv m: my Int $i = 42; say $i ~~ Mu:U; 14:39
camelia False
apogee_ntv m: my $i = 42; say $i ~~ Mu:U;
camelia False
ugexe do you know what :U is?
apogee_ntv Undefined only 14:40
ugexe ah i see, the first one is different
oh, its not
apogee_ntv On legacy I believe one of those is True and the other is False but could be misremembering. 14:41
ugexe i would expect them all to be false
legacys type constraints and smileys were pretty broken
m: sub foo(--> int) { return "xyz" }; say foo().WHAT 14:43
camelia (Str)
ugexe m: sub foo(--> int) { return "xyz" }; say foo().WHAT
camelia (Str)
ugexe m: sub foo(*@_, Str :$foo) { say $foo.WHAT }; foo(foo => 42)
camelia (Int)
apogee_ntv Can Camelia do RakuAST vs Legacy or no? 14:44
ugexe use `run` and ENV<RAKUDO_RAUKAST=1> 14:45
probably better to just use the command line though so you're using the latest rakudo
apogee_ntv Not used to this syntax so could be wrong but 14:51
m: %*ENV<RAKUDO_RAKUAST> = 1; run $*EXECUTABLE, '-e', 'my $v = 42; sub f($x) { $x ~~ Mu:U }; my Int $i = 42; say ($v ~~ Mu:U, f(42), $v !~~ Mu:U, $i ~~ Int:U)
camelia ===SORRY!=== Error while compiling <tmp>
Unable to parse expression in single quotes; couldn't find final "'" (corresponding starter was at line 1)
at <tmp>:1
------> ~ Mu:U, f(42), $v !~~ Mu:U, $i ~~ Int:U)<HERE><EOL>
expecting any of:
ā€¦
apogee_ntv m: %*ENV<RAKUDO_RAKUAST> = 1; run $*EXECUTABLE, '-e', 'my $v = 42; sub f($x) { $x ~~ Mu:U }; my Int $i = 42; say ($v ~~ Mu:U, f(42), $v !~~ Mu:U, $i ~~ Int:U)'
camelia (True True False True)
apogee_ntv m: %*ENV<RAKUDO_RAKUAST> = 0; run $*EXECUTABLE, '-e', 'my $v = 42; sub f($x) { $x ~~ Mu:U }; my Int $i = 42; say ($v ~~ Mu:U, f(42), $v !~~ Mu:U, $i ~~ Int:U)'
camelia (False False False True)
apogee_ntv Thats the difference I ran into
ugexe well something is certainly wrong, using --optimize=off gives f, f, t, f 14:54
apogee_ntv I think f/f/t/f matches the behavior I would expect 14:59
ugexe i think the optimizer is losing the :U 15:00
apogee_ntv m: %*ENV<RAKUDO_RAKUAST> = 0; run $*EXECUTABLE, '-e', 'my $v = 42; sub f($x) { !$x.DEFINITE }; my Int $i = 42; say (!$v.DEFINITE, f(42), $v.DEFINITE, !$i.DEFINITE)' 15:16
camelia (False False True False)
apogee_ntv m: %*ENV<RAKUDO_RAKUAST> = 1; run $*EXECUTABLE, '-e', 'my $v = 42; sub f($x) { !$x.DEFINITE }; my Int $i = 42; say (!$v.DEFINITE, f(42), $v.DEFINITE, !$i.DEFINITE)'
camelia (False False True False)
apogee_ntv Works here as I'd expect.
ugexe right, because the issue is the optimizer
and smart matching 15:17
apogee_ntv Yeah seems so
On the plus side nothing I have installed except a couple of my own modules are doing this smartmatch so it doesn't seem to widely affect real code. On the minus side it's still wrong. 15:24
ugexe legacy wasn't exactly right either so that pattern in general would have been sort of busted for awhile 15:27
github.com/rakudo/rakudo/issues/5644 seems related 15:30
apogee_ntv Yeah legacy was wrong but I was doing one of the cases where it was right :D 15:53
ugexe i'm trying to see if it can be fixed to give fftf without breaking anything 15:55
with the optimizer that is
[Coke] goes online 15:57
41 failures on fdde48d8da 15:58
linkable6 (2026-09-26) github.com/rakudo/rakudo/commit/fdde48d8da Merge pull request #6743 from ugexe/ugexe/multi-mu-sorts-last
[Coke] lizmat: was hoping you wouldn't get stuck with the ast announcement, sorry.
github.com/coke/raku-blin-release-results updated 16:00
ugexe, lizmat - assuming that blin run looks OK - any more tests to be run? Are we comfortable with doing the release today? 16:03
lizmat +1 from me (yes, there will be issues, but we need to do a cutoff at some point)
[Coke] I would move that 6.e overview into the docs folder. 16:04
looks like I got all commits except for that last markdown file, no need to test that.
patrickb: I proposed a beta release to the RSC and it was not adopted. (one of the reasons: We have never done a beta release before) 16:09
and so therefore don't have any infra/docs/confidence on a beta release doing what we want.
ugexe looks like PDF::Native might be a new failure 16:10
Geth rakudo/main: ed1af967a1 | (Elizabeth Mattijsen)++ | 2 files
Move 6.e overview to docs directory
[Coke] As lizmat said, goal for this month is to flip the default switch on AST, nothing else.
lizmat re PDF::Native, do we know which lib should be installed on MacOS to make that work? 16:13
brew doesn't know about "libpdf" 16:14
[Coke] .seen dwarring 16:20
tellable6 [Coke], I saw dwarring 2021-09-28T18:15:00Z in #raku: <dwarring> yes there is a lot going on there
ab5tract ugexe: is there a substantive difference between doing `run $*EXE...`and `Q|...|.AST>EVAL` ? 16:22
`Q|...|.AST.EVAL`, rather 16:23
ugexe [Coke]: could you retry PDF::Native? it might be a gc issue
[Coke] it's 12:24 here - I'll plan on starting the release about 12:45 unless someone speaks up. 16:24
ab5tract (other than Q||.AST is not a guaranteed interface, of course)
[Coke] (that pdf module does look like it's been getting recent updates, so not abandoned)
ugexe ab5tract: i mean one spawns a fresh process and one happens in process, and each of those mean a bunch of things 16:26
ab5tract in terms of verifying /interrogating RakuAST behavior, I hadn't run into any issues with using the .AST.EVAL with camelia 16:28
or at least none that I ever noticed, so fair point 16:29
[Coke] ugexe: sure. 16:46
done- it's clean 16:49
Geth rakudo: ugexe++ created pull request #6745:
Don't fold a :U or :D smartmatch from a declared type		 16:50
rakudo: ugexe++ created pull request #6746:
RakuAST: don't reduce a smartmatch against a declaration, thunk, or mutable constant
rakudo: ugexe++ created pull request #6747:
RakuAST: make a bracketed infix behave as the infix it brackets
[Coke] any more commits being considered for today? 16:51
16:52 lizmat left
ugexe i didn't push those with the expectation they would be in this release, although they do fix things. my position is still the same from the meeting, although i could probably continue fixing things indefinitely šŸ¤· 16:58
16:58 lizmat joined
[Coke] ok. starting the release. 17:02
... after getting one more cuppa
lizmat ++[Coke]
[Coke] releasable6: next 17:11
releasable6 [Coke], Next release will happen when it's ready. There are no known blockers. 479 out of 558 commits logged
[Coke], Details: gist.github.com/736f930a706b2d66ac...0855dd5c09
[Coke] oof. Glad I tried to keep up with that, but still so many left.
lizmat I guess Inline::Perl5 is now the only major thing that will really break with the 2026.09 release 17:13
and all it needs is a release :-(
lizmat nudges nine
apogee_ntv github.com/raku-community-modules/...h/pull/248 For someone with community mods roles. This mostly affects people who already have NativeHelpers::Blob <= 0.1.12 installed but it bit me. 17:58
[Coke] (still processing commits. :| 18:16
apogee_ntv Have raised the 3 issues I ran into fixing stuff up for RakuAST so far. I have found workarounds for all but as published a lot of my modules will break. 18:27
lizmat so why didn't blin pick up on them ?
are they not in the ecosystem ? 18:28
apogee_ntv Selkie and MCP::Server definitely are which would have been the andthen/notandthen issue and the doc comments issue but one of the breaks wouldn't be caught by tests. I'm pretty sure the other would be by Selkie xt. 18:29
[Coke] again, blin does not test the whole ecosystem.
there are already selkie fixes in this release. 18:30
lizmat apogee_ntv: did you test with HEAD ?
[Coke] (having just completed the changelog)
apogee_ntv lizmat: With head as of about 4 days ago when I dropped that commit comment. 18:31
[Coke] Selkie ā€“ OK
Selkie::UI ā€“ OK
github.com/coke/raku-blin-release-...9/overview - tested fine on fdde48d8da
linkable6 (2026-09-26) github.com/rakudo/rakudo/commit/fdde48d8da Merge pull request #6743 from ugexe/ugexe/multi-mu-sorts-last
lizmat nine has released an Inline::Perl5 update that should work in RakuAST 18:32
apogee_ntv I can check if they are fixed on main
[Coke] so selkie not part of the "excluded because of json::class" deps.
taking a short break after changelog shenanagins.
apogee_ntv Selkie 0.99 isnt on ecosystem yet, could be newer code that broke :D
lizmat [Coke]++ 18:33
apogee_ntv Its a massive change
I'm still testing the frozen changes.
lizmat well, yeah, it's about 6 years of work :-) 18:34
confirmed Inline::Perl5:ver<0.62>:auth<github:niner> installed ok under RakuAST 18:38
apogee_ntv :P It's going to be great I promise, massive Windows fixes and performance boosts, far less exposed sharp corners (you don't need to know what an ncplane is to make most custom widgets any more).
It's just a lot more polished.
All of the APIs are much more consistent too. 18:40
Breaks a lot of BC with 0.17.* but I'm hoping most of the API surface wont change again for a long time. 18:43
[Coke] ok, so it wasn't released, so we're clear, aye? 18:45
apogee_ntv 1 of the 3 issues I raised was fixed (plus the Mu:U one that I mentioned here), other 2 (WhateverCode & .WHY attachment) remain open. 18:47
Just checked with my repro scripts against head
lizmat apogee_ntv: could you live with a release as it is now? 18:48
apogee_ntv Yes MCP::Server will break I believe but I can re-release it tonight
With a workaroun
lizmat cool, then we can move forward, I'd say 18:49
apogee_ntv +`
+1
[Coke] ok
lizmat: are we sure we want to mention RAKUDO_RAKUAST=0 on the release announcement? I thought we had discussion keeping that for when someone opened a bug. 18:58
lizmat ah yes... hmm... yeah, maybe remove that then 19:01
apogee_ntv Strongly recommend mentioning it.
Less engaged people will see something break and have no idea what happened.
ugexe please list some drawbacks to demonstrate you considered them 19:02
apogee_ntv Drawbacks to mentioning it? People run it and never switch over seems like the obvious one. But I think more people will pull rakudo 2026.09 through a random distro upgrade and have no idea what happened. 19:03
ugexe making people think they are using a legacy built core when they aren't is going to be way more confusing to them 19:04
apogee_ntv Why would we make people think that? 19:05
ugexe because that is what it always was and disabling the thing that replaced it would seem like logically getting the old behavior? 19:06
apogee_ntv Is that not what RAKUDO_RAKUAST=0 does? Give you the legacy AST? 19:08
ugexe what about the frontend used to build the core itself? 19:09
[Coke] lizmat: slightly modified version of your announcement - this ok? gist.github.com/coke/67d0036621bf8...7f70a8961a
ugexe the simplest and least confusing thing for end users is just to mention using the previous legacy release
lizmat +1
ugexe not advertise a huge foot gun and feeding the idea to llms 19:10
[Coke] ah, and I did that without removing the RAKUAST mention.
apogee_ntv I'm just imagining a what if I wasn't in this channel and I woke up tomorrow, ran a blind brew upgrade and everything broke. First thing I would do is check the release notes.
[Coke] As mentioned on the call, I have hesitations about telling users "don't upgrade" 19:11
(THis is why I wanted this announcement sorted out by the RSC before the day after the release.)
apogee_ntv +1 If people pin it, it will sit pinned for months
Everything I ever pin I forget that I have pinned until it stops working :P
[Coke] We could create a wiki page with details and point to that, but I imagine that won't solve the problem ugexe is positing 19:12
We could elminate the env var mention and the pin to previous release, and just say "great care was taken... but if you DO find an issue, please open an issue" 19:14
apogee_ntv Maybe make a separate troubleshooting wiki page and link to it for if someone has an issue? 19:15
[Coke] and, as mentioned on the call, we could then have some boilerplate for issues raised in the next month that includes both the "please stick with previous version until we fix this in hopefully the next release", and after checking, verify that if it works with the env var, tell them that, and still "look for a fix in an upcoming release"
ugexe yeah i'd rather anyone having an issue come and say something abou tit
[Coke] ... right, basically a version of what apogee_ntv just said
ugexe otherwise they wont say something about it until we remove the env var
[Coke] ok, let me rework this slightly for the announcement...
apogee_ntv Could print a message when RAKUDO_RAKUAST=0 which suggests filing an issue. :P 19:16
A little nudge on every run
"You are clearly working around a problem, please tell us what it is, this option will go away eventually" but in nicer words 19:17
[Coke] What about the 6.e language env var?
apogee_ntv: probably too late to sneak that in for today
Geth rakudo: ugexe++ created pull request #6751:
Decide a literal smartmatch the way the literal's ACCEPTS does
apogee_ntv [Coke]: Probably but could be in 2026.10?
imo at the very least telling people RAKUDO_RAKUAST=0 wont be around forever is wise. 19:18
Geth rakudo: ugexe++ created pull request #6752:
RakuAST: parse Int(Str:D) and Int(Array[Int]) as coercion types
[Coke] apogee_ntv: PR welcome. :) 19:22
or an issue, at least.
gist.github.com/coke/67d0036621bf8...7f70a8961a
apogee_ntv I will PR
[Coke] includes RAKU_LANGUAGE_LEVEL mention - should it?
apogee_ntv++
Can check how deprecated code emits its text and copy that. 19:23
I should have been more clear about getting the text for the announcement with a few days after the RSC decision. 19:24
ugexe there are CI jobs that set rakudo_rakuast=0 19:25
maybe its fine, but thats going to be a lot of output presumably 19:26
[Coke] we can see what it looks like in the PR actions.
ugexe yeah... wouldnt surprise me if it actually fails ci
since things check for warnings
[Coke] (and have a secret env var to hide the output?) 19:27
ugexe: thoughts on RAKU_LANGUAGE_LEVEL i the release ann.?
ugexe it kinda feels like if you're setting that env var you should already be familiar with whatever we want them to do
like if you read to set that env var somewhere, you should have already read to report the issue. telling them every time they run raku with that env var is just repeating what they already know isnt it? 19:28
apogee_ntv It does until modules stick it in their readme and people do it blindly. Maybe I'm overstating the issue and we're a small enough group that everyone follows releases.
ugexe [Coke]: seems fine to mention
apogee_ntv I think RAKUDO_NO_DEPRECATIONS=1 already suppresses deprecation notices 19:29
lizmat yes, it does
apogee_ntv So I can make any warning respect that? 19:30
[Coke] lizmat: latest version look ok to you> 19:35
gist.github.com/coke/67d0036621bf8...7f70a8961a
ugexe but then the tests for deprecations wont work 19:36
apogee_ntv Saw the 2 roast tests, will temp $*ENV and unset them in lexical scope in the tests? 19:39
unset it*
ugexe i dont think changing tests for this is the right thing to do
apogee_ntv That seems to harden the tests anyway?
Makes no sense to run a test for deprecation messages with the env var possibly set at the parent process level? 19:40
idk, the test change seems appropriate even if this change doesn't happen, we set env for the opposite test (testing RAKUDO_NO_DEPRECATIONS=1)? 19:42
[Coke] I'm going to move forward with the release if no one objects to the current phrasing. 19:43
apogee_ntv Looks good if we dont want to mention the escape hatch.
ugexe i guess i'd have to see them all, for the specific instance you describe it make sense but i dont think that is going to avoid the general problem i describe: some tests want to test deprecation messages so they can't be disabled, and the ci still runs the test and spectests with a rakudo_rakuast=0 variant 19:47
maybe im just misremember such tests though, so dont take my word on it. but if you do see failures it's likely for the reason i describe 19:49
the tests might be written in such a way that additional deprecations don't matter
apogee_ntv I *think* there are 2 but could have missed some. There are some that already set the env var to 0 and to 1. 19:54
I did some pretty lazy greps to find them so will see what breaks, happy to close the PRs if we dont want them, either of them. I wont get offended. :P Just thinking what would I want if I were a less engaged module maintainer or user. 19:56
And it would not be "I find this escape hatch and then it disappears on me down the line suddenly."
lizmat [Coke]: sorry was distracted with a TRF meeting
so no RAKUDO_RAKUAST=0 mention? If that's what the consensus is, I'm fine with that
apogee_ntv And the problem is today, half the way I would find that escape hatch is asking Claude 'why did this break today?' and it would say "there's a new version, let me go dig through the source changes... oh you can use RAKUDO_RAKUAST=0 and it will be fine." 19:58
(again if hypothetically I wasn't in IRC seeing the changes) 19:59
If my terminal then tells me "This escape hatch is going away" I'm more likely to report my issue or fix my code, as half-engaged maintainer me.
ugexe i mean its not even a true escape hatch. the core they are using is still built with rakuast 20:00
Geth rakudo/release-2026.09: 6df91a8338 | (Will Coleda)++ | 3 files
Update changelog + announcement

Deliberately not logged:
  [561c5121][a0a60ed3][682fbc6b][79c849db][d1abb79b][12b5be61][b83057b1][ff413403][a107b0ce][a456c3a3]
lizmat hmmm... the TRF board could send an email to all people that registered at raku.foundation/ with an announcement
ugexe and how things behave between every combination of legacy core, rakuast core, legacy runtime, and rakuast runtime has differences 20:01
apogee_ntv True but the core is confirmed working with RakuAST, their code isn't, my code works with it as of 2hrs ago and much of whats on raku.land isn't even now.
In terms of my code anyway.
[Coke] "isn't even now" what?
ugexe then you have overlooked that user code on a rakuast built core using legacy frontend can break in even more confusing ways
[Coke] rakudo/release-2026.09 - feel free to review that while I go do a moarvm release. 20:02
apogee_ntv MCP::Server isnt but I will release it tonight, App::Moneymoor if you already had DBIish from before July installed. 20:03
Geth rakudo: ugexe++ created pull request #6753:
RakuAST: set declarator docs at BEGIN time		 20:07
rakudo: ugexe++ created pull request #6754:
RakuAST: treat a WhateverCode operand of a short circuit operator as a value		 20:21
[Coke] MoarVM release done 20:27
apogee_ntv Any idea when 2026.09 will be on the setup-raku action? Is that available as soon as its released or are there extra steps? 20:38
[Coke] That's not something I run directly. 20:49
(what is it?) 20:50
Geth roast: m-doughty++ created pull request #917:
Explicitly unset RAKUDO_NO_DEPRECATIONS on 'is DEPRECATED' test in Roast		 20:54
apogee_ntv [Coke]: It's the github action to set up Raku in CI
Geth rakudo: ugexe++ created pull request #6755:
Keep EVAL of a RakuAST node from running its MAIN		 21:00
21:01 finanalyst left
[Coke] spec test hanging on t/spec/S17-channel/stress.t 21:02
no noticable cpu or memory usage 21:03
Rerun - same hang. 21:11
6.c errata failure /spec/integration/advent2011-day23.t 21:17
retrying, will see how 6.d goes. 21:18
6.c error repeatable 21:20
Not sure if these are worth blocking the release for. Would like a second opinion 21:21
Geth rakudo: m-doughty++ created pull request #6756:
Deprecate the legacy frontend with a message		 21:23
[Coke] d is hanging on the same stress test 21:27
apogee_ntv How do you run them under the different erratas? I dont mind taking a look. Anything to get my mind off this cold tbh. 21:30
[Coke] ah. 6.c didn't hang, so I saw the advent error, but I think that error was on the other two, hidden behind the hang
those are branches in raku/roast 21:31
so just checkout the right errata branch
but it seems like all the errors are also on master
ugexe [Coke]: github.com/Raku/roast/commit/e6502dcf1 wasn't ported to errata
notably this bit: github.com/Raku/roast/blob/e749867....t#L16-L17 21:33
the missing semicolon means the + on the next line is treated as an infix which for rakuast doesn't compile 21:34
[Coke] ok. so maybe master is just the hang. 21:35
I'll cherry-pick that. 21:36
ugexe github.com/Raku/roast/commit/d7f03...4834539919 this is a fix in 6.e-erratta 21:38
Geth roast/6.c-errata: d74a1da366 | (Stefan Seifert)++ (committed by Will Coleda) | integration/advent2011-day23.t
Fix missing semicolon in test

Commit d7f03fcb90d3cc26ae0c284ac879364834539919 introduce a missing semicolon error. This however did not surface because the following line starts with a prefix + which without the semicolon was interpreted as an infix. The result is that the test sub always returned a true value.
... (9 more lines)
apogee_ntv Looking at the hang, looks like it works on legacy. Digging into it.
roast/6.d-errata: 9d3699885a | (Stefan Seifert)++ (committed by Will Coleda) | integration/advent2011-day23.t
Fix missing semicolon in test

Commit d7f03fcb90d3cc26ae0c284ac879364834539919 introduce a missing semicolon error. This however did not surface because the following line starts with a prefix + which without the semicolon was interpreted as an infix. The result is that the test sub always returned a true value.
... (9 more lines)
[Coke] 6.c is clean with that. 21:41
apogee_ntv Found it, `start until` behaves differently on RakuAST (stress.t). 21:43
[Coke] there are more failure in d hiding behind the hang. will rerun to catch them all 21:46
apogee_ntv Loop is being compiled as a lazy seq and never invoked because the return from the loop is discarded (this is in bogosort).
$sorted.receive waits forever on an empty channel 21:47
method propagate-sink(Bool $is-sunk) { 21:53
self.blorst.apply-sink(False);
}
It ignores $is-sunk it looks like.
[Coke] huh. I just did a run on master that hung ... but if I ^C it, it ends in a pass. 21:55
apogee_ntv github.com/rakudo/rakudo/blob/ed1a...kumod#L501
[Coke] master: after the ^C: gist.github.com/coke/553e753495e1c...3ceb1c6125
camelia ===SORRY!=== Error while compiling <tmp>
Confused
at <tmp>:1
------> after the ^C: https:<HERE>//gist.github.com/coke/553e753495e1cbf73
expecting any of:
colon pair
apogee_ntv Inherits from github.com/rakudo/rakudo/blob/ed1a...kumod#L411 21:56
So if I'm reading right (and it's very possible I'm not), the sunk start doesn't run and the $sorted.receive just waits forever? 21:59
[Coke] 6.d is hiding another failure 22:07
gist.github.com/coke/0f5bfd95563bb...8b6aeb2af6 22:08
I'd like to get the master/6.d branches sorted before continuing on the release. 22:09

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!