This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Kawa Compilation


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]