ugexe do you know how other language ffis handle varargs 01:06
the first thing that comes to my mind would be something like `sub var_fun(int32, **@varargs where * ~~ CNativeType --> int32) is native { * }` and then infer the types from what i passed. i.e. check that varargs contains only types that we know are c types or whatever so we don't have to guess or try hard figuring out what it should be 01:09
github.com/ffi/ffi/wiki/Examples#using-varargs here is how ruby does it fwiw 01:16
probably can't be much more help as i've not been in a C mindset in awhile 01:18
www.swig.org/Doc4.3/SWIGDocumentat...arargs_nn4 does make it all seem rather messy though 01:30
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2025/03/31/2025-...t-journey/ 12:25
lizmat the Missing serialize REPR function for REPR MVMContext (BOOTContext) error means we somewhere missed an nqp::scdisable op in the code, right ? 16:41
mandrillone I’ve been reading in the logs that you are rethinking nativecall. I propose that raku gets rid of it, and we should replace it with a raku->machine language interface that is much more simple. In brief, we do something similar to Perl pack and unpack to creates Bufs on the fly with binary data. Then we implement a “call” directive with two 19:38
Bufs arguments: the first is machine language code that gets executed the second gets placed as a pointer in the machine accumulator register
[Coke] "much more simple" in which direction? 19:39
that sounds more complicated for users.
mandrillone Depends, it’s a base upon which to build libraries that gets feature parity with what is already there 19:40
For instance one may want to call a c compiler to get the executable Buf
Maybe instead of putting the second buf on the accumulator, it gets copied on the stack 19:42
The key is that the abi would be simpler 19:43
We could keep the current way to pass callbacks using pointers 19:50
[Coke] I am not a c developer, but: would that be better than using one of the (two?) existing libraries we've integrated with already? would it be portable across multiple architectures? 20:21
mandrillone Take the case of calling a function with variadic arguments, fact is that only a C compiler knows how to do that. You would then make a C function that act as a trampoline between the rake interface and the C library. You could compile this function at BEGIN time using a c compiler, and store the Buf variable holding it in the precompiled file, or 20:26
in a .so file. Of course, there is nothing holding you from doing that with Nativecall, but  the same mechanism could be used for basically anything.
[Coke]: I fail to see the point of these two libraries, they are really both surrogates for C compilers 20:32
Also C is not the only interesting language
take for instance Rust, is there currently a way to call Rust from Raku? 20:33
mandrillone All these issues were solved 32 years ago by m$ for their VisualBasic programming language, when they based their whole OS around the COM standard. In the meanwhile, that has been deprecates 20:51
jdv com ports?! is it 1995 again?! 21:02
was is com and com+ way back when? meh. 21:04
japhb Don't forget DCOM. Because everyone in tech in the 90s needs to have something that gives them nightmares. 21:48
jdv :) 21:49
[Coke] I do not miss corba 22:01
tellable6 2025-03-31T21:59:36Z #raku-dev <finanalyst> [Coke] would you please look at the edit function on new-raku.
japhb [Coke]: Oh, SO agreed 22:14
[Coke] Even better, I got to work on corba at Enron! 22:23
japhb OK, that definitely beats my particular hell! 22:45
Geth MoarVM/main: 4 commits pushed by (Daniel Green)++, MasterDuke17++ 23:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!