[Openmcl-devel] OpenMCL / Cocoa

[Brian Cully]

n fact, I'm writing a Cocoa MUD client that communicates w/ a lisp engine
via standard io. There's really no conceptual difference between that and a
socket of some kind, I just chose it because I wanted very direct control of
the lisp reader.

It's not terribly hard to do. I have a LispREPL class encapsulating the
message passing (and I added categories to NSDictionary/Array/etc to get
lisp representations). On top of that is a LispREPLController which provides
the UI glue (I have my own listener window, rather than using OpenMCL's
built in cocoa listener).

Messages are passed as s-exps. On the lisp side, there's no work at all
there, of course, and on the Cocoa side, I wrote tacked on a category to
NSString to convert forms to NSArrays.

In practice, this has worked out very well for me so far. It's extremely
easy to add Cocoa stuff to the lisp backend, and you can do it piece-meal as
you need to.

There is one perpetual issue: since I process sexps in Cocoa as an NSArray,
I lose out on dotted conses. Since I translate from alists to NSDictionary,
there's lossage here that you need to stay aware of . For instance, when one
changes the server setting, it sends a message like the following:

(moxie::send-window-event :COCOA-WINDOW-ID :settings-changed '((:hostname
"whatever")))

When, ideally, it would send '((:hostname . "whatever")) so one could use
car/cdr properly. It's even worse, because if you were to send the following
message to the Cocoa end of things:

(:window-event :COCOA-WINDOW-ID :settings-changed '((:hostname .
"whatever")))

Things will work fine from cocoa (NSDictionary/Array have no cdr concept to
run afoul of), but when you change that host from "whatever" to "sowhat"
(via Cocoa preference panels, of course), it strips that dot out of the
event:

(moxie::send-window-event :COCOA-WINDOW-ID :settings-changed '((:hostname
"sowhat")))

So in the process of moving between cocoa and lisp, you have to be cognizant
of the fact that applying cdr to any data returned from Cocoa will always
return a list.

It's not a huge deal, and aside from that things work quite well. At some
point I intend to wrap up the lisp communication/dispatch into a framework
so it can be used elsewhere. The only reason I haven't done it yet is
because I want a plug in system that loads lisp/cocoa simultaneously, so
someone can package lisp code w/ interface builder NIB files, and no one
would need to know a lisp is under all that.

I tried, briefly, to embed a lisp using ECLS, but there were an enormous
amount of problems with that approach, and so I went with running a lisp in
a subprocess. It's annoying because of asynchronous timing issues, but a win
overall, imho.

If you want the code to the lisp handler, shoot me a private mail and I'll
see about packing it up for you. It's a pretty simple piece of code, really.
The hardest part was writing the translator from forms to NSArrays, and that
didn't even take an hour.

-bjc

On 1/24/06, Gary King <gwking at metabang.com> wrote:
>
> I know that progress continues with the Objective C / Cocoa bridge
> but I'm wondering if anyone has worked on running OpenMCL and a Cocoa
> application using sockets to communicate between them. I have some
> ideas I'd like to play with where the GUI could be Cocoa and some of
> the smarts could be OpenMCL. I think that sockets would be fast
> enough, etc. to handle simple needs. Unfortunately, I'm pressed for
> time and would rather not much with setup unless I have to so...
>
> Has anyone else build any infrastructure along these lines that
> they'd like to share? Also, is this a _bad_ idea? Am I missing
> something?
>
> Thanks,
> --
> Gary Warren King
> metabang.com
> http://www.metabang.com/
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20060124/86f8ee07/attachment.htm>