Geth rakudo: ugexe++ created pull request #6398:
RakuAST: set a stub's yada bit before applying its traits		 00:41
rakudo: ugexe++ created pull request #6399:
RakuAST: defer private method resolution when the package is composing		 01:07
rakudo: ugexe++ created pull request #6400:
RakuAST: return Nil from a QUIT phaser when its when/default succeeds		 01:28
02:12 ShimmerFairy joined 02:55 librasteve_ left 03:01 guifa left 05:38 hurufu joined 07:49 hurufu left 08:41 librasteve_ joined
librasteve_ rakudoweekly.blog/2026/07/06/2026-27-trf-lives/ 08:41
09:13 finanalyst joined 09:30 finanalyst left 10:57 librasteve_ left 12:08 librasteve_ joined 13:53 MBot_3265 joined
Geth rakudo: ugexe++ created pull request #6401:
RakuAST: allow a bare Whatever `where` constraint		 14:14
14:17 librasteve_ left
[Coke] OK. we got 2 votes for a moarvm point release. Is there a test somewhere to prevent this particular bug or something like it from sneaking back in? 14:20
(it's OK if that test is in NQP or higher)
(ok for me without me thinking about it too much, anyway)
timo well, there are no tests inside moarvm itself at all, so it would have to be nqp or rakudo 14:23
15:02 MBot_3265 left
aruniecrisps @librasteve was there any conclusion taken on the AI policy for core ? 17:28
ugexe github.com/raku-community-modules/...od#L63-L65 18:35
i hope nothing was actually using that :/ 18:36
sub OBJECT_BODY(Mu \any) is export { Pointer.new(any.WHERE + Offset); }
[Coke] aruniecrisps - not that I'm aware of 18:37
I suspect we're going to want more of raku.foundation in place before trying to come up with a definitive stance. 18:38
timo what's the problem with that code? ;) ;) 18:47
a garbage collection may happen in between that line and using the result? oh that would be so unfortunate 18:48
better hope your program or service is set up to automatically restart when it crashes 18:50
ugexe the offset calculation has the same issue but at least that can be brute forced to work i.e. retry until the .where at the start and end of the try match 19:16
timo as a moar dev I can only tut tut at anyone trying to directly pointer-access into the insides of structs 19:20
does the language spec say anything about what .WHERE should give? we could come up with a random per-process constant that we xor all WHERE results with to discourage users from trying to do something wild like this 19:21
ugexe according to the rakuast blin failures it is fairly widely used. although we only know that the offset calculation doesnt work since that is a compile time error. if that was fixed we might find most of the modules also depend on e.g. OBJECT_BODY in some way 19:22
timo i don't actually know what the compile time error in question is 19:28
ugexe the constant Offset in that same source file can fail 19:31
github.com/coke/raku-ast-blin-resu...12#L40-L47 this is how it presents itself
timo oh, that's what you meant 19:34
anyway, yeah, even after you fix that it'll still be dangerous to be doing what it's doing :) 19:37
ugexe i mean i meant both... i was going to attempt to fix the offset with brute force but then i noticed OBJECT_BODY and kind of wonder whats the point 19:38
19:40 GlitchSyndicate joined, GlitchSyndicate left
timo something kinda cool I can do now in the gdb plugin within an rr session is when a continuation gets taken I can show the spot where it gets invoked, like what thread and when on the timeline 20:06
the moar debugger really wants to get a stepping mode that can follow a continuation to when it gets invoked
Geth rakudo: ugexe++ created pull request #6402:
RakuAST: make every variable declaration a declarator doc target		 21:46
22:01 Observer joined 22:02 Observer left
Geth rakudo: ugexe++ created pull request #6403:
RakuAST: honor a custom declarator's companion attribute type		 22:22

Powered by Cro and the Raku® Programming Language.

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

Thank you!