| 17 Dec 2025 | |||
| lizmat checks if Inline::Perl5 installs now | 14:17 | ||
| installs fine now, so I'd say we're good | |||
| [Coke] | OK. as "usual", I have a volunteer thing saturday morning. we'll see how I feel about getting a head start friday night - please no more big stuff before the release. | 14:26 | |
| lizmat | I hope to be able to fix one RakUAST localization issue, but that will only affect when running with RAKUDO_RAKUAST=1 | 14:31 | |
| before the release, hope that's ok | |||
| disbot6 | <jubilatious1_98524> @shimmerfairy I remember when @guifa had written an SO answer-or-two that used $cent, that's when I looked it up? No idea what happened afterwards. | 14:59 | |
| [Coke] | lizmat: that's fine | 15:19 | |
| lizmat | so just saw a slow benchmark on Mastodon, caused by using (*@a) rather than (@a) | 16:05 | |
| and I was thinking: in RakuAST, if we see a multi sub / method with a *@foo signature | |||
| and there is no candidate with (@foo) signature | 16:06 | ||
| why not automatically generate a candidate: bar(*@foo) { bar(@foo) } and change the signature of the sub/method found to (@foo) | 16:07 | ||
| also, maybe: if it was an only sub / method: add a proto and make 2 candidates? | 16:10 | ||
| m: my @a = ^1000; my $then = now; sub foo(*@b) { }; foo(@a) for ^1000; say now - $then | 16:19 | ||
| camelia | 0.709933255 | ||
| lizmat | m: my @a = ^1000; my $then = now; sub foo(@b) { }; foo(@a) for ^1000; say now - $then | ||
| camelia | 0.000715315 | ||
| lizmat | m: my @a = ^1000; my $then = now; multi foo(*@b) { }; multi foo(@b) { }; foo(@a) for ^1000; say now - $then | 16:20 | |
| camelia | 0.000835773 | ||
| lizmat | slurpies are expensive | ||
| timo | does that give different behaviour when Slip or something like that is involved? | 16:54 | |
| ShimmerFairy | I don't know anything about RakuAST, so all I can say at first blush is that feels like an optimizer task. "Oh, only one of (*@a) and (@a) is ever used for this function's signatures, let's use whichever one is quicker/cheaper" | 16:56 | |
| timo | m: sub star(*@b) { dd :@b }; sub nostar(@c) { dd :@c }; star((1,2,3)); nostar((1,2,3)) | ||
| camelia | :b([1, 2, 3]) :c((1, 2, 3)) |
||
| timo | well, my example doesn't use multi | 16:58 | |
| lizmat | the @foo signature binds, the *@foo signature creates a whole new array | 17:00 | |
| so if you call bar(@a) with 100000 elemens in @a, it will *copy* all those elements to a new array | |||
| bar(*@a) rather :-) | |||
| timo | so if the code is doing something like @b.push it would change the array you passed in if we automatically generate a no-slurp candidate for you behind the scenes | 17:01 | |
| lizmat | yeah | ||
| timo | feels slightly foot-gunny | ||
| lizmat | so yeah, maybe that's too tricky | ||
| meh | 17:02 | ||
| timo | stuff is tricky | 17:03 | |
| ShimmerFairy | That would be a nice thing to improve, and it seems to me the optimizer is the perfect place to figure out when and where you can fiddle with things behind the user's back. | 17:04 | |
| timo | static optimizer may not be able to do too much, given how much late-binding raku supports and how much funky stuff the user may do after the optimizer has had its say | 17:09 | |
| moarvm's dynamic specializer can do speculative optimizations but it's very "close up" to the thing and doesn't have simple access to higher-level information | 17:11 | ||
| if there's stuff that can be expressed as a dispatch, that can give the runtime a lot of power to do stuff cleverly, but that doesn't apply easily everywhere | |||
| lizmat | I wonder if we somehow could make a Scalar container object that would be considered read-only, depending on an external flag (rather than in the object itself) | 17:17 | |
| and put that flag in the array and create a new array object for the (@foo) signature case, using the same underlying nqp::list | 17:24 | ||
| unless "is raw" is specified: (@foo is raw) | |||
| timo | the Array could have AT-POS that returns a re-containerized value and BIND-POS that dies or something? | 17:29 | |
| then it could just™ have the underlying nqp::list in its whatsitcalled $!reified? | |||
| unclear what to do if there is a todo or other kind of reification involved | 17:30 | ||
| lizmat | also ASSIGN-POS | 17:31 | |
| but yeah, that's be a solution as well | |||
| probably easier to do | 17:32 | ||
| timo | and STORE | 17:35 | |
| lizmat | yuo | ||
| yup | |||
| melezhik5 | have started brownie test om inline perl | 18:56 | |
| on | |||
| melezhik | . | 19:02 | |
| Test passed ok | 19:03 | ||