Geth rakudo/main: 6f06f9f1fe | (Will Coleda)++ | docs/release_guide.pod
Add next release date

release engineer TBD		 00:03
[Coke] releasable6: next
releasable6 [Coke], Release date for Rakudo 2025.11 is listed in “Planned future releases”, but it was already released.
[Coke], and I oop! Backtrace: gist.github.com/8462582ad482994687...31ad86d722
Geth rakudo/main: c5c33ba9dc | (Will Coleda)++ | docs/release_guide.pod
Try alpha "TBD" for releasable.
 00:09
rakudo/main: e66655c07a | (Will Coleda)++ (committed using GitHub Web editor) | 2 files
Coke/releng (#6023)

  * We don't have future dates listed there...
anymore
  * minor nits found during 2025.11 release		 00:19
setup-raku: 5ebf60c573 | dependabot[bot]++ (committed using GitHub Web editor) | package-lock.json
Bump js-yaml from 3.14.1 to 3.14.2 (#43)

Bumps [js-yaml](github.com/nodeca/js-yaml) from 3.14.1 to 3.14.2.
  - [Changelog](github.com/nodeca/js-yaml/blob/mas...NGELOG.md)
  - [Commits](github.com/nodeca/js-yaml/compare/......3.14.2)
  ---
... (8 more lines)		 00:24
jdv [Coke]: sure 01:19
02:21 unicodable6 left 02:24 unicodable6 joined 06:02 melezhik joined
Geth rakudo/main: a1336399a5 | (Patrick Böker)++ | t/04-nativecall/26-varargs.t
Another vararg test: passing `Int`s
 07:45
rakudo/main: 31ff2eb228 | (Patrick Böker)++ (committed using GitHub Web editor) | t/04-nativecall/26-varargs.t
Merge pull request #6027 from patrickbkr/another-vararg-test

Another vararg test: passing `Int`s
07:52 librasteve_ joined 08:01 n70470 joined
n70470 . 08:01
08:02 n70470 is now known as melezhik2
japhb lizmat: I just came across github.com/lizmat/path-utils/blob/...od#L15-L30 and I have to tip my hat to you for that little bit of packaged evil. ;-) 08:04
08:06 melezhik2 left 08:14 n71246 joined 08:15 n71246 left
lizmat yeah, the grammar on "and there a no return statements" is horrible :-) 09:16
sjn looks like a typo to me :-P 09:31
melezhik . 09:34
10:02 librasteve_ left
ab5tract someone pushed a commit that breaks a number of tests, # Found 1 unexpected entries: $current-offset-nanos 10:58
bisectable6: use v6c; not SETTING::.keys.grep: * ~~ q|$current-offset-nanos| 11:03
bisectable6 ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight
ab5tract, Output on all releases: gist.github.com/ab45123775f561be70...c74e3ee3e9 11:04
ab5tract, bisect log: gist.github.com/58ca9f2809eb3fb0c5...a6d0078721
ab5tract, Output on all releases and bisected commits: gist.github.com/5d5f53f0526c38008f...db763b8e27
ab5tract bisectable6: use v6.c; return not SETTING::.keys.grep: * ~~ q|$current-offset-nanos| 11:05
bisectable6 ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight
ab5tract m: use v6.c; say not SETTING::.keys.grep: * ~~ q|$current-offset-nanos|
camelia False
bisectable6 ab5tract, ¦6c (95 commits): «Attempt to return outside of any Routine␤ in block <unit> at /tmp/Lza_QFPxj_ line 1␤␤ «exit code = 1»»
ab5tract, Nothing to bisect!
ab5tract bisectable6: use v6.c; not SETTING::.keys.grep: * ~~ q|$current-offset-nanos| 11:06
bisectable6 ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight
ab5tract, ¦6c (95 commits): «WARNINGS for /tmp/1NdzUan6Hy:␤Useless use of "not " in expression "not SETTING::.keys.grep: * ~~ q|$current-offset-nanos|" in sink context (line 1)␤»
ab5tract, Nothing to bisect!
ab5tract bisectable6: help 11:07
bisectable6 ab5tract, Like this: bisectable6: old=2015.12 new=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # See wiki for more examples: github.com/Raku/whateverable/wiki/Bisectable
ab5tract bisectable6: use v6.c; exit + not SETTING::.keys.grep: * ~~ q|$current-offset-nanos|
bisectable6 ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight 11:08
ab5tract, Output on all releases: gist.github.com/6ec0687a34664ad18c...cf5dc1d7e5
ab5tract, Bisecting by exit code (old=2025.11 new=31ff2eb). Old exit code: 1
ab5tract, bisect log: gist.github.com/5d72c053db5c13e94c...f97f059407
ab5tract, Output on all releases and bisected commits: gist.github.com/4e75ed764c082435b4...6737a1fc7f
ab5tract what is going on here? 11:09
bisectable6: use v6.c; exit + not SETTING::.keys.grep: * ~~ q|$current-offset-nanos|
bisectable6 ab5tract, Will bisect the whole range automagically because no endpoints were provided, hang tight
ab5tract oops
m: use v6.c; say not SETTING::.keys.grep: * ~~ q|$current-offset-nanos|
camelia False
bisectable6 ab5tract, Output on all releases: gist.github.com/7e2b033a11bcfc33da...a5c18f2bba 11:10
ab5tract, Bisecting by exit code (old=2025.11 new=31ff2eb). Old exit code: 1
ab5tract, bisect log: gist.github.com/0791121c271bbaba71...6395fc11cd
ab5tract, Output on all releases and bisected commits: gist.github.com/32d0881b4ef690ba12...1e3d8223c3
ab5tract here is the commit: 3b80351fa6c99a341f35a2978ee847975c4165d5 11:12
is rir on IRC?
is the "right" thing to do to add $current-offset-nanos to the tests? or to just replace the one time the variable is referenced with a direct call to Rakude::Internals.current-offset-nanos 11:15
I guess the addition of this variable only affects versions < 6.e because RakuAST is much cleaner about what it brings in 11:18
m: use v6.c; q{ say not SETTING::.keys.grep: * ~~ q|$current-offset-nanos| }.AST.EVAL 11:19
camelia True
ab5tract in that case I will just fix the tests 11:20
hmmm, still fails a test: Lexical with name '$current-offset-nanos' has a different type in this frame 11:22
Geth rakudo/main: 6432643ba3 | ab5tract++ | src/core.c/Instant.rakumod
Remove lexical $current-offset-nanos

Using a variable to store `Rakudo::Internals.current-offset-nanos` pollutes the SETTING and CORE namespaces for versions < 6.e.
For 6.e, a different exception occurs:
   Lexical with name '$current-offset-nanos' has a different type in this frame
These are presumably fixable but it's also feasible that any performance gains could be delivered at the optimizer level instead.		 11:26
lizmat ab5tract: good catch 11:36
however, now each time 'now' is called, it will do the calculation in Internals... so the constant needs to be made there 11:37
or int assigned at started
*startup
ab5tract well is it static or dynamic? 11:39
the return value of Internal.current-offset-nanos, I mean 11:40
if there is any chance at all that it changes, it seems to me that it needs to be called each time 11:42
and if there is no chance that it changes, why is there a calculation there and not a constant value?
I'm fine with the approach in the previous patch, but it was merged without testing, which is a real annoyance for others who are hacking on core 12:10
Geth rakudo/r5317-role-it: 178bf24439 | ab5tract++ | src/Perl6/Metamodel/ParametricRoleHOW.nqp
Add an istype check on the role group

This addresses R#5317, which had the following test case:
   role R {}
   role S does R {}
   my R $v = role V does S {}
... (21 more lines)		 12:25
linkable6 R#5317 [open]: github.com/rakudo/rakudo/issues/5317 [roles][Will be addressed in RakuAST] role-constrained variable does not accept derived role defined inline
rakudo: ab5tract++ created pull request #6028:
Add an istype check on the role group
lizmat ab5tract: the only time that number changes, is when the world adds a leap-second 13:01
timo .o( is it bad that we can't update that in a running process? )
lizmat well, possibly: if we really want to support a hot update, then we would need quite a different approach 13:03
because atm it would require a core update / re-compile
timo maybe processes shouldn't be running for multiple years at a time in the first place 13:04
leap seconds are announced long in advance, right?
lizmat yeah, historically
but it also looks like we won't have a leap-second added for quite some time to come, due to climate change 13:05
and there's been even talk of actually introducing a negative leap-second at some point: en.wikipedia.org/wiki/Leap_second 13:06
ab5tract are state variables available in Rakudo::Internals methods?
lizmat it's pretty early in the core 13:07
ab5tract lizmat: it definitely sounds like we don't want or need to call it more than once
lizmat yeah
ab5tract my only real issue with that patch is the ignored test failures 13:08
lizmat eh? I didn't see any test fails ? 13:09
ah... because the name got added? grr I guess I only checked spectest :-( 13:12
ab5tract ah, that makes sense 13:13
definitely done that before :)
so, I have another role group istype check that produces a lot of TODO passes :D
doesn't totally fix t/spec/S02-types/generics.t, but it does fix the shortened version of that test from r#5970 13:15
linkable6 R#5970 [open]: github.com/rakudo/rakudo/issues/5970 RakuAST - Fix generics package names
ab5tract ah crap, now I've done a test fail too lol 13:16
echo $RAKUDO_RAKUAST 13:17
the patch is not rakuast specific though
patrickb ab5tract: Can you please retrigger the CI on github.com/ab5tract/Terminal-Print/pull/90 ? 13:34
ab5tract patrickb: not at all computer at the moment. Maybe find a typo or a docs gap and push a fix? 13:53
Otherwise I can do it in about 2-3 hours
patrickb ack 13:55
14:46 El_Che joined
El_Che hi, I get a segmentation error when building moarmv on OpenSuse Leap 16.0: +++ Compilinggen/moar/stage1/nqpmo.moarvm 14:46
tellable6 2025-11-15T19:36:34Z #raku-dev <[Coke]> el_che 2025.11 should be ready for binary releases now
El_Che make: *** [Makefile:370: gen/moar/stage1/nqpmo.moarvm] Segmentation fault (core dumped)
has someone here experienced that here? 14:47
lizmat sounds unfamiliar to me 14:49
timo that's very early in the compilation process isn't it?
can you get a backtrace? maybe you have `coredumpctl` and you can get the output of `coredumpctl info`? 14:50
El_Che it's in a container in a github action, I'll start by pasting the complete build in a guist
*gist
timo ah that's annoying. but at least with a container it should be relatively reproducible? does it happen reliably or sporadically? 14:51
El_Che every time 14:52
productionresultssa14.blob.core.wi...98a6654-99
7b-47e9-b12b-9515b896b4de&skv=2025-11-05&sp=r&spr=https&sr=b&st=2025-11-18T14%3A51%3A10Z&sv=2025-11-05
that is the complete log
timo "Server failed to authenticate the request" :)
El_Che damn
timo ah haha there's more to t he link
now it works
El_Che gist.github.com/nxadm/a4b8d9007ebd...-leap-16-0 14:53
in case the action links is temporary
timo right. we'll need more info to go on than just the log output. something must be quite wrong for moar to segfault with the first .moarvm file it sees 14:54
15:04 linkable6__ joined, bloatable6__ joined
El_Che leap is a recent distro, just added to the build 15:06
(sorry I am on and off, in a meeting)
building in a loop to see if it 100% segfaults (I suppose) 15:07
15:08 bloatable6 left, linkable6 left
timo there's another segfault 15:11
15:12 tellable6 left, shareable6 left, tellable6 joined
El_Che only segfaults so far 15:12
timo does it spit out a core.$PID file in the CWD? that + the moar binary and libmoar.so would be good to have to find out what's going wrong. `strace -f` of the compiling step could also give a hint 15:17
maybe `strace -f -k` to get stack traces as well 15:18
El_Che I will try to run the build locally 15:19
timo AFKBBL
El_Che I am not able to do it soonish, I'll release without opensuse leap 16 15:20
ab5tract patrickb: Terminal::Print CI/CD re-triggered and all checks are green 17:14
japhb ab5tract: Pretty please can you set the Terminal::Print webhook to point to Geth for #mugs? 17:25
ab5tract japhb: sure, but ... how? :) 17:30
japhb ab5tract: Open the repo on github, go to the Settings page in the tab bar, go to Webhooks in the leftnav, click the Add webhook button, Payload URL should be webhooks.liz.nl/?chan=%23mugs and Content type should be application/json and for Which events, choose Send me everything. 17:33
ab5tract japhb: done! thanks for the detailed instructions 17:42
japhb You betcha! :-D 17:43
And thanks
Geth rakudo/r5317-role-it: c70122ad8f | ab5tract++ | src/Perl6/Metamodel/ParametricRoleHOW.nqp
Add an istype check on the role group

This addresses R#5317, which had the following test case:
   role R {}
   role S does R {}
   my R $v = role V does S {}
... (21 more lines)		 20:27
linkable6__ R#5317 [open]: github.com/rakudo/rakudo/issues/5317 [roles][Will be addressed in RakuAST] role-constrained variable does not accept derived role defined inline
21:00 librasteve_ joined 21:11 melezhik left

Powered by Cro and the Raku® Programming Language.

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

Thank you!