🦋 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.
01:32 guifa left 01:34 guifa joined 02:21 guifa left 02:37 guifa joined
releasable6 Next release in ≈1 day and ≈15 hours. 2 blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 03:00
[Coke] much easier to keep the changelog up to date as you go 03:23
blin #3 is 97% done 03:24
trying to stay awake so I can cleanly shut off the vm.. :) 03:39
04:08 guifa left
[Tux] Rakudo v2025.03-245-gbff242f6c (v6.d) on MoarVM 2025.03-13-gb405e940e
csv-ip5xs0.266 - 0.270
csv-ip5xs-201.077 - 1.131
csv-parser1.087 - 1.096
csv-test-xs-200.115 - 0.116
test1.874 - 1.877
test-t0.421 - 0.431
test-t --race0.266 - 0.271
test-t-204.879 - 4.947
test-t-20 --race1.240 - 1.252
 06:29
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
nine [Coke]: LLMs have become pretty decent at turning commit lists into changelogs 07:23
08:30 Xliff joined
Xliff \o 08:30
So... can I ask what will trigger 6.e? 08:31
6.d is getting long in the tooth.
nine Realistically: someone arguing convincingly that it's time for 6.e 08:32
Xliff Wouldn't RakuAST provide a good reason? 08:33
10th anniversary is coming up. That would be a good enough time as any. 08:34
nine IIRC we did discuss 6.e in the RSC and RakuAST was a prominent point in that discussion
Xliff nine: Fair enough. Thanks for the update. I'm going to take a nap before $dayJob. 09:13
09:13 Xliff left 09:16 lizmat left, lizmat_ joined 09:17 lizmat_ left 09:18 lizmat joined
nine May be a good point for a reminder that according to its charter, the RCS decides only if the community does not come to a decision by itself. 09:24
lizmat focusing on github.com/rakudo/rakudo/issues/5855 now 09:43
looks like $=finish and $=rakudoc are not visible at CHECK time 09:44
but $=pod is (in RakuAST)
yet I can't really see any difference in handling between RakuAST::VarDeclaration::Implicit::Doc::Pod and RakuAST::VarDeclaration::Implicit::Doc::Finish 09:46
in their PERFORM-CHECK logic
so why is $=pod known to the resolver at CHECK time, but $=rakudoc and $=finish aren't? 09:49
any suggestions, nine?
perhaps the PERFORM_CHECK logic in RakuAST::VarDeclaration::Implicit::Doc::Finish should add $=finish to the given resolver ? 09:50
or would that be too late ?
09:56 finanalyst joined
nine Despite its name PERFORM-CHECK has nothing to do with this 10:50
lizmat but that method is run at CHECK time, is it not ? 11:24
nine yes 11:27
A more accurate and helpful statement would probably be that that method is *also* run at CHECK time 11:33
lizmat right
I seem to be missing where $=pod actually winds up being resolvable 11:37
nine I don't see RakuAST::Var::Doc use the resolver at all. 11:41
m: say SETTING::<$=pod>
camelia []
nine m: say SETTING::<$=finish>
camelia Nil
nine m: say SETTING::<$=data>
camelia Nil
nine This ^^^ is the answer to your riddle 11:42
lizmat m: say SETTING::<$=data>:exists 11:43
camelia False
lizmat m: say CORE::<$=pod>:exists 11:44
camelia True
nine The fix is most likely to get rid of RakuAST::Var::Doc 11:45
lizmat totally ? 11:48
nine Yes. I don't see a need for it.
lizmat ok, so what should the AST then be for a $=rakudoc access ? 12:00
nine Just a RakuAST::Var::Lexical 12:01
After all, it's just a lexical variable with a funny name and contents filled by the compiler
lizmat Variable '$=finish' is not declared. 12:04
and for $=pod I get: 12:05
Lexical symbol '$=pod' is already bound to an outer symbol.
nine Solving those will as a side-effect solve the CHECK issue
lizmat add(RakuAST::VarDeclaration::Implicit::Special.new(:name('$=finish'))); appears to make it worse 12:12
nine Why would you do that? 12:13
lizmat Lexical symbol '$=finish' is already bound to an outer symbol
to declare it ?
nine Why would you need a VarDeclaration::Implicit::Special for that when there's already a RakuAST::Var**Declaration**::Implicit::Doc::Pod.new 12:16
lizmat ah, duh... :-) but why doesn't that "vivify" that $=finish in the SETTING:: then ? 12:18
12:18 guifa joined
nine Why would it do that? How would it do that? And why would you even want that? 12:27
lizmat to make the "Variable '$=finish' is not declared" error go away ? 12:29
the not-declared error is coming from a resolver 12:30
how do I get the resolver to resolve it ?
nine I get the impression that you are lacking a basic understanding of how variables (and other names) are declared and resolved. 12:31
lizmat I think you are right :-)
nine Reading time then. I suggest starting at RakuAST::Resolver::Compile.resolve-lexical 12:32
lizmat reads
I guess "resolve-lexical-in-outer" is the fallback being executed in this case 12:34
? 12:35
ok, so this chases back the contexts until it reaches CORE-SETTING-REV
which was basically my understanding so far 12:36
so I'm still not sure how it will be able to find "$=finish" if nothing has put it in the CORE-SETTING-REV context ? 12:37
nine What does any of this have to do with the setting? 12:38
lizmat because SETTING::<$=finish>:exists is expected to be True ?
nine I suggest you take a step or 3 back. Would you expect to find the $=finish of your own code somewhere in the setting? 12:39
lizmat heh, good point 12:41
nope, it should be in UNIT:: ??
m: dd SETTING::<$pod>:exists 12:43
camelia Bool::False
lizmat m: dd CORE::<$pod>:exists # this is really an artefact 12:44
camelia Bool::False
lizmat hmmm.. I guess not: in the legacy grammar that would be what $=pod resolves to if there is none in UNIT:: right ?
nine Again, I don't think there's anything special about $=pod at all. It's just a lexical variable 12:46
lizmat that lives in the compunit if there's any pod 12:47
[Coke] 3 blin failures bisected to github.com/rakudo/rakudo/commit/bf...4a47a3ea9a 12:56
lizmat meh
timo huh. 12:57
lizmat [Coke]: which ones?
[Coke] gist.github.com/coke/e2c3aba29f565...7625cce431
this laptop is nearly dead, will post full failures.md in a bit. 12:58
lizmat ++[Coke]
13:08 guifa left
[Coke] github.com/rakudo/rakudo/issues/5857 13:18
nine [HTML::Canvas::To::PDF] # MoarVM panic: Internal error: invalid thread ID -1755445856 in GC work pass
I doubt that bisection result is meaningful
lizmat well.... that commit could be tickling a bug ? 13:19
anyways, going to ruminate afk for a few hours&
timo if that error happens 100% every time you run the tests, then yes
but that kind of error rarely happens reproductibly
so the majority of "good" commits are still suspect 13:20
making the pin-pointed commit most likely wrong
[Coke] 2 other modules didn't like the commit either, and i only see the panic on one of them. 13:21
but I leave it to the devs. I do note that the run with the new zef but the empty zef store took 2 more hours than the previous run 13:22
timo we'll need to look more closely than the automatic bisection can do it i think 13:28
[Coke] github.com/Raku/roast/pull/874/files - I think I made a mistake here - just because these are passing on the *latest* rakudo, doesn't mean they are passing on *earlier* rakudos. 14:13
so I think my desire to get a clean pass here is not sufficient reason to break someone testing against, e.g. 2023.06 rakudo 14:14
Any thoughts?
github.com/rakudo/rakudo/issues/5841 - running 6.d again now, but still have two failures in 6.c that need to be addressed. 14:16
With the release tomorrow, could use any eyes on github.com/rakudo/rakudo/issues/5841 14:18
5 different failing files now across c & d. 14:22
jdv are there corresponding changes in main that could be cherry picked? 14:32
[Coke] for one of them, the change is master itself is suspect. 14:35
Others I've already applied.
the remaining ones in d I haven't gotten to yet. 14:36
there were a suprising amount of failures here.
github.com/Raku/roast/issues/878 - the suspect one
Geth rakudo/main: 4217a5cfd0 | (Elizabeth Mattijsen)++ | src/core.c/Array.rakumod
Revert "Change internal handling of index out of range"

This reverts commit bff242f6c9a0846c3382a2d3f1dee04a47a3ea9a.
This produced (possibly false positive) failures in blin. Being so close before the release, it feels safer to revert for now		 15:42
lizmat [Coke]: we can check again after the release
[Coke] Sounds good 15:47
lizmat nine: I just found out that "CHECK say $=pod" in RakuAST shows the wrong $=pod 16:00
so the fact that $=pod works in a CHECK phaser, is an artefact of it existing in CORE:: 16:01
nine I know
That's why I posted the stuff about SETTING::<$=pod>
lizmat right, but I didn't realize it was the wrong one, so that put me on a goose chase to find the difference in handling of $=pod and $=finish 16:02
when there isn't any, really
nine How could it have been the right one, when you're looking at the setting instead of your compunit? 16:04
lizmat yeah, it all makes sense *now* :-) 16:05
ok, so at runtime, UNIT::<$=finish> has the right value 16:07
so it's a matter of timing 16:08
nine Well only in the broadest of senses 16:10
lizmat I still don't grok how we get from 16:11
has RakuAST::VarDeclaration::Implicit::Doc::Finish $.finish;
in ::CompUnit to setting UNIT::<$=finish> *after* CHECK time, and before any INIT phaser is run 16:12
nine I would forget about UNIT::<$=finish> as it's just a distraction. That's a totally different way of accessing that lexical 16:13
UNIT:: has nothing to do with the resolver 16:14
Reading from RakuAST::Resolver::Compile.resolve-lexical should lead you to where you need to be 16:23
lizmat afk& 16:34
[Coke] releasable6: next 17:21
releasable6 [Coke], Next release in ≈1 day and ≈1 hour. 1 blocker. 246 out of 246 commits logged
[Coke], Details: gist.github.com/51aa8d239bcf1234c3...dc1a2f79c5
[Coke] do we have CI running for spectest/stresstest on master on a regular basis? 18:49
sorry, I should be more precise: given "regular basis", I don't mean *continuous*. Are we running the spec tests automatically at all? 18:51
nine I don't think so 18:54
ab5tract It would be interesting to run them on PR merge. Or we could trigger them with a specific tag format (*-prerelease or so) 20:11
20:17 finanalyst left
[Coke] Would definitely make the release easier on those months where spec tests are failing 20:29
jdv it only takes a few minutes on a decet box though 20:30
*decent
[Coke] retrying my spec test runs on the blin box, as it only just occurred to me maybe it's an OSX thing
jdv: Yes, but if it's *manual*, it's still a PITA 20:31
You know how many times I've run stresstest this month? :)
jdv regular blin runs could be more worhwhile, to me at least
[Coke] I did four blin runs this month. Do you mean more regular?
jdv i mean automatic
its a real hassle
[Coke] mmm
I'm sure we could improve the state of both, for sure. 20:32
Let me get through a release or two with zero issues then I can think about that more. :)
20:34 finanalyst joined
[Coke] ... dammit. 6.c and 6.d are both fine at this point on the blin box. 20:38
so any remaining issues are either the "we're not testing the unicode thing we think we are" or "this test fails on osx"
good news, no more changes needed in roast for the release tomorrow
releasable6: next 20:41
releasable6 [Coke], Next release in ≈22 hours. There are no known blockers. 246 out of 246 commits logged
Geth rakudo/release-2025.04: a32ac4ce73 | (Will Coleda)++ | 3 files
Update changelog + announcement

Deliberately not logged:
  [f796a996][184d3257][bc5b2673][9c9d822e][dd0b647d][8a393381]
  [4c2fa940][a3841c26][aad9c3bd][403252cf][5bd76f54][690370ad]
  [f140ce2c][be3d06a7][e494d4d8][bff242f6][4217a5cf]		 21:13
[Coke] Little head start. That's everything before "do the MoarVM release" 21:14
(so anything else going on main is not in the release... please wait until post release for anything else if possible, and if something has to get in the release that wasn't already on main, it'll have to get merged to the release branch (and I need to get pinged) 21:16
jdv: remembered the Changelog itself this time
jdv: didn't accidentally create a YYYY.MM.md 21:17
timo if i'm allowed to pick nits, "these tests pass in default grammar" and "remove useless `,`" seem a little small to be getting their own entry? 21:36
i'd reword the one above that "Update vendored mimalloc version"; it's not really important to change log readers what a bump is, i think? 21:37
[Coke] Sure - I didn't put much effort into rewriting the ones that were standalone. 21:43
note that the changelog draft has been there all month for updates from devs. 21:44
timo yeah i know :<
[Coke] Well, better tonight than tomorrow! 21:45
If you have any suggestions, throw them in a gist (or a PR for the release branch), and I'll deal with them tomorrow morning, no worries, timo
Thanks for reviewing! 21:46
(note to self, update both the changelog & the rel ann.)
21:51 finanalyst left 21:56 guifa joined
jdv [Coke]: ok 22:59
releasable6 Next release in ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 23:00

Powered by Cro and the Raku® Programming Language.

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

Thank you!