From frido at q-software-solutions.de  Wed Feb  1 17:22:10 2006
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Wed, 01 Feb 2006 18:22:10 +0100
Subject: [mcclim-devel] An easy question?
Message-ID: <877j8fj8ot.fsf@flarge.here>

I'm trying to understand a bit more of clim. Now I'm stuck.

How do I write an accept method which an be used in subset-completion?

e.g I have the class
(defclass t1 ()
          ((val :initarg :val...
           (sval :initarge ...))))

Now I want to present a list of things to the user he/she can choose
from something like

(accept `(subset-completion ,(list (make-instance 't1 :val...
                                   (make-instance 't1 :val ....))))

I got a somewhat working solution with present-to-string but what I
really want is something like this

| |  "(val t1 , (sval " .... for the first object
| |  "(val t1)          .... for the second object

etc.

I'm sure there is something for that ....

Help would be very appriciated.

Regards
Friedrich


From peter.braroe at newsmachine.com  Wed Feb  1 09:57:52 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Wed, 1 Feb 2006 10:57:52 +0100
Subject: [mcclim-devel] Newbie problems with "accepting-values" / no method
	for CLIM:STREAM-CURSOR-POSITION
Message-ID: <8692cd540602010157k75435d07x1aeac1ee539617be@mail.gmail.com>

Hello all!

I am trying to get into mcCLIM to write a frontend to a text (news) analysis
tool... I use CMUCL and have followed the INSTALL.CMU file and most of the
demos work fine. But as I get down to it and start writing code to use
 "accepting-values"
for instance I get the message below. I also get it when running the demos
so i assume that something is wrong with the environment... but what? It's
probably something simple but I have tried to figgure it out for a lot of
hours and some ideas would be greatly appreciated!

Thanks,

/Peter

PS I tried wihout SLIME but that didn't work either. See second trace below.

CL-USER> (clim-demo::accepting-interval)

No matching method for the generic function
#<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58BBC3B9}>,
when
called with arguments
(#<Two-Way Stream, Input = #<SWANK-BACKEND::SLIME-INPUT-STREAM
                             {58B7D7B5}>, Output = #<Stream for descriptor
7>>).
   [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

Restarts:
  0: [CONTINUE] Retry call to :FUNCTION.
  1: [ABORT] Abort handling SLIME request.
  2: [ABORT] Return to Top-Level.

Backtrace:
  0: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<#1=unused-arg> #<#1#>
#<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58BBC3B9}>
(#<Two-Way Stream, Input = #<SWANK-BACKEND::SLIME-INPUT-STREAM {58B7D7B5}>,
Output = #<Stream for descriptor 7>>))
  1: (CLIM-INTERNALS::INVOKE-ACCEPTING-VALUES #<Two-Way Stream, Input =
#<SWANK-BACKEND::SLIME-INPUT-STREAM {58B7D7B5}>, Output = #<Stream for
descriptor 7>> #<Closure Over Function (FLET
#:ACCEPTING-VALUES-CONTINUATION1 CLIM-DEMO::ACCEPTING-INTERVAL) {58A68171}>
:OWN-WINDOW #<unused-arg> ...)
  2: (CLIM-DEMO::ACCEPTING-INTERVAL :MIN -1.0 :MAX 1.0 ...)
  3: (SWANK::EVAL-REGION "(clim-demo::accepting-interval)" T)
  4: ("DEFSLIMEFUN LISTENER-EVAL")

_____________________TRACE WITHOUT SLIME
________________________________________

* (clim-demo::accepting-interval)

No matching method for the generic function
#<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58B61979}>,
when
called with arguments (#<Synonym Stream to *TERMINAL-IO*>).
   [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

Restarts:
  0: [CONTINUE] Retry call to :FUNCTION.
  1: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
 #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58B61979}>
 (#<Synonym Stream to *TERMINAL-IO*>))
Source:
; File: target:pcl/braid.lisp
(CERROR "Retry call to ~S."
        'NO-APPLICABLE-METHOD-ERROR
        :FUNCTION GENERIC-FUNCTION
        ...)
0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060201/4e9c7e8c/attachment.html>

From moore at bricoworks.com  Wed Feb  1 17:49:34 2006
From: moore at bricoworks.com (Timothy Moore)
Date: Wed, 01 Feb 2006 18:49:34 +0100
Subject: [mcclim-devel] Newbie problems with "accepting-values" / no method
	for CLIM:STREAM-CURSOR-POSITION
In-Reply-To: <8692cd540602010157k75435d07x1aeac1ee539617be@mail.gmail.com>
References: <8692cd540602010157k75435d07x1aeac1ee539617be@mail.gmail.com>
Message-ID: <43E0F4AE.9000309@bricoworks.com>

Peter Braroe wrote:
> Hello all!
> 
> I am trying to get into mcCLIM to write a frontend to a text (news) 
> analysis tool... I use CMUCL and have followed the INSTALL.CMU file and 
> most of the demos work fine. But as I get down to it and start writing 
> code to use  "accepting-values" for instance I get the message below. I 
> also get it when running the demos so i assume that something is wrong 
> with the environment... but what? It's probably something simple but I 
> have tried to figgure it out for a lot of hours and some ideas would be 
> greatly appreciated!
> 
You can only call CLIM input/output functions with CLIM streams as 
arguments, so you can't use them interactively in a SLIME buffer or at 
the command line. I should add that of course you can launch CLIM 
applications there. However, you can do interactive CLIM experiments 
(very productive!) with the Lisp Listener application in the Apps directory.

Tim


From ahefner at gmail.com  Wed Feb  1 18:19:28 2006
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 1 Feb 2006 13:19:28 -0500
Subject: [mcclim-devel] Newbie problems with "accepting-values" / no
	method for CLIM:STREAM-CURSOR-POSITION
In-Reply-To: <8692cd540602010157k75435d07x1aeac1ee539617be@mail.gmail.com>
References: <8692cd540602010157k75435d07x1aeac1ee539617be@mail.gmail.com>
Message-ID: <31ffd3c40602011019n6f934738v64ad621c26dd5308@mail.gmail.com>

Looking at your backtrace, it appears that accepting-values is being
called on a stream from SLIME rather than a CLIM stream, so naturally
there are no applicable methods. CLIM usually binds *standard-input* 
and *standard-output* to reasonable defaults (see
frame-standard-input, frame-standard-output which make this choice). I
don't know why that isn't happening here without seeing your code,
maybe it is running in an unusual context (like before the frame
toplevel binds those stream variables, or in an event handler). In any
case, all you need to do is obtain the appropriate CLIM streams (via
any of frame-standard-input, get-frame-pane, etc) for your window and
write to those.

On 2/1/06, Peter Braroe <peter.braroe at newsmachine.com> wrote:
> Hello all!
>
> I am trying to get into mcCLIM to write a frontend to a text (news) analysis
> tool... I use CMUCL and have followed the INSTALL.CMU file and most of the
> demos work fine. But as I get down to it and start writing code to use
> "accepting-values" for instance I get the message below. I also get it when
> running the demos so i assume that something is wrong with the
> environment... but what? It's probably something simple but I have tried to
> figgure it out for a lot of hours and some ideas would be greatly
> appreciated!
>
> Thanks,
>
> /Peter
>
> PS I tried wihout SLIME but that didn't work either. See second trace below.
>
> CL-USER> (clim-demo::accepting-interval)
>
> No matching method for the generic function
> #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58BBC3B9}>,
> when
> called with arguments
> (#<Two-Way Stream, Input =
> #<SWANK-BACKEND::SLIME-INPUT-STREAM
>                              {58B7D7B5}>, Output = #<Stream for descriptor
> 7>>).
>    [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
>
> Restarts:
>   0: [CONTINUE] Retry call to :FUNCTION.
>   1: [ABORT] Abort handling SLIME request.
>   2: [ABORT] Return to Top-Level.
>
> Backtrace:
>   0: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<#1=unused-arg> #<#1#>
> #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58BBC3B9}>
> (#<Two-Way Stream, Input =
> #<SWANK-BACKEND::SLIME-INPUT-STREAM {58B7D7B5}>, Output =
> #<Stream for descriptor 7>>))
>   1: (CLIM-INTERNALS::INVOKE-ACCEPTING-VALUES #<Two-Way
> Stream, Input = #<SWANK-BACKEND::SLIME-INPUT-STREAM
> {58B7D7B5}>, Output = #<Stream for descriptor 7>> #<Closure Over Function
> (FLET #:ACCEPTING-VALUES-CONTINUATION1
> CLIM-DEMO::ACCEPTING-INTERVAL) {58A68171}> :OWN-WINDOW #<unused-arg> ...)
>   2: (CLIM-DEMO::ACCEPTING-INTERVAL :MIN -1.0 :MAX 1.0 ...)
>   3: (SWANK::EVAL-REGION "(clim-demo::accepting-interval)"
> T)
>   4: ("DEFSLIMEFUN LISTENER-EVAL")
>
> _____________________TRACE WITHOUT SLIME
> ________________________________________
>
> * (clim-demo::accepting-interval)
>
> No matching method for the generic function
> #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58B61979}>,
> when
> called with arguments (#<Synonym Stream to *TERMINAL-IO*>).
>    [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
>
> Restarts:
>   0: [CONTINUE] Retry call to :FUNCTION.
>   1: [ABORT   ] Return to Top-Level.
>
> Debug  (type H for help)
>
> ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
>  #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58B61979}>
>  (#<Synonym Stream to *TERMINAL-IO*>))
> Source:
> ; File: target:pcl/braid.lisp
> (CERROR "Retry call to ~S."
>         'NO-APPLICABLE-METHOD-ERROR
>         :FUNCTION GENERIC-FUNCTION
>         ...)
> 0]
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>
>
>


From peter.braroe at newsmachine.com  Fri Feb  3 15:35:23 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Fri, 03 Feb 2006 16:35:23 +0100
Subject: [mcclim-devel] Newbie problems with "accepting-values" / no
	method for CLIM:STREAM-CURSOR-POSITION
In-Reply-To: <31ffd3c40602011019n6f934738v64ad621c26dd5308@mail.gmail.com>
References: <8692cd540602010157k75435d07x1aeac1ee539617be@mail.gmail.com>
	<31ffd3c40602011019n6f934738v64ad621c26dd5308@mail.gmail.com>
Message-ID: <1138980923.3190.51.camel@localhost.localdomain>

Hello!

Well what I was trying to do was to run the example as I didn't trust my
own code!  So from SLIME i (as described in the documentation) invoked:

(clim-demo::accepting-interval)

The same thing didn't work when trying directly when loading CMUCL from
the command line... The above code is same as in the 0.9.1 distro. 

Perhpas this has something to do with the multiprocessing? Forgive my
naivete but I am a newbie to LISP. I tried to do
(mp::startup-idle-and-top-level-loops) but that doesnt seem to work
(just says "no value") with SLIME so i have googled and instead set the
elisp variable slime-multiprocessing to t. I don't know if this is the
same or how to chech which processes are active - is there some kind of
"top" for LISP? Any pointers to good documentation here? I have found
clim-ug.pdf and expect to do some serious weekend reading.

Are you guys using slime? what I basically want to do as a first step is
to create a command called "tree-draw" which draws a tree diagram of my
data from the slime command line. 

What is the best way to create a window so I can do some simple stuff
like (clim:draw-line* *my-sheet* 200 10 10 150) to make my tree diagram.
I wan't the tree drawing to use data created by running previous
commands from the slime command line. 

Later I want to create a full app with a root window and child windows
for different graphs, status info, configuration dialogs and other
things. Any ideas on where I can find sources for a more full bodied app
to look at and lean from? 

Thanks for your help so far! 

/Peter

PS CLIM seems cool, a lot more elegant than programming in Java for
instance. But it seems a bit hard to get into due to lack of newbie
style documentation - I am happy to write together the feedback and
collection of "non-obvious but simple" stuff that an beginner needs to
know for publication somewhere suitable! Good idea?








What works for me:
gadget-test
calculator






On Wed, 2006-02-01 at 13:19 -0500, Andy Hefner wrote: 
> Looking at your backtrace, it appears that accepting-values is being
> called on a stream from SLIME rather than a CLIM stream, so naturally
> there are no applicable methods. CLIM usually binds *standard-input* 
> and *standard-output* to reasonable defaults (see
> frame-standard-input, frame-standard-output which make this choice). I
> don't know why that isn't happening here without seeing your code,
> maybe it is running in an unusual context (like before the frame
> toplevel binds those stream variables, or in an event handler). In any
> case, all you need to do is obtain the appropriate CLIM streams (via
> any of frame-standard-input, get-frame-pane, etc) for your window and
> write to those.
> 
> On 2/1/06, Peter Braroe <peter.braroe at newsmachine.com> wrote:
> > Hello all!
> >
> > I am trying to get into mcCLIM to write a frontend to a text (news) analysis
> > tool... I use CMUCL and have followed the INSTALL.CMU file and most of the
> > demos work fine. But as I get down to it and start writing code to use
> > "accepting-values" for instance I get the message below. I also get it when
> > running the demos so i assume that something is wrong with the
> > environment... but what? It's probably something simple but I have tried to
> > figgure it out for a lot of hours and some ideas would be greatly
> > appreciated!
> >
> > Thanks,
> >
> > /Peter
> >
> > PS I tried wihout SLIME but that didn't work either. See second trace below.
> >
> > CL-USER> (clim-demo::accepting-interval)
> >
> > No matching method for the generic function
> > #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58BBC3B9}>,
> > when
> > called with arguments
> > (#<Two-Way Stream, Input =
> > #<SWANK-BACKEND::SLIME-INPUT-STREAM
> >                              {58B7D7B5}>, Output = #<Stream for descriptor
> > 7>>).
> >    [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
> >
> > Restarts:
> >   0: [CONTINUE] Retry call to :FUNCTION.
> >   1: [ABORT] Abort handling SLIME request.
> >   2: [ABORT] Return to Top-Level.
> >
> > Backtrace:
> >   0: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<#1=unused-arg> #<#1#>
> > #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58BBC3B9}>
> > (#<Two-Way Stream, Input =
> > #<SWANK-BACKEND::SLIME-INPUT-STREAM {58B7D7B5}>, Output =
> > #<Stream for descriptor 7>>))
> >   1: (CLIM-INTERNALS::INVOKE-ACCEPTING-VALUES #<Two-Way
> > Stream, Input = #<SWANK-BACKEND::SLIME-INPUT-STREAM
> > {58B7D7B5}>, Output = #<Stream for descriptor 7>> #<Closure Over Function
> > (FLET #:ACCEPTING-VALUES-CONTINUATION1
> > CLIM-DEMO::ACCEPTING-INTERVAL) {58A68171}> :OWN-WINDOW #<unused-arg> ...)
> >   2: (CLIM-DEMO::ACCEPTING-INTERVAL :MIN -1.0 :MAX 1.0 ...)
> >   3: (SWANK::EVAL-REGION "(clim-demo::accepting-interval)"
> > T)
> >   4: ("DEFSLIMEFUN LISTENER-EVAL")
> >
> > _____________________TRACE WITHOUT SLIME
> > ________________________________________
> >
> > * (clim-demo::accepting-interval)
> >
> > No matching method for the generic function
> > #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58B61979}>,
> > when
> > called with arguments (#<Synonym Stream to *TERMINAL-IO*>).
> >    [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
> >
> > Restarts:
> >   0: [CONTINUE] Retry call to :FUNCTION.
> >   1: [ABORT   ] Return to Top-Level.
> >
> > Debug  (type H for help)
> >
> > ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
> >  #<STANDARD-GENERIC-FUNCTION CLIM:STREAM-CURSOR-POSITION (2) {58B61979}>
> >  (#<Synonym Stream to *TERMINAL-IO*>))
> > Source:
> > ; File: target:pcl/braid.lisp
> > (CERROR "Retry call to ~S."
> >         'NO-APPLICABLE-METHOD-ERROR
> >         :FUNCTION GENERIC-FUNCTION
> >         ...)
> > 0]
> >
> > _______________________________________________
> > mcclim-devel mailing list
> > mcclim-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> >
> >
> >



From idurand at labri.fr  Fri Feb  3 15:46:38 2006
From: idurand at labri.fr (Irene DURAND)
Date: Fri, 03 Feb 2006 16:46:38 +0100
Subject: [mcclim-devel] The function (SETF RECTANGLE-EDGES*) is undefined.
Message-ID: <43E37ADE.9040907@labri.fr>

Hello,

With an updated version of mcclim and SBCL 0.9.5, my software Autowrite 
does not run anymore (see stackframe below).
The same software compiles and runs fine with CMUCL and a previous clim 
core.
-- 

Ir?ne 
http://dept-info.labri.u-bordeaux.fr/~idurand


The function (SETF RECTANGLE-EDGES*) is undefined.
   [Condition of type UNDEFINED-FUNCTION]

Restarts:
  0: [ABORT] Return to application command loop
  1: [ABORT-REQUEST] Abort handling SLIME request.
  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {A462359}>)

Backtrace:
  0: ("bogus stack frame")
  1: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> 0 #<GOATEE::SCREEN-LINE X 81:81 Y 0:0 "" {A9CDB11}>)
  2: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER (GOATEE::SCREEN-LINE)) (#(NIL 0 10 4 11) . #()) #<unavailable argument> #<GOATEE::SCREEN-LINE X 81:81 Y 0:0 "" {A9CDB11}> (:X-POSITION 81 :Y-POSITION 0 :PARENT #<GOATEE:SIMPLE-SCREEN-AREA X 81:81 Y 0:0 {A797881}> :BUFFER-LINE #<GOATEE::EXTENT-BUFFER-LINE ""> :LAST-TICK 2 ...))
  3: ((LAMBDA (SB-PCL::|.P0.| SB-PCL::|.P1.| SB-PCL::|.P2.| SB-PCL::|.P3.| SB-PCL::|.P4.| SB-PCL::|.P5.| SB-PCL::|.P6.| SB-PCL::|.P7.|)) #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument>)
  4: ((SB-PCL::FAST-METHOD GOATEE::INITIALIZE-AREA-FROM-BUFFER (GOATEE:SIMPLE-SCREEN-AREA T)) (#(NIL 16) . #()) #<unavailable argument> #<GOATEE:SIMPLE-SCREEN-AREA X 81:81 Y 0:0 {A797881}> #<GOATEE::EDITABLE-BUFFER {A53CC29}>)
  5: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER (GOATEE:SIMPLE-SCREEN-AREA)) (#(NIL 17 15 22 21 19 16) . #()) #<unavailable argument> #<GOATEE:SIMPLE-SCREEN-AREA X 81:81 Y 0:0 {A797881}> (:AREA-STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :BUFFER #<GOATEE::EDITABLE-BUFFER {A53CC29}> :X-POSITION 81 :Y-POSITION 0 :CURSOR-VISIBILITY T ...))
  6: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.DFUN-REST-ARG.)) #<unavailable argument> #<unavailable argument> #<GOATEE:SIMPLE-SCREEN-AREA X 81:81 Y 0:0 {A797881}> (:AREA-STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :BUFFER #<GOATEE::EDITABLE-BUFFER {A53CC29}> :X-POSITION 81 :Y-POSITION 0 :CURSOR-VISIBILITY T ...))
  7: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) #<unavailable argument> #<unavailable argument> #<STANDARD-CLASS GOATEE:SIMPLE-SCREEN-AREA> (:AREA-STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :BUFFER #<GOATEE::EDITABLE-BUFFER {A53CC29}> :X-POSITION 81 :Y-POSITION 0 :CURSOR-VISIBILITY T ...))
  8: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER (GOATEE:GOATEE-INPUT-EDITING-MIXIN)) #<unavailable argument> #<unavailable argument> #<STANDARD-INPUT-EDITING-STREAM {986DAE1}> (:STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :INITIAL-CONTENTS ""))
  9: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.DFUN-REST-ARG.)) #<unavailable argument> #<unavailable argument> #<STANDARD-INPUT-EDITING-STREAM {986DAE1}> (:STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :INITIAL-CONTENTS ""))
 10: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) #<unavailable argument> #<unavailable argument> #<STANDARD-CLASS STANDARD-INPUT-EDITING-STREAM> (:STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :INITIAL-CONTENTS ""))
 11: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING (EXTENDED-INPUT-STREAM T T T T)) #<unavailable argument> #<unavailable argument> #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> #<CLOSURE (LAMBDA (STREAM)) {97BBD85}> #<CLOSURE (LAMBDA (STREAM CLIM-INTERNALS::CONT)) {97BBDD5}> "" STANDARD-INPUT-EDITING-STREAM)
 12: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING :AROUND (EXTENDED-OUTPUT-STREAM T T T T)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING #)> :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION #> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (5)) :ARG-INFO (5)) #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> #<CLOSURE (LAMBDA (STREAM)) {97BBD85}> #<CLOSURE (LAMBDA (STREAM CLIM-INTERNALS::CONT)) {97BBDD5}> "" STANDARD-INPUT-EDITING-STREAM)
 13: (ACCEPT (COMMAND :COMMAND-TABLE #<STANDARD-COMMAND-TABLE AUTOWRITE {A023991}>) :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :PROMPT NIL :DEFAULT (CLIM-INTERNALS::COM-NULL-COMMAND) :DEFAULT-TYPE CLIM-INTERNALS::NULL-COMMAND)
 14: (READ-COMMAND #<STANDARD-COMMAND-TABLE AUTOWRITE {A023991}> :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL :USE-KEYSTROKES NIL)
 15: (READ-COMMAND-USING-KEYSTROKES #<STANDARD-COMMAND-TABLE AUTOWRITE {A023991}> NIL :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL)
 16: (READ-COMMAND #<STANDARD-COMMAND-TABLE AUTOWRITE {A023991}> :STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}> :COMMAND-PARSER NIL :COMMAND-UNPARSER NIL :PARTIAL-COMMAND-PARSER NIL :USE-KEYSTROKES T)
 17: ((SB-PCL::FAST-METHOD READ-FRAME-COMMAND :AROUND (APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD READ-FRAME-COMMAND #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<AUTOWRITE {961A071}> (:STREAM #<INTERACTOR-PANE INTERACTOR-PANE {ACCB111}>))
 18: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<AUTOWRITE {961A071}> NIL)
 19: ((SB-PCL::FAST-METHOD DEFAULT-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<AUTOWRITE {961A071}> NIL)
 20: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.DFUN-REST-ARG.)) #<unavailable argument> #<unavailable argument> #<AUTOWRITE {961A071}> NIL)
 21: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL (APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<AUTOWRITE {961A071}> #<unavailable argument>)
 22: ((SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL :AROUND (APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD RUN-FRAME-TOP-LEVEL #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<AUTOWRITE {961A071}> NIL)
 23: (INTERFACE)
 24: (SB-INT:EVAL-IN-LEXENV (START) #<NULL-LEXENV>)
 25: (SWANK::EVAL-REGION "(start)
" T)
 26: ((LAMBDA NIL))
 27: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL) {A6EF1FD}>)
 28: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL) {A6EF1FD}>)
 29: (SB-INT:EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(start)
") #<NULL-LEXENV>)
 30: ((LAMBDA NIL))
 31: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {A6EEB9D}>)
 32: ((LAMBDA NIL))
 33: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {9E5E8DD}>)
 34: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A310E51}> #<CLOSURE (LAMBDA NIL) {A6EEA5D}>)
 35: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {A310E51}> #<FUNCTION (LAMBDA NIL) {9E5E8DD}>)
 36: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {A310E51}>)
 37: ((LAMBDA NIL))
 38: ((LAMBDA NIL))
 39: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {A46B07D}>)
 40: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A310E51}> #<CLOSURE (LAMBDA NIL) {A46B08D}>)
 41: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {A310E51}> #<CLOSURE (LAMBDA NIL) {A46B07D}>)
 42: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {A46B05D}>)
 43: ((LAMBDA NIL))
 44: ("foreign function: call_into_lisp")
 45: ("foreign function: funcall0")
 46: ("foreign function: new_thread_trampoline")
 47: ("foreign function: #x53EB80")




From amoroso at mclink.it  Fri Feb  3 16:29:39 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 03 Feb 2006 17:29:39 +0100
Subject: [mcclim-devel] Newbie problems with "accepting-values" / no
	method for CLIM:STREAM-CURSOR-POSITION
In-Reply-To: <1138980923.3190.51.camel@localhost.localdomain> (Peter
	Braroe's message of "Fri, 03 Feb 2006 16:35:23 +0100")
References: <8692cd540602010157k75435d07x1aeac1ee539617be@mail.gmail.com>
	<31ffd3c40602011019n6f934738v64ad621c26dd5308@mail.gmail.com>
	<1138980923.3190.51.camel@localhost.localdomain>
Message-ID: <873bj02yoc.fsf@plato.moon.paoloamoroso.it>

Peter Braroe <peter.braroe at newsmachine.com> writes:

> Well what I was trying to do was to run the example as I didn't trust my
> own code!  So from SLIME i (as described in the documentation) invoked:
>
> (clim-demo::accepting-interval)
>
> The same thing didn't work when trying directly when loading CMUCL from
> the command line... The above code is same as in the 0.9.1 distro. 

Try evaluating the above form from the CLIM Listener.


> things. Any ideas on where I can find sources for a more full bodied app
> to look at and lean from? 

You might start here:

  http://www.cl-user.net/asp/tags/clim


> PS CLIM seems cool, a lot more elegant than programming in Java for
> instance. But it seems a bit hard to get into due to lack of newbie
> style documentation - I am happy to write together the feedback and
> collection of "non-obvious but simple" stuff that an beginner needs to
> know for publication somewhere suitable! Good idea?

You might consider joining some of the gardeners projects, or starting
a new one:

  CL Gardeners - Tending the Common Lisp garden
  http://www.lispniks.com/cl-gardeners/


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From moore at bricoworks.com  Fri Feb  3 16:39:44 2006
From: moore at bricoworks.com (Timothy Moore)
Date: Fri, 03 Feb 2006 17:39:44 +0100
Subject: [mcclim-devel] The function (SETF RECTANGLE-EDGES*) is undefined.
In-Reply-To: <43E37ADE.9040907@labri.fr>
References: <43E37ADE.9040907@labri.fr>
Message-ID: <43E38750.6060009@bricoworks.com>

Irene DURAND wrote:
> Hello,
> 
> With an updated version of mcclim and SBCL 0.9.5, my software Autowrite 
> does not run anymore (see stackframe below).
> The same software compiles and runs fine with CMUCL and a previous clim 
> core.

[problem with (setf rectangle-edges*)]

The setf* stuff changed recently. You need to be sure you've recompiled 
all your files that use CLIM.

Tim


From athas at sigkill.dk  Sat Feb  4 20:56:09 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Sat, 04 Feb 2006 21:56:09 +0100
Subject: [mcclim-devel] Proper naming of threads under SBCL (patch)
Message-ID: <8764nuhmhi.fsf@sigkill.dk>

Attached is a patch which will pass the names of threads created with
`make-process' properly on to `sb-thread:make-thread' under
SBCL. Without this patch, the specified names of threads will not show
up when doing a thread listing with `sb-thread:list-all-threads'.

It's an extremely simple patch and it hasn't caused any problems for
me.
-- 
\  Troels "Athas" Henriksen
/\ sigkill.dk/blog (Danish)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp-sbcl.lisp
Type: application/octet-stream
Size: 691 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060204/f177d0e7/attachment.obj>

From asf at boinkor.net  Sun Feb  5 15:13:36 2006
From: asf at boinkor.net (Andreas Fuchs)
Date: Sun, 05 Feb 2006 16:13:36 +0100
Subject: [mcclim-devel] standard-tree-output-records using spatial-trees
Message-ID: <873bixkfdr.wl%asf@boinkor.net>

Hi all,

As this is the first weekend of my holidays, I hacked on mcclim a
little. So, I implemented standard-tree-output-records as per Tim
Moore's suggestion, using R-trees from Christophe's excellent
spatial-trees library. This one didn't take as long as I expected:
about 4 hours. Props to Xof (-:

I tested the change against beirc, which seems to be working. No
performance measurements yet. I'll just sit on #lisp and wait for the
scrollback buffer to grow (-:

Here's the patch:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,tree-output-records.patch
Type: application/octet-stream
Size: 7047 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060205/78631332/attachment.obj>
-------------- next part --------------

Comments and testers (both for correctness and for performance
improvements/degradation) welcome!

Have fun,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

From asf at boinkor.net  Sun Feb  5 22:51:49 2006
From: asf at boinkor.net (Andreas Fuchs)
Date: Sun, 05 Feb 2006 23:51:49 +0100
Subject: [mcclim-devel] standard-tree-output-records using spatial-trees
In-Reply-To: <873bixkfdr.wl%asf@boinkor.net>
References: <873bixkfdr.wl%asf@boinkor.net>
Message-ID: <87wtg9iflm.wl%asf@boinkor.net>

Today, Andreas Fuchs <asf at boinkor.net> wrote:
> Here's the patch:

Turns out that this patch has problems with asdf-loading mcclim
(spatial-trees depend on mcclim if certain features are present), so
here's an uptdated patch:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,tree-output-records.patch
Type: application/octet-stream
Size: 7543 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060205/5c3a0a9b/attachment.obj>
-------------- next part --------------
Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

From csr21 at cam.ac.uk  Mon Feb  6 15:03:09 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 06 Feb 2006 15:03:09 +0000
Subject: [mcclim-devel] postscript streams
Message-ID: <sqbqxkedhu.fsf@cam.ac.uk>

Hi,

I'm in the process of attempting to merge our local divergences into
mcclim's CVS, and I have a question about one of them (see below): is
it reasonable to add updating-output-stream-mixin to the
postscript-stream class?  Though memory grows dim, I think we use this
to allow the same drawing routines (which use updating-output) to draw
both to screen and to postscript; we don't actually call
incremental-redisplay on a postscript stream.

Thanks,

Christophe

Index: Backends/PostScript/class.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Backends/PostScript/class.lisp,v
retrieving revision 1.7
diff -u -r1.7 class.lisp
--- Backends/PostScript/class.lisp      31 Oct 2005 10:21:14 -0000      1.7
+++ Backends/PostScript/class.lisp      6 Feb 2006 12:30:36 -0000
@@ -61,6 +61,7 @@
                              permanent-medium-sheet-output-mixin
                              sheet-mute-repainting-mixin
                              mirrored-sheet-mixin ; ?
+                             climi::updating-output-stream-mixin ; ??
                              standard-extended-output-stream
                              standard-output-recording-stream)
   ((file-stream :initarg :file-stream :reader postscript-stream-file-stream)


From moore at bricoworks.com  Mon Feb  6 16:36:52 2006
From: moore at bricoworks.com (Timothy Moore)
Date: Mon, 06 Feb 2006 17:36:52 +0100
Subject: [mcclim-devel] postscript streams
In-Reply-To: <sqbqxkedhu.fsf@cam.ac.uk>
References: <sqbqxkedhu.fsf@cam.ac.uk>
Message-ID: <43E77B24.5080900@bricoworks.com>

Christophe Rhodes wrote:
> Hi,
> 
> I'm in the process of attempting to merge our local divergences into
> mcclim's CVS, and I have a question about one of them (see below): is
> it reasonable to add updating-output-stream-mixin to the
> postscript-stream class?  Though memory grows dim, I think we use this
> to allow the same drawing routines (which use updating-output) to draw
> both to screen and to postscript; we don't actually call
> incremental-redisplay on a postscript stream.
I agree with this change. If you wanted to be more ambitious and make 
updating-output-stream-mixin a super class of 
standard-output-recording-stream, I'd be quite agreeable to that too.

Tim

> 
> Thanks,
> 
> Christophe
> 
> Index: Backends/PostScript/class.lisp
> ===================================================================
> RCS file: /project/mcclim/cvsroot/mcclim/Backends/PostScript/class.lisp,v
> retrieving revision 1.7
> diff -u -r1.7 class.lisp
> --- Backends/PostScript/class.lisp      31 Oct 2005 10:21:14 -0000      1.7
> +++ Backends/PostScript/class.lisp      6 Feb 2006 12:30:36 -0000
> @@ -61,6 +61,7 @@
>                               permanent-medium-sheet-output-mixin
>                               sheet-mute-repainting-mixin
>                               mirrored-sheet-mixin ; ?
> +                             climi::updating-output-stream-mixin ; ??
>                               standard-extended-output-stream
>                               standard-output-recording-stream)
>    ((file-stream :initarg :file-stream :reader postscript-stream-file-stream)
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From csr21 at cam.ac.uk  Mon Feb  6 16:38:58 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 06 Feb 2006 16:38:58 +0000
Subject: [mcclim-devel] CLX translate function
Message-ID: <sq7j88e925.fsf@cam.ac.uk>

Hi,

Another divergence minimization patch for review, this time slightly
more involved.  It is to do with the translation function for the CLX
backend, and while it doesn't intend to introduce any functionality
(or lack of it) that there was before, I'd feel happier to know that
someone other than me understood my comment.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: medium.diff
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060206/bb58525d/attachment.ksh>
-------------- next part --------------

Cheers,

Christophe

From csr21 at cam.ac.uk  Mon Feb  6 16:52:54 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 06 Feb 2006 16:52:54 +0000
Subject: [mcclim-devel] postscript streams
In-Reply-To: <43E77B24.5080900@bricoworks.com> (Timothy Moore's message of
	"Mon, 06 Feb 2006 17:36:52 +0100")
References: <sqbqxkedhu.fsf@cam.ac.uk> <43E77B24.5080900@bricoworks.com>
Message-ID: <sq3biwe8ex.fsf@cam.ac.uk>

Timothy Moore <moore at bricoworks.com> writes:

> I agree with this change. If you wanted to be more ambitious and make
> updating-output-stream-mixin a super class of
> standard-output-recording-stream, I'd be quite agreeable to that too.

I decided to be unambitious, and restricted myself to leaving a
comment to that effect.

Cheers,

Christophe


From peter.braroe at newsmachine.com  Tue Feb  7 09:50:12 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Tue, 07 Feb 2006 10:50:12 +0100
Subject: [mcclim-devel] Problems getting "format-graph-from-roots" to work...
Message-ID: <1139305812.5740.15.camel@localhost.localdomain>

Hello all! 

I have gotten slightly further in my ambition to make a clim program to
draw tree diagrams. After looking at various examples I have put
together a little program that gives the error below. 

No matching method for the generic function
#<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}>,
when
called with arguments
(#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y
0.0d0:0.0d0
   {59D5278D}>
 #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> NIL NIL).
   [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]


I am loading CLIM with asdf in my .cmucl-init and doing other stuff such
as drawing a lines, rectangles works fine... Is it the code or my
environment? I am getting seriously frustrated...

Ideas? 

Also my clim package 0.9.1 does not seem to have
"format-graph-from-root" (singular) only the "format-graph-from-roots"
is this because the one root only version is not implemented? Does
anyone know?

Thanks beforehand for any help, 

/Peter
______________________________________________________________________
draw-tree.cl

(defpackage :tree-test (:USE :CLIM :CLIM-EXTENSIONS :CLIM-LISP))

(in-package :tree-test)

(defvar *test-frame* nil)
(defvar *test-pane* nil)

(defun run-tree-test ()
  (let ((*test-frame*
	       (setf *test-frame*
		     (make-application-frame 'tree-test
					     :height 400
					     :width 700 					     :doc-title "Tree diagram test"))))
    (run-frame-top-level *test-frame*)
    *test-frame*))


(define-application-frame tree-test ()
  ()
  
  (:menu-bar menubar-command-table)
  (:panes
   (screen :application
           :display-time nil
           :text-style (make-text-style :sans-serif :roman :normal)
	   )
   )
  (:layouts
   (defaults (vertically () screen)
     )
   )
  #+nil
  (:top-level (tree-test-frame-top-level)))

(make-command-table 'menubar-command-table
		    :errorp nil
		    :menu '(("Draw Tree" :command com-tree)))

(define-tree-test-command com-tree ()
  (draw-tree))


(defun draw-tree ()

  (setq *test-pane* (get-frame-pane *test-frame* 'screen))

  (format-graph-from-roots '((a (b (d)) (c (d))))
			   #'(lambda (x s) (princ (car x) s))
			   #'cdr
			   :stream *standard-output*
			   :orientation :vertical
			   :merge-duplicates t
			   :duplicate-key #'car))



Note: Have tried both *standard-output* and *test-pane* as :stream

______________________________________________________________________
No matching method for the generic function
#<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}>,
when
called with arguments
(#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y
0.0d0:0.0d0
   {59D5278D}>
 #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> NIL NIL).
   [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

Restarts:
  0: [CONTINUE] Retry call to :FUNCTION.
  1: [ABORT] Return to application command loop
  2: [ABORT] Abort handling SLIME request.
  3: [ABORT] Return to Top-Level.

Backtrace:
  0: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<#1=unused-arg> #<#1#>
#<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}>
(#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y
0.0d0:0.0d0 {59D5278D}> #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN
{59BF5855}> NIL NIL))
  1: ((FLET #:CONTINUATION99 (LABELS CLIM-INTERNALS::CONT
CLIM:FORMAT-GRAPH-FROM-ROOTS)) #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN
{59BF5855}>)
  2: ((METHOD CLIM:INVOKE-WITH-OUTPUT-RECORDING-OPTIONS NIL
(CLIM:OUTPUT-RECORDING-STREAM T T T)) #<#1=unused-arg> #<#1#>
#<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> #<Closure Over
Function (FLET #:CONTINUATION99 (LABELS CLIM-INTERNALS::CONT
CLIM:FORMAT-GRAPH-FROM-ROOTS)) {59D528C1}> ...)
  3: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL
(CLIM:OUTPUT-RECORDING-STREAM T T NULL)) (#() . #(#)) #<unused-arg>
#<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> #<Closure Over
Function (LABELS CLIM-INTERNALS::CONT CLIM:FORMAT-GRAPH-FROM-ROOTS)
{59D51C09}> ...)
  4: (CLIM:FORMAT-GRAPH-FROM-ROOTS ((TREE-TEST::A # #)) #<Function
"DEFUN DRAW-TREE" {59BEF231}> #<Function CDR
{101CF0C9}> :ORIENTATION ...)
  5: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
(#() . #(# # # # # ...)) #<unused-arg> #<TREE-TEST::TREE-TEST
{59BF2A5D}> NIL)
  6: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G6356)" #<#1=unused-arg>
#<#1#> #<TREE-TEST::TREE-TEST {59BF2A5D}> NIL)
  7: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
(#(20) . #()) #<#1=unused-arg> #<TREE-TEST::TREE-TEST {59BF2A5D}>
#<#1#>)
  8: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND)
#1=(CLIM:APPLICATION-FRAME)) (#(16 15) . #(#))
#S(PCL::FAST-METHOD-CALL :FUNCTION #<Function (METHOD
CLIM:RUN-FRAME-TOP-LEVEL NIL #1#) {58C4A031}> :PV-CELL (# .
#) :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<TREE-TEST::TREE-TEST
{59BF2A5D}> NIL)
  9: (TREE-TEST::RUN-TREE-TEST)
 10: (SWANK::EVAL-REGION "(tree-test::run-tree-test)
" T)
 11: ("DEFSLIMEFUN LISTENER-EVAL")
 12: (SWANK::CALL-WITH-BUFFER-SYNTAX #<Closure Over Function
"DEFSLIMEFUN LISTENER-EVAL" {59BF2261}>)
 13: ("DEFUN EVAL-FOR-EMACS")
 14: ((METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK NIL (T T))
#<#1=unused-arg> #<#1#> #<Function SWANK:SWANK-DEBUGGER-HOOK {59F4E871}>
#<Closure Over Function "DEFUN EVAL-FOR-EMACS" {59BF2189}>)
 15: ("DEFUN HANDLE-REQUEST")
 16: ("DEFUN CALL-WITH-CONNECTION")
 17: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {59F36D15}>
#<Closure Over Function "DEFUN CALL-WITH-CONNECTION" {59BF1F09}>)
 18: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {59F36D15}>
#<Function "DEFUN HANDLE-REQUEST" {5A001911}>)
 19: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {59F36D15}>)
 20: (SWANK::PROCESS-AVAILABLE-INPUT #<Stream for descriptor 6>
#<Closure Over Function "DEFUN INSTALL-SIGIO-HANDLER" {59BF1EF9}>)
 21: ((FLET SWANK::HANDLER SWANK::INSTALL-SIGIO-HANDLER))
 22: (SWANK-BACKEND::SIGIO-HANDLER #<#1=unused-arg> #<#1#> #<#1#>)
 23: ("call_into_lisp+#x8C [#x80548DC] /usr/bin/cmucl")
 24: ("funcall3+#x29 [#x80546E4] /usr/bin/cmucl")
 25: ("interrupt_handle_now+#xEF [#x80503A3] /usr/bin/cmucl")
 26: ("NIL+#x80507C4 [#x80507C4] /usr/bin/cmucl")
 27: ("__kernel_sigreturn+#x0 [#xFFFFE420] ")
 28: (SYSTEM:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL)
 29: (LISP::DO-INPUT #<Stream for Standard Input>)
 30: (LISP::INPUT-CHARACTER #<Stream for Standard Input> NIL
(LISP::*EOF*))
 31: (LISP::SYNONYM-IN #<Synonym Stream to SYSTEM:*STDIN*> NIL
(LISP::*EOF*))
 32: (LISP::TWO-WAY-IN #<Two-Way Stream, Input = #<Synonym Stream to
SYSTEM:*STDIN*>, Output = #<Synonym Stream to SYSTEM:*STDOUT*>> NIL
(LISP::*EOF*))
 33: (LISP::SYNONYM-IN #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (LISP::*EOF*))
 34: (READ-CHAR #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL
(LISP::*EOF*) NIL)
 35: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) T)
 36: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL)
 37: (LISP::READ-PRESERVING-WHITESPACE-INTERNAL 4 #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) ...)[:EXTERNAL]
 38: (LISP::READ-INTERNAL #<Synonym Stream to
SWANK::*CURRENT-STANDARD-INPUT*> NIL (:EOF) NIL)
 39: (READ #<Synonym Stream to SWANK::*CURRENT-STANDARD-INPUT*> NIL
(:EOF) NIL)
 40: (LISP::%TOP-LEVEL)
 41: ((LABELS LISP::RESTART-LISP SAVE-LISP))




From csr21 at cam.ac.uk  Tue Feb  7 10:13:31 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 07 Feb 2006 10:13:31 +0000
Subject: [mcclim-devel] Problems getting "format-graph-from-roots" to
	work...
In-Reply-To: <1139305812.5740.15.camel@localhost.localdomain> (Peter Braroe's
	message of "Tue, 07 Feb 2006 10:50:12 +0100")
References: <1139305812.5740.15.camel@localhost.localdomain>
Message-ID: <sqpslzeat0.fsf@cam.ac.uk>

Peter Braroe <peter.braroe at newsmachine.com> writes:

> I have gotten slightly further in my ambition to make a clim program to
> draw tree diagrams. After looking at various examples I have put
> together a little program that gives the error below. 

I believe that the more complicated graph layouts (:digraph, maybe
:dag?) are currently unimplemented.  Try passing :graph-type :tree
explicitly to FORMAT-GRAPH-FROM-ROOTS.

> Also my clim package 0.9.1 does not seem to have
> "format-graph-from-root" (singular) only the "format-graph-from-roots"
> is this because the one root only version is not implemented? Does
> anyone know?

The singular FORMAT-GRAPH-FROM-ROOT appears not to be in the Clim II
specification.

Cheers,

Christophe


From amoroso at mclink.it  Tue Feb  7 12:17:23 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 07 Feb 2006 13:17:23 +0100
Subject: [mcclim-devel] Problems getting "format-graph-from-roots" to
	work...
In-Reply-To: <1139305812.5740.15.camel@localhost.localdomain> (Peter
	Braroe's message of "Tue, 07 Feb 2006 10:50:12 +0100")
References: <1139305812.5740.15.camel@localhost.localdomain>
Message-ID: <87acd3pdm4.fsf@plato.moon.paoloamoroso.it>

Peter Braroe <peter.braroe at newsmachine.com> writes:

> I have gotten slightly further in my ambition to make a clim program to
> draw tree diagrams. After looking at various examples I have put
> together a little program that gives the error below. 
[...]
> Also my clim package 0.9.1 does not seem to have

Have you tried the CVS version?


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From peter.braroe at newsmachine.com  Tue Feb  7 13:45:23 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Tue, 7 Feb 2006 14:45:23 +0100
Subject: SV: [mcclim-devel] Problems getting "format-graph-from-roots"
	towork...
In-Reply-To: <87acd3pdm4.fsf@plato.moon.paoloamoroso.it>
Message-ID: <20060207134723.5F5D42A034@common-lisp.net>

Hello!

I got it working with Christophes tip! Thanks! 

Now all I need to do is to figure out how to get it to draw in color... does
anyone know if that is supported with :ink or some other method?

Thanks!

/Peter

--------------------------------------------------------------------------
Peter A. Braroe                    
NewsMachine     

-----Ursprungligt meddelande-----
Fr?n: mcclim-devel-bounces at common-lisp.net
[mailto:mcclim-devel-bounces at common-lisp.net] F?r Paolo Amoroso
Skickat: den 7 februari 2006 13:17
Till: mcclim
?mne: Re: [mcclim-devel] Problems getting "format-graph-from-roots"
towork...

Peter Braroe <peter.braroe at newsmachine.com> writes:

> I have gotten slightly further in my ambition to make a clim program to
> draw tree diagrams. After looking at various examples I have put
> together a little program that gives the error below. 
[...]
> Also my clim package 0.9.1 does not seem to have

Have you tried the CVS version?


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
_______________________________________________
mcclim-devel mailing list
mcclim-devel at common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From amoroso at mclink.it  Tue Feb  7 14:13:17 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 07 Feb 2006 15:13:17 +0100
Subject: SV: [mcclim-devel] Problems getting "format-graph-from-roots"
	towork...
In-Reply-To: <200602071345.k17DjdO1021312@mailhub6.mclink.it> (Peter
	Braroe's message of "Tue, 7 Feb 2006 14:45:23 +0100")
References: <200602071345.k17DjdO1021312@mailhub6.mclink.it>
Message-ID: <87irrrntoi.fsf@plato.moon.paoloamoroso.it>

"Peter Braroe" <peter.braroe at newsmachine.com> writes:

> Now all I need to do is to figure out how to get it to draw in color... does
> anyone know if that is supported with :ink or some other method?

Try wrapping the drawing operations into a WITH-DRAWING-OPTIONS form.


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From peter.braroe at newsmachine.com  Tue Feb  7 14:17:43 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Tue, 7 Feb 2006 15:17:43 +0100
Subject: SV: SV: [mcclim-devel] Problems getting
	"format-graph-from-roots"towork...
In-Reply-To: <87irrrntoi.fsf@plato.moon.paoloamoroso.it>
Message-ID: <20060207141301.594747C03B@common-lisp.net>

Hello!

Tried it but didnt seem to work... :-( I will mail you a screenshot direct
(tried to post it to the mailing list before but it was too big and bounced,
apparently there is a 40K limit!)

Ideas?

/Peter

----------------------------------------------------------------------------
--
Peter A. Braroe                    
VD, NewsMachine     
Blekingegatan 44
S-116 62 Stockholm
Office: +46-(0)8-442 03 31     
Mobile: +46-(0)708-750 991

-----Ursprungligt meddelande-----
Fr?n: mcclim-devel-bounces at common-lisp.net
[mailto:mcclim-devel-bounces at common-lisp.net] F?r Paolo Amoroso
Skickat: den 7 februari 2006 15:13
Till: 'mcclim'
?mne: Re: SV: [mcclim-devel] Problems getting
"format-graph-from-roots"towork...

"Peter Braroe" <peter.braroe at newsmachine.com> writes:

> Now all I need to do is to figure out how to get it to draw in color...
does
> anyone know if that is supported with :ink or some other method?

Try wrapping the drawing operations into a WITH-DRAWING-OPTIONS form.


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log
_______________________________________________
mcclim-devel mailing list
mcclim-devel at common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From amoroso at mclink.it  Tue Feb  7 14:39:48 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 07 Feb 2006 15:39:48 +0100
Subject: SV: SV: [mcclim-devel] Problems getting
	"format-graph-from-roots"towork...
In-Reply-To: <200602071417.k17EHvbY015768@mailhub1.mclink.it> (Peter
	Braroe's message of "Tue, 7 Feb 2006 15:17:43 +0100")
References: <200602071417.k17EHvbY015768@mailhub1.mclink.it>
Message-ID: <871wyfnsgb.fsf@plato.moon.paoloamoroso.it>

"Peter Braroe" <peter.braroe at newsmachine.com> writes:

> Tried it but didnt seem to work... :-( I will mail you a screenshot direct
[...]
> "Peter Braroe" <peter.braroe at newsmachine.com> writes:
>
>> Now all I need to do is to figure out how to get it to draw in color...
> does
>> anyone know if that is supported with :ink or some other method?
>
> Try wrapping the drawing operations into a WITH-DRAWING-OPTIONS form.

I have received your screen shot.  If you want colored arcs, you may
use the :ARC-DRAWING-OPTIONS of FORMAT-GRAPH-FROM-ROOTS.  If you are
instead interested in colored nodes, try something like this for
:OBJECT-PRINTER (untested):

  #'(lambda (x s)
      (with-drawing-options (*test-frame* :ink +red+)
        (princ (car x) s)))


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From peter.braroe at newsmachine.com  Tue Feb  7 14:37:29 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Tue, 7 Feb 2006 15:37:29 +0100
Subject: SV: [mcclim-devel] Problems getting "format-graph-from-roots" to
	work...
In-Reply-To: <17384.43843.829971.171459@necronomicon.sift.info>
Message-ID: <20060207143247.6B5B640012@common-lisp.net>

Hello again!

FIX
>It's a pretty easy fix of just turning a single root
>into a list and then calling format-graph-from-roots,

What is the most elegant lispe method for this? Could one make it a macro?
Examples? Or would it be better to fix it in the CLIM as a patch?

ERROR!
Well it sure would help a novice like me with an error! Saves a lot of head
scratching... 

EXAMPLES
It's hard to know what is OK to do and what is not OK. Since I am planning
to do a lot of tree graphs I expect I will find out what is doable and what
is not... When I am done exploring I could make a new tree-test.cl and
perhaps it could go into /Examples? Who would I send that too?

Things I would like to do are:
 - Color coded trees
 - Scaling (resize of window event re-scales trees)
 - Hardcopy (to postscript)

And more...

FUN
I am pretty new to both LISP and CLIM but am having a lot of fun with it
despite the odd frustration here and there. I am using it for some NLP
research what is everyone else doing out there with clim?

Thanks, 

/Peter

	


---------------------------------------------------------------------------
Peter A. Braroe                    
VD, NewsMachine     
Blekingegatan 44
S-116 62 Stockholm
Office: +46-(0)8-442 03 31     
Mobile: +46-(0)708-750 991

-----Ursprungligt meddelande-----
Fr?n: rpgoldman at real-time.com [mailto:rpgoldman at real-time.com] 
Skickat: den 7 februari 2006 15:14
Till: peter.braroe at newsmachine.com
Kopia: mcclim developers' list
?mne: [mcclim-devel] Problems getting "format-graph-from-roots" to work...

>>>>> "PB" == Peter Braroe <peter.braroe at newsmachine.com> writes:

    PB> Hello all! 
    PB> I have gotten slightly further in my ambition to make a clim program
to
    PB> draw tree diagrams. After looking at various examples I have put
    PB> together a little program that gives the error below. 

    PB> No matching method for the generic function
    PB> #<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}>,
    PB> when
    PB> called with arguments
    PB> (#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y
    PB> 0.0d0:0.0d0
    PB>    {59D5278D}>
    PB>  #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> NIL NIL).
    PB>    [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

The problem arises because DIGRAPH layout has not been implemented in
McCLIM.  Tree layout is all that has been done.  Until such a time as
this has been fixed, we should probably change format-graph-from-roots
to toss an error if it is called with an unsupported layout method.

I see from your example code that you're trying to draw a tree.  Give
tree as layout method and I believe you'll be ok.

[...snip...]


    PB> Also my clim package 0.9.1 does not seem to have
    PB> "format-graph-from-root" (singular) only the
"format-graph-from-roots"
    PB> is this because the one root only version is not implemented? Does
    PB> anyone know?

Hm.  I know that I reported this earlier.  I guess we never got around
to fixing it.  It's a pretty easy fix of just turning a single root
into a list and then calling format-graph-from-roots, IIRC.

R



From rpgoldman at real-time.com  Tue Feb  7 14:14:27 2006
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Tue, 7 Feb 2006 08:14:27 -0600
Subject: [mcclim-devel] Problems getting "format-graph-from-roots" to work...
In-Reply-To: <1139305812.5740.15.camel@localhost.localdomain>
References: <1139305812.5740.15.camel@localhost.localdomain>
Message-ID: <17384.43843.829971.171459@necronomicon.sift.info>

>>>>> "PB" == Peter Braroe <peter.braroe at newsmachine.com> writes:

    PB> Hello all! 
    PB> I have gotten slightly further in my ambition to make a clim program to
    PB> draw tree diagrams. After looking at various examples I have put
    PB> together a little program that gives the error below. 

    PB> No matching method for the generic function
    PB> #<STANDARD-GENERIC-FUNCTION CLIM:LAYOUT-GRAPH-NODES (1) {58CD5C11}>,
    PB> when
    PB> called with arguments
    PB> (#<CLIM-INTERNALS::DIGRAPH-GRAPH-OUTPUT-RECORD X 0.0d0:0.0d0 Y
    PB> 0.0d0:0.0d0
    PB>    {59D5278D}>
    PB>  #<CLIM:APPLICATION-PANE TREE-TEST::SCREEN {59BF5855}> NIL NIL).
    PB>    [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

The problem arises because DIGRAPH layout has not been implemented in
McCLIM.  Tree layout is all that has been done.  Until such a time as
this has been fixed, we should probably change format-graph-from-roots
to toss an error if it is called with an unsupported layout method.

I see from your example code that you're trying to draw a tree.  Give
tree as layout method and I believe you'll be ok.

[...snip...]


    PB> Also my clim package 0.9.1 does not seem to have
    PB> "format-graph-from-root" (singular) only the "format-graph-from-roots"
    PB> is this because the one root only version is not implemented? Does
    PB> anyone know?

Hm.  I know that I reported this earlier.  I guess we never got around
to fixing it.  It's a pretty easy fix of just turning a single root
into a list and then calling format-graph-from-roots, IIRC.

R


From rpgoldman at sift.info  Tue Feb  7 14:15:34 2006
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Tue, 7 Feb 2006 08:15:34 -0600
Subject: [mcclim-devel] Problems getting "format-graph-from-roots" to
	work...
In-Reply-To: <sqpslzeat0.fsf@cam.ac.uk>
References: <1139305812.5740.15.camel@localhost.localdomain>
	<sqpslzeat0.fsf@cam.ac.uk>
Message-ID: <17384.43910.910335.971793@necronomicon.sift.info>

>>>>> "CR" == Christophe Rhodes <csr21 at cam.ac.uk> writes:

    CR> Peter Braroe <peter.braroe at newsmachine.com> writes:
    >> I have gotten slightly further in my ambition to make a clim program to
    >> draw tree diagrams. After looking at various examples I have put
    >> together a little program that gives the error below. 

    CR> I believe that the more complicated graph layouts (:digraph, maybe
    CR> :dag?) are currently unimplemented.  Try passing :graph-type :tree
    CR> explicitly to FORMAT-GRAPH-FROM-ROOTS.

Nothing except tree is currently supported.

    >> Also my clim package 0.9.1 does not seem to have
    >> "format-graph-from-root" (singular) only the "format-graph-from-roots"
    >> is this because the one root only version is not implemented? Does
    >> anyone know?

    CR> The singular FORMAT-GRAPH-FROM-ROOT appears not to be in the Clim II
    CR> specification.

Since it's so trivial, any reason not to support it, if only for
backward compatibility?

R


From rpgoldman at sift.info  Tue Feb  7 15:43:30 2006
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Tue, 7 Feb 2006 09:43:30 -0600
Subject: SV: [mcclim-devel] Problems getting "format-graph-from-roots" to
	work...
In-Reply-To: <200602071437.k17EbavX023935@enchanter.real-time.com>
References: <17384.43843.829971.171459@necronomicon.sift.info>
	<200602071437.k17EbavX023935@enchanter.real-time.com>
Message-ID: <17384.49186.398929.479070@necronomicon.sift.info>

>>>>> "PB" == Peter Braroe <peter.braroe at newsmachine.com> writes:

    PB> Hello again!
    PB> FIX
    >> It's a pretty easy fix of just turning a single root
    >> into a list and then calling format-graph-from-roots,

    PB> What is the most elegant lispe method for this? Could one make it a macro?
    PB> Examples? Or would it be better to fix it in the CLIM as a patch?

    PB> ERROR!
    PB> Well it sure would help a novice like me with an error! Saves a lot of head
    PB> scratching... 

I believe that the following would do the job:

(defun format-graph-from-root (root-object &rest other-args)
  (apply #'format-graph-from-roots (list root-object) other-args))

...but I confess to not having tested it.  I don't have a test case
handy.  Give it a whirl (note that you'll have to do this in some
package where format-graph-from-roots is visible, or modify the above
to clim:format-graph-from-roots.

If it works properly and I haven't committed some horrible solecism (I
didn't look at the standard for the proper definition of
format-graph-from-root), then perhaps we could put it into McCLIM.

Hope that is helpful,
Robert


From strandh at labri.fr  Tue Feb  7 18:29:34 2006
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 7 Feb 2006 19:29:34 +0100
Subject: SV: [mcclim-devel] Problems getting "format-graph-from-roots" to
	work...
In-Reply-To: <20060207143247.6B5B640012@common-lisp.net>
References: <17384.43843.829971.171459@necronomicon.sift.info>
	<20060207143247.6B5B640012@common-lisp.net>
Message-ID: <17384.59150.11623.282109@serveur5.labri.fr>

Peter Braroe writes:
 > what is everyone else doing out there with clim?

My main project at the moment (and also the reason I started writing
McCLIM) is Gsharp, an interactive editor for music scores. 

There is also a long-term project to create an IDE for Lisp.
The best approximation so far is the CLIM Desktop, containing Climacs
(editor), Closure (browser), Clouseau (inspector), Beirc (IRC client),
the CLIM Listener, a CLIM-based rudimentary debugger pane, etc. 

I have also written some minor applications like a GF front browser, a
calendar program, and more.

-- 
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.
---------------------------------------------------------------------


From csr21 at cam.ac.uk  Wed Feb  8 17:03:34 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 08 Feb 2006 17:03:34 +0000
Subject: [mcclim-devel] incremental redisplay slowness and local patches
Message-ID: <sqwtg5ye8p.fsf@cam.ac.uk>

Hi,

As some of you know, the tablature application suffers from scaling
problems in incremental redisplay because of the precision of the
algorithm.  While the spatial-trees stuff might solve this in the end,
at the moment we are working around it by a conservative
incremental-redisplay.

In the interest of minimizing divergence from CVS McCLIM, we would
like to have that incremental-redisplay as a different method,
specialized on an application class.  However, our first try (define a
new output record type) was a failure, as incremental-redisplay itself
is actually called on a stream, not on an output record; we could
specialize redisplay, but then we would have to duplicate a whole load
of stuff.

We do know that the stream we want to call our own method for
incremental-redisplay on is one obtained by OPEN-WINDOW-STREAM, and we
control the place where this is called.  Our current code, then, is
  (change-class (open-window-stream ...) 'tabcode-window-stream)
with
  (defclass tabcode-window-stream (climi::window-stream) ())

This, however, uses a scary clim-internals internal symbol.  That's
fine up to a point, but it would be better from our point of view if
there were a way of doing this in a documented way; is there a
spec-blessed way of having a custom incremental-redisplay method
called?  Alternatively, can climi::window-stream be documented and
exported?  Any other ideas?

Cheers,

Christophe


From pw at snoopy.mv.com  Wed Feb  8 17:57:17 2006
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Wed, 8 Feb 2006 12:57:17 -0500
Subject: [mcclim-devel] incremental redisplay slowness and local patches
Message-ID: <20060208175718.27937.qmail@copper.mv.net>

> 
> This, however, uses a scary clim-internals internal symbol.  That's
> fine up to a point, but it would be better from our point of view if
> there were a way of doing this in a documented way; is there a
> spec-blessed way of having a custom incremental-redisplay method
> called?  Alternatively, can climi::window-stream be documented and
> exported?  Any other ideas?

I have not tried this myself, but there is the
:record-type keyword to updating-output where you
can supply your own class of output-record. Then
redisplay-output-record on what that returns should
do what you want. No?

Paul



From clemens at endorphin.org  Thu Feb  9 13:25:35 2006
From: clemens at endorphin.org (Clemens Fruhwirth)
Date: Thu, 09 Feb 2006 14:25:35 +0100
Subject: [mcclim-devel] Re: Guided Tour of CLIM 
In-Reply-To: <m2slraqzb5.fsf@deadspam.com> 
References: <20060125230444.89F163CBC9@irulan.endorphin.org>
	<m2slraqzb5.fsf@deadspam.com>
Message-ID: <20060209133234.EDEF43CB97@irulan.endorphin.org>

Lu?s Oliveira <luismbo at gmail.com> wrote:

>   - I'd suggest restructuring the code in way that doesn't generate
>     warnings about undefined functions. Eg: I was confused about why my
>     McCLIM didn't seem to have this update-draw-pane function used in
>     the draw-frame commands.

The draw-frame example had a missing closing parenthesis. Please retry
with the examples checked in CVS. (Doc/Guided-Tour)

>   - The draw-frame example doesn't work for me (SBCL 0.9.8 and McCLIM
>     HEAD, CLX backend). I get an error saying:
>       "The function (SETF RECTANGLE-EDGES*) is undefined."
>     Hmm, and I get this same error with the file-browser example.

I don't use that function directly. Can you paste a backtrace?

>   - Is the source code for the examples available somewhere? That'd be
>     useful.

Sure, in the CVS!

Thank you for your feedback.
-- 
Fruhwirth Clemens - http://clemens.endorphin.org 
for robots: sp4mtrap at endorphin.org


From raymond.toy at ericsson.com  Thu Feb  9 18:33:27 2006
From: raymond.toy at ericsson.com (Raymond Toy)
Date: Thu, 09 Feb 2006 13:33:27 -0500
Subject: [mcclim-devel] Class precedence error with sheet.lisp and cmucl
Message-ID: <sxdbqxgl6vc.fsf@rtp.ericsson.se>


While compiling mcclim from a cvs checkout of 2006-02-08 using the
latest cmucl snapshot, I get an error when compiling
Backend/Postscript/sheet.lisp.  The error message is

Error in function PCL::CPL-ERROR:
   While computing the class precedence list of the class named
   POSTSCRIPT-STREAM: The class named
   CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN is a forward referenced class.
   The class named CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN is a direct
   superclass of the class named POSTSCRIPT-STREAM..
   [Condition of type SIMPLE-ERROR]

I guess this might be a bug in cmucl's PCL.

Ray



From csr21 at cam.ac.uk  Thu Feb  9 12:26:13 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Thu, 09 Feb 2006 12:26:13 +0000
Subject: [mcclim-devel] incremental redisplay slowness and local patches
In-Reply-To: <20060208175718.27937.qmail@copper.mv.net> (Paul Werkowski's
	message of "Wed, 8 Feb 2006 12:57:17 -0500")
References: <20060208175718.27937.qmail@copper.mv.net>
Message-ID: <sqd5hwk9ay.fsf@cam.ac.uk>

pw at snoopy.mv.com (Paul Werkowski) writes:

>> 
>> This, however, uses a scary clim-internals internal symbol.  That's
>> fine up to a point, but it would be better from our point of view if
>> there were a way of doing this in a documented way; is there a
>> spec-blessed way of having a custom incremental-redisplay method
>> called?  Alternatively, can climi::window-stream be documented and
>> exported?  Any other ideas?
>
> I have not tried this myself, but there is the
> :record-type keyword to updating-output where you
> can supply your own class of output-record. Then
> redisplay-output-record on what that returns should
> do what you want. No?

Sadly not, I think.  (This was basically our first try).

The problem with this solution is that it's not the redisplay part
that is the time sink in our application, it is computing the region
to replay overlapping records in.  In DEFMETHOD INCREMENTAL-REDISPLAY,
the relevant snippet is
   (let ((res +nowhere+))
     (loop for (r) in erase-overlapping do (setf res (region-union res r)))
     (loop for (r) in move-overlapping do (setf res (region-union res r)))
     (replay history stream res))
which computes the precise region to replay the history over.

Unfortunately, this precise region computation is extremely expensive
in our case, which typically has many many disjoint moved and erased
records.  Our modification is to do
  (setf res (bounding-rectangle (region-union res r)))
which scales linearly with the number of records in erase-overlapping
and move-overlapping, rather than some ghastly factor as in the
default code (and similarly is linear in the replay, rather than again
some ghastly factor when computing whether a record intersects this
highly-complex region); however, this means we need to specialize
INCREMENTAL-REDISPLAY itself, which does not have an output-record
argument.

Cheers,

Christophe


From moore at bricoworks.com  Thu Feb  9 22:22:46 2006
From: moore at bricoworks.com (Timothy Moore)
Date: Thu, 9 Feb 2006 23:22:46 +0100
Subject: [mcclim-devel] Re: Guided Tour of CLIM 
In-Reply-To: <20060209133234.EDEF43CB97@irulan.endorphin.org>
References: <20060125230444.89F163CBC9@irulan.endorphin.org>
	<m2slraqzb5.fsf@deadspam.com>
	<20060209133234.EDEF43CB97@irulan.endorphin.org>
Message-ID: <ea923b9b60d72941e23ec3c4bc566473@bricoworks.com>


On Feb 9, 2006, at 2:25 PM, Clemens Fruhwirth wrote:

> Lu?s Oliveira <luismbo at gmail.com> wrote:
>
>>   - The draw-frame example doesn't work for me (SBCL 0.9.8 and McCLIM
>>     HEAD, CLX backend). I get an error saying:
>>       "The function (SETF RECTANGLE-EDGES*) is undefined."
>>     Hmm, and I get this same error with the file-browser example.
>
> I don't use that function directly. Can you paste a backtrace?
>
This is caused by a recent check in of mine. Be sure you recompile all 
your CLIM files, both in McCLIM and your own stuff.

Tim



From johnc at yagc.ndo.co.uk  Tue Feb 14 09:58:10 2006
From: johnc at yagc.ndo.co.uk (John Connors)
Date: Tue, 14 Feb 2006 09:58:10 +0000
Subject: [mcclim-devel] Threading and Waiting
Message-ID: <43F1A9B2.4080301@yagc.ndo.co.uk>

While looking for the 'right' way to get a SCBL thread to wait for a specified 
condition as part of an attempt to update port from the CLOCC, I came across 
this gem in the McCLIM sources.

(declaim (inline yield))
(defun yield ()
   (declare (optimize speed (safety 0)))
   (sb-alien:alien-funcall
    (sb-alien:extern-alien "sched_yield" (function sb-alien:int)))
   (values))

(defun process-wait (reason predicate)
   (let ((old-state (process-whostate *current-process*)))
     (unwind-protect
	 (progn
	   (setf old-state (process-whostate *current-process*)
		 (process-whostate *current-process*) reason)
	   (loop
	    (let ((it (funcall predicate)))
	      (when it (return it)))
	    ;(sleep .01)
                (yield)))
       (setf (process-whostate *current-process*) old-state))))

Now this will work, but my understanding is when calling sched_yeild, a thread 
gets completely expired and put at the back of the scheduling queue. What was/is 
wrong with sleep?




From dan at telent.net  Tue Feb 14 11:22:33 2006
From: dan at telent.net (Daniel Barlow)
Date: Tue, 14 Feb 2006 11:22:33 +0000
Subject: [mcclim-devel] Threading and Waiting
In-Reply-To: <43F1A9B2.4080301@yagc.ndo.co.uk>
References: <43F1A9B2.4080301@yagc.ndo.co.uk>
Message-ID: <20060214112233.GA32465@eval.metacircles.com>

On Tue, Feb 14, 2006 at 09:58:10AM +0000, John Connors wrote:
> While looking for the 'right' way to get a SCBL thread to wait for a 
> specified condition as part of an attempt to update port from the CLOCC, I 
> came across this gem in the McCLIM sources.

Really, there _is_ no 'right' way.  Threads in SBCL (as with threads
in OpenMCL and any other implementation using "native" threads) are
scheduled by the operating system, and the operating system, as a
rule, can't evaluate arbitrary bits of Lisp to decide if a thread is
runnable or not.  So it has to run it to find out if it wants to run
or not, which is not what I or anyone would really consider an
efficient use of resources.

Most of the uses of process-wait in the wild are for implementing
higher-level synchronisation constructs like
mutexes/semaphores/queues, and most of the Lisps with OS-scheduled
threads already have efficient implementations of these that play
nicely with the kernel scheduler (or at least have the potential to,
which a Lisp-based solution will never have[*]).  It would make far
more sense to encourage people to use the higher-level constructs
than provide them with a hacky workaround to shore up shonky code.
See e.g. http://www.cliki.net/BORDEAUX-MP for one possible "standard"
interface that includes mutexes and posix-style condition variables

> Now this will work, but my understanding is when calling sched_yeild, a 
> thread gets completely expired and put at the back of the scheduling queue. 

The semantics of sched_yield have changed (possibly even more than
once) from one Linux version to the next, and I can't even remember
what it's suppsoed to do these days.  I rather suspect that in the
grand scheme of things it doesn't matter too much, as this approach is
never going to be particularly efficient whatever you do.


-dan


From athas at sigkill.dk  Tue Feb 14 13:01:51 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Tue, 14 Feb 2006 14:01:51 +0100
Subject: [mcclim-devel] Writing single-line strings to clim-stream-panes
Message-ID: <87wtfy5c1s.fsf@sigkill.dk>

Assume an instance of a standard clim-stream-pane with a width and
height of 0 respectively (though the issue concerns panes of all
sizes). If one prints a string *with* linebreaks to this pane, it will
properly resize itself to accommodate the text. If the string does
*not* include linebreaks, however, the pane will not be resized (and
thus, not be visible by the user). I consider this a bug.

A possible solution, and the one I have followed due to my lack of
insight into McCLIM internals, is to modify `seos-write-string' in
stream-output.lisp to call `change-space-requirements' on the pane
with a :min-height parameter of the height of the string being
printed. This does ensure that the pane is never too small to
accommodate the string, but it is certainly an ugly hack.

Does anyone else have a better solution?
-- 
\  Troels "Athas" Henriksen
/\ sigkill.dk/blog (Danish)


From peter.braroe at newsmachine.com  Wed Feb 15 13:14:01 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Wed, 15 Feb 2006 14:14:01 +0100
Subject: [mcclim-devel] How to get Swedish characters/Latin-1 to work! +
	best way to do pop-up menu?
In-Reply-To: <87wtfy5c1s.fsf@sigkill.dk>
Message-ID: <20060215171319.69EB74200C@common-lisp.net>

Hello again!

I got my tree diagrams to work with color and all, and I am going to make a
example file for others, where should i post it?

I now need to get Swedish characters like ??? ??? to work i.e. latin-1
support, when I google it seems that this should work but when I type a
Swedish character it does not register - is there something special that I
should do? I am using latest CMUCL under Linux... 

Also what is the best way to do a pop-up menu window? 

In the simplest case I want to make a about dialog. In the other case I want
to accept some data, preferably from a number of drop-down menus. I also
want to make some dialogs to set preferences... any elegant examples of this
to look at somewhere? 

Thanks as always for any help!

/Peter




From athas at sigkill.dk  Wed Feb 15 18:13:05 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Wed, 15 Feb 2006 19:13:05 +0100
Subject: [mcclim-devel] How to get Swedish characters/Latin-1 to work! +
	best way to do pop-up menu?
In-Reply-To: <20060215171319.69EB74200C@common-lisp.net> (Peter Braroe's
	message of "Wed, 15 Feb 2006 14:14:01 +0100")
References: <20060215171319.69EB74200C@common-lisp.net>
Message-ID: <87k6bwfq32.fsf@sigkill.dk>

"Peter Braroe" <peter.braroe at newsmachine.com> writes:

> I now need to get Swedish characters like ??? ??? to work i.e. latin-1
> support, when I google it seems that this should work but when I type a
> Swedish character it does not register - is there something special that I
> should do? I am using latest CMUCL under Linux... 

Look at the bottom tip on http://mcclim.cliki.net/Tip

You are required to manually find the keysym for the characters you want to
support, though.

-- 
\  Troels "Athas" Henriksen
/\ sigkill.dk/blog (Danish)


From athas at sigkill.dk  Thu Feb 16 14:12:53 2006
From: athas at sigkill.dk (Troels Henriksen)
Date: Thu, 16 Feb 2006 15:12:53 +0100
Subject: [mcclim-devel] Writing single-line strings to clim-stream-panes
In-Reply-To: <87wtfy5c1s.fsf@sigkill.dk> (Troels Henriksen's message of
	"Tue, 14 Feb 2006 14:01:51 +0100")
References: <87wtfy5c1s.fsf@sigkill.dk>
Message-ID: <87zmkrtmsa.fsf@sigkill.dk>

Troels Henriksen <athas at sigkill.dk> writes:

> Does anyone else have a better solution?

Attached to this post is a patch to stream-output.lisp that fixes the
issue and doesn't cause horrible breakage (AFAICS).
-- 
\  Troels "Athas" Henriksen
/\ sigkill.dk/blog (Danish)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stream-output.lisp.patch
Type: text/x-patch
Size: 1840 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060216/9dd6e775/attachment.bin>

From ahefner at gmail.com  Thu Feb 16 16:40:38 2006
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 16 Feb 2006 11:40:38 -0500
Subject: [mcclim-devel] Writing single-line strings to clim-stream-panes
In-Reply-To: <87zmkrtmsa.fsf@sigkill.dk>
References: <87wtfy5c1s.fsf@sigkill.dk> <87zmkrtmsa.fsf@sigkill.dk>
Message-ID: <31ffd3c40602160840i129d605dlbeb90fa3ce6dda3@mail.gmail.com>

This looks like the right thing.

Have you tried any benchmarks of the impact on text output speed (for,
say, writing 10,000 lines of text to the pane)? I've feared that
reinvoking the layout algorithm (and resizing the CLX mirror, etc) for
each line of output would wreck the already unsatisfactory performance
in this case.

In many cases (commands or display functions printing substantial
output) it would be advantageous to let the output be generated in a
batch, and resize the sheet pane once when it completes. This is a
different pattern of usage than the lone application-pane which is
only written to occasionally, but certainly the programmer should not
have to fuss with manually resizing the pane in the latter case.

OTOH, this seems like exactly what changing-space-requirements is for.
So long as the appropriate places (execution of command bodies, pane
redisplay) in McCLIM are surrounded by this form, performance should
not be impacted.

There is an alternate approach whereby growth of the bounding
rectangle of a sheet output history would trigger an automatic resize
of the sheet. This is clean and appealing, and would work for all
manner of output besides text, but I've come to think that for some
applications (graphics..) the ability to clip output within the sheet
region is a feature rather than a bug.

On 2/16/06, Troels Henriksen <athas at sigkill.dk> wrote:
> Troels Henriksen <athas at sigkill.dk> writes:
>
> > Does anyone else have a better solution?
>
> Attached to this post is a patch to stream-output.lisp that fixes the
> issue and doesn't cause horrible breakage (AFAICS).
> --
> \  Troels "Athas" Henriksen
> /\ sigkill.dk/blog (Danish)
>
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>
>
>
>


From peter.braroe at newsmachine.com  Fri Feb 17 18:39:50 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Fri, 17 Feb 2006 19:39:50 +0100
Subject: [mcclim-devel] How to get Swedish characters/Latin-1 to work!
	+ best way to do pop-up menu?
In-Reply-To: <87k6bwfq32.fsf@sigkill.dk>
References: <20060215171319.69EB74200C@common-lisp.net>
	<87k6bwfq32.fsf@sigkill.dk>
Message-ID: <1140201590.2244.16.camel@localhost.localdomain>

Hello!

Well I tried the tip, but on my first attempt it bugged out... and then
i saw that a ' had snuck in and - sucsess! 

Please find the file i used enclosed!

What I trying to figgure the best way for now is:

 - How to i most elegantly pop-up a window? 
(for instance "Are you sure you would like to quit? Save first?)

 - How to make items in a formated list clickable through translations
 
and other things... 

Happy weekend to you all!

/Peter 


On Wed, 2006-02-15 at 19:13 +0100, Troels Henriksen wrote:
> "Peter Braroe" <peter.braroe at newsmachine.com> writes:
> 
> > I now need to get Swedish characters like ??? ??? to work i.e. latin-1
> > support, when I google it seems that this should work but when I type a
> > Swedish character it does not register - is there something special that I
> > should do? I am using latest CMUCL under Linux... 
> 
> Look at the bottom tip on http://mcclim.cliki.net/Tip
> 
> You are required to manually find the keysym for the characters you want to
> support, though.
> 
-------------- next part --------------
;;; Non-ASCII input
;;;
;;; Out-of-the-box, McCLIM only supports ASCII input. If you use the CLX backend (most likely the
;;; default for your platform), you can use the following trick to enable more characters.
;;;
;;; You must redefine the clim-clx::translate function:

(in-package :clim-clx)


(defun translate (src src-start src-end afont dst dst-start)
  (let ((min-char-index (xlib:font-min-char afont))
	(max-char-index (xlib:font-max-char afont)))
    (if (stringp src)
	(loop for i from src-start below src-end
	      for j from dst-start
	      for index = (char-code (aref src i))
	      while (<= min-char-index index max-char-index)
	      do (setf (aref dst j) index)
	      finally (return i))
      (loop for i from src-start below src-end
	    for j from dst-start
	    for index = (if (characterp (aref src i))
			    (char-code (aref src i)) (aref src i))
	    while (<= min-char-index index max-char-index)
	    do (setf (aref dst j) index)
	    finally (return i)))))

;;
;; Without this function, the CLX backend is incapable of handling Unicode characters.
;;

;;
;; Use this function to add the characters you need:
;;

(defun fix-character (character keysym)
  "Setup character to work in CLX and McCLIM."
  (xlib::define-keysym character keysym)
  (goatee::add-gesture-command-to-table character 'goatee::insert-character
                                       goatee::*simple-area-gesture-table*))


(defun fix-swedish-input ()
  "Adds Swedish special characters."
  (fix-character #\? 229)
  (fix-character #\? 197)
  (fix-character #\? 228)
  (fix-character #\? 196)
  (fix-character #\? 246)
  (fix-character #\? 214))

  
;;
;; For example:
;;

(defun fix-danish-input ()
  "Adds Danish special characters."
  (fix-character #\? 230)
  (fix-character #\? 198)
  (fix-character #\? 248)
  (fix-character #\? 216)
  (fix-character #\? 229)
  (fix-character #\? 197))

;; Or:

(defun fix-german-input ()
  "Adds German special characters."
  (fix-character #\? 228)
  (fix-character #\? 246)
  (fix-character #\? 252)
  (fix-character #\? 196)
  (fix-character #\? 214)
  (fix-character #\? 220)
  (fix-character #\? 223))

;; You should now have non-ASCII input. In editor-panes, at least.



From amoroso at mclink.it  Fri Feb 17 19:21:15 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 17 Feb 2006 20:21:15 +0100
Subject: [mcclim-devel] How to get Swedish characters/Latin-1 to work! +
	best way to do pop-up menu?
In-Reply-To: <1140201590.2244.16.camel@localhost.localdomain> (Peter
	Braroe's message of "Fri, 17 Feb 2006 19:39:50 +0100")
References: <20060215171319.69EB74200C@common-lisp.net>
	<87k6bwfq32.fsf@sigkill.dk>
	<1140201590.2244.16.camel@localhost.localdomain>
Message-ID: <871wy1eqqc.fsf@plato.moon.paoloamoroso.it>

Peter Braroe <peter.braroe at newsmachine.com> writes:

>  - How to i most elegantly pop-up a window? 
> (for instance "Are you sure you would like to quit? Save first?)

The CLIM function NOTIFY-USER is supposed to do that, but McCLIM does
not implement it yet.  As a workaround you may use ACCEPTING-VALUES:
McCLIM implements enough of its functionality that it should be
possible to do what you want.


>  - How to make items in a formated list clickable through translations

The idiomatic CLIM way to do that, I think, is via presentation to
command translators.


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From amoroso at mclink.it  Sat Feb 18 16:51:01 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 18 Feb 2006 17:51:01 +0100
Subject: [mcclim-devel] mcclim.org domain: still active?
Message-ID: <871wy0wqyy.fsf@plato.moon.paoloamoroso.it>

If I try to connect to:

  http://www.mcclim.org

I get a server not found error.  Is the mcclim.org domain still
active?


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From amoroso at mclink.it  Sat Feb 18 17:08:17 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 18 Feb 2006 18:08:17 +0100
Subject: [mcclim-devel] Error while compiling PostScript backend
Message-ID: <87wtfsvblq.fsf@plato.moon.paoloamoroso.it>

I have tried building from scratch the latest McCLIM CVS sources with
CMUCL Snapshot 2005-11 (19C) under Linux, and compilation stops with
the error:

[...]
; /home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f written.
; Compilation finished in 0:00:00.
; Loading #P"/home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f".
; Loading #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f".

Execution of a form compiled with errors:
 (DEFMETHOD SHEET-DIRECT-MIRROR ((SHEET POSTSCRIPT-STREAM))
   (POSTSCRIPT-STREAM-FILE-STREAM SHEET))
   [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]

Restarts:
  0: [CONTINUE] Return NIL from load of #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f".
  1: [RETRY   ] Retry performing #<ASDF:LOAD-OP NIL {5837C315}> on
                #<ASDF:CL-SOURCE-FILE "sheet" {5837C145}>.
  2: [ACCEPT  ] Continue, treating #<ASDF:LOAD-OP NIL {5837C315}> on
                #<ASDF:CL-SOURCE-FILE "sheet" {5837C145}> as
                having been successful.
  3: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

(C::DO-CALL #<Code Object "Top-Level Form" {580C4017}> 78 79 4 ...)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:code/byte-interp.lisp.
0]


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From csr21 at cam.ac.uk  Sat Feb 18 23:55:04 2006
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sat, 18 Feb 2006 23:55:04 +0000
Subject: [mcclim-devel] Error while compiling PostScript backend
In-Reply-To: <87wtfsvblq.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's
	message of "Sat, 18 Feb 2006 18:08:17 +0100")
References: <87wtfsvblq.fsf@plato.moon.paoloamoroso.it>
Message-ID: <sqmzgousrr.fsf@cam.ac.uk>

Paolo Amoroso <amoroso at mclink.it> writes:

> I have tried building from scratch the latest McCLIM CVS sources with
> CMUCL Snapshot 2005-11 (19C) under Linux, and compilation stops with
> the error:
>
> [...]
> ; /home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f written.
> ; Compilation finished in 0:00:00.
> ; Loading #P"/home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f".
> ; Loading #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f".

If that's verbatim, then you're loading an old fasl, surely?

> Execution of a form compiled with errors:
>  (DEFMETHOD SHEET-DIRECT-MIRROR ((SHEET POSTSCRIPT-STREAM))
>    (POSTSCRIPT-STREAM-FILE-STREAM SHEET))
>    [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
>
> Restarts:
>   0: [CONTINUE] Return NIL from load of #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f".
>   1: [RETRY   ] Retry performing #<ASDF:LOAD-OP NIL {5837C315}> on
>                 #<ASDF:CL-SOURCE-FILE "sheet" {5837C145}>.
>   2: [ACCEPT  ] Continue, treating #<ASDF:LOAD-OP NIL {5837C315}> on
>                 #<ASDF:CL-SOURCE-FILE "sheet" {5837C145}> as
>                 having been successful.
>   3: [ABORT   ] Return to Top-Level.

What was the original error?

Christophe


From amoroso at mclink.it  Sun Feb 19 16:59:30 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sun, 19 Feb 2006 17:59:30 +0100
Subject: [mcclim-devel] Error while compiling PostScript backend
References: <87wtfsvblq.fsf@plato.moon.paoloamoroso.it>
	<sqmzgousrr.fsf@cam.ac.uk>
Message-ID: <87mzgne13h.fsf@plato.moon.paoloamoroso.it>

Christophe Rhodes <csr21 at cam.ac.uk> writes:

> Paolo Amoroso <amoroso at mclink.it> writes:
>
>> I have tried building from scratch the latest McCLIM CVS sources with
>> CMUCL Snapshot 2005-11 (19C) under Linux, and compilation stops with
>> the error:
>>
>> [...]
>> ; /home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f written.
>> ; Compilation finished in 0:00:00.
>> ; Loading #P"/home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f".
>> ; Loading #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f".
>
> If that's verbatim, then you're loading an old fasl, surely?

I have tried rebuilding McCLIM from scratch with a freshly checked out
copy of the CVS repository.


> What was the original error?

Here are the errors I get:

; loading system definition from /home/paolo/src/dev/mcclim/mcclim.asd into
; #<The ASDF1947 package>
; Loading #P"/home/paolo/src/dev/mcclim/mcclim.asd".
[...]
; Python version 1.1, VM version Intel x86 on 19 FEB 06 05:42:56 pm.
; Compiling: /home/paolo/src/dev/mcclim/Backends/PostScript/sheet.lisp 30 DEC 05 07:02:39 pm
[...]
; Error: (during macroexpansion)
; 
; Error in function PCL::CPL-ERROR:
;    While computing the class precedence list of the class named
;    POSTSCRIPT-STREAM: The class named ..
; 
; Compiling DEFMETHOD SHEET-MIRRORED-ANCESTOR (POSTSCRIPT-STREAM): 
; Compiling DEFMETHOD SHEET-MIRROR (POSTSCRIPT-STREAM): 
; Compiling DEFMETHOD REALIZE-MIRROR (POSTSCRIPT-PORT POSTSCRIPT-STREAM): 
; Byte Compiling Top-Level Form: 
; Compiling DEFMETHOD DESTROY-MIRROR (POSTSCRIPT-PORT POSTSCRIPT-STREAM): 
; 

; Error: (during macroexpansion)
; 
; Error in function PCL::CPL-ERROR:
;    While computing the class precedence list of the class named
;    POSTSCRIPT-STREAM: The class named ..
; ; 

; Error: (during macroexpansion)
; 
; Error in function PCL::CPL-ERROR:
;    While computing the class precedence list of the class named
;    POSTSCRIPT-STREAM: The class named ..
[...]

These errors rang a bell.  I have already seen similar ones here:

  Class precedence error with sheet.lisp and cmucl
  http://article.gmane.org/gmane.lisp.mcclim.devel/896

Never mind.


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From peter.braroe at newsmachine.com  Mon Feb 20 16:38:37 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Mon, 20 Feb 2006 17:38:37 +0100
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog!
Message-ID: <1140453517.2229.31.camel@localhost.localdomain>

Hello all!

As I have understood, it seems that :own-window t for accepting-values
or NOTIFY-USER is not available yet in McCLIM. I really have my heart
set on using a pop-up windows to manage prefs etc. but it seems
non-trivial... 

What I want to do is:

1  Create a child window
2A Populate with text-fields, checkboxes, and buttons (like gadet-test)
2B Add "Save" button and method that returns/stores the values selected 
3  Move focus to child, put original window in background
4  Destroy child window, refocus on original window

It certainly seems possible looking at the Clim spec, but when I google
it seems that I can't find much about it or examples. Sooo i am
wondering if there is a reason for this...

So if anyone has a nice example* of how to do this that would be a
dream, and if not the next best thing would be if someone had a clear
understanding of how it should be donwe. And if not some vauge ideas on
how to get started, and where to look would be excellent!

Thanks all!


/Peter

(*Even just a "About" pop-up example would be loveley!)



From amoroso at mclink.it  Mon Feb 20 17:06:14 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 20 Feb 2006 18:06:14 +0100
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog!
References: <1140453517.2229.31.camel@localhost.localdomain>
Message-ID: <87bqx2klix.fsf@plato.moon.paoloamoroso.it>

Peter Braroe <peter.braroe at newsmachine.com> writes:

> As I have understood, it seems that :own-window t for accepting-values
> or NOTIFY-USER is not available yet in McCLIM. I really have my heart

As far as I know, McCLIM does support :own-window t for
accepting-values.


> What I want to do is:
>
> 1  Create a child window
> 2A Populate with text-fields, checkboxes, and buttons (like gadet-test)
> 2B Add "Save" button and method that returns/stores the values selected 
> 3  Move focus to child, put original window in background
> 4  Destroy child window, refocus on original window
[...]
> So if anyone has a nice example* of how to do this that would be a

One way to do that is by creating a full application frame for your
dialog box with all the gadgets you need, and call it from your
application code.  It works nicely, but is rather verbose.  Some time
ago I posted an example here:

  Poor man's CLIM text style selection dialog
  http://common-lisp.net/pipermail/mcclim-devel/2005-July/004113.html


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From peter.braroe at newsmachine.com  Mon Feb 20 17:53:30 2006
From: peter.braroe at newsmachine.com (Peter Braroe)
Date: Mon, 20 Feb 2006 18:53:30 +0100
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog!
In-Reply-To: <87bqx2klix.fsf@plato.moon.paoloamoroso.it>
References: <1140453517.2229.31.camel@localhost.localdomain>
	<87bqx2klix.fsf@plato.moon.paoloamoroso.it>
Message-ID: <1140458010.13470.8.camel@localhost.localdomain>

Hey!

Thanks! And that was quick!

I tried it and it worke great, nice little thing, now i have something
to work from! 

Regarding the accepting-values and :own-window. I didn't get that to
work. Do I need to do something special to get a new window? The 0.9.1
spec said something about it beeing unimplemented so I didn't research
it too much.

Here it says:

"There is no gadget-based implementation of accepting-values. own-window
is not supported."
http://common-lisp.net/pipermail/mcclim-announce/2005-March/000000.html


But now that I know it works I will try a bit harder to get it to work!

Thanks again!!

/Peter



On Mon, 2006-02-20 at 18:06 +0100, Paolo Amoroso wrote:
> Peter Braroe <peter.braroe at newsmachine.com> writes:
> 
> > As I have understood, it seems that :own-window t for accepting-values
> > or NOTIFY-USER is not available yet in McCLIM. I really have my heart
> 
> As far as I know, McCLIM does support :own-window t for
> accepting-values.
> 
> 
> > What I want to do is:
> >
> > 1  Create a child window
> > 2A Populate with text-fields, checkboxes, and buttons (like gadet-test)
> > 2B Add "Save" button and method that returns/stores the values selected 
> > 3  Move focus to child, put original window in background
> > 4  Destroy child window, refocus on original window
> [...]
> > So if anyone has a nice example* of how to do this that would be a
> 
> One way to do that is by creating a full application frame for your
> dialog box with all the gadgets you need, and call it from your
> application code.  It works nicely, but is rather verbose.  Some time
> ago I posted an example here:
> 
>   Poor man's CLIM text style selection dialog
>   http://common-lisp.net/pipermail/mcclim-devel/2005-July/004113.html
> 
> 
> Paolo



From amoroso at mclink.it  Mon Feb 20 19:20:45 2006
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 20 Feb 2006 20:20:45 +0100
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog!
In-Reply-To: <1140458010.13470.8.camel@localhost.localdomain> (Peter
	Braroe's message of "Mon, 20 Feb 2006 18:53:30 +0100")
References: <1140453517.2229.31.camel@localhost.localdomain>
	<87bqx2klix.fsf@plato.moon.paoloamoroso.it>
	<1140458010.13470.8.camel@localhost.localdomain>
Message-ID: <87fymdbzw2.fsf@plato.moon.paoloamoroso.it>

Peter Braroe <peter.braroe at newsmachine.com> writes:

> Regarding the accepting-values and :own-window. I didn't get that to
> work. Do I need to do something special to get a new window? The 0.9.1
> spec said something about it beeing unimplemented so I didn't research
> it too much.

Version 0.9.1 is quite old and a lot of progress has been made on
McCLIM.  I suggest that you get the latest CVS sources, which is
currently the canonical way of using an up to date McCLIM.


Paolo
-- 
Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log


From asf at boinkor.net  Tue Feb 21 09:35:34 2006
From: asf at boinkor.net (Andreas Fuchs)
Date: Tue, 21 Feb 2006 10:35:34 +0100
Subject: [mcclim-devel] standard-tree-output-records using spatial-trees
In-Reply-To: <87wtg9iflm.wl%asf@boinkor.net>
References: <873bixkfdr.wl%asf@boinkor.net>
	<87wtg9iflm.wl%asf@boinkor.net>
Message-ID: <87y805jbq1.wl%asf@boinkor.net>

In the time I used this patch, a few things came up:

 * I made the map-over-* methods the default.
 * map-over-* didn't check if the child truly intersects the region /
   contains the point; this is enough only for ORs and regions that
   are equal to their bounding rectangle.

Here's the patch fixing both these issues:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,tree-output-records-3.patch
Type: application/octet-stream
Size: 8090 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060221/b293ba54/attachment.obj>
-------------- next part --------------

Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

From clemens at endorphin.org  Wed Feb 22 10:24:31 2006
From: clemens at endorphin.org (Clemens Fruhwirth)
Date: Wed, 22 Feb 2006 11:24:31 +0100
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog! 
In-Reply-To: <87fymdbzw2.fsf@plato.moon.paoloamoroso.it> 
References: <1140453517.2229.31.camel@localhost.localdomain>
	<87bqx2klix.fsf@plato.moon.paoloamoroso.it>
	<1140458010.13470.8.camel@localhost.localdomain>
	<87fymdbzw2.fsf@plato.moon.paoloamoroso.it>
Message-ID: <20060222103304.224B03C456@irulan.endorphin.org>

Paolo Amoroso <amoroso at mclink.it> wrote:

> Peter Braroe <peter.braroe at newsmachine.com> writes:
> 
> > Regarding the accepting-values and :own-window. I didn't get that to
> > work. Do I need to do something special to get a new window? The 0.9.1
> > spec said something about it beeing unimplemented so I didn't research
> > it too much.
> 
> Version 0.9.1 is quite old and a lot of progress has been made on
> McCLIM.  I suggest that you get the latest CVS sources, which is
> currently the canonical way of using an up to date McCLIM.

Are there any plans release plans? It doesn't look as if there are many
destabilizing merges are going on at the moment, so are there any
arguments to just release a CVS snapshot as 0.9.2? 

Of course, this violates some principals -- releases should receive a
minimal amount of testing and so on -- however, as we point to the users
to the CVS anyway, there is little to be lost.
-- 
Fruhwirth Clemens - http://clemens.endorphin.org 
for robots: sp4mtrap at endorphin.org



From strandh at labri.fr  Wed Feb 22 18:30:34 2006
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 22 Feb 2006 19:30:34 +0100
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog! 
In-Reply-To: <20060222103304.224B03C456@irulan.endorphin.org>
References: <1140453517.2229.31.camel@localhost.localdomain>
	<87bqx2klix.fsf@plato.moon.paoloamoroso.it>
	<1140458010.13470.8.camel@localhost.localdomain>
	<87fymdbzw2.fsf@plato.moon.paoloamoroso.it>
	<20060222103304.224B03C456@irulan.endorphin.org>
Message-ID: <17404.44490.680585.286875@serveur5.labri.fr>

Clemens Fruhwirth writes:
 > Are there any plans release plans? It doesn't look as if there are many
 > destabilizing merges are going on at the moment, so are there any
 > arguments to just release a CVS snapshot as 0.9.2? 

Andreas Fuchs did the previous release and he probably had some idea
as to what a release should be.  At least it would be appropriate to
ask him beforehand. 

-- 
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.
---------------------------------------------------------------------


From rpgoldman at real-time.com  Wed Feb 22 18:33:49 2006
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Wed, 22 Feb 2006 12:33:49 -0600
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog! 
In-Reply-To: <17404.44490.680585.286875@serveur5.labri.fr>
References: <1140453517.2229.31.camel@localhost.localdomain>
	<87bqx2klix.fsf@plato.moon.paoloamoroso.it>
	<1140458010.13470.8.camel@localhost.localdomain>
	<87fymdbzw2.fsf@plato.moon.paoloamoroso.it>
	<20060222103304.224B03C456@irulan.endorphin.org>
	<17404.44490.680585.286875@serveur5.labri.fr>
Message-ID: <17404.44685.712680.425690@necronomicon.sift.info>

>>>>> "RS" == Robert Strandh <strandh at labri.fr> writes:

    RS> Clemens Fruhwirth writes:
    >> Are there any plans release plans? It doesn't look as if there are many
    >> destabilizing merges are going on at the moment, so are there any
    >> arguments to just release a CVS snapshot as 0.9.2? 

    RS> Andreas Fuchs did the previous release and he probably had some idea
    RS> as to what a release should be.  At least it would be appropriate to
    RS> ask him beforehand. 

How does this relate to Paolo's recent notes to the effect that the
current CVS HEAD is broken for CMUCL?

Best,
R


From strandh at labri.fr  Wed Feb 22 20:15:01 2006
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 22 Feb 2006 21:15:01 +0100
Subject: [mcclim-devel] Spiffy code sought for elegant pop-up dialog! 
In-Reply-To: <17404.44685.712680.425690@necronomicon.sift.info>
References: <1140453517.2229.31.camel@localhost.localdomain>
	<87bqx2klix.fsf@plato.moon.paoloamoroso.it>
	<1140458010.13470.8.camel@localhost.localdomain>
	<87fymdbzw2.fsf@plato.moon.paoloamoroso.it>
	<20060222103304.224B03C456@irulan.endorphin.org>
	<17404.44490.680585.286875@serveur5.labri.fr>
	<17404.44685.712680.425690@necronomicon.sift.info>
Message-ID: <17404.50757.835471.836054@serveur5.labri.fr>

rpgoldman at real-time.com writes:
 > 
 > How does this relate to Paolo's recent notes to the effect that the
 > current CVS HEAD is broken for CMUCL?

I don't know, because I only follow this discussion superficially.  It
would certainly be good if the latest release did not have that
problem. 

-- 
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.
---------------------------------------------------------------------


From asf at boinkor.net  Sun Feb 26 11:34:26 2006
From: asf at boinkor.net (Andreas Fuchs)
Date: Sun, 26 Feb 2006 12:34:26 +0100
Subject: [mcclim-devel] [patch] make goatee search & execute frame commands
	by gesture
Message-ID: <87fym64am5.wl%asf@boinkor.net>

Hi all,

as it is now, goatee doesn't search for commands by keystroke gesture
in the application frame's command table. This means that any
command-invoking keystrokes that are entered when goatee is active
will be ignored. This seems to affect all applications that have an
interactor pane, like beirc.

So, here's a patch that makes goatee search for & execute the command
in the current application frame, if there is one.

I'm not sure if this is the right thing to do, but it allows us to use
keystroke accelerators in beirc commands, so I'd like it to go in,
after goatee-literate people (hi, tim!) have OKed it.


Here's the patch (sorry for the big hunk; the upper part is what I
changed; the lower part is emacs cl-indent playing games):
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,goatee-execute-frame-commands.patch
Type: application/octet-stream
Size: 3374 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060226/caffad8d/attachment.obj>
-------------- next part --------------

Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

From asf at boinkor.net  Sun Feb 26 15:45:24 2006
From: asf at boinkor.net (Andreas Fuchs)
Date: Sun, 26 Feb 2006 16:45:24 +0100
Subject: [mcclim-devel] [patch] make goatee search & execute frame
	commands	by gesture
In-Reply-To: <87fym64am5.wl%asf@boinkor.net>
References: <87fym64am5.wl%asf@boinkor.net>
Message-ID: <87ek1q3yzv.wl%asf@boinkor.net>

Today, Andreas Fuchs <asf at boinkor.net> wrote:
> Index: Goatee/editing-stream.lisp
> ===================================================================

Hrmpf. That patch was missing a vital part; here's the complete,
corrected patch (which now redisplays the application-frame's panes
like the command loop does):

Index: Goatee/editing-stream.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Goatee/editing-stream.lisp,v
retrieving revision 1.21
diff -u -r1.21 editing-stream.lisp
--- Goatee/editing-stream.lisp	22 Feb 2005 14:00:18 -0000	1.21
+++ Goatee/editing-stream.lisp	26 Feb 2006 15:42:44 -0000
@@ -160,7 +160,20 @@
     (return-from stream-process-gesture gesture))
   (let ((area (area stream))
 	(snapshot (snapshot stream)))
-    (execute-gesture-command gesture area *simple-area-gesture-table*)
+    (unless (execute-gesture-command gesture area *simple-area-gesture-table*)
+      (when (and (boundp '*application-frame*) (application-frame-p *application-frame*))
+        (handler-case
+            (prog1
+              (execute-frame-command *application-frame*
+                                     (lookup-keystroke-command-item
+                                      gesture
+                                      (frame-command-table *application-frame*)))
+              (redisplay-frame-panes *application-frame*))
+          (command-not-present ()
+            ;; gestures with modifiers will send one or several
+            ;; (modifier down) events. These will probably not be
+            ;; found, so ignore them.
+            nil))))
     (make-input-editing-stream-snapshot snapshot area)
     (let ((first-mismatch (mismatch (stream-input-buffer snapshot)
 				    (stream-input-buffer stream))))
Index: Goatee/goatee-command.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Goatee/goatee-command.lisp,v
retrieving revision 1.20
diff -u -r1.20 goatee-command.lisp
--- Goatee/goatee-command.lisp	5 Dec 2005 22:40:01 -0000	1.20
+++ Goatee/goatee-command.lisp	26 Feb 2006 15:42:44 -0000
@@ -94,7 +94,8 @@
 	      (funcall command :input-gesture gesture)
 	      (setf *last-command* command)
 	      (setf (last-command area) command)))
-	  (redisplay-area area)))))
+	  (redisplay-area area)
+          t))))
 
 ;; Utilities for the word movement commands
 

Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs


From asf at boinkor.net  Mon Feb 27 18:01:19 2006
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 27 Feb 2006 19:01:19 +0100
Subject: [mcclim-devel] standard-tree-output-records using spatial-trees
In-Reply-To: <87y805jbq1.wl%asf@boinkor.net>
References: <873bixkfdr.wl%asf@boinkor.net> <87wtg9iflm.wl%asf@boinkor.net>
	<87y805jbq1.wl%asf@boinkor.net>
Message-ID: <8764n08yvk.wl%asf@boinkor.net>

On 2006-02-21, Andreas Fuchs <asf at boinkor.net> wrote:
> * map-over-* didn't check if the child truly intersects the region /
> contains the point; this is enough only for ORs and regions that
> are equal to their bounding rectangle.

Thanks to Robert's tests with gsharp yesterday, we found out that this
code wrongly assumes that output records are regions. ORs are just
bounding rectangles, which means the code shouldn't call
bounding-rectangle on any OR; also, we shouldn't use the ORs in region
comparisons directly.

This version of the patch fixes this defect:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ,tree-output-records-4.patch
Type: application/octet-stream
Size: 7927 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20060227/4880dbc5/attachment.obj>
-------------- next part --------------
Cheers,
-- 
Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs