So far as I underestand, Haiku will have C++ APIs.
This causes problems amongst high level and very high level language users. Some of those languages (like python and common lisp) uses ffi -systems which allows you to write wrappers in those languages for C library interfaces, unfortunately, they are not able to handle with C++ API.
How do you plan solving this issue?
So far as I underestand, Haiku will have C++ APIs.This causes problems amongst high level and very high level language users. Some of those languages (like python and common lisp) uses ffi -systems which allows you to write wrappers in those languages for C library interfaces, unfortunately, they are not able to handle with C++ API.
How do you plan solving this issue?
There has long, long been a python wrapper to the BeOS API.
On my long list of BeOS/Haiku related things to do is to provide a Ruby wrapper to the BeOS API. Python isn’t bad but I much prefer Ruby (I was using Ruby long before Rails and all the associated hype.)
SWIG is a nice system for automatically generating language bindings for a given C or C++ API, and that is the first thing I plan to try when I attempt to make Ruby bindings to the Be API. SWIG supports many different languages (including Ruby of course) in generating bindings.
Being able to write BeOS apps in Ruby would be a great productivity boost, if for nothing more than prototyping.
On my long list of BeOS/Haiku related things to do is to provide a Ruby wrapper to the BeOS API. Python isn't bad but I much prefer Ruby (I was using Ruby long before Rails and all the associated hype.)SWIG is a nice system for automatically generating language bindings for a given C or C++ API, and that is the first thing I plan to try when I attempt to make Ruby bindings to the Be API. SWIG supports many different languages (including Ruby of course) in generating bindings.
Being able to write BeOS apps in Ruby would be a great productivity boost, if for nothing more than prototyping.
Wow, supports C# even - that sounds pretty neat… if Mono ever gets ported, maybe that would be useful to build a Be API binding layer for C# code.
Wow, supports C# even - that sounds pretty neat... if Mono ever gets ported, maybe that would be useful to build a Be API binding layer for C# code.
Yeah SWIG is a very cool tool. Apparently it compiles with no problems on BeOS (something I intend to try soon.) Also I met the main SWIG developer at RubyConf 2001 and he was a real nice guy.
Being able to write BeOS apps in Ruby would be a great productivity boost, if for nothing more than prototyping.
Is this not what you are talking about?
Is this not what you are talking about?
That is just the Ruby language and its built in classes, etc., compiled for Zeta (I had to download and compile it myself for R5.)
What I’m talking about is writing C++ classes that expose the BeOS API to Ruby. Ruby cannot automatically interact with native code, it requires a layer in between. Though there are some extensions which allow you to load and run compiled dynamic libraries, the typical way is to write wrappers which sit in between Ruby and the native code. You compile these wrappers and then Ruby loads those like add-ons are loaded in BeOS. Then when you call a certain method on those add-ons in Ruby, the add-on “translates” that into a call to the native library code.
SWIG automates generating such wrappers.
Lisp is much more dynamic in doing those foreign function interfaces than ruby. Using SWIG would be performance decrease for me. I’d need a straight ffi into C++ ABI. Somebody said me that when you change to GCC 4, this would be possible. Another my fav language, forth is same kind.
Lisp is much more dynamic in doing those foreign function interfaces than ruby. Using SWIG would be performance decrease for me. I'd need a straight ffi into C++ ABI. Somebody said me that when you change to GCC 4, this would be possible. Another my fav language, forth is same kind.
Well Ruby itself is pretty slow compared to any compiled code, so the slow-down from putting a SWIG layer between Ruby and the BeOS API would be neglible compared to the slowness of Ruby itself. But I feel the greatly decreased development time from using Ruby is worth the performance loss. But for most real-world apps on reasonably fast hardware, Ruby is plenty fast enough.
But a Lisp interface to the BeOS API would be neat too. I’d probably play with it, but let’s face facts: cool as it is, most modern programmers just won’t touch Lisp. A future Ruby interface and the current Python one are more accessible to most programmers.
I face reality too: I use Lisp, I don’t care who doesn’t use because it is better to me that they doesn’t use. I rather keep the power I get from advanced text editors and power of morphing Lisp as my own knowledge. 
I just find you guys funny who says ruby or python could reach the same power what Lisp has. Not for twenty years! And usually programmers are ignorant enough, so I gues I can keep Lisp as my own knowledge for long time and kick “modern programmer”'s ass for good as future programmer.
Anyway, I think many else HL programmer, who wouldn’t use Lisp, would benefit from straight C++ foreign function interface.
Most of the problems anyone attempting to wrap the BeOS API basically boils down to the following problems:
Is a parameter to a function for input, output or both? E.g. status_t get_mouse_map(mouse_map *map). Need to annotate (preferedly in the function declaration itself) the types of a parameter.
Are you responsible for allocating memory when sending in a pointer. If so, does the acquire the memory? If not, is it you or the function that is going to release the memory when done?
Related to the previous point are funny classes like BLooper, which you don’t delete yourself, i.e. the target language shouldn’t assume ownership and garbage collect it when it goes out of scope. Same thing when passing native (target language) objects from/to the C++ world.
Should a “bad” (i.e., status_t != B_OK) map to an exception? That’s common practice in Python. See http://bits.jansson.be/extender/wiki/ApiConventions for a brief discussion.
Then, there are a few problems about converting types from/to the target language. Most often this can be done automatically without needing to give a hint to the wrapper generator.
When this is done, it’s easier to generate code for bindings. My plan is to generate SWIG code, still planning to make the app flexible enough to accomodate different wrapper generators, for example a custom one. Which is often faster, as SWIG will flatten your C++ class and re-generate it on the C++ side, whereas Boost and similar efforts will have only a pure C-based wrapper.
– tic
Hi all,
To resurrect an old thread, and a topic which was recently touched on one of the MLs:
Earlier this year, I did some work with swig and ruby bindings for Haiku. It is very early stages, but BWindows and manipulating some objects work. See http://poorcoding.com/art/rube.html.
Here is a simple BApplication code and output screenshot: http://poorcoding.com/art/pub/screenshots/RuBe-BWindow.png.
It is not even close to being complete, unfortunately I have not had time to progress it further these past months.
Regards,
arfonzo
