From rm at seid-online.de  Tue Feb  1 13:48:22 2005
From: rm at seid-online.de (rm at seid-online.de)
Date: Tue, 1 Feb 2005 14:48:22 +0100
Subject: [mcclim-devel] McCLIM and OpenMCL
Message-ID: <20050201134822.GA13336@seid-online.de>


Hello list,

i'm trying to run mcclim on my Linux/PPC with openmcl but
when i load the system i get the following error as soon
as i try to start the listener:

 ? (clim-listener:run-listener)
 > Error in process listener(2): Undefined function CLIM-INTERNALS::COMPUTE-INHERITED-KEYSTROKES called with arguments (#<STANDARD-COMMAND-TABLE CLIM-LISTENER::LISTENER #x35BBCD3E>) .
 > While executing: #<STANDARD-METHOD CLIM:READ-FRAME-COMMAND (CLIM-LISTENER::LISTENER)>
 > Type :GO to continue, :POP to abort.
 > If continued: Retry applying CLIM-INTERNALS::COMPUTE-INHERITED-KEYSTROKES to (#<STANDARD-COMMAND-TABLE CLIM-LISTENER::LISTENER #x35BBCD3E>).
 Type :? for other options.
 1 >

I tried to load mcclim both following the instructions in INSTALL.OPENMCL and using the 
new mcclim.asd (nice job, btw :).
The same code (cvs checkout) seems to work fine (but slow) with recent versions of SBCL.

Any hints?

   TIA Ralf Mattes


From amoroso at mclink.it  Tue Feb  1 19:46:59 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 01 Feb 2005 20:46:59 +0100
Subject: [mcclim-devel] McCLIM and OpenMCL
In-Reply-To: <20050201134822.GA13336@seid-online.de> (rm@seid-online.de's
	message of "Tue, 1 Feb 2005 14:48:22 +0100")
References: <20050201134822.GA13336@seid-online.de>
Message-ID: <877jlsysek.fsf@plato.moon.paoloamoroso.it>

rm at seid-online.de writes:

> i'm trying to run mcclim on my Linux/PPC with openmcl but
> when i load the system i get the following error as soon
> as i try to start the listener:
[...]

You may also add an entry here:

  http://mcclim.cliki.net/Bug


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


From strandh at labri.fr  Wed Feb  2 10:13:21 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 2 Feb 2005 11:13:21 +0100
Subject: [mcclim-devel] McCLIM inspector: how do I contribute?
In-Reply-To: <7e267a92050201145067b9e3b5@mail.gmail.com>
References: <7e267a92050201145067b9e3b5@mail.gmail.com>
Message-ID: <16896.42945.230260.16387@serveur5.labri.fr>

Hello, 

Peter Scott writes:
 > I've been working on improving the McCLIM inspector, and I've made
 > some substantial changes, like improved display of functions, strings,
 > structures, and generic functions, along with a bunch of added
 > comments and documentation. How can I contribute my changes to McCLIM?
 > 
 > Do I get everything in order and then send patches? If so, to whom?

Sure, if you can do patches, that would be good.  Please send them to
mcclim-devel at common-lisp.net.

Thanks for contributing,
-- 
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 moore at bricoworks.com  Wed Feb  2 10:26:19 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Wed, 2 Feb 2005 11:26:19 +0100
Subject: [mcclim-devel] McCLIM inspector: how do I contribute?
In-Reply-To: <16896.42945.230260.16387@serveur5.labri.fr>
References: <7e267a92050201145067b9e3b5@mail.gmail.com>
	<16896.42945.230260.16387@serveur5.labri.fr>
Message-ID: <E107E32A-7504-11D9-AB72-000A959839F8@bricoworks.com>


On Feb 2, 2005, at 11:13 AM, Robert Strandh wrote:

> Hello,
>
> Peter Scott writes:
>>
...
>> Do I get everything in order and then send patches? If so, to whom?
>
> Sure, if you can do patches, that would be good.  Please send them to
> mcclim-devel at common-lisp.net.
>
I just commited your (Peter's) clim-mop patch, so don't send that again 
:)

Tim



From asf at boinkor.net  Wed Feb  2 10:37:20 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Wed, 02 Feb 2005 11:37:20 +0100
Subject: [mcclim-devel] asdf-install ready mcclim.asd
In-Reply-To: <87k6pt8lab.wl%asf@boinkor.net>
References: <87mzup918o.wl%asf@boinkor.net>
	<87is5dbhpz.fsf@plato.moon.paoloamoroso.it>
	<87k6pt8lab.wl%asf@boinkor.net>
Message-ID: <871xbzi6xr.wl%asf@boinkor.net>

On 2005-01-31, Andreas Fuchs <asf at boinkor.net> wrote:
> By the way, I have put up an asdf-installable tarball of yesterday's
> McCLIM CVS checkout (non-anonymous CVS, though).
>
> Testers, get it via ASDF-INSTALL by running:
>
> (asdf-install:install
> "http://boinkor.net/lisp/mcclim/mcclim-2005-01-31.tar.gz")

Alright, I put up a new asdf-installable snapshot. Features:

 * Should work with OpenMCL (caveat: needs CLX pre-installed. The one
   from fink should work, if you have clx.asd linked from your
   asdf:*central-repository* directory)
 * more sparse dependency graph on the CLIM system - more incremental
   development support (-:

For a quick overview of the benefits of the second bullet, compare
http://www.boinkor.net/lisp/mcclim/CLIM.ps (the old graph) and
http://www.boinkor.net/lisp/mcclim/new-graphs/CLIM.ps (-:

The asdf-installable snapshot:

http://www.boinkor.net/lisp/mcclim/mcclim-2005-01-31e.tar.gz

If you pulled the previous asdf-install snapshot, you can get the
updated mcclim.asd (it's all that changed) from:

http://www.boinkor.net/lisp/mcclim/testing/mcclim.asd

> on your favorite lisp REPL. One pitfall: remove old links to
> system.lisp from your asdf:*central-registry* directories. I had to
> remove symlinks called clim.asd, clim-clx.asd, clim-clx-user.asd and
> clim-listener.asd.
>
> Nice test case after you installed it:
>
> (asdf:oos 'asdf:load-op :clim-examples)
> (clim-demo::run-test 'clim-demo::method-browser)
>
> and enter clim:note-sheet-grafted (-:

Good luck and have fun testing it!
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From pabw00 at gmail.com  Wed Feb  2 01:10:07 2005
From: pabw00 at gmail.com (Peter Wilson)
Date: Tue, 1 Feb 2005 17:10:07 -0800
Subject: [mcclim-devel] Inspector patch: view cons cells as list
Message-ID: <272abcf70502011710384ff3ed@mail.gmail.com>

Attached is an inspector patch which allows toggling the display of
cons cells between the current graph view and a list view.

It also makes the brief display of a character print the character.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cons-list.patch
Type: application/octet-stream
Size: 4282 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050201/85c57aa6/attachment.obj>

From amoroso at mclink.it  Wed Feb  2 12:58:19 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 02 Feb 2005 13:58:19 +0100
Subject: [mcclim-devel] CLIM-CLX::CLX-MEDIUM fell through ETYPECASE
 expression; error when starting Listener
Message-ID: <87fz0f15lg.fsf@plato.moon.paoloamoroso.it>

When I start the CLIM Listener by evaluating:

  (clim-listener:run-listener)

I get the error with backtrace included below.  I use McCLIM CVS
sources updated a few minutes ago, with CMUCL Snapshot 2005-01 under
Slackware Linux 10.0.


Paolo

-----------------------------------------------------------------------------
#<CLIM-CLX::CLX-MEDIUM {58FE5205}> fell through ETYPECASE expression.
Wanted one of (STREAM (MEMBER T) STRING NULL).
   [Condition of type CONDITIONS::CASE-FAILURE]

Restarts:
  0: [ABORT             ] Return to application command loop
  1: [RETURN-TO-LISTENER] Return to listener.
  2:                      Return to Top-Level.

Debug  (type H for help)

(FORMAT #<CLIM-CLX::CLX-MEDIUM {58FE5205}> "~A" "CL-USER")
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:code/format.lisp.
0] backtrace

0: (FORMAT #<CLIM-CLX::CLX-MEDIUM {58FE5205}> "~A" "CL-USER")
1: ((METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL NIL
     (CLIM:MEDIUM T T))
    (#(2 5 6 3 2 ...) . #(# #)) #<unused-arg>
    #<CLIM-CLX::CLX-MEDIUM {58FE5205}> #<CLIM-CLX::CLX-MEDIUM {58FE5205}> ...)
2: ((FLET #:CONT0
      CLIM-LISTENER::PRINT-LISTENER-PROMPT)
    #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58EBB45D}>)
3: ((METHOD CLIM:INVOKE-WITH-TEXT-STYLE NIL (CLIM:MEDIUM T T)) #<unused-arg>
    #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {58FE5205}>
    #<Closure Over Function (FLET #:CONT19
                              )
      {58BAECD1}>
    ...)
4: ((FLET #:CONT25
      )
    #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58EBB45D}>)
5: ((METHOD CLIM:INVOKE-WITH-TEXT-STYLE NIL (CLIM:MEDIUM T T)) #<unused-arg>
    #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {58FE5205}>
    #<Closure Over Function (FLET #:CONT19
                              )
      {58BAEB51}>
    ...)
6: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
    (#() . #(# # # # # ...)) #<unused-arg>
    #<CLIM-LISTENER::LISTENER {580BE0DD}>
    (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT))
7: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4720)" #<unused-arg> #<unused-arg>
    #<CLIM-LISTENER::LISTENER {580BE0DD}>
    (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT))
8: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
    (#(22) . #()) #<unused-arg> #<CLIM-LISTENER::LISTENER {580BE0DD}>
    #<unused-arg>)
9: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM-LISTENER::LISTENER))
    #<unused-arg>
    #S(PCL::FAST-METHOD-CALL
         :FUNCTION #<Function # {11686409}>
         :PV-CELL (# . #)
         :NEXT-METHOD-CALL NIL
         :ARG-INFO (1 . T))
    #<CLIM-LISTENER::LISTENER {580BE0DD}> (:LISTENER-FUNCALL NIL))
10: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME))
     (#(18 17) . #(#))
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {583301C9}>
          :PV-CELL NIL
          :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL
                                 :FUNCTION #
                                 :PV-CELL #
                                 :NEXT-METHOD-CALL NIL
                                 :ARG-INFO #)
          :ARG-INFO (1 . T))
     #<CLIM-LISTENER::LISTENER {580BE0DD}> (:LISTENER-FUNCALL NIL))
11: (INTERACTIVE-EVAL (CLIM-LISTENER:RUN-LISTENER))
12: (LISP::%TOP-LEVEL)
13: ((LABELS LISP::RESTART-LISP
       SAVE-LISP))

0]
-----------------------------------------------------------------------------

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


From amoroso at mclink.it  Wed Feb  2 13:13:57 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 02 Feb 2005 14:13:57 +0100
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update:
 mcclim/Apps/Inspector/clouseau.asd
 mcclim/Apps/Inspector/inspector.lisp mcclim/Apps/Inspector/inspector.asd
In-Reply-To: <20050202093353.A7D7A8802C@common-lisp.net> (Timothy Moore's
	message of "Wed,  2 Feb 2005 10:33:53 +0100 (CET)")
References: <20050202093353.A7D7A8802C@common-lisp.net>
Message-ID: <871xbz14ve.fsf@plato.moon.paoloamoroso.it>

tmoore at common-lisp.net (Timothy Moore) writes:

> Update of /project/mcclim/cvsroot/mcclim/Apps/Inspector
[...]
> Log Message:
> Changed name of inspector system and package to  clouseau in order to avoid conflicts with system inspectors.

The sample form in Apps/Inspector/INSTALL should accordingly be
changed to:

  (clouseau::inspector (clim:make-application-frame clouseau::inspector :obj 20))


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


From moore at bricoworks.com  Wed Feb  2 13:20:21 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Wed, 2 Feb 2005 14:20:21 +0100
Subject: [mcclim-devel] CLIM-CLX::CLX-MEDIUM fell through ETYPECASE
	expression; error when starting Listener
In-Reply-To: <87fz0f15lg.fsf@plato.moon.paoloamoroso.it>
References: <87fz0f15lg.fsf@plato.moon.paoloamoroso.it>
Message-ID: <3072F479-751D-11D9-AB72-000A959839F8@bricoworks.com>

I'm not seeing  this. I think you might need to remove old fasl files.  
I didn't realize that this morning's checkin required that, but the new  
behavior of with-drawing-options probably does require a recompile of  
everything

Tim

On Feb 2, 2005, at 1:58 PM, Paolo Amoroso wrote:

> When I start the CLIM Listener by evaluating:
>
>   (clim-listener:run-listener)
>
> I get the error with backtrace included below.  I use McCLIM CVS
> sources updated a few minutes ago, with CMUCL Snapshot 2005-01 under
> Slackware Linux 10.0.
>
>
> Paolo
>
> ----------------------------------------------------------------------- 
> ------
> #<CLIM-CLX::CLX-MEDIUM {58FE5205}> fell through ETYPECASE expression.
> Wanted one of (STREAM (MEMBER T) STRING NULL).
>    [Condition of type CONDITIONS::CASE-FAILURE]
>
> Restarts:
>   0: [ABORT             ] Return to application command loop
>   1: [RETURN-TO-LISTENER] Return to listener.
>   2:                      Return to Top-Level.
>
> Debug  (type H for help)
>
> (FORMAT #<CLIM-CLX::CLX-MEDIUM {58FE5205}> "~A" "CL-USER")
> Source: Error finding source:
> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no  
> longer exists:
>   target:code/format.lisp.
> 0] backtrace
>
> 0: (FORMAT #<CLIM-CLX::CLX-MEDIUM {58FE5205}> "~A" "CL-USER")
> 1: ((METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL NIL
>      (CLIM:MEDIUM T T))
>     (#(2 5 6 3 2 ...) . #(# #)) #<unused-arg>
>     #<CLIM-CLX::CLX-MEDIUM {58FE5205}> #<CLIM-CLX::CLX-MEDIUM  
> {58FE5205}> ...)
> 2: ((FLET #:CONT0
>       CLIM-LISTENER::PRINT-LISTENER-PROMPT)
>     #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58EBB45D}>)
> 3: ((METHOD CLIM:INVOKE-WITH-TEXT-STYLE NIL (CLIM:MEDIUM T T))  
> #<unused-arg>
>     #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {58FE5205}>
>     #<Closure Over Function (FLET #:CONT19
>                               )
>       {58BAECD1}>
>     ...)
> 4: ((FLET #:CONT25
>       )
>     #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58EBB45D}>)
> 5: ((METHOD CLIM:INVOKE-WITH-TEXT-STYLE NIL (CLIM:MEDIUM T T))  
> #<unused-arg>
>     #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {58FE5205}>
>     #<Closure Over Function (FLET #:CONT19
>                               )
>       {58BAEB51}>
>     ...)
> 6: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
>     (#() . #(# # # # # ...)) #<unused-arg>
>     #<CLIM-LISTENER::LISTENER {580BE0DD}>
>     (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT))
> 7: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4720)" #<unused-arg>  
> #<unused-arg>
>     #<CLIM-LISTENER::LISTENER {580BE0DD}>
>     (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT))
> 8: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
>     (#(22) . #()) #<unused-arg> #<CLIM-LISTENER::LISTENER {580BE0DD}>
>     #<unused-arg>)
> 9: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM-LISTENER::LISTENER))
>     #<unused-arg>
>     #S(PCL::FAST-METHOD-CALL
>          :FUNCTION #<Function # {11686409}>
>          :PV-CELL (# . #)
>          :NEXT-METHOD-CALL NIL
>          :ARG-INFO (1 . T))
>     #<CLIM-LISTENER::LISTENER {580BE0DD}> (:LISTENER-FUNCALL NIL))
> 10: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND)  
> (CLIM:APPLICATION-FRAME))
>      (#(18 17) . #(#))
>      #S(PCL::FAST-METHOD-CALL
>           :FUNCTION #<Function # {583301C9}>
>           :PV-CELL NIL
>           :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL
>                                  :FUNCTION #
>                                  :PV-CELL #
>                                  :NEXT-METHOD-CALL NIL
>                                  :ARG-INFO #)
>           :ARG-INFO (1 . T))
>      #<CLIM-LISTENER::LISTENER {580BE0DD}> (:LISTENER-FUNCALL NIL))
> 11: (INTERACTIVE-EVAL (CLIM-LISTENER:RUN-LISTENER))
> 12: (LISP::%TOP-LEVEL)
> 13: ((LABELS LISP::RESTART-LISP
>        SAVE-LISP))
>
> 0]
> ----------------------------------------------------------------------- 
> ------
>
> -- 
> 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  Wed Feb  2 14:21:45 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 02 Feb 2005 15:21:45 +0100
Subject: [mcclim-devel] CLIM-CLX::CLX-MEDIUM fell through ETYPECASE
	expression; error when starting Listener
References: <87fz0f15lg.fsf@plato.moon.paoloamoroso.it>
	<3072F479-751D-11D9-AB72-000A959839F8@bricoworks.com>
Message-ID: <87ekfzyrd2.fsf@plato.moon.paoloamoroso.it>

Timothy Moore <moore at bricoworks.com> writes:

> I'm not seeing  this. I think you might need to remove old fasl files.
> I didn't realize that this morning's checkin required that, but the
> new  behavior of with-drawing-options probably does require a
> recompile of  everything

Yes, this is the case.  Thanks,


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


From mikemac at mikemac.com  Wed Feb  2 16:26:13 2005
From: mikemac at mikemac.com (mikemac at mikemac.com)
Date: Wed, 02 Feb 2005 10:26:13 -0600
Subject: [mcclim-devel] McCLIM inspector: how do I contribute? 
In-Reply-To: Your message of "Wed, 02 Feb 2005 11:13:21 +0100."
	<16896.42945.230260.16387@serveur5.labri.fr> 
Message-ID: <200502021626.j12GQE2J010107@saturn.mikemac.com>


>To: Peter Scott <sketerpot at gmail.com>
>Date: Wed, 2 Feb 2005 11:13:21 +0100
>From: Robert Strandh
>
>Hello, 
>
>Peter Scott writes:
> > I've been working on improving the McCLIM inspector, and I've made
> > some substantial changes, like improved display of functions, strings,
> > structures, and generic functions, along with a bunch of added
> > comments and documentation. How can I contribute my changes to McCLIM?
> > 
> > Do I get everything in order and then send patches? If so, to whom?
>
>Sure, if you can do patches, that would be good.  Please send them to
>mcclim-devel at common-lisp.net.

  Or you could get CVS commit access. Then you could just check in
your fixes/improvements.

  Mike McDonald
  mikemac at mikemac.com


From strandh at labri.fr  Wed Feb  2 17:53:02 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 2 Feb 2005 18:53:02 +0100
Subject: [mcclim-devel] McCLIM inspector: how do I contribute? 
In-Reply-To: <200502021626.j12GQE2J010107@saturn.mikemac.com>
References: <16896.42945.230260.16387@serveur5.labri.fr>
	<200502021626.j12GQE2J010107@saturn.mikemac.com>
Message-ID: <16897.4990.633651.749262@serveur5.labri.fr>

mikemac at mikemac.com writes:
 >   Or you could get CVS commit access. Then you could just check in
 > your fixes/improvements.

That's not a bad idea.  I am looking for someone to take over the
inspector anyway, because I am a little bit too busy with Climacs at
the moment. 
-- 
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 sketerpot at gmail.com  Wed Feb  2 17:45:08 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Wed, 2 Feb 2005 10:45:08 -0700
Subject: [mcclim-devel] McCLIM inspector: how do I contribute?
In-Reply-To: <200502021626.j12GQE2J010107@saturn.mikemac.com>
References: <16896.42945.230260.16387@serveur5.labri.fr>
	<200502021626.j12GQE2J010107@saturn.mikemac.com>
Message-ID: <7e267a9205020209455054754e@mail.gmail.com>

On Wed, 02 Feb 2005 10:26:13 -0600, mikemac at mikemac.com 
>   Or you could get CVS commit access. Then you could just check in
> your fixes/improvements.

That would be the most convenient way. My common-lisp.net username is pscott.

-Peter


From strandh at labri.fr  Wed Feb  2 19:36:42 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 2 Feb 2005 20:36:42 +0100
Subject: [mcclim-devel] (no subject)
Message-ID: <16897.11210.638959.241770@serveur5.labri.fr>

Hello, 

Vincent Arkesteijn (<vincent at arkesteijn.net>) has agreed to take over
the maintenance of the CLIM inspector (Clouseau).  For that reason, he
will need write privileges to the McCLIM CVS tree. 

Thanks in advance,
-- 
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 strandh at labri.fr  Wed Feb  2 19:45:41 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 2 Feb 2005 20:45:41 +0100
Subject: [mcclim-devel] write privileges to McCLIM for Peter Scott
Message-ID: <16897.11749.139085.282631@serveur5.labri.fr>

Hello, 

Could you please give write priviles to the McCLIM CVS tree for Peter
Scott (who already has a common-lisp.net account with the name pscott)
so that he can commit changes to the CLIM inspector?

Thanks in advance, 
-- 
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  2 20:10:15 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Wed, 2 Feb 2005 14:10:15 -0600
Subject: [mcclim-devel] Inspector MOP
In-Reply-To: <7e267a9205013113155951458@mail.gmail.com>
References: <7e267a9205013113155951458@mail.gmail.com>
Message-ID: <16897.13223.481064.343461@gargle.gargle.HOWL>


I just caught up with this email, and it looks to me as if this will
cause the inspector to fail for any lisp other than mcl and sbcl (and
possibly cmucl).  Shouldn't you be calling functions in the CLIM-MOP
package?  I just submitted a patch to Lisp-Dep/fix-acl.lisp to (I
hope) make the CLIM-MOP package work for my beloved Allegro CL.

Best,
R


From moore at bricoworks.com  Wed Feb  2 20:42:15 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Wed, 2 Feb 2005 21:42:15 +0100
Subject: [mcclim-devel] Inspector MOP
In-Reply-To: <16897.13223.481064.343461@gargle.gargle.HOWL>
References: <7e267a9205013113155951458@mail.gmail.com>
	<16897.13223.481064.343461@gargle.gargle.HOWL>
Message-ID: <EC866870-755A-11D9-AB72-000A959839F8@bricoworks.com>

The inspector is currently using clim-mop.

Tim

On Feb 2, 2005, at 9:10 PM, rpgoldman at real-time.com wrote:

>
> I just caught up with this email, and it looks to me as if this will
> cause the inspector to fail for any lisp other than mcl and sbcl (and
> possibly cmucl).  Shouldn't you be calling functions in the CLIM-MOP
> package?  I just submitted a patch to Lisp-Dep/fix-acl.lisp to (I
> hope) make the CLIM-MOP package work for my beloved Allegro CL.
>
> Best,
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From jdz at dir.lv  Wed Feb  2 21:05:48 2005
From: jdz at dir.lv (Janis Dzerins)
Date: Wed, 02 Feb 2005 23:05:48 +0200
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update:
	mcclim/Apps/Inspector/clouseau.asd
	mcclim/Apps/Inspector/inspector.lisp
	mcclim/Apps/Inspector/inspector.asd
In-Reply-To: <871xbz14ve.fsf@plato.moon.paoloamoroso.it>
References: <20050202093353.A7D7A8802C@common-lisp.net>
	<871xbz14ve.fsf@plato.moon.paoloamoroso.it>
Message-ID: <1107378348.7779.1.camel@localhost>

On Wed, 2005-02-02 at 14:13 +0100, Paolo Amoroso wrote:

> The sample form in Apps/Inspector/INSTALL should accordingly be
> changed to:
> 
>   (clouseau::inspector (clim:make-application-frame clouseau::inspector :obj 20))

How about either:
  (clouseau::inspector 20)
or
  (clim:make-application-frame 'clouseau::inspector :obj 20)
?

-- 
Janis Dzerins

  If million people say a stupid thing, it's still a stupid thing.




From pabw00 at gmail.com  Wed Feb  2 23:33:44 2005
From: pabw00 at gmail.com (Peter Wilson)
Date: Wed, 2 Feb 2005 15:33:44 -0800
Subject: [mcclim-devel] Inspector patch: view cons cells as list
In-Reply-To: <7e267a92050202134674d30700@mail.gmail.com>
References: <272abcf70502011710384ff3ed@mail.gmail.com>
	<7e267a92050202134674d30700@mail.gmail.com>
Message-ID: <272abcf705020215331c7e939@mail.gmail.com>

On Wed, 2 Feb 2005 14:46:53 -0700, Peter Scott <sketerpot at gmail.com> wrote:

> It's a little hard to use (toggling is difficult when you have to hit
> those tiny little parentheses, and I'm not entirely sure how to get
> back from the graphical view),

True. I forgot to make the graphical view use the cons presentation.
(Although if there were some way to make (presentation-type-of) of a
cons return something more informative than (SEQUENCE T), it might
work automatically.)


--- inspector.lisp	2005-02-02 15:22:39.000000000 -0800
+++ inspector.lisp	2005-02-02 15:26:09.000000000 -0800
@@ -138,7 +138,7 @@
 	(formatting-column (pane)
 	  (formatting-cell (pane)
             (with-output-as-presentation
-                (pane object (presentation-type-of object))
+                (pane object 'cons)
               (draw-rectangle* pane 0 0 20 10 :filled nil))
 	    (draw-line* pane 10 0 10 10)
 	    (draw-arrow* pane 5 5 5 30)
@@ -152,7 +152,7 @@
 	      (formatting-column (pane)
 		(formatting-cell (pane)
 		  (with-output-as-presentation
-		      (pane object (presentation-type-of object))
+		      (pane object 'cons)
 		    (draw-rectangle* pane 0 0 20 10 :filled nil))
 		  (draw-line* pane 10 0 10 10)
 		  (draw-arrow* pane 5 5 5 30)


From sketerpot at gmail.com  Wed Feb  2 21:46:53 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Wed, 2 Feb 2005 14:46:53 -0700
Subject: [mcclim-devel] Inspector patch: view cons cells as list
In-Reply-To: <272abcf70502011710384ff3ed@mail.gmail.com>
References: <272abcf70502011710384ff3ed@mail.gmail.com>
Message-ID: <7e267a92050202134674d30700@mail.gmail.com>

On Tue, 1 Feb 2005 17:10:07 -0800, Peter Wilson <pabw00 at gmail.com> wrote:
> Attached is an inspector patch which allows toggling the display of
> cons cells between the current graph view and a list view.

It's a little hard to use (toggling is difficult when you have to hit
those tiny little parentheses, and I'm not entirely sure how to get
back from the graphical view), but it looks like something that should
be included in some form or another. I've merged it into my updated
inspector.lisp, so when I get CVS access it'll be put in CVS.

> It also makes the brief display of a character print the character.

I wrote the exact same code yesterday, just indented a little
differently. Neat, huh? Of course, it's only three lines of code.

-Peter


From rpgoldman at real-time.com  Thu Feb  3 00:57:29 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Wed, 2 Feb 2005 18:57:29 -0600
Subject: [mcclim-devel] clim-mop exported symbols
Message-ID: <16897.30457.719394.847395@gargle.gargle.HOWL>


Is there any canonical list specifying what the exported symbols of
the clim-mop package should be?  I've been trying to make a defpackage
for fix-acl.lisp, but all the existing forms seem to loop over some
other package's exported symbols and export them.  

So I've been making up my list of symbols by waiting until some
compilation crashes, and then exporting a new one.  This doesn't seem
like a happy solution ;-)

Wouldn't it be better to have a canonical defpackage somewhere, so
that we can all see what we can count on?

Failing that, would someone with a working SBCL or CMUCL installation,
please send me a list of the exported symbols from their clim-mop
definition?

R


From sketerpot at gmail.com  Thu Feb  3 01:09:56 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Wed, 2 Feb 2005 18:09:56 -0700
Subject: [mcclim-devel] clim-mop exported symbols
In-Reply-To: <16897.30457.719394.847395@gargle.gargle.HOWL>
References: <16897.30457.719394.847395@gargle.gargle.HOWL>
Message-ID: <7e267a920502021709400326c4@mail.gmail.com>

On Wed, 2 Feb 2005 18:57:29 -0600, rpgoldman at real-time.com
<rpgoldman at real-time.com> wrote:
> Failing that, would someone with a working SBCL or CMUCL installation,
> please send me a list of the exported symbols from their clim-mop
> definition?

On SBCL 0.8.16, using the latest McCLIM CVS:

STANDARD-WRITER-METHOD
SLOT-DEFINITION-INITFUNCTION
ENSURE-CLASS
METHOD-QUALIFIERS
GENERIC-FUNCTION-NAME
EXTRACT-LAMBDA-LIST
FUNCTION
REMOVE-DEPENDENT
COMPUTE-CLASS-PRECEDENCE-LIST
EXTRACT-SPECIALIZER-NAMES
REMOVE-DIRECT-METHOD
SLOT-VALUE-USING-CLASS
SLOT-DEFINITION-NAME
GENERIC-FUNCTION-METHODS
REMOVE-METHOD
INTERN-EQL-SPECIALIZER
METHOD-GENERIC-FUNCTION
SPECIALIZER-DIRECT-METHODS
SLOT-DEFINITION-INITARGS
ENSURE-GENERIC-FUNCTION-USING-CLASS
MAKE-METHOD-LAMBDA
CLASS-DIRECT-SLOTS
SLOT-DEFINITION-READERS
DIRECT-SLOT-DEFINITION
METHOD
EQL-SPECIALIZER-OBJECT
METHOD-SPECIALIZERS
DIRECT-SLOT-DEFINITION-CLASS
ENSURE-GENERIC-FUNCTION
STANDARD-OBJECT
SLOT-MAKUNBOUND-USING-CLASS
CLASS-DEFAULT-INITARGS
SPECIALIZER
SLOT-DEFINITION-ALLOCATION
EQL-SPECIALIZER
ENSURE-CLASS-USING-CLASS
SLOT-DEFINITION-LOCATION
ALLOCATE-INSTANCE
ADD-DEPENDENT
GENERIC-FUNCTION-METHOD-COMBINATION
SLOT-DEFINITION
T
STANDARD-READER-METHOD
STANDARD-DIRECT-SLOT-DEFINITION
COMPUTE-APPLICABLE-METHODS
SLOT-DEFINITION-TYPE
COMPUTE-DISCRIMINATING-FUNCTION
CLASS-DIRECT-DEFAULT-INITARGS
REMOVE-DIRECT-SUBCLASS
STANDARD-CLASS
GENERIC-FUNCTION-DECLARATIONS
FUNCALLABLE-STANDARD-OBJECT
CLASS-SLOTS
FUNCALLABLE-STANDARD-INSTANCE-ACCESS
METHOD-COMBINATION
ADD-METHOD
CLASS-NAME
SLOT-DEFINITION-INITFORM
FORWARD-REFERENCED-CLASS
SPECIALIZER-DIRECT-GENERIC-FUNCTIONS
CLASS-FINALIZED-P
BUILT-IN-CLASS
EFFECTIVE-SLOT-DEFINITION
VALIDATE-SUPERCLASS
GENERIC-FUNCTION-LAMBDA-LIST
UPDATE-DEPENDENT
CLASS
SET-FUNCALLABLE-INSTANCE-FUNCTION
FIND-METHOD-COMBINATION
CLASS-PRECEDENCE-LIST
STANDARD-INSTANCE-ACCESS
ADD-DIRECT-SUBCLASS
STANDARD-METHOD
MAKE-INSTANCE
GENERIC-FUNCTION-METHOD-CLASS
STANDARD-SLOT-DEFINITION
COMPUTE-DEFAULT-INITARGS
WRITER-METHOD-CLASS
FUNCALLABLE-STANDARD-CLASS
COMPUTE-APPLICABLE-METHODS-USING-CLASSES
MAP-DEPENDENTS
STANDARD-EFFECTIVE-SLOT-DEFINITION
STANDARD-ACCESSOR-METHOD
READER-METHOD-CLASS
ACCESSOR-METHOD-SLOT-DEFINITION
GENERIC-FUNCTION
CLASS-DIRECT-SUBCLASSES
SLOT-DEFINITION-WRITERS
METHOD-LAMBDA-LIST
EFFECTIVE-SLOT-DEFINITION-CLASS
COMPUTE-EFFECTIVE-METHOD
STANDARD-GENERIC-FUNCTION
COMPUTE-SLOTS
METHOD-FUNCTION
GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER
CLASS-DIRECT-SUPERCLASSES
COMPUTE-EFFECTIVE-SLOT-DEFINITION
ADD-DIRECT-METHOD
FINALIZE-INHERITANCE
SLOT-BOUNDP-USING-CLASS
CLASS-PROTOTYPE
NIL


From strandh at labri.fr  Thu Feb  3 05:19:48 2005
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 3 Feb 2005 06:19:48 +0100
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update:
	mcclim/Apps/Inspector/clouseau.asd
	mcclim/Apps/Inspector/inspector.lisp
	mcclim/Apps/Inspector/inspector.asd
In-Reply-To: <1107378348.7779.1.camel@localhost>
References: <20050202093353.A7D7A8802C@common-lisp.net>
	<871xbz14ve.fsf@plato.moon.paoloamoroso.it>
	<1107378348.7779.1.camel@localhost>
Message-ID: <16897.46196.352258.848508@serveur5.labri.fr>

Janis Dzerins writes:
 > On Wed, 2005-02-02 at 14:13 +0100, Paolo Amoroso wrote:
 > 
 > > The sample form in Apps/Inspector/INSTALL should accordingly be
 > > changed to:
 > > 
 > >   (clouseau::inspector (clim:make-application-frame clouseau::inspector :obj 20))
 > 
 > How about either:
 >   (clouseau::inspector 20)

That would inspect the object 20 as opposed to an inspector frame that
inspects the object 20. 

 > or
 >   (clim:make-application-frame 'clouseau::inspector :obj 20)

That creates an instance of an inspector frame that inspects the
object 20, but does not run the application. 

Perhaps my example is confusing because the call to
clouseau::inspector runs the inspector and the call to
make-application-frame just creates something for the inspector to
inspect, and that something happens to be an inspector
applicataion-frame. 

-- 
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 amoroso at mclink.it  Thu Feb  3 14:18:23 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 03 Feb 2005 15:18:23 +0100
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update:
	mcclim/Apps/Inspector/clouseau.asd mcclim/Apps/Inspector/inspector.lisp
	mcclim/Apps/Inspector/inspector.asd
In-Reply-To: <16897.46196.352258.848508@serveur5.labri.fr> (Robert Strandh's
	message of "Thu, 3 Feb 2005 06:19:48 +0100")
References: <20050202093353.A7D7A8802C@common-lisp.net>
	<871xbz14ve.fsf@plato.moon.paoloamoroso.it>
	<1107378348.7779.1.camel@localhost>
	<16897.46196.352258.848508@serveur5.labri.fr>
Message-ID: <87vf99k9qo.fsf@plato.moon.paoloamoroso.it>

Robert Strandh <strandh at labri.fr> writes:

> Perhaps my example is confusing because the call to
> clouseau::inspector runs the inspector and the call to
> make-application-frame just creates something for the inspector to
> inspect, and that something happens to be an inspector
> applicataion-frame. 

He he he, the devious self-referentiality of Lispers :)


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


From amoroso at mclink.it  Thu Feb  3 14:49:26 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 03 Feb 2005 15:49:26 +0100
Subject: [mcclim-devel] clim-mop exported symbols
References: <16897.30457.719394.847395@gargle.gargle.HOWL>
Message-ID: <87lla5itqh.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> Failing that, would someone with a working SBCL or CMUCL installation,
> please send me a list of the exported symbols from their clim-mop
> definition?

I include below the CLIM-MOP symbols in my CMUCL Snapshot 2005-01
image with the latest McCLIM.


Paolo

----------------------------------------------------------------
ADD-METHOD 
ALLOCATE-INSTANCE 
CLASS-NAME 
COMPUTE-APPLICABLE-METHODS 
ENSURE-GENERIC-FUNCTION 
MAKE-INSTANCE 
METHOD-QUALIFIERS 
PCL:ACCESSOR-METHOD-SLOT-DEFINITION 
PCL:ADD-DEPENDENT 
PCL:ADD-DIRECT-METHOD 
PCL:ADD-DIRECT-SUBCLASS 
PCL:CLASS-DEFAULT-INITARGS 
PCL:CLASS-DIRECT-DEFAULT-INITARGS 
PCL:CLASS-DIRECT-SLOTS 
PCL:CLASS-DIRECT-SUBCLASSES 
PCL:CLASS-DIRECT-SUPERCLASSES 
PCL:CLASS-FINALIZED-P 
PCL:CLASS-PRECEDENCE-LIST 
PCL:CLASS-PROTOTYPE 
PCL:CLASS-SLOTS 
PCL:COMPUTE-APPLICABLE-METHODS-USING-CLASSES 
PCL:COMPUTE-CLASS-PRECEDENCE-LIST 
PCL:COMPUTE-DEFAULT-INITARGS 
PCL:COMPUTE-DISCRIMINATING-FUNCTION 
PCL:COMPUTE-EFFECTIVE-METHOD 
PCL:COMPUTE-EFFECTIVE-SLOT-DEFINITION 
PCL:COMPUTE-SLOTS 
PCL:DIRECT-SLOT-DEFINITION 
PCL:DIRECT-SLOT-DEFINITION-CLASS 
PCL:EFFECTIVE-SLOT-DEFINITION 
PCL:EFFECTIVE-SLOT-DEFINITION-CLASS 
PCL:ENSURE-CLASS 
PCL:ENSURE-CLASS-USING-CLASS 
PCL:ENSURE-GENERIC-FUNCTION-USING-CLASS 
PCL:EQL-SPECIALIZER 
PCL:EQL-SPECIALIZER-OBJECT 
PCL:EXTRACT-LAMBDA-LIST 
PCL:EXTRACT-SPECIALIZER-NAMES 
PCL:FINALIZE-INHERITANCE 
PCL:FIND-METHOD-COMBINATION 
PCL:FORWARD-REFERENCED-CLASS 
PCL:FUNCALLABLE-STANDARD-CLASS 
PCL:FUNCALLABLE-STANDARD-INSTANCE-ACCESS 
PCL:FUNCALLABLE-STANDARD-OBJECT 
PCL:GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER 
PCL:GENERIC-FUNCTION-DECLARATIONS 
PCL:GENERIC-FUNCTION-LAMBDA-LIST 
PCL:GENERIC-FUNCTION-METHOD-CLASS 
PCL:GENERIC-FUNCTION-METHOD-COMBINATION 
PCL:GENERIC-FUNCTION-METHODS 
PCL:GENERIC-FUNCTION-NAME 
PCL:INTERN-EQL-SPECIALIZER 
PCL:MAKE-METHOD-LAMBDA 
PCL:MAP-DEPENDENTS 
PCL:METAOBJECT 
PCL:METHOD-FUNCTION 
PCL:METHOD-GENERIC-FUNCTION 
PCL:METHOD-LAMBDA-LIST 
PCL:METHOD-SPECIALIZERS 
PCL:READER-METHOD-CLASS 
PCL:REMOVE-DEPENDENT 
PCL:REMOVE-DIRECT-METHOD 
PCL:REMOVE-DIRECT-SUBCLASS 
PCL:SET-FUNCALLABLE-INSTANCE-FUNCTION 
PCL:SLOT-BOUNDP-USING-CLASS 
PCL:SLOT-DEFINITION 
PCL:SLOT-DEFINITION-ALLOCATION 
PCL:SLOT-DEFINITION-INITARGS 
PCL:SLOT-DEFINITION-INITFORM 
PCL:SLOT-DEFINITION-INITFUNCTION 
PCL:SLOT-DEFINITION-LOCATION 
PCL:SLOT-DEFINITION-NAME 
PCL:SLOT-DEFINITION-READERS 
PCL:SLOT-DEFINITION-TYPE 
PCL:SLOT-DEFINITION-WRITERS 
PCL:SLOT-MAKUNBOUND-USING-CLASS 
PCL:SLOT-VALUE-USING-CLASS 
PCL:SPECIALIZER 
PCL:SPECIALIZER-DIRECT-GENERIC-FUNCTIONS 
PCL:SPECIALIZER-DIRECT-METHODS 
PCL:STANDARD-ACCESSOR-METHOD 
PCL:STANDARD-DIRECT-SLOT-DEFINITION 
PCL:STANDARD-EFFECTIVE-SLOT-DEFINITION 
PCL:STANDARD-INSTANCE-ACCESS 
PCL:STANDARD-READER-METHOD 
PCL:STANDARD-SLOT-DEFINITION 
PCL:STANDARD-WRITER-METHOD 
PCL:UPDATE-DEPENDENT 
PCL:VALIDATE-SUPERCLASS 
PCL:WRITER-METHOD-CLASS 
REMOVE-METHOD 
STANDARD-GENERIC-FUNCTION 
STANDARD-METHOD 
----------------------------------------------------------------

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


From rpgoldman at sift.info  Thu Feb  3 15:40:01 2005
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Thu, 3 Feb 2005 09:40:01 -0600
Subject: [mcclim-devel] patch for fix-acl.lisp
Message-ID: <16898.17873.115593.672958@gargle.gargle.HOWL>


Will someone with privileges please apply the attached patch (I also
attach the full lisp file, should that be easier) to
Lisp-Dep/fix-acl.lisp?

AFAICT, this should fix problems with defining the CLIM-MOP package
for Allegro Common Lisp.

I don't see any downside to applying this patch, since some canvassing
reveals that I'm the only person who will admit to using McCLIM with
Allegro CL, so I will only be hurting myself if there's anything
wrong!  And I *might* be helping some future ACL user.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix-acl-patch
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050203/effa9978/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fix-acl.lisp
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050203/effa9978/attachment-0001.ksh>

From amoroso at mclink.it  Thu Feb  3 15:53:00 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 03 Feb 2005 16:53:00 +0100
Subject: [mcclim-devel] Method browser error: no matching method for GF
 CLASS-NAME when browsing PRINT-OBJECT
Message-ID: <87d5vhiqsj.fsf@plato.moon.paoloamoroso.it>

When I provide the name of the PRINT-OBJECT generic function as input
to the method browser in Examples/method-browser.lisp, I get the error
message with backtrace included below.  I use the latest McCLIM CVS
sources with CMUCL Snapshot 2005-01 under Slackware Linux 10.0.


Paolo

------------------------------------------------------------------------
No matching method for the generic function
#<STANDARD-GENERIC-FUNCTION CLASS-NAME (1) {281B2709}>, when called with
arguments (#<PCL:EQL-SPECIALIZER {285532FD}>).
   [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

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

Debug  (type H for help)

("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
 #<STANDARD-GENERIC-FUNCTION CLASS-NAME (1) {281B2709}>
 (#<PCL:EQL-SPECIALIZER {285532FD}>))
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:pcl/braid.lisp.
0] backtrace

0: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
    #<STANDARD-GENERIC-FUNCTION CLASS-NAME (1) {281B2709}>
    (#<PCL:EQL-SPECIALIZER {285532FD}>))
1: ("DEFUN SORTED-GF-SPECIALIZERS" #<STANDARD-CLASS CLIM:OPACITY {283D4B55}>
    #<PCL:EQL-SPECIALIZER {285532FD}>)
2: (LISP::MERGE-LISTS* #<unavailable-arg>
                       #<unavailable-arg>
                       #<Function "DEFUN SORTED-GF-SPECIALIZERS" {58F75D31}>
                       NIL
                       ...)
3: (LISP::SORT-LIST
    (#<STANDARD-CLASS CLIM-CLX::CLX-PORT {282FEC85}>
     #<STANDARD-CLASS CLIM-CLX::FONTSET {285FD915}>
     #<STANDARD-CLASS CLIM:PANE {28322D0D}>
     #<STANDARD-CLASS CLIM-INTERNALS::STANDARD-SPACE-REQUIREMENT {28343B4D}>
     #<STANDARD-CLASS CLIM:COMMAND-TABLE {2838DC75}> ...)
    #<Function "DEFUN SORTED-GF-SPECIALIZERS" {58F75D31}>
    NIL)
4: (CLIM-DEMO::SORTED-GF-SPECIALIZERS
    #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (47) {281B3739}>)
5: (CLIM-DEMO::COMPUTE-INITIAL-ARG-TYPES
    #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (47) {281B3739}>)
6: (CLIM-DEMO::SETUP-NEW-GF #<CLIM-DEMO::METHOD-BROWSER {58428FFD}>
                            #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (47)
                              {281B3739}>)
7: (CLIM-INTERNALS::INVOKE-CALLBACK
    #<CLIM:TEXT-FIELD-PANE CLIM-DEMO::GF-NAME-INPUT {58EF4FD5}>
    CLIM-DEMO::GF-NAME-INPUT-CALLBACK)
8: ((METHOD CLIM:HANDLE-EVENT NIL (CLIM:TEXT-FIELD-PANE CLIM:KEY-PRESS-EVENT))
    (#(64 67 22 21 64 ...) . #(#)) #<unused-arg>
    #<CLIM:TEXT-FIELD-PANE CLIM-DEMO::GF-NAME-INPUT {58EF4FD5}>
    #<CLIM:KEY-PRESS-EVENT {5892B97D}>)
9: (CLIM-INTERNALS::HANDLE-NON-STREAM-EVENT
    #<CLIM-INTERNALS::PORT-EVENT-QUEUE {5849386D}>)
10: ((METHOD CLIM:STREAM-INPUT-WAIT NIL (CLIM:STANDARD-EXTENDED-INPUT-STREAM))
     (#(18) . #(#)) #<unused-arg>
     #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
     (:TIMEOUT NIL :INPUT-WAIT-TEST
      #<Function CLIM-INTERNALS::INPUT-CONTEXT-WAIT-TEST {1155B1F1}>))
11: ((METHOD CLIM:STREAM-READ-GESTURE NIL
      (CLIM:STANDARD-EXTENDED-INPUT-STREAM))
     (#(60) . #(#)) #<unused-arg>
     #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
     (:TIMEOUT NIL :PEEK-P NIL :INPUT-WAIT-TEST ...))
12: (CLIM:READ-COMMAND
     #<CLIM:STANDARD-COMMAND-TABLE CLIM-DEMO::METHOD-BROWSER {58EDF55D}>
     :STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
     :COMMAND-PARSER ...)
13: (CLIM:READ-COMMAND-USING-KEYSTROKES
     #<CLIM:STANDARD-COMMAND-TABLE CLIM-DEMO::METHOD-BROWSER {58EDF55D}>
     NIL
     :STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
     ...)
14: (CLIM:READ-COMMAND
     #<CLIM:STANDARD-COMMAND-TABLE CLIM-DEMO::METHOD-BROWSER {58EDF55D}>
     :STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
     :COMMAND-PARSER ...)
15: ((METHOD CLIM:READ-FRAME-COMMAND (:AROUND) (CLIM:APPLICATION-FRAME))
     (#(5) . #())
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {11563581}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL NIL
          :ARG-INFO (1 . T))
     #<CLIM-DEMO::METHOD-BROWSER {58428FFD}>
     (:STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>))
16: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#() . #(# # # # # ...)) #<unused-arg>
     #<CLIM-DEMO::METHOD-BROWSER {58428FFD}> NIL)
17: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4227)" #<unused-arg> #<unused-arg>
     #<CLIM-DEMO::METHOD-BROWSER {58428FFD}> NIL)
18: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#(20) . #()) #<unused-arg> #<CLIM-DEMO::METHOD-BROWSER {58428FFD}>
     #<unused-arg>)
19: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME))
     (#(16 15) . #(#))
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {11686B49}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL NIL
          :ARG-INFO (1 . T))
     #<CLIM-DEMO::METHOD-BROWSER {58428FFD}> NIL)
20: (INTERACTIVE-EVAL (CLIM-DEMO::RUN-TEST 'CLIM-DEMO::METHOD-BROWSER))
21: (LISP::%TOP-LEVEL)
22: ((LABELS LISP::RESTART-LISP
       SAVE-LISP))

0]
------------------------------------------------------------------------

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


From csr21 at cam.ac.uk  Thu Feb  3 15:45:35 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Thu, 03 Feb 2005 15:45:35 +0000
Subject: [mcclim-devel] [Christophe Rhodes] [Sbcl-devel] PCL depessimization
Message-ID: <sqwttpk5pc.fsf@cam.ac.uk>

Hi,

Tim Moore suggested that this might be of interest -- I'd certainly be
interested in hearing reports from anyone who tries mcclim with sbcl
and the attached patch.

Thanks,

Christophe

-------------- next part --------------
An embedded message was scrubbed...
From: Christophe Rhodes <csr21 at cam.ac.uk>
Subject: [Sbcl-devel] PCL depessimization
Date: Thu, 03 Feb 2005 12:20:05 +0000
Size: 8266
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050203/fb9b71b9/attachment.mht>

From ahefner at gmail.com  Thu Feb  3 16:10:25 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 3 Feb 2005 11:10:25 -0500
Subject: [mcclim-devel] Method browser error: no matching method for GF
	CLASS-NAME when browsing PRINT-OBJECT
In-Reply-To: <87d5vhiqsj.fsf@plato.moon.paoloamoroso.it>
References: <87d5vhiqsj.fsf@plato.moon.paoloamoroso.it>
Message-ID: <31ffd3c40502030810366be864@mail.gmail.com>

It currently doesn't understand EQL specializers, they're on the TODO
list. I think that the MOP doesn't make many promises about what an
EQL specializer really is, so at the time I wrote this I didn't bother
supporting them. I'm sure it can be fixed easily enough.


On Thu, 03 Feb 2005 16:53:00 +0100, Paolo Amoroso <amoroso at mclink.it> wrote:
> When I provide the name of the PRINT-OBJECT generic function as input
> to the method browser in Examples/method-browser.lisp, I get the error
> message with backtrace included below.  I use the latest McCLIM CVS
> sources with CMUCL Snapshot 2005-01 under Slackware Linux 10.0.
> 
> Paolo
> 
> ------------------------------------------------------------------------
> No matching method for the generic function
> #<STANDARD-GENERIC-FUNCTION CLASS-NAME (1) {281B2709}>, when called with
> arguments (#<PCL:EQL-SPECIALIZER {285532FD}>).
>    [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
> 
> Restarts:
>   0: [CONTINUE] Retry call to :FUNCTION.
>   1: [ABORT   ] Return to application command loop
>   2:            Return to Top-Level.
> 
> Debug  (type H for help)
> 
> ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
>  #<STANDARD-GENERIC-FUNCTION CLASS-NAME (1) {281B2709}>
>  (#<PCL:EQL-SPECIALIZER {285532FD}>))
> Source: Error finding source:
> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
>   target:pcl/braid.lisp.
> 0] backtrace
> 
> 0: ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
>     #<STANDARD-GENERIC-FUNCTION CLASS-NAME (1) {281B2709}>
>     (#<PCL:EQL-SPECIALIZER {285532FD}>))
> 1: ("DEFUN SORTED-GF-SPECIALIZERS" #<STANDARD-CLASS CLIM:OPACITY {283D4B55}>
>     #<PCL:EQL-SPECIALIZER {285532FD}>)
> 2: (LISP::MERGE-LISTS* #<unavailable-arg>
>                        #<unavailable-arg>
>                        #<Function "DEFUN SORTED-GF-SPECIALIZERS" {58F75D31}>
>                        NIL
>                        ...)
> 3: (LISP::SORT-LIST
>     (#<STANDARD-CLASS CLIM-CLX::CLX-PORT {282FEC85}>
>      #<STANDARD-CLASS CLIM-CLX::FONTSET {285FD915}>
>      #<STANDARD-CLASS CLIM:PANE {28322D0D}>
>      #<STANDARD-CLASS CLIM-INTERNALS::STANDARD-SPACE-REQUIREMENT {28343B4D}>
>      #<STANDARD-CLASS CLIM:COMMAND-TABLE {2838DC75}> ...)
>     #<Function "DEFUN SORTED-GF-SPECIALIZERS" {58F75D31}>
>     NIL)
> 4: (CLIM-DEMO::SORTED-GF-SPECIALIZERS
>     #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (47) {281B3739}>)
> 5: (CLIM-DEMO::COMPUTE-INITIAL-ARG-TYPES
>     #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (47) {281B3739}>)
> 6: (CLIM-DEMO::SETUP-NEW-GF #<CLIM-DEMO::METHOD-BROWSER {58428FFD}>
>                             #<STANDARD-GENERIC-FUNCTION PRINT-OBJECT (47)
>                               {281B3739}>)
> 7: (CLIM-INTERNALS::INVOKE-CALLBACK
>     #<CLIM:TEXT-FIELD-PANE CLIM-DEMO::GF-NAME-INPUT {58EF4FD5}>
>     CLIM-DEMO::GF-NAME-INPUT-CALLBACK)
> 8: ((METHOD CLIM:HANDLE-EVENT NIL (CLIM:TEXT-FIELD-PANE CLIM:KEY-PRESS-EVENT))
>     (#(64 67 22 21 64 ...) . #(#)) #<unused-arg>
>     #<CLIM:TEXT-FIELD-PANE CLIM-DEMO::GF-NAME-INPUT {58EF4FD5}>
>     #<CLIM:KEY-PRESS-EVENT {5892B97D}>)
> 9: (CLIM-INTERNALS::HANDLE-NON-STREAM-EVENT
>     #<CLIM-INTERNALS::PORT-EVENT-QUEUE {5849386D}>)
> 10: ((METHOD CLIM:STREAM-INPUT-WAIT NIL (CLIM:STANDARD-EXTENDED-INPUT-STREAM))
>      (#(18) . #(#)) #<unused-arg>
>      #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
>      (:TIMEOUT NIL :INPUT-WAIT-TEST
>       #<Function CLIM-INTERNALS::INPUT-CONTEXT-WAIT-TEST {1155B1F1}>))
> 11: ((METHOD CLIM:STREAM-READ-GESTURE NIL
>       (CLIM:STANDARD-EXTENDED-INPUT-STREAM))
>      (#(60) . #(#)) #<unused-arg>
>      #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
>      (:TIMEOUT NIL :PEEK-P NIL :INPUT-WAIT-TEST ...))
> 12: (CLIM:READ-COMMAND
>      #<CLIM:STANDARD-COMMAND-TABLE CLIM-DEMO::METHOD-BROWSER {58EDF55D}>
>      :STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
>      :COMMAND-PARSER ...)
> 13: (CLIM:READ-COMMAND-USING-KEYSTROKES
>      #<CLIM:STANDARD-COMMAND-TABLE CLIM-DEMO::METHOD-BROWSER {58EDF55D}>
>      NIL
>      :STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
>      ...)
> 14: (CLIM:READ-COMMAND
>      #<CLIM:STANDARD-COMMAND-TABLE CLIM-DEMO::METHOD-BROWSER {58EDF55D}>
>      :STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>
>      :COMMAND-PARSER ...)
> 15: ((METHOD CLIM:READ-FRAME-COMMAND (:AROUND) (CLIM:APPLICATION-FRAME))
>      (#(5) . #())
>      #S(PCL::FAST-METHOD-CALL
>           :FUNCTION #<Function # {11563581}>
>           :PV-CELL (# . #)
>           :NEXT-METHOD-CALL NIL
>           :ARG-INFO (1 . T))
>      #<CLIM-DEMO::METHOD-BROWSER {58428FFD}>
>      (:STREAM #<CLIM:APPLICATION-PANE CLIM-DEMO::OUTPUT-PANE {58EF43ED}>))
> 16: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
>      (#() . #(# # # # # ...)) #<unused-arg>
>      #<CLIM-DEMO::METHOD-BROWSER {58428FFD}> NIL)
> 17: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4227)" #<unused-arg> #<unused-arg>
>      #<CLIM-DEMO::METHOD-BROWSER {58428FFD}> NIL)
> 18: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
>      (#(20) . #()) #<unused-arg> #<CLIM-DEMO::METHOD-BROWSER {58428FFD}>
>      #<unused-arg>)
> 19: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME))
>      (#(16 15) . #(#))
>      #S(PCL::FAST-METHOD-CALL
>           :FUNCTION #<Function # {11686B49}>
>           :PV-CELL (# . #)
>           :NEXT-METHOD-CALL NIL
>           :ARG-INFO (1 . T))
>      #<CLIM-DEMO::METHOD-BROWSER {58428FFD}> NIL)
> 20: (INTERACTIVE-EVAL (CLIM-DEMO::RUN-TEST 'CLIM-DEMO::METHOD-BROWSER))
> 21: (LISP::%TOP-LEVEL)
> 22: ((LABELS LISP::RESTART-LISP
>        SAVE-LISP))
> 
> 0]
> ------------------------------------------------------------------------
> 
> --
> 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 strandh at labri.fr  Thu Feb  3 18:30:46 2005
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 3 Feb 2005 19:30:46 +0100
Subject: [mcclim-devel] write privileges to McCLIM for Peter Scott
Message-ID: <16898.28118.670979.467958@serveur5.labri.fr>

Hello,

Could you please give write priviles to the McCLIM CVS tree for Peter
Scott (who already has a common-lisp.net account with the name pscott)
so that he can commit changes to the CLIM inspector?

Thanks in advance, 
-- 
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 mmommer at common-lisp.net  Thu Feb  3 17:37:20 2005
From: mmommer at common-lisp.net (Mario Mommer)
Date: Thu, 03 Feb 2005 18:37:20 +0100
Subject: [mcclim-devel] Re: [admin] (no subject)
In-Reply-To: <16897.11210.638959.241770@serveur5.labri.fr>
References: <16897.11210.638959.241770@serveur5.labri.fr>
Message-ID: <fz1xbxtui7.fsf@germany.igpm.rwth-aachen.de>


Hi!

Robert Strandh <strandh at labri.fr> writes:
> Vincent Arkesteijn (<vincent at arkesteijn.net>) has agreed to take over
> the maintenance of the CLIM inspector (Clouseau).  For that reason, he
> will need write privileges to the McCLIM CVS tree. 

Ok, done.

Regards,
        Mario.



From pdm at zamazal.org  Thu Feb  3 20:53:32 2005
From: pdm at zamazal.org (Milan Zamazal)
Date: Thu, 03 Feb 2005 21:53:32 +0100
Subject: [mcclim-devel] Patch fixing the PNM image writing bug
Message-ID: <87zmylbc1f.fsf@blackbird.zamazal.org>

The following patch seems to fix the PNM image writing bug present when
using Unicode enabled SBCL:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.lisp.patch
Type: text/x-patch
Size: 3116 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050203/8a815f92/attachment.bin>

From mikemac at mikemac.com  Fri Feb  4 02:54:38 2005
From: mikemac at mikemac.com (mikemac at mikemac.com)
Date: Thu, 03 Feb 2005 20:54:38 -0600
Subject: [mcclim-devel] patch for fix-acl.lisp 
In-Reply-To: Your message of "Thu, 03 Feb 2005 09:40:01 CST."
	<16898.17873.115593.672958@gargle.gargle.HOWL> 
Message-ID: <200502040254.j142scJu013321@saturn.mikemac.com>


>To: "mcclim developers' list" <mcclim-devel at common-lisp.net>
>Date: Thu, 3 Feb 2005 09:40:01 -0600
>From: "Robert P. Goldman"
>
>
>--cTQmglwQu/
>Content-Type: text/plain; charset=us-ascii
>Content-Description: message body text
>Content-Transfer-Encoding: 7bit
>
>
>Will someone with privileges please apply the attached patch (I also
>attach the full lisp file, should that be easier) to
>Lisp-Dep/fix-acl.lisp?
>
>AFAICT, this should fix problems with defining the CLIM-MOP package
>for Allegro Common Lisp.
>
>I don't see any downside to applying this patch, since some canvassing
>reveals that I'm the only person who will admit to using McCLIM with
>Allegro CL, so I will only be hurting myself if there's anything
>wrong!  And I *might* be helping some future ACL user.

  Your "canvassing" wasn't very thurough.  But go ahead since it's
broken anyway.

  Mike McDonald
  mikemac at mikemac.com


From ajuckel at gmail.com  Fri Feb  4 15:15:05 2005
From: ajuckel at gmail.com (Anthony Juckel)
Date: Fri, 4 Feb 2005 09:15:05 -0600
Subject: [mcclim-devel] [Christophe Rhodes] [Sbcl-devel] PCL
	depessimization
In-Reply-To: <sqwttpk5pc.fsf@cam.ac.uk>
References: <sqwttpk5pc.fsf@cam.ac.uk>
Message-ID: <a45b92ac050204071557ff47f8@mail.gmail.com>

On Thu, 03 Feb 2005 15:45:35 +0000, Christophe Rhodes <csr21 at cam.ac.uk> wrote:
> Hi,
> 
> Tim Moore suggested that this might be of interest -- I'd certainly be
> interested in hearing reports from anyone who tries mcclim with sbcl
> and the attached patch.
> 

I tried Climacs out with this patch applied last night, and am very
happy to report that it worked as advertised.  In my prior testing of
Climacs, I found that the buffer display would lag quite noticably
behind my keystrokes, even at rather moderate typing speeds.  With
this patch applied to sbcl, the lag was extremely moderate.

More specifically, on my Athlon XP 1800+ (1.5 GHz), running Climacs on
the unpatched SBCL would result in delays of up to half a second when
typing rapidly.  On the other hand, once this patch was applied, the
lag became almost imperceptible, and in fact I may be imagining it.  I
haven't done any more extensive testing that simply compiling McCLIM
and Climacs, and editing, saving and loading a simple text file.  The
patch applied cleanly to HEAD (I didn't try applying it to 0.8.19..I'm
not sure if there would be a conflict), and I had no problems building
and no errors when running the application.

Good work, Christophe!

Anthony W. Juckel


From amoroso at mclink.it  Fri Feb  4 16:06:01 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 04 Feb 2005 17:06:01 +0100
Subject: [mcclim-devel] Clouseau-based inspector for Listener
Message-ID: <878y6471jq.fsf@plato.moon.paoloamoroso.it>

This 5 minutes hack adds to the CLIM Listener a new "Inspect" command
based on the Clouseau inspector:

(in-package :clim-listener)

(define-command (com-inspect :name "Inspect" :command-table lisp-commands :menu t)
    ((obj 'expression :prompt "expression"))
  (clouseau::inspector obj))

(define-gesture-name :inspect :pointer-button-press (:middle :control))

(define-presentation-to-command-translator com-inspect-translator
    (expression com-inspect lisp-commands
                :menu t
                :gesture :inspect
                :documentation ((object stream)
                                (format stream "Inspect ~S" object))
                :pointer-documentation "Inspect")
    (obj)
  (list obj))

The command works, but the translator sort of.

When I Ctrl-Middle-click on an object with expression presentation
type, or right-click and select the "Inspect" command, the Clouseau
frame does open, but it does not inspect the right object: it always
inspects nil, which is probably what com-inspect actually gets.  What
am I doing wrong?

I'm not sure the gesture I have chosen is the right one. but
Shift-Middle-click is already taken by copy and paste.  Any other
suggestions?

Also, is expression the right presentation type to hook this
functionality into in the first place?  Is the translator appropriate?

This tweak to clouseau::inspector makes it possible for the calling
frame to continue processing events, especially repaint ones:

(defun inspector (obj)
  (let ((*print-length* 10)
        (*print-level* 10))
    (run-frame-top-level
     (make-application-frame 'inspector :calling-frame *application-frame* :obj obj))))

Perhaps it may be worth changing clouseau::inspector so that it can
start a new thread in a way similar to clim-listener:run-listener.
This way it would be possible to open more than one inspector frame at
a time from the Listener.


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


From sketerpot at gmail.com  Fri Feb  4 16:11:00 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Fri, 4 Feb 2005 09:11:00 -0700
Subject: [mcclim-devel] Clouseau-based inspector for Listener
In-Reply-To: <878y6471jq.fsf@plato.moon.paoloamoroso.it>
References: <878y6471jq.fsf@plato.moon.paoloamoroso.it>
Message-ID: <7e267a92050204081168c870a0@mail.gmail.com>

On Fri, 04 Feb 2005 17:06:01 +0100, Paolo Amoroso <amoroso at mclink.it> wrote:
> (defun inspector (obj)
>   (let ((*print-length* 10)
>         (*print-level* 10))
>     (run-frame-top-level
>      (make-application-frame 'inspector :calling-frame *application-frame* :obj obj))))
> 
> Perhaps it may be worth changing clouseau::inspector so that it can
> start a new thread in a way similar to clim-listener:run-listener.
> This way it would be possible to open more than one inspector frame at
> a time from the Listener.

This sounds like a good idea, and I'll add a keyword argument to spawn
a new process later today. If you can't wait until tomorrow, this bit
of code should do the trick, albeit in a slightly ugly way, now and
forevermore:

(clim-sys:make-process #'(lambda () (inspector obj))
			   :name "Inspector Clouseau")

Where OBJ is the object you want to inspect.

-Peter


From amoroso at mclink.it  Fri Feb  4 16:29:16 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 04 Feb 2005 17:29:16 +0100
Subject: [mcclim-devel] Clouseau-based inspector for Listener
In-Reply-To: <7e267a92050204081168c870a0@mail.gmail.com> (Peter Scott's
	message of "Fri, 4 Feb 2005 09:11:00 -0700")
References: <878y6471jq.fsf@plato.moon.paoloamoroso.it>
	<7e267a92050204081168c870a0@mail.gmail.com>
Message-ID: <87y8e45lwj.fsf@plato.moon.paoloamoroso.it>

Peter Scott <sketerpot at gmail.com> writes:

> This sounds like a good idea, and I'll add a keyword argument to spawn
> a new process later today. If you can't wait until tomorrow, this bit
> of code should do the trick, albeit in a slightly ugly way, now and
> forevermore:
>
> (clim-sys:make-process #'(lambda () (inspector obj))
> 			   :name "Inspector Clouseau")

Maybe something like this, which makes the process name more
mp:all-processes friendly:

  ...
  :name (format nil "Inspector Clouseau: ~S" obj)
  ...

Take all the time you need, I'm not in a hurry.  Thanks,


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


From strandh at labri.fr  Sat Feb  5 04:59:46 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 5 Feb 2005 05:59:46 +0100
Subject: [mcclim-devel] Clouseau-based inspector for Listener
In-Reply-To: <7e267a92050204081168c870a0@mail.gmail.com>
References: <878y6471jq.fsf@plato.moon.paoloamoroso.it>
	<7e267a92050204081168c870a0@mail.gmail.com>
Message-ID: <16900.21186.67816.863300@serveur5.labri.fr>

Peter Scott writes:
 > On Fri, 04 Feb 2005 17:06:01 +0100, Paolo Amoroso <amoroso at mclink.it> wrote:
 > > (defun inspector (obj)
 > >   (let ((*print-length* 10)
 > >         (*print-level* 10))
 > >     (run-frame-top-level
 > >      (make-application-frame 'inspector :calling-frame *application-frame* :obj obj))))
 > > 
 > > Perhaps it may be worth changing clouseau::inspector so that it can
 > > start a new thread in a way similar to clim-listener:run-listener.
 > > This way it would be possible to open more than one inspector frame at
 > > a time from the Listener.
 > 
 > This sounds like a good idea, and I'll add a keyword argument to spawn
 > a new process later today. If you can't wait until tomorrow, this bit
 > of code should do the trick, albeit in a slightly ugly way, now and
 > forevermore:
 > 
 > (clim-sys:make-process #'(lambda () (inspector obj))
 > 			   :name "Inspector Clouseau")
 > 
 > Where OBJ is the object you want to inspect.

I thought that functionality was already in there.
-- 
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 amoroso at mclink.it  Sat Feb  5 09:52:36 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 05 Feb 2005 10:52:36 +0100
Subject: [mcclim-devel] Clouseau-based inspector for Listener
References: <878y6471jq.fsf@plato.moon.paoloamoroso.it>
	<7e267a92050204081168c870a0@mail.gmail.com>
	<16900.21186.67816.863300@serveur5.labri.fr>
Message-ID: <87is57e3kr.fsf@plato.moon.paoloamoroso.it>

Robert Strandh <strandh at labri.fr> writes:

> I thought that functionality was already in there.

You are indeed right, it's in clouseau::com-inspect.  But, if I
inderstand correctly, it takes its argument interactively.


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


From strandh at labri.fr  Sat Feb  5 09:58:05 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 5 Feb 2005 10:58:05 +0100
Subject: [mcclim-devel] Clouseau-based inspector for Listener
In-Reply-To: <87is57e3kr.fsf@plato.moon.paoloamoroso.it>
References: <878y6471jq.fsf@plato.moon.paoloamoroso.it>
	<7e267a92050204081168c870a0@mail.gmail.com>
	<16900.21186.67816.863300@serveur5.labri.fr>
	<87is57e3kr.fsf@plato.moon.paoloamoroso.it>
Message-ID: <16900.39085.3020.46823@serveur5.labri.fr>

Paolo Amoroso writes:
 > Robert Strandh <strandh at labri.fr> writes:
 > 
 > > I thought that functionality was already in there.
 > 
 > You are indeed right, it's in clouseau::com-inspect.  But, if I
 > inderstand correctly, it takes its argument interactively.

Anything presented should be clickable. 

-- 
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 sketerpot at gmail.com  Sat Feb  5 17:16:03 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Sat, 5 Feb 2005 10:16:03 -0700
Subject: [mcclim-devel] Clouseau-based inspector for Listener
In-Reply-To: <87is57e3kr.fsf@plato.moon.paoloamoroso.it>
References: <878y6471jq.fsf@plato.moon.paoloamoroso.it>
	<7e267a92050204081168c870a0@mail.gmail.com>
	<16900.21186.67816.863300@serveur5.labri.fr>
	<87is57e3kr.fsf@plato.moon.paoloamoroso.it>
Message-ID: <7e267a9205020509163f9fd63c@mail.gmail.com>

On Sat, 05 Feb 2005 10:52:36 +0100, Paolo Amoroso <amoroso at mclink.it> wrote:
> Robert Strandh <strandh at labri.fr> writes:
> 
> > I thought that functionality was already in there.
> 
> You are indeed right, it's in clouseau::com-inspect.  But, if I
> inderstand correctly, it takes its argument interactively.

Things have been shuffled around a bit; there's now a new keyword
argument to INSPECTOR, :new-process, which tells it to make a new
process, and clouseau::com-inspect uses that. This shouldn't require
changing any old code, and it's more consistant with the listener.

-Peter


From csr21 at cam.ac.uk  Tue Feb  8 12:46:32 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 08 Feb 2005 12:46:32 +0000
Subject: [mcclim-devel] A couple of inspector fixups
Message-ID: <sqr7jrjk2f.fsf@cam.ac.uk>

Hi,

The attached

* deals with unbound slots;
* defines a brief method for structure objects and conditions;
* defines a normal method for conditions;
* fixes the inspection of functions.

In addition, I think that the comment about slot definition readers
and writers is partially misleading -- I think that _does_ find
readers and writers for standard-{direct,effective}-slot-definitions.
It probably doesn't currently for structure-{d,e}-slot-definitions,
though.

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

Cheers,

Christophe

From vincent at arkesteijn.net  Tue Feb  8 22:14:54 2005
From: vincent at arkesteijn.net (Vincent Arkesteijn)
Date: Tue, 8 Feb 2005 23:14:54 +0100
Subject: [mcclim-devel] A couple of inspector fixups
In-Reply-To: <sqr7jrjk2f.fsf@cam.ac.uk>
References: <sqr7jrjk2f.fsf@cam.ac.uk>
Message-ID: <20050208221454.GA27244@vja.demon.nl>

Hi,

On Tue, Feb 08, 2005 at 12:46:32PM +0000, Christophe Rhodes wrote:
> The attached
> 
> * deals with unbound slots;
> * defines a brief method for structure objects and conditions;
> * defines a normal method for conditions;
> * fixes the inspection of functions.

Thanks! I see Peter has already committed this.

> In addition, I think that the comment about slot definition readers
> and writers is partially misleading -- I think that _does_ find
> readers and writers for standard-{direct,effective}-slot-definitions.
> It probably doesn't currently for structure-{d,e}-slot-definitions,
> though.

Well, it appears to work for standard-direct-slot-definitions, but not
for standard-effective-slot-definitions. Which doesn't violate the mop.

Knowing this, I've managed to make com-describe-slot work. Thanks for
drawing attention to it.

Vincent.


From csr21 at cam.ac.uk  Wed Feb  9 09:47:47 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 09 Feb 2005 09:47:47 +0000
Subject: [mcclim-devel] selections
Message-ID: <sqzmye3vzw.fsf@cam.ac.uk>

Hi,

Am I right in thinking that there are at least some problems still
outstanding with X select-and-paste?  If so, people affected may be
interested to try changing the implementation of BIND-SELECTION in
Backends/CLX/port.lisp to 
  (defmethod bind-selection ((port clx-port) window &optional time)
    (xlib:set-selection-owner
     (xlib:window-display (sheet-direct-mirror window))
     :primary (sheet-direct-mirror window) time))
where the new bit is passing TIME down to XLIB:SET-SELECTION-OWNER.

The CLX manual has this to say about it:

   NOTE: Standard conventions for inter-client communication require
   that a non-nil time must be specified. If possible, the time should
   be the time of a user event which initiated the change of
   ownership. Alternatively, a timestamp can be obtained by calling
   change-property to append zero-length data to some property; the
   timestamp in the resulting :property-notify event can then be used.

I have no idea why, nor indeed whether this will fix any open
problems.

Cheers,

Christophe



From csr21 at cam.ac.uk  Wed Feb  9 10:15:20 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 09 Feb 2005 10:15:20 +0000
Subject: [mcclim-devel] X window manager focus
Message-ID: <sqoeeu3upz.fsf@cam.ac.uk>

Hi,

Relatedly to my last message, I believe that there is another ICCCM
compliance issue in the CLX backend: this one is probably related to
window manager focus glitches.  Given a focus-follows-mouse setup, the
following occurs when I mouse into a McCLIM window:

  0: (CLIM-CLX::PORT-CLIENT-MESSAGE
      #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE CLIM-INTERNALS::TOP-LEVEL-SHEET {1000671781}>
      NIL :WM_PROTOCOLS #(230 2313329802 7859248 7859248 2313329802))
    1: (CLIM-CLX::PORT-WM-PROTOCOLS-MESSAGE
        #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE CLIM-INTERNALS::TOP-LEVEL-SHEET {1000671781}>
        NIL :WM_TAKE_FOCUS #(230 2313329802 7859248 7859248 2313329802))
    1: CLIM-CLX::PORT-WM-PROTOCOLS-MESSAGE returned NIL
  0: CLIM-CLX::PORT-CLIENT-MESSAGE returned NIL

where again the relevant part is that the timestamp passed down is NIL.

ICCCM has this to say (section 4.1.7):

  Clients that use a SetInputFocus request must set the time field to
  the timestamp of the event that caused them to make the
  attempt. This cannot be a FocusIn event because they do not have
  timestamps. Clients may also acquire the focus without a
  corresponding EnterNotify. Note that clients must not use
  CurrentTime in the time field.

so the call to XLIB:SET-INPUT-FOCUS in the PORT-WM-PROTOCOLS-MESSAGE
for :WM_TAKE_FOCUS (Backends/CLX/port.lisp) is doomed, at the moment,
to violate ICCCM.  However, if I'm reading this right, the
WM_TAKE_FOCUS client message has the timestamp we want to pass to
SET-INPUT-FOCUS in its data field somewhere:

  Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property
  may receive a ClientMessage event from the window manager (as
  described in section 4.2.8) with WM_TAKE_FOCUS in its data[0] field
  and a valid timestamp (i.e. not CurrentTime) in its data[1]
  field. If they want the focus, they should respond with a
  SetInputFocus request with its window field set to the window of
  theirs that last had the input focus or to their default input
  window, and the time field set to the timestamp in the message. For
  further information, see section 4.2.7.

and indeed (elt data 1) in the above trace seems to be a valid
timestamp.

Am I on the right track, do people think?

Cheers,

Christophe


From csr21 at cam.ac.uk  Wed Feb  9 10:22:37 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 09 Feb 2005 10:22:37 +0000
Subject: [mcclim-devel] X window manager focus
In-Reply-To: <sqoeeu3upz.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Wed, 09 Feb 2005 10:15:20 +0000")
References: <sqoeeu3upz.fsf@cam.ac.uk>
Message-ID: <sqk6pi3udu.fsf@cam.ac.uk>

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

> Relatedly to my last message, I believe that there is another ICCCM
> compliance issue in the CLX backend: this one is probably related to
> window manager focus glitches.  Given a focus-follows-mouse setup, the
> following occurs when I mouse into a McCLIM window:

For related reading, see
<http://mail.gnome.org/archives/gtk-list/1998-April/msg00274.html>
(woohoo, we're only 7 years behind the gtk people! ;-)

Cheers,

Christophe


From csr21 at cam.ac.uk  Wed Feb  9 11:25:08 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 09 Feb 2005 11:25:08 +0000
Subject: [mcclim-devel] X window manager focus
In-Reply-To: <sqoeeu3upz.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Wed, 09 Feb 2005 10:15:20 +0000")
References: <sqoeeu3upz.fsf@cam.ac.uk>
Message-ID: <sqfz063rhn.fsf@cam.ac.uk>

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

> Am I on the right track, do people think?

So that we're all on the same page, I attach a diff which, I think

* makes BIND-SELECTION ICCCM compliant;
* makes the handling of WM_TAKE_FOCUS ICCCM compliant;
* alters BIND-SELECTION so that it returns true if the selection
  acquisition succeeded and false if it fails, and uses this in
  text-selections.lisp.

This seems to work for me at least as well as it did before.  If
people are either satisfied by my reading of ICCCM or someone else
reports that it solves a problem for them, please apply it.

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

Cheers,

Christophe

From nyef at sc.am  Fri Feb 11 16:43:48 2005
From: nyef at sc.am (Nyef)
Date: Fri, 11 Feb 2005 11:43:48 -0500
Subject: [mcclim-devel] CLX clear-area breakage
Message-ID: <20050211164348.GA31298@sc.am>

Hello all.

medium-clear-area in Backends/CLX/medium.lisp isn't doing a transform 
from medium to device coordinates, nor is it clipping the coordinates to 
the limits allowed by CLX. This causes window-clear on streams with 
more than about 2800 lines (maybe less!) to break. Attached is a patch 
which should fix this.

-- 
--Alastair Bridgewater
-------------- next part --------------
Index: medium.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Backends/CLX/medium.lisp,v
retrieving revision 1.65
diff -u -r1.65 medium.lisp
--- medium.lisp	18 Jan 2005 13:35:26 -0000	1.65
+++ medium.lisp	11 Feb 2005 16:35:29 -0000
@@ -965,13 +965,19 @@
   (xlib:display-force-output (clx-port-display (port medium))))
 
 (defmethod medium-clear-area ((medium clx-medium) left top right bottom)
-  (let ((min-x (round-coordinate (min left right)))
-	(min-y (round-coordinate (min top bottom)))
-	(max-x (round-coordinate (max left right)))
-	(max-y (round-coordinate (max top bottom))))
-    (xlib:clear-area (port-lookup-mirror (port medium) (medium-sheet medium))
-		     :x min-x :y min-y
-		     :width (- max-x min-x) :height (- max-y min-y))))
+  (let ((tr (sheet-native-transformation (medium-sheet medium))))
+    (with-transformed-position (tr left top)
+      (with-transformed-position (tr right bottom)
+	(let ((min-x (round-coordinate (min left right)))
+	      (min-y (round-coordinate (min top bottom)))
+	      (max-x (round-coordinate (max left right)))
+	      (max-y (round-coordinate (max top bottom))))
+	  (xlib:clear-area (port-lookup-mirror (port medium)
+					       (medium-sheet medium))
+			   :x (max #x-8000 (min #x7fff min-x))
+			   :y (max #x-8000 (min #x7fff min-y))
+			   :width (max 0 (min #xffff (- max-x min-x)))
+			   :height (max 0 (min #xffff (- max-y min-y)))))))))
 
 (defmethod medium-beep ((medium clx-medium))
   (xlib:bell (clx-port-display (port medium))))

From amoroso at mclink.it  Mon Feb 14 14:52:22 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 14 Feb 2005 14:52:22 +0000
Subject: [mcclim-devel] Missing CLIMI::Y2 slot error when selecting text for
	copying
Message-ID: <87vf8v6vo9.fsf@plato.moon.paoloamoroso.it>

When I run the CLIM Listener, evaluate (princ "Paolo"),
Shift-left-button drag to select the previously output `Paolo' string
for copying, and then release the shift key, I get the error with
backtrace included below.  I use the latest McCLIM CVS sources
(rebuilt from source after deleting old fasl files) with CMUCL
Snapshot 2005-02 under Slackware Linux 10.0.


Paolo

----------------------------------------------------------------------
Error in function "DEFMETHOD SLOT-MISSING (T T T T)":
   When attempting to read the slot's value (slot-value), the slot
   CLIM-INTERNALS::Y2 is missing from the object
   #<CLIM-INTERNALS::STANDARD-TEXT-DISPLAYED-OUTPUT-RECORD

   0,17 ("Paolo")

   {582664A5}>.
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [RESTART-EVENT-LOOP] Restart CLIM's event loop.
  1: [DESTROY           ] Destroy the process

Debug  (type H for help)

("DEFMETHOD SLOT-MISSING (T T T T)" #<unused-arg> #<unused-arg> #<unused-arg>
 #<CLIM-INTERNALS::STANDARD-TEXT-DISPLAYED-OUTPUT-RECORD 0,17 ("Paolo")
   {582664A5}>
 ...)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:pcl/slots.lisp.
0] backtrace

0: ("DEFMETHOD SLOT-MISSING (T T T T)" #<unused-arg> #<unused-arg>
    #<unused-arg>
    #<CLIM-INTERNALS::STANDARD-TEXT-DISPLAYED-OUTPUT-RECORD 0,17 ("Paolo")
      {582664A5}>
    ...)
1: (SLOT-VALUE
    #<CLIM-INTERNALS::STANDARD-TEXT-DISPLAYED-OUTPUT-RECORD 0,17 ("Paolo")
      {582664A5}>
    CLIM-INTERNALS::Y2)
2: ("DEFUN FETCH-SELECTION" #<CLIM-INTERNALS::STRING-MARKING {58974585}>)
3: (MAP NIL
        #<Closure Over Function "DEFUN FETCH-SELECTION" {58A00559}>
        (#<CLIM-INTERNALS::STRING-MARKING {58974585}>))
4: (CLIM-INTERNALS::FETCH-SELECTION
    #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58F362B5}>)
5: ((METHOD CLIM:DISPATCH-EVENT (:AROUND)
     (CLIM-INTERNALS::CUT-AND-PASTE-MIXIN
      CLIM-BACKEND:SELECTION-REQUEST-EVENT))
    #<unused-arg> #<unused-arg>
    #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58F362B5}>
    #<CLIM-CLX::CLX-SELECTION-REQUEST-EVENT {58A0000D}>)
6: ((METHOD CLIM:PROCESS-NEXT-EVENT NIL (CLIM:BASIC-PORT)) (#() . #(#))
    #<unused-arg> #<CLIM-CLX::CLX-PORT :HOST "" :DISPLAY-ID 0 {5810715D}> NIL)
7: ("DEFMETHOD INITIALIZE-CLX (CLX-PORT)")
8: ("DEFUN MAKE-PROCESS")

0]
----------------------------------------------------------------------

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


From amoroso at mclink.it  Mon Feb 14 14:41:39 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 14 Feb 2005 14:41:39 +0000
Subject: [mcclim-devel] No presentation type error for
 STANDARD-GENERIC-FUNCTION when running inspector example
Message-ID: <873bvz8aqk.fsf@plato.moon.paoloamoroso.it>

When I run this sample inspector form:

  (clouseau:inspector #'documentation)

from the Clouseau documentation in Apps/Inspector/INSTALL, I get the
error and backtrace included below.  I use the latest McCLIM CVS
sources (rebuilt from source after deleting old fasl files) with CMUCL
Snapshot 2005-02 under Slackware Linux 10.0.


Paolo

-------------------------------------------------------------------------
Error in function CLIM-INTERNALS::PROTOTYPE-OR-ERROR:
   STANDARD-GENERIC-FUNCTION is an unknown presentation type
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [ABORT] Return to application command loop
  1:         Return to Top-Level.

Debug  (type H for help)

(CLIM-INTERNALS::PROTOTYPE-OR-ERROR STANDARD-GENERIC-FUNCTION)
Source:
; File: /home/paolo/src/mcclim/presentations.lisp
(ERROR "~S is an unknown presentation type" NAME)
0] backtrace

0: (CLIM-INTERNALS::PROTOTYPE-OR-ERROR STANDARD-GENERIC-FUNCTION)
1: (CLIM-INTERNALS::PRESENTATION-CONTAINS-POSITION
    #<CLIM:STANDARD-PRESENTATION 0.0:400,0.0:365.0 STANDARD-GENERIC-FUNCTION
      {58242285}>
    367
    296)
2: (CLIM-INTERNALS::MAP-OVER-PRESENTATIONS-CONTAINING-POSITION
    #<Closure Over Function "DEFUN MAP-APPLICABLE-TRANSLATORS" {58727589}>
    #<CLIM:STANDARD-PRESENTATION 0.0:400,0.0:365.0 STANDARD-GENERIC-FUNCTION
      {58242285}>
    367
    296)
3: ((METHOD CLIM:MAP-OVER-OUTPUT-RECORDS-CONTAINING-POSITION NIL
     (T CLIM:STANDARD-SEQUENCE-OUTPUT-RECORD T T))
    (#(6) . #()) #<unused-arg>
    #<Closure Over Function "DEFUN MAP-OVER-PRESENTATIONS-CONTAINING-POSITION"
      {587275C1}>
    #<CLIM:STANDARD-TREE-OUTPUT-HISTORY X 0.0:400 Y 0.0:365.0 {5816BCED}> ...)
4: (CLIM-INTERNALS::MAP-OVER-PRESENTATIONS-CONTAINING-POSITION
    #<Closure Over Function "DEFUN MAP-APPLICABLE-TRANSLATORS" {58727589}>
    #<CLIM:STANDARD-TREE-OUTPUT-HISTORY X 0.0:400 Y 0.0:365.0 {5816BCED}>
    367
    296)
5: (CLIM-INTERNALS::MAP-APPLICABLE-TRANSLATORS
    #<Closure Over Function "DEFUN FIND-INNERMOST-PRESENTATION-MATCH"
      {58727559}>
    #<CLIM:STANDARD-TREE-OUTPUT-HISTORY X 0.0:400 Y 0.0:365.0 {5816BCED}>
    ((# . #) (# . #) (CLIM:MENU-ITEM . #))
    #<CLOUSEAU:INSPECTOR {58EEFEF5}>
    ...)
6: (CLIM-INTERNALS::FIND-INNERMOST-PRESENTATION-MATCH
    ((# . #) (# . #) (CLIM:MENU-ITEM . #))
    #<CLIM:STANDARD-TREE-OUTPUT-HISTORY X 0.0:400 Y 0.0:365.0 {5816BCED}>
    #<CLOUSEAU:INSPECTOR {58EEFEF5}>
    #<CLIM:APPLICATION-PANE CLOUSEAU::APP {581199FD}>
    ...)
7: (CLIM:FIND-INNERMOST-APPLICABLE-PRESENTATION
    ((# . #) (# . #) (CLIM:MENU-ITEM . #))
    #<CLIM:APPLICATION-PANE CLOUSEAU::APP {581199FD}>
    367
    296
    ...)
8: (CLIM-INTERNALS::FRAME-HIGHLIGHT-AT-POSITION
    #<CLOUSEAU:INSPECTOR {58EEFEF5}>
    #<CLIM:APPLICATION-PANE CLOUSEAU::APP {581199FD}>
    367
    296
    ...)
9: ((METHOD CLIM-INTERNALS::FRAME-INPUT-CONTEXT-TRACK-POINTER (:BEFORE)
     (CLIM:STANDARD-APPLICATION-FRAME T CLIM:OUTPUT-RECORDING-STREAM T))
    #<unused-arg> #<unused-arg> #<CLOUSEAU:INSPECTOR {58EEFEF5}>
    ((# . #) (# . #) (CLIM:MENU-ITEM . #)) ...)
10: ("LAMBDA (G4238 G4239 G4240)" #<unused-arg> #<unused-arg>
     #<CLOUSEAU:INSPECTOR {58EEFEF5}> ((# . #) (# . #) (CLIM:MENU-ITEM . #))
     ...)
11: (CLIM:HIGHLIGHT-APPLICABLE-PRESENTATION #<CLOUSEAU:INSPECTOR {58EEFEF5}>
                                            #<CLIM:INTERACTOR-PANE
                                              CLOUSEAU::INT {5800378D}>
                                            ((# . #) (# . #)
                                             (CLIM:MENU-ITEM . #))
                                            T)
12: ((METHOD CLIM:STREAM-READ-GESTURE NIL
      (CLIM:STANDARD-EXTENDED-INPUT-STREAM))
     (#(60) . #(#)) #<unused-arg>
     #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>
     (:TIMEOUT NIL :INPUT-WAIT-TEST
      #<Function CLIM-INTERNALS::INPUT-CONTEXT-WAIT-TEST {1155E391}>
      :INPUT-WAIT-HANDLER ...))
13: ((METHOD CLIM:STREAM-READ-GESTURE NIL (CLIM:STANDARD-INPUT-EDITING-STREAM))
     (#(3 4 7 5 0 ...) . #()) #<unused-arg>
     #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>
     (:TIMEOUT NIL :PEEK-P NIL :INPUT-WAIT-TEST ...))
14: ((METHOD CLIM:STREAM-READ-GESTURE (:AROUND)
      (CLIM-INTERNALS::EMPTY-INPUT-MIXIN))
     #<unused-arg>
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {1142FC09}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL
                                 :FUNCTION #
                                 :PV-CELL #
                                 :NEXT-METHOD-CALL NIL
                                 :ARG-INFO #)
          :ARG-INFO (1 . T))
     #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>
     (:TIMEOUT NIL :PEEK-P NIL :INPUT-WAIT-TEST ...))
15: (CLIM-INTERNALS::READ-COMPLETION-GESTURE
     #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>
     (#\ )
     T)
16: (CLIM:COMPLETE-INPUT #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>
                         #<Closure Over Function "DEFINE-PRESENTATION-METHOD ACCEPT"
                           {58606E29}>
                         :PARTIAL-COMPLETERS (#\ )
                         ...)
17: ((METHOD CLIM-INTERNALS::%ACCEPT NIL
      (CLIM-INTERNALS::|(presentation-type CLIM::COMMAND-NAME)| T T
       CLIM:TEXTUAL-VIEW))
     #<unused-arg> #<unused-arg>
     #<CLIM-INTERNALS::|(presentation-type CLIM::COMMAND-NAME)| {28430CF5}>
     (CLIM:COMMAND-NAME
      :COMMAND-TABLE #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR
                       {58C75FAD}>)
     ...)
18: ("DEFUN ACCEPT-1" #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>)
19: (CLIM:ACCEPT
     (CLIM:COMMAND-NAME
      :COMMAND-TABLE #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR
                       {58C75FAD}>)
     :STREAM #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>
     :PROMPT ...)
20: (CLIM:COMMAND-LINE-COMMAND-PARSER
     #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR {58C75FAD}>
     #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>)
21: ((METHOD CLIM-INTERNALS::%ACCEPT NIL
      (CLIM-INTERNALS::|(presentation-type CLIM::COMMAND)| T T
       CLIM:TEXTUAL-VIEW))
     #<unused-arg> #<unused-arg>
     #<CLIM-INTERNALS::|(presentation-type CLIM::COMMAND)| {28430995}>
     (CLIM:COMMAND :COMMAND-TABLE
      #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR {58C75FAD}>)
     ...)
22: ("DEFUN ACCEPT-1" #<CLIM:STANDARD-INPUT-EDITING-STREAM {58604CED}>)
23: ((METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING NIL
      (CLIM:EXTENDED-INPUT-STREAM T T T T))
     #<unused-arg> #<unused-arg>
     #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>
     #<Closure Over Function "DEFUN ACCEPT-1" {586047F9}> ...)
24: ((METHOD CLIM-INTERNALS::INVOKE-WITH-INPUT-EDITING (:AROUND)
      (CLIM:EXTENDED-OUTPUT-STREAM T T T T))
     (#(49) . #())
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {11539EC1}>
          :PV-CELL NIL
          :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL
                                 :FUNCTION #
                                 :PV-CELL NIL
                                 :NEXT-METHOD-CALL NIL
                                 :ARG-INFO #)
          :ARG-INFO (5))
     #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>
     #<Closure Over Function "DEFUN ACCEPT-1" {586047F9}> ...)
25: (CLIM:ACCEPT
     (CLIM:COMMAND :COMMAND-TABLE
      #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR {58C75FAD}>)
     :STREAM #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>
     :PROMPT ...)
26: (CLIM:READ-COMMAND
     #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR {58C75FAD}>
     :STREAM #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>
     :COMMAND-PARSER ...)
27: (CLIM:READ-COMMAND-USING-KEYSTROKES
     #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR {58C75FAD}>
     NIL
     :STREAM #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>
     ...)
28: (CLIM:READ-COMMAND
     #<CLIM:STANDARD-COMMAND-TABLE CLOUSEAU:INSPECTOR {58C75FAD}>
     :STREAM #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>
     :COMMAND-PARSER ...)
29: ((METHOD CLIM:READ-FRAME-COMMAND (:AROUND) (CLIM:APPLICATION-FRAME))
     (#(5) . #())
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {11566721}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL NIL
          :ARG-INFO (1 . T))
     #<CLOUSEAU:INSPECTOR {58EEFEF5}>
     (:STREAM #<CLIM:INTERACTOR-PANE CLOUSEAU::INT {5800378D}>))
30: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#() . #(# # # # # ...)) #<unused-arg> #<CLOUSEAU:INSPECTOR {58EEFEF5}>
     NIL)
31: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4230)" #<unused-arg> #<unused-arg>
     #<CLOUSEAU:INSPECTOR {58EEFEF5}> NIL)
32: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#(20) . #()) #<unused-arg> #<CLOUSEAU:INSPECTOR {58EEFEF5}> #<unused-arg>)
33: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME))
     (#(16 15) . #(#))
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {116898C1}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL NIL
          :ARG-INFO (1 . T))
     #<CLOUSEAU:INSPECTOR {58EEFEF5}> NIL)
34: ((FLET CLOUSEAU::RUN
       CLOUSEAU:INSPECTOR))
35: (INTERACTIVE-EVAL (CLOUSEAU:INSPECTOR #'DOCUMENTATION))
36: (LISP::%TOP-LEVEL)
37: ((LABELS LISP::RESTART-LISP
       SAVE-LISP))

0]
-------------------------------------------------------------------------

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


From csr21 at cam.ac.uk  Mon Feb 14 16:27:33 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 14 Feb 2005 16:27:33 +0000
Subject: [mcclim-devel] Missing CLIMI::Y2 slot error when selecting text
	for copying
In-Reply-To: <87vf8v6vo9.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's
	message of "Mon, 14 Feb 2005 14:52:22 +0000")
References: <87vf8v6vo9.fsf@plato.moon.paoloamoroso.it>
Message-ID: <sqmzu75cp6.fsf@cam.ac.uk>

Paolo Amoroso <amoroso at mclink.it> writes:

> When I run the CLIM Listener, evaluate (princ "Paolo"),
> Shift-left-button drag to select the previously output `Paolo' string
> for copying, and then release the shift key, I get the error with
> backtrace included below.  I use the latest McCLIM CVS sources
> (rebuilt from source after deleting old fasl files) with CMUCL
> Snapshot 2005-02 under Slackware Linux 10.0.

Thanks.  This should be fixed now.

Cheers,

Christophe


From csr21 at cam.ac.uk  Mon Feb 14 17:04:56 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 14 Feb 2005 17:04:56 +0000
Subject: [mcclim-devel] draw-circle*
Message-ID: <sqis4v5ayv.fsf@cam.ac.uk>

Hi,

Am I confused, or is something wrong?

At the CLIM listener,
  (clim:draw-circle* *standard-output* 100 100 100)
draws a big black circle at the top left of the pane.  However,
  (clim:with-room-for-graphics (*standard-output*)
    (clim:draw-circle* *standard-output* 100 100 100))
leaves enough space for a circle, but doesn't actually draw anything
visible.  However,
  (clim:with-room-for-graphics (*standard-output*)
    (clim:draw-line* *standard-output* 0 0 100 100))
behaves much as I expect.

Help?

Cheers,

Christophe


From asf at boinkor.net  Mon Feb 14 20:37:26 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 14 Feb 2005 21:37:26 +0100
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
Message-ID: <87vf8ukhdl.wl%asf@boinkor.net>

Hi all,

I'd like to use my new-found McCLIM committer powers to push a new
release of McCLIM out the door.

This is the schedule that Xophe came up with on #lisp a few days ago
(augmented with real dates):

 * Freeze McCLIM proper on 2005-02-21
 * Freeze Apps/ and Examples/ on 2005-02-28
 * Release on 2005-03-06

If that isn't messing with anybody's plans, I'd like to stick to that
schedule and upload a nice official tarball in the end. (-:

If this release goes well, we could try a bi-monthly release schedule
based on that - hack a 6 weeks, freeze two (or just one) weeks,
release. Evidence from the mcclim-cvs list archive of the last few
months suggests that this could provide usable snapshots of a steadily
progressing McCLIM.

Happy hacking,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From rpgoldman at real-time.com  Mon Feb 14 20:52:43 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Mon, 14 Feb 2005 14:52:43 -0600
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <87vf8ukhdl.wl%asf@boinkor.net>
References: <87vf8ukhdl.wl%asf@boinkor.net>
Message-ID: <16913.3995.121204.904516@gargle.gargle.HOWL>


With that in mind, would anyone who knows the architecture of the
whole McCLIM megalith be willing to put up suggestions for testing?

I seem to be about the only person using McCLIM on Allegro.  I'd be
willing to do some testing in advance of the release, but I need some
coaching!

Best,
R


From strandh at labri.fr  Tue Feb 15 05:45:56 2005
From: strandh at labri.fr (Robert Strandh)
Date: Tue, 15 Feb 2005 06:45:56 +0100
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <87vf8ukhdl.wl%asf@boinkor.net>
References: <87vf8ukhdl.wl%asf@boinkor.net>
Message-ID: <16913.35988.254324.57532@serveur5.labri.fr>

Hello Andreas, 

Personally, I am all for it. 
-- 
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 moore at bricoworks.com  Tue Feb 15 09:41:10 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Tue, 15 Feb 2005 10:41:10 +0100
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <87vf8ukhdl.wl%asf@boinkor.net>
References: <87vf8ukhdl.wl%asf@boinkor.net>
Message-ID: <2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>

On Feb 14, 2005, at 9:37 PM, Andreas Fuchs wrote:

> Hi all,
>
> I'd like to use my new-found McCLIM committer powers to push a new
> release of McCLIM out the door.
>
> This is the schedule that Xophe came up with on #lisp a few days ago
> (augmented with real dates):
>
>  * Freeze McCLIM proper on 2005-02-21
>  * Freeze Apps/ and Examples/ on 2005-02-28
>  * Release on 2005-03-06
>
Yes, this is a great idea. Of course there's some major features I'd 
like to get in before a release :), but that's the whole point of the 
time-boxed release schedule proposed here.
Here are my priorities for an imminent release. Only two of these are 
personal tasks of mine, hint hint  :

Make sure McCLIM works well, out of the box, with climacs. I don't 
think that will be too hard -- we should be there -- but climacs is 
clearly the major client of McCLIM now; climacs users should be able to 
install and use McCLIM without problems.

Fix bugs that  have turned up in accepting-values and updating-output. 
I hope to have this fixed up today or tomorrow.

Look at Paolo's bug list and see if there's any low-hanging fruit. One 
bug that is not low-hanging but that is extremely embarrassing is 
numbers-pane-layout-specifiers. Every new user tries an example that 
specifies the relative sizes of panes using ratios and then wonders why 
it doesn't work. I've looked at this problem before, wandered deep into 
the frame layout code, got lost and abandoned, but I would really like 
to have this bug fixed before a release.

Someone should look at the Beagle backend, make sure that it can build 
and pop something up. Documenting what's missing would be good too.

It would be *fabulous* if the Freetype support was useable in CMUCL and 
SBCL (and OpenMCL too, for I understand that its alien stuff is not too 
different from the others) with a minimum of user intervention. Does 
anyone want to take that on?

For Apps and Examples:
  there may be examples that are so old that they should be banished, 
even if they do work.

Some integration of the Inspector and the Listener would be nice.

For the release:
Some work on the documentation would be nice. I'm planning to write a 
chapter on "Writing a CLIM application" that would be good to include. 
A comprehensive list of what's missing or broken would be very useful; 
I think we can do this with respect to the Franz User's Guide as that 
would be more helpful the spec for existing CLIM users. Going 
function-by-function through the guide and listing differences in the 
McCLIM manual would be very useful, but is probably too much work 
before this release. That would be a great project if someone wants to 
take it on.

asdf-install enabled! I'd be comfortable dumping support for 
mk:defsystem -- or any defsystem -- if that would help get things into 
shape for asdf.


> If that isn't messing with anybody's plans, I'd like to stick to that
> schedule and upload a nice official tarball in the end. (-:
>
> If this release goes well, we could try a bi-monthly release schedule
> based on that - hack a 6 weeks, freeze two (or just one) weeks,
> release. Evidence from the mcclim-cvs list archive of the last few
> months suggests that this could provide usable snapshots of a steadily
> progressing McCLIM.
>
Yes yes yes :)

Tim



From csr21 at cam.ac.uk  Tue Feb 15 10:44:34 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Tue, 15 Feb 2005 10:44:34 +0000
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com> (Timothy
	Moore's message of "Tue, 15 Feb 2005 10:41:10 +0100")
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
Message-ID: <sqpsz2cdbh.fsf@cam.ac.uk>

Timothy Moore <moore at bricoworks.com> writes:

> Make sure McCLIM works well, out of the box, with climacs. I don't
> think that will be too hard -- we should be there -- but climacs is
> clearly the major client of McCLIM now; climacs users should be able
> to install and use McCLIM without problems.

I think climacs is possibly the closest thing to an application with
potential users that's in the "public domain", so to speak, but let's
not discount the possibility that there are some silent people working
on their own apps :-)

If I could be indulged in suggesting one or two relatively cosmetic
fixes: one is the bouncing pointer documentation pane in the listener
when mousing over a multiline (or simply long) form; another,
well... am I allowed to mention the word "scrollbars"?  My particular
case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a
lot of grey at the bottom of a scrolled area where real output ought
to be.  (I'm afraid I don't even understand how this can happen, but
I'll try to characterize it better if this is a new bug for anyone).

Cheers,

Christophe


From jdz at dir.lv  Tue Feb 15 12:53:34 2005
From: jdz at dir.lv (Janis Dzerins)
Date: Tue, 15 Feb 2005 14:53:34 +0200
Subject: [mcclim-devel] Statement of intent: release McCLIM on
	Mothering Sunday (2005-03-06)
In-Reply-To: <sqpsz2cdbh.fsf@cam.ac.uk>
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
	<sqpsz2cdbh.fsf@cam.ac.uk>
Message-ID: <1108472014.7967.18.camel@localhost>

On Tue, 2005-02-15 at 10:44 +0000, Christophe Rhodes wrote:
> Timothy Moore <moore at bricoworks.com> writes:
> 
> > Make sure McCLIM works well, out of the box, with climacs. I don't
> > think that will be too hard -- we should be there -- but climacs is
> > clearly the major client of McCLIM now; climacs users should be able
> > to install and use McCLIM without problems.
> 
> I think climacs is possibly the closest thing to an application with
> potential users that's in the "public domain", so to speak, but let's
> not discount the possibility that there are some silent people working
> on their own apps :-)

What's so funny? :)  I have this game I'm working on, which is in an
almost-done state (screenshot available at <URL:
http://www.ltn.lv/~jonis/wapi.png >).  There are a few things I'd like
to add before I release it, but I think it will happen before the next
release of McCLIM.  It will be public domain, as the Clones game.

(And I can't wait till we have some application which uses the McCLIM's
GLX backend (I have a few ideas))!

-- 
Janis Dzerins

  If million people say a stupid thing, it's still a stupid thing.




From amoroso at mclink.it  Tue Feb 15 17:28:14 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 15 Feb 2005 17:28:14 +0000
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com> (Timothy
	Moore's message of "Tue, 15 Feb 2005 10:41:10 +0100")
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
Message-ID: <87fyzxivgx.fsf@plato.moon.paoloamoroso.it>

Timothy Moore <moore at bricoworks.com> writes:

> On Feb 14, 2005, at 9:37 PM, Andreas Fuchs wrote:
[...]
>> I'd like to use my new-found McCLIM committer powers to push a new
>> release of McCLIM out the door.
[...]
> Yes, this is a great idea. Of course there's some major features I'd

I second that.


> Look at Paolo's bug list and see if there's any low-hanging fruit. One

May I suggest this one?

  Package lock errors when compiling/loading with CMUCL 19 or later
  http://mcclim.cliki.net/Bug#listener-cmucl-package-lock


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


From amoroso at mclink.it  Tue Feb 15 17:40:58 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 15 Feb 2005 17:40:58 +0000
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<16913.3995.121204.904516@gargle.gargle.HOWL>
Message-ID: <87y8dphgb9.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> With that in mind, would anyone who knows the architecture of the
> whole McCLIM megalith be willing to put up suggestions for testing?

I don't know even a fraction of the architecture :)  That said,
although I have my own code, I catch most of the bugs by simply
running the applications and demos included with McCLIM, particularly
the CLIM Listener.

You may try running these programs and executing a few commands.  Here
is a command that shakes the listener a bit (requires a fast
machine...)

  Show Class Subclasses (class) t  

Before reporting a bug, you may want to double check by rebuilding
McCLIM from scratch after deleting old fasl files.


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


From amoroso at mclink.it  Tue Feb 15 21:26:55 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Tue, 15 Feb 2005 21:26:55 +0000
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com> (Timothy
	Moore's message of "Tue, 15 Feb 2005 10:41:10 +0100")
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
Message-ID: <87mzu5wm3k.fsf@plato.moon.paoloamoroso.it>

Timothy Moore <moore at bricoworks.com> writes:

> include. A comprehensive list of what's missing or broken would be
> very useful; I think we can do this with respect to the Franz User's

In this Oct 16, 2004 blog entry:

  McCLIM changes and development status
  http://www.paoloamoroso.it/log/041016.html

I provided a very rough estimate.  With the same code, I now get 66
unimplemented symbols out of a total of 1920 symbols in the CLIM
package.  Back in October 2005, the figures were 69 and 1918
respectively.


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


From sketerpot at gmail.com  Tue Feb 15 20:23:34 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Tue, 15 Feb 2005 13:23:34 -0700
Subject: [mcclim-devel] No presentation type error for
	STANDARD-GENERIC-FUNCTION when running inspector example
In-Reply-To: <873bvz8aqk.fsf@plato.moon.paoloamoroso.it>
References: <873bvz8aqk.fsf@plato.moon.paoloamoroso.it>
Message-ID: <7e267a92050215122339619157@mail.gmail.com>

This ugly quick fix might help:

;; Ugly and weird, and written without much understanding of the
;; real issues that it fixes. Beware.
(defmethod clim:presentation-type-of ((object standard-generic-function))
    'clim:expression)

I don't know why CMUCL is saying that (clim:presentation-type-of
#'documentation) is STANDARD-GENERIC-FUNCTION, which doesn't seem to
be defined as a presentation type. It doesn't happen for me on SBCL.
Perhaps a more CMUCL-knowledgable person could weigh in?

-Peter


From pw at snoopy.mv.com  Tue Feb 15 20:54:42 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Tue, 15 Feb 2005 15:54:42 -0500
Subject: [mcclim-devel] No presentation type error
	forSTANDARD-GENERIC-FUNCTION when running inspector example
References: <873bvz8aqk.fsf@plato.moon.paoloamoroso.it>
	<7e267a92050215122339619157@mail.gmail.com>
Message-ID: <001101c513a0$93057270$0201a8c0@moby>

| 
| ;; Ugly and weird, and written without much understanding of the
| ;; real issues that it fixes. Beware.
| (defmethod clim:presentation-type-of ((object standard-generic-function))
|     'clim:expression)
| 
| I don't know why CMUCL is saying that (clim:presentation-type-of
| #'documentation) is STANDARD-GENERIC-FUNCTION, which doesn't seem to
| be defined as a presentation type. It doesn't happen for me on SBCL.
| Perhaps a more CMUCL-knowledgable person could weigh in?

FWIW, LWW CLIM also returns STANDARD-GENERIC-FUNCTION.
Are not all CLOS classes presentation-types by default?

Paul




From jdz at dir.lv  Tue Feb 15 22:12:33 2005
From: jdz at dir.lv (Janis Dzerins)
Date: Wed, 16 Feb 2005 00:12:33 +0200
Subject: [mcclim-devel] Statement of intent: release McCLIM on
	Mothering Sunday (2005-03-06)
In-Reply-To: <87mzu5wm3k.fsf@plato.moon.paoloamoroso.it>
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
	<87mzu5wm3k.fsf@plato.moon.paoloamoroso.it>
Message-ID: <1108505553.12981.1.camel@localhost>

On Tue, 2005-02-15 at 21:26 +0000, Paolo Amoroso wrote:
> Timothy Moore <moore at bricoworks.com> writes:
> 
> I provided a very rough estimate.  With the same code, I now get 66
> unimplemented symbols out of a total of 1920 symbols in the CLIM
> package.  Back in October 2005, the figures were 69 and 1918
> respectively.

A bit of regress it seems, but don't you accidentally have taken any
screenshots back from the future? :)

-- 
Janis Dzerins

  If million people say a stupid thing, it's still a stupid thing.




From ahefner at gmail.com  Tue Feb 15 22:17:06 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Tue, 15 Feb 2005 17:17:06 -0500
Subject: [mcclim-devel] No presentation type error
	forSTANDARD-GENERIC-FUNCTION when running inspector example
In-Reply-To: <001101c513a0$93057270$0201a8c0@moby>
References: <873bvz8aqk.fsf@plato.moon.paoloamoroso.it>
	<7e267a92050215122339619157@mail.gmail.com>
	<001101c513a0$93057270$0201a8c0@moby>
Message-ID: <31ffd3c405021514171630f056@mail.gmail.com>

They are indeed. I think this is retarded, personally, but that's what
the spec says..


On Tue, 15 Feb 2005 15:54:42 -0500, Paul Werkowski <pw at snoopy.mv.com> wrote:

> FWIW, LWW CLIM also returns STANDARD-GENERIC-FUNCTION.
> Are not all CLOS classes presentation-types by default?
> 
> Paul


From csr21 at cam.ac.uk  Wed Feb 16 11:38:55 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 16 Feb 2005 11:38:55 +0000
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <sqpsz2cdbh.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Tue, 15 Feb 2005 10:44:34 +0000")
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
	<sqpsz2cdbh.fsf@cam.ac.uk>
Message-ID: <sqwtt8ybsg.fsf@cam.ac.uk>

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

> am I allowed to mention the word "scrollbars"?  My particular
> case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a
> lot of grey at the bottom of a scrolled area where real output ought
> to be.

Just in case anyone is confused over what I mean here, a screenshot
demonstrating the problem is at
<http://www-jcsu.jesus.cam.ac.uk/~csr21/mcclim-scroll-problem.png>.
This screenshot was obtained by, in SBCL
  (mapcar #'require '(:asdf :clx :clim-clx-user :clouseau))
  (clouseau:inspector (find-package "CL"))
and scrolling down.

Cheers,

Christophe



From csr21 at cam.ac.uk  Wed Feb 16 11:22:55 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 16 Feb 2005 11:22:55 +0000
Subject: [mcclim-devel] Re: image:write-pnm doesn't work with SBCL 0.8.17
In-Reply-To: <200412101611.iBAGBIxZ016351@saturn.mikemac.com> (Milan
	Zamazal's message of "Fri, 10 Dec 2004 10:11:18 -0600")
References: <200412101611.iBAGBIxZ016351@saturn.mikemac.com>
Message-ID: <sqr7jgybiy.fsf@cam.ac.uk>

Milan Zamazal <pdm at zamazal.org> writes:

> Image writing in Backends/CLX/image.lisp breaks with SBCL 0.8.17.  The
> output streams there are character streams, so if the environment is a
> UTF-8 environment for instance, then the output stream is recoded and
> the resulting image is broken.

Can you try the attached?

I haven't altered the cut-and-paste code in Backend/Beagle/; anyone
who cares should probably see if the code is identical and if so
refactor.  In addition, someone who cares about pnm might want to make
read-image-file and write-image-file or write-pnm logical inverses of
each other -- I haven't tested the attached at all beyond compiling it
because I have no idea how it should be used.  Maybe if someone who
uses it attempts to document it, it will make more sense?

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

Cheers,

Christophe

From amoroso at mclink.it  Wed Feb 16 17:34:05 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 16 Feb 2005 18:34:05 +0100
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <sqwtt8ybsg.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Wed, 16 Feb 2005 11:38:55 +0000")
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
	<sqpsz2cdbh.fsf@cam.ac.uk> <sqwtt8ybsg.fsf@cam.ac.uk>
Message-ID: <87hdkcl88i.fsf@plato.moon.paoloamoroso.it>

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

> Christophe Rhodes <csr21 at cam.ac.uk> writes:
>
>> am I allowed to mention the word "scrollbars"?  My particular
>> case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a
>> lot of grey at the bottom of a scrolled area where real output ought
>> to be.
>
> Just in case anyone is confused over what I mean here, a screenshot
> demonstrating the problem is at
> <http://www-jcsu.jesus.cam.ac.uk/~csr21/mcclim-scroll-problem.png>.

Yes, I'm familiar with this problem and confirm it.


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


From sketerpot at gmail.com  Wed Feb 16 17:52:24 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Wed, 16 Feb 2005 10:52:24 -0700
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <sqpsz2cdbh.fsf@cam.ac.uk>
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
	<sqpsz2cdbh.fsf@cam.ac.uk>
Message-ID: <7e267a9205021609523269d8df@mail.gmail.com>

On Tue, 15 Feb 2005 10:44:34 +0000, Christophe Rhodes <csr21 at cam.ac.uk> wrote:
> am I allowed to mention the word "scrollbars"?  My particular
> case is that sometimes, in sb-sprof-ui or in my tabcode app, I see a
> lot of grey at the bottom of a scrolled area where real output ought
> to be.  (I'm afraid I don't even understand how this can happen, but
> I'll try to characterize it better if this is a new bug for anyone).

Here's something you might try for a possibly increased understanding
of the scrollbar bug: in the inspector, inspect something particularly
long and scroll down until you see the gray. Then click on a blank
area of the white part of the window. This issues the command "Toggle
Inspect NIL" (doesn't do anything; a minor bug) and it often makes the
gray bug go away. This code might also have something to do with the
inspector's version of the bug (but I don't really know what's going
on, so it might not):

(defmethod redisplay-frame-pane :after ((frame inspector)
					(pane application-pane)
					&key force-p)
  (declare (ignore force-p))
  (change-space-requirements
   pane
   :height (bounding-rectangle-height (stream-output-history pane))))

This has something to do with the scrolling, but I'm not sure exactly what.

-Peter


From asf at boinkor.net  Wed Feb 16 20:48:44 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Wed, 16 Feb 2005 21:48:44 +0100
Subject: [mcclim-devel] Statement of intent: release McCLIM on Mothering
	Sunday (2005-03-06)
In-Reply-To: <2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
References: <87vf8ukhdl.wl%asf@boinkor.net>
	<2705338f05c469d1a3a8593d4de8fa5e@bricoworks.com>
Message-ID: <87oeekjknn.wl%asf@boinkor.net>

On 2005-02-15, Timothy Moore <moore at bricoworks.com> wrote:
[reordered for temporal consistency]
> asdf-install enabled! I'd be comfortable dumping support for
> mk:defsystem -- or any defsystem -- if that would help get things
> into shape for asdf.

Done! I just committed mcclim.asd to the tree. That should make every
tar ball made from mcclim ASDF-INSTALLable now. I'll provide a summary
of the changes (especially for authors of ASDF-enabled packages that
depend on mcclim) soon.

> It would be *fabulous* if the Freetype support was useable in CMUCL
> and SBCL (and OpenMCL too, for I understand that its alien stuff is
> not too different from the others) with a minimum of user
> intervention. Does anyone want to take that on?

I'll look into that next. There are some strange forward-references
that shouldn't be happening in the code that Brian Mastenbrook ported
to SBCL.

>> If this release goes well, we could try a bi-monthly release
>> schedule based on that - hack a 6 weeks, freeze two (or just one)
>> weeks, release. Evidence from the mcclim-cvs list archive of the
>> last few months suggests that this could provide usable snapshots
>> of a steadily progressing McCLIM.
>>
> Yes yes yes :)

(-:

Have fun,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From asf at boinkor.net  Wed Feb 16 21:10:22 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Wed, 16 Feb 2005 22:10:22 +0100
Subject: [mcclim-devel] Install instructions for mcclim.asd
Message-ID: <87mzu4jjnl.wl%asf@boinkor.net>

Hi,

(this will probably morph into some form of INSTALL file, hopefully
before the release happens. Feedback appreciated (-:)

Installing McCLIM using mcclim.asd
==================================

To tell ASDF about the wherabouts of McCLIM and to compile it for the
first time, perform these steps:

 1. Symlink mcclim.asd to a directory in your
    asdf:*central-repository* list. E.g., for SBCL, that would be:

      $ ln -sf /path/to/mcclim.asd ~/.sbcl/systems/

 2. If you are using a Lisp implementation that requires a separate
    CLX to be installed, do this now and symlink the clx's .asd file
    to your asdf:*central-repository*, as above.

 3. On your Lisp's REPL (with ASDF loaded), type

     (asdf:oos 'asdf:load-op :mcclim)
     ; compilation messages should zip past

After step 3, McCLIM and a suitable backend should be loaded and
you are good to go.

When you restart your lisp image, you will need to perform step 3 to
load McCLIM again.

Installing mcclim.asd if you were using ASDF & system.lisp before
=================================================================

Make sure to remove all symlinks in your asdf:*central-repository* to
system.lisp and replace them with symlinks to mcclim.asd. Keeping the
old links around will break loading the McCLIM system in subtle ways.

After replacing the symlinks, follow the "Installing McCLIM..."
section above, beginning at step 1 - the symlink mcclim.asd itself is
required, too.

Writing a system that depends on McCLIM
=======================================

In an ASDF system that depends on a loaded CLIM, use the following
code to declare a dependency on McCLIM:

(defsystem :your-clim-using-system
           :depends-on (:mcclim #| other dependencies |#)
           :components (#| components |#)
           )

The dependency on the McCLIM system will also load a suitable display
backend on implementations where it can determine one.



Have fun,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From ajuckel at gmail.com  Thu Feb 17 03:12:37 2005
From: ajuckel at gmail.com (Anthony Juckel)
Date: Wed, 16 Feb 2005 21:12:37 -0600
Subject: [mcclim-devel] Patch for gadgets.lisp
Message-ID: <a45b92ac0502161912d736d66@mail.gmail.com>

Attached is a simple patch to fix a problem I was having with
gadget-output-record after the recent change in standard-rectangle
from individual slots to a coordinates slot.

Anthony W. Juckel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gadgets.patch
Type: text/x-patch
Size: 321 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050216/8ec52b40/attachment.bin>

From ajuckel at gmail.com  Thu Feb 17 03:30:58 2005
From: ajuckel at gmail.com (Anthony Juckel)
Date: Wed, 16 Feb 2005 21:30:58 -0600
Subject: [mcclim-devel] Gadgets within accepting-values
Message-ID: <a45b92ac050216193043af25aa@mail.gmail.com>

Along the same lines as my previous email, I'm having trouble getting
a gadget to display within an accepting-values dialog.  Apparently the
problem arises because setup-gadget-record is being called on the
accepting-values-stream, and the first thing setup-gadget-record wants
to do is set the height of the accepting-values-stream sheet. 
Unfortunately, accepting-values stream has no height slot.  I'm still
rather unclear about the internal workings of accepting-values, so I'm
not brave enough to offer a solution, but I thought I could at least
notify the  list of the problem.

Anthony W. Juckel

Full disclosure:
McCLIM was checked out and recompiled (after removing old fasls) this evening.

  0: ((SB-PCL::FAST-METHOD SLOT-MISSING (T T T T)) #<unavailable
argument> #<unavailable argument> #<unavailable argument>
#<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {90B1EC1}>
CLIM-INTERNALS::HEIGHT SLOT-VALUE NIL)
  1: ("XEP for (SB-PCL::FAST-METHOD SLOT-MISSING (T T T ...))" 7
#<unavailable argument> #<unavailable argument> #<unavailable
argument> #<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {90B1EC1}>
CLIM-INTERNALS::HEIGHT SLOT-VALUE NIL)[:EXTERNAL]
  2: (SLOT-VALUE #<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {90B1EC1}>
CLIM-INTERNALS::HEIGHT)
  3: (CLIM-INTERNALS::SETUP-GADGET-RECORD
#<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {90B1EC1}>
#<CLIM:GADGET-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 {90B5AC9}> 0
0)
  4: ("FLET #:ACCEPTING-VALUES-CONTINUATION0"
#<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {90B1EC1}>)
  5: ("FLET #:UPDATING-OUTPUT-CONTINUATION415" #<CLIM:APPLICATION-PANE
NET.JUCKEL.EXALTED.CLIM::INSPECTOR {A722651}>)
  6: ((SB-PCL::FAST-METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD
(CLIM:OUTPUT-RECORDING-STREAM T T T)) #<unavailable argument>
#<unavailable argument> #<CLIM:APPLICATION-PANE
NET.JUCKEL.EXALTED.CLIM::INSPECTOR {A722651}> #<FUNCTION "CLOSURE"
{90B3FFD}> #<unavailable argument> #<FUNCTION "FLET #:CONSTRUCTOR1076"
{26F203D}> NIL)
  7: (CLIM-INTERNALS::%INVOKE-UPDATING
#<CLIM-INTERNALS::ACCEPTING-VALUES-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 
1 {90B32A1}> #<CLIM:APPLICATION-PANE
NET.JUCKEL.EXALTED.CLIM::INSPECTOR {A722651}> #<FUNCTION "CLOSURE"
{90B1F45}>)
  8: ("FLET #:CONTINUATION2071" #<CLIM:APPLICATION-PANE
NET.JUCKEL.EXALTED.CLIM::INSPECTOR {A722651}>
#<CLIM-INTERNALS::ACCEPTING-VALUES-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 
1 {90B32A1}>)
  9: ((SB-PCL::FAST-METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD
(CLIM:OUTPUT-RECORDING-STREAM T T T)) #<unavailable argument>
#<unavailable argument> #<CLIM:APPLICATION-PANE
NET.JUCKEL.EXALTED.CLIM::INSPECTOR {A722651}> #<FUNCTION "CLOSURE"
{90B2755}> #<unavailable argument> #<FUNCTION "CLOSURE" {90B2725}>
(:UNIQUE-ID 1 :ID-TEST #<FUNCTION "top level local call EQL"
{1076E65}> :CACHE-VALUE CLIM-INTERNALS::NO-CACHE-VALUE :CACHE-TEST
#<FUNCTION CLIM-INTERNALS::FORCE-UPDATE-CACHE-TEST> :FIXED-POSITION
NIL ...))
 10: ((SB-PCL::FAST-METHOD CLIM:INVOKE-UPDATING-OUTPUT
(CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN T T T T T T))
#<unavailable argument> #<unavailable argument>
#<CLIM:APPLICATION-PANE NET.JUCKEL.EXALTED.CLIM::INSPECTOR {A722651}>
#<FUNCTION "CLOSURE" {90B1F45}>
CLIM-INTERNALS::ACCEPTING-VALUES-RECORD (NIL) #<FUNCTION "top level
local call EQL" {1076E65}> CLIM-INTERNALS::NO-CACHE-VALUE #<FUNCTION
CLIM-INTERNALS::FORCE-UPDATE-CACHE-TEST> NIL)
 11: ("varargs entry for CLIM-INTERNALS::INVOKE-ACCEPTING-VALUES"
#<CLIM:APPLICATION-PANE NET.JUCKEL.EXALTED.CLIM::INSPECTOR {A722651}>
#<FUNCTION "CLOSURE" {9010C15}> :OWN-WINDOW #<unused argument>
:EXIT-BOXES #<unused argument> :INITIALLY-SELECT-QUERY-IDENTIFIER NIL
:MODIFY-INITIAL-QUERY #<unused argument> :RESYNCHRONIZE-EVERY-PASS NIL
:RESIZE-FRAME #<unused argument> :ALIGN-PROMPTS NIL :LABEL #<unused
argument> :SCROLL-BARS #<unused argument> :X-POSITION #<unused
argument> :Y-POSITION #<unused argument> :WIDTH #<unused argument>
:HEIGHT #<unused argument> :COMMAND-TABLE CLIM:ACCEPTING-VALUES
:FRAME-CLASS #<unused argument>)
 12: ((SB-PCL::FAST-METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL
(CLIM:APPLICATION-FRAME)) #<unavailable argument> #<unavailable
argument> #<NET.JUCKEL.EXALTED.CLIM::EXALTED-CLIM {9EEE7D1}> NIL)
 13: ("XEP for (SB-PCL::FAST-METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL
(CLIM:APPLICATION-FRAME))" 4 #<unavailable argument> #<unavailable
argument> #<NET.JUCKEL.EXALTED.CLIM::EXALTED-CLIM {9EEE7D1}>
NIL)[:EXTERNAL]
 14: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL
(CLIM:APPLICATION-FRAME)) #<unavailable argument> #<unavailable
argument> #<NET.JUCKEL.EXALTED.CLIM::EXALTED-CLIM {9EEE7D1}>
#<unavailable argument>)
 15: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND
(CLIM:APPLICATION-FRAME)) #<unavailable argument>
#S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD
CLIM:RUN-FRAME-TOP-LEVEL #) {26DFF05}> :PV-CELL NIL :NEXT-METHOD-CALL
NIL :ARG-INFO (1 . T)) #<NET.JUCKEL.EXALTED.CLIM::EXALTED-CLIM
{9EEE7D1}> NIL)
 16: ("LABELS CLIM-INTERNALS::BOING")
 17: ("#'(LAMBDA NIL (LET # # ...) ...)")
 18: ("foreign function: call_into_lisp")
 19: ("foreign function: funcall0")


From chandler at unmutual.info  Thu Feb 17 14:05:53 2005
From: chandler at unmutual.info (Brian Mastenbrook)
Date: Thu, 17 Feb 2005 08:05:53 -0600
Subject: [mcclim-devel] MORE ALIENS (or Freetype on SBCL)
Message-ID: <baa972593337ff8e22312355d5797b3d@unmutual.info>

A little bit ago I tried looking into Freetype on SBCL. I got to the 
point where after some random amount of fooling around with recompiling 
forms from SLIME, it works - but not by default; it appears to either 
have some invisible problems with alien struct circularity, or I'm just 
being boneheaded about something. The latest tarball of my progress is 
here:

http://www.unmutual.info/software/freetype.tar.gz

To use this, remove Experimental/freetype from your McCLIM tree and 
replace it with the result of untarring this. The mcclim-freetype.asd 
system should load everything, but compilation of freetype-fonts.lisp 
will fail due to alien type problems.

Your mission, should you choose to accept it, is to figure out why SBCL 
doesn't understand that the alien type face is more than just (struct 
face-rec-); it must have slots as well. Good luck!
--
Brian Mastenbrook
bmastenb at cs.indiana.edu
http://cs.indiana.edu/~bmastenb/



From amoroso at mclink.it  Thu Feb 17 14:36:41 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 17 Feb 2005 15:36:41 +0100
Subject: [mcclim-devel] Gadgets within accepting-values
In-Reply-To: <a45b92ac050216193043af25aa@mail.gmail.com> (Anthony Juckel's
	message of "Wed, 16 Feb 2005 21:30:58 -0600")
References: <a45b92ac050216193043af25aa@mail.gmail.com>
Message-ID: <87acq3fe2u.fsf@plato.moon.paoloamoroso.it>

Anthony Juckel <ajuckel at gmail.com> writes:

> Along the same lines as my previous email, I'm having trouble getting
> a gadget to display within an accepting-values dialog.  Apparently the

Can you please add an entry here?

  http://mcclim.cliki.net/Bug


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


From pdm at zamazal.org  Fri Feb 18 10:05:22 2005
From: pdm at zamazal.org (Milan Zamazal)
Date: Fri, 18 Feb 2005 11:05:22 +0100
Subject: [mcclim-devel] Re: image:write-pnm doesn't work with SBCL 0.8.17
In-Reply-To: <sqr7jgybiy.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Wed, 16 Feb 2005 11:22:55 +0000")
References: <200412101611.iBAGBIxZ016351@saturn.mikemac.com>
	<sqr7jgybiy.fsf@cam.ac.uk>
Message-ID: <87zmy22nfh.fsf@blackbird.zamazal.org>

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

    CR> Can you try the attached?

Thanks, except for a few typos it seems to work.  Here's a fixed version
of the patch:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pnm-fixed.diff
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050218/03ac5f39/attachment.ksh>
-------------- next part --------------

    CR> Maybe if someone who uses it attempts to document it, it will
    CR> make more sense?

Well, I attempted to add documentation strings to the objects I use.
Here's an additional patch to the previous one:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pnm-doc.diff
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050218/03ac5f39/attachment-0001.ksh>
-------------- next part --------------

Regards,

Milan Zamazal

-- 
I think any law that restricts independent use of brainpower is suspect.
                                               -- Kent Pitman in comp.lang.lisp

From csr21 at cam.ac.uk  Fri Feb 18 13:54:58 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Fri, 18 Feb 2005 13:54:58 +0000
Subject: [mcclim-devel] Yet another bug for the bug list
Message-ID: <sqvf8qrn0t.fsf@cam.ac.uk>

Hi,

I'm sure most of you know this already, but windows opened by
OPEN-WINDOW-STREAM are not automatically closed when their parent is
closed, even if they share the same event queue -- and once the parent
is gone it is then impossible to close them short of destroying the
port.

(This has UI implications in my climacs/tabcode app.)

Cheers,

Christophe


From amoroso at mclink.it  Fri Feb 18 14:33:13 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 18 Feb 2005 15:33:13 +0100
Subject: [mcclim-devel] Yet another bug for the bug list
In-Reply-To: <sqvf8qrn0t.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Fri, 18 Feb 2005 13:54:58 +0000")
References: <sqvf8qrn0t.fsf@cam.ac.uk>
Message-ID: <87acq2szti.fsf@plato.moon.paoloamoroso.it>

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

> I'm sure most of you know this already, but windows opened by
> OPEN-WINDOW-STREAM are not automatically closed when their parent is
> closed, even if they share the same event queue -- and once the parent

Could you please add an entry here?

  http://mcclim.cliki.net/Bug

It's not that I'm lazy and I don't want to do it myself (I'll gladly
do it if you can't).  It's just that I'm trying to spread the voice
about the above unofficially official bug list.


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


From strandh at labri.fr  Sat Feb 19 08:27:41 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 19 Feb 2005 09:27:41 +0100
Subject: [mcclim-devel] problems with the implementation of the layout
	protocol
Message-ID: <16918.63613.498798.240109@serveur5.labri.fr>

Hello everyone,

As far as I can tell, there are two major problems with the current
implementation of the layout protocol:

  * First, compose-space and change-space-requirements have :before,
    :after, or :around methods that are essential for the
    implementation to work.  The consequences of this way of doing it
    (it seems to me) is that client code that wishes to change the
    default behavior or override it in subclasses of standard CLIM
    layout panes cannot do so without being aware of the existence of
    these methods. 

  * Second, change-space-requirements always calls itself on the
    parent pane.  However, the definition of the restraining-pane is
    that it should stop propagation of change-space-requirement.
    After discussions with Andy Hefner, we conclude that
    change-space-requirement should call
    note-space-requirement-changed, which in turn calls
    change-space-requirement on its parent, unless overridden. 

These points make it hard to implement the restraining pane, which is
probably why it is not implemented, even though it ought to be fairly
easy. 

-- 
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  Sat Feb 19 11:30:48 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sat, 19 Feb 2005 11:30:48 +0000
Subject: [mcclim-devel] Yet another bug for the bug list
In-Reply-To: <87acq2szti.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's
	message of "Fri, 18 Feb 2005 15:33:13 +0100")
References: <sqvf8qrn0t.fsf@cam.ac.uk>
	<87acq2szti.fsf@plato.moon.paoloamoroso.it>
Message-ID: <sqd5uwss5z.fsf@cam.ac.uk>

Paolo Amoroso <amoroso at mclink.it> writes:

> Christophe Rhodes <csr21 at cam.ac.uk> writes:
>
>> I'm sure most of you know this already, but windows opened by
>> OPEN-WINDOW-STREAM are not automatically closed when their parent is
>> closed, even if they share the same event queue -- and once the parent
>
> Could you please add an entry here?
>
>   http://mcclim.cliki.net/Bug
>
> It's not that I'm lazy and I don't want to do it myself (I'll gladly
> do it if you can't).  It's just that I'm trying to spread the voice
> about the above unofficially official bug list.

Yeah.  I understand what you're trying to do here -- but I'm uncertain
that it's the best use of resources...

The issue I have is that I've used a raw cliki-based bug tracking
system before -- entomotomy -- and while it was by no means an
unmitigated disaster, I think it would be fair to say that for those
who had the most interaction with it, it was more work than it needed
to be.

What I would like to see is something which can be driven by e-mail,
much like debbugs, working maybe from header information, maybe from
stuff in the body.  So when a bug report like mine arrives, someone In
Charge of Bugs forwards the mail on to mcclim-bug at common-lisp.net,
say, with a few commands in the new body:

  open open-window-stream-windows-not-closed-by-parent
  submitter csr21 at cam.ac.uk
  thanks

and then the body of the original message, or even just a message-id,
if the system would be smart enough to convert that to a URL to the
mcclim-devel archives.  Closing a bug should likewise be done by
e-mail; discussion can be done over the mailing list, with any
particularly pertinent messages likewise forwarded to the magical bug
system (with command "addto" or something).

I suppose what I'm getting at is that I've interacted with bug
trackers that are so much better in terms of convenience than an HTML
textarea that I'm pretty unwilling to spend my time with a vanilla
cliki on something which shouldn't interfere with my workflow.  (Don't
feel too bad about this, though, because I have the same visceral
hatred of both the Sourceforge bug tracker and bugzilla-based systems
-- in all cases, they are /way/ too much work for the end-user to
submit bugs, and quite often they are also too much work for the
administrator).

So if you don't mind, I'll pass on vanilla cliki interactions for
things like this; on the other hand, if people want to collaborate on
something which talks to a cliki given e-mail input, then I'm willing
at least to share ideas and maybe even get down and dirty.

Cheers,

Christophe


From amoroso at mclink.it  Sat Feb 19 14:16:36 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 19 Feb 2005 15:16:36 +0100
Subject: [mcclim-devel] Yet another bug for the bug list
References: <sqvf8qrn0t.fsf@cam.ac.uk>
	<87acq2szti.fsf@plato.moon.paoloamoroso.it> <sqd5uwss5z.fsf@cam.ac.uk>
Message-ID: <874qg8ocsb.fsf@plato.moon.paoloamoroso.it>

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

> I suppose what I'm getting at is that I've interacted with bug
> trackers that are so much better in terms of convenience than an HTML
> textarea that I'm pretty unwilling to spend my time with a vanilla
> cliki on something which shouldn't interfere with my workflow.  (Don't
> feel too bad about this, though, because I have the same visceral

I don't feel bad at all, I actually do appreciate your feedback.
That's the kind of feedback I wished I got when I created the bug list
page at McCLIM CLiki.

Given limited resources, I thought that a CLiki-based bug list might
have been an acceptable tradeoff between hunting for bug reports in
the mailing list archive, and setting up some more formal and/or
convenient bug tracking system.

Any comments from the McCLIM developers?  What should be done with the
bug list page at McCLIM CLiki?  Shall we drop it?


> hatred of both the Sourceforge bug tracker and bugzilla-based systems
> -- in all cases, they are /way/ too much work for the end-user to
> submit bugs, and quite often they are also too much work for the
> administrator).

You should probably check the simple bug reporting procedures and
systems that Aunt Tillie uses for reporting bugs of her favorite
office suite and web browser, i.e. OpenOffice and Firefox :)

  Firefox Help: Reporting Bugs
  http://www.mozilla.org/support/firefox/bugs

  qa: Bugs&Issues Explained (OpenOffice.org)
  http://qa.openoffice.org/issue_handling/project_issues.html


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


From mikemac at mikemac.com  Sun Feb 20 00:50:17 2005
From: mikemac at mikemac.com (mikemac at mikemac.com)
Date: Sat, 19 Feb 2005 18:50:17 -0600
Subject: [mcclim-devel] Yet another bug for the bug list 
In-Reply-To: Your message of "Sat, 19 Feb 2005 15:16:36 +0100."
	<874qg8ocsb.fsf@plato.moon.paoloamoroso.it> 
Message-ID: <200502200050.j1K0oH08014361@saturn.mikemac.com>


>To: mcclim-devel at common-lisp.net
>Date: Sat, 19 Feb 2005 15:16:36 +0100
>From: Paolo Amoroso
>
>Christophe Rhodes <csr21 at cam.ac.uk> writes:
>
>> I suppose what I'm getting at is that I've interacted with bug
>> trackers that are so much better in terms of convenience than an HTML
>> textarea that I'm pretty unwilling to spend my time with a vanilla
>> cliki on something which shouldn't interfere with my workflow.  (Don't
>> feel too bad about this, though, because I have the same visceral

>Any comments from the McCLIM developers?  What should be done with the
>bug list page at McCLIM CLiki?  Shall we drop it?

  How about a CLIM based front end that sumbits a properly formatted
bug report to an Email address? Might make an interesting first app
for someone wanting to learn CLIM but who also wants to contribute
something useful.

  Mike McDonald
  mikemac at mikemac.com


From csr21 at cam.ac.uk  Mon Feb 21 13:27:34 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 21 Feb 2005 13:27:34 +0000
Subject: [mcclim-devel] Re: image:write-pnm doesn't work with SBCL 0.8.17
In-Reply-To: <87zmy22nfh.fsf@blackbird.zamazal.org> (Milan Zamazal's message
	of "Fri, 18 Feb 2005 11:05:22 +0100")
References: <200412101611.iBAGBIxZ016351@saturn.mikemac.com>
	<sqr7jgybiy.fsf@cam.ac.uk> <87zmy22nfh.fsf@blackbird.zamazal.org>
Message-ID: <sqis4m3uwp.fsf@cam.ac.uk>

Milan Zamazal <pdm at zamazal.org> writes:

>>>>>> "CR" == Christophe Rhodes <csr21 at cam.ac.uk> writes:
>
>     CR> Can you try the attached?
>
> Thanks, except for a few typos it seems to work.  Here's a fixed version
> of the patch:

Thanks, I committed your fixed version.

Cheers,

Christophe


From asf at boinkor.net  Mon Feb 21 18:10:50 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 21 Feb 2005 19:10:50 +0100
Subject: [mcclim-devel] Annc: Freeze for Mothering Sunday release
Message-ID: <871xb9vl5h.wl%asf@boinkor.net>

Hello everybody,

this message marks the begin of the freeze period of McCLIM proper
(that includes all lisp files in the mcclim/ root directory,
Backends/, Goatee/ and Lisp-Dep/) for the Mothering Sunday release.

Apps/, Examples/ and Experimental/ are due to freeze next monday.

This means for you,

the user of McCLIM:

 Please help us test McCLIM. Running every available CLIM app, running
 the examples, building on different lisp implementations, trying
 obscure things, and sending reports of bugs you find are all very
 much appreciated (especially the sending reports of bugs part). The
 more bugs we find now, the better the release will be.

the McCLIM developer:

 Bug fixes only, please. And please stick to conservative commits:
 fixing a bug in the layout protocol is ok, but rewriting the layout
 protocol should wait until after the release. If a bug can only be
 fixed by a big change, the fix should wait until after the release -
 the bug will be mentioned in the release notes.

 The intent is to release something that resembles the state of
 today's McCLIM as closely as possible, but without the easy-to-fix
 bugs. (-:

Cheers,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From asf at boinkor.net  Mon Feb 21 18:35:41 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 21 Feb 2005 19:35:41 +0100
Subject: [mcclim-devel] Annc: Freeze for Mothering Sunday release
In-Reply-To: <871xb9vl5h.wl%asf@boinkor.net>
References: <871xb9vl5h.wl%asf@boinkor.net>
Message-ID: <87zmxxu5fm.wl%asf@boinkor.net>

(just one thing that I forgot)

Today, Andreas Fuchs <asf at boinkor.net> wrote:
> the McCLIM developer:
> 
> Bug fixes only, please. And please stick to conservative commits:
> fixing a bug in the layout protocol is ok, but rewriting the layout
> protocol should wait until after the release. If a bug can only be
> fixed by a big change, the fix should wait until after the release -
> the bug will be mentioned in the release notes.
>
> The intent is to release something that resembles the state of
> today's McCLIM as closely as possible, but without the easy-to-fix
> bugs. (-:

Of course, documentation is always welcome. Feel free to update and
extend the user's guide, the installation documentation or other
documents at any time (-:

-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From csr21 at cam.ac.uk  Mon Feb 21 21:45:39 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 21 Feb 2005 21:45:39 +0000
Subject: [mcclim-devel] Yet another bug for the bug list
In-Reply-To: <874qg8ocsb.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's
	message of "Sat, 19 Feb 2005 15:16:36 +0100")
References: <sqvf8qrn0t.fsf@cam.ac.uk>
	<87acq2szti.fsf@plato.moon.paoloamoroso.it> <sqd5uwss5z.fsf@cam.ac.uk>
	<874qg8ocsb.fsf@plato.moon.paoloamoroso.it>
Message-ID: <sqhdk5si2k.fsf@cam.ac.uk>

Paolo Amoroso <amoroso at mclink.it> writes:

> Any comments from the McCLIM developers?  What should be done with the
> bug list page at McCLIM CLiki?  Shall we drop it?

While we have it, we should probably keep it up to date -- unless
someone is actively tagging and tracking bug reports sent to this
list.  However, I'd urge people interested in these infrastructural
issues to think about a better system as a matter of relative urgency.
(It would be nice to have a system in place for the next release.)

Cheers,

Christophe


From csr21 at cam.ac.uk  Mon Feb 21 21:47:14 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 21 Feb 2005 21:47:14 +0000
Subject: [mcclim-devel] Yet another bug for the bug list
In-Reply-To: <200502200050.j1K0oH08014361@saturn.mikemac.com>
	(mikemac@mikemac.com's
	message of "Sat, 19 Feb 2005 18:50:17 -0600")
References: <200502200050.j1K0oH08014361@saturn.mikemac.com>
Message-ID: <sqd5utshzx.fsf@cam.ac.uk>

mikemac at mikemac.com writes:

>   How about a CLIM based front end that sumbits a properly formatted
> bug report to an Email address? Might make an interesting first app
> for someone wanting to learn CLIM but who also wants to contribute
> something useful.

Sure, but this is only useful if that e-mail address isn't some gaping
void -- that is, there's infrastructural work that needs to be done
too.  On the other hand, having a "Report Bug" command available
automatically in McCLIM apps would be neat if it could be made to
work...

Cheers,

Christophe


From asf at boinkor.net  Mon Feb 21 22:12:46 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 21 Feb 2005 23:12:46 +0100
Subject: [mcclim-devel] Yet another bug for the bug list
In-Reply-To: <sqd5uwss5z.fsf@cam.ac.uk>
References: <sqvf8qrn0t.fsf@cam.ac.uk>
	<87acq2szti.fsf@plato.moon.paoloamoroso.it>
	<sqd5uwss5z.fsf@cam.ac.uk>
Message-ID: <87y8dhtvdt.wl%asf@boinkor.net>

On 2005-02-19, Christophe Rhodes <csr21 at cam.ac.uk> wrote:
> The issue I have is that I've used a raw cliki-based bug tracking
> system before -- entomotomy -- and while it was by no means an
> unmitigated disaster, I think it would be fair to say that for those
> who had the most interaction with it, it was more work than it
> needed to be.
>
> What I would like to see is something which can be driven by e-mail,
> much like debbugs, working maybe from header information, maybe from
> stuff in the body.  So when a bug report like mine arrives, someone
> In Charge of Bugs forwards the mail on to
> mcclim-bug at common-lisp.net, say, with a few commands in the new
> body:
>
> open open-window-stream-windows-not-closed-by-parent
> submitter csr21 at cam.ac.uk
> thanks
>
> and then the body of the original message, or even just a
> message-id, if the system would be smart enough to convert that to a
> URL to the mcclim-devel archives.  Closing a bug should likewise be
> done by e-mail; discussion can be done over the mailing list, with
> any particularly pertinent messages likewise forwarded to the
> magical bug system (with command "addto" or something).

I created a "roundup" (roundup.sf.net) issue tracker for mcclim and
populated it with bugs from the wiki page. The web interface isn't
that bad, although the e-mail interface could use some work, if it is
to support the (debbugs-centric) workflow you describe above.

If you want to take a look, it's at
<URL:http://boinkor.net/lisp/mcclim/roundup.cgi/mcclim/>.


-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From ml13 at onlinehome.de  Wed Feb 23 19:58:27 2005
From: ml13 at onlinehome.de (ml13 at onlinehome.de)
Date: Wed, 23 Feb 2005 20:58:27 +0100
Subject: [mcclim-devel] building probl lw darwin
Message-ID: <694bd01964bc4d280d7768d81e5ecf69@onlinehome.de>

Hi,

I cannot, unfortunately, build mcclim on lw.

The last form in the file "fix-lispworks.lisp" is causing trouble:

(defmethod clim-mop:class-direct-superclasses ((instance (eql 
*ptype-t-class*)))
   (list (find-class 'standard-object)))  ;; scary..

lw complains:
Error: The variable *PTYPE-T-CLASS* is unbound.

I am completely new to mcclim, so I am sorry for not backtracing this 
more properly.

Any ideas?

Thanks,
	Peter



From tim at tenkan.org  Thu Feb 24 01:19:53 2005
From: tim at tenkan.org (Tim Daly Jr.)
Date: 24 Feb 2005 02:19:53 +0100
Subject: [mcclim-devel] mcclim.asd, defresource.lisp
Message-ID: <87oeeakb46.fsf@beer.intern>


Hi all,

Closure uses the DEFRESOURCE macro defined in defresource.lisp.  The
new mcclim.asd doesn't load defresource.lisp.  (system.lisp does).  I
don't know what defresource.lisp really depends on, but after applying
the patch below and deleting all the mcclim fasls, I was still able to
load mcclim.  So, I propose:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcclim-asd-defresource.patch
Type: text/x-patch
Size: 651 bytes
Desc: patch to mcclim.asd to include defresource.lisp
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050224/5fd0e85e/attachment.bin>
-------------- next part --------------



-- 
-Tim


From ajuckel at gmail.com  Fri Feb 25 03:26:40 2005
From: ajuckel at gmail.com (Anthony Juckel)
Date: Thu, 24 Feb 2005 21:26:40 -0600
Subject: [mcclim-devel] Reposting gadgets.patch
Message-ID: <a45b92ac0502241926475a093b@mail.gmail.com>

I'm resending this patch (this time as a unified diff) to gadgets.lisp
as, apparently, it has been overlooked.  Perhaps I was a bit too terse
when sending the patch the first time around.

This patch is a one-line bug fix, which I believe stems from a change
in standard-rectangle.  Previously, rectangle coordinates were stored
in slots (x1 y1 x2 y2) within standard-rectangle.  In an attempt to
optimize rectangle operations, these were condensed into a single
coordinates slot.  The problem is that an :after method on
initialize-instance for gadget-output-record was never notified of
said change, and was still attempting to call (with-slots (x1 x2 y1
y2) ...) on a standard rectangle.  This was causing problems for me,
so I swapped in a destructuring-bind on coordinates instead.

Anthony W. Juckel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gadgets.patch
Type: text/x-patch
Size: 612 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050224/1b963968/attachment.bin>

From mikemac at mikemac.com  Fri Feb 25 05:23:54 2005
From: mikemac at mikemac.com (mikemac at mikemac.com)
Date: Thu, 24 Feb 2005 23:23:54 -0600
Subject: [mcclim-devel] Reposting gadgets.patch 
In-Reply-To: Your message of "Thu, 24 Feb 2005 21:26:40 CST."
	<a45b92ac0502241926475a093b@mail.gmail.com> 
Message-ID: <200502250523.j1P5Ns4I004900@saturn.mikemac.com>



>Index: gadgets.lisp

>@@ -2700,7 +2700,7 @@
>          (height (space-requirement-height sr)))
>     (allocate-space child width height)
>     (setf (gadget record) child)
>-    (with-slots (x1 x2 y1 y2) record
>+    (multiple-value-bind (x1 y1 x2 y2) (slot-value record 'coordinates)

  Try this instead:

      (multiple-value-bind (x1 y1 x2 y2) (rectangle-edges* record)

  Using internal state of classes is a no-no. Use the interfaces
provided by the spec.

  Mike McDonald
  mikemac at mikemac.com


From ahefner at gmail.com  Fri Feb 25 05:57:19 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Fri, 25 Feb 2005 00:57:19 -0500
Subject: [mcclim-devel] Reposting gadgets.patch
In-Reply-To: <31ffd3c405022421555d8ce9fd@mail.gmail.com>
References: <a45b92ac0502241926475a093b@mail.gmail.com>
	<200502250523.j1P5Ns4I004900@saturn.mikemac.com>
	<31ffd3c405022421555d8ce9fd@mail.gmail.com>
Message-ID: <31ffd3c405022421572aa2aeb2@mail.gmail.com>

Actually neither of these patches are correct, the intent is to modify
the value of the slots.

:)


On Thu, 24 Feb 2005 23:23:54 -0600, mikemac at mikemac.com
<mikemac at mikemac.com> wrote:
>
>
> >Index: gadgets.lisp
>
> >@@ -2700,7 +2700,7 @@
> >          (height (space-requirement-height sr)))
> >     (allocate-space child width height)
> >     (setf (gadget record) child)
> >-    (with-slots (x1 x2 y1 y2) record
> >+    (multiple-value-bind (x1 y1 x2 y2) (slot-value record 'coordinates)
>
>   Try this instead:
>
>       (multiple-value-bind (x1 y1 x2 y2) (rectangle-edges* record)
>
>   Using internal state of classes is a no-no. Use the interfaces
> provided by the spec.
>
>   Mike McDonald
>   mikemac at mikemac.com
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>


From mikemac at mikemac.com  Fri Feb 25 08:07:18 2005
From: mikemac at mikemac.com (mikemac at mikemac.com)
Date: Fri, 25 Feb 2005 02:07:18 -0600
Subject: [mcclim-devel] Reposting gadgets.patch 
In-Reply-To: Your message of "Fri, 25 Feb 2005 00:57:19 EST."
	<31ffd3c405022421572aa2aeb2@mail.gmail.com> 
Message-ID: <200502250807.j1P87Ioh005193@saturn.mikemac.com>


>To: mcclim-devel at common-lisp.net
>Date: Fri, 25 Feb 2005 00:57:19 -0500
>From: Andy Hefner
>
>Actually neither of these patches are correct, the intent is to modify
>the value of the slots.
>
>:)

  Fine, then use MAKE-RECTANGLE* to make a new rectangle. Don't
modify an existing one:

	Members of this class are immutable. 

  Mike McDonald
  mikemac at mikemac.com


From moore at bricoworks.com  Fri Feb 25 09:45:34 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Fri, 25 Feb 2005 10:45:34 +0100
Subject: [mcclim-devel] Reposting gadgets.patch 
In-Reply-To: <200502250807.j1P87Ioh005193@saturn.mikemac.com>
References: <200502250807.j1P87Ioh005193@saturn.mikemac.com>
Message-ID: <f94681a55786088fdd8c66d66e684c64@bricoworks.com>

On Feb 25, 2005, at 9:07 AM, mikemac at mikemac.com wrote:

>
>> To: mcclim-devel at common-lisp.net
>> Date: Fri, 25 Feb 2005 00:57:19 -0500
>> From: Andy Hefner
>>
>> Actually neither of these patches are correct, the intent is to modify
>> the value of the slots.
>>
>> :)
>
>   Fine, then use MAKE-RECTANGLE* to make a new rectangle. Don't
> modify an existing one:
>
> 	Members of this class are immutable.
Then we need to rewrite recording.lisp :) Seriously, we've abused 
rectangles in this way for a very long time; they're too convenient to 
use in the representation of output recording  records. We also 
conflate rectangles, bounding rectangles, and output records, even 
though the spec says they are different. I think the admonition 
"rectangles are immutable" is more in the context of operations on 
regions.

Tim



From luke at synap.se  Sat Feb 26 19:46:38 2005
From: luke at synap.se (Luke Gorrie)
Date: 26 Feb 2005 20:46:38 +0100
Subject: [mcclim-devel] backspace at argument prompt -> infinite loop
Message-ID: <l3zmxrt881.fsf@gant.netcamp.se>

Hi guys,

Some IRC log to share :-)

<Luke_> tbmoore: if I type command name, space (see prompt for argument),
        backspace -- then it goes into an infinite loop printing the
        "scan-pointer ~S > insertion-pointer ~S; shouldn't happen" message
<Luke_> in Closure or in clim-listener
<tbmoore> Luke_: Ouch
<Luke_> if I nuke the listener thread at this point it seems to put things
        into a bad state where if I try to start a new listener it hangs
        before reaching the prompt (under SBCL)
<tbmoore> Luke_: If you can send email to the list, that would be good.
<tbmoore> But I think this should not be too hard to fix.



From tom.winchester at internode.on.net  Mon Feb 28 06:09:35 2005
From: tom.winchester at internode.on.net (Tom Winchester)
Date: Mon, 28 Feb 2005 16:39:35 +1030
Subject: [mcclim-devel] help needed with the beagle backend
Message-ID: <3d1d83fa9e0d4a0be8625273b24f3442@internode.on.net>

Hi there.

I have been trying to get the beagle back-end for mcclim running. I am 
using use openmcl 0.14.2-p1, mac os x 10.3.8, and a fresh cvs of mcclim 
taken this morning. The clx back-end runs nicely -thanks to the 
splendid effort of the mcclim team.

My first attempt consisted of executing the statement (asdf:operate 
'asdf:load-op 'beagle). Even when repeated in an OpenMCL Listener, the 
result was:

 > Error in process Listener(3): Cannot IMPORT "SET-PORT-KEYBOARD-FOCUS" 
from package "CLIMI"
 > While executing: CCL::OPERATION-ON-ALL-SPECS
 > Type :GO to continue, :POP to abort.
 > If continued: Ignore attempt to IMPORT "SET-PORT-KEYBOARD-FOCUS" from 
package "CLIMI"
Type :? for other options.
1 >

I then examined the documentation in the Backends/beagle directiory of 
the mcclim (cvs) distribution. The load files essentially perform the 
following steps inside the OpenMCL Listener window:

(load "/opt/local/share/openmcl/0.14.2-p1/tools/asdf")
(pushnew "/Users/tom/.asdf-install-openmcl-dir/systems/" 
asdf:*central-registry*)
(asdf:operate 'asdf:load-op :asdf-install)
(asdf:operate 'asdf:load-op 'clx)
(asdf:operate 'asdf:load-op :mcclim)
(asdf:operate 'asdf:load-op :clim-examples)
(asdf:operate 'asdf:load-op :clim-listener)
(asdf:operate 'asdf:load-op :beagle)

This is equivalent to my current ~/.openmclrc file, except that all of 
this is stated to be done inside the OpenMCL Listener, and the final 
statement.

Upon pasting the above sequence of statements into an OpenMCL Listener 
the same error results. Does anyone know if this error is a genuine 
bug, or is there something else missing in the loading sequence I 
describe above.

I am aware that the beagle back-end is experimental, but my aim is to 
be able to reproduce some of the screen-shots of mcclim using the 
beagle back-end which available on the web.

Thanks.



From csr21 at cam.ac.uk  Mon Feb 28 07:05:39 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 28 Feb 2005 07:05:39 +0000
Subject: [mcclim-devel] help needed with the beagle backend
In-Reply-To: <3d1d83fa9e0d4a0be8625273b24f3442@internode.on.net> (Tom
	Winchester's message of "Mon, 28 Feb 2005 16:39:35 +1030")
References: <3d1d83fa9e0d4a0be8625273b24f3442@internode.on.net>
Message-ID: <sqvf8dcgfw.fsf@cam.ac.uk>

Tom Winchester <tom.winchester at internode.on.net> writes:

> I have been trying to get the beagle back-end for mcclim running. I am
> using use openmcl 0.14.2-p1, mac os x 10.3.8, and a fresh cvs of
> mcclim taken this morning. The clx back-end runs nicely -thanks to the
> splendid effort of the mcclim team.
>
> My first attempt consisted of executing the statement (asdf:operate
> 'asdf:load-op 'beagle). Even when repeated in an OpenMCL Listener, the
> result was:
>
>  > Error in process Listener(3): Cannot IMPORT
> "SET-PORT-KEYBOARD-FOCUS" from package "CLIMI"

I believe that the backend protocol changed recently, and this symbol
was renamed to %set-port-keyboard-focus.  Try changing uses of it in
the beagle backend (and adding a timestamp keyword argument to the
method definition).

Cheers,

Christophe


From amoroso at mclink.it  Mon Feb 28 09:33:36 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 28 Feb 2005 10:33:36 +0100
Subject: [mcclim-devel] Copying text to clipboard loops displaying messages
	to Konsole
Message-ID: <87650d111r.fsf@plato.moon.paoloamoroso.it>

When I copy some text with Shift-left-click from the CLIM Listener for
later copying somewhere else, I get an infinite loop that displays
messages (all identical) like this to the KDE Konsole from which I
have started the Listener:

#<CLIM-CLX::CLX-SELECTION-REQUEST-EVENT {5850A54D}> is an instance of type CLX-SELECTION-REQUEST-EVENT
   it has the following slots:
      TIMESTAMP: 5010524
          SHEET: #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58B8A0CD}>
         REGION: <unbound>
      SELECTION: :PRIMARY
      REQUESTOR: #<XLIB:WINDOW :0 31457298>
         TARGET: :COMPOUND_TEXT
       PROPERTY: :_QT_SELECTION

If I later paste with Shift-middle-click the clipboard selection to
another Konsole pane, I get a garbled string similar to that described
here:

  http://common-lisp.net/pipermail/mcclim-devel/2004-December/002731.html

I have to quit the Listener in order to stop the infinite loop.

I use CMUCL Snapshot 2005-02 with the latest McCLIM CVS sources under
Slackware Linux 10.0, with a 2.6.10 kernel.


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


From tim at tenkan.org  Mon Feb 28 15:06:59 2005
From: tim at tenkan.org (Tim Daly Jr.)
Date: 28 Feb 2005 16:06:59 +0100
Subject: [mcclim-devel] updated mcclim.asd patch
Message-ID: <871xb0k9kc.fsf@beer.intern>


This patch to mcclim.asd adds the file defresource.lisp to the :clim
system (this change was also in the last patch), and adds a dependency
on design.lisp for X11-colors.lisp (for MAKE-NAMED-COLOR).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcclim.asd.patch
Type: text/x-patch
Size: 1280 bytes
Desc: patch to mcclim.asd
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050228/892462c8/attachment.bin>
-------------- next part --------------

-- 
-Tim


From amoroso at mclink.it  Mon Feb 28 15:55:02 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 28 Feb 2005 16:55:02 +0100
Subject: [mcclim-devel] Annc: Freeze for Mothering Sunday release
In-Reply-To: <871xb9vl5h.wl%asf@boinkor.net> (Andreas Fuchs's message of
	"Mon, 21 Feb 2005 19:10:50 +0100")
References: <871xb9vl5h.wl%asf@boinkor.net>
Message-ID: <87650cr86h.fsf@plato.moon.paoloamoroso.it>

Andreas Fuchs <asf at boinkor.net> writes:

> this message marks the begin of the freeze period of McCLIM proper
> (that includes all lisp files in the mcclim/ root directory,
> Backends/, Goatee/ and Lisp-Dep/) for the Mothering Sunday release.
>
> Apps/, Examples/ and Experimental/ are due to freeze next monday.

Would it be possible to fix this CLIM Listener bug before the next
freeze?

  Package lock errors when compiling/loading with CMUCL 19 or later
  http://mcclim.cliki.net/Bug#listener-cmucl-package-lock

New users may get perplexed when finding that the flagship McCLIM demo
may not build cleanly and requires a manual fix.

Thanks anyway,


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


From asf at boinkor.net  Mon Feb 28 16:39:30 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 28 Feb 2005 17:39:30 +0100
Subject: [mcclim-devel] updated mcclim.asd patch
In-Reply-To: <871xb0k9kc.fsf@beer.intern>
References: <871xb0k9kc.fsf@beer.intern>
Message-ID: <87k6ostz99.wl%asf@boinkor.net>

Today, Tim Daly, Jr. <tim at tenkan.org> wrote:
> [1  <text/plain (7bit)>]
>
> This patch to mcclim.asd adds the file defresource.lisp to the :clim
> system (this change was also in the last patch), and adds a
> dependency on design.lisp for X11-colors.lisp (for
> MAKE-NAMED-COLOR).

Thank you. I've now committed that patch (plus another dependency that
was dropped before).

-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs


From asf at boinkor.net  Mon Feb 28 22:20:41 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 28 Feb 2005 23:20:41 +0100
Subject: [mcclim-devel] Annc: Freeze, part 2 for Mothering Sunday release
Message-ID: <87hdjwtjgm.wl%asf@boinkor.net>

Hello everybody,

today is the freeze date for McCLIM's Apps/, Examples/ and
Experimental/ directories for the release next sunday.

So, to repeat the call for testers in the last announcement: Please
help us test the code that's in there. (-:

Cheers,
-- 
Andreas Fuchs, <asf at boinkor.net>, asf at jabber.at, antifuchs