I would like to tinker with Cocoa bindings and try to move that
project forward.
Where should I start from? I would like to take the route of parsing
Obj-C header files.
Thanks, Joel
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Hi,
On 18.07.2006, at 23:38, Joel Reymont wrote:
> Folks,
>
> I would like to tinker with Cocoa bindings and try to move that
> project forward.
>
> Where should I start from? I would like to take the route of
> parsing Obj-C header files.
The swig manual states that they support experimentally Objective-C
parsing. Swig is a wrapper generator with an OCaml backend. So this
might be a starting point :-)
Regards,
Jean-Marie
PS: I don't have any experience with swig myself, therefore I don't
claim that it is really good.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFEvejdNIUNP/I5YOgRAlczAJ0VSNF58STHKC2TYTh20npVmTTLWQCfeUP+
ewIbhrUog9FVwuulMfA+evc=
=7pR1
-----END PGP SIGNATURE-----
> Folks,
>
> I would like to tinker with Cocoa bindings and try to move that
> project forward.
>
> Where should I start from? I would like to take the route of
> parsing Obj-C header files.
>
I agree that this is long overdue. A long time ago, Mike Hamburg,
Jeff Henrikson, and I made noises about working on this, based on
Mike's work on addressing the runtime side of it (he got so far as to
have a somewhat under-performant but usable runtime library
integrating O'Caml with the Objective C runtime based, IIRC, on
Obj.magic) and Jeff pointed out that Frontc, the parser that he used
in his Forklift FFI, had diverged from probably the best one for real-
world use, which is embedded in CIL and intertwined in ways that make
it a challenge to backport. Mike, Jeff, if you're reading this, is
this a fair characterization of your efforts and thoughts?
In any case, I still believe that:
1) It's worth addressing whatever issues need addressing in Mike's work.
2) It's worth resolving what parser to use and, IMHO, how to evolve
Forklift to support generating calls to and from Objective C via
Mike's runtime work.
3) It's worth combining the two to provide the Forklift annotations
to allow calling into and out of Cocoa on Mac OS X.
4) It's worth writing an FRP system for O'Caml a la Yampa for Haskell.
5) It's worth using said FRP system in conjunction with perhaps
<http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto-
u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a
truly cross-platform GUI environment for O'Caml.
Thoughts?
> Thanks, Joel
>
> --
> http://wagerlabs.com/
Best regards,
Paul
On Jul 20, 2006, at 5:40 PM, Paul Snively wrote:
> 4) It's worth writing an FRP system for O'Caml a la Yampa for Haskell.
> 5) It's worth using said FRP system in conjunction with perhaps
> <http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto-
> u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a
> truly cross-platform GUI environment for O'Caml.
FWIW The past couple weeks I've been working on an FRP system modeled
after PLT Scheme's FrTime for O'Caml. I hope to release a preliminary
version in a week or so.
> 5) It's worth using said FRP system in conjunction with perhaps
> <http://ocaml-win32.sourceforge.net>, http://wwwfun.kurims.kyoto-
> u.ac.jp/soft/lsl/lablgtk.html, and our Cocoa bindings to create a
> truly cross-platform GUI environment for O'Caml.
This is my idea also. Along with the FRP core I've been developing a
simple set of GUI widgets based on lablgtk2 that integrate with it
(with the the intent of also writing Cocoa and Win32 bindings).
> I must be missing something but ... what does FRP have to do with
> Cocoa bindings?
>
In and of itself, nothing; I just like the FRP approach to GUI
programming, so I see an opportunity to kill two birds with one stone:
1) Provide O'Caml a nice FRP framework.
2) Provide O'Caml a nice GUI framework that doesn't suffer the
vagaries of the usual OO GUI frameworks.
Best regards,
Paul
> 2) Provide O'Caml a nice GUI framework that doesn't suffer the
> vagaries of the usual OO GUI frameworks.
Does LabGTK suffer from this?
I'm new to OCaml but I've got Haskell experience and I'm thinking of
following the HOC (Haskell Cocoa bindings) approach to parsing header
files. I previously got most of a Lisp Cocoa bridge done (for Allegro
CL) and found the dynamic approach to be in a pain in the rear due to
the high numbers of hidden structs and classes that don't appear in
header files but can be discovered through the runtime.
-Corey
On 7/20/06, Paul Snively <psni...@mac.com> wrote:
>
--
-Corey O'Connor
At the risk of engaging in more than my fair share of self-promotion,
I should point out that the OCaml NAE I/O Reactor library I just
released is an FRP framework. It's pretty spare at the moment and
needs a lot of additions. Also, I didn't write it with graphical
user interfaces in mind-- the goal was a good framework for single-
threaded multiplexing network application servers. (The acronym
"NAE" stands for 'Network Application Environment'.)
<http://sf.net/projects/ocnae/>
The Yampa framework doesn't strike me as appropriate for building a
GUI. I suspect such a GUI toolkit would offer highly underwhelming
performance characteristics. I could be wrong about that, and would
welcome such a surprise, but that's what my unscientific guess tells me.
> 2) Provide O'Caml a nice GUI framework that doesn't suffer the
> vagaries of the usual OO GUI frameworks.
For my own part, I plan to do all my GUI work in Cocoa with native
Objective-C. A more useful addition to the OCaml HUMP, I argue,
would be bindings for CoreData.
<http://developer.apple.com/macosx/coredata.html>
At some point, if no one else has done it first, I will get around to
doing it myself. Don't anybody hold their breath waiting for it,
though... I have a lot of hobby projects these days, what with a day
job and a 6-month old baby in the house.
ā
j h woodyatt <j...@conjury.org>