One of the challenges with the API will be memory management. C++ doesn’t bother with it, so it’s up to the programmer, but Python does bother with it, using a reference counting system.
Many API functions take a pointer and store it somewhere accessible after that function returns. In that case, and only in that case, you have to increment the reference count, so Python won’t delete the object prematurely. For example, BWindow::AddChild(BView **, …), and a number of similar interface kit functions. BMenuItem’s constructor doesn’t copy the BMessage. Etc.
I assume the BWindow interface constructor creates a new Python thread state and that it’s handled appropriately in all the callbacks etc. If not, of course that’s another thing to look into.
On macOS, there’s a way to create a “bridge” to call C++ from Swift. I haven’t seen an example of making such a bridge without XCode, though. I haven’t been able to try to see if it’s possible with the Haiku port of Swift, either. Maybe it’s already possible?
The HaikuDepot Swift is still at 3.1, although there looks like 4.2 was in the works on GitHub.
Reading this, i dont know if there’s a point on doing an “autotranslation” of the code using swig, if manual behavior has to be implemented in several places (better said, a lot of places) instead of crafting the api bindings manually with the required behaviour…
When I was looking at this 20 years ago, Swig didn’t look like the right thing, but I assume it has learned some new tricks since then, and anyway I don’t remember much about it. Anyway, just sort of guessing at what you mean - yes, there are some important details about function calls that aren’t captured by ordinary C++ declaration, so that stuff needs to be coded out in some way that can be fed back into Swig.
Sorry, i misswrote when self translating to english. I mean that depending on the amount of gotchas like donn reported, it might be easier/shorter to write the bindings (not “api”) in python.
i.e. you take 20h with swig and 50h manually implementing correct behaviour, instead of 80manually with human design (supposedly good).
however, the amount of boilerplate transformation that swig does is huge…
Good news. After my chat yesterday with the man from swig, the app no longer throws memory issues. Also removed the need for a helper class for octal type constants.
Just finishing tha last main hurdle, of overriding methods like MessageReceived and having it called in python.
Once that’s done I’ll make the app a bit more complex, then document an estimate for the initial and future level of efforts for creating and maintaining the bindings.
Came here to talk about this, I am not dissapointed. I will have a peek when you update the source, to see how it goes.
The override process didnt work for me in pybind11 ( better said i wasnt able to solve it yet) , so i am curious about how did you do it in swig to solve that.
Source code updated. I’m not handling the close message by using Quit On Exit as python needs to intercept this in order to know to quit itself. Hence the commented out work on renaming BApplication and providing an adapter class for it, along with a way to handle MessageReceived.
Been testing more things on pybind (just to test the library for alternative uses/project/at work) and bypassing the calls to the py side failed on my own tests (because when clicking the close button nothing happens)
I dont fully understand why you run the example on a thread tho, if the BApplication instance Run method should be blocking, while the BWindow runs on its own thread…
In any case, the swig file you have is much smaller than the cpp-file definition class for pybind11 that I have, and autodoes more things with the includes. For a function or a non-gui class itself i would take PB11 probably (as you can just use it in a “make” command with header only include), but for this, seems like a no brainer to do it on swig.
Just my 2cts, hoping not many gotchas are found on the way…
If Python still has a global thread lock, and I bet it does, that needs to be [re]acquired in MessageReceived and other hook functions that call into the interpreter.
I tried porting Go to Haiku, and at first I thought it wouldn’t be so bad since Go already generates Elf’s, and supports FreeBSD. However, Go ends up needing constants from the guts of the OS (signals, syscalls, this kind of stuff), and that’s where I had to leave it. If Go worked on Haiku, that opens the door for Docker.
I’m interested in getting Go working on Haiku too, for my own nefarious needs. I had a look at it a while ago but seemed to need to get IIRC 1.5 working, then use that to build the latest version of Go.
It doesn’t work. I’m currently lost in how Go & Haiku manage system calls and such. I tried to get started with the existing work, but I wasn’t successful. Instead, I started from scratch. Luckily the Go build environment is OS-aware, so if you tried to build for a new OS, it builds for the host OS with support for the host OS with support for the target OS, then rebuilds for the target OS. So for me, it was building a Linux version which understands and would later build for Haiku. My code is at https://github.com/rjzak/go/tree/go1.11.4-haiku.
That’s exactly why we dont have 1.5 running. I watched all the changes that were done on 1.4 (with syscalls done “by hand”) and tried to update a clean 1.5 version with them. 1.4+ have changes on the code where they were using some c-files and now code is in go files with go syntax, hence a code conversion has to be done too.
So… unless syscalls are done again in go-format to match the minimal version, probably means no further versions available.
I will have a peek when you update the source, to see how it goes.
better said i wasnt able to solve it yet) , so i am curious about how did you do it in swig to solve that.
