[hoc-devel] Issue 27 in hoc: Updates for 64-bit and Objective-C 4

[<cod...@go...>]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 27 by mo...@deepbondi.net: Updates for 64-bit and Objective-C 4
http://code.google.com/p/hoc/issues/detail?id=27

Sorry for the lack of focus in this post (should it maybe be a Wiki page  
instead?), but it addresses a lot of different issues.

Apple's Objective C runtime, GHC and Cabal have all changed quite a bit  
since the last time this project got much attention.  This is mainly just  
an experience report on some recent work I've done updating HOC to work  
with the latest versions of each of these.

The work in progress is currently available at  
https://github.com/mokus0/hoc.  I'm using git because I find it so much  
more convenient than subversion.  Once it's all working again, I can push  
it back into SVN if that is preferred, or I'd be just as happy to take over  
managing the project if the current managers would like to move on, in  
which case I would probably move it officially to Github unless there's a  
strong community preference to keep it here.

There are several changes so far, with more to come:

- It builds with far fewer Cabal hacks, and the one remaining hack can  
easily be eliminated if we are willing to just abandon support for  
pre-ObjC-2 on Mac OS, which I think is a reasonable thing to do.  I think  
from an ease-of-building standpoint it is pretty close to ready for  
Hackage.  Getting to this point involved splitting it into two packages  
though - all the FFI imports are now in a separate "HOC-cbits" package.   
This was necessary because GHC loads all imported modules to support  
template haskell, and this is the easiest way to get the "c bits" loaded.

- It runs on x86-64.  This was by far the hardest part, and also still the  
most delicate.  Passing of structures in the ABI is poorly specified (IMO)  
and Apple's compiler follows it even more poorly.  Currently it uses a  
simple threshold that happens to get most cases right, but this definitely  
needs some more thought.

- It runs on Mac OS 10.7.  This required a few hard-to-track-down but minor  
changes.  Most notably, "id" values are not necessarily pointers and  
ffi_closures need special care when allocating to make sure they come from  
memory that doesn't have execution protection.

- The test suite is now configured to run via "cabal test".  This means  
that building requires cabal 1.9.2 or newer.

- base < 4 support has been dropped.  If necessary it wouldn't be hard to  
add back later.

Other work planned:

- More testing and cleanup of my changes.  The code as it stands now will  
not work properly when compiled 32-bit due to a few quick fixes I haven't  
yet abstracted properly, but I plan to clean up that stuff tomorrow.  Also  
it appears that Objective C exceptions are not always being caught and  
marshaled.

- The interface generator does not work on recent Cocoa headers.  My first  
thought is to update it to use BridgeSupport metadata files.  I seem to  
recall from an earlier look at this idea that there was not enough  
information in them to support the interface generator.  If that turns out  
to be the case then I'll either change the generated module s or update the  
existing design to parse the newer files.

If anyone has any thoughts on either the changes made so far or changes  
that need to be made, I'd love to hear them.