ShimmerFairy timo: I didn't check it at the time, but looking now, I think the issue there is that, in general, unassigned codepoints have the XX Line_Break value, but certain ranges of unassigned codepoints *instead* are assigned the value ID. So I think UnipropCheck is saying that MoarVM did (maybe still does?) return XX for unassigned points it should say ID on. 04:19
(Ideally, *none* of that %expected-loses workaround would exist, but Rakudo's unicode property handling leaves something to be desired at the moment anyway.) 04:21
05:50 kjp left 05:51 kjp joined 05:52 kjp left 05:53 kjp joined
ab5tract ShimmerFairy: I opened a problem solving ticket about uniprop a year or two ago but never managed to get a response :( 07:34
or 07:44
I should say I failed to spark a vibrant discussion 07:45
in short, my position is: the uni* family feels like it was designed prior to multiple dispatch, adverbs, and failure objects. At least it fails to utilize any of the above 08:04
ShimmerFairy Something I've been wondering about is how "outdated" the Unicode handling is in Raku, given the language's age. It's worth remembering that when Perl 6 got its start, Unicode was "only" about 10 years old, and things have definitely changed since then. 08:24
One concrete example is that S05 makes reference to NFG strings doing caseless matching as per UTS#18 RL2.4, but if you look that up in modern versions of UTS#18 that rule has been all but gutted, explicitly stating that full case-insensitive matching is too difficult to expect most regex engines to handle. (The modern version of the rule is that the existence of Str.fc() is enough to satisfy.) 08:26
08:44 librasteve_ joined
Geth nqp/main: d200536e77 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get outdated pointer fix, timo++
 09:13
patrickb timo: Can you give me a bit more information regarding src/spesh/disp.c? That's concerned with streamlining / generating byte code for the things in lib/NativeCall/Dispatcher.rakumod, correct? If so I would have thought that no changes are necessary. I probably miss something. Can you clarify? 09:18
timo sure, are you familiar with how the dispatch program mechanism works internally? 09:21
the part in spesh/disp.c is concerned with turning what would normally be interpreted by the dispatch program interpreter into bytecode instructions, so that further optimizations as well as the JIT can make things better 09:23
patrickb I read jnthns blog posts twice. But that's about it.
timo i'm thinking if you didn't put anything for handling variadic calls into the jit, we need to at least go through nativecall_dispatch or nativecall_invoke rather than jitting a C function call ourselves 09:24
patrickb Initially the dispatch program is some C structure that is worked through?
timo that's right 09:25
patrickb Sidenote: I think nativecall_invoke is entirely unused dead code and could be removed.
timo the debugging utilities for dispatch programs and dispatch recordings are a bit crude still
right, i suspected that that's the implementation we had before dispatch landed and was completely superceded 09:26
patrickb nativecalls always end up in nativecall_dispatch. There is no not / ops only variant of the code in that function, right? 09:27
timo how do you mean?
patrickb s/not/jit/
the nativecall_dispatch function does the actual setup and dynamic call using either dyncall or libffi. I can't possibly have missed a separate machinery doing the same thing via ops or jit machine code. Right? 09:29
So in other words I don't have to reproduce the same changes I made to nativecall_dispatch again some place else (as one sometimes has to do for jittable opcodes). 09:30
Geth rakudo/main: 820a4a94a7 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get outdated pointer fix, timo++
 09:59
timo sorry i was AFK for a moment 10:04
if the result from speshing the disp that belongs to a native call is still a sp_dispatch_*, src/jit/graph.c:3975 and following will spit out a MVM_JIT_NODE_DISPATCH that src/jit/x64/emit.dasc:3436 will turn into a low-level function call, but the function call goes to the run_dispatch function pointer that's stored in the inline cache entry 10:08
oh, actually, right above that in graph.c is handling for sp_runnativecall_* 10:09
that has a corresponding MVM_jit_emit_runnativecall in emit.dasc:3378 10:10
the good thing about jitting is that we don't have any need for dyncall or libffi at all 10:11
emit_posix_callargs and emit_win64_callargs would probably be the spot where handling the difference between before and after the `...` in the argument list would have to happen 10:12
ShimmerFairy By the way, I've always been curious about why we got rid of the Cursor/Match distinction. I just did a bit of digging, and am I right in concluding that it was "just" to avoid expensive copies? (As opposed to a deeper flaw in how the design of the whole system worked with two classes?) 10:38
releasable6 Next release in ≈3 days and ≈7 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft 11:00
patrickb timo: Oh. I absolutely didn't see that. Thanks for pointing me at that. This means var-args are pretty broken as soon as the jit kicks in, right? 11:01
timo that might be true 11:09
lizmat and that's why I didn't see and breakage on Apple Silicon 11:12
timo the nativecall tests we have are a little weak, i don't think they would show us if nativecall jitting was completely broken 11:27
ShimmerFairy: i don't know anything more than what you already concluded
ShimmerFairy For context, I'm only curious because I've been hacking together a grammar thingy in C++, and I've reached a point where splitting my one cursor class into two could make sense, but I was worried that there was a very good reason Raku went the exact opposite direction. 11:31
timo i assume you already went and read commit logs related to the changes? 11:32
lizmat if I remember correctly, originally there was a Match and a Cursor object ($/ and $cent), but at some point @larry decided that it would be better to have one 11:33
ShimmerFairy Yeah, that's how I finally answered my long-standing question. I asked here just to see if there was a second hidden reason. 11:34
timo it's really not trivial to follow such decision processes after the fact, is it? the problem-solving repo is a good thing to have 11:36
ShimmerFairy I still love $¢, even if there's no reason to type it anymore. Having forced myself to go through the steps of implementing a grammar engine, my feeling is that (aside from real-world efficiency concerns), there's no major benefit either way to having separate or joined Match/Cursor objects.
Personally, I think I prefer having a clean distinction between in-progress and completed searches, but in reality those two concepts are similar enough that smushing them into one class is barely noticeable. 11:39
11:46 finanalyst joined
[Tux] Rakudo v2025.11-44-g820a4a94a (v6.d) on MoarVM 2025.11-45-g380ad21ae
csv-ip5xs0.256 - 0.258
csv-ip5xs-201.094 - 1.112
csv-parser1.131 - 1.143
csv-test-xs-200.114 - 0.115
test1.848 - 1.886
test-t0.453 - 0.460
test-t --race0.280 - 0.281
test-t-205.825 - 5.885
test-t-20 --race1.415 - 1.435
 12:01
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
13:05 melezhik joined 13:06 librasteve_ left
[Coke] So do we think we're good for the release this weekend? 14:12
I can do a compressed blin run on just the 3 modules that pinged on the full one.
14:14 finanalyst left
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
15:27 melezhik left
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
16:46 finanalyst joined
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
17:09 finanalyst left
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
18:55 melezhik5 joined
melezhik5 have started brownie test om inline perl 18:56
on
19:02 melezhik joined
melezhik . 19:02
Test passed ok 19:03
19:04 melezhik5 left 19:24 rakkable left 19:25 rakkable joined 20:02 librasteve_ joined 21:12 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!