01:04 librasteve_ left 02:30 nine left, nine joined
releasable6 Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 07:00
08:28 librasteve_ joined 09:11 [Tux] left 09:18 [Tux] joined
[Coke] releasable6: next 12:27
releasable6 [Coke], Next release in ≈2 days and ≈6 hours. There are no known blockers. 8 out of 44 commits logged
[Coke], Details: gist.github.com/31f9f4c09670ce1a33...4f911a185f
[Coke] anyone wants to give those messages some nice text for the changelog, that'd be appreciated.
(especially for the merges that have multiple commits for the same big thing.)' 12:28
timo line two belongs to the same thing as the first line, it's not really a change from one release to the next 12:35
lizmat will go over it shortly 12:39
[Coke]: wasn't there an already post-processed version of that gist somewhere ? 12:45
ah, I guess I'll just port them to github.com/rakudo/rakudo/wiki/ChangeLog-Draft ? 12:47
[Tux] Rakudo v2025.11-44-g820a4a94a (v6.d) on MoarVM 2025.11-45-g380ad21ae
csv-ip5xs0.267 - 0.273
csv-ip5xs-201.122 - 1.149
csv-parser1.140 - 1.150
csv-test-xs-200.115 - 0.116
test1.889 - 1.891
test-t0.458 - 0.466
test-t --race0.284 - 0.286
test-t-205.884 - 5.925
test-t-20 --race1.437 - 1.450
 12:52
csv-test-xs 0.014 - 0.014
tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log
[Coke] Right, that's the post processed page. 13:04
github.com/rakudo/rakudo/wiki/ChangeLog-Draft
Any that can be done before the release make it go smoother, thanks1 13:05
!
lizmat [Coke]: need to go afk for a few hours, will continue on the Changelog after that 13:44
[Coke] Sure, any help appreciated, thanks. 14:26
15:12 melezhik joined
melezhik [Coke]: ab5tract - wish to run brownie for the head before release ? 15:18
Cc patrickb
[Coke] You can - I will probably not do another full blin run at this point, given that the one "real" failure has been resolved. 15:19
disbot6 <melezhik.> Sure 15:29
timo i think we will still want to do something about vararg support "missing" from the jit before the release goes out. either nope out in the jit when we see there's varargs involved, or by implementing it correctly in the right place
[Coke] timo++ 15:44
would what we have at HEAD right now be a step back?
timo i'm not sure if patrickb is already on it, but I think that's the case?
no, what we have right now is better than it was days ago 15:45
patrickb last months release already had the broken var-args support in it. The breakage only affects Vararg calls, so this is not really bad. 15:46
timo oh, OK, i wasn't aware we already had varargs last time 15:47
patrickb I do like to fix this, I've already had a quick look at spesh and jit.
[Coke] Can we do it before the weekend?
I think we have enough today that a release would be nice.
patrickb But given I only have an abstract idea of our jit and spesh, I believe this will take time. Not before the release 15:48
[Coke] ok. so are we OK going as is?
patrickb Except: If timo and I pair up. Then I guess we'd have a chance.
timo ok, I'll look into it this evening
[Coke] ... ok. let me know by your EOD friday. 15:49
And we can decide collectively tomorrow.
patrickb timo: I don't want to force this on you, but I'd personally love to colab on this. I'd love to get to know spesh more...
timo tomorrow is my last work day for the year, after that i would be free to do a session like that 15:50
lizmat fwiw, I don't think 2025.11 contained varargs support 15:52
patrickb That would be too late for the release. Maybe you could have a look tonight and we could maybe still do a session looking at spesh? (Please?)
lizmat rakudo.org/post/announce-rakudo-release-2025.11 doesn't mention it
timo yeah that's what i was thinking of doing 15:54
patrickb agreed. then I was wrong about that.
Wouldn't be that bad nonetheless, it's not breaking existing features. But would still be nice to get it fixed before the release. But that's mostly for selfish reasons. 15:55
timo making the jit bail out when it sees a var arg native call op only makes the frame in question not be jitted, so it only really has a performance impact 15:57
patrickb that would be a quick fix 15:58
timo quick fix is good on the day before the release ;)
[Coke] +1
lizmat [Coke]: Changelog processes 16:25
*processed rather :-) 16:45
m: sub a(|c) { dd c }; my $a = 666; a :$a(42) 17:20
camelia No such method 'CALL-ME' for invocant of type 'Pair'
in block <unit> at <tmp> line 1
lizmat from stackoverflow.com/questions/798498...sh-in-raku 17:27
[Coke] releasable6: next 17:28
releasable6 [Coke], Next release in ≈2 days and ≈1 hour. There are no known blockers. 43 out of 44 commits logged
[Coke], Details: gist.github.com/53b5784082fe881d86...7116645ec4
[Coke] lizmat++!
timo patrickb: do you have a good simple test library that lets you verify that a variadic call was done correctly? 18:32
see the moarvm channel for the first stab at bailing out the jit when it sees a variadic nativecall 18:34
patrickb There is t/04-nativecall/26-varargs.t (iirc) 19:24
21:01 melezhik left
Geth nqp/main: 4c2a291f65 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get variadic args JIT issue patch, timo++
 23:35
rakudo/main: 159288a3d5 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get variadic args JIT issue patch, timo++
 23:40
lizmat [Coke]: ^^ 23:47
sleep&

Powered by Cro and the Raku® Programming Language.

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

Thank you!