From csr21 at cantab.net  Fri May  4 09:31:56 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Fri, 04 May 2007 10:31:56 +0100
Subject: [mcclim-devel] Test suites and code coverage
Message-ID: <871whxq6ib.fsf@cantab.net>

Hi,

Some people may know that Juho Snellman committed a nice new tool to
SBCL recently: a tool to measure code coverage[1].  For laughs, I
thought I'd try it out on McCLIM and its test suite...

To do so, I first loaded clx, spatial-trees and flexichain.  Then
  (require :sb-cover)
  (declaim (optimize sb-cover:store-coverage-data))
  (asdf:oos 'asdf:load-op :mcclim)
  (sb-cover:reset-coverage) ; debatable.  See below.
  (defpackage :clim-tests (:use :clim :clim-lisp))
  (mapcar #'load (directory "/path/to/mcclim/Tests/*.lisp"))

The results I got are available at
<http://doc.gold.ac.uk/~mas01cr/tmp/mcclim-tests/>.

So, firstly, this is clearly not automated enough; I plan to spend a
little time making running tests easier.  The point about clearing
coverage before running the tests is to remove all the uses of
internal code (such as macros) in the building of mcclim itself.  I
don't know whether that's fair or not, but in doing so I noticed that
there are some load-time tests (in e.g. bezier.lisp) which might be
better placed in a test suite.

I also am aware that I didn't run Drei or automaton test suites in the
process of doing this; running those should be a simple matter.

What does this show?  Well, even though it's difficult to test a UI
library in an automated fashion, I'm pretty sure that there are large
swathes of things that /are/ testable in an automated fashion that
aren't being so tested -- and that maybe by making these statistics
available people could find bits that interest them and write tests to
exercise those bits.

There's also the obvious possibility of collecting the coverage
statistics while running demodemo -- which will exercise backend
functions and some of the UI code, and show us where some gaps are.
(There's also my long-standing idea of using the Null backend to test
UI in an automated fashion, but I'm sure more work needs to be done to
make that possible.)

Anyway.  Comments, ideas?

Cheers,

Christophe

[1] Weblog entry at
<http://jsnell.iki.fi/blog/archive/2007-05-03-code-coverage-tool-for-sbcl.html>;
some details at <http://www.sbcl.org/manual/sb_002dcover.html>.




From csr21 at cantab.net  Mon May  7 09:55:19 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 07 May 2007 10:55:19 +0100
Subject: [mcclim-devel] Test suites and code coverage
In-Reply-To: <871whxq6ib.fsf@cantab.net> (Christophe Rhodes's message of "Fri, 
	04 May 2007 10:31:56 +0100")
References: <871whxq6ib.fsf@cantab.net>
Message-ID: <87r6ptufeg.fsf@cantab.net>

Christophe Rhodes <csr21 at cantab.net> writes:

> There's also the obvious possibility of collecting the coverage
> statistics while running demodemo -- which will exercise backend
> functions and some of the UI code, and show us where some gaps are.

I've now done this: the results of compiling and loading the files in
the mcclim/ and mcclim/Backends/CLX/ directories, and then starting
demodemo and interacting a little bit with each of the demos, is up at
<http://www-jcsu.jesus.cam.ac.uk/~csr21/tmp/mcclim-tests/>.

Cheers,

Christophe


From rpgoldman at real-time.com  Mon May  7 13:33:10 2007
From: rpgoldman at real-time.com (Robert Goldman)
Date: Mon, 07 May 2007 08:33:10 -0500
Subject: [mcclim-devel] Test suites and code coverage
In-Reply-To: <871whxq6ib.fsf@cantab.net>
References: <871whxq6ib.fsf@cantab.net>
Message-ID: <463F2A96.1020004@real-time.com>

Christophe Rhodes wrote:
> Hi,
> 
> Some people may know that Juho Snellman committed a nice new tool to
> SBCL recently: a tool to measure code coverage[1].  For laughs, I
> thought I'd try it out on McCLIM and its test suite...
> 
> To do so, I first loaded clx, spatial-trees and flexichain.  Then
>   (require :sb-cover)
>   (declaim (optimize sb-cover:store-coverage-data))
>   (asdf:oos 'asdf:load-op :mcclim)
>   (sb-cover:reset-coverage) ; debatable.  See below.
>   (defpackage :clim-tests (:use :clim :clim-lisp))
>   (mapcar #'load (directory "/path/to/mcclim/Tests/*.lisp"))
> 
> The results I got are available at
> <http://doc.gold.ac.uk/~mas01cr/tmp/mcclim-tests/>.
> 
> So, firstly, this is clearly not automated enough; I plan to spend a
> little time making running tests easier.  The point about clearing
> coverage before running the tests is to remove all the uses of
> internal code (such as macros) in the building of mcclim itself.  I
> don't know whether that's fair or not, but in doing so I noticed that
> there are some load-time tests (in e.g. bezier.lisp) which might be
> better placed in a test suite.
> 
> I also am aware that I didn't run Drei or automaton test suites in the
> process of doing this; running those should be a simple matter.
> 
> What does this show?  Well, even though it's difficult to test a UI
> library in an automated fashion, I'm pretty sure that there are large
> swathes of things that /are/ testable in an automated fashion that
> aren't being so tested -- and that maybe by making these statistics
> available people could find bits that interest them and write tests to
> exercise those bits.
> 
> There's also the obvious possibility of collecting the coverage
> statistics while running demodemo -- which will exercise backend
> functions and some of the UI code, and show us where some gaps are.
> (There's also my long-standing idea of using the Null backend to test
> UI in an automated fashion, but I'm sure more work needs to be done to
> make that possible.)
> 
> Anyway.  Comments, ideas?
> 
These results are very thought provoking, but I was wondering --- is
there a source of information about what the counts mean somewhere?  I
have looked at the sb-cover manual section and Juho's page, and I don't
see a definition for these terms.  I am asking because I'm trying to
grope towards an understanding of how to use them.  For example, I see
in your statistics that graph-formatting.lisp (one of the few pieces of
McCLIM I can claim to somewhat understand), has 54.2% expression
coverage and 46.8% branch coverage.  I'm not sure how to relate that to
what I know, which is that graph-formatting is radically unfinished (it
supports only tree formatting, neither DAG nor directed graph formatting
options, at least as of about a month ago, which was when I last pulled
a CVS update).

Thanks,
r


From christian at defun.dk  Mon May  7 18:22:36 2007
From: christian at defun.dk (Christian Lynbech)
Date: Mon, 07 May 2007 20:22:36 +0200
Subject: [mcclim-devel] McCLIM on the Mac
In-Reply-To: <20070430210423.GA8062@ununoctium> (David Lichteblau's message of
	"Mon, 30 Apr 2007 23:04:23 +0200")
References: <m2zm4piuv4.fsf@christian-lynbechs-power-mac-g5.local>
	<20070430210423.GA8062@ununoctium>
Message-ID: <m2d51cijdf.fsf@christian-lynbechs-power-mac-g5.local>

My patch is attached below. 

It is really quite simple. First of all it enables the beagle backend provided
you do not have clx and do have mcl|openmcl. That should be safe enough.

The fix itself goes into "Backends/beagle/beagle-backend.asd" and here things
are more fishy. Well, the fix itself is innocent enough, it fixes the imports
of two unknown symbols. 

The first fix `%set-port-keyboard-focus' is just outcommented since this is
not referenced anywhere other than in beagle-backend.asd.

The other fix relates to `keyboard-input-focus' which also is no longer known. The
patch changes that into `port-keyboard-input-focus' but judging from a comment
of its only usage in `beagle-notification-to-clim-event' in
"Backends/beagle/input/events.lisp" there must have been a subtle difference
between `keyboard-input-focus' and `port-keyboard-input-focus'.

Anyway, we never get to that point, the process breaks down long before,
suggesting problems in the ObjC bridge.

I am using OpenMCL 1.0 rather than the latest snapshot because that gives me a
weird compilation error, but that may improve matters.

I also attach the script I have used to start up McCLIM on openmcl, the
instructions in "Backends/beagle/README.txt" does not seem to match reality all
that well.

                                 -- Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff:mcclim
Type: application/octet-stream
Size: 2055 bytes
Desc: Diff to make McCLIM compile on OpenMCL 1.0
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070507/f2eebae5/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openmcl-load-up.lisp
Type: application/octet-stream
Size: 341 bytes
Desc: Forms to load McCLIM on openmcl 1.0
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070507/f2eebae5/attachment-0001.obj>
-------------- next part --------------


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic at hal.com (Michael A. Petonic)

From christian at defun.dk  Mon May  7 18:44:49 2007
From: christian at defun.dk (Christian Lynbech)
Date: Mon, 07 May 2007 20:44:49 +0200
Subject: [mcclim-devel] McCLIM on the Mac
In-Reply-To: <44DA07BB-F761-11DB-8FE9-000A9577B8A2@robotcat.demon.co.uk>
	(Duncan Rose's message of "Mon, 30 Apr 2007 22:25:07 +0100")
References: <44DA07BB-F761-11DB-8FE9-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <m28xc0iice.fsf@christian-lynbechs-power-mac-g5.local>

I tried some of your suggestions and it changed the behaviour a bit.

I first changed to the address-book demo with first exhibited the same
behaviour as before. I then changed the default frame manager and now
rather than a lowlevel error, I get the following lisp level error
which could hint at the aforementioned input focus problem.

    No applicable method for args:
     (#<BEAGLE-PORT :screen MAIN-SCREEN>
      #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>)
     to #<STANDARD-GENERIC-FUNCTION CLIM-BACKEND:PORT-FRAME-KEYBOARD-INPUT-FOCUS #x8A8156E>
       [Condition of type SIMPLE-ERROR]

    Restarts:
     0: [ABORT] Return to SLIME's top level.
     1: [ABORT-BREAK] Reset this process
     2: [ABORT] Kill this process

    Backtrace:
      0: (#<CCL::STANDARD-KERNEL-METHOD NO-APPLICABLE-METHOD (T)> #<STANDARD-GENERIC-FUNCTION CLIM-BACKEND:PORT-FRAME-KEYBOARD-INPUT-FOCUS #x8A8156E>)
      1: (#<STANDARD-METHOD CLIM:STREAM-SET-INPUT-FOCUS (CLIM:CLIM-STREAM-PANE)> #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>)
      2: (#<STANDARD-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)> #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>)
      3: (CCL::%%STANDARD-COMBINED-METHOD-DCODE #<CONNECTION  #x844548E> #<TWO-WAY-STREAM input #<SWANK-BACKEND::SLIME-INPUT-STREAM #x844339E>, output #<SWANK-BACKEND::SLIME-OUTPUT-STREAM #x8445416> #x8443286>)
      4: (ADDRESS-BOOK)
      5: (CCL::CALL-CHECK-REGS 'ADDRESS-BOOK)
      6: (#<Anonymous Function #x840A1A6> "(address-book)
         ")
      7: (SWANK::CALL-WITH-BUFFER-SYNTAX #<COMPILED-LEXICAL-CLOSURE #x9348F7E>)
      8: (CCL::CALL-CHECK-REGS 'SWANK:INTERACTIVE-EVAL)
      9: (#<Anonymous Function #x840AE26> '(SWANK:INTERACTIVE-EVAL
            "(address-book)
         ") 30 'NIL)
     10: (#<Anonymous Function #x83A1D26> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x841AF46> #<COMPILED-LEXICAL-CLOSURE #x9348F9E>)
     11: (FUNCALL 'SWANK::EVAL-FOR-EMACS)
     12: (#<Anonymous Function #x83F0CE6>)
     13: (#<Anonymous Function #x83A1D26> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x841AF46> #<Anonymous Function #x83F0CE6>)
     14: (SWANK::CALL-WITH-REDIRECTED-IO #<COMPILED-LEXICAL-CLOSURE #x9348FBE> 'NIL)
     15: (SWANK::CALL-WITH-CONNECTION #<CONNECTION  #x844548E> #<Anonymous Function #x83F0CE6>)
     16: (SWANK::HANDLE-REQUEST #<CONNECTION  #x844548E>)
     17: (SWANK::CALL-WITH-BINDINGS 'NIL #<COMPILED-LEXICAL-CLOSURE #x9348FD6>)
     18: (CCL::RUN-PROCESS-INITIAL-FORM '(#<COMPILED-LEXICAL-CLOSURE #x9341CFE>) #<PROCESS worker(33) [Active] #x9341D36>)
     19: (#<Anonymous Function #x80D0DFE> '(#<COMPILED-LEXICAL-CLOSURE #x9341CFE>) 0)
     20: (#<Anonymous Function #x80C3956> 791992 #<LISP-THREAD worker [tcr @ #x3056E0] #x9341E2E>)


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic at hal.com (Michael A. Petonic)


From christian at defun.dk  Mon May  7 18:56:44 2007
From: christian at defun.dk (Christian Lynbech)
Date: Mon, 07 May 2007 20:56:44 +0200
Subject: [mcclim-devel] McCLIM on the Mac
In-Reply-To: <20070430210423.GA8062@ununoctium> (David Lichteblau's message of
	"Mon, 30 Apr 2007 23:04:23 +0200")
References: <m2zm4piuv4.fsf@christian-lynbechs-power-mac-g5.local>
	<20070430210423.GA8062@ununoctium>
Message-ID: <m24pmoihsj.fsf@christian-lynbechs-power-mac-g5.local>

>>>>> "David" == David Lichteblau <david at lichteblau.com> writes:

David> can you submit those fixes as a patch?

I forgot some places for the bad import, here is an updated patch.

                             -- Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff:mcclim
Type: application/octet-stream
Size: 3024 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070507/6423265b/attachment.obj>

From david at lichteblau.com  Mon May  7 19:06:29 2007
From: david at lichteblau.com (David Lichteblau)
Date: Mon, 7 May 2007 21:06:29 +0200
Subject: [mcclim-devel] McCLIM on the Mac
In-Reply-To: <m28xc0iice.fsf@christian-lynbechs-power-mac-g5.local>
References: <44DA07BB-F761-11DB-8FE9-000A9577B8A2@robotcat.demon.co.uk>
	<m28xc0iice.fsf@christian-lynbechs-power-mac-g5.local>
Message-ID: <20070507190629.GA23110@ununoctium>

Quoting Christian Lynbech (christian at defun.dk):
> I tried some of your suggestions and it changed the behaviour a bit.
> 
> I first changed to the address-book demo with first exhibited the same
> behaviour as before. I then changed the default frame manager and now
> rather than a lowlevel error, I get the following lisp level error
> which could hint at the aforementioned input focus problem.
> 
>     No applicable method for args:
>      (#<BEAGLE-PORT :screen MAIN-SCREEN>
>       #<CLIM-DEMO::ADDRESS-BOOK #x9348EBE>)
>      to #<STANDARD-GENERIC-FUNCTION CLIM-BACKEND:PORT-FRAME-KEYBOARD-INPUT-FOCUS #x8A8156E>
>        [Condition of type SIMPLE-ERROR]

That would be recent bit rot, due to Christophe Rhodes's keyboard focus
changes.  %SET-PORT-KEYBOARD-FOCUS has been removed.  Instead ports need
to implement a method on PORT-FRAME-KEYBOARD-INPUT-FOCUS, which returns
the sheet that has input focus according to cocoa, and a SETF method of
the same name to change cocoa's focus.


BTW, the code involving event handling looks rather recent.  Browsing
through CVS history I noticed that Tim Moore committed some changes a
little over a year ago, for McCLIM 0.9.2.


d.


From tompa.persson at gmail.com  Mon May  7 19:20:37 2007
From: tompa.persson at gmail.com (Thomas Persson)
Date: Mon, 07 May 2007 21:20:37 +0200
Subject: [mcclim-devel] com-beginning-of-buffer keybinding
Message-ID: <878xc030fu.fsf@opinion.spacecentre.se>


Hi

When playing around a bit with climacs I noticed that
com-beginning-of-buffer in Drei is bound to:

    (#\< :shift :meta)

which at least on my keyboard is physically impossible to type.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: drei.patch
Type: text/x-patch
Size: 279 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070507/76cc601d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070507/76cc601d/attachment.sig>

From csr21 at cantab.net  Mon May  7 22:14:29 2007
From: csr21 at cantab.net (Christophe Rhodes)
Date: Mon, 07 May 2007 23:14:29 +0100
Subject: [mcclim-devel] com-beginning-of-buffer keybinding
In-Reply-To: <878xc030fu.fsf@opinion.spacecentre.se> (Thomas Persson's message
	of "Mon, 07 May 2007 21:20:37 +0200")
References: <878xc030fu.fsf@opinion.spacecentre.se>
Message-ID: <87irb4uvqy.fsf@cantab.net>

Thomas Persson <tompa.persson at gmail.com> writes:

> When playing around a bit with climacs I noticed that
> com-beginning-of-buffer in Drei is bound to:
>
>     (#\< :shift :meta)
>
> which at least on my keyboard is physically impossible to type.

Yeah, this is a problem.  The Right Answer is not to patch it like you
did (although in fact that's likely how it will look finally) but
instead to remove the :shift (if present) in the mapping from keycodes
and modifiers to keysyms.

It's all a bit of a mess right now, though.  (See multiple copies of
keysyms.lisp scattered around the mcclim source tree)

Cheers,

Christophe


From christian at defun.dk  Mon May  7 18:59:06 2007
From: christian at defun.dk (Christian Lynbech)
Date: Mon, 07 May 2007 20:59:06 +0200
Subject: [mcclim-devel] McCLIM on the Mac
In-Reply-To: <44DA07BB-F761-11DB-8FE9-000A9577B8A2@robotcat.demon.co.uk>
	(Duncan Rose's message of "Mon, 30 Apr 2007 22:25:07 +0100")
References: <44DA07BB-F761-11DB-8FE9-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <m2zm4gh345.fsf@christian-lynbechs-power-mac-g5.local>

I made another attempt, this time making sure the flow was routed
around the bad climi reference. The resulting error in the inferior
lisp buffer is as follows. Something is still bad but the error is
different so it seems as if a proper fix for the foxus problem is
needed to progress.

                             -- Christian

    ? 2007-05-07 20:51:01.701 dppccl[4675] Exception raised during posting of notification.  Ignored.  exception: Lisp exception: Unknown foreign type: SINGLE-FLOAT
    2007-05-07 20:51:02.018 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'endEditing'
    2007-05-07 20:51:02.027 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'updateHemlockSelection'
    2007-05-07 20:51:29.346 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.356 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.366 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.386 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.396 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.406 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.417 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.436 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.467 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.479 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.487 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.507 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.527 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.547 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.557 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:51:29.567 dppccl[4675] Error in event loop: value NIL is not of the expected type SIMPLE-VECTOR.
    2007-05-07 20:52:17.668 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'updateHemlockSelection'
    2007-05-07 20:52:20.446 dppccl[4675] *** NSThread: ignoring exception 'Lisp exception: value NIL is not of the expected type SIMPLE-VECTOR.' that raised during delayed perform of target 0x1862600 and selector 'updateHemlockSelection'
    2007-05-07 20:53:46.679 dppccl[4675] *** Assertion failure in -[NSWindowGraphicsContext reenableDisplayPosting], GraphicsContext.subproj/NSWindowGraphicsContext.m:117
    2007-05-07 20:53:46.682 dppccl[4675] Error in event loop: Objective-C runtime exception: 
    Invalid parameter not satisfying: _displayPostingDisableCount > 0
    2007-05-07 20:53:46.688 dppccl[4675] *** Assertion failure in -[NSViewHierarchyLock unlockTopMostReader], AppKit.subproj/NSViewHierarchyLock.m:444


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic at hal.com (Michael A. Petonic)


From jeremy.rayman at gmail.com  Fri May 11 03:05:09 2007
From: jeremy.rayman at gmail.com (Jeremy Rayman)
Date: Thu, 10 May 2007 20:05:09 -0700
Subject: [mcclim-devel] clim-debugger update;
	keyboard navigation and an .asd file
Message-ID: <2fc9a7750705102005j7c4ae61bx1aa135041f9368fe@mail.gmail.com>

Hi there,

Peter Mechlenborg has a copy of clim-debugger.lisp on his webspace
with mostly-working keyboard navigation. He was the original author of
the clim-debugger. I cleaned up the rough edges, added some other
keyboard shortcuts, and made an .asd file for it.

The patches against today's CVS are here:
http://jlr.freeshell.org/data/mcclim/patches/clim-debugger.asd.patch
http://jlr.freeshell.org/data/mcclim/patches/clim-debugger-keyboard-navigation.patch

You can also find the full .asd and clim-debugger.lisp in that dir, in
case the patches don't work for you.

clim-debugger.asd.patch:
* Add an ASDF system for the clim-debugger.

clim-debugger-keyboard-navigation.patch:
* Keyboard navigation:
   - Arrow keys move up and down stack frames, space expands current frame
   - Enter key inspects current object
   - Select restart by number (0-10)
   - Shortcuts: #\a abort, #\q quit, #\c continue

Thanks so much for McCLIM.

- Jeremy Rayman
jeremy.rayman @ gmail.com


p.s. Peter's original copy is at
http://www.daimi.au.dk/~metch/lisp/clim-debugger.lisp .


From daniel at bigwalter.net  Mon May 14 20:11:58 2007
From: daniel at bigwalter.net (Daniel Jensen)
Date: Mon, 14 May 2007 22:11:58 +0200
Subject: [mcclim-devel] Presentation Translator Utilities
Message-ID: <87lkfr412p.fsf@orme.bigwalter.net>

I began writing the functions in 27.5 "Presentation Translator
Utilities", since they are missing in McCLIM, but I'm having trouble
reading the spec.

The spec does not go into detail on how translators are implemented. The
description for define-presentation-translator mentions that they have
names and are stored in command tables. The McCLIM implementation is a
reasonable interpretation of this.

The problem lies with add-presentation-translator-to-command-table. Here
it is very clear that the name is used outside command tables too:

    add-presentation-translator-to-command-table
    command-table translator-name &key (errorp t)  [Function]

    Adds the translator named by translator-name to command-table. The
    translator must have been previously defined with
    define-presentation-translator or
    define-presentation-to-command-translator.

It is not possible to write this function without changing more stuff. I
guess it calls for a global translator table (i.e., a hash table.)

What do you think? I don't really get it. I would much rather like to
change the definition of add-presentation-translator-to-command-table.
It makes more sense to me to do it like this:

    add-presentation-translator-to-command-table
    command-table translator &key (errorp t)  [Function]

    Adds a presentation translator to command-table. The translator must
    have been previously defined with define-presentation-translator or
    define-presentation-to-command-translator.

This removes the only usage of the global name. It is more consistent
with the other translator functions.

I attach a file with the functions from 27.5. See if you like it. It
might be an idea to refactor them together with the rest of the
translator code, because I copied a lot from there.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: presentation-translator-utils.lisp
Type: application/octet-stream
Size: 2671 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070514/aee52bac/attachment.obj>

From bohmer at gmail.com  Tue May 15 11:55:36 2007
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Tue, 15 May 2007 13:55:36 +0200
Subject: [mcclim-devel] small baby clim steps
Message-ID: <b00235700705150455g46e69e69uc10dc8832304425a@mail.gmail.com>

Hei,

I'm in the process of learning clim, I have a small code example under.
What I want to do is to add my own pane to a the display pane. Later I
want to be able to move the pane around in the pane by clicking on the
pane and drag it to the new place.

My first problem is that I don't know how to insert new panes into the
"display" pane.. The with-output-as-gadget require a stream, and I
don't know how to obtain this stream, and if the example under will
work.

(define-application-frame test ()
  ()
  (:panes
   (display :application :output-record
	    (make-instance 'standard-tree-output-record))
   (my-interactor :interactor))
  (:layouts
   (:default   (vertically (:height 500 :width 400)
		 (2/3 display)
		 (1/3 my-interactor)))))

(define-test-command (com-add :name t :menu "Add")
    ()
    (with-output-as-gadget
	(stream)
      (make-pane 'push-button
		 :label "Click here to exit"
		 :activate-callback
		 #'(lambda (button)
		     (frame-exit (pane-frame button)))))))


-- 
Knut Olav B?hmer


From bohmer at gmail.com  Thu May 17 20:46:15 2007
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Thu, 17 May 2007 22:46:15 +0200
Subject: [mcclim-devel] Re: small baby clim steps
In-Reply-To: <b00235700705150455g46e69e69uc10dc8832304425a@mail.gmail.com>
References: <b00235700705150455g46e69e69uc10dc8832304425a@mail.gmail.com>
Message-ID: <b00235700705171346l470dea94v6b7f8722f031afd6@mail.gmail.com>

On 15/05/07, Knut Olav B?hmer <bohmer at gmail.com> wrote:
<-cut->
> (define-test-command (com-add :name t :menu "Add")
>     ()
>     (with-output-as-gadget
>         (stream)
>       (make-pane 'push-button
>                  :label "Click here to exit"
>                  :activate-callback
>                  #'(lambda (button)
>                      (frame-exit (pane-frame button)))))))

I found an example that did what I want.

(define-petrinet-command (com-dynamic :menu t :name t) ()
  (with-look-and-feel-realization (*default-frame-manager* *application-frame*)
    (let ((button (make-pane 'push-button :label "Dynamically Generated"))
	  (layout-pane (find-pane-named *application-frame* 'simulation)))
      (sheet-adopt-child layout-pane button))))

But why should I not use presentations? What are presentation-types
related to what I'm doing?


-- 
Knut Olav B?hmer


From bohmer at gmail.com  Sat May 19 20:53:46 2007
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Sat, 19 May 2007 22:53:46 +0200
Subject: [mcclim-devel] Re: small baby clim steps
In-Reply-To: <b00235700705171346l470dea94v6b7f8722f031afd6@mail.gmail.com>
References: <b00235700705150455g46e69e69uc10dc8832304425a@mail.gmail.com>
	<b00235700705171346l470dea94v6b7f8722f031afd6@mail.gmail.com>
Message-ID: <b00235700705191353j21661cfend0d23812d0bdeb28@mail.gmail.com>

On 17/05/07, Knut Olav B?hmer <bohmer at gmail.com> wrote:

> But why should I not use presentations? What are presentation-types
> related to what I'm doing?

I have ended up using presentations. Now I'm trying to move the
objects, but the objects don't "stick" to the new place..

Here is the relevant part of my code.

(define-presentation-to-command-translator move-place-translator
    (place com-move-place simulation
	   :documentation "Move the place")
    (presentation x y)
  (list presentation x y))

(define-simulation-command (com-move-place)
    ((place 'place) (x 'real) (y 'real))
  (erase-output-record place *standard-output*)
  (setf (output-record-position place)
	(drag-output-record *standard-output* place
			    :finish-on-release t)))


-- 
Knut Olav B?hmer


From bohmer at gmail.com  Sat May 19 21:37:41 2007
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Sat, 19 May 2007 23:37:41 +0200
Subject: [mcclim-devel] Re: small baby clim steps
In-Reply-To: <b00235700705191353j21661cfend0d23812d0bdeb28@mail.gmail.com>
References: <b00235700705150455g46e69e69uc10dc8832304425a@mail.gmail.com>
	<b00235700705171346l470dea94v6b7f8722f031afd6@mail.gmail.com>
	<b00235700705191353j21661cfend0d23812d0bdeb28@mail.gmail.com>
Message-ID: <b00235700705191437t70897186id5fb0ef1bea12222@mail.gmail.com>

On 19/05/07, Knut Olav B?hmer <bohmer at gmail.com> wrote:
> On 17/05/07, Knut Olav B?hmer <bohmer at gmail.com> wrote:
>
> I have ended up using presentations. Now I'm trying to move the
> objects, but the objects don't "stick" to the new place..

Solved..
It was my :display-funcion that redrawed the original image.


-- 
Knut Olav B?hmer


From bohmer at gmail.com  Wed May 23 09:06:31 2007
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Wed, 23 May 2007 11:06:31 +0200
Subject: [mcclim-devel] Update object of a presentation.
Message-ID: <b00235700705230206l3736ca7ci3747727fa3693e4@mail.gmail.com>

Hi,

Let's say I have an object, that is presented with (present ...) on a pane.
It is then drawn on the pane with (define-presentation-method present
(...) (draw-arrow (start-of object) (end-of object) ...))

The arrow is used to represent the speed and direction of some
external object (like the wind)

Then the wind speed and direction changes, so the object is updated.
Now I need to update the presentation to reflect the changes in the object.

How can I update just that object?

-- 
Knut Olav B?hmer


From athas at sigkill.dk  Wed May 23 21:25:12 2007
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 23 May 2007 23:25:12 +0200
Subject: [mcclim-devel] Update object of a presentation.
In-Reply-To: <b00235700705230206l3736ca7ci3747727fa3693e4@mail.gmail.com>
	(Knut Olav =?utf-8?Q?B=C3=B8hmer's?= message of "Wed,
	23 May 2007 11:06:31 +0200")
References: <b00235700705230206l3736ca7ci3747727fa3693e4@mail.gmail.com>
Message-ID: <87lkffxmfb.fsf@lambda.athas.dyndns.dk>

"Knut Olav B?hmer" <bohmer at gmail.com> writes:

> Then the wind speed and direction changes, so the object is updated.
> Now I need to update the presentation to reflect the changes in the
> object.

I don't think you're supposed to do that. IIRC, output presentations
should not be associated with objects that mutate a lot.

> How can I update just that object?

Since presentations are output records, you could define a method on
REPLAY-OUTPUT-RECORD and call REPLAY on the appropriate presentation
object, but it's not exactly elegant.

-- 
\  Troels
/\ Henriksen


From rpgoldman at real-time.com  Wed May 23 21:54:53 2007
From: rpgoldman at real-time.com (Robert Goldman)
Date: Wed, 23 May 2007 16:54:53 -0500
Subject: [mcclim-devel] Update object of a presentation.
In-Reply-To: <87lkffxmfb.fsf@lambda.athas.dyndns.dk>
References: <b00235700705230206l3736ca7ci3747727fa3693e4@mail.gmail.com>
	<87lkffxmfb.fsf@lambda.athas.dyndns.dk>
Message-ID: <4654B82D.6020905@real-time.com>

Troels Henriksen wrote:
> "Knut Olav B?hmer" <bohmer at gmail.com> writes:
> 
>> Then the wind speed and direction changes, so the object is updated.
>> Now I need to update the presentation to reflect the changes in the
>> object.
> 
> I don't think you're supposed to do that. IIRC, output presentations
> should not be associated with objects that mutate a lot.
> 
>> How can I update just that object?
> 
> Since presentations are output records, you could define a method on
> REPLAY-OUTPUT-RECORD and call REPLAY on the appropriate presentation
> object, but it's not exactly elegant.
> 

This is actually a question of considerably interest to me.  It sounds
like Knut and I may have similar interests.

The CLIM UI model maps nicely onto conventional document-oriented
applications.  There's an artifact out there (I'm probably overly
constraining things by calling it a document), and the user manipulates
it with various commands, and the display updates to reflect the changed
state of the artifact.

I have found it much more difficult to figure out how to take this UI
model and map it onto process control applications, which are of primary
interest to me.  In such applications, there is an external process,
operating asynchronously with the program, that sends (conceptually, at
any rate) updates that should be reflected on the display, so that the
user remains aware of the state of the process.

Such applications seem to map less cleanly onto the CLIM model, and
*may* fit more nicely onto constraint-based UI frameworks like Garnet
and whatever that cells thing is...

There's probably a way to create an observer process that will capture
the state updates, update the various objects and cause them to be
redisplayed, but I don't know of a way to do this that elegantly
captures the behavior.

Speaking of which, I'm not big on the design patterns stuff --- is there
a design pattern, analogous to model-view-controller, that captures what
one does when writing a process control UI?

Best,
R



From pw at snoopy.mv.com  Wed May 23 22:14:20 2007
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Wed, 23 May 2007 18:14:20 -0400
Subject: [mcclim-devel] Update object of a presentation.
In-Reply-To: <4654B82D.6020905@real-time.com>
References: <b00235700705230206l3736ca7ci3747727fa3693e4@mail.gmail.com>	<87lkffxmfb.fsf@lambda.athas.dyndns.dk>
	<4654B82D.6020905@real-time.com>
Message-ID: <4654BCBC.8020604@snoopy.mv.com>

> 
> I have found it much more difficult to figure out how to take this UI
> model and map it onto process control applications, which are of primary
> interest to me.  In such applications, there is an external process,
> operating asynchronously with the program, that sends (conceptually, at
> any rate) updates that should be reflected on the display, so that the
> user remains aware of the state of the process.
> 
> Such applications seem to map less cleanly onto the CLIM model, and
> *may* fit more nicely onto constraint-based UI frameworks like Garnet
> and whatever that cells thing is...
> 
>

All you really have to do is modify your object and get REDISPLAY to
run. This happens by default when :incremental-redisplay is true
and the object modification is the result of a command (including some
command invoked by define-presentation-to-command-translator).

Look at Examples/stopwatch.lisp to see how an external process can cause
the display to be updated.

Paul



From mikemac at mikemac.com  Thu May 24 05:52:37 2007
From: mikemac at mikemac.com (Mike McDonald)
Date: Wed, 23 May 2007 22:52:37 -0700
Subject: [mcclim-devel] Update object of a presentation. 
In-Reply-To: Your message of "Wed, 23 May 2007 16:54:53 EST."
	<4654B82D.6020905@real-time.com> 
Message-ID: <200705240552.l4O5qbS32520@saturn.mikemac.com>


  A common mistake (IMHO) of people new to CLIM is them trying to
force everything into a presentation. Presentations are very powerful
abstractions but they are NOT the be all, end all of UI paradigms.
CLIM has a full set of graphics routines that can be used to display
information in addition to the presentation mechanism.

  A common CLIM "pattern" is based upon the Controller-Model-View GUI
paradigm. (I can't believe I've used "paradigm" twice in one Email!
Probably spelled it wrong too!) In CLIM, you can use an application
pane as the viewer, using all of CLIM's graphics routines. An
interactor pane is often used as the controller, using an application
specific command table to provide more complicated interactions than
simple GUI elements can provide. A hbox pane is often used as a button
box/menu bar for those simple interactions ('Start', 'Stop",
'Emergency Core Shutdown') that don't require additional arguments.

  I guess what I'm trying to say is that CLIM has enough power and
flexibility to handle most kinds of GUI models. Don't get stuck on
just presentations.

  Mike McDonald
  mikemac at mikemac.com


From bohmer at gmail.com  Thu May 24 20:24:46 2007
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Thu, 24 May 2007 22:24:46 +0200
Subject: [mcclim-devel] Update object of a presentation.
In-Reply-To: <4654BCBC.8020604@snoopy.mv.com>
References: <b00235700705230206l3736ca7ci3747727fa3693e4@mail.gmail.com>
	<87lkffxmfb.fsf@lambda.athas.dyndns.dk>
	<4654B82D.6020905@real-time.com> <4654BCBC.8020604@snoopy.mv.com>
Message-ID: <b00235700705241324g6e8f0ff1ma5348b73e5e6e1b8@mail.gmail.com>

Thank you for all the useful input. The stopwatch demo looks like a
good example. But I think my problem here now is that I'm trying to
update some arrows during the feedback function in drag-output-record.
Maybe some update/refresh functionality is suspended during this
function?



On 24/05/07, Paul Werkowski <pw at snoopy.mv.com> wrote:
> >
> > I have found it much more difficult to figure out how to take this UI
> > model and map it onto process control applications, which are of primary
> > interest to me.  In such applications, there is an external process,
> > operating asynchronously with the program, that sends (conceptually, at
> > any rate) updates that should be reflected on the display, so that the
> > user remains aware of the state of the process.
> >
> > Such applications seem to map less cleanly onto the CLIM model, and
> > *may* fit more nicely onto constraint-based UI frameworks like Garnet
> > and whatever that cells thing is...
> >
> >
>
> All you really have to do is modify your object and get REDISPLAY to
> run. This happens by default when :incremental-redisplay is true
> and the object modification is the result of a command (including some
> command invoked by define-presentation-to-command-translator).
>
> Look at Examples/stopwatch.lisp to see how an external process can cause
> the display to be updated.
>
> Paul
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>


-- 
Knut Olav B?hmer


From bohmer at gmail.com  Sun May 27 10:46:49 2007
From: bohmer at gmail.com (=?ISO-8859-1?Q?Knut_Olav_B=F8hmer?=)
Date: Sun, 27 May 2007 12:46:49 +0200
Subject: [mcclim-devel] Update object of a presentation.
In-Reply-To: <b00235700705241324g6e8f0ff1ma5348b73e5e6e1b8@mail.gmail.com>
References: <b00235700705230206l3736ca7ci3747727fa3693e4@mail.gmail.com>
	<87lkffxmfb.fsf@lambda.athas.dyndns.dk>
	<4654B82D.6020905@real-time.com> <4654BCBC.8020604@snoopy.mv.com>
	<b00235700705241324g6e8f0ff1ma5348b73e5e6e1b8@mail.gmail.com>
Message-ID: <b00235700705270346y380cd891uef5d0db4f2a5aba@mail.gmail.com>

On 24/05/07, Knut Olav B?hmer <bohmer at gmail.com> wrote:
> Thank you for all the useful input. The stopwatch demo looks like a
> good example. But I think my problem here now is that I'm trying to
> update some arrows during the feedback function in drag-output-record.
> Maybe some update/refresh functionality is suspended during this
> function?



I have attached my code.
What I want to do, is to update the arrows while I'm dragging the
circles (places).





-- 
Knut Olav B?hmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simulation.lisp
Type: application/octet-stream
Size: 3409 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070527/7e302a96/attachment.obj>

From daniel at bigwalter.net  Sun May 27 17:23:58 2007
From: daniel at bigwalter.net (Daniel Jensen)
Date: Sun, 27 May 2007 19:23:58 +0200
Subject: [mcclim-devel] The accept-values command table
Message-ID: <87iraei3ip.fsf@orme.bigwalter.net>

McCLIM for some reason uses the name accepting-values for the
accepting-values command table. The CLIM spec uses a slightly different
name; accept-values. This patch changes the name.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcclim-accept-values.patch
Type: text/x-patch
Size: 4150 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070527/cde42df3/attachment.bin>
-------------- next part --------------

The change will break some programs. Scigraph uses the McCLIM name in a
few places. I made a patch for this program, but I haven't tested it.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: scigraph-accept-values.patch
Type: text/x-patch
Size: 1654 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070527/cde42df3/attachment-0001.bin>

From daniel at bigwalter.net  Sun May 27 18:48:02 2007
From: daniel at bigwalter.net (Daniel Jensen)
Date: Sun, 27 May 2007 20:48:02 +0200
Subject: [mcclim-devel] Background ink in accept dialog
Message-ID: <87abvqhzml.fsf@orme.bigwalter.net>

Patch: Change accept-present-default, textual-dialog-view, to use
*3d-normal-color* for background ink. A similar change was made for
menus in menu-choose.lisp.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: accept-background-ink.patch
Type: text/x-patch
Size: 728 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20070527/7dcfc3da/attachment.bin>