lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/03/25/2025-...n-rakuast/ 11:34
jdv [Coke]: the only place the extra 0 is used is on the branch push dst 13:00
maybe that addition you made to the release guide added confusion?
we could just rename the release branches if its causing trouble. maybe like rakudo "release-..." or whatever... 13:02
patrickb NativeCall has no support for varargs at all, correct? It seems the trick to just treat a vararg function as a non-vararg function does not work on all architectures. It namely fails on ARM MacOS with dyncall. 13:25
I validated that with a small c prog that uses dyncall directly and performs a call to a vararg function. It works when dyncalling it as a proper vararg function, but fails when doing a regular dyncall (the arguments don't survive). On Linux x64 it works. Only fails on MacOS Arm. 13:28
That's my little test prog: paste.sr.ht/~patrickb/c336c2664351...53563b319b 13:30
Strange enough the value that the vararg function sees is not completely off, but only differs slightly. I.e. the pointer is 0x16bce7590 on the outside and 0x16bce7540 on the inside. 13:33
Anyone knows if calling vararg functions like normal functions is expected to work or if it's undef behavior that just happened to work? 13:35
[Coke] jdv- no, the confusion was that the command to create the tar file *fails* for me when used with 2025.03 13:37
but *worked* with 2025.030 (worked, but then created the wrong folder)
jdv what is going on over there:) 13:39
[Coke] I would like to schedule something a few weeks out where I can show you how the moarvm process from my standpoint so we can figure out why it's weird for me. 13:40
and it may just be "will not paying attention". :( 13:41
jdv sure 13:42
Nicholas Wierdly I don't know about ARM varags ABIs. But IIRC "we" discovered that the x86_64 ABI for varargs differs from the ABI for fix arg counts. IIRC it was that for varargs one of the CPU registers is popluated with the value "number of arguments", but for fixed arg count functions that register is any old garbage. After all, the callee knows the difference 13:44
result - casting a varargs function (eg printf) to a pointer to a function that takes exactly one char * arguments
and then using tha tfunction pointer somewhere else
and kaboomy
busy with (other) meetings - can't really fill in further 13:46
other than "these seem to be bad cheating assumptions and they will catch you out later"
patrickb Nicholas: That's valuable information. So even on x64 we only managed to do it out of sheer luck. The only way forward then would be to put vararg support into Moar / NativeCall. Ugh. 14:09
Nicholas sorry, seems that I didn't document all the details back then: github.com/Perl/perl5/commit/ceab7...7540fe14f1 14:27
patrickb For vararg support, NativeCall will need to know the types of all the args that are passed. Since the signature doesn't tell for the variadic args, there needs to be some other way. I figure we want to explicitly specify the type when calling. Could an annotation on the capture work? 15:36
Also is there any potential in automatically determining the C type based on the variable type passed in in Raku land? (always keeping the ability to specify the type explicitly) We should probably start with only explicit types as a first step. 15:38
patrickb github.com/Raku/problem-solving/issues/473 15:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!