This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Kawa Compilation
- From: Nigel Dolby <nigel_dolby at acm dot org>
- To: 'Kawa List' <kawa at sources dot redhat dot com>
- Date: Thu, 09 Mar 2006 10:59:37 -0600
- Subject: Re: Kawa Compilation
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.