27 Mar 2025
patrickb MVM_nativecall_invoke is effectively unused and replaced by MVM_nativecall_dispatch. Correct? 22:34
timo that's quite possible 22:45
patrickb Is it possible to put a trait on a capture? If so, is it possible to reach for that trait in the dispatcher when processing said call? 23:08
I'm off to bed soon, but will backlog.
timo oh, capture? i'm not exactly sure, but if the thing you want to put on it is only a few different kinds of values, you could parameterize a type 23:09
MVMCapture wouldn't allow something like mixing in roles to get more attributes, see, because only P6Opaque (and maybe CStruct?) can do that 23:10
patrickb I want to add a list of types of the variadic args on native-calls. 23:16
Context: I want to add vararg support to nativecall. I somehow need to specify the types of the variadic args when calling. 23:17
A named arg containing a list could do the trick. But syntactically an annotation would be more fitting IMHO. But maybe I'll just go for the named arg, because it's simpler. 23:18
github.com/Raku/problem-solving/issues/473 My ramblings surrounding this are captured there 23:19
lizmat couldn't the logic for setting up the nqp::istype list be used for that ? 23:23
timo do varargs actually care about types we may want to pass? 23:39
var args in C and the calling conventions we support is already very wibbly wobbly 23:41
we do want to have some stuff like "when passing a Str, it has to be encoded as a windows-style wide string" for example
that probably doesn't want to be specified at every call site, which would mean it should probably go near the sub declaration site 23:43
the "is variadic" trait could also go on the first parameter that is part of the variadic argument list
or on the last one that isn't
japhb timo: According to patrickb's research on a MacOS/ARM problem, varargs don't Just Work on the MacOS/ARM ABI. But of course they do on Linux/x64, which may have been why people didn't run into this earlier. 23:46
timo thinking of the possibly most common var arg functions printf and scanf, we'll want to be able to support at the very least "is rw" so individual args can be passed as "out" parameters. otherwise the user of the bound function would have to pass a CPointer 23:47
yeah, some ABIs need some information about the var args in a register IIRC. maybe the number of var args being passed?
presumably the system5 abi or whichever it is that we have on linux/x86 doesn't need anything like that and so if you just define a couple of subs that bind to the "sprintf" symbol and have different signatures it Just Works. maybe even with just a `*@args` parameter? 23:48
now, while we can't very easily put traits on a Capture, we can actually put information on a Scalar's descriptor if that would fit 23:57
28 Mar 2025
there's also the opportunity to have a "proto sub" for a variadic C (or other native) function that has the information about "variadicness" on it, and then one or many multi candidates for specific annotations going from specific to general 00:09
could even be the same trait for proto sub vs only sub
japhb Oh now that's an interesting usage (variadicity as a proto trait). 00:27
timo i think it makes sense from a "hook to hang it on" but it'd be annoying to have to make a proto + at least one multi for any vararg native function 00:28
proto and multi do have the syntax to put a "don't use anything to the right for deciding the right multi candidate" which is kind of the opposite of what we want here 00:29
i think it's ;; in the parameter list
and of course we might want to have a multi where each sub is bound to a different native symbol, so forcing the trait to be on the proto wouldn't be nice for that 00:30
japhb Hmmm, decent point. 00:35
I feel like it would be useful to get as close to `sub foo(*@args) is native {}` as we can would be nice, because slurpy arrays are the closest equivalent I can think of for variadics. 00:39
One possible way to think of it might be a sub-Signature applied to a Capture. 00:40
`sub foo(|c (Str, Str, Int)) is native { }` 00:41
nine Variadic calls don't differ from normal calls very much. In the end, it only comes down to the number of 64 bit integer and 128 bit float arguments respectively. There are no other argument types (on x86-64 but from a quick glance, ARM is similar). 07:46
We may need some extra information for Raku though like the mentioned is rw or string encodings. 07:48
In any case, these are certainly properties of the call site. After all the point of variadic functions is that the argument list can be different for each call.
patrickb Can we move this discussion to github.com/Raku/problem-solving/issues/473 12:21
I hope that makes keeping track of the different ideas easier. 12:22
nine: Yes, it's not much different. In dyncall it's two additional calls to dcMode() to set the mode before the first fixed arg and before the first dynamic arg. 12:23
But the question I think needs to be solved is where the types of the dynamic args come from. I agree it's a thing of the call site as long as we don't want to reduce the system in so far as having to specify each different type variant in a new declaration. (That's approach 1. in that p-s issue). 12:26
timo ah, amd64 system V abi has the number of floating point arguments inside the rax register 15:59
30 Mar 2025
Geth MoarVM: MasterDuke17++ created pull request #1928:
Bump mimalloc to v2.2.3		 01:04
MoarVM/main: 03e4fee65d | (Daniel Green)++ | 3rdparty/mimalloc
Bump mimalloc to v2.2.3
 01:35
MoarVM/main: e2d43f4f34 | MasterDuke17++ (committed using GitHub Web editor) | 3rdparty/mimalloc
Merge pull request #1928 from MasterDuke17/bump_mimalloc_to_2.2.3

Bump mimalloc to v2.2.3
MoarVM: MasterDuke17++ created pull request #1929:
Cleanup some compiler warnings and one ubsan runtime errors		 01:41

Powered by Cro and the Raku® Programming Language.

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

Thank you!