CPP, Leopard and Haskell Objective-C bindings

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

CPP, Leopard and Haskell Objective-C bindings

Joel Reymont
It seems that the current approach taken by HOC is to strip  
preprocessing directives. This may not have been a problem before  
Leopard but Cocoa header files are now full of macros in most unusual  
places, e.g.

@interface NSObject (NSDeprecatedMethods)

+ (void)poseAsClass:(Class)aClass  
DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER;

@end

I'm trying to figure out the easiest way to run CPP over the header  
files before processing them in HOC.

Is there a CPP written in Haskell and packaged as a library?

Does someone have a quick Haskell solution for running CPP over a  
header file (with include paths?), redirecting into a temp file and  
reading that back into Haskell?

Should I preprocess all Cocoa header files using make and then read  
these in?

        Thanks, Joel

--
http://wagerlabs.com





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: CPP, Leopard and Haskell Objective-C bindings

Malcolm Wallace
> Is there a CPP written in Haskell and packaged as a library?

Yes, cpphs, which can be used either as a stand-alone tool or as a
library.

    http://haskell.org/cpphs

Regards,
    Malcolm
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: CPP, Leopard and Haskell Objective-C bindings

Wolfgang Thaller
In reply to this post by Joel Reymont
On 6-Nov-07, at 5:00 PM, Joel Reymont wrote:

> It seems that the current approach taken by HOC is to strip  
> preprocessing directives.

True. Additionally, some of those strange macros are just interpreted  
as language keywords by the parser.

> I'm trying to figure out the easiest way to run CPP over the header  
> files before processing them in HOC.

That is not exactly what we want, I think. Currently, HOC parses  
things file-by-file, so we do NOT want to follow #include directives.  
We might just process the line pragmas from CPP to keep track of where  
things came from, OTOH.

> Is there a CPP written in Haskell and packaged as a library?

There is "cpphs".

As a quick solution, I'd say we run the HOC InterfaceGenerator over  
the 10.4 SDK in /Developer/SDKs/ (which has all the "old" headers).

I'm still working on cleaning up my InterfaceGenerator rewrite (I  
didn't have enough time to finihs last weekend, so maybe next weekend,  
but at least I'm motivated now). I think any more more elaborate  
improvements to the interface generator should be based on that  
instead of my old code.

Cheers,

Wolfgang

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: CPP, Leopard and Haskell Objective-C bindings

Joel Reymont

On Nov 6, 2007, at 6:57 PM, Wolfgang Thaller wrote:

> That is not exactly what we want, I think. Currently, HOC parses  
> things file-by-file, so we do NOT want to follow #include  
> directives. We might just process the line pragmas from CPP to keep  
> track of where things came from, OTOH.

You _do_ need to pre-process. Witness the following:

@interface NSWindow : NSResponder
#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_5
<NSAnimatablePropertyContainer, NSUserInterfaceValidations>
#else
<NSUserInterfaceValidations>
#endif
{
     /*All instance variables are private*/
...

It breaks the HOC parser.

> I'm still working on cleaning up my InterfaceGenerator rewrite (I  
> didn't have enough time to finihs last weekend, so maybe next  
> weekend, but at least I'm motivated now).

I'll be waiting anxiously.

> I think any more more elaborate improvements to the interface  
> generator should be based on that instead of my old code.


Maybe I can merge my changes when you are ready. What are your  
improvements to the interface generator?

        Thanks, Joel

--
http://wagerlabs.com





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

HOC is dead! Long live HOC!

Joel Reymont
In reply to this post by Wolfgang Thaller
BridgeSupport [1] is new functionality in Leopard that makes the  
current Haskell Objective-C bindings (HOC) obsolete (almost).

---
The metadata is intended to be a resource for use beyond bridging.  
Most frameworks on the system provide two chunks of XML BridgeSupport  
metadata; succinct and full.

The succinct version contains all of the metadata not provided by the  
Objective-C runtime (which provides about 80% of what is necessary to  
do full fidelity calls in / out of Objective-C via libffi).

The full version contains just that, the full metadata required to  
describe the APIs of the framework, including all the bits that could  
be gleaned at runtime.
---

BridgeSupport makes it unnecessary to parse Cocoa headers since all  
the required data is right there in plain XML [2]. It's no longer  
necessary to bundle libffi with HOC either since Leopard comes with a  
much improved version.

I hereby propose to close up the old HOC project on SourceForge and  
set up a new one at GoogleCode. I already did this but GoogleCode  
noticed the SF project and is now waiting for permission from Wolfgang  
and Andre.

        Thanks, Joel

[1] http://www.friday.com/bbum/2007/10/27/pyobjc-20-pyobjc-in-leopard/
[2] /System/Library/Frameworks/AppKit.framework/Resources/
BridgeSupport/AppKitFull.bridgesupport

--
http://wagerlabs.com





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HOC is dead! Long live HOC!

Wolfgang Thaller
On 7-Nov-07, at 5:14 PM, Joel Reymont wrote:

> BridgeSupport [1] is new functionality in Leopard that makes the  
> current Haskell Objective-C bindings (HOC) obsolete (almost).

"Almost" here means about five to ten percent of the code ;-). If the  
BridgeSupport files really contain all the information we need, then  
we can indeed drop the Objective-C parsing code from HOC and use a  
BridgeSupport parser instead.
Unfortunately, that parser itself is less than 500 lines out of 7000  
(in the HOC library and the InterfaceGenerator taken together). But  
the sheer beauty of having someone else maintain the parser for us  
should make it worthwhile.

One big piece of information we need that is currently missing from  
the BridgeSupport files is which declaration comes form which header  
file. HOC's module structure currently follows Apple's .h files, and  
we need the module system for resolving naming ambiguities. So either  
we need to change that, or we need to get the information from  
elsewhere. There might be other small things missing, we'll have to  
carefully look at the details.

> [...] It's no longer necessary to bundle libffi with HOC either  
> since Leopard comes with a much improved version.

Yes, that's one great little addition to Mac OS X :-).

> I hereby propose to close up the old HOC project on SourceForge and  
> set up a new one at GoogleCode. I already did this but GoogleCode  
> noticed the SF project and is now waiting for permission from  
> Wolfgang and Andre.

I haven't had a chance recently to do a thorough comparison of  
different open source hosting providers, so I have no opinion on this  
one. So if you want to invest time in maintaining HOC, and you want to  
maintain it on GoogleCode, then so be it. How do I give my permission?


Cheers,

Wolfgang

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: HOC is dead! Long live HOC!

Joel Reymont

On Nov 7, 2007, at 9:57 PM, Wolfgang Thaller wrote:

> One big piece of information we need that is currently missing from  
> the BridgeSupport files is which declaration comes form which header  
> file. HOC's module structure currently follows Apple's .h files, and  
> we need the module system for resolving naming ambiguities.

Why not assume that each class goes into a file of its own and all  
classes in a directory matching the name of the framework? You will  
then have AppKit/NSWindow.hs, etc. I think this is how it's done right  
now. Constants and such can be gathered in AppKit/AppKit.hs.

>> I haven't had a chance recently to do a thorough comparison of  
>> different open source hosting providers, so I have no opinion on  
>> this one. So if you want to invest time in maintaining HOC, and you  
>> want to maintain it on GoogleCode, then so be it. How do I give my  
>> permission?


Either you or Andre should have received an email from Google Code.  
Please add wagerlabs to the project admins on SourceForge and I'll  
look into it.

        Thanks, Joel

--
http://wagerlabs.com





_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe