Generate C extension via DragonRuby

[AndyObtiva]

At RubyConf 2023, I met with Amir Rajan, the maintainer of DragonRuby, and he showed me a tool for generating Ruby C extensions automatically from C library header files (like LibUI for example). He said, we could use it as a quick shortcut to build the LibUI Ruby binding automatically instead of continuing to build by hand. The only catch is that DragonRuby runs on MRuby. But, he said that when it generates the C code, we can update all mrb calls to rb calls, and the generated code might end up working under MRI C Ruby too. That said, supporting MRuby is still useful as it can get access to MRuby features like compilation to native executable on Mac, Windows, and Linux (as well as mobile devices in the future).

In any case, I wonder if this could speed up your work on converting uiArea draw calls to a Ruby C extension.

To play around with it, please create an account on DragonRuby and share with me your account email (you can email me at "andy{dot}am{at}gmail{dot}com"). I can get you a free account subscription from the maintainer of DragonRuby.

In summary:

• We can use DragonRuby to generate MRuby Binding C Extensions for LibUI
• We can also use DragonRuby to generate CRuby Binding C Extensions for LibUI by renaming mrb calls to rb calls
• MRuby can be useful to enable native executable compilation under Mac, Windows, and Linux (in addition to phones)
• DragonRuby should provide a faster way to build Ruby C Extensions for LibUI, including uiArea draw calls.

[rubyFeedback]

Perhaps we could run both and have it as an option to allow which one to choose? That is we can use kojix2' manual code; and if what Amir said works, the automatic generation. And then we can compare for a while.

The only catch is that DragonRuby runs on MRuby. But, he said that when it generates the C code, we can update all mrb calls to
rb calls, and the generated code might end up working under MRI C Ruby too.

Perhaps a wrapper for that code could work.

That said, supporting MRuby is still useful as it can get access to MRuby features like compilation to native executable on
Mac, Windows, and Linux (as well as mobile devices in the future).

Would be cool too - more options. Even though I don't use mruby myself. I found that mruby is only really used by people
who know C very well. Whereas most MRI ruby users probably only know ruby itself very well.

Although if this is so easy, surely the ruby C devs know the scope of the support that is possible here? I mean we only have to look at the fiddle guys. They understand the magic of C. I only see random segfaults when I try to do stuff myself. :P

converting uiArea draw calls to a Ruby C extension

So I probably don't understand anything but can't we autogenerate such bindings for that part, and then check whether it works? I mean we would not need to have to convert all of libui-ruby to that, right? We could just use the autogenerated code that we need to use.

There is probably something I am missing here. From the description it sounds possible and a "low hanging fruit", yet usually there is some catch or drawback. I really should have learned C properly before ruby ... it feels as if the most important stuff keeps on happening in C.

[kojix2]

mruby is a tool for incorporating a Ruby interpreter into your favorite programs (often written in C).

Embedding mruby means that the program will be able to interpret the code. For example, if you compile Microsoft Excel with mruby embedded, you can use Ruby instead of VBA. This is a joke, but that is how it is used.

For example, a company in Matsue, where matz lives, uses mruby/c to control industrial sewing machines [Japanese].

[kojix2]

In my opinion, the really hard part is not writing C extensions, but maintaining native gems with sustainability.

Modern code completion systems like Copilot, are excellent and will automatically generate 80-90% of the code. libui's C-API is simple because it is designed to be called from other programming languages.

But once you start compiling libui-ng and the C extensions to create binaries, and then package them as native gems for each platform to distribute to people, it becomes a very hard job to continue...