Haiku-x64 port #1154
Haiku-x64 port #1154
Conversation
|
r_2_102_0_5_40_43299C_BFE1B1.log This is the log of the test suite. |
| @@ -620,7 +620,39 @@ static int uv__fs_readdir(uv_fs_t* req) { | |||
| if (dirent->name == NULL) | |||
| goto error; | |||
|
|
|||
| dirent->type = uv__fs_get_dirent_type(res); | |||
| #if TO_HAIKU | |||
There was a problem hiding this comment.
This file is part of libuv... it seems they think they support Haiku (notice the defined(__HAIKU__) cases in this file).
I'm hoping to not need to have a patched version of the files from libuv. Perhaps they would accept this modification as a PR (or have feedback on it)? Just changing the TO_HAIKU to defined(__HAIKU__) would probably be enough to start the discussion.
Perhaps also posting a note on this issue would send notification to parties who've previously expressed an interest in Haiku/libuv:
| @@ -732,7 +732,7 @@ extern z_const char * const z_errmsg[10]; /* indexed by 2-zlib_error */ | |||
| # define OS_CODE 10 | |||
| #endif | |||
|
|
|||
| #ifdef _BEOS_ | |||
| #if defined _BEOS_ || defined __HAIKU__ | |||
There was a problem hiding this comment.
The extraction for %sys-zlib.h and %u-zlib.c is actually done via a script that runs on the official zlib sources:
https://github.com/metaeducation/ren-c/blob/master/tools/make-zlib.r
Since the last capture was done it looks like they had a PR which added in some __HAIKU__ bits, but not this OS_CODE part:
https://github.com/madler/zlib/pull/830/files
That was very recent (July 29).
If this change is correct, then sending it as a PR to zlib would be ideal. Then I'd just re-run a capture, picking up any other potentially important patches.
| 0.5.40 haiku-x64/haiku "x64" | ||
| #SGD #LEN #LLC #LLP64 <DCE> /DCE %NWK | ||
|
|
||
| 0.5.75 haiku/haiku "x86-32" |
There was a problem hiding this comment.
The 0.5.75 version numbering was a joke based on the syllable pattern of 5-7-5 in Haiku poems.
But this hasn't really escaped into the wild anywhere. So if there's now a 32-bit and 64-bit version, then 0.5.4 and 0.5.40 would fit the pattern better.
If this build section is renamed to Haiku, then it's probably time that any references in Ren-C sources to BeOS in #defines can be dropped at this point.
| #else // Just try /usr/bin/open on POSIX, OS X, Haiku, etc. | ||
| #elif TO_HAIKU | ||
|
|
||
| rebElide("append", list, rebT("open %1")); |
There was a problem hiding this comment.
Glad you encountered the user API, it's kind of what kicked off Ren-C as a project:
https://forum.rebol.info/t/limiting-api-entry-points-in-favor-of-exchanging-strings/540
I think how this is accomplished is pretty neat (based on making sure all value cell and series don't have a first byte that could be from a legal UTF-8 string). It makes bridging with C literate, for a complex example see things like the ODBC extension:
ren-c/extensions/odbc/mod-odbc.c
Line 539 in 8a0da55
The way this stuff was done in R3-Alpha was very...unfit.
Ren-C fu is a whole new game (especially if you're dealing with the bootstrap process), so congratulations on getting things to work!
Oops--I jumped to read over the PR first, and repeated this point. Well as I say, it seems they're sincere about supporting Haiku. So seems just throwing a proposal their way and letting them give feedback on how they'd want to attack it could probably work out...
If it works for you and doesn't break anything else, I'll call it good enough. Rebmake is a catastrophe that turned out to be a somewhat educational catastrophe. I didn't write it, and the various pitfalls I encountered trying to keep it running fed back into the language design considerably...features like the distinction between NULL, NONE, VOID and BLANK! really came from how little of a safety net classical Rebol let you have: https://forum.rebol.info/t/shades-of-distinction-in-non-valued-intents/1604 Overall, looks good.. if you can take the zlib and libuv issues to them then the rest is mostly fine. Seems like it's about time to purge any BeOS references (outside of comments in systems.r for the historical versioning). |
|
Just to get this moved along I went ahead and merged it, and added a few patches to make it work with the bootstrap executables: I added comments regarding reaching out to libuv and zlib, lest the changes be lost in some future shuffle... |
Here are the changes I made to build on Haiku-x64.
Review carefully because my Rebol-fu is quite rusty.
Some changes are questionable (like stat()ing for each entry, but I didn't find any other way on Haiku) and could be considered misplaced (the stat() kludge probably belongs in libuv, but I didn't figure out how to access the directory descriptor).
I also had to change the make.r/rebmake.r stuff, generating makefiles didn't work for me.