Long time ago I liked playing with Bethon (python implementation of BeOS’s API)
I remember I was using a 0.54 version, but today the only version available online is a 0.51 from a web archive.
So I started to search on my DVD Backups and I found it, a fresh tar.gz of Bethon 0.54.
Is someone interested? should I share it? if so, where?
Sent (hope it went ok)
After some adjustments in headers positions, it seems to compile (x86_gcc2) until it halts for BLocker with:
make[2]: Entering directory ‘/boot/home/Apps/Bethon-0.5.4/build’
cc -c -O -I…/base -DHAVE_CONFIG -I/boot/system/develop/headers/python2.7 BLocker.cpp -o BLocker.o
/boot/system/develop/headers/os/support/Locker.h: In function struct PyObject * PyBLocker_FromBLocker(const BLocker *, int)': /boot/system/develop/headers/os/support/Locker.h:35:BLocker::BLocker(const BLocker &)’ is private
/boot/home/Apps/Bethon-0.5.4/build/BLocker.cpp:541: within this context
I don’t know if there’s a simple trick to adjust the code, maybe someone skilled on C++
uploaded and confirmed.
If someone is dying to use BLocker objects from Python, he or she will have to figure out what to do here, but the easy way out is to just forget about that particular class. in the source directory, rename BLocker.dx to BLocker.dxx or whatever. Then back in build, run mkmake and you should have a new xmakefile with no BLocker, and you can proceed.
Then you’ll need to change at least one think in symbols - in the copy I’m looking at, mkdef assumes cc xxsym.c is going to create xxsym, not a.out. So the cc command needs -o xxsym
In the source I have here, printb is also modifed - what was
if (w ~ /B_/) {
is now
if (w ~ /B_[A-Za-z0-9_]*$/) {
… and you’ll need to edit the install script, to point it to wherever you decide this stuff should be installed where python will find it, somewhere in non-packaged I reckon. I haven’t tested it.
Thank you donn!
ASAP I’ll try those changes!
I followed your guide and I succeeded, I managed to install the modules to
/boot/home/config/non-packaged/lib/python2.7/plat-haiku1
but python don’t let me import those modules nor if them are in parent folder
Have I used the wrong place?
I guess so. Either a directory already in sys.path, or you have to add that directory. (It might be worthwhile to read up on that a little - I have a vague memory for example of an environment variable like PYTHONPATH, but it has been so long since I used Python that I’m not a good source of information.)
There are already a boat load of directories in sys.path, so I think I’d use one of those and not worry about fine distinctions. This particular distinction is useful if several hosts are sharing a python install, with a mix of installed applications and a mix of platforms. That’s a different lifestyle than we usually have here on Haiku.
Again you were right and your memory is good!
PYTHONPATH is the environment variable, which actually is null by default. Doing a “print (sys.path)” whithin python it shows the paths listed with python -m site
so I created /boot/home/.local/lib/python2.7/site-packages and put there the files created by make install
now it works fine… Only one problem left:
all the modules seems to work fine except
SupportKit,
when I do a import SupportKit it returns :
Traceback (most recent call last):
File “”, line 1, in
File “/boot/home/.local/lib/python2.7/site-packages/SupportKit.py”, line 30
BPrivate::B_GMT_TIME = 0
^
(the arrow points to the colon)
commenting out all the BPrivate::…
another error appears loading the module at line 321:
*B_EMPTY_STRING = 0
^
invalid syntax
Removing the * I was able to run my old app, and seems to work, actually I don’t know what those commented out strings do as the same strings are placed above without BPrivate::
I gather you have it working. The scripts that extract constant values from the Haiku header files apparently need some work. It would be surprising if they didn’t after all these years. Just from what I see here, I don’t imagine you’ll want to use B_EMPTY_STRING from Python code.