[mcclim-cvs] CVS update: mcclim/Backends/beagle/README.txt

[Duncan Rose]

Update of /project/mcclim/cvsroot/mcclim/Backends/beagle
In directory common-lisp.net:/tmp/cvs-serv24047/beagle

Modified Files:
	README.txt 
Log Message:
Some refactoring of events.lisp; made an effort to trawl for
memory allocations and ensure they're freed appropriately.
Estimate this to be around 70-80% done. Seems to give
performance and stability benefits.

Date: Fri May 20 00:25:33 2005
Author: drose

Index: mcclim/Backends/beagle/README.txt
diff -u mcclim/Backends/beagle/README.txt:1.11 mcclim/Backends/beagle/README.txt:1.12
--- mcclim/Backends/beagle/README.txt:1.11	Wed May 18 22:21:56 2005
+++ mcclim/Backends/beagle/README.txt	Fri May 20 00:25:33 2005
@@ -114,9 +114,9 @@
 4.  -> (load "home:load-clim")
 5.  -> (load "home:load-clx")
 6.  -> (load "home:load-beagle")
-7.  -> (setf climi::*default-server-path* :clx)
+7.  -> (setf climi:*default-server-path* :clx)
 8.  -> (clim-listener:run-listener)
-9.  CL-USER> (setf climi::*default-server-path* :beagle)
+9.  CL-USER> (setf climi:*default-server-path* :beagle)
 10. CL-USER> (clim-listener:run-listener-process)
 
 I can get both a CLX and a Beagle Listener running simultaneously.
@@ -181,7 +181,8 @@
     Actually, this ^^^ seems to work fine, but the highlighting for button
     gadgets looks screwy under OS X.
     (Think there is a problem with tracking rectangles not being set for
-    panes. Investigation needed.)
+    panes. Another alternative relates to the calculation of pointer position
+    in the MOUSE-ENTER/EXIT event generator.)
 
 
 7.  Keyboard events are not handled "properly" as far as any OS X user will
@@ -201,13 +202,6 @@
     like to avoid having pixmap caches for mirrors though.
 
 
-9.  Foreign memory management is non-existent. This is fine whilst running
-    in the same thread as the OpenMCL Listener (since we use its autorelease
-    pool) but when running in a separate thread lots of warning messages
-    are generated. You might find it necessary to force-quit OpenMCL after
-    you've finished.
-
-
 12. There's some debug output remaining in some corner cases.
 
 
@@ -284,6 +278,13 @@
     It's still present in the output history, and mousing over it makes
     it reappear, but still... not sure why this happens.
 
+
+29. Event signal-semaphore and consume-semaphore code isn't quite right;
+    if the user generates events whilst Beagle is in the middle of a
+    long-lived operation (generating a big graph, for example), some of
+    those events are 'trapped' in the queue until other events take place.
+    Looking at the code, I don't think this should happen... (but it does).
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 FIXED STUFF PREVIOUSLY ON THE KNOWN LIMITATIONS / TODO LIST
@@ -317,6 +318,20 @@
     FIXED 17.MAY.2005 DAR - the problem was we never invoked 
                             'setf (port-keyboard-input-focus' in handling
     the 'did become key' notification.
+
+-9.-  Foreign memory management is non-existent. This is fine whilst running
+    in the same thread as the OpenMCL Listener (since we use its autorelease
+    pool) but when running in a separate thread lots of warning messages
+    are generated. You might find it necessary to force-quit OpenMCL after
+    you've finished.
+
+    UPDATE: have made one pass ensuring heap allocated memory (with
+    MAKE-RECORD) is free'd, and that retained objects are released. Things
+    seem much better now but I'm sure I overlooked a few.
+    Moving this to 'resolved' (but keep eyes open for more occurrences ;-)
+
+    Note: this also seems to have given a bit of a speed-boost; perhaps we
+    avoid swapping, or have cut down on GC overhead.
 
 -10.- Text sizes aren't calculated correctly; when multiple lines are output
     together, the bottom of one line can be overwritten by the top of the