|
Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes. Set by lizmat on 24 May 2021. |
|||
|
00:43
guifa joined
04:26
guifa left
|
|||
| ab5tract | patrickb: does variadic arg support connect meaningfully to supporting passing structs by value? | 16:40 | |
| patrickb | Sadly it does not. | 18:25 | |
| But I know a bit about that. | |||
| the dyncall lib only supports struct passing on x86-64. Libffi probably everywhere. Thus the first step would be to embed libffi instead of dyncall (I believe libffi has Windows support by now, so the original reason we chose dyncall isn't there anymore.) I suspect the rest is pretty trivial. | 18:27 | ||
| japhb | patrickb: Is there any performance difference between libffi and dyncall that you know of? | 18:33 | |
| tellable6 | 2025-04-25T07:34:52Z #raku <Xliff> japhb Are you still working on Terminal::Widgets? I may need your help with a ProgressBar implementation that it can use. Ping me. | ||
| japhb | I wonder why tellable6 took that long to deliver the message ... maybe I only talked to people on channels that didn't have whateverable presence? | 18:34 | |
| Whatever, I'd already worked with Xliff on that anyway | 18:35 | ||
| ab5tract | patrickb: that sounds promising! | ||
| patrickb | japhb: I believe there is no significant difference. | ||
| japhb | \o/ | ||
| patrickb | Fram what I know the only reason we went with dyncall was it's support of Windows that libffi lacked at the time | ||
| japhb | nodnod | ||
| ab5tract | Are the library APIs similar? | 18:39 | |
| I guess there are only so many ways to phrase “run this please” :) | 18:40 | ||
| patrickb | We already have libffi support! | 18:46 | |
| But we only embed dyncall, libffi currently needs to be installed separately and then used with the --with-libffi moar configure flag. | 18:47 | ||
| We'd need to embed libffi by default for us to be able to rely on features it provides, but dyncall doesn't. | 18:48 | ||
| ab5tract | I see I see | 18:57 | |
| patrickb | nine: I guess the code object approach results in nice APIs. But I'd not want to be forced to build the lowest layer with this. Having a wrapping function doing the extraction and then calling a lower level function with the explicit types seems cleaner. Then when binding a vararg function one is not forced right away to write such determine-my-types code. In the case of ioctl I'd not want to | 20:17 | |
| write such code at all. That function is growing over time and covering all the cases on all platforms is a huge amount of work. And then you won't use most of the possibilities anyways... | |||
|
20:42
mef left
21:14
mef joined
|
|||