8 Jan 2026
patrickb the undeclared routines are what I see as well. that's caused by that "*.&method-name()" syntax. 05:43
timo to be fair, `*.&method-name()` is not a syntax we have to my knowledge? we do have `*."$method-name"()` though 07:57
ShimmerFairy m: sub foo(Int $a) { $a * 2 }; say 42.&foo; say "ABC".&foo 09:05
camelia 84
Type check failed in binding to parameter '$a'; expected Int but got Str ("ABC")
in sub foo at <tmp> line 1
in block <unit> at <tmp> line 1
ShimmerFairy timo: it does exist, at least for using subs as if they were methods
timo ok, but then i wouldn't call that "&method-name" 09:06
patrickb github.com/ugexe/zef/blob/main/lib...kumod#L343 10:09
that's one of the places. It does work on the legacy compiler. 10:10
timo do we not have that tested in roast, or is that just marked todo? 10:16
melezhik . 12:18
lizmat dev.to/lizmat/raku-resolutions-17g7 13:19
Geth nqp/main: 6eb71d27b0 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get timo++'s alignment fix
13:33
rakudo/main: fb0142fe54 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get timo++'s MoarVM alignment fix
13:37
lizmat fwiw, it feels like it's gotten about 5% slower after this :-( 14:06
at least on MacOS
(without JIT) 14:07
timo that's odd, as this would only impact the spesh thread itself, which runs in parallel to the actual program 14:17
lizmat ok, let me rephrase: profiled code appears to be working about 5% slower 14:18
would that make sense?
timo that is also strange 14:19
lizmat well, again, this is on MacOS on Apple sillicon, so no JIT
timo the only user of the region alloc is spesh 14:21
whether jit or not should not matter. the region alloc's main feature is that once spesh is done with a given function the whole region is thrown away at once 14:23
lizmat ok, well maybe my CPU is getting pinched somehow 14:24
[Coke] releasable6: next 14:41
releasable6 [Coke], Next release in ≈9 days and ≈4 hours. There are no known blockers. 8 out of 12 commits logged
[Coke], Details: gist.github.com/330e80eb39d27d4ef6...327aeb5854
timo lizmat: we need to find you something that uses performance counters or something like `perf stat` does so you don't get misleading results from other processes interfering, or something like that 17:05
can't seem to find anything that's like `perf stat` as in "run it with your command and immediately see some stats", the closest you can get is apparently to create a trace file with either microsoft's xctrace for apple or with apple's own `instruments` CLI tool (not to be confused with the GUI tool of the same name that does the same thing but not on the CLI) and then feeding the trace file into 17:25
an analysis step
ab5tract m: Q|sub foo($s) { "foo " ~ $s }; [1,2,3].map: { *.&foo.say }|.AST.EVAL 17:32
camelia ( no output )
ab5tract m: sub foo($s) { "foo " ~ $s }; [1,2,3].map: { *.&foo.say }
camelia ===SORRY!=== Error while compiling <tmp>
Malformed double closure; WhateverCode is already a closure without curlies, so either remove the curlies or use valid parameter syntax instead of *
at <tmp>:1
------> oo " ~ $s }; [1,2,3].map: { *.&foo.s…
ab5tract ahh, of course 17:33
m: Q|sub foo($s) { "foo " ~ $s }; [1,2,3].map: *.&foo.say |.AST.EVAL
camelia foo 1
foo 2
foo 3
ab5tract So the syntax is fine. The issue is that those subs aren't lexically available
patrickb Rewriting the zef sources to do `.map: { sub-name($_) }` instead makes it progress though. 21:16
lizmat .map(&sub-name) ??? 22:24
timo lizmat: only the same if sub-name only takes one argument, not sure if that's the case in the code in question 22:42
lizmat sub-name($_) appears to suggest that ?
timo could have optional parameters 22:54
lizmat m: sub a($a, $b?) { $a * $a }; say (^10).map(&a) 22:56
camelia (0 4 16 36 64)
lizmat that works, no ?
ah... ok
gotcha
9 Jan 2026
patrickb github.com/ugexe/zef/blob/main/lib...kumod#L343 this is one of the places with that code 08:34