[gsharp-devel] Problem of second gsharp

[Robert STRANDH]

Christophe Rhodes writes:
 > 
 > There's a problem when running the second (and subsequent) gsharps of
 > any given session.  The problem arises, I think, because of too much
 > state maintenance, but I'm not sure whose fault it is -- gsharp's, or
 > the CLIM CLX backend.
 > 
 > To reproduce the problem, 
 >   (gsharp::run-gsharp)
 >   c ] d [
 >   Quit (from menu or interactor)
 >   (gsharp::run-gsharp)
 >   c ] d [
 > at this point, you will hit the debugger.  What's happening is that
 > the pixmap held in *lighter-gray-progressions* and
 > *darker-gray-progressions* is cached from the first gsharp run, and
 > the copy-from-pixmap from the second gsharp is confused because the X
 > display of the first gsharp (presumably associated in some way with
 > the pixmap in question) is closed.
 > 
 > So, firstly, whose fault is this?  

Certainly Gsharp's.  Pixmaps are per X session, so it should not hold
on to those between sessions.  

 > And secondly, if it is a problem in
 > gsharp, where is best to deal with it?  Should these caches be
 > maintained per-frame, or per-score-pane?  I guess per-frame, since
 > that's effectively how they were treated before...

I would think that putting them in the frame would be bad, since
technically, the frame should not know how the score pane accomplishes
its task.  the *xx-gray-progressions* variables are not exported from
the score-pane package, indicating that their existence is not known
to the outside world.  I would put them in the score pane, together
with the other pixmaps.  This change should be fairly simple to make. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------