So, Rebol 3 is open-source, and there’s a binary floating around for Haiku…awesome! Is the GUI expected for Haiku at some point? That’d be a wonderful way to fertilize the app garden of Haiku.
I will try to resurrect this thread, as I’m working a.) on Red and b.) wanted to ask/discuss some questions regarding Haiku.
@cipri
Red is more than a scripting language. It has a REPL, but you can also compile your code to native binaries, which is the big difference to REBOL. It also offers a DSL for system programming (Red/System Language Specification https://static.red-lang.org/red-system-specs.html). It can be compared to C.
Now to the part why I posted here.
Haikus API is mainly coded in C++, so it does not offer an FFI. This is the biggest issue for porting many new and great languages like Red, PONY, Haxe, and Nim (not that much, because it also compiles to C++) with GUI support.
Is there any information on how this issue could be tackled? Is writing a C wrapper around the BeOS API even possible? Are there any discussions or incentives regarding this topic?
Any info is much appreciated!
Thanks!
1 Like
I hope you get traction on this.
Look at Bethon for Python, at IUP for C and Lua (but I never finished this), and at various projects around SWIG and libcharlemagne for a more generic solution.
I think only Bethon managed to get somewhere, and currently it is not really maintained, so it probably needs a few updates to get back on track.
1 Like
Thanks.
Having a C API wrapper could work out as long as there are no fancy C++ features like templates, multiple inheritance, function overloading, exceptions etc. used. Is the Haiku API using any of those?
Implementing a high-performance IPC/RPC (COM-like, ICE-like etc.) would be the best solution in my eyes.
Mutliple inheritance is used in some places, function overloading is used a lot, exceptions and templates only rarely. But you can get around it if your C wrapper isn’t a 1:1 mapping of the C++ API, I’d say.
1 Like
If you look at Bethon … I’m sorry. (It’s mine. Hideous hacked together mess of shell scripts, awk, sed, m4.) May be hard to look at, and of course it’s very much about (old) Python internals. Later I also put together a Haiku API interface for Haskell, again reflecting the very different requirements of that language.
You’re right, you’ll need a C wrapper, for every member function in every class in the kit.
Most of the work for that can be automatic boilerplate, but it has to start with full specs for those functions 1) as implemented in Haiku, and 2) as implemented in your language. For the first, you can get started with the .h header files, but they aren’t enough on their own. C++ function types fail to distinguish between input and output parameters, for one thing. If foreign programming language support ever rises to the top of the list for Haiku development, this would in my opinion be the first step, a “machine readable” full API that specifies the storage expectations for each parameter, whether the function may write to it, etc.
The second step depends on the language, of course. You’ll often be returning values as function values where C++ has an output parameter. You likely won’t be able to support function overloading, so you may have to introduce some new function names. Etc.
It can be an interesting project, and the BeOS API is mercifully simple for C++ - basic C++ features, not much multiple inheritance. You will get only complaints for your trouble, because it will never quite have everything you can get with the underlying C++ API, and anyone who wants to write a real application would be strongly advised to learn C++, but for the occasional case at the margin where an application is better written in LanguageY and needs only a basic API, it’s great to have it.
2 Likes
It looks like Sean Healy’s HaikuLanguageBindings is still under active development, and is targeting both Perl and Python: http://haiku.healynet.org/cgi-bin/fossil/haiku-api-bindings/timeline
So that’s worth a look, then.
2 Likes