This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Kawa Compilation
- From: Per Bothner <per at bothner dot com>
- To: Nigel Dolby <nigel_dolby at acm dot org>
- Cc: 'Kawa List' <kawa at sources dot redhat dot com>
- Date: Thu, 09 Mar 2006 10:26:17 -0800
- Subject: Re: Kawa Compilation
- References: <44105EF9.2030707@acm.org>
Nigel Dolby wrote:
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.
Strange. CVS should be a fairly standard and supported GNU/Linux package.
But I'm not familiar with Xandros. Maybe they just mean it's
unsupported by Xandros.
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?
You should be fine. Run cvs update next time you want the latest and
greatest.
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.
The JDK documentation for setDefaultCloseOperation very clearly says what
EXIT_ON_CLOSE does: Exit the application using the System exit method.
This means shutting down the *entire* virtual machine. There is nothing
Kawa could or should do about that.
Of course you can repeatedly create and destroy application windows.
But don't set EXIT_ON_CLOSE if you want to do that.
The problem may be terminology wrt "application". You're associating
the term with a window or thread or task, but in the Java world it
usually means an entire Virtual Machine. (There are some exceptions.
For example a Servlet Containtainer manages multiple "web applications",
using the same VM.)
Note that Kawa doesn't do any magic to create or manage threads when you
create a Swing JFrame. You may need to do that to avoid deadlock, just
like with other Swing applications. When a Scheme interactive window
(console) is created, then that does create the thread for you.
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).
Copying the object will of course break object identity, and any graphs
containing the object. If you just want to remember and maybe undo
slots that you changed, then just do that: remember the fields that
you've changed. Of course "ACID" transactions complicate things.
The whole morass of "Java beans" and "property editors" may be relevant
here, though I'm not all that solid on this stuff myself.
There is also a confusing number of tools for object persistence,
connecting to databases, etc. I think Kawa would be a good tool
for making this easier, so I'm interested in exploring this area.
Not before Kawa 1.8.1, though!
--
--Per Bothner
per@bothner.com http://per.bothner.com/