🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
Geth rakudo/lizmat-span: 9f44aca38b | (Elizabeth Mattijsen)++ | 8 files
Implement Haskell's "span" in 6.e

Inspired by stackoverflow.com/questions/728094...n-function
This implements both the method as well as the sub version of "span".
For more flexibility, the condition can also be a List of conditions ... (17 more lines)
06:30
rakudo: lizmat++ created pull request #4976:
Implement Haskell's "span" in 6.e
Geth rakudo/lizmat-span: 8a5a36bc7d | (Elizabeth Mattijsen)++ | 2 files
Generalize the matcher on span

Instead of just allowing a Callable, go for smart-matching instead.
   .say for (2, 2, 2, 5, 5, "a", "b", "c").span: Int;
   (2 2 2 5 5)
   (a b c)
   .say span Int, 2, 2, 2, 5, 5, "a", "b", "c");
   (2 2 2 5 5)
   (a b c)
12:49
|Tux| Rakudo v2022.06-33-g6dc2f92c9 (v6.d) on MoarVM 2022.06-6-gc315523ab
csv-ip5xs0.782 - 0.921
csv-ip5xs-205.218 - 5.599
csv-parser3.616 - 4.037
csv-test-xs-200.403 - 0.417
test6.867 - 6.868
test-t1.393 - 1.737
test-t --race0.843 - 0.920
test-t-2020.438 - 20.729
test-t-20 --race6.586 - 6.691
13:13
locria Hello, Raku devs 13:19
Is there any plan to add full C FFI to NativeCall?
lizmat I don't know of any concrete plans
locria This was discussed over a year ago
I want to help, but I don't know how to 13:20
lizmat perhaps nine patrickb vrurg have ideas 13:21
locria I know how to use libffi, but not the internals of moarvm
Can IRC bot ping user on discord? 13:22
lizmat not sure, don't think so 13:23
locria How do I contact them
lizmat hopefully they react to the ping on this channel.... or you could create a Rakudo issue ? 13:26
vrurg An issue would be better. And I'm barely an expert with nativecall and moarvm. 13:28
patrickb locria: Thanks for your offer to help! I think nine is the one to ask. Creating an issue at github.com/rakudo/rakudo and pinging @niner there is a good start 13:31
locria thanks 13:35
nine We already have a libffi based backend for NativeCall. Extending that wouldn't be a problem. I don't even see anything keeping us from switching the default over from dyncall. The two issues are really elsewhere. 14:19
First, more libffi or dyncall is the wrong direction. We want less of those. We already compile many calls to x86 code directly making those native calls almost the same speed as well actual native calls. 14:20
Second the real blocker is not even that, we have already JIT code passing structs to native functions, so we know what the ABI looks like. The real blocker is the API one. I simply haven't seen any good idea on what such native sub definitions would look like. 14:21
Right now sub foo(MyStruct) is native { !!! } is a definition for a void foo(MyStruct*) { ... } function. It would have been easy if the NativeCall definition for that would be sub foo(Pointer[MyStruct]) { !!! } for foo(MyStruct*) and sub foo(MyStruct) for foo(MyStruct) 14:23
vrurg nine: sub foo(MyStruct $v is rw) { !!! } 14:34
nine What would foo(MyStruct **) then be? 14:35
vrurg sub foo(Pointer[MyStruct] $v is rw) { !!! }? 14:36
Or we could use a dedicated trait for that. `is pointer`, `is ppointer` or alike.
Pointer[MyStruct] semantics should be there too, though. 14:37
Pointer[Pointer[MyStruct]] is just too cumbersome, hence the trait idea. 14:38