🦋 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] |
|
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 |