Haiku-PyAPI: Python bindings for the Haiku API

Software Native
21

It needs to be one file Be.so because modules reference classes from different files, so they need to be compiled together.
https://pybind11.readthedocs.io/en/stable/advanced/misc.html#partitioning-code-over-multiple-extension-modules

22

Build system done! Builds using jam -j$(nproc) should run in parallel, yielding a significant speed boost. Also, failed builds should be able to continue where they left off instead of restarting. :tada:

Looks like you’ve made progress with BeMatched. I can’t quite play it because when I click on a card…

terminate called after throwing an instance of 'pybind11::error_already_set'
  what():  AttributeError: 'Be.Button.BButton' object has no attribute 'IsEnabled'

At:
  /boot/home/Desktop/haiku/BeMatched/main.py(188): ok
  /boot/home/Desktop/haiku/BeMatched/main.py(133): MessageReceived
23

Sorry, forgot to push Haiku-PyAPI again.
How about having a ‘make install’ for the build system,
that copies the Be folder to the python vendor-packages?
And what about having an option for which python version to build for?

24

An install target should be easy enough. Choosing the python version is probably a bit harder but some kind of config file like Haiku has should work.

25

It could go in /system/lib/python3.9/vendor-packages/.
and i dont think it should be too hard to choose the python version,
we just need to change the -I paths for the build command.

26

Ah, sorry, I meant the hard part would be letting the user tell jam which python version it should compile for. A config file is one way of doing that.

27

Can it be given as an argument, or a target?

28

For example:
build-3.9
build-3.10
build-3.11
install-3.9
install-3.10
install-3.11

29

Ah, how ugly! You’re hurting my eyes! Just kidding :joy:

There is a way of passing arguments for the build script. It looks like jam install -spython-version=3.11 and would have to be specified every time you build or install unless we specify a default.

30

BeMatched runs now, thanks to the changes you’ve pushed.

For those curious, here’s a schreenshot:

BeMatched
BeMatched616×640 17.5 KB

9 Likes
31

Interesting topic, thanks for working on this! :ok_hand:

4 Likes
32

Nice job, thank you all very much for working on this!

Looking at that self.events thing in the original code example, maybe it might be possible for the bindings to support responding to BMessages using a Python function decorator, so roughly like this:

@BMessageHandlerFunction(self.START_MSG)
def start(self, msg):
       ...

That would eliminate the overhead for manually managing that event map and overriding MessageReceived() in every program.

Just an idea from someone who isn’t a Python expert by any stretch of the imagination.

33

Not really,
jam build should be aliased to build-3.10.
And -spython-version=3.11? You’re calling my codes ugly?

34

What! me? never. :smile:

Build-3.10 works fine enough but doesn’t scale very nicely. Imagine in some dystopian future… jam build-$python_version-$arch-$debug_or_release and us having to write code for every possible combination!

35

well, maybe -spy=3.11

36

Having decorators isn’t really possible, but now made self.events be there already, and removed the need for overriding MessageReceived.

1 Like
37

@BiPolar added python3.11 as an in between IIRC, so it shouldn’t be used a lot, python3.10 is “at this moment” still the default in Haiku, and python3.12 is in the works (kudos to @BiPolar there) :slight_smile:

2 Likes
38

It’s just an example.

39

Just thought I’d shed some info here, np :slight_smile: (you guys probably are still aware of this, but others maybe not) :slight_smile:

40

@ZardShard can you help me with the Jamfile?
I am having trouble with the install rules. :confounded: