I can add that the NativeCall interface works exceptionally well, even allowing one to pass a Raku sub, closure, or anonymous block as a callback into a C function.
For example: https://raku.land/cpan:FRITH/Spreadsheet::Libxlsxio On Wed, Sep 29, 2021 at 11:14 AM Simon Proctor <simon.proc...@gmail.com> wrote: > I'm sure there are people who will be able to give some more information > than me but I will say you can do worse than reading the documentation on > NativeCall. > > https://docs.raku.org/language/nativecall > > I've played about with it a bit and it really is quite simple to get > started with. Generally you can directly map to a C/C++ call and then wrap > that in a nicer interface if you want to. > > Some example modules already using it: > > https://raku.land/cpan:MARTIMM/Gnome::Gtk3 > https://raku.land/cpan:TIMOTIMO/SDL2::Raw > https://raku.land/github:JJ/SDL2 > https://raku.land/github:hartenfels/Text::Markdown::Discount > > (There's a bunch more too). > > Good luck :) > > > > On Wed, 29 Sept 2021 at 08:49, YueCompl via perl6-users < > perl6-us...@perl.org> wrote: > >> Also asked at >> https://www.reddit.com/r/rakulang/comments/pxqaxi/whats_native_ie_highmachineperformance_hybrid >> >> >> Greetings! >> >> u/raiph is really a great evangelist, months ago, he swept away my >> (wrong) assumption that Raku must be mostly old school PERL, and keep >> impressing me with fantasies already done by Raku. Recently being [compiler >> in minutes](https://www.youtube.com/watch?v=rxaB6m_sQKk). >> >> I'm considering seriously the realworld adoption of Raku in my work, so >> I'd like to ask this. >> >> My current (private) framework facilitates the writing of high >> performance tensor components in C++, those get assembled to computation >> networks with Python scripting at runtime, then run mostly in C++ code but >> occasionally call back to script code. There had been even older workflows >> with Boost, but I started with Pybind11 a few years ago, with the approach >> pretty much described in [this SO answer]( >> https://stackoverflow.com/a/50125447/6394508). >> >> As our business develops, more and more expressiveness is demanded, >> Python magic methods way of language tweaking becomes a limiting factor >> gradually. We are currently using a custom scripting language I implemented >> fresh new, atop Haskell/GHC, with script-assemblable >> high-machine-performance components writable in the `IO` and `STM` monad. I >> share many of Raku's design ideas in implementing that PL, but failed to >> discover that before u/raiph caught my attention to Raku. >> >> Apparently Raku is more mature and feature rich than my current piece, >> especially in syntax customization, that we demand heavily. >> >> But I'm not clear by far, what's the approach for Raku code with native >> parts get developed with good ergonomics? >> >> The native parts is not expected to be C/C++, but some PL with moderate >> raw machine performance, and ergonomics is very important, so manual memory >> management is a deal breaker for us. For example, Go's machine performance >> is acceptable by us, but Rust is not due to memory management burden (even >> though much more principled than C). >> >> The scripting part cries for flexibility and clean-ness in >> syntax/semantics, toward purity of business concerns, ideally no computer >> implementation concerns should surface to the scripting grammar, machine >> performance in scripting is not sensitive at all, since it is just to build >> one variant of the business program, the "real" run of the program should >> mostly consist of compiled native code. Though calling script parts back, >> meanwhile the high-performance run, is also desirable in a small number of >> scenarios. >> >> That said but Julia's approach - LLVM based JIT from scripting, is not >> affordable by us, we have no expertise in machine code generation, even the >> simpler IR manipulation. >> >> Also debuggability in the native code part is crucial, C++ served us well >> in this regard, VSCode etc. can attach to a Python process and set >> breakpoints on the C++ code, then step through the suspicious code path. >> >> Haskell is far from on par w.r.t. stepping debuggers, but bugs are >> interestingly less with it, for unutterable reasons. >> >> Best regards, >> Compl >> >> > > -- > Simon Proctor > Cognoscite aliquid novum cotidie > > http://www.khanate.co.uk/ > -- Fernando Santagata
