Re: Kawa Compilation

[Nigel Dolby <nigel_dolby at acm dot org>]

Per, Robert,

Many thanks for your e-mails.

Thank you, Robert, for the very explicit instructions and for leaving 
aside the polemics - sorry you had to. Moving from Common Lisp to Scheme 
plus picking up large chunks of Java leaves me stretched a little thin 
for also picking up Linux at the moment. But if Kawa actually provides 
Lisp-based prototyping integrated with cross-platform delivery then it 
should be worth the effort - thanks for your forebearance - I've been 
waiting 15 or 20 years for the functionality.

Xandros Linux does not come with CVS installed, but the Xandros Networks 
application it contains can install CVS if the Debian Unsupported Site 
source is enabled from the Edit|Set Application Sources menu entry.

My initial attempt to login to CVS received a warning: "cvs login: 
warning: failed to open /home/nigeldolby/.cvspass for reading: No such 
file or directory" but the subsequent download command successfully 
transferred large numbers of files and created a Kawa subdirectory 
structure. It is not quite clear to me whether step (2) in your 
instructions is the same as the two CVS commands above it, or is there a 
separate "CVS update" activity? I'm now proposing to step through your 
instructions line by line, and I'll try to feed back on anything that is 
unclear or that doesn't work on my system.

Per commented that EXIT_ON_CLOSE asks for application exit to happen, 
but, unless there is some other value one can set, I think that, when 
prototyping, there may be a reason why it is not as simple as that. The 
Kawa interactive window is really just like a Lisp Listener in Common 
Lisp systems such as Allegro. A Lisp Listener allows one to repeatedly 
create and destroy application windows without itself closing. This is 
useful when prototyping interface functionality, during the time that an 
initial cut at what a window should look like and do is refined into 
something that actually works. In the Java environment it seems that a 
window is associated with a thread of execution, and thus that closing a 
window that is set to EXIT_ON_CLOSE should terminate the thread 
associated with the window, but not necessarily the thread that created 
that thread.

Per also asked a little while ago why I thought that copy-clos-instance 
was a desirable function to have. It is a year or two since I looked at 
this area of my code but one use, as I recall, arose in the editing 
functionality. The application exposes data to the user in terms of the 
objects that represent the user's information. These objects contain 
multiple user-settable slots and, when they are edited, multiple changes 
can be made to an object before any change is made persistent (via an 
explicit "save" command). In order to support back-out of changes it is 
necessary to capture the initial state of an object when editing begins, 
and a reasonable way to do that is simply to copy the instance (also 
using copy-tree to preserve lists in the slots).

Thanks for all your help.


                                                  Nigel Dolby.