From randomtalk at gmail.com  Sun May  1 19:29:49 2005
From: randomtalk at gmail.com (Jason Wang)
Date: Sun, 1 May 2005 15:29:49 -0400
Subject: [mcclim-devel] clim 2 spec in pdf format?
In-Reply-To: <87br7wk154.fsf@beer.intern>
References: <E1E73C3A-B95F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<87br7wk154.fsf@beer.intern>
Message-ID: <939cf200505011229739ac1bf@mail.gmail.com>

hi, does anyone have clim 2 spec in pdf format? if so, can you send it
to me? as i want to print it out for reference.. thanks alot :D

Jason
-- 
www.programer.name - my own personal blog : )

The mind is its own place, and in itself can make a heav'n of hell, a
hell of heav'n. What matter where, if I be still the same, and what I
should be, all but less than he whom thunder hath made greater?  Here
at least we shall be free; th' Almighty hath not built here for his
envy, will not drive us hence: Here we may reign secure, and in my
choice to reign is worth ambition though in hell: Better to reign in
hell, than serve in heav'n.
---  John Milton, in his epic poem Paradise Lost


From randomtalk at gmail.com  Sun May  1 20:12:59 2005
From: randomtalk at gmail.com (Jason Wang)
Date: Sun, 1 May 2005 16:12:59 -0400
Subject: [mcclim-devel] function undefined when trying to access the example
	page?
In-Reply-To: <D7CE07E9-B9A0-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <57939FA8-B995-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<D7CE07E9-B9A0-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <939cf20050501131232671d86@mail.gmail.com>

hi, i just got the latest version of ucw from tla, May 1st, 2005.. the
server is up and running fine. However, when i try to access the
examples page, it gave me a function undefined message:
debugger invoked on a UNDEFINED-FUNCTION in thread 5746:
  The function IT.BESE.UCW::PARSE-REQUEST is undefined.

anyone know what's going on?
-- 
www.programer.name - my own personal blog : )

The mind is its own place, and in itself can make a heav'n of hell, a
hell of heav'n. What matter where, if I be still the same, and what I
should be, all but less than he whom thunder hath made greater?  Here
at least we shall be free; th' Almighty hath not built here for his
envy, will not drive us hence: Here we may reign secure, and in my
choice to reign is worth ambition though in hell: Better to reign in
hell, than serve in heav'n.
---  John Milton, in his epic poem Paradise Lost


From smustudent1 at yahoo.com  Mon May  2 02:15:59 2005
From: smustudent1 at yahoo.com (C Y)
Date: Sun, 1 May 2005 19:15:59 -0700 (PDT)
Subject: [mcclim-devel] Axiom 
Message-ID: <20050502021559.3656.qmail@web31702.mail.mud.yahoo.com>

Here is a screenshot:
http://mathshield.sourceforge.net/axiomstartuppage.png

I'm guessing this is well withing McCLIM's abilities, at least to 
build a mockup of.  I believe bold text and buttons are clickable.

CY

P.S. - sorry if this is a dupe, I don't think my other response made
it.

On Thursday 28 April 2005 03:03 pm, Andy Hefner wrote:
> What kind of browser?
>
> On 4/28/05, C Y <smustudent1 at yahoo.com> wrote:
> > "I've looked at McClim which is a path I'd dearly love to take
> > but so far I've not gotten it to work. If someone could
> > reproduce the first page of the browser (a few buttons, an
> > image) in McClim that might be enough to get me over the
> > hurdle. A pure lisp solution is preferred."

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From smustudent1 at yahoo.com  Mon May  2 03:29:45 2005
From: smustudent1 at yahoo.com (C Y)
Date: Sun, 1 May 2005 20:29:45 -0700 (PDT)
Subject: [mcclim-devel] Scigraph
Message-ID: <20050502032945.79157.qmail@web31704.mail.mud.yahoo.com>

Hi all.  I've just been trying to build scigraph with the latest cvs
McCLIM and cmucl 19a, and I've been hitting a variety of problems.  Has
anybody else seen any trouble with recent cvs McCLIM?

CY



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 


From duncan at robotcat.demon.co.uk  Mon May  2 08:01:23 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Mon, 2 May 2005 09:01:23 +0100
Subject: [mcclim-devel] Scigraph
In-Reply-To: <20050502032945.79157.qmail@web31704.mail.mud.yahoo.com>
Message-ID: <603A9F3C-BAE0-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Monday, May 2, 2005, at 04:29 AM, C Y wrote:

> Hi all.  I've just been trying to build scigraph with the latest cvs
> McCLIM and cmucl 19a, and I've been hitting a variety of problems.  Has
> anybody else seen any trouble with recent cvs McCLIM?
>

It builds fine for me under OpenMCL. Can you be more specific regarding
the errors you're seeing?

The only external dependency I can think of in the build is CLX. Do you
have it installed (this shouldn't matter for building most of McCLIM,
only when building the back end I think).

-Duncan


> CY
>
>
>
> 		
> __________________________________
> Do you Yahoo!?
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From tomi.neste at netikka.fi  Mon May  2 09:39:13 2005
From: tomi.neste at netikka.fi (Tomi K Neste)
Date: Mon, 02 May 2005 12:39:13 +0300
Subject: [mcclim-devel] Problems in reading with :timeout
Message-ID: <opsp46fnjiqgqnvi@localhost>

I'm having some newb confusion about the timeout value in stream input  
functions, (read-gesture ...) etc.
(read-gesture :timeout 0) always just returns NIL, while timeout values >0  
don't seem to have any effect at all. For example, in the Listener  
(read-gesture :timeout 1) keeps blocking until some gesture is given.  
Another source of confusion is the :input-wait-handler. From reading the  
spec I got the idea that it should be called "continously" when there  
isn't any input in the given stream, but it looks like the function is  
never executed.
Are these real problems or am I just missing something obvious?


From amoroso at mclink.it  Mon May  2 11:17:29 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 02 May 2005 13:17:29 +0200
Subject: [mcclim-devel] clim 2 spec in pdf format?
In-Reply-To: <939cf200505011229739ac1bf@mail.gmail.com> (Jason Wang's
	message of "Sun, 1 May 2005 15:29:49 -0400")
References: <E1E73C3A-B95F-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<87br7wk154.fsf@beer.intern>
	<939cf200505011229739ac1bf@mail.gmail.com>
Message-ID: <87ekcpop12.fsf@plato.moon.paoloamoroso.it>

Jason Wang <randomtalk at gmail.com> writes:

> hi, does anyone have clim 2 spec in pdf format? if so, can you send it
> to me? as i want to print it out for reference.. thanks alot :D

The CLIM 2 specification is available in PostScript format here:

  ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/gui/clim/papers/0.html

You can either directly print it, or convert it to PDF and print the
result.


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


From smustudent1 at yahoo.com  Mon May  2 11:42:16 2005
From: smustudent1 at yahoo.com (C Y)
Date: Mon, 2 May 2005 04:42:16 -0700 (PDT)
Subject: [mcclim-devel] Scigraph
In-Reply-To: 6667
Message-ID: <20050502114216.28899.qmail@web31713.mail.mud.yahoo.com>


--- Duncan Rose <duncan at robotcat.demon.co.uk> wrote:
>
> It builds fine for me under OpenMCL. Can you be more specific
> regarding the errors you're seeing?
> 
> The only external dependency I can think of in the build is CLX. Do
> you have it installed (this shouldn't matter for building most of 
> McCLIM, only when building the back end I think).

Here we go (core with McCLIM built and loaded):

CMU Common Lisp 19a, running on gentoo
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Sun, 2005-05-01 22:50:16-04:00 on gentoo
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
    Python 1.1, target Intel x86
    CLOS based on Gerd's PCL 2004/04/14 03:32:47
    CLX X Library MIT R5.02
    Gray Streams Protocol Support
* (asdf:oos 'asdf:load-op :scigraph)

[snip]

; Compiling DEFMETHOD ZOOM-OUT (GRAPH-ZOOM-MIXIN T): 
; Byte Compiling Top-Level Form: 

;
/home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving-object.x86f
written.
; Compilation finished in 0:00:04.
; Loading
#p"/home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving-object.x86f".
; [GC threshold exceeded with 63,889,944 bytes in use.  Commencing GC.]
; [GC completed with 56,906,880 bytes retained and 6,983,064 bytes
freed.]
; [GC will next occur when at least 68,906,880 bytes are in use.]

Condition COMMAND-TABLE-NOT-FOUND was signalled.
   [Condition of type COMMAND-TABLE-NOT-FOUND]

Restarts:
  0: [CONTINUE] Return NIL from load of
#p"/home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving-object.x86f".
  1: [RETRY   ] Retry performing #<ASDF:LOAD-OP NIL {5A60D8FD}> on
                #<ASDF:CL-SOURCE-FILE "moving-object" {285FCC25}>.
  2: [ACCEPT  ] Continue, treating #<ASDF:LOAD-OP NIL {5A60D8FD}> on
                #<ASDF:CL-SOURCE-FILE "moving-object" {285FCC25}> as
having
                been successful.
  3: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

; [GC threshold exceeded with 68,917,416 bytes in use.  Commencing GC.]
; [GC completed with 55,934,776 bytes retained and 12,982,640 bytes
freed.]
; [GC will next occur when at least 67,934,776 bytes are in use.]
(CLIM:FIND-COMMAND-TABLE :GRAPH :ERRORP T)
Source: 
; File: /home/user/mcclimtoplevel/mcclim/commands.lisp
(ERROR 'COMMAND-TABLE-NOT-FOUND)
0] 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From amoroso at mclink.it  Mon May  2 12:04:23 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 02 May 2005 14:04:23 +0200
Subject: [mcclim-devel] Scigraph
In-Reply-To: <20050502114216.28899.qmail@web31713.mail.mud.yahoo.com> (C.
	Y.'s message of "Mon, 2 May 2005 04:42:16 -0700 (PDT)")
References: <20050502114216.28899.qmail@web31713.mail.mud.yahoo.com>
Message-ID: <87wtqhltq0.fsf@plato.moon.paoloamoroso.it>

C Y <smustudent1 at yahoo.com> writes:

> Here we go (core with McCLIM built and loaded):
[...]
> * (asdf:oos 'asdf:load-op :scigraph)
[...]
> Condition COMMAND-TABLE-NOT-FOUND was signalled.

I confirm this build problem.  I am currently able to build Scigraph
only with MK:DEFSYSTEM.  With MK:DEFSYSTEM in your Lisp image, load
system.lisp and evaluate the forms:

  (mk:oos :scigraph :compile)

  (mk:oos :scigraph :load)


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


From a_bakic at yahoo.com  Mon May  2 15:30:35 2005
From: a_bakic at yahoo.com (Aleksandar Bakic)
Date: Mon, 2 May 2005 08:30:35 -0700 (PDT)
Subject: [mcclim-devel] Scigraph
In-Reply-To: <20050502032945.79157.qmail@web31704.mail.mud.yahoo.com>
Message-ID: <20050502153035.43665.qmail@web40614.mail.yahoo.com>

Hi,

I've had minor problems with Scigraph and a recent CMUCL snapshot. Here are two
patches that work for me:

*** Apps/Scigraph/dwim/package.lisp     6 Aug 2004 13:19:40 -0000       1.4
--- Apps/Scigraph/dwim/package.lisp     2 May 2005 15:24:25 -0000
***************
*** 50,56 ****
            parse-error *default-server-path*)

     #+clim
!    (:use clim-lisp)
     #-clim
     (:use lisp clos)))

--- 50,56 ----
            parse-error *default-server-path*)

     #+clim
!    (:use :clim-lisp)
     #-clim
     (:use lisp clos)))

and

*** Apps/Scigraph/scigraph/draw.lisp    6 Aug 2004 13:19:40 -0000       1.2
--- Apps/Scigraph/scigraph/draw.lisp    2 May 2005 15:24:41 -0000
***************
*** 135,145 ****
         (with-drawing-options (,stream :clipping-region .x.)
           , at body)))
        (:clim-2
!        (let ((.x. *clim-clip-rectangle*))
!        (setf (bounding-rectangle-min-x .x.) le
!              (bounding-rectangle-min-y .x.) te
!              (bounding-rectangle-max-x .x.) re
!              (bounding-rectangle-max-y .x.) be)
         (with-drawing-options (,stream :clipping-region .x.)
           , at body))))))

--- 135,150 ----
         (with-drawing-options (,stream :clipping-region .x.)
           , at body)))
        (:clim-2
!         (let* ((.x. *clim-clip-rectangle*)
!              (coords (slot-value .x. 'coordinates))) ;mcclim only
!         (setf (aref coords 0) le
!               (aref coords 1) te
!               (aref coords 2) re
!               (aref coords 3) be)
! ;;     (setf (bounding-rectangle-min-x .x.) le
! ;;           (bounding-rectangle-min-y .x.) te
! ;;           (bounding-rectangle-max-x .x.) re
! ;;           (bounding-rectangle-max-y .x.) be)
         (with-drawing-options (,stream :clipping-region .x.)
           , at body))))))

***************
*** 223,229 ****
              (clip ,x1 ,x2 yb ,y1 ,y2)))))
      (let ((c1 (code x1 y1))
          (c2 (code x2 y2)))
!       (declare (type (integer 0 9) c1 c2))
        (loop (and (zerop c1) (zerop c2) (return (values x1 y1 x2 y2)))
            (or (zerop (logand c1 c2)) (return nil))
            (clip-point c1 x1 y1 x2 y2)
--- 228,234 ----
              (clip ,x1 ,x2 yb ,y1 ,y2)))))
      (let ((c1 (code x1 y1))
          (c2 (code x2 y2)))
!       (declare (type (integer 0 10) c1 c2))
        (loop (and (zerop c1) (zerop c2) (return (values x1 y1 x2 y2)))
            (or (zerop (logand c1 c2)) (return nil))
            (clip-point c1 x1 y1 x2 y2)
***************
*** 425,448 ****
      (when transform
        (multiple-value-setq (x1 y1) (uv-to-screen stream x1 y1))
        (multiple-value-setq (x2 y2) (uv-to-screen stream x2 y2)))
!     (multiple-value-setq (x1 y1 x2 y2) (clip-line-to-clip-rectangle x1 y1 x2
y 2))
!     (if x1
!       (if (zerop dash-pattern)
!           (progn
!             (draw-line x1 y1 x2 y2 :stream stream :alu alu
!                                 :thickness thickness :line-end-shape
!                                 (if end-point-p line-end-shape
:no-end-point))
!             0.0)
!           (progn
!             (dash-line
!               dash-pattern x1 y1 x2 y2 dash-ds
!               :stream stream
!               :alu alu
!               :thickness thickness
!               :pattern pattern)
!             ;; draw end caps here.
!             ))
!       dash-ds)))                              ; Don't change ds.

  (defun device-draw-lines (stream points &rest keys &key &allow-other-keys)
    (let ((ds (or (getf keys :dash-ds) 0.0)))
--- 430,454 ----
      (when transform
        (multiple-value-setq (x1 y1) (uv-to-screen stream x1 y1))
        (multiple-value-setq (x2 y2) (uv-to-screen stream x2 y2)))
!     (multiple-value-bind (x1 y1 x2 y2)
!       (clip-line-to-clip-rectangle x1 y1 x2 y2)
!       (if x1
!         (if (zerop dash-pattern)
!             (progn
!               (draw-line x1 y1 x2 y2 :stream stream :alu alu
!                          :thickness thickness :line-end-shape
!                          (if end-point-p line-end-shape :no-end-point))
!               0.0)
!             (progn
!               (dash-line
!                dash-pattern x1 y1 x2 y2 dash-ds
!                :stream stream
!                :alu alu
!                :thickness thickness
!                :pattern pattern)
!               ;; draw end caps here.
!               ))
!         dash-ds))))                           ; Don't change ds.

  (defun device-draw-lines (stream points &rest keys &key &allow-other-keys)
    (let ((ds (or (getf keys :dash-ds) 0.0)))


Regards,
Alex

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


From duncan at robotcat.demon.co.uk  Mon May  2 18:22:18 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Mon, 2 May 2005 19:22:18 +0100
Subject: [mcclim-devel] Scigraph
In-Reply-To: <20050502114216.28899.qmail@web31713.mail.mud.yahoo.com>
Message-ID: <1E20AD9A-BB37-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


*cough* sorry, I thought you were asking about a general build problem
rather than a Scigraph specific one. The subject line should have clued
me in, but...

Sorry 'bout that.

-Duncan


On Monday, May 2, 2005, at 12:42 PM, C Y wrote:

>
> --- Duncan Rose <duncan at robotcat.demon.co.uk> wrote:
>>
>> It builds fine for me under OpenMCL. Can you be more specific
>> regarding the errors you're seeing?
>>
>> The only external dependency I can think of in the build is CLX. Do
>> you have it installed (this shouldn't matter for building most of
>> McCLIM, only when building the back end I think).
>
> Here we go (core with McCLIM built and loaded):
>
> CMU Common Lisp 19a, running on gentoo
> With core: /usr/local/lib/cmucl/lib/lisp.core
> Dumped on: Sun, 2005-05-01 22:50:16-04:00 on gentoo
> See <http://www.cons.org/cmucl/> for support information.
> Loaded subsystems:
>     Python 1.1, target Intel x86
>     CLOS based on Gerd's PCL 2004/04/14 03:32:47
>     CLX X Library MIT R5.02
>     Gray Streams Protocol Support
> * (asdf:oos 'asdf:load-op :scigraph)
>
> [snip]
>
> ; Compiling DEFMETHOD ZOOM-OUT (GRAPH-ZOOM-MIXIN T):
> ; Byte Compiling Top-Level Form:
>
> ;
> /home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving- 
> object.x86f
> written.
> ; Compilation finished in 0:00:04.
> ; Loading
> #p"/home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving- 
> object.x86f".
> ; [GC threshold exceeded with 63,889,944 bytes in use.  Commencing GC.]
> ; [GC completed with 56,906,880 bytes retained and 6,983,064 bytes
> freed.]
> ; [GC will next occur when at least 68,906,880 bytes are in use.]
>
> Condition COMMAND-TABLE-NOT-FOUND was signalled.
>    [Condition of type COMMAND-TABLE-NOT-FOUND]
>
> Restarts:
>   0: [CONTINUE] Return NIL from load of
> #p"/home/user/mcclimtoplevel/mcclim/Apps/Scigraph/scigraph/moving- 
> object.x86f".
>   1: [RETRY   ] Retry performing #<ASDF:LOAD-OP NIL {5A60D8FD}> on
>                 #<ASDF:CL-SOURCE-FILE "moving-object" {285FCC25}>.
>   2: [ACCEPT  ] Continue, treating #<ASDF:LOAD-OP NIL {5A60D8FD}> on
>                 #<ASDF:CL-SOURCE-FILE "moving-object" {285FCC25}> as
> having
>                 been successful.
>   3: [ABORT   ] Return to Top-Level.
>
> Debug  (type H for help)
>
> ; [GC threshold exceeded with 68,917,416 bytes in use.  Commencing GC.]
> ; [GC completed with 55,934,776 bytes retained and 12,982,640 bytes
> freed.]
> ; [GC will next occur when at least 67,934,776 bytes are in use.]
> (CLIM:FIND-COMMAND-TABLE :GRAPH :ERRORP T)
> Source:
> ; File: /home/user/mcclimtoplevel/mcclim/commands.lisp
> (ERROR 'COMMAND-TABLE-NOT-FOUND)
> 0]
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>



From randomtalk at gmail.com  Mon May  2 23:45:01 2005
From: randomtalk at gmail.com (Jason Wang)
Date: Mon, 2 May 2005 19:45:01 -0400
Subject: [mcclim-devel] function undefined when trying to access the
	example page?
In-Reply-To: <20050502090413.GA6963@seid-online.de>
References: <57939FA8-B995-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<D7CE07E9-B9A0-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
	<939cf20050501131232671d86@mail.gmail.com>
	<20050502090413.GA6963@seid-online.de>
Message-ID: <939cf2005050216456c7e7cdd@mail.gmail.com>

i'm sorry.. i sent to the wrong mailing-list :|.. i'll be careful from now on :D
-- 
www.programer.name - my own personal blog : )


From lanning at scra.org  Tue May  3 13:20:41 2005
From: lanning at scra.org (Craig Lanning)
Date: Tue, 03 May 2005 09:20:41 -0400
Subject: [mcclim-devel] re: Black art
In-Reply-To: <20050429191920.50152.qmail@web31707.mail.mud.yahoo.com>
References: <20050429191920.50152.qmail@web31707.mail.mud.yahoo.com>
Message-ID: <1115126441.6090.5.camel@dhcp139.isg-scra.org>

OK, I've looked around for this code and can't find it.  I may just be
overlooking it since I can't remember what I called it.  The curious
part is that I can't seem to find the original one I wrote to do the
same thing for Symbolics' Dynamic Windows, either.  I must have dumped
them to CD.  In which case they're sitting in a box in my office right
now.  Maybe this will motivate me to unload my boxes.

I'll just spend a few hours and put together a new one and post it.

Craig

On Fri, 2005-04-29 at 12:19 -0700, C Y wrote:
> >>   And a graphical CLIM interface builder could possibly go
> >> a long way towards helping people create "correct" code or at 
> >> least avoid errors.
> >
> > I built one of these more than 10 years ago.  I'll dust off the 
> > code and post it to the list in the next few days.  (It probably 
> > needs updating since I haven't looked at it in at least 5 years.)
> 
> In case I forgot to say it elsewhere, drool... :-)
> 
> CY
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From duncan at robotcat.demon.co.uk  Wed May  4 13:14:44 2005
From: duncan at robotcat.demon.co.uk (duncan at robotcat.demon.co.uk)
Date: Wed, 04 May 2005 14:14:44 +0100
Subject: [mcclim-devel] Problems in reading with :timeout
In-Reply-To: <opsp46fnjiqgqnvi@localhost>
Message-ID: <20050504131121.125DE88708@common-lisp.net>

tomi.neste at netikka.fi wrote:
> I'm having some newb confusion about the timeout value in stream input  
> functions, (read-gesture ...) etc.
> (read-gesture :timeout 0) always just returns NIL, while timeout values >=
> 0  
> don't seem to have any effect at all. For example, in the Listener  
> (read-gesture :timeout 1) keeps blocking until some gesture is given.  
> Another source of confusion is the :input-wait-handler. From reading the =
>  
> spec I got the idea that it should be called "continously" when there  
> isn't any input in the given stream, but it looks like the function is  
> never executed.
> Are these real problems or am I just missing something obvious?

I see the same behaviour as you describe when running under Beagle; I
don't know if this is in fact the correct behaviour or if there's
a problem in the event processing code.

You are not alone ;-)

-Duncan



> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> 



From ahefner at gmail.com  Wed May  4 14:36:52 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 4 May 2005 10:36:52 -0400
Subject: [mcclim-devel] Problems in reading with :timeout
In-Reply-To: <opsp46fnjiqgqnvi@localhost>
References: <opsp46fnjiqgqnvi@localhost>
Message-ID: <31ffd3c405050407367664b07c@mail.gmail.com>

AFAIK, these basically don't work right now. I briefly hacked on these
(toward the goal of fixing scheduled event delivery), and I know there
are some obvious things that need to be changed in the SBCL support
files. I'll take a look at what I've done (if I can find it..) and see
if anything is commitable. I don't know the status of support on the
other lisps.

On 5/2/05, Tomi K Neste <tomi.neste at netikka.fi> wrote:
> I'm having some newb confusion about the timeout value in stream input
> functions, (read-gesture ...) etc.
> (read-gesture :timeout 0) always just returns NIL, while timeout values >0
> don't seem to have any effect at all. For example, in the Listener
> (read-gesture :timeout 1) keeps blocking until some gesture is given.
> Another source of confusion is the :input-wait-handler. From reading the
> spec I got the idea that it should be called "continously" when there
> isn't any input in the given stream, but it looks like the function is
> never executed.
> Are these real problems or am I just missing something obvious?


From rpgoldman at real-time.com  Wed May  4 14:46:15 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Wed, 4 May 2005 09:46:15 -0500
Subject: [mcclim-devel] Problems in reading with :timeout
In-Reply-To: <31ffd3c405050407367664b07c@mail.gmail.com>
References: <opsp46fnjiqgqnvi@localhost>
	<31ffd3c405050407367664b07c@mail.gmail.com>
Message-ID: <17016.57399.200435.41954@gargle.gargle.HOWL>


If there's any test code lying around (Tomi, have any snippets?), I
could test this stuff on Allegro.  I poked around a little in mp-acl,
and it looks like this stuff should work...

R



From ahefner at gmail.com  Wed May  4 17:08:07 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 4 May 2005 13:08:07 -0400
Subject: [mcclim-devel] resizeable panes
In-Reply-To: <17013.18383.240838.797341@gargle.gargle.HOWL>
References: <17010.37438.264108.469809@gargle.gargle.HOWL>
	<31ffd3c4050429153439b45739@mail.gmail.com>
	<17013.18383.240838.797341@gargle.gargle.HOWL>
Message-ID: <31ffd3c4050504100825d3a9ec@mail.gmail.com>

Off the top of my head, something like this within your layout should world:

(vertically ()
   top-pane
   (make-pane 'clim-extensions:box-adjuster-gadget)
   bottom-pane)

The idea is that you insert it a layout between the panes you want it
to resize. This should work fine for a horizontal layout also, the
box-adjuster-gadget takes its orientation from its parent.

On 5/1/05, rpgoldman at real-time.com <rpgoldman at real-time.com> wrote:
> Is there an example of the use of the box-adjuster-gadget anywhere?
> Sorry to be lame.  I couldn't find one anywhere in the stuff that
> comes with McCLIM (or I did something wrong with find...).
> 
> Thanks,
> R
>


From tomi.neste at netikka.fi  Fri May  6 11:17:54 2005
From: tomi.neste at netikka.fi (Tomi K Neste)
Date: Fri, 06 May 2005 14:17:54 +0300
Subject: [mcclim-devel] Problems in reading with :timeout 
Message-ID: <opsqcpn4h0qgqnvi@localhost>

Oops.. accidently sent this to rpgoldman only :-|

Just tried on SBCL with recent McCLIM and :timeout 0 works fine  >0 values  
still seem to be blocking forever.
Looks like clim-internals:stream-input-wait keeps continuously calling  
clim-internals:event-queue-listen-or-wait
with wrong TIMEOUT. Or maybe not, it's all (still) bit over my head

The :timeout 0 => NIL still seems to a problem on CMUCL, but that's on a  
few months old version of McCLIM, so
maybe it's fixed and irrelevant by now anyway. I really should update my  
CMUCL stuff on that laptop...

I'm trying to figure out how to do some simple animation, like a clock or  
process browser that should keep on updating every few seconds. So I  
thought the way to go would be specializing the READ-COMMAND or  
READ-FRAME-COMMAND and use the :timeout where approriate. I also thought  
about using different thread for the pane updating, but I'm not sure if  
that would be a smart thing to do.
So I'm wondering if there's a canonical way to accomplish something like  
that, some sources perhaps?

BTW, big thanks to all McCLIM developers, fascinating stuff :-)


From duncan at robotcat.demon.co.uk  Fri May  6 17:11:49 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Fri, 6 May 2005 18:11:49 +0100
Subject: [mcclim-devel] Problems in reading with :timeout 
In-Reply-To: <opsqcpn4h0qgqnvi@localhost>
Message-ID: <EEC8E97F-BE51-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>


On Friday, May 6, 2005, at 12:17 PM, Tomi K Neste wrote:

--->8--- snipped for brevity --->8---

>
> I'm trying to figure out how to do some simple animation, like a clock 
> or process browser that should keep on updating every few seconds. So 
> I thought the way to go would be specializing the READ-COMMAND or 
> READ-FRAME-COMMAND and use the :timeout where approriate. I also 
> thought about using different thread for the pane updating, but I'm 
> not sure if that would be a smart thing to do.
> So I'm wondering if there's a canonical way to accomplish something 
> like that, some sources perhaps?
>

Hrm. I wrote a little clock thing quite a while ago and had trouble 
with this. The following post includes some code to show a problem I 
was having (fixed at the time the mail was sent in actual fact) so it's 
fully functional and uses scheduled events to redraw a pane:-

http://common-lisp.net/pipermail/mcclim-devel/2003-October/000438.html

Hopefully this will help you out.

-Duncan


> BTW, big thanks to all McCLIM developers, fascinating stuff :-)
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From tomi.neste at netikka.fi  Fri May  6 19:36:31 2005
From: tomi.neste at netikka.fi (Tomi K Neste)
Date: Fri, 06 May 2005 22:36:31 +0300
Subject: [mcclim-devel] Problems in reading with :timeout 
In-Reply-To: <EEC8E97F-BE51-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
References: <EEC8E97F-BE51-11D9-800F-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <opsqdcq5u2qgqnvi@localhost>

On Fri, 6 May 2005 18:11:49 +0100, Duncan Rose  
<duncan at robotcat.demon.co.uk> wrote:

>
> Hrm. I wrote a little clock thing quite a while ago and had trouble with  
> this. The following post includes some code to show a problem I was  
> having (fixed at the time the mail was sent in actual fact) so it's  
> fully functional and uses scheduled events to redraw a pane:-
>
> http://common-lisp.net/pipermail/mcclim-devel/2003-October/000438.html
>
> Hopefully this will help you out.
>
> -Duncan
>

Hmm.. weird. I'm just trying your code snippet on SBCL and it doesn't seem  
to work. DRAW-SIMPLE gets called only once at the beginning, after that  
the window seems to go catatonic. No redraws or reactions to window close  
events.
I get
WARNING:
    recursive lock attempt #S(SB-THREAD:MUTEX
                              :NAME "event queue"
                              :LOCK 0
                              :DATA NIL
                              :VALUE 3737)

It works fine if SCHEDULE-TIMER-EVENT is removed. With no animations, of  
course ;-)
I didn't know about the schedule-timer-event though, so if it's supposed  
to work that's probably what i need. Thanks for the pointer.





From rpgoldman at real-time.com  Fri May  6 22:10:16 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Fri, 6 May 2005 17:10:16 -0500
Subject: [mcclim-devel] new graph type: first drawf
Message-ID: <17019.60232.378979.108653@gargle.gargle.HOWL>


I have developed a tentative first version of a new graph type, which
is a tree with cross-edges.  I.e., you have a graph which is basically
a tree, but where you are allowed to have cross edges.  The cross
edges are NOT the same as graph edges, and in particular, don't cause
additions to the PARENT/CHILD relationships, nor (for this reason) do
they cause depths to be incremented.  Note that these cross-edges do
NOT have to be only one one level of the tree --- they can cross
levels.  To build such a graph you need to add two more arguments to
format-graph-from-roots:

:CROSS-ARC-DRAWER

a function that takes all the arguments accepted by a normal
arc-drawer, but also an edge-type keyword argument, which it is free
to ignore.

:CROSS-ARC-PRODUCER

a function that takes a graph-node as argument, like
inferior-producer, but that returns two values: a list of destination
nodes and (optionally) a list of type-designators, that can be passed
to the cross-arc-drawer, as the value of the :edge-type keyword
argument.

I have posted the source for this to the following URL, hoping that it
will attract comments and suggestions:

http://rpgoldman.real-time.com/lisp/tree-with-cross-edges.lisp

I'd love to see this integrated into McCLIM some day!

KNOWN BUGS:

1.  Currently only works on :horizontal orientation (I don't have the arc
routing for vertical yet).

2.  Only draws straight lines for cross edges.  It would be nice if the
cross edges would swoop around intervening nodes, but I haven't read
enough of the CLIM spec to figure out how to do this yet.

3.  If you have a depth-bounded tree, probably something very ugly
will happen!

I'll try to assemble some screendumps and post them, but for now it's
weekend...

Best,
R


From frido at q-software-solutions.de  Mon May  9 07:25:26 2005
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Mon, 09 May 2005 09:25:26 +0200
Subject: [mcclim-devel] list-pane usage
In-Reply-To: <17009.6811.306786.30827@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Thu, 28 Apr 2005 12:17:15 -0500")
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
	<17009.6811.306786.30827@gargle.gargle.HOWL>
Message-ID: <87sm0wkgih.fsf_-_@flarge.here>

Well I'm starting to find my path into CLIM. The application I like to
implement is an account keeping application. I implemented it before
with LispWorks and CAPI and now I want to make it a clim
application. I found out about the different panes but got a bit stuck
with how to use one of them the list-pane. It seems that this is the
pane I'd like to use to keep a list of short descriptions of the
divrese accounts. I first modelled the accounts stuff as the
address-book example, but am now deriving. So what I like to know is
how to make this part of the address-book example:
(defmethod display-names ((frame address-book) stream)
  (dolist (address *addresses*)
    ;; PRESENT invokes the :PRINTER for the ADDRESS presentation-type, defined above.
    ;; It also makes each address printed out mouse-sensitive.
    (updating-output (stream :unique-id address)
      (present address 'address :stream stream)
      (terpri stream))))

work with a list pane. What I want is that that the list-pane entried
get mouse-sensitive. I searched the examples but found nothing which
gives me a hint. Maybe some of you can?

Regards
Friedrich


From rpgoldman at real-time.com  Mon May  9 14:27:37 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Mon, 9 May 2005 09:27:37 -0500
Subject: [mcclim-devel] question about CLIM spec
Message-ID: <17023.29529.655307.306906@gargle.gargle.HOWL>


I was looking over Christophe's dendrogram sample code, and was
surprised to find the following in the comments:

"...this one is technically non-conforming, in that
FORMAT-GRAPH-FROM-ROOTS isn't specified as &KEY &ALLOW-OTHER-KEYS"

I went back to the spec and yes, AFAICT, the format-graph-from-roots
function is specified as NOT being extendible with new keyword
arguments.

With all due respect, this seems kooky, since FORMAT-GRAPH-FROM-ROOTS'
interface seems poorly structured to do much of anything beyond trees
or graphs that are essentially tree-like.  The interface seems poor if
you want to have edges of different flavors, if you want to control the
assignment of depths, etc.

Now, of course, you can do a pretty arbitrary amount of customization
by developing new graph-output-records.  BUT...  the spec as written
(to the best of my understanding) doesn't provide any way to customize
these new output record classes with initargs.  Not only doesn't
format-graph-from-roots as specified allow for extending its argument
set, it also doesn't specify (again, as far as I can tell), how to
pass initargs to the new class.  

The McCLIM implementation takes what seems to me to be a very sensible
approach of passing extra keyword arguments from
format-graph-from-roots into the make-instance for the
GRAPH-OUTPUT-RECORD, but this is an extension to the specification.

Question:  have I misread the specification, or is this a deficiency
in it?

Cheers,
Robert


From strandh at labri.fr  Mon May  9 14:39:10 2005
From: strandh at labri.fr (Robert Strandh)
Date: Mon, 9 May 2005 16:39:10 +0200
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: <17023.29529.655307.306906@gargle.gargle.HOWL>
References: <17023.29529.655307.306906@gargle.gargle.HOWL>
Message-ID: <17023.30222.684330.831241@serveur5.labri.fr>

rpgoldman at real-time.com writes:
 > 
 > Question:  have I misread the specification, or is this a deficiency
 > in it?

The latter is very likely.  You can do us a favor and go to the
annotatable spec at

  http://bauhh.dyndns.org:8000/clim-spec/index.html 

and enter your comments at the appropriate place.

Thanks. 
-- 
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  Mon May  9 15:39:56 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 09 May 2005 17:39:56 +0200
Subject: [mcclim-devel] list-pane usage
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
	<17009.6811.306786.30827@gargle.gargle.HOWL>
	<87sm0wkgih.fsf_-_@flarge.here>
Message-ID: <87sm0wxvar.fsf@plato.moon.paoloamoroso.it>

Friedrich Dominicus <frido at q-software-solutions.de> writes:

> address-book example, but am now deriving. So what I like to know is
> how to make this part of the address-book example:
> (defmethod display-names ((frame address-book) stream)
>   (dolist (address *addresses*)
>     ;; PRESENT invokes the :PRINTER for the ADDRESS presentation-type, defined above.
>     ;; It also makes each address printed out mouse-sensitive.
>     (updating-output (stream :unique-id address)
>       (present address 'address :stream stream)
>       (terpri stream))))
>
> work with a list pane. What I want is that that the list-pane entried
> get mouse-sensitive. I searched the examples but found nothing which

You may do something like this in the panes section of the relevant
application frame (untested):

(define-application-frame ...
  ...
  (:panes
    (addresses (make-pane 'list-pane
                          :mode :exclusive
                          :items *addresses*
                          :value-changed-callback 'select-address))
    ...
    ))

Where #'select-address does whatever is needed to make the address
selected by the user via the list pane the current one.


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


From amoroso at mclink.it  Mon May  9 15:45:07 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 09 May 2005 17:45:07 +0200
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: <17023.29529.655307.306906@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Mon, 9 May 2005 09:27:37 -0500")
References: <17023.29529.655307.306906@gargle.gargle.HOWL>
Message-ID: <87oebkxv24.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> I was looking over Christophe's dendrogram sample code, and was

Which code?


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


From ahefner at gmail.com  Mon May  9 16:46:59 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Mon, 9 May 2005 12:46:59 -0400
Subject: [mcclim-devel] list-pane usage
In-Reply-To: <87sm0wkgih.fsf_-_@flarge.here>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
	<17009.6811.306786.30827@gargle.gargle.HOWL>
	<87sm0wkgih.fsf_-_@flarge.here>
Message-ID: <31ffd3c4050509094665919900@mail.gmail.com>

The list-pane is a gadget, and not required or expected to integrate
with presentations in the way you suggest (native window system
gadgets can't be expected to know about presentations). Presently you
must fall back to a more conventional toolkit model of programming
where gadgets are concerned (performing action via the
value-changed-callback, as Paolo describes).

How to better integrate gadgets with higher levels of the CLIM
framework is an open question. The big thread a week or two ago
touched on some of this.

On 5/9/05, Friedrich Dominicus <frido at q-software-solutions.de> wrote:
> Well I'm starting to find my path into CLIM. The application I like to
> implement is an account keeping application. I implemented it before
> with LispWorks and CAPI and now I want to make it a clim
> application. I found out about the different panes but got a bit stuck
> with how to use one of them the list-pane. It seems that this is the
> pane I'd like to use to keep a list of short descriptions of the
> divrese accounts. I first modelled the accounts stuff as the
> address-book example, but am now deriving. So what I like to know is
> how to make this part of the address-book example:
> (defmethod display-names ((frame address-book) stream)
>   (dolist (address *addresses*)
>     ;; PRESENT invokes the :PRINTER for the ADDRESS presentation-type, defined above.
>     ;; It also makes each address printed out mouse-sensitive.
>     (updating-output (stream :unique-id address)
>       (present address 'address :stream stream)
>       (terpri stream))))
> 
> work with a list pane. What I want is that that the list-pane entried
> get mouse-sensitive. I searched the examples but found nothing which
> gives me a hint. Maybe some of you can?
> 
> Regards
> Friedrich
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>


From moore at bricoworks.com  Mon May  9 20:32:46 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Mon, 9 May 2005 22:32:46 +0200
Subject: [mcclim-devel] list-pane usage
In-Reply-To: <87sm0wkgih.fsf_-_@flarge.here>
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
	<17009.6811.306786.30827@gargle.gargle.HOWL>
	<87sm0wkgih.fsf_-_@flarge.here>
Message-ID: <fee7b70f4df6481e188843ced78513e2@bricoworks.com>

In my checkbook application I've ignored gadgets altogether, in favor 
of tables with presentations in the cells. In fact a presentation can 
span several cells of a row.

Tim

On May 9, 2005, at 9:25 AM, Friedrich Dominicus wrote:

> Well I'm starting to find my path into CLIM. The application I like to
> implement is an account keeping application. I implemented it before
> with LispWorks and CAPI and now I want to make it a clim
> application. I found out about the different panes but got a bit stuck
> with how to use one of them the list-pane. It seems that this is the
> pane I'd like to use to keep a list of short descriptions of the
> divrese accounts. I first modelled the accounts stuff as the
> address-book example, but am now deriving. So what I like to know is
> how to make this part of the address-book example:
> (defmethod display-names ((frame address-book) stream)
>   (dolist (address *addresses*)
>     ;; PRESENT invokes the :PRINTER for the ADDRESS presentation-type, 
> defined above.
>     ;; It also makes each address printed out mouse-sensitive.
>     (updating-output (stream :unique-id address)
>       (present address 'address :stream stream)
>       (terpri stream))))
>
> work with a list pane. What I want is that that the list-pane entried
> get mouse-sensitive. I searched the examples but found nothing which
> gives me a hint. Maybe some of you can?
>
> Regards
> Friedrich
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From frido at q-software-solutions.de  Tue May 10 05:09:02 2005
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Tue, 10 May 2005 07:09:02 +0200
Subject: [mcclim-devel] list-pane usage
In-Reply-To: <87sm0wxvar.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's
	message of "Mon, 09 May 2005 17:39:56 +0200")
References: <17006.64818.608786.797221@gargle.gargle.HOWL>
	<87wtqomvit.fsf@plato.moon.paoloamoroso.it>
	<17007.41995.725215.885595@gargle.gargle.HOWL>
	<877jiot4fe.fsf@plato.moon.paoloamoroso.it>
	<17009.5931.275190.675482@gargle.gargle.HOWL>
	<17009.6811.306786.30827@gargle.gargle.HOWL>
	<87sm0wkgih.fsf_-_@flarge.here>
	<87sm0wxvar.fsf@plato.moon.paoloamoroso.it>
Message-ID: <87fywvk6q9.fsf@flarge.here>

Thanks, it seems that going this way is "the traditional" one. Someone
else pointed out that there should be a thread about this handling of
gadgets I have to look through it. However thanks for giving me a
hand.

Regards
Friedrich


From duncan at robotcat.demon.co.uk  Tue May 10 14:50:46 2005
From: duncan at robotcat.demon.co.uk (duncan at robotcat.demon.co.uk)
Date: Tue, 10 May 2005 15:50:46 +0100
Subject: [mcclim-devel] commit privs
Message-ID: <20050510145053.8BAD5880A4@common-lisp.net>


I have a number of changes to Beagle to commit; who assigns commit privs
for the mcclim repository?

-Duncan




From rpgoldman at sift.info  Wed May 11 02:02:54 2005
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Tue, 10 May 2005 21:02:54 -0500
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: <17023.30222.684330.831241@serveur5.labri.fr>
References: <17023.29529.655307.306906@gargle.gargle.HOWL>
	<17023.30222.684330.831241@serveur5.labri.fr>
Message-ID: <17025.26574.827145.299220@gargle.gargle.HOWL>

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

    RS> rpgoldman at real-time.com writes:
    >> 
    >> Question:  have I misread the specification, or is this a deficiency
    >> in it?

    RS> The latter is very likely.  You can do us a favor and go to the
    RS> annotatable spec at

    RS>   http://bauhh.dyndns.org:8000/clim-spec/index.html 

    RS> and enter your comments at the appropriate place.

OK, I had a preliminary whack at it.  I hope the comments are useful.
I am hardly an expert on this subject!

R


From smustudent1 at yahoo.com  Wed May 11 03:00:08 2005
From: smustudent1 at yahoo.com (C Y)
Date: Tue, 10 May 2005 20:00:08 -0700 (PDT)
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: 6667
Message-ID: <20050511030008.1025.qmail@web31711.mail.mud.yahoo.com>


Wasn't the plan to move the annotated spec to common-lisp.net?  Or did
I miss an update on that?

CY

--- "Robert P. Goldman" <rpgoldman at sift.info> wrote:
> >>>>> "RS" == Robert Strandh <strandh at labri.fr> writes:
> 
>     RS> rpgoldman at real-time.com writes:
>     >> 
>     >> Question:  have I misread the specification, or is this a
> deficiency
>     >> in it?
> 
>     RS> The latter is very likely.  You can do us a favor and go to
> the
>     RS> annotatable spec at
> 
>     RS>   http://bauhh.dyndns.org:8000/clim-spec/index.html 
> 
>     RS> and enter your comments at the appropriate place.
> 
> OK, I had a preliminary whack at it.  I hope the comments are useful.
> I am hardly an expert on this subject!
> 
> R
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
> 


		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html



From strandh at labri.fr  Wed May 11 05:18:21 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 11 May 2005 07:18:21 +0200
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: <17025.26574.827145.299220@gargle.gargle.HOWL>
References: <17023.29529.655307.306906@gargle.gargle.HOWL>
	<17023.30222.684330.831241@serveur5.labri.fr>
	<17025.26574.827145.299220@gargle.gargle.HOWL>
Message-ID: <17025.38301.389857.683446@serveur5.labri.fr>

Robert P. Goldman writes:
 > 
 > OK, I had a preliminary whack at it.  I hope the comments are useful.
 > I am hardly an expert on this subject!

Don't worry about it.  Most of us aren't.

Thanks for doing that.
-- 
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 May 11 05:19:43 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 11 May 2005 07:19:43 +0200
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: <20050511030008.1025.qmail@web31711.mail.mud.yahoo.com>
References: <20050511030008.1025.qmail@web31711.mail.mud.yahoo.com>
Message-ID: <17025.38383.317268.699056@serveur5.labri.fr>

C Y writes:
 > 
 > Wasn't the plan to move the annotated spec to common-lisp.net?  Or did
 > I miss an update on that?

I discussed that with Gilbert a few days ago, and now it seems that he
prefers keeping it on his home machine.

-- 
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 May 11 05:31:10 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 11 May 2005 07:31:10 +0200
Subject: [mcclim-devel] commit privs
In-Reply-To: <20050510145053.8BAD5880A4@common-lisp.net>
References: <20050510145053.8BAD5880A4@common-lisp.net>
Message-ID: <17025.39070.757320.88689@serveur5.labri.fr>

duncan at robotcat.demon.co.uk writes:
 > 
 > I have a number of changes to Beagle to commit; who assigns commit privs
 > for the mcclim repository?

Physically, some cl.net maintainer must do it, but they will only do
that if the other developers agree.  As for me, I see absolutely no
problem with that. 

-- 
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 smustudent1 at yahoo.com  Wed May 11 06:25:46 2005
From: smustudent1 at yahoo.com (C Y)
Date: Tue, 10 May 2005 23:25:46 -0700 (PDT)
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: 6667
Message-ID: <20050511062546.47988.qmail@web31715.mail.mud.yahoo.com>


Should we at least keep a backup in case something unforseen happens to
his machine?

CY

--- Robert Strandh <strandh at labri.fr> wrote:
> C Y writes:
>  > 
>  > Wasn't the plan to move the annotated spec to common-lisp.net?  Or
> did
>  > I miss an update on that?
> 
> I discussed that with Gilbert a few days ago, and now it seems that
> he
> prefers keeping it on his home machine.
> 
> -- 
> 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.
> ---------------------------------------------------------------------
> 


		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html



From strandh at labri.fr  Wed May 11 06:49:57 2005
From: strandh at labri.fr (Robert Strandh)
Date: Wed, 11 May 2005 08:49:57 +0200
Subject: [mcclim-devel] question about CLIM spec
In-Reply-To: <20050511062546.47988.qmail@web31715.mail.mud.yahoo.com>
References: <20050511062546.47988.qmail@web31715.mail.mud.yahoo.com>
Message-ID: <17025.43797.569079.875303@serveur5.labri.fr>

C Y writes:
 > 
 > Should we at least keep a backup in case something unforseen happens to
 > his machine?

That might be a good idea, depending on what Gilbert is currently
doing for backups. 

-- 
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  Fri May 13 02:34:45 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 12 May 2005 21:34:45 -0500
Subject: [mcclim-devel] patch for graph-formatting.lisp
Message-ID: <17028.4677.113012.336416@gargle.gargle.HOWL>


I believe that there is a bug in graph-formatting.lisp where a graph,
if it gets > 10 deep, will cause adjust-array to be called to create
new array entries initialized to nil instead of to zero, meaning that
comparisons cause a crash.

Here's a patch.  Will someone familiar with this code please vet it
and apply it if appropriate?

Thanks,

Robert

Index: graph-formatting.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/graph-formatting.lisp,v
retrieving revision 1.14
diff -u -F^(def -r1.14 graph-formatting.lisp
--- graph-formatting.lisp	23 Apr 2005 20:02:01 -0000	1.14
+++ graph-formatting.lisp	13 May 2005 02:33:33 -0000
@@ -312,7 +312,7 @@ (defmethod layout-graph-nodes ((graph-ou
                  (walk (node depth)
                    (unless (graph-node-minor-size node)
                      (when (>= depth (length generation-sizes))
-                       (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2)))))
+                       (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2) :initial-element 0))))
                      (setf (aref generation-sizes depth)
                            (max (aref generation-sizes depth) (node-major-dimension node)))
                      (setf (graph-node-minor-size node) 0)




From rpgoldman at real-time.com  Fri May 13 02:16:30 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 12 May 2005 21:16:30 -0500
Subject: [mcclim-devel] question about layout-graph-nodes
Message-ID: <17028.3582.281182.329031@gargle.gargle.HOWL>


I managed to persuade format-graph-from-roots to crash, and it did so
inside the WALK local function in layout-graph-nodes.  Alas, this
isn't too easy to debug, even with my beloved Allegro, because of all
of the closures....  But I was wondering about the following piece of
layout-graph-nodes.  Perhaps I'm missing something, but there seems to
be a call to MAX whose return is never harvested.


(labels (...
         (walk (node depth)
           (unless (graph-node-minor-size node)
             (when (>= depth (length generation-sizes))
               (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2)))))
             (setf (aref generation-sizes depth)
               (max (aref generation-sizes depth) (node-major-dimension node)))
             (setf (graph-node-minor-size node) 0)
**           (max (node-minor-dimension node)
                  (setf (graph-node-minor-size node)
                    (let ((sum 0) (n 0))
                      (map nil (lambda (child)
                                 (let ((x (walk child (+ depth 1))))
                                   (when x
                                     (incf sum x)
                                     (incf n))))
                           (graph-node-children node))
                      (+ sum
                         (* (max 0 (- n 1)) within-generation-separation))))))))
  (map nil #'(lambda (x) (walk x 0)) root-nodes)
  ...)

I confess that I am not a big user of MAP, nor do I fully grok what's
going on here, but it seems like the MAX on the starred line does not
serve any purpose.  That suggests to me that the code mgiht be garbled
somehow....

Any suggestions?  For reference, I attach the full defmethod at the end of
the message.

BTW, the error occurring somehwere in here is a 'NIL' is not of
expected type REAL error, which suggests to me that one of the
comparisons has gone bad...  I think it's because at generation 10,
the array gets resized, and the initial value is NIL instead of 0...

Thanks,
R

(defmethod layout-graph-nodes ((graph-output-record tree-graph-output-record)
                               stream arc-drawer arc-drawing-options)
  ;; work in progress! --GB 2002-08-14
  (declare (ignore arc-drawer arc-drawing-options))
  (with-slots (orientation center-nodes generation-separation within-generation-separation root-nodes) graph-output-record
    (check-type orientation (member :horizontal :vertical)) ;xxx move to init.-inst.
    ;; here major dimension is the dimension in which we grow the
    ;; tree.
    (let ((within-generation-separation (parse-space stream within-generation-separation
                                                     (case orientation
                                                       (:horizontal :vertical)
                                                       (:vertical :horizontal))))
          (generation-separation (parse-space stream generation-separation orientation)))
      (let ((generation-sizes (make-array 10 :adjustable t :initial-element 0)))
        (labels ((node-major-dimension (node)
                   (if (eq orientation :vertical)
                       (bounding-rectangle-height node)
                       (bounding-rectangle-width node)))
                 (node-minor-dimension (node)
                   (if (eq orientation :vertical)
                       (bounding-rectangle-width node)
                       (bounding-rectangle-height node)))
                 (walk (node depth)
                   (unless (graph-node-minor-size node)
                     (when (>= depth (length generation-sizes))
                       (setf generation-sizes (adjust-array generation-sizes (ceiling (* depth 1.2)))))
                     (setf (aref generation-sizes depth)
                           (max (aref generation-sizes depth) (node-major-dimension node)))
                     (setf (graph-node-minor-size node) 0)
                     (max (node-minor-dimension node)
                          (setf (graph-node-minor-size node)
                                (let ((sum 0) (n 0))
                                  (map nil (lambda (child)
                                             (let ((x (walk child (+ depth 1))))
                                               (when x
                                                 (incf sum x)
                                                 (incf n))))
                                       (graph-node-children node))
                                  (+ sum
                                     (* (max 0 (- n 1)) within-generation-separation))))))))
          (map nil #'(lambda (x) (walk x 0)) root-nodes)
          (let ((hash (make-hash-table :test #'eq)))
            (labels ((foo (node majors u0 v0)
                       (cond ((gethash node hash)
                              v0)
                             (t
                              (setf (gethash node hash) t)
                              (let ((d (- (node-minor-dimension node)
                                          (graph-node-minor-size node))))
                                (let ((v (+ v0 (/ (min 0 d) -2))))
                                  (setf (output-record-position node)
                                        (if (eq orientation :vertical)
                                            (transform-position (medium-transformation stream) v u0)
                                            (transform-position (medium-transformation stream) u0 v)))
                                  (add-output-record node graph-output-record))
                                ;;
                                (let ((u (+ u0 (car majors)))
                                      (v (+ v0 (max 0 (/ d 2))))
                                      (firstp t))
                                  (map nil (lambda (q)
                                             (unless (gethash q hash)
                                               (if firstp
                                                   (setf firstp nil)
                                                   (incf v within-generation-separation))
                                               (setf v (foo q (cdr majors)
                                                            u v))))
                                           (graph-node-children node)))
                                ;;
                                (+ v0 (max (node-minor-dimension node)
                                           (graph-node-minor-size node))))))))
              ;;
              (let ((majors (mapcar (lambda (x) (+ x generation-separation))
                                    (coerce generation-sizes 'list))))
                (let ((u (+ 0 (car majors)))
                      (v 0))
                  (maplist (lambda (rest)
                             (setf v (foo (car rest) majors u v))
                             (unless (null rest)
                               (incf v within-generation-separation)))
                           (graph-root-nodes graph-output-record)))))))))))


From rpgoldman at real-time.com  Fri May 13 17:36:43 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Fri, 13 May 2005 12:36:43 -0500
Subject: [mcclim-devel] pathology in updating output with
	format-graph-from-roots
Message-ID: <17028.58795.723526.97583@gargle.gargle.HOWL>


[discussed on #lisp, to no avail...]

If you look at http://rpgoldman.real-time.com/goofy-clim.png
you will see what happens when one of my panes runs a display-function
that calls format-graph-from-roots inside updating-output.  The
display does not all get updated, leaving funny gray borders around
the active area of two panes.

What's interesting is that this pathology affects the interactor pane
at the bottom of the layout, as well as the application pane at the
top.

Before I made the display function for the top pane, the interactor
pane used to function correctly.  Now it erases its contents after
every command, and has the gray border problem.

I almost wonder if my adding :incremental-redisplay t to the
application frames could have somehow bled over into the options used
in initializing the interactor pane....

Finally, even with updating-output, using format-graph-from-roots
does not correctly relize that it needs a horizontal scrollbar as well
as a vertical one, when it gets a new graph in it.

Some partial solutions:

1.  Make application-panes with :scrollbars :both.  I think this is
    actually a McCLIM bug.  The spec states that the default value for
    application panes should be T (and it is), but also that T should
    be the same as :both (which doesn't seem to be an available
    option, according to the spec).  So, somewhere we're treating
    :both and t differently, but I think they should be the same.

2.  Use the bounding rectangle for the graph-output-record that
    format-graph-from-roots returns to set the :min-height and
    :min-width of the enclosing window, for example:

(defun graph-mdp (stream &optional (mdp (taems-mdp *application-frame*)))
  (when mdp
    (let ((normal-ink +foreground-ink+)
	  (arrow-ink  *graph-edge-ink*)
	  (text-style *graph-text-style*))
      (declare (special normal-ink arrow-ink text-style))
      (let* ((graph-output-record
	      (with-drawing-options (stream :text-style text-style)
		(format-graph-from-roots (list (taems:initial-state mdp))
					 ;; printer
					 #'draw-mdp-node
					 ;; inferior-producer
					 #'taems:mdp-successors
					 :stream stream
					 :arc-drawer
					 #'clim-internals::arrow-arc-drawer
					 )))
	     (rect (bounding-rectangle graph-output-record)))
	(change-space-requirements stream
				   :min-width (bounding-rectangle-width rect)
				   :min-height (bounding-rectangle-height rect))
	graph-output-record))))

[this function will be invoked wrapped in updating-output.]

That seems to get the scrollbars to be oriented to the right height
and width. 

I know that Andy has said that he doesn't like the idea of having
format-graph-from-roots automagically call change-space-requirements,
for the reason that it could cause too much wasted computation.  As a
programmer, though, having a function that is this high-level, but
then requires low-level messing with output records and the fairly
cryptic and ill-documented change-space-requirements seems very odd.  

I suspect that my use of change-space-requirements is just plain
wrong.  My case up above is trivial, because my pane will ONLY have
the graph in it; heaven help me if I ever want to stick a graph onto a
scrolling output history pane or something...  There ought to be (and
probably is) some way of saying to the pane "hey, please make room for
this big bolus of fresh, piping-hot pixels," but I don't understand
the protocol well enough to say what it is...

But neither of the above fixes the weird gray stuff, which seems to be
some flavor of updating error, and likely too deep in the guts of the
system for the likes of me.  Any suggestions for how I should start?



From amoroso at mclink.it  Fri May 13 18:28:18 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 13 May 2005 20:28:18 +0200
Subject: [mcclim-devel] pathology in updating output with
	format-graph-from-roots
In-Reply-To: <17028.58795.723526.97583@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Fri, 13 May 2005 12:36:43 -0500")
References: <17028.58795.723526.97583@gargle.gargle.HOWL>
Message-ID: <87r7gbt1z1.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> If you look at http://rpgoldman.real-time.com/goofy-clim.png
> you will see what happens when one of my panes runs a display-function
> that calls format-graph-from-roots inside updating-output.  The
> display does not all get updated, leaving funny gray borders around
> the active area of two panes.

I have seen gray borders also under other circumstances, i.e. in some
cases when displaying text.


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


From duncan at robotcat.demon.co.uk  Sun May 15 10:19:15 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Sun, 15 May 2005 11:19:15 +0100
Subject: [mcclim-devel] Context menu
Message-ID: <CA2F15A4-C52A-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>


I think I'm missing something to do with defining commands, and 
right-click context menus.

I have process objects that are presented and a number of commands 
defined for this type. I assumed (presumably wrongly :-) that these 
commands would be displayed automatically when the presentation is 
right-clicked over.

An example command definition follows:

(define-glimpse-command (com-kill-process :name t :menu nil)
   ((obj 'ccl::process    ; need to generalize this...
	:prompt "process"
	:gesture nil))
   (clim-sys:destroy-process obj)
   (com-show-processes))

[aside; I suspect it could be useful to define a PROCESS type in 
CLIM-SYS]

Do commands need to have a specific ':menu' entry to appear?

-Duncan



From moore at bricoworks.com  Sun May 15 14:43:11 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Sun, 15 May 2005 16:43:11 +0200
Subject: [mcclim-devel] Context menu
In-Reply-To: <CA2F15A4-C52A-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>
References: <CA2F15A4-C52A-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <5e1dfbdaab18b827df66ed9d4b8fc454@bricoworks.com>


On May 15, 2005, at 12:19 PM, Duncan Rose wrote:

>
> I think I'm missing something to do with defining commands, and 
> right-click context menus.
>
> I have process objects that are presented and a number of commands 
> defined for this type. I assumed (presumably wrongly :-) that these 
> commands would be displayed automatically when the presentation is 
> right-clicked over.
>
You need to define a presentation translator for something to appear in 
the context menu. You do that by:
* Specifying a gesture in the define-glimpse-command form. You've 
specifically said nil there;
* Using define-presentation-to-command-translator with a non-nil menu 
argument.

Tim

> An example command definition follows:
>
> (define-glimpse-command (com-kill-process :name t :menu nil)
>   ((obj 'ccl::process    ; need to generalize this...
> 	:prompt "process"
> 	:gesture nil))
>   (clim-sys:destroy-process obj)
>   (com-show-processes))
>
> [aside; I suspect it could be useful to define a PROCESS type in 
> CLIM-SYS]
>
> Do commands need to have a specific ':menu' entry to appear?
>
> -Duncan
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From metch at daimi.au.dk  Mon May 16 14:00:01 2005
From: metch at daimi.au.dk (Peter Mechlenborg)
Date: Mon, 16 May 2005 16:00:01 +0200
Subject: [mcclim-devel] Debugger take III
Message-ID: <4288A761.4010500@daimi.au.dk>

Hi

I have made some new adjustments to the debugger.

I would like to get commit access, but until I've been granted that,
you can get the modified debugger the usual place:
www.daimi.au.dk/~metch/lisp/

Changes:

- Added a packages.lisp file for the package.

- Added an asd file. You should note that that it currently doesn't
   depend on swank because I had some troubles making it
   work. Therefore you have load Slime manually.

- Keyboard shortcuts: 0 - 9 chooses the current restart (like
   Slime). Up and down moves the pointer between the stack frames and
   local variables. Space opens a stack frame (enter in Slime). Enter
   starts Clouseau (I finally get the name :-)) on a local variable.


The biggest problem now, is that it is slow. I normally use sbcl, but
I tried Mcclim on cmucl and it seemed that it was quite a bit faster. I 
think this has something to do with garbage collection, but that could 
be way off. Do any of you know what causes the big differences between 
sbcl cmucl?


Bye, and remember to have fun!

   --  Peter



From amoroso at mclink.it  Mon May 16 14:47:36 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 16 May 2005 16:47:36 +0200
Subject: [mcclim-devel] Debugger take III
In-Reply-To: <4288A761.4010500@daimi.au.dk> (Peter Mechlenborg's message of
	"Mon, 16 May 2005 16:00:01 +0200")
References: <4288A761.4010500@daimi.au.dk>
Message-ID: <873bsnqlbr.fsf@plato.moon.paoloamoroso.it>

Peter Mechlenborg <metch at daimi.au.dk> writes:

> I have made some new adjustments to the debugger.
[...]
> The biggest problem now, is that it is slow. I normally use sbcl, but
> I tried Mcclim on cmucl and it seemed that it was quite a bit
> faster. I think this has something to do with garbage collection, but
> that could be way off. Do any of you know what causes the big
> differences between sbcl cmucl?

Maybe some issues related to threading or socket I/O with SLIME?


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


From nikodemus at random-state.net  Mon May 16 14:31:47 2005
From: nikodemus at random-state.net (Nikodemus Siivola)
Date: Mon, 16 May 2005 17:31:47 +0300 (EEST)
Subject: [mcclim-devel] Debugger take III
In-Reply-To: <4288A761.4010500@daimi.au.dk>
References: <4288A761.4010500@daimi.au.dk>
Message-ID: <Pine.OSX.4.62.0505161729550.633@subversive.local>

On Mon, 16 May 2005, Peter Mechlenborg wrote:

> I tried Mcclim on cmucl and it seemed that it was quite a bit faster. I think 
> this has something to do with garbage collection, but that could be way off. 
> Do any of you know what causes the big differences between sbcl cmucl?

I'd be surprised if it was GC. Are you aware of the statistical profiler 
in the SB-SPROF contrib? It is very usefull for profiling whole-system 
stuff like this.

Cheers,

  -- Nikodemus              Schemer: "Buddha is small, clean, and serious."
                   Lispnik: "Buddha is big, has hairy armpits, and laughs."


From csr21 at cam.ac.uk  Mon May 16 20:41:16 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 16 May 2005 21:41:16 +0100
Subject: [mcclim-devel] commit privs
In-Reply-To: <20050510145053.8BAD5880A4@common-lisp.net>
	(duncan@robotcat.demon.co.uk's
	message of "Tue, 10 May 2005 15:50:46 +0100")
References: <20050510145053.8BAD5880A4@common-lisp.net>
Message-ID: <sqacmu6h03.fsf@cam.ac.uk>

duncan at robotcat.demon.co.uk writes:

> I have a number of changes to Beagle to commit; who assigns commit
> privs for the mcclim repository?

Management seems unclear, but as far as I can tell, you have been
given commit privileges to the mcclim repository.

Cheers,

Christophe


From idurand at labri.fr  Tue May 17 21:06:59 2005
From: idurand at labri.fr (idurand at labri.fr)
Date: Tue, 17 May 2005 23:06:59 +0200
Subject: [mcclim-devel] cvs access
Message-ID: <1116364019.428a5cf3dcec0@iona.labri.fr>


Trying to get a cvs version of mcclim I get

Ordinateur-de-IRENE-DURAND:~ idurand$ cvs -z3 -d
:pserver:anonymous:anonymous at common-lisp.net:/project/mcclim/cvsroot co mcclim
? mcclim/cvsroot
? mcclim/Backends/CLX/clim-extensions.dfsl
? mcclim/Backends/CLX/frame-manager.dfsl
? mcclim/Backends/CLX/graft.dfsl
? mcclim/Backends/CLX/image.dfsl
? mcclim/Backends/CLX/keysymdef.dfsl
? mcclim/Backends/CLX/keysyms-common.dfsl
? mcclim/Backends/CLX/keysyms.dfsl
? mcclim/Backends/CLX/medium.dfsl
? mcclim/Backends/CLX/package.dfsl
? mcclim/Backends/CLX/port.dfsl
? mcclim/examples/franz
? mcclim/looks/pixie.dfsl
cvs server: existing repository /project/mcclim/cvsroot/McCLIM does not match
/project/mcclim/cvsroot/mcclim
cvs server: ignoring module mcclim

What am I doing wrong?

Irene

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From idurand at labri.fr  Wed May 18 11:19:52 2005
From: idurand at labri.fr (idurand at labri.fr)
Date: Wed, 18 May 2005 13:19:52 +0200
Subject: [mcclim-devel] Re: cvs access
In-Reply-To: <1116364019.428a5cf3dcec0@iona.labri.fr>
References: <1116364019.428a5cf3dcec0@iona.labri.fr>
Message-ID: <1116415192.428b24d835d49@mailhost.labri.fr>

Hello,

I have a previous version of mcclim which works fine with cmucl-18e.

I am trying to have the latest version of mcclim work with cmucl-19a.
Everything compiles and loads fine but then the execution fails:

Any idea of what to try?
Irene

PS: Below the trace of a session,
CMU Common Lisp 19a, running on kresse
With core: /home/idurand/opt/prog/CL/CMUCL/19a/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2004-07-28 18:51:48+02:00 on lorien
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
    Python 1.1, target Intel x86
    CLOS based on Gerd's PCL 2004/04/14 03:32:47
* *features*

(:MK-DEFSYSTEM :GRAY-STREAMS :CLX-MIT-R5 :CLX-MIT-R4 :XLIB :CLX
 :CLX-LITTLE-ENDIAN :GERDS-PCL :PCL-STRUCTURES :PORTABLE-COMMONLOOPS :PCL
 :CMU19 :CMU19A :PYTHON :CONSERVATIVE-FLOAT-TYPE :MODULAR-ARITH :MP :X86
 :LINKAGE-TABLE :RELATIVE-PACKAGE-NAMES :LINUX :GLIBC2 :UNIX :RANDOM-MT19937
 :GENCGC :PENTIUM :I486 :HASH-NEW :HEAP-OVERFLOW-CHECK :STACK-CHECKING :COMMON
 :COMMON-LISP :ANSI-CL :IEEE-FLOATING-POINT :CMU)
*
; Loading #p"/home/idurand/mcclim/system.lisp".

You need to run (mp::startup-idle-and-top-level-loops) to start up the
multiprocessing support.

;; Loading #p"/home/idurand/mcclim/Backends/CLX/system.lisp".
T
*   (mk:operate-on-system :clim-clx-user :load)

NIL
*   (mk:operate-on-system :clim-examples :load)

; Loading #p"/home/idurand/mcclim/Examples/calculator.x86f".
...
 #<FILE: Examples/menutest> #<FILE: Examples/colorslider>
 #<FILE: Examples/calculator>)
* (clim-demo::calculator)

:INTERNET fell through ECASE expression.  Wanted one of (:UNIX OR :TCP NIL).
   [Condition of type CONDITIONS::CASE-FAILURE]

Restarts:
  0: [ABORT] Return to Top-Level.

Debug  (type H for help)

(XLIB::OPEN-X-STREAM "theolite17.informatik.uni-stuttgart.de" 1 :INTERNET)
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:clx/dependent.lisp.
0] backtrace

0: (XLIB::OPEN-X-STREAM "theolite17.informatik.uni-stuttgart.de" 1 :INTERNET)
1: (XLIB:OPEN-DISPLAY "theolite17.informatik.uni-stuttgart.de"
                      :DISPLAY
                      1
                      :PROTOCOL
                      ...)
2: ((METHOD CLIM-CLX::INITIALIZE-CLX NIL (CLIM-CLX::CLX-PORT))
    (#(0 14 15 14 15 ...) . #(# #)) #<unused-arg> #<error printing object>)
3: ("LAMBDA (PCL::.KEYARGS-START. PCL::.VALID-KEYS. #:G5082 #:G5083 #:G5084)"
    #<unused-arg> #<unused-arg> #<error printing object>
    (:SERVER-PATH
     (:CLX :HOST "theolite17.informatik.uni-stuttgart.de" :DISPLAY-ID 1 ...)))
4: ("DEFMETHOD MAKE-INSTANCE (CLASS)" #<unused-arg> #<unused-arg>
    #<STANDARD-CLASS CLIM-CLX::CLX-PORT {58720D75}>
    (:SERVER-PATH
     (:CLX :HOST "theolite17.informatik.uni-stuttgart.de" :DISPLAY-ID 1 ...)))
5: (CLIM:FIND-PORT :SERVER-PATH NIL)
6: (CLIM:FIND-FRAME-MANAGER)
7: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME))
    (#(16 15) . #(#))
    #S(PCL::FAST-METHOD-CALL
         :FUNCTION #<Function # {59A18201}>
         :PV-CELL (# . #)
         :NEXT-METHOD-CALL NIL
         :ARG-INFO (1 . T))
    #<CLIM-DEMO::CALCULATOR {588876B5}> NIL)
8: (CLIM-DEMO::CALCULATOR)
9: (INTERACTIVE-EVAL (CLIM-DEMO::CALCULATOR))
10: (LISP::%TOP-LEVEL)
11: ((LABELS LISP::RESTART-LISP
       SAVE-LISP))

0]

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From rpgoldman at real-time.com  Thu May 19 19:30:07 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 19 May 2005 14:30:07 -0500
Subject: [mcclim-devel] question about curves and formatting graphs
Message-ID: <17036.59711.134835.283860@gargle.gargle.HOWL>


If one wanted to draw curvy lines in McCLIM, is there any way of doing
this?  I had assumed, foolish me, that this could be done using Bezier
curves, but now I see that those were an Allegro extension to the
standard, and not part of CLIM 2.0....

I'm not much of a graphics person, and don't understand X very well,
so I was wondering --- is there anything about X itself that makes
drawing curved lines particularly difficult?

Also, has anyone been thinking about the possibility of dynamic
graphs?  I.e., graphs where one might want to enter leaves?  Or the
possibility of having a fixed graph where a user might move the nodes
around to make the graph more readable.  CLIM doesn't have any sort of
"smart link" object that would support this, does it?

Thanks,
Robert


From amoroso at mclink.it  Thu May 19 19:49:50 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 19 May 2005 21:49:50 +0200
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <17036.59711.134835.283860@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Thu, 19 May 2005 14:30:07 -0500")
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
Message-ID: <87u0kzf129.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> Also, has anyone been thinking about the possibility of dynamic
> graphs?  I.e., graphs where one might want to enter leaves?  Or the
> possibility of having a fixed graph where a user might move the nodes
> around to make the graph more readable.  CLIM doesn't have any sort of

Scigraph provides a similar feature, i.e. the ability of interactively
editing certain chart attributes such as titles and labels.


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


From rpgoldman at real-time.com  Thu May 19 19:51:43 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 19 May 2005 14:51:43 -0500
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <87u0kzf129.fsf@plato.moon.paoloamoroso.it>
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
	<87u0kzf129.fsf@plato.moon.paoloamoroso.it>
Message-ID: <17036.61007.280321.295019@gargle.gargle.HOWL>

>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:

    PA> rpgoldman at real-time.com writes:
    >> Also, has anyone been thinking about the possibility of dynamic
    >> graphs?  I.e., graphs where one might want to enter leaves?  Or the
    >> possibility of having a fixed graph where a user might move the nodes
    >> around to make the graph more readable.  CLIM doesn't have any sort of

    PA> Scigraph provides a similar feature, i.e. the ability of interactively
    PA> editing certain chart attributes such as titles and labels.

Sorry.  I'm just too much of a CS person and not enough of a
mathematician!  By "graph" I meant the kind with nodes and links, not
the kind with x and y axes...

R


From amoroso at mclink.it  Thu May 19 20:29:58 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 19 May 2005 22:29:58 +0200
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <17036.61007.280321.295019@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Thu, 19 May 2005 14:51:43 -0500")
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
	<87u0kzf129.fsf@plato.moon.paoloamoroso.it>
	<17036.61007.280321.295019@gargle.gargle.HOWL>
Message-ID: <87hdgzez7d.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> Sorry.  I'm just too much of a CS person and not enough of a
> mathematician!  By "graph" I meant the kind with nodes and links, not
> the kind with x and y axes...

Ooops... disregard.

You may try this file:

  simple-graphedit.lisp
  A toy graph editor, written by John Aspinall

in this collection of graphers/browsers:

  ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/gui/clim/clim_2/browsers/0.html


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


From rpgoldman at sift.info  Thu May 19 21:57:02 2005
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Thu, 19 May 2005 16:57:02 -0500
Subject: [mcclim-devel] compose-space question
Message-ID: <17037.2990.7409.180350@gargle.gargle.HOWL>


I have been finding that my application-panes look to be off in width
by the width of their scroll-bars.  When I look at the COMPOSE-SPACE
definitions (these are a little overwhelming for a novice like me) it
looks like the effective method for compose-space for an
application-pane is this one:

(defmethod compose-space ((pane clim-stream-pane) &key width height)
  (let ((w (bounding-rectangle-width (stream-output-history pane)))
        (h (bounding-rectangle-height (stream-output-history pane))))
    (make-space-requirement :width  w :min-width  w :max-width +fill+
                            :height h :min-height h :max-height
                            +fill+)))

This one doesn't have the potential for adding the width of
scrollbars.  Does this look like the right fix?


(defmethod compose-space :around ((pane clim-stream-pane) &key width height)
  (let ((inner-width (call-next-method)))
    (with-slots (scroll-bars) pane
      (cond ((null scroll-bars) inner-width)
	    ((eq scroll-bars :vertical)
	     (space-requirement+ inner-width
				 (compose-space (slot-value (pane-scroller pane) 'vscrollbar))))
	    ((eq scroll-bars :horizontal)
	     (space-requirement+ inner-width
				 (compose-space (slot-value (pane-scroller pane) 'hscrollbar))))
	    (t (space-requirement+
		inner-width
		(space-requirement+
		 (compose-space (slot-value (pane-scroller pane) 'vscrollbar))
		 (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))))))))


From duncan at robotcat.demon.co.uk  Thu May 19 22:28:36 2005
From: duncan at robotcat.demon.co.uk (Duncan Rose)
Date: Thu, 19 May 2005 23:28:36 +0100
Subject: [mcclim-devel] compose-space question
In-Reply-To: <17037.2990.7409.180350@gargle.gargle.HOWL>
Message-ID: <57A115EE-C8B5-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>


On Thursday, May 19, 2005, at 10:57  pm, Robert P. Goldman wrote:

>
> I have been finding that my application-panes look to be off in width
> by the width of their scroll-bars.  When I look at the COMPOSE-SPACE
> definitions (these are a little overwhelming for a novice like me) it
> looks like the effective method for compose-space for an
> application-pane is this one:
>
> (defmethod compose-space ((pane clim-stream-pane) &key width height)
>   (let ((w (bounding-rectangle-width (stream-output-history pane)))
>         (h (bounding-rectangle-height (stream-output-history pane))))
>     (make-space-requirement :width  w :min-width  w :max-width +fill+
>                             :height h :min-height h :max-height
>                             +fill+)))
>
> This one doesn't have the potential for adding the width of
> scrollbars.  Does this look like the right fix?
>
>
> (defmethod compose-space :around ((pane clim-stream-pane) &key width 
> height)
>   (let ((inner-width (call-next-method)))
>     (with-slots (scroll-bars) pane
>       (cond ((null scroll-bars) inner-width)
> 	    ((eq scroll-bars :vertical)
> 	     (space-requirement+ inner-width
> 				 (compose-space (slot-value (pane-scroller pane) 'vscrollbar))))
> 	    ((eq scroll-bars :horizontal)
> 	     (space-requirement+ inner-width
> 				 (compose-space (slot-value (pane-scroller pane) 'hscrollbar))))
> 	    (t (space-requirement+
> 		inner-width
> 		(space-requirement+
> 		 (compose-space (slot-value (pane-scroller pane) 'vscrollbar))
> 		 (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))))))))

I don't think stream panes should know anything about scroll bars; 
these belong to
the scroller pane rather than the stream pane I think (i.e. the stream 
pane
doesn't want to ask for more space to account for scroll bars, rather 
the scroller
pane should add space for bars to the space requirement of the stream 
pane on its
behalf).

That said I tend to find my ideas of what's what are often incorrect ;-)

-Duncan


> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
>



From rpgoldman at sift.info  Thu May 19 22:49:00 2005
From: rpgoldman at sift.info (rpgoldman at sift.info)
Date: Thu, 19 May 2005 17:49:00 -0500
Subject: [mcclim-devel] compose-space question
In-Reply-To: <57A115EE-C8B5-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>
References: <17037.2990.7409.180350@gargle.gargle.HOWL>
	<57A115EE-C8B5-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <17037.6108.995520.213819@gargle.gargle.HOWL>

>>>>> "DR" == Duncan Rose <duncan at robotcat.demon.co.uk> writes:

    DR> On Thursday, May 19, 2005, at 10:57  pm, Robert P. Goldman wrote:

    >> 
    >> I have been finding that my application-panes look to be off in width
    >> by the width of their scroll-bars.  When I look at the COMPOSE-SPACE
    >> definitions (these are a little overwhelming for a novice like me) it
    >> looks like the effective method for compose-space for an
    >> application-pane is this one:

[...snip...]

    DR> I don't think stream panes should know anything about scroll
    DR> bars; these belong to the scroller pane rather than the stream
    DR> pane I think (i.e. the stream pane doesn't want to ask for
    DR> more space to account for scroll bars, rather the scroller
    DR> pane should add space for bars to the space requirement of the
    DR> stream pane on its behalf).

    DR> That said I tend to find my ideas of what's what are often
    DR> incorrect ;-)

I don't exactly understand.  All I know is that my application panes
are clipped to the right in a way that really suggests to me that
McCLIM is trying to display an area w wide, and that it's computing
the w based on the width of the output record, and then it's display w
starting from the outside of the scroller-pane, so that what is
displayed is actually w - (width scroller-pane).  

This was the best guess I had for how to fix it.  :-(  

Maybe this lives in the incremental redisplay protocol, rather than
the space requirement protocol.

I'm still bamboozled by the fact that adding incremental redisplay to
my APPLICATION pane badly gaffed the rendering of my INTERACTOR pane,
whose definition changed not a whit...

Anyone else have any clues?

Thanks,
R


-- 
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

211 N. First St., Suite 300
Minneapolis, MN 55401

Voice:	(612) 384-3454
SIFT offices:  (612) 339-7438
Email:    rpgoldman at SIFT.info


From rpgoldman at real-time.com  Fri May 20 01:53:46 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 19 May 2005 20:53:46 -0500
Subject: [mcclim-devel] compose-space question
In-Reply-To: <57A115EE-C8B5-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>
References: <17037.2990.7409.180350@gargle.gargle.HOWL>
	<57A115EE-C8B5-11D9-84D9-000A9577B8A2@robotcat.demon.co.uk>
Message-ID: <17037.17194.9553.447477@gargle.gargle.HOWL>

If it's not a compose-space problem, I'm wondering about the code in
incremental-redisplay.lisp.  Could it be the case that 

(defmethod incremental-redisplay ((stream updating-output-stream-mixin) position
                                  erases moves draws erase-overlapping move-overlapping)
  (declare (ignore position))
  (let ((history (stream-output-history stream)))
    (with-output-recording-options (stream :record nil :draw t)
      (loop
          for (nil br) in erases
          do (erase-rectangle stream br))
      (loop
          for (nil old-bounding) in moves
          do (erase-rectangle stream old-bounding))
      (loop
          for (nil br) in erase-overlapping
          do (erase-rectangle stream br))
      (loop
          for (nil old-bounding) in move-overlapping
          do (erase-rectangle stream old-bounding)))
    (loop
        for (r) in moves
        do (replay r stream))
    (loop
        for (r) in draws
        do (replay r stream))
    (let ((res +nowhere+))
      (loop for (r) in erase-overlapping do (setf res (region-union res r)))
      (loop for (r) in move-overlapping do (setf res (region-union res r)))
      (replay history stream res)) ))

Does the Wrong Thing when the STREAM argument is an application pane,
ignoring the viewport stuff, and so the region operations are done
with the wrong bounding area?  In particular, it seems like the draws
are clipped, possibly because the region-union doesn't take into
account the scroll-bar area.

This is just a theory, and actually doesn't feel quite right to me.
But I'm bamboozled for why the stream has this odd clipping.  Can
anyone confirm or disprove it?  Better yet, does anyone have a better
theory to offer?

Thanks,
R


From amoroso at mclink.it  Fri May 20 09:27:38 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 20 May 2005 11:27:38 +0200
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <17036.59711.134835.283860@gargle.gargle.HOWL>
	(rpgoldman@real-time.com's
	message of "Thu, 19 May 2005 14:30:07 -0500")
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
Message-ID: <87hdgydz79.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> Also, has anyone been thinking about the possibility of dynamic
> graphs?  I.e., graphs where one might want to enter leaves?  Or the

Other possibly relevant code:

  class browser
  http://bauhh.dyndns.org:8000/hacklets/class-browser.lisp

  Petri net editor (does not work with McCLIM)
  http://www.sts.tu-harburg.de/~mi.wessel/papers/petri2.lisp

  graphers collection (see clim.grapher, which seems to be based on CLIM 1.x)
  ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/gui/graphers/0.html


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


From rpgoldman at real-time.com  Fri May 20 13:12:06 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Fri, 20 May 2005 08:12:06 -0500
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <87hdgydz79.fsf@plato.moon.paoloamoroso.it>
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
	<87hdgydz79.fsf@plato.moon.paoloamoroso.it>
Message-ID: <17037.57894.738981.487133@gargle.gargle.HOWL>


It was interesting to me that the grapher Paolo pointed to last time
did NOT use format-graph-from-roots.  I don't know whether this was
because that grapher was built before format-graph-from-roots was
generally available (I think it's always been in CLIM), or because the
graph layout algorithm in format-graph-from-roots is not very amenable
to having the user intervene into graph layout.

It might be instructive to compare format-graph-from-roots with the
grapher that appears in Garnet, which is based on a cells-like
constraint architecture.  In that framework there are edge objects
that are constrained to be attached to points on graph nodes.  I don't
see how one could really build a user-modifiable graph w/o such
objects.  On the other hand, I'm not sure how one could introduce such
entities, since CLIM doesn't necessarily easily admit for propagation
cycles.  I.e., such objects would only work in panes with particular
sorts of display-functions.

BTW, on a dual SMP 3G with 1G of RAM last night, I tried to layout a
graph with approx 5K nodes, and McCLIM went into GC thrashing and took
the lisp process down (which I take to be an accomplishment).  I hope
to be able to have some time to run the profiler and try to figure out
what might be optimized --- I haven't tweaked my compiler settings at
all, so this might simply be badly-compiled iterative code eating the
stack...

It's too early, and I'm probably rambling, so I'll sign off...


From amoroso at mclink.it  Sun May 22 11:45:29 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sun, 22 May 2005 13:45:29 +0200
Subject: [mcclim-devel] question about curves and formatting graphs
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
	<87hdgydz79.fsf@plato.moon.paoloamoroso.it>
	<17037.57894.738981.487133@gargle.gargle.HOWL>
Message-ID: <87u0kvtrfq.fsf@plato.moon.paoloamoroso.it>

rpgoldman at real-time.com writes:

> It was interesting to me that the grapher Paolo pointed to last time
> did NOT use format-graph-from-roots.  I don't know whether this was

In my reading of CLIM literature and code, I don't remember running
across the use of format-graph-from-roots for dynamic graphs.


> BTW, on a dual SMP 3G with 1G of RAM last night, I tried to layout a
> graph with approx 5K nodes, and McCLIM went into GC thrashing and took
> the lisp process down (which I take to be an accomplishment).  I hope

Can you try evaluating this form at the CLIM Listener?

  (time (clim-listener::com-show-class-subclasses t))

I don't know how many nodes the generated graph contains, but there
are many.  It takes under a second on my 2.8 GHz Pentium IV machine
with 2 GB of RAM.


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


From ahefner at gmail.com  Wed May 25 00:21:26 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Tue, 24 May 2005 20:21:26 -0400
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <17036.59711.134835.283860@gargle.gargle.HOWL>
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
Message-ID: <31ffd3c405052417213200fe22@mail.gmail.com>

On 5/19/05, rpgoldman at real-time.com <rpgoldman at real-time.com> wrote:
> 
> If one wanted to draw curvy lines in McCLIM, is there any way of doing
> this?  I had assumed, foolish me, that this could be done using Bezier
> curves, but now I see that those were an Allegro extension to the
> standard, and not part of CLIM 2.0....

Lacking any better ideas, I'd break the curves down into line segments
and draw them as such.

> Also, has anyone been thinking about the possibility of dynamic
> graphs?  I.e., graphs where one might want to enter leaves?  Or the
> possibility of having a fixed graph where a user might move the nodes
> around to make the graph more readable.  CLIM doesn't have any sort of
> "smart link" object that would support this, does it?

I don't have any thoughts on dynamic graphs, but 'adjustable' graphs
are a fine idea. I've been interested in such a thing for a while now,
but lacked any real immediate need for it. Now that someone else has
mentioned it, I've been inspired to take a little time to bash out an
implementation.

I started with Tim Moore's dragndrop example, extending the basic ide
aby implementing draggable presentations via a new
draggable-presentation and a command and translator to invoke the
dragging. Adding :record-type 'draggable-presentation in calls to
clim:present makes presentaitons draggable. This allowed me to drag
presentations within graph nodes around, but with no knowledge of the
graph edges. Clearly some work on the graph formatter is need. (this
code is attached as draggable-presentations.lisp)

To remedy this, I've attached an experimental patch which refactors
graph edge layout and incorporates the needed bookkeeping to associate
a graph node with its edges. This allowed my second attempt, also
attached, to drag graph nodes around, updating the edges correctly.

Perhaps this is of some interest.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graph-edge-tracking.patch
Type: text/x-patch
Size: 4476 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050524/2428a38d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draggable-presentations.lisp
Type: application/octet-stream
Size: 1559 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050524/2428a38d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draggable-graph-1.lisp
Type: application/octet-stream
Size: 3364 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050524/2428a38d/attachment-0001.obj>

From csr21 at cam.ac.uk  Wed May 25 10:16:55 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Wed, 25 May 2005 11:16:55 +0100
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <31ffd3c405052417213200fe22@mail.gmail.com> (Andy Hefner's
	message of "Tue, 24 May 2005 20:21:26 -0400")
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
	<31ffd3c405052417213200fe22@mail.gmail.com>
Message-ID: <sq1x7vehk8.fsf@cam.ac.uk>

Andy Hefner <ahefner at gmail.com> writes:

> Perhaps this is of some interest.

Well, it's definitely fun to play with! :-)

Cheers,

Christophe


From christian.lynbech at ericsson.com  Thu May 26 12:08:26 2005
From: christian.lynbech at ericsson.com (Christian Lynbech)
Date: Thu, 26 May 2005 14:08:26 +0200
Subject: [mcclim-devel] ASDF building problems on CMUCL
Message-ID: <86ll62jikl.fsf@ericsson.com>

It seems as if there are some problems with ASDF module specification
for scigraph in current versions of McCLIM CVS.

When I try to build as per the instructions (using cmucl), the build
stalls after loading the module specs and it does not matter whether I
load system.lisp or mcclim.asd.

A stacktrace is show below.

Outcommenting the definition of the scigraph system removes the
problem and McCLIM builds and runs without problems. It would thus
appear that the scigraph system triggers an infinite loop somewhere in
ASDF.

The problem appears with todays CVS and the version labelled as
McCLIM-0-9-1; it appears that the version McCLIM-0-9 only works with
mkdefsystem enabled lisps.

I am running on a Debian system with the following versions:

    ii  common-lisp-controller             4.14                   
    ii  cmucl                              19a-release-20040728-11
    ii  cl-asdf                            1.86-4                 



0] backtrace

0: (ASDF::PARSE-COMPONENT-FORM NIL
                               (:MODULE "scigraph" :PATHNAME
                                #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/"
                                :DEPENDS-ON ...))
1: (ASDF::PARSE-COMPONENT-FORM 2

                               NIL
                               (:MODULE "scigraph" :PATHNAME
                                #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/"
                                :DEPENDS-ON ...))[:EXTERNAL]
2: (LISP::SLOLOAD
    #<Stream for file "/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd">)
3: (LISP::INTERNAL-LOAD #p"mcclim.asd"
                        #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd"
                        :ERROR
                        :SOURCE)
4: (LISP::INTERNAL-LOAD #p"mcclim.asd"
                        #p"/net/daphne/usr/local/home/tedchly/Tools/ANON-CVS/mcclim/mcclim.asd"
                        :ERROR
                        NIL)
5: (LOAD "mcclim.asd" :VERBOSE NIL :PRINT ...)
6: (EXTENSIONS:INTERACTIVE-EVAL (LOAD "mcclim.asd"))
7: (LISP::%TOP-LEVEL)
8: ((LABELS LISP::RESTART-LISP
      EXTENSIONS:SAVE-LISP))




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



From amoroso at mclink.it  Thu May 26 18:29:26 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Thu, 26 May 2005 20:29:26 +0200
Subject: [mcclim-devel] ASDF building problems on CMUCL
In-Reply-To: <86ll62jikl.fsf@ericsson.com> (Christian Lynbech's message of
	"Thu, 26 May 2005 14:08:26 +0200")
References: <86ll62jikl.fsf@ericsson.com>
Message-ID: <87acmhvo1l.fsf@plato.moon.paoloamoroso.it>

Christian Lynbech <christian.lynbech at ericsson.com> writes:

> It seems as if there are some problems with ASDF module specification
> for scigraph in current versions of McCLIM CVS.
[...]
> McCLIM-0-9-1; it appears that the version McCLIM-0-9 only works with
> mkdefsystem enabled lisps.

I confirm this.


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


From rpgoldman at real-time.com  Thu May 26 19:00:45 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 26 May 2005 14:00:45 -0500
Subject: [mcclim-devel] question about curves and formatting graphs
In-Reply-To: <87u0kvtrfq.fsf@plato.moon.paoloamoroso.it>
References: <17036.59711.134835.283860@gargle.gargle.HOWL>
	<87hdgydz79.fsf@plato.moon.paoloamoroso.it>
	<17037.57894.738981.487133@gargle.gargle.HOWL>
	<87u0kvtrfq.fsf@plato.moon.paoloamoroso.it>
Message-ID: <17046.7389.812556.698284@gargle.gargle.HOWL>

>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:

    PA> rpgoldman at real-time.com writes:
    >> It was interesting to me that the grapher Paolo pointed to last time
    >> did NOT use format-graph-from-roots.  I don't know whether this was

    PA> In my reading of CLIM literature and code, I don't remember running
    PA> across the use of format-graph-from-roots for dynamic graphs.


    >> BTW, on a dual SMP 3G with 1G of RAM last night, I tried to layout a
    >> graph with approx 5K nodes, and McCLIM went into GC thrashing and took
    >> the lisp process down (which I take to be an accomplishment).  I hope

    PA> Can you try evaluating this form at the CLIM Listener?

    PA>   (time (clim-listener::com-show-class-subclasses t))

    PA> I don't know how many nodes the generated graph contains, but there
    PA> are many.  It takes under a second on my 2.8 GHz Pentium IV machine
    PA> with 2 GB of RAM.

Well, that was very fast for me, too:

CL-USER(9): (clim-listener:run-listener)
; cpu time (non-gc) 1,100 msec user, 10 msec system
; cpu time (gc)     340 msec user, 0 msec system
; cpu time (total)  1,440 msec user, 10 msec system
; real time  1,446 msec
; space allocation:
;  297,880 cons cells, 12,937,112 other bytes, 0 static bytes

I will check and see what's up with my MDP's state space that makes it
go out to lunch.

Sorry to be so dilatory.  Travel and the resulting email avalanche to
handle are going to keep me slow investigating this.

R


From frido at q-software-solutions.de  Sun May 29 15:38:23 2005
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Sun, 29 May 2005 17:38:23 +0200
Subject: [mcclim-devel] mcclim and Umlaute?
In-Reply-To: <86ll62jikl.fsf@ericsson.com> (Christian Lynbech's message of
	"Thu, 26 May 2005 14:08:26 +0200")
References: <86ll62jikl.fsf@ericsson.com>
Message-ID: <87wtpiujo0.fsf@flarge.here>

sorry, I have not idea what mcclim does with German Umlauts. 
I'm using sbcl with :sb-unicode in the *features* list but if there
e.g a ? or even a ? in a text, I will be thrown into the debugger. 

What do I have to do to make Umlauts running with SBCL?

Regards
Friedrich


From csr21 at cam.ac.uk  Sun May 29 15:52:43 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Sun, 29 May 2005 16:52:43 +0100
Subject: [mcclim-devel] mcclim and Umlaute?
In-Reply-To: <87wtpiujo0.fsf@flarge.here> (Friedrich Dominicus's message of
	"Sun, 29 May 2005 17:38:23 +0200")
References: <86ll62jikl.fsf@ericsson.com> <87wtpiujo0.fsf@flarge.here>
Message-ID: <sqvf52ni5w.fsf@cam.ac.uk>

Friedrich Dominicus <frido at q-software-solutions.de> writes:

> sorry, I have not idea what mcclim does with German Umlauts. 
> I'm using sbcl with :sb-unicode in the *features* list but if there
> e.g a ? or even a ? in a text, I will be thrown into the debugger. 

On the assumption that you're using the CLX backend, I think the
relevant piece of code is the default :TRANSLATE function in clx.

> What do I have to do to make Umlauts running with SBCL?

Take a look at translate.lisp in climacs CVS, and see if that can be
adapted to your needs.

(Note: the issue is more complex than this simple "solution" might
imply.  I'm assuming that you don't actually want to think about the
complexity of managing font sets with differing encodings, but please
don't let me stop you.)

Cheers,

Christophe


From frido at q-software-solutions.de  Mon May 30 05:41:03 2005
From: frido at q-software-solutions.de (Friedrich Dominicus)
Date: Mon, 30 May 2005 07:41:03 +0200
Subject: [mcclim-devel] mcclim and Umlaute?
In-Reply-To: <sqvf52ni5w.fsf@cam.ac.uk> (Christophe Rhodes's message of
	"Sun, 29 May 2005 16:52:43 +0100")
References: <86ll62jikl.fsf@ericsson.com> <87wtpiujo0.fsf@flarge.here>
	<sqvf52ni5w.fsf@cam.ac.uk>
Message-ID: <87y89xfez4.fsf@flarge.here>

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

> Friedrich Dominicus <frido at q-software-solutions.de> writes:
>
>> sorry, I have not idea what mcclim does with German Umlauts. 
>> I'm using sbcl with :sb-unicode in the *features* list but if there
>> e.g a ?? or even a ?? in a text, I will be thrown into the debugger. 
>
> On the assumption that you're using the CLX backend, I think the
> relevant piece of code is the default :TRANSLATE function in clx.
Yes I use CLX and I found the relevant pieces e.g:
#-unicode
(defun translate (src src-start src-end afont dst dst-start)
  ;; This is for replacing the clx-translate-default-function


but also
; Yes, the following is a nasty hack.
; It's just a proof of concept, I'll try not to commit it :]
; If it does get committed, it shouldn't affect anyone much...

#+unicode
(defun translate (source source-start source-end initial-font destination destination-start)
  ; do the first character especially
  (let* ((code   (char-code (char source source-start)))
         (result (fontset-point code)))

in medium.lisp in
McCLIM/Backends/CLX/

well my featurs list says that :sb-unicode is part of it but not
:unicode. 

However something is there and I'm now wondering:
a) wether to use it
b) if that is sufficient 





>
>> What do I have to do to make Umlauts running with SBCL?
>
> Take a look at translate.lisp in climacs CVS, and see if that can be
> adapted to your needs.
Must be sitting around here somewhere.
>
> (Note: the issue is more complex than this simple "solution" might
> imply.  I'm assuming that you don't actually want to think about the
> complexity of managing font sets with differing encodings, but please
> don't let me stop you.)
I was afraid that that's the case and asked therefor if someone more
in "CLIM" has an idea. I'm just starting to learn it and well at the
moment I have a rough understanding on how it works. But there are so
many functions, macros etc, that it's a long way to go till I get a
base understanding...

Besides it seems that McCLIM /= CLIM in some aspects.

Just one example this compiles and works in McCLIM
(define-command-table file-menu
    :inherit-from '(user-command-table)
    :menu (("Load" :command com-load-account)
           ("Quit" :command com-quit-application)))


but LWs CLIM accepts that too but while starting the application I
got:
(main)

Error: Command table NIL not found
  1 (abort) Return to level 0.
  2 Return to top loop level 0.

That's really encouriging, because:
(find-command-table 'USER-COMMAND-TABLE)
#<STANDARD-COMMAND-TABLE USER-COMMAND-TABLE 21F0D66C>

but of course something here might be wrong for LW-CLIM
(define-application-frame clim-account ()
  ((current-account :initform nil :accessor current-account)
   (interaction-pane))
  (:pointer-documentation :t)
  (:menu-bar
        (("File"   :menu file-menu)))
  (:panes 
   (interactor :interactor)
   (actual-account :application
            :incremental-redisplay t
            :display-function #'display-current-account)
   (accounts  :application
              :incremental-redisplay t
              :display-function #'display-accounts))
  (:layouts
   (default
       (vertically ()
         (horizontally ()
           actual-account accounts)
         interactor))))


which seems to be fine for McCLIM.

So the C in CLIM seems to be a overoptimistic....

but that's a different story....

Regards
Friedrich