01:35 [Coke] left 01:37 [Coke] joined 14:26 librasteve_ joined
timo I copied over the contents of a dyncall checkout from hg and i'll have a look if dyncall r1.5 maybe doesn't have the problem any more 16:59
not fixed. there is still apparently no callUChar (or any variants of passing an unsigned argument), the C function, when compiled by clang, ends up comparing 0xfffffffe to 0xfe and getting 0 17:17
so what's the right way forward here actually 17:20
just deprecate dyncall and only support libffi from here on out? 17:21
[Coke]: you've declared this a blocker for the next release, any opinions? 17:23
librasteve_ rakudoweekly.blog/2026/06/01/2026-...ast-fruit/ 17:25
[Coke] We could deprecate dyncall on those particular combinations of compiler flags? 17:26
my goal: clean CI
timo no 17:27
we do not have any control over what a .so that the user wants to call was compiled with 17:28
this is literally the assembly that clang compiles the code to:
0x7f03873cb502: cmp edi,0xfe
0x7f03873cb508: mov eax,0xa
0x7f03873cb50d: cmovne eax,ecx
0x7f03873cb510: ret
well, it first xor ecx, ecx to clear that register 17:29
the code we compile is DLLEXPORT int TakeUint8(unsigned char x) { if (x == 0xFE) return 10; return 0; }
[Coke] let me rephrase this: if we know this can never work, why are we testing it to get failures? 17:30
timo it works with gcc
but we do not control whether code called by the user with their actual nativecall code will be compiled by gcc, clang, msvc, tcc, icc, or whatever else 17:31
[Coke] ... but we DO control our OWN CI 17:32
so why is our CI setup to fail?
timo you're saying we should kick out, or maybe #TODO, this one particular test?
[Coke] is the fix to todo that test in rakudo if we are on clang?
timo it is already todo'd but only on macos 17:33
[Coke] consensus!
timo though it should succeed on macos with gcc i would assume
it's really not cool that we have this "landmine" in nativecall, though I can't tell how many libraries out there may be impacted by this particular issue 17:35
presumably if the code does anything non-trivial with the argument it would normalize to only the lowest byte
[Coke] so if nqp -V | grep '^moar::cc=clang$', todo that test? 18:29
timo if cc is clang and the nativecall impl isn't dyncall i think 19:23
librasteve_: it's not exactly clear how much benefit moarvm can gain from zig. the total "performance" figure for any given thing you're running is made up of many different bits, and each bit has a different potential for being sped up with a different language 20:47
ideally, we would only be interpreting bytecode rarely and have jitted code most of the time, for example. making the interpreter itself faster can only improve the speed of not-jitted pieces of code
some things are the same when called by the interpreter or when called by jitted code, so improving these things makes both faster, but it only matters if that is a noticeable part of total run time and not just a blip 20:49
making spesh and jit themselves faster isn't worth so much, as they run in the background. all you can hope for is that getting an optimized version of a function out the door earlier means you run the slow un-optimized version less often before the optimized version kicks in 20:53
patrickb the midterm plan is to drop dyncall entirely and use libffi exclusively. There is still work to do though. 21:05
MasterDuke has been working on this. If I find the time I'm willing to get a Windows libffi build working, that's another dependency we need to solve. 21:07
librasteve_ timo: thanks for taking the time to explain that to an interested spectator, please forgive me for speculative remarks about the potential for Zig in MOARVM, my angle is more to raise awareness of our project than to present a well reasoned option 21:27
(luckily you guys are better engineers than I and I will confident you will continue to maintain the technical vision in spite of wild ideas) 21:29
my instinct is that C is a very hard tool to beat in projects such as MOARVM - I would hate to try and wrangle Rust code to be effective in this kind of binary image centric dynamic paging role 21:31
of all the new languages, I expect that Zig MAY be useful in some PARTS of the runtime … but there would need to be strong reasons to replace C even here and there and for large enough chunks of code to make running a hybrid toolchain worthwhile 21:33
perhaps a performant Copy-On-Write library that would let us follow through on Daniel Sockwell’s ideas from a couple of years back for immutable data sturcture 21:35
but that is even more speculation … ;-)

Powered by Cro and the Raku® Programming Language.

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

Thank you!