Subject: [clisp-list] GTK and CLISP

From: Peter Wood <[email-masked]>
Date: 29 Mar 2001 14:19:33 +0200

Hi

If some knowledgable person has the time, perhaps they would help me
with the following.  (I am pretty new to this, so I beg your pardon if
my questions are stupid)

1) Is there some good reason nobody seems to go the "ffi way" when
doing gui stuff with lisp.  Unless I am mistaken, it all seems to be
sockets and pipes.  Why?

2) I am using a slightly modified CLISP linked to the GTK libraries,
and this makes it easy to write gui functions for CLISP in C (using
GTK) which can be linked into lisp via FFI.  Is there something wrong
with doing this in *principle*.

3) So far I have only written a small demo with it but it was
ridiculously easy, and seemed to work very well.

BUT ...

4) Are there memory issues that I am not seeing.  GTK seems pretty
solid.  But am I introducing a weak link by doing this.  What sort of
limitations are there in passing data between functions written in
Lisp and functions written in C?  For example, would it be possible to
run a REPL in a gtk window?  Or why not write an editor this way? So
for example (gtk:ed) ran a gtk function which produced an editor
window which would have access to CLISP's power.
 
5) Example 29.4 in the impnotes shows how a memory leak can occur - Is
this sort of thing generally a serious problem, or can workarounds be
found? Could one not solve many memory problems by breaking up
(problematic) complex, Lisp data structures before passing them to C,
as simple types, where they could be reassembled by C functions, and
free()'d appropriately?  Would this be prohibitively expensive?  

Apologies for the long post,

Peter

---

From: Marco Antoniotti <[email-masked]>
Date: Thu, 29 Mar 2001 10:23:35 -0500

> From: Peter Wood <[email-masked]>
> Sender: [email-masked]
> Content-Length: 1760
> 
> Hi
> 

Because things like GTK make and regular Lisp systems make it very
difficult to integrate the Event Loop and the REPL.  This is the key
difficulty.  Also in older versions of GTK it was not even possible to
get a hold of the X display to do obvious things.

IMHO, all in all this is historic.  At the time when C and Lisp were
the dominant "system" languages, they developed without
interoperability in mind.  (Common) Lisp lost and now the heritage
remains that it is difficult to integrated Lisp and C.  Later
languages (and toy languages like Scheme) have chosen the path to "sit
upon" C and are therefore very good at either been embedded into C or
to call C.  Calling C is something simple to do with any CL
implementation.  It is the reverse that is very difficult.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group	tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA			http://bioinformatics.cat.nyu.edu
	       "Hello New York! We'll do what we can!"
			Bill Murray in `Ghostbusters'.

---

From: Hannu Koivisto <[email-masked]>
Date: 29 Mar 2001 18:58:55 +0300

Peter Wood <[email-masked]> writes:

| 1) Is there some good reason nobody seems to go the "ffi way" when
| doing gui stuff with lisp.  Unless I am mistaken, it all seems to be
| sockets and pipes.  Why?

You are indeed mistaken.  For example, GTK bindings for CMUCL have
been done in the "FFI way".  Most other GUI toolkits I know of are
either Win32 stuff (although I'm sure Win32 GUI calls are done via
some sort of FFI) or lay on top of CLX, which talks to the X server
via sockets, but that's the way even C programs talk to the X
server.  Oh, and I recall someone mentioning that MCL's higher
level GUI stuff lies on top of foreign functions that one can use
directly as well.  And of course Genera's GUI needs neither FFI nor
sockets/pipes :)

| 2) I am using a slightly modified CLISP linked to the GTK libraries,
| and this makes it easy to write gui functions for CLISP in C (using
| GTK) which can be linked into lisp via FFI.  Is there something wrong
| with doing this in *principle*.

I don't see anything fundamentally wrong with it.  I don't think it
would be my preference, though; I'd rather write FFI definitions
directly for GTK functions, but then again, I don't need to use GTK
with CLISP so I haven't really thought about this.

| 4) Are there memory issues that I am not seeing.  GTK seems pretty
| solid.  But am I introducing a weak link by doing this.  What sort of

Well, I guess there is almost always a weak link at some point if
you consider calling C code a weak link :)  Of course you must be
extra careful with FFI stuff, because problems there can cause Lisp
to crash whereas problems with plain Lisp code just throw you to
the debugger.  At least in principle :)

| limitations are there in passing data between functions written in
| Lisp and functions written in C?  For example, would it be possible to

I don't think there are much limitations that can't be overcome.
Some things might be awkward to express with CLISP's FFI but then
you could always write a little bit of glue code in C.

| run a REPL in a gtk window?  Or why not write an editor this way? So

If you have a Lisp interface to GTK, I don't see anything that
would prevent you from writing whatever you want with it, let it be
REPL, editor or Gimp-in-CL.

| 5) Example 29.4 in the impnotes shows how a memory leak can occur - Is
| this sort of thing generally a serious problem, or can workarounds be
| found?

Workarounds can be found; I think the memory problem was left there
in order to keep the example simple or just to demonstrate how one
can accidentally introduce memory leaks.

| Could one not solve many memory problems by breaking up
| (problematic) complex, Lisp data structures before passing them to C,
| as simple types, where they could be reassembled by C functions, and
| free()'d appropriately?  Would this be prohibitively expensive?  

The problem in that example was not in passing complex Lisp
structures to C but returning malloc'ed data from C to Lisp.  You
just need to either tell user to free it manually (just as he would
have to with C code), use finalization or perhaps convert the data
structure to some Lisp object and free the resource allocated by C
immediately after that so that the user doesn't have to free it (he
just gets a Lisp object that is garbage collected normally).  You
might end up using the last approach semi-automatically because you
often want to convert the data returned by C code to some higher
level Lisp object (if you didn't, the user of your interface would
probably end up doing it anyway).  The best solution varies case by
case, of course.

-- 
Hannu
Please don't send copies of list mail

---

From: Peter Wood <[email-masked]>
Date: 29 Mar 2001 19:23:33 +0200

> probably end up doing it anyway).  The best solution varies case by

Yes, thanks.  I had it the wrong way round. I like the last solution
you mention.  

Peter

---

From: Reini Urban <[email-masked]>
Date: Thu, 29 Mar 2001 20:37:13 +0200 (CEST)

> Yes, thanks.  I had it the wrong way round. I like the last solution

you might also want to see the new gtk-emacs. this is implemented by a
simple ffi.