From amoroso at mclink.it  Sat Jan  1 18:08:45 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 01 Jan 2005 19:08:45 +0100
Subject: [mcclim-devel] Bug list page at McCLIM CLiki: new resource
In-Reply-To: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's
	message of "Tue, 28 Dec 2004 12:25:48 +0100")
References: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it>
Message-ID: <87acrtyqc2.fsf@plato.moon.paoloamoroso.it>

Paolo Amoroso <amoroso at mclink.it> writes:

> I have created a simple McCLIM bug list at:
>
>   http://mcclim.cliki.net/Bug

I have added all the bugs reported to the mailing list in 2004 and not
yet fixed.  I guess most of the older ones were fixed in some way, and
it would be a lot of work to check very old reports against current
code.  If there are still very old bugs, they will be probably
"rediscovered".

Note that I have added entries only when I could do some kind of
direct check, or I was sure from memory.  I have deliberately left out
from the list all bugs related to Lisp implementations or operating
systems to which I have no access, most notably OpenMCL, Allegro CL
and LispWorks.  Users of those systems are encouraged to add more
entries if appropriate.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From amoroso at mclink.it  Mon Jan  3 09:03:53 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 03 Jan 2005 10:03:53 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
Message-ID: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>

When I run a McCLIM application, according to `top' CPU usage is
constantly above 95% or so, and the KDE System Monitor reports about
50% for CPU 1.  Here is a typical `top' entry when running the CLIM
Listener:

top - 09:52:31 up 3 min,  1 user,  load average: 0.37, 0.23, 0.10
Tasks:  78 total,   2 running,  76 sleeping,   0 stopped,   0 zombie
Cpu(s): 14.3% us, 36.0% sy,  0.0% ni, 49.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   2075012k total,   301272k used,  1773740k free,    11244k buffers
Swap:  2004420k total,        0k used,  2004420k free,   165556k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2728 paolo     25   0 1284m  37m  45m S 99.9  1.8   0:18.87 cmucl
[...]

When only the CMUCL toplevel is running, it is below 1%.  Why is CPU
usage so high with McCLIM applications?  Is it real or some sort of
measuring artifact?

I use the latest McCLIM CVS sources with CMUCL Snapshot 2004-12 under
Slackware Linux 10.0.  My PC is a 2.8 GHz Pentium IV with 2 GB of RAM.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From amoroso at mclink.it  Mon Jan  3 13:06:40 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 03 Jan 2005 14:06:40 +0100
Subject: [mcclim-devel] Running McCLIM and CL-SDL together: is it possible?
Message-ID: <87652e8xwf.fsf@plato.moon.paoloamoroso.it>

Is it possible to run a McCLIM and a CL-SDL (cl-sdl.sourceforge.net)
application within the same Lisp image?

When I try this with CMUCL, only the CL-SDL application runs and the
McCLIM one--say, the CLIM Listener--is frozen, i.e. the window is not
refreshed and does not process input events.  Things do not change if
I start the CLIM Listener with :new-process t.

I understand that the OpenGL/SDL event loop is a bit "pervasive", but
I wonder whether there are any workarounds.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From david.golden at oceanfree.net  Mon Jan  3 14:51:44 2005
From: david.golden at oceanfree.net (David Golden)
Date: Mon, 3 Jan 2005 14:51:44 +0000
Subject: [mcclim-devel] newbie niggles and whines.
In-Reply-To: <87acrtyqc2.fsf@plato.moon.paoloamoroso.it>
References: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it>
	<87acrtyqc2.fsf@plato.moon.paoloamoroso.it>
Message-ID: <200501031451.44660.david.golden@oceanfree.net>

I played briefly with McCLIM (in CMUCL on linux) over the holidays, and 
now I have a list of niggles and whines.  These are meant as 
constructive minor first-impressions criticisms, I realise fully things 
are still being actively developed! - McCLIM is generally quite cool.

 I don't want to clutter the bug list page with them as several are 
vague and not necessarily bugs, but because I start work again tomorrow 
and probably won't have time to follow any up until next xmas or 
something, here follows brain dump for others to pick up on, or not:

1. Listener (shows symptoms anyway, problem may lie deeper):  Super-key 
handling is broken? super key presses are detected, but any mouse 
movement or button press first seems to cancel the super key, thus 
making it impossible to use e.g. s-L

Xev shows X isn't at fault (I think) - can anyone confirm?

2. Listener: Tab key  Completion.   Completes after tab when you enter 
two or more characters, but puts in some sort of a  "[]" 
nonprinting-character sign after one?   Similarly, space-key completion 
doesn't after one character, only completes after two?  Presumably this 
behaviour is a bug rather than a feature.

3. Listener: Completion - showing possibilities? like bash, or just by 
dropping down a keyboard-navigable variant of the right click menu?

4. Listener: deletion on the command line.  Probably a feature that's 
coming just not implemented. Once the listener displays the e.g. "Show 
Class Subclasses (class)" , you can't "go back" with the backspace key 
anymore - it just outputs "(class)" again.

5. Listener: ability to "press enter" with the mouse? Huh? you say - 
well, it's like this - the last thing I select for a one-arg command is 
often something I click with the mouse (or in my case stylus, 
actually...).   - maybe the current command line should be clickable to 
perform the action if it becomes valid, like previous command lines are 
once they're done once.  While this might be computationally somewhat 
expensive, people have absurdly fast computers these days.

6. (whine) Text Selection. Yes, I realise it's a brand-new feature. But 
wouldn't it be nicer to use click v.s. drag discrimination rather than 
the unusual shift-key? i.e. if the mouse moves more than 10 pixels
over the text while the LMB is down, assume it's a highlight action
rather than a click action? (Of course, there's also drag-drop to worry 
about).

7. (wishlist note)  Accessibility or at least keyboard gadget 
navigation...

8. (whine/opinion) Dialogs. "exit" and "abort" to me don't seem strongly 
differentiated enough - exit really doesn't say to me "exit and use 
these values".  Yes, they're in the spec as the defaults (which is 
probably enough to decide it, I guess...), but  e.g. "Accept" (or 
"Okay" or "Use") / "Cancel" would be so much more in-line with modern 
usage.   

9.  Look-and-feel:  Antialiased fonts on linux by default.  Yes, XRENDER 
etc. lowlevel support belongs in clx distribution, not McCLIM - but if 
it is available, McCLIM should really default to it at this stage on 
linux, IMHO.  Again, this is probably planned, but hey.


From chandler at unmutual.info  Mon Jan  3 15:26:27 2005
From: chandler at unmutual.info (Brian Mastenbrook)
Date: Mon, 3 Jan 2005 09:26:27 -0600
Subject: [mcclim-devel] newbie niggles and whines.
In-Reply-To: <200501031451.44660.david.golden@oceanfree.net>
References: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it>
	<87acrtyqc2.fsf@plato.moon.paoloamoroso.it>
	<200501031451.44660.david.golden@oceanfree.net>
Message-ID: <D6080A5E-5D9B-11D9-9ADB-000D933F67D6@unmutual.info>

On Jan 3, 2005, at 8:51 AM, David Golden wrote:

> 9.  Look-and-feel:  Antialiased fonts on linux by default.  Yes, 
> XRENDER
> etc. lowlevel support belongs in clx distribution, not McCLIM - but if
> it is available, McCLIM should really default to it at this stage on
> linux, IMHO.  Again, this is probably planned, but hey.

XRENDER doesn't do antialiased fonts; it simply has protocol primitives 
for drawing with alpha blending. All applications which use XRENDER to 
display antialiased fonts are also using the Freetype library (in the 
form of libXft) to do the displaying, which requires a nontrivial 
amount of FFI.

Now, there is a FFI binding to Freetype in the Experimental section, 
but it's for CMUCL only and I have no idea how to use it. IWBNI this 
worked on both SBCL and CMUCL, and maybe even used UFFI. The other 
option is to use Xach Beane's truetype-in-lisp to parse a few fonts and 
convert them to curves which can be loaded and displayed with no FFI. 
The Bitstream Vera family of fonts is under an open license for the 
GNOME project; dumping these in some kind of sexpr format describing 
the curves shouldn't be too hard, but drawing them is another matter.
--
Brian Mastenbrook
http://www.iscblog.info/
http://www.cs.indiana.edu/~bmastenb/



From amoroso at mclink.it  Mon Jan  3 16:07:59 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 03 Jan 2005 17:07:59 +0100
Subject: [mcclim-devel] newbie niggles and whines.
In-Reply-To: <200501031451.44660.david.golden@oceanfree.net> (David Golden's
	message of "Mon, 3 Jan 2005 14:51:44 +0000")
References: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it>
	<87acrtyqc2.fsf@plato.moon.paoloamoroso.it>
	<200501031451.44660.david.golden@oceanfree.net>
Message-ID: <87u0pypkbk.fsf@plato.moon.paoloamoroso.it>

David Golden <david.golden at oceanfree.net> writes:

> 4. Listener: deletion on the command line.  Probably a feature that's 
> coming just not implemented. Once the listener displays the e.g. "Show 
> Class Subclasses (class)" , you can't "go back" with the backspace key 
> anymore - it just outputs "(class)" again.

Real men use Emacs keybindings :)

You can delete the whole line with C-u, or the word to the left of the
cursor with M-Backspace.  Or you may use the following:

1) C-b or M-b to move the cursor left
2) C-d or C-k to delete part or all of the rightmost part of the line


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From strandh at labri.fr  Mon Jan  3 16:47:53 2005
From: strandh at labri.fr (Robert Strandh)
Date: Mon, 3 Jan 2005 17:47:53 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
In-Reply-To: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
References: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
Message-ID: <16857.30521.442390.868730@serveur5.labri.fr>

Paolo Amoroso writes:
 > When I run a McCLIM application, according to `top' CPU usage is
 > constantly above 95% or so, and the KDE System Monitor reports about
 > 50% for CPU 1.  Here is a typical `top' entry when running the CLIM
 > Listener:
 > 
 > top - 09:52:31 up 3 min,  1 user,  load average: 0.37, 0.23, 0.10
 > Tasks:  78 total,   2 running,  76 sleeping,   0 stopped,   0 zombie
 > Cpu(s): 14.3% us, 36.0% sy,  0.0% ni, 49.7% id,  0.0% wa,  0.0% hi,  0.0% si
 > Mem:   2075012k total,   301272k used,  1773740k free,    11244k buffers
 > Swap:  2004420k total,        0k used,  2004420k free,   165556k cached
 > 
 >   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 >  2728 paolo     25   0 1284m  37m  45m S 99.9  1.8   0:18.87 cmucl
 > [...]
 > 
 > When only the CMUCL toplevel is running, it is below 1%.  Why is CPU
 > usage so high with McCLIM applications?  Is it real or some sort of
 > measuring artifact?
 > 
 > I use the latest McCLIM CVS sources with CMUCL Snapshot 2004-12 under
 > Slackware Linux 10.0.  My PC is a 2.8 GHz Pentium IV with 2 GB of RAM.

I think it has to do with CMUCL multi process implementation.  I was
told that if you start the idle loop, then this problem will go away. 

-- 
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 david.golden at oceanfree.net  Mon Jan  3 16:52:28 2005
From: david.golden at oceanfree.net (David Golden)
Date: Mon, 3 Jan 2005 16:52:28 +0000
Subject: [mcclim-devel] newbie niggles and whines.
In-Reply-To: <87u0pypkbk.fsf@plato.moon.paoloamoroso.it>
References: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it>
	<200501031451.44660.david.golden@oceanfree.net>
	<87u0pypkbk.fsf@plato.moon.paoloamoroso.it>
Message-ID: <200501031652.28534.david.golden@oceanfree.net>

On Monday 03 January 2005 16:07, Paolo Amoroso wrote:
y use the following:

> 1) C-b or M-b to move the cursor left

Well, yes, but... try this - with the "(class)" hint up, press C-b once, 
then press backspace (<-)  - once the editing has "gotten started" with 
C-b, the backspace works!  But backspace can't initiate the deletion 
once the "(class)" hint is up (it can until the hint is displayed). 





From amoroso at mclink.it  Mon Jan  3 17:08:48 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 03 Jan 2005 18:08:48 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
In-Reply-To: <16857.30521.442390.868730@serveur5.labri.fr> (Robert Strandh's
	message of "Mon, 3 Jan 2005 17:47:53 +0100")
References: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
	<16857.30521.442390.868730@serveur5.labri.fr>
Message-ID: <878y7aphi7.fsf@plato.moon.paoloamoroso.it>

Robert Strandh <strandh at labri.fr> writes:

> Paolo Amoroso writes:
>  > When I run a McCLIM application, according to `top' CPU usage is
>  > constantly above 95% or so, and the KDE System Monitor reports about
[...]
> I think it has to do with CMUCL multi process implementation.  I was
> told that if you start the idle loop, then this problem will go away. 

This works.  But the way the idle loop is started in CMUCL makes it
difficult to deliver applications.

If I deliver a McCLIM application containing the CMUCL executable, a
Lisp image, and a shell script that launches the executable with the
image as an argument, the high CPU usage is still there.  Since the
multiprocessing initialization function does not return, the only way
I know of invoking it is calling MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS
interactively.  But I can not expect users to do that: I would like to
hide the Lisp toplevel to them.

It might be possible to change CMUCL so that it always starts the idle
loop.  If this is not done by default, there may be some stability
issues.  But this is probably best discussed in the CMUCL mailing
list.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From csr21 at cam.ac.uk  Mon Jan  3 16:30:27 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Mon, 03 Jan 2005 16:30:27 +0000
Subject: [mcclim-devel] deftype coordinate
Message-ID: <sqis6eqxuk.fsf@cam.ac.uk>

Hi,

A little bit of empirical measurement by Juho Snellman reveals that in
certain circumstances, such as waving the mouse over the gsharp
window, mcclim under sbcl spends 70% or so of its time in bignum
operations related to converting floating point numbers to rational
ones.  I believe that this is an artifact of the "permissive"
coordinate type (currently set to real, apparently after a version of
cmucl started doing some kind of type checking or inference).

Attached is a patch which restores the double-float coordinate type,
along with at least some of the necessary coercions here and there.
I'd probably not merge this directly, because I'm still confused over
when something is a coordinate and when it isn't.

I believe that bounding-rectangles and regions are coordinate-based,
and that output-records are rational-based, at least in terms of their
position.  If this is the case, I'd suggest adding completely separate
slots for the two "worlds"; rather than having coercions on accesses,
there would be coupled setter methods.  In this patch, I've instead
been somewhat conservative: anywhere where I was uncertain what was
happening, I inserted a call to the COORDINATE function.

This version has survived a certain amount of rudimentary testing in
the listener and gsharp.  I'd be interested to know if there is any
perceptual speed change, and also whether there are coordinate-related
bugs remaining.

[ this patch was driven by a branch of SBCL in CVS tagged as
  clos-typechecking-branch, which includes type checks for most (setf
  slot-value), (setf accessor) and make-instance calls ]

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


Cheers,

Christophe

From strandh at labri.fr  Mon Jan  3 17:14:15 2005
From: strandh at labri.fr (Robert Strandh)
Date: Mon, 3 Jan 2005 18:14:15 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
In-Reply-To: <878y7aphi7.fsf@plato.moon.paoloamoroso.it>
References: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
	<16857.30521.442390.868730@serveur5.labri.fr>
	<878y7aphi7.fsf@plato.moon.paoloamoroso.it>
Message-ID: <16857.32103.861449.518018@serveur5.labri.fr>

Paolo Amoroso writes:
 > > I think it has to do with CMUCL multi process implementation.  I was
 > > told that if you start the idle loop, then this problem will go away. 
 > 
 > This works.  But the way the idle loop is started in CMUCL makes it
 > difficult to deliver applications.
 > 
 > If I deliver a McCLIM application containing the CMUCL executable, a
 > Lisp image, and a shell script that launches the executable with the
 > image as an argument, the high CPU usage is still there.  Since the
 > multiprocessing initialization function does not return, the only way
 > I know of invoking it is calling MP::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS
 > interactively.  But I can not expect users to do that: I would like to
 > hide the Lisp toplevel to them.

I fully agree with you.  I kept forgetting to do that so I had
processes taking up 100% CPU on some of our servers.  I therefore
switched to SBCL that does not have this problem. 

 > It might be possible to change CMUCL so that it always starts the idle
 > loop.  If this is not done by default, there may be some stability
 > issues.  But this is probably best discussed in the CMUCL mailing
 > list.

That or the #lisp IRC channel. 

Take care (and happy new year by the way),
-- 
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 Jan  3 17:37:34 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 03 Jan 2005 18:37:34 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
In-Reply-To: <16857.32103.861449.518018@serveur5.labri.fr> (Robert Strandh's
	message of "Mon, 3 Jan 2005 18:14:15 +0100")
References: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
	<16857.30521.442390.868730@serveur5.labri.fr>
	<878y7aphi7.fsf@plato.moon.paoloamoroso.it>
	<16857.32103.861449.518018@serveur5.labri.fr>
Message-ID: <874qhypg69.fsf@plato.moon.paoloamoroso.it>

Robert Strandh <strandh at labri.fr> writes:

> I fully agree with you.  I kept forgetting to do that so I had
> processes taking up 100% CPU on some of our servers.  I therefore
> switched to SBCL that does not have this problem. 

I don't mind SBCL.  But, at least for delivery, I prefer CMUCL to
extract every bit of additional performance.  In the case of a
graphical system like McCLIM, this does help.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From strandh at labri.fr  Mon Jan  3 17:56:25 2005
From: strandh at labri.fr (Robert Strandh)
Date: Mon, 3 Jan 2005 18:56:25 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
In-Reply-To: <874qhypg69.fsf@plato.moon.paoloamoroso.it>
References: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
	<16857.30521.442390.868730@serveur5.labri.fr>
	<878y7aphi7.fsf@plato.moon.paoloamoroso.it>
	<16857.32103.861449.518018@serveur5.labri.fr>
	<874qhypg69.fsf@plato.moon.paoloamoroso.it>
Message-ID: <16857.34633.212932.76595@serveur5.labri.fr>

Paolo Amoroso writes:
 > Robert Strandh <strandh at labri.fr> writes:
 > 
 > > I fully agree with you.  I kept forgetting to do that so I had
 > > processes taking up 100% CPU on some of our servers.  I therefore
 > > switched to SBCL that does not have this problem. 
 > 
 > I don't mind SBCL.  But, at least for delivery, I prefer CMUCL to
 > extract every bit of additional performance.  In the case of a
 > graphical system like McCLIM, this does help.

Either way, I am sure the CMUCL maintainers would want McCLIM to run
well on CMUCL.  It would therefore be a good idea to ask them whether
there is something that can be done to fix this problem. 

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------


From david.golden at oceanfree.net  Mon Jan  3 18:44:24 2005
From: david.golden at oceanfree.net (David Golden)
Date: Mon, 3 Jan 2005 18:44:24 +0000
Subject: [mcclim-devel] newbie niggles and whines.
In-Reply-To: <D6080A5E-5D9B-11D9-9ADB-000D933F67D6@unmutual.info>
References: <87d5wuslz7.fsf@plato.moon.paoloamoroso.it>
	<200501031451.44660.david.golden@oceanfree.net>
	<D6080A5E-5D9B-11D9-9ADB-000D933F67D6@unmutual.info>
Message-ID: <200501031844.24801.david.golden@oceanfree.net>

On Monday 03 January 2005 15:26, Brian Mastenbrook wrote:

> Now, there is a FFI binding to Freetype in the Experimental section,
> but it's for CMUCL only and I have no idea how to use it. IWBNI this
> worked on both SBCL and CMUCL, and maybe even used UFFI. 

Indeed. Hey,  another thing that would be a distinctly nontrivial amount 
of work  would be FFI and McCLIM  backend for Cairo. :-) 
http://cairographics.org/


From amoroso at mclink.it  Mon Jan  3 19:17:28 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 03 Jan 2005 20:17:28 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
In-Reply-To: <E255B576-5DAF-11D9-815F-000A95717856@constantly.at> (Rudi
	Schlatte's message of "Mon, 3 Jan 2005 18:49:58 +0100")
References: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
	<16857.30521.442390.868730@serveur5.labri.fr>
	<878y7aphi7.fsf@plato.moon.paoloamoroso.it>
	<16857.32103.861449.518018@serveur5.labri.fr>
	<874qhypg69.fsf@plato.moon.paoloamoroso.it>
	<E255B576-5DAF-11D9-815F-000A95717856@constantly.at>
Message-ID: <878y7al3uf.fsf@plato.moon.paoloamoroso.it>

Rudi Schlatte <rudi at constantly.at> writes:

> The INSTALL.lisp file has this magic incantation in its #+cmu section
> that seems to take care of the problem:
>
> (setf mp::*idle-process* mp::*initial-process*)

This has apparently not effect: CPU usage is still above 95% with
McCLIM.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From rudi at constantly.at  Mon Jan  3 17:49:58 2005
From: rudi at constantly.at (Rudi Schlatte)
Date: Mon, 3 Jan 2005 18:49:58 +0100
Subject: [mcclim-devel] CPU usage > 95% when running McCLIM apps
In-Reply-To: <874qhypg69.fsf@plato.moon.paoloamoroso.it>
References: <871xd2riiu.fsf@plato.moon.paoloamoroso.it>
	<16857.30521.442390.868730@serveur5.labri.fr>
	<878y7aphi7.fsf@plato.moon.paoloamoroso.it>
	<16857.32103.861449.518018@serveur5.labri.fr>
	<874qhypg69.fsf@plato.moon.paoloamoroso.it>
Message-ID: <E255B576-5DAF-11D9-815F-000A95717856@constantly.at>


On 3. J?n 2005, at 18:37, Paolo Amoroso wrote:

> Robert Strandh <strandh at labri.fr> writes:
>
>> I fully agree with you.  I kept forgetting to do that so I had
>> processes taking up 100% CPU on some of our servers.  I therefore
>> switched to SBCL that does not have this problem.
>
> I don't mind SBCL.  But, at least for delivery, I prefer CMUCL to
> extract every bit of additional performance.  In the case of a
> graphical system like McCLIM, this does help.
>

The INSTALL.lisp file has this magic incantation in its #+cmu section 
that seems to take care of the problem:

(setf mp::*idle-process* mp::*initial-process*)

IIRC I got this from eclipse-the-window-manager, or perhaps from 
cl-http.  Perhaps someone with more cmu-fu than me could comment if 
this has any side-effects?

Rudi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050103/cc000edc/attachment.sig>

From timmy at cc.gatech.edu  Mon Jan  3 22:23:58 2005
From: timmy at cc.gatech.edu (Timmy Douglas)
Date: Mon, 03 Jan 2005 17:23:58 -0500
Subject: [mcclim-devel] running clim apps over ssh -X fails
Message-ID: <87is6e9mo1.fsf@mail.gatech.edu>


the following fixes it:

16:01 < dan_b> I would hazard that if you replace the call to
xlib:open-display 
               with xlib:oipen-default-display (and no arguments) it'd
               probably 
               work fine
16:01 < timmyd> and the other error message is echod to the terminal
16:01 < dan_b> but open-default-display is not part of standard CLX
16:02 < dan_b> (that's in the initialize-clx method in
Backends/CLX/port.lisp, 
               around line 236 in my copy)



(defmethod initialize-clx ((port clx-port))
  (let ((options (cdr (port-server-path port))))
    (setf (clx-port-display port)
      (xlib:open-default-display))
    (progn
      (setf (xlib:display-error-handler (clx-port-display port))
        #'clx-error-handler)



From matley at muppetslab.org  Wed Jan  5 01:58:58 2005
From: matley at muppetslab.org (Matley)
Date: Wed, 5 Jan 2005 02:58:58 +0100 (CET)
Subject: [mcclim-devel] problem with Goatee
Message-ID: <33619.82.52.104.246.1104890338.squirrel@mail.ghislieri.it>

I am using mcclim (from cvs) and i am playing with goatee and his test
(goatee-test.lisp)

If i change the :initial-contents to a string with a newline inside, like
(format nil "The fox jumped ~% over the goatee") i get corrupted output
([] characters). Bigger the string i put in it, more corrupted i get the
output.

I tried to debug it, without success because i didnt understand all the
protocol (buffer, dblhead, etc.) inside it.

So my questions are:

Is it a bug or is there another mechanism to insert more line?

Is goatee the standard text editing tool (usable as an enhanced gadget)?




From amoroso at mclink.it  Wed Jan  5 08:55:49 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Wed, 05 Jan 2005 09:55:49 +0100
Subject: [mcclim-devel] Spam at McCLIM CLiki
Message-ID: <87brc445m2.fsf@plato.moon.paoloamoroso.it>

The first spammed page at McCLIM CLiki:

  http://mcclim.cliki.net/Recent%20Changes

shows that spammers have found also the site.  An uphill battle
starts...


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From rpgoldman at real-time.com  Thu Jan  6 16:26:27 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 6 Jan 2005 10:26:27 -0600
Subject: [mcclim-devel] question about display functions and control apps
In-Reply-To: <31ffd3c40412281319699e1744@mail.gmail.com>
References: <16849.50000.441579.260315@gargle.gargle.HOWL>
	<31ffd3c40412281319699e1744@mail.gmail.com>
Message-ID: <16861.26291.680262.914663@gargle.gargle.HOWL>


I'm afraid I'm restarting an old discussion, but I've had it on the
backburner, and now that I'm moving forward, I'm not quite sure how to
finish out the solution.

>>>>> "AH" == Andy Hefner <ahefner at gmail.com> writes:

    AH> What I might do is run a separate thread from the GUI that monitors
    AH> external conditions. It can close over your frame event queue, and
    AH> communicate changes to the GUI via events as necessary. Just define
    AH> your own event subclasses and write handle-event methods for them,
    AH> which will run in the GUI thread and can perform the necessary
    AH> updates. McCLIM itself already works in this fashion on threaded
    AH> platforms, events are collected from CLX in a background thread which
    AH> queues them up for the applications to handle.

I think this is the right solution for control applications.  One has
a second thread, which gets status updates and latches them into
slots in the application frame, and then we queue up an event.  Here
are a couple of follow-ons, though:

1.  Do I just make an event that will translate into setting
    frame-needs-redisplay?

2.  How do I ensure that the slots that I'm latching into are stable
    over the redisplay?  I imagine I make a clim-sys:lock object to
    make the update process and the redisplay process mutually
    exclusive, but can anyone give me a little guidance about what to
    protect in the CLIM code?

    I have been thinking that I should make a method for
    redisplay-frame-pane for my application that will hold the lock
    and (call-next-method).  Is this the right level of granularity?

Thanks!
Robert


From pw at snoopy.mv.com  Thu Jan  6 19:04:36 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Thu, 6 Jan 2005 14:04:36 -0500
Subject: [mcclim-devel] question about display functions and control apps
References: <16849.50000.441579.260315@gargle.gargle.HOWL><31ffd3c40412281319699e1744@mail.gmail.com>
	<16861.26291.680262.914663@gargle.gargle.HOWL>
Message-ID: <000501c4f422$90f07680$0201a8c0@moby>



| I'm afraid I'm restarting an old discussion, but I've had it on the
| backburner, and now that I'm moving forward, I'm not quite sure how to
| finish out the solution.
|
| >>>>> "AH" == Andy Hefner <ahefner at gmail.com> writes:
|
|     AH> What I might do is run a separate thread from the GUI that
monitors
|     AH> external conditions. It can close over your frame event queue, and
|     AH> communicate changes to the GUI via events as necessary. Just
define
|     AH> your own event subclasses and write handle-event methods for them,
|     AH> which will run in the GUI thread and can perform the necessary
|     AH> updates. McCLIM itself already works in this fashion on threaded
|     AH> platforms, events are collected from CLX in a background thread
which
|     AH> queues them up for the applications to handle.
|
| I think this is the right solution for control applications.  One has
| a second thread, which gets status updates and latches them into
| slots in the application frame, and then we queue up an event.  Here
| are a couple of follow-ons, though:
|
| 1.  Do I just make an event that will translate into setting
|     frame-needs-redisplay?
|

I tried this approach in Lispworks CLIM and it seems to work pretty well.

Paul

~~~~~~~~~~~~~~~~~~~~~~~~~~
(in-package :clim-user)

(defclass thing ()
  ((x :initarg :x)
   (y :initarg :y))
  (:default-initargs :x (random 100) :y (random 100)))

(define-application-frame a-test ()
  ((things :initform nil))
  (:pointer-documentation nil)
  (:menu-bar nil)
  (:panes
   (p1 :application
       :width 300 :height 200
       :end-of-line-action :allow
       :display-function 'p1df
       :incremental-redisplay t
       :display-time t
       ))
  (:layouts
   (default p1)))

(defun p1df (frame pane)
  (with-output-recording-options (pane :record t)
    (with-slots (things) frame
      (dolist (thing things)
        (with-slots (x y) thing
          (updating-output (pane :unique-id thing
                                 :cache-value (list x y)
                                 :cache-test #'equal)
            (draw-rectangle* pane x y (+ x 10) (+ y 10) :ink +blue+)))))))

(defvar *frame* nil)

(defun doit ()
  ;; display A-TEST application
  (setq *frame* (make-application-frame 'a-test))
  (run-frame-top-level *frame*))

(defclass my-event (device-event)
  ;; T-L-S seems to expect only device-event
  ;; Can't make application-pane see any yet
  ((pane :initarg :pane)))

(defmethod handle-event (client (event my-event))
  (with-application-frame (frame)
    (with-slots (pane) event
      (redisplay-frame-pane frame pane))))

(defun stuffit (frame)
  ;; do something to "update the database"
  (let ((tls (frame-top-level-sheet frame))
        (pane (frame-standard-output frame)))
    (with-slots (things) frame
      (with-output-recording-options (pane :record t)
        (push (make-instance 'thing) things))
      (setf (pane-needs-redisplay pane) t))
    (queue-event
     tls
     (make-instance 'my-event :sheet tls :pane pane :modifier-state 0))))




From pw at snoopy.mv.com  Fri Jan  7 20:50:00 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Fri, 7 Jan 2005 15:50:00 -0500
Subject: [mcclim-devel] question about display functions and control apps
References: <16849.50000.441579.260315@gargle.gargle.HOWL><31ffd3c40412281319699e1744@mail.gmail.com><16861.26291.680262.914663@gargle.gargle.HOWL>
	<000501c4f422$90f07680$0201a8c0@moby>
Message-ID: <000901c4f4fa$77595100$0201a8c0@moby>


| | 1.  Do I just make an event that will translate into setting
| |     frame-needs-redisplay?
| |
| 
| I tried this approach in Lispworks CLIM and it seems to work pretty well.

It is even easier than I thought. Here is a refinement of yesterdays code.

Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(in-package :clim-user)

(defclass thing ()
  ((x :initarg :x)
   (y :initarg :y))
  (:default-initargs :x (random 100) :y (random 100)))

(define-application-frame a-test ()
  ((things :initform nil))
  (:pointer-documentation nil)
  (:menu-bar nil)
  (:panes
   (p1 :application
       :width 300 :height 200
       :end-of-line-action :allow
       :display-function 'p1df
       :incremental-redisplay t))
  (:layouts
   (default p1)))

(defun p1df (frame pane)
  (with-output-recording-options (pane :record t)
    (with-slots (things) frame
      (dolist (thing things)
        (with-slots (x y) thing
          (updating-output (pane :unique-id thing
                                 :cache-value (list x y)
                                 :cache-test #'equal)
            (draw-rectangle* pane x y (+ x 10) (+ y 10) :ink +blue+)))))))

(defvar *frame* nil)

(defun doit ()
  ;; display A-TEST application
  (setq *frame* (make-application-frame 'a-test))
  (run-frame-top-level *frame*))

(defclass my-event (device-event)()
  (:default-initargs :modifier-state 0))

(defmethod handle-event (client (event my-event))
  (with-application-frame (frame)
    (redisplay-frame-pane frame client))))

(defun stuffit (frame)
  ;; do something to "update the database"
  (let ((tls (frame-top-level-sheet frame))
        (pane (frame-standard-output frame)))
    (with-slots (things) frame
      (push (make-instance 'thing) things))
    ;; Inform frame that something has changed
    (queue-event
     tls
     ;; :sheet causes event-handler client to be that
     (make-instance 'my-event :sheet pane))))




From moore at bricoworks.com  Fri Jan  7 21:42:15 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Fri, 7 Jan 2005 22:42:15 +0100
Subject: [mcclim-devel] question about display functions and control apps
In-Reply-To: <000901c4f4fa$77595100$0201a8c0@moby>
References: <16849.50000.441579.260315@gargle.gargle.HOWL><31ffd3c40412281319699e1744@mail.gmail.com><16861.26291.680262.914663@gargle.gargle.HOWL>
	<000501c4f422$90f07680$0201a8c0@moby>
	<000901c4f4fa$77595100$0201a8c0@moby>
Message-ID: <FF520DB6-60F4-11D9-9C83-000A959839F8@bricoworks.com>


On Jan 7, 2005, at 9:50 PM, Paul Werkowski wrote:

>
> | | 1.  Do I just make an event that will translate into setting
> | |     frame-needs-redisplay?
> | |
> |
> | I tried this approach in Lispworks CLIM and it seems to work pretty 
> well.
>
> It is even easier than I thought. Here is a refinement of yesterdays 
> code.
>
> Paul
Very interesting. Does this all "just work" in LispWorks CLIM? Do see 
any weird artifacts with presentation highlighting?

Tim

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (in-package :clim-user)
>
> (defclass thing ()
>   ((x :initarg :x)
>    (y :initarg :y))
>   (:default-initargs :x (random 100) :y (random 100)))
>
> (define-application-frame a-test ()
>   ((things :initform nil))
>   (:pointer-documentation nil)
>   (:menu-bar nil)
>   (:panes
>    (p1 :application
>        :width 300 :height 200
>        :end-of-line-action :allow
>        :display-function 'p1df
>        :incremental-redisplay t))
>   (:layouts
>    (default p1)))
>
> (defun p1df (frame pane)
>   (with-output-recording-options (pane :record t)
>     (with-slots (things) frame
>       (dolist (thing things)
>         (with-slots (x y) thing
>           (updating-output (pane :unique-id thing
>                                  :cache-value (list x y)
>                                  :cache-test #'equal)
>             (draw-rectangle* pane x y (+ x 10) (+ y 10) :ink 
> +blue+)))))))
>
> (defvar *frame* nil)
>
> (defun doit ()
>   ;; display A-TEST application
>   (setq *frame* (make-application-frame 'a-test))
>   (run-frame-top-level *frame*))
>
> (defclass my-event (device-event)()
>   (:default-initargs :modifier-state 0))
>
> (defmethod handle-event (client (event my-event))
>   (with-application-frame (frame)
>     (redisplay-frame-pane frame client))))
>
> (defun stuffit (frame)
>   ;; do something to "update the database"
>   (let ((tls (frame-top-level-sheet frame))
>         (pane (frame-standard-output frame)))
>     (with-slots (things) frame
>       (push (make-instance 'thing) things))
>     ;; Inform frame that something has changed
>     (queue-event
>      tls
>      ;; :sheet causes event-handler client to be that
>      (make-instance 'my-event :sheet pane))))
>
>
> _______________________________________________
> mcclim-devel mailing list
> mcclim-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel



From pw at snoopy.mv.com  Sat Jan  8 00:13:20 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Fri, 7 Jan 2005 19:13:20 -0500
Subject: [mcclim-devel] question about display functions and control apps
References: <16849.50000.441579.260315@gargle.gargle.HOWL><31ffd3c40412281319699e1744@mail.gmail.com><16861.26291.680262.914663@gargle.gargle.HOWL>
	<000501c4f422$90f07680$0201a8c0@moby>
	<000901c4f4fa$77595100$0201a8c0@moby>
	<FF520DB6-60F4-11D9-9C83-000A959839F8@bricoworks.com>
Message-ID: <000901c4f516$dcabf8c0$0201a8c0@moby>

| Very interesting. Does this all "just work" in LispWorks CLIM? Do see
| any weird artifacts with presentation highlighting?

It all seems to just work. I added some simple presentation stuff to the
code (see below)
and don't see anything unusual as yet. LWW CLIM's presentation highlighting
leaves
a bit to be desired as the outline seems to be off by 1 pixel (overwriting
object on
left and top) but that's normal.

I'm going to try this technique on some real code that currently does have
some
presentation abnormalities to see if this works better. I'll let you know
what happens.

Paul

~~~~~~~~~~~~~~~~~~~~~~~
(in-package :clim-user)

(defclass thing ()
  ((x :initarg :x)
   (y :initarg :y))
  (:default-initargs :x (random 100) :y (random 100)))

(define-application-frame a-test ()
  ((things :initform nil))
  (:pointer-documentation nil)
  (:menu-bar nil)
  (:panes
   (p1 :application
       :width 300 :height 200
       :end-of-line-action :allow
       :display-function 'p1df
       :incremental-redisplay t))
  (:layouts
   (default p1)))

(defun p1df (frame pane)
  (with-output-recording-options (pane :record t)
    (with-slots (things) frame
      (dolist (thing things)
        (with-slots (x y) thing
          (updating-output (pane :unique-id thing
                                 :cache-value (list x y)
                                 :cache-test #'equal)
            (with-output-as-presentation (pane thing 'thing)
              (draw-rectangle* pane x y (+ x 10) (+ y 10) :ink
+blue+))))))))

(defvar *frame* nil)

(defun doit ()
  ;; display A-TEST application
  (setq *frame* (make-application-frame 'a-test))
  (run-frame-top-level *frame*))

(defclass my-event (device-event)()
  (:default-initargs :modifier-state 0))

(defmethod handle-event (client (event my-event))
  (with-application-frame (frame)
    (redisplay-frame-pane frame client)))

(defun stuffit (frame)
  ;; do something to "update the database"
  (let ((tls (frame-top-level-sheet frame))
        (pane (frame-standard-output frame)))
    (with-slots (things) frame
      (push (make-instance 'thing) things))
    ;; Inform frame that something has changed
    (queue-event
     tls
     ;; :sheet causes event-handler client to be that
     (make-instance 'my-event :sheet pane))))


(define-presentation-type thing ())

(define-a-test-command (com-noop)((object 'thing))
  (print object *trace-output*)
  )

(define-presentation-to-command-translator x-noop
   (thing com-noop a-test)
   (object)
  (list object))





From amoroso at mclink.it  Sat Jan  8 13:19:23 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sat, 08 Jan 2005 14:19:23 +0100
Subject: [mcclim-devel] Running McCLIM and CL-SDL together: is it possible?
References: <87652e8xwf.fsf@plato.moon.paoloamoroso.it>
Message-ID: <87u0psqcro.fsf@plato.moon.paoloamoroso.it>

Paolo Amoroso <amoroso at mclink.it> writes:

> Is it possible to run a McCLIM and a CL-SDL (cl-sdl.sourceforge.net)
> application within the same Lisp image?
>
> When I try this with CMUCL, only the CL-SDL application runs and the
> McCLIM one--say, the CLIM Listener--is frozen, i.e. the window is not
> refreshed and does not process input events.  Things do not change if
> I start the CLIM Listener with :new-process t.

I have been suggested (thanks David!) that, given CMUCL's cooperative
multiprocessing model, the CL-SDL application thread and the Listener
thread may not be yielding regularly.  So, in the file
examples/2d-test.lisp of the CL-SDL distribution, I tried adding a
call to MP:PROCESS-YIELD as the last expression in the LAMBDA of
MAKE-UPDATE-FN.

This way both the CL-SDL demo and the Listener can run at the same
time.  CPU usage is over 99% even with just the demo, but OpenGL
applications are quite demanding.

Cool.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From ajuckel at gmail.com  Sat Jan 15 06:35:19 2005
From: ajuckel at gmail.com (Anthony Juckel)
Date: Sat, 15 Jan 2005 00:35:19 -0600
Subject: [mcclim-devel] Presentation types, accept and the like
Message-ID: <a45b92ac0501142235252667fb@mail.gmail.com>

This message doesn't pertain to the internal development of McCLIM,
but is rather a general CLIM question.  The only CLIM mailing list
that I've found seems to have next to no traffic on it, so this seemed
the best place to send my questions.  Perhaps it would be prudent (if
messages like this become a hassle) to create a mcclim-user mailing
list on common-lisp.net?

What is the proper way to go about defining presentation types with
their associated methods, especially accept?  For some background, I'm
working on an application for working with a set of objects that I've
defined.  In defining these objects, I've done some MOP-ery to allow
me to specify for a given slot on an object, which values are allowed:

(defclass my-class ()
  ((slot-a :allowed-values ("some" "allowed" "values")))
  (:metaclass restricted-slot-value-class))

I've also got the necessary machinery to easily get the allowable
values for a given slot of an object.  Now, I'd like to use this
machinery to ease the creation of dialogs pertaining to these objects.
 For example, if a user is needing to supply a value for slot-a, I'd
like to display a menu to the user containing the valid values.

The way that I've tried to accomplish this is that I've created a
presentation type for each slot in the object (I know there must be a
more general solution...).  Then I've defined an accept method for
these presentation types.  Now, in my accept method, I'm trying to use
menu-choose as follows:

(clim:define-presentation-method clim:accept ((type slot-a) stream
view &key &allow-other-keys)
  (declare (ignore view))
  (clim:menu-choose (allowed-values 'slot-a)))

I then create a dialog using accepting-values, which in turn calls
this accept method.  This isn't giving me the desired behavior though.
 When I click on the input field for slot-a, I do get the proper menu
displayed, but when I first choose an option, it doesn't appear to
have any effect, but does redisplay the menu again.  After choosing a
menu option a second time, the choice does indeed seem to stick.

 Am I just missing a step, or have I wondered down a wrong path
entirely?  Does anyone have any advice for how better to handle such a
situation?

Anthony W. Juckel


From pw at snoopy.mv.com  Sat Jan 15 14:00:06 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Sat, 15 Jan 2005 09:00:06 -0500
Subject: [mcclim-devel] cvs problem?
Message-ID: <000501c4fb0a$84dd5900$0201a8c0@moby>

Tried to do a cvs update, got

cvs server: cannot open directory /project/mcclim/cvsroot/mcclim/images: No
such file or directory
cvs server: skipping directory images

Paul




From moore at bricoworks.com  Sat Jan 15 14:39:35 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Sat, 15 Jan 2005 15:39:35 +0100
Subject: [mcclim-devel] Presentation types, accept and the like
In-Reply-To: <a45b92ac0501142235252667fb@mail.gmail.com>
References: <a45b92ac0501142235252667fb@mail.gmail.com>
Message-ID: <46BC66B3-6703-11D9-820C-000A959839F8@bricoworks.com>

On Jan 15, 2005, at 7:35 AM, Anthony Juckel wrote:

> This message doesn't pertain to the internal development of McCLIM,
> but is rather a general CLIM question.  The only CLIM mailing list
> that I've found seems to have next to no traffic on it, so this seemed
> the best place to send my questions.  Perhaps it would be prudent (if
> messages like this become a hassle) to create a mcclim-user mailing
> list on common-lisp.net?
If we get to that point, sure, though I don't think we're quite there 
yet :) For the moment these kinds of discussions tend to point out 
shortcomings in McCLIM and for that reason are valuable to have on the 
developer's list. Also, few of here are experienced users of the 
commercial CLIM implementation, so in a sense we're all finding the 
true way together.

> What is the proper way to go about defining presentation types with
> their associated methods, especially accept?  For some background, I'm
> working on an application for working with a set of objects that I've
> defined.  In defining these objects, I've done some MOP-ery to allow
> me to specify for a given slot on an object, which values are allowed:
>
> (defclass my-class ()
>   ((slot-a :allowed-values ("some" "allowed" "values")))
>   (:metaclass restricted-slot-value-class))
>
> I've also got the necessary machinery to easily get the allowable
> values for a given slot of an object.  Now, I'd like to use this
> machinery to ease the creation of dialogs pertaining to these objects.
>  For example, if a user is needing to supply a value for slot-a, I'd
> like to display a menu to the user containing the valid values.
>
> The way that I've tried to accomplish this is that I've created a
> presentation type for each slot in the object (I know there must be a
> more general solution...).  Then I've defined an accept method for
> these presentation types.  Now, in my accept method, I'm trying to use
> menu-choose as follows:
>
There are a couple of ways you can go here, depending on how much 
flexibility you need in accepting the values. CLIM has useful 
presentation types for accepting one of several values, MEMBER and 
COMPLETION. The accept method for COMPLETION doesn't directly present a 
menu; it's a text field in which one can use tab completion and get a 
menu by right clicking. I'll return to just using a menu in a second.

You can define presentation types that inherit from completion or 
directly use the COMPLETION type to accept values (either within 
ACCEPTING-VALUES) or elsewhere:

(setf (slot-value obj 'slot-a) (accept `(completion ,(allowed-values 
'slot-a)) stream))

This is nice because it can be abstracted in a function in the obvious 
way.

You could also define a presentation type that uses the slot name as an 
argument:

(define-presentation-type slot-val (slot-name) :inherit-from t)
(define-presentation-method accept (type slot-val) stream view &key)
   (accept `(completion ,(allowed-values ,slot-name)) stream view))

> (clim:define-presentation-method clim:accept ((type slot-a) stream
> view &key &allow-other-keys)
>   (declare (ignore view))
>   (clim:menu-choose (allowed-values 'slot-a)))
>
> I then create a dialog using accepting-values, which in turn calls
> this accept method.  This isn't giving me the desired behavior though.

I believe that's because the control flow within accepting-values is 
very strange. I'm a bit surprised that this works at all. Are you 
looking for a pop-up menu, or a list of choices embedded in the dialog? 
The right way to do this is probably with gadgets and gadget views. 
Gadget views are not implemented yet in McCLIM, but they are certainly 
on our list. In an ideal world the view in a dialog  for the completion 
type would present a pop-up menu.

If you do implement a custom accept method like this, you should 
probably define your own view and specialize this method on the view so 
that you can textually input values in other input contexts.

>  When I click on the input field for slot-a, I do get the proper menu
> displayed, but when I first choose an option, it doesn't appear to
> have any effect, but does redisplay the menu again.  After choosing a
> menu option a second time, the choice does indeed seem to stick.
>
What do you mean by "choose an option;" another option in the dialog 
box? It's possible that a recent update to the dialog code would fix 
your problem. Otherwise I'd need to see your code to figure out what's 
going on as I certainly haven't considered yet doing  things like 
calling menu-choose within accepting values.
>  Am I just missing a step, or have I wondered down a wrong path
> entirely?  Does anyone have any advice for how better to handle such a
> situation?
>
There are a lot of different paths :)

Tim



From ajuckel at gmail.com  Sat Jan 15 19:02:45 2005
From: ajuckel at gmail.com (Anthony Juckel)
Date: Sat, 15 Jan 2005 13:02:45 -0600
Subject: [mcclim-devel] Presentation types, accept and the like
In-Reply-To: <46BC66B3-6703-11D9-820C-000A959839F8@bricoworks.com>
References: <a45b92ac0501142235252667fb@mail.gmail.com>
	<46BC66B3-6703-11D9-820C-000A959839F8@bricoworks.com>
Message-ID: <a45b92ac05011511027ea49c87@mail.gmail.com>

On Sat, 15 Jan 2005 15:39:35 +0100, Timothy Moore <moore at bricoworks.com> wrote:
> On Jan 15, 2005, at 7:35 AM, Anthony Juckel wrote:
[...snip...]
> > The way that I've tried to accomplish this is that I've created a
> > presentation type for each slot in the object (I know there must be a
> > more general solution...).  Then I've defined an accept method for
> > these presentation types.  Now, in my accept method, I'm trying to use
> > menu-choose as follows:
> >
> There are a couple of ways you can go here, depending on how much
> flexibility you need in accepting the values. CLIM has useful
> presentation types for accepting one of several values, MEMBER and
> COMPLETION. The accept method for COMPLETION doesn't directly present a
> menu; it's a text field in which one can use tab completion and get a
> menu by right clicking. I'll return to just using a menu in a second.

This is actually the way that I started out (using MEMBER), so perhaps
I'll settle with that for now.  One thing about the usability though,
it would be nice if you could navigate the dialog completely without
using the mouse.  Currently, I have to (at least, I believe I have to)
click on the first field, then I can type in my value and hit enter to
move to the next, but I have to again use the mouse to click the exit
button.

> 
> You can define presentation types that inherit from completion or
> directly use the COMPLETION type to accept values (either within
> ACCEPTING-VALUES) or elsewhere:
> 
> (setf (slot-value obj 'slot-a) (accept `(completion ,(allowed-values
> 'slot-a)) stream))
> 
> This is nice because it can be abstracted in a function in the obvious
> way.
> 
> You could also define a presentation type that uses the slot name as an
> argument:
> 
> (define-presentation-type slot-val (slot-name) :inherit-from t)
> (define-presentation-method accept (type slot-val) stream view &key)
>    (accept `(completion ,(allowed-values ,slot-name)) stream view))
> 
> > (clim:define-presentation-method clim:accept ((type slot-a) stream
> > view &key &allow-other-keys)
> >   (declare (ignore view))
> >   (clim:menu-choose (allowed-values 'slot-a)))
> >
> > I then create a dialog using accepting-values, which in turn calls
> > this accept method.  This isn't giving me the desired behavior though.
> 
> I believe that's because the control flow within accepting-values is
> very strange. I'm a bit surprised that this works at all. Are you
> looking for a pop-up menu, or a list of choices embedded in the dialog?
> The right way to do this is probably with gadgets and gadget views.
> Gadget views are not implemented yet in McCLIM, but they are certainly
> on our list. In an ideal world the view in a dialog  for the completion
> type would present a pop-up menu.

I was looking for a pop-up menu, which is what I get with the above. 
When I click on the field to edit, a popup menu is drawn with the
allowed values for that field.

> 
> If you do implement a custom accept method like this, you should
> probably define your own view and specialize this method on the view so
> that you can textually input values in other input contexts.
> 
> >  When I click on the input field for slot-a, I do get the proper menu
> > displayed, but when I first choose an option, it doesn't appear to
> > have any effect, but does redisplay the menu again.  After choosing a
> > menu option a second time, the choice does indeed seem to stick.
> >
> What do you mean by "choose an option;" another option in the dialog
> box? It's possible that a recent update to the dialog code would fix
> your problem. Otherwise I'd need to see your code to figure out what's
> going on as I certainly haven't considered yet doing  things like
> calling menu-choose within accepting values.

By "choose an option" I was referring to clicking on a particular menu
item in the popup menu.  I use the term field to refer to the
different elements that I'm editing within accepting-values.  So I
would click on a field, select an item from the menu, select an item
from the new menu to get the value to stick.

Thank you for your ideas.

Anthony W. Juckel


From strandh at labri.fr  Sun Jan 16 06:17:53 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sun, 16 Jan 2005 07:17:53 +0100
Subject: [mcclim-devel] cvs problem?
In-Reply-To: <000501c4fb0a$84dd5900$0201a8c0@moby>
References: <000501c4fb0a$84dd5900$0201a8c0@moby>
Message-ID: <16874.1809.599012.603295@serveur5.labri.fr>

Hello, 

Paul Werkowski writes:
 > Tried to do a cvs update, got
 > 
 > cvs server: cannot open directory /project/mcclim/cvsroot/mcclim/images: No
 > such file or directory
 > cvs server: skipping directory images

That directory was explicitly removed from the CVS tree, because it
was empty and created name conflics with the one called Images on
non-case-senstivie platforms.

I guess you would have to remove your local directory images, perhaps
physically from the CVS/* files as well.


-- 
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 jk at xylema.org  Sun Jan 16 09:43:23 2005
From: jk at xylema.org (John Kozak)
Date: Sun, 16 Jan 2005 09:43:23 +0000
Subject: [mcclim-devel] cvs problem?
In-Reply-To: <16874.1809.599012.603295@serveur5.labri.fr>
References: <000501c4fb0a$84dd5900$0201a8c0@moby>
	<16874.1809.599012.603295@serveur5.labri.fr>
Message-ID: <16874.14139.699983.171559@thameslighter.net>

Robert Strandh writes:
 > Hello, 
 > 
 > Paul Werkowski writes:
 >  > Tried to do a cvs update, got
 >  > 
 >  > cvs server: cannot open directory /project/mcclim/cvsroot/mcclim/images: No
 >  > such file or directory
 >  > cvs server: skipping directory images
 > 
 > That directory was explicitly removed from the CVS tree, because it
 > was empty and created name conflics with the one called Images on
 > non-case-senstivie platforms.
 > 
 > I guess you would have to remove your local directory images, perhaps
 > physically from the CVS/* files as well.

CVS update doesn't create or delete directories by default; you need
to specify some options:

  cvs up -dP

will delete local copies of any deleted directories at the repository
(-P) and create any directories newly created at the repository (-d).  
You can make this default behaviour by adding this line to ~/.cvsrc:

   update -dP

(trim leading whitespace).

John





From pw at snoopy.mv.com  Sun Jan 16 13:28:07 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Sun, 16 Jan 2005 08:28:07 -0500
Subject: [mcclim-devel] cvs problem?
References: <000501c4fb0a$84dd5900$0201a8c0@moby><16874.1809.599012.603295@serveur5.labri.fr>
	<16874.14139.699983.171559@thameslighter.net>
Message-ID: <001a01c4fbcf$3712fd90$0201a8c0@moby>

  > 
|  > That directory was explicitly removed from the CVS tree, because it
|  > was empty and created name conflics with the one called Images on
|  > non-case-senstivie platforms.
|  > 
|  > I guess you would have to remove your local directory images, perhaps
|  > physically from the CVS/* files as well.
| 
| CVS update doesn't create or delete directories by default; you need
| to specify some options:
| 
|   cvs up -dP
| 
| will delete local copies of any deleted directories at the repository
| (-P) and create any directories newly created at the repository (-d).  
| You can make this default behaviour by adding this line to ~/.cvsrc:
| 
|    update -dP


Yeah, I know. I did that several times before posting the message. Later
in the day the same command worked fine and I assumed someone did
something to fix it. Or maybe my box was afflicted by some random cosmic
ray. All is OK now.

Thanks,
Paul




From pdm at zamazal.org  Sun Jan 16 20:55:52 2005
From: pdm at zamazal.org (Milan Zamazal)
Date: Sun, 16 Jan 2005 21:55:52 +0100
Subject: [mcclim-devel] Re: cvs problem?
References: <000501c4fb0a$84dd5900$0201a8c0@moby>
	<16874.1809.599012.603295@serveur5.labri.fr>
	<16874.14139.699983.171559@thameslighter.net>
	<001a01c4fbcf$3712fd90$0201a8c0@moby>
Message-ID: <87d5w5um93.fsf@blackbird.zamazal.org>

>>>>> "PW" == Paul Werkowski <pw at snoopy.mv.com> writes:

    PW> Later in the day the same command worked fine and I assumed
    PW> someone did something to fix it. Or maybe my box was afflicted
    PW> by some random cosmic ray. 

No, I had the same problem and it didn't disappear.  I had to remove the
subdirectory by hand.

Regards,

Milan Zamazal

-- 
http://www.zamazal.org



From amoroso at mclink.it  Mon Jan 17 12:19:42 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 17 Jan 2005 13:19:42 +0100
Subject: [mcclim-devel] <integer> is not of type XLIB:GCONTEXT error when
 using pixmaps in Listener
Message-ID: <871xck5jtt.fsf@plato.moon.paoloamoroso.it>

I have updated my McCLIM CVS working copy with the latest commits
since last January 11.  In the CLIM Listener, when I left-click the
current directory presentation in the wholine pane, I get this error:

Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
   39 is not of type XLIB:GCONTEXT
   [Condition of type TYPE-ERROR]

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

Debug  (type H for help)

(XLIB:DRAW-RECTANGLE 7 #<XLIB:WINDOW :0 44040284> 39 0 ...)[:EXTERNAL]
0] backtrace

0: (XLIB:DRAW-RECTANGLE 7 #<XLIB:WINDOW :0 44040284> 39 0 ...)[:EXTERNAL]
1: ((METHOD CLIM-CLX::MEDIUM-DRAW-RECTANGLE-USING-INK* NIL
     (CLIM-CLX::CLX-MEDIUM T T T T ...))
    (#(2 5 8 NIL) . #()) #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {588E952D}>
    #<unused-arg> ...)
2: ((METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL NIL
     (CLIM:MEDIUM T T))
    (#(2 5 6 3 2 ...) . #(# #)) #<unused-arg>
    #<CLIM-CLX::CLX-MEDIUM {588E952D}> #<CLIM-CLX::CLX-MEDIUM {588E952D}> ...)
3: (CLIM-LISTENER::DRAW-ICON T
                             #<CLIM-INTERNALS::INDEXED-PATTERN {5843D4C5}>
                             :EXTRA-SPACING 3)
4: ((FLET #:CONTINUATION22
      (FLET #:CONT20
        #)))
5: ((FLET #:CONTINUATION24
      (FLET #:CONT20
        #))
    #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}> #<unused-arg>)
6: ((FLET #:CONTINUATION24
      (FLET #:CONT20
        #))
    2 #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}>
    #<unused-arg>)[:EXTERNAL]
7: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL
     (CLIM:OUTPUT-RECORDING-STREAM T T T))
    (#() . #(#)) #<unused-arg>
    #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}>
    #<Function (FLET #:CONTINUATION24
                 #)
      {580CA3A1}>
    ...)
8: ((FLET #:CONT20
      (FLET #:DESTINATION-CONTINUATION0
        CLIM-LISTENER::COM-SHOW-DIRECTORY))
    #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}>)
9: ((METHOD CLIM:INVOKE-WITH-TEXT-STYLE NIL (CLIM:MEDIUM T T)) #<unused-arg>
    #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {588E952D}>
    #<Closure Over Function (FLET #:CONT19
                              )
      {58CB7AA9}>
    ...)
10: ("LAMBDA (G8058 G8059 G8060)" #<unused-arg> #<unused-arg>
     #<CLIM-LISTENER::LISTENER {588E559D}>
     (CLIM-LISTENER::COM-SHOW-DIRECTORY #P"/home/paolo/"))
11: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#() . #(# # # # # ...)) #<unused-arg>
     #<CLIM-LISTENER::LISTENER {588E559D}>
     (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT))
12: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4608)" #<unused-arg> #<unused-arg>
     #<CLIM-LISTENER::LISTENER {588E559D}>
     (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT))
13: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#(22) . #()) #<unused-arg> #<CLIM-LISTENER::LISTENER {588E559D}>
     #<unused-arg>)
14: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM-LISTENER::LISTENER))
     #<unused-arg>
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {1167A9D1}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL NIL
          :ARG-INFO (1 . T))
     #<CLIM-LISTENER::LISTENER {588E559D}> (:LISTENER-FUNCALL NIL))
15: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME))
     (#(18 17) . #(#))
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {590472D9}>
          :PV-CELL NIL
          :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL
                                 :FUNCTION #
                                 :PV-CELL #
                                 :NEXT-METHOD-CALL NIL
                                 :ARG-INFO #)
          :ARG-INFO (1 . T))
     #<CLIM-LISTENER::LISTENER {588E559D}> (:LISTENER-FUNCALL NIL))
16: (INTERACTIVE-EVAL (CLIM-LISTENER:RUN-LISTENER))
17: (LISP::%TOP-LEVEL)
18: ((LABELS LISP::RESTART-LISP
       SAVE-LISP))

0]

If I load Experimental/pointer-doc-hack.lisp in the Listener and move
the mouse pointer toward the current directory presentation, I get
this similar, possibly related error:

Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
   0 is not of type XLIB:GCONTEXT
   [Condition of type TYPE-ERROR]

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

Debug  (type H for help)

(XLIB:DRAW-RECTANGLE 7 #<XLIB:WINDOW :0 44040277> 0 0 ...)[:EXTERNAL]
0]

I use CMUCL Snapshot 2004-12 with the latest McCLIM CVS sources under
Slackware Linux 10.0.


Paolo
-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film


From moore at bricoworks.com  Tue Jan 18 11:11:52 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Tue, 18 Jan 2005 12:11:52 +0100
Subject: [mcclim-devel] Presentation types, accept and the like
In-Reply-To: <a45b92ac05011511027ea49c87@mail.gmail.com>
References: <a45b92ac0501142235252667fb@mail.gmail.com>
	<46BC66B3-6703-11D9-820C-000A959839F8@bricoworks.com>
	<a45b92ac05011511027ea49c87@mail.gmail.com>
Message-ID: <C17B4EE4-6941-11D9-ACEB-000A959839F8@bricoworks.com>


On Jan 15, 2005, at 8:02 PM, Anthony Juckel wrote:

> On Sat, 15 Jan 2005 15:39:35 +0100, Timothy Moore 
> <moore at bricoworks.com> wrote:
>
...
> This is actually the way that I started out (using MEMBER), so perhaps
> I'll settle with that for now.  One thing about the usability though,
> it would be nice if you could navigate the dialog completely without
> using the mouse.  Currently, I have to (at least, I believe I have to)
> click on the first field, then I can type in my value and hit enter to
> move to the next, but I have to again use the mouse to click the exit
> button.
>
You can specify :initially-select-query-identifier to accepting-values. 
Perhaps a sensible default would be the first query. I agree that it 
would be nice if leaving  the last query field would exit 
accepting-values and will look at implementing that behavior.

> I was looking for a pop-up menu, which is what I get with the above.
> When I click on the field to edit, a popup menu is drawn with the
> allowed values for that field.
>
A pop-up menu is nice. However, special effects like this should be 
done with accept-present-default. There's no documentation on what 
accept-present-default should do either in the CLIM spec or the Franz 
user guide. I just checked in an implementation of a pop-up menu which 
you can use via the climi::+pop-up-menu-view+ parameter. I also added 
some documentation to dialog.lisp about the internals of 
accepting-values. This should get people started on writing better 
input gadgets for accepting-values. Note that this uses internals of 
McCLIM and is subject to change, especially when we get around to 
implementing accepting-values panes. Also, the climi internal symbols 
will probably be exported from clim-extensions.

Tim



From ahefner at gmail.com  Thu Jan 20 00:07:06 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 19 Jan 2005 19:07:06 -0500
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update:
	mcclim/presentation-defs.lisp
In-Reply-To: <31ffd3c4050119160541fbbc44@mail.gmail.com>
References: <20050119224446.F422788027@common-lisp.net>
	<31ffd3c4050119160541fbbc44@mail.gmail.com>
Message-ID: <31ffd3c405011916076d45a96c@mail.gmail.com>

I think this is wrong. McCLIM now returns the class name of the object
even when no corresponding presentation type has been defined. On Jan
2nd I commited a change to stop this from happening (I think it was
causing problems with the listener), which this seems to undo.

Thoughts?


On Wed, 19 Jan 2005 14:44:46 -0800 (PST), Timothy Moore
<tmoore at common-lisp.net> wrote:
> Update of /project/mcclim/cvsroot/mcclim
> In directory common-lisp.net:/tmp/cvs-serv20050
>
> Modified Files:
>         presentation-defs.lisp
> Log Message:
> For CLOS objects, make presentation-type-of return the name of the class if possible
> Date: Wed Jan 19 14:44:46 2005
> Author: tmoore
>
> Index: mcclim/presentation-defs.lisp
> diff -u mcclim/presentation-defs.lisp:1.39 mcclim/presentation-defs.lisp:1.40
> --- mcclim/presentation-defs.lisp:1.39  Tue Jan 11 05:02:19 2005
> +++ mcclim/presentation-defs.lisp       Wed Jan 19 14:44:46 2005
> @@ -87,11 +87,15 @@
>  (defmethod presentation-type-of ((object standard-object))
>    (multiple-value-bind (name lambda-list)
>        (get-ptype-from-class-of object)
> -    (if (and name
> -             (or (null lambda-list)
> -                 (member (first lambda-list) lambda-list-keywords)))
> -        name
> -        (call-next-method))))
> +    (cond ((and name
> +               (or (null lambda-list)
> +                   (member (first lambda-list) lambda-list-keywords)))
> +          name)
> +         (name
> +          'standard-object)
> +         (t (let* ((class (class-of object))
> +                   (class-name (class-name class)))
> +              (or class-name class))))))
>
>  (defmethod presentation-type-of ((object structure-object))
>    (multiple-value-bind (name lambda-list)
> @@ -100,7 +104,6 @@
>              (member lambda-list lambda-list-keywords))
>          name
>          (call-next-method))))
> -
>
>  (define-presentation-generic-function
>      %map-over-presentation-type-supertypes
>
> _______________________________________________
> mcclim-cvs mailing list
> mcclim-cvs at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-cvs
>


From ahefner at gmail.com  Thu Jan 20 01:49:21 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Wed, 19 Jan 2005 20:49:21 -0500
Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update:
	mcclim/presentation-defs.lisp
In-Reply-To: <31ffd3c4050119160541fbbc44@mail.gmail.com>
References: <20050119224446.F422788027@common-lisp.net>
	<31ffd3c4050119160541fbbc44@mail.gmail.com>
Message-ID: <31ffd3c40501191749192a87d0@mail.gmail.com>

Having read the spec, I see I'm wrong about this. Sorry about that.


On Wed, 19 Jan 2005 19:05:51 -0500, Andy Hefner <ahefner at gmail.com> wrote:
> I think this is wrong. McCLIM now returns the class name of the object
> even when no corresponding presentation type has been defined. On Jan
> 2nd I commited a change to stop this from happening (I think it was
> causing problems with the listener), which this seems to undo.
> 
> Thoughts?
> 
> 
> On Wed, 19 Jan 2005 14:44:46 -0800 (PST), Timothy Moore
> <tmoore at common-lisp.net> wrote:
> > Update of /project/mcclim/cvsroot/mcclim
> > In directory common-lisp.net:/tmp/cvs-serv20050
> >
> > Modified Files:
> >         presentation-defs.lisp
> > Log Message:
> > For CLOS objects, make presentation-type-of return the name of the class if possible
> > Date: Wed Jan 19 14:44:46 2005
> > Author: tmoore
> >
> > Index: mcclim/presentation-defs.lisp
> > diff -u mcclim/presentation-defs.lisp:1.39 mcclim/presentation-defs.lisp:1.40
> > --- mcclim/presentation-defs.lisp:1.39  Tue Jan 11 05:02:19 2005
> > +++ mcclim/presentation-defs.lisp       Wed Jan 19 14:44:46 2005
> > @@ -87,11 +87,15 @@
> >  (defmethod presentation-type-of ((object standard-object))
> >    (multiple-value-bind (name lambda-list)
> >        (get-ptype-from-class-of object)
> > -    (if (and name
> > -             (or (null lambda-list)
> > -                 (member (first lambda-list) lambda-list-keywords)))
> > -        name
> > -        (call-next-method))))
> > +    (cond ((and name
> > +               (or (null lambda-list)
> > +                   (member (first lambda-list) lambda-list-keywords)))
> > +          name)
> > +         (name
> > +          'standard-object)
> > +         (t (let* ((class (class-of object))
> > +                   (class-name (class-name class)))
> > +              (or class-name class))))))
> >
> >  (defmethod presentation-type-of ((object structure-object))
> >    (multiple-value-bind (name lambda-list)
> > @@ -100,7 +104,6 @@
> >              (member lambda-list lambda-list-keywords))
> >          name
> >          (call-next-method))))
> > -
> >
> >  (define-presentation-generic-function
> >      %map-over-presentation-type-supertypes
> >
> > _______________________________________________
> > mcclim-cvs mailing list
> > mcclim-cvs at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-cvs
> >
>


From amoroso at mclink.it  Fri Jan 21 19:23:08 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Fri, 21 Jan 2005 20:23:08 +0100
Subject: [mcclim-devel] Show Command Table Listener command: error
 left-clicking field in ACCEPTING-VALUES dialog
Message-ID: <87ekgea8o3.fsf@plato.moon.paoloamoroso.it>

I have found a bug that can be reproduced this way.  Run the CLIM
Listener, enter the command "Show Command Table" and hit ENTER without
providing an argument.  An ACCEPTING-VALUES dialog prompting for the
missing argument appears.  Left-clicking the input field generates
this error:

No matching method for the generic function
#<STANDARD-GENERIC-FUNCTION CLIM:COMMAND-TABLE-NAME (1) {284FF439}>, when
called with arguments (NIL).
   [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]

Restarts:
  0: [CONTINUE          ] Retry call to :FUNCTION.
  1: [ABORT             ] Return to application command loop
  2: [RETURN-TO-LISTENER] Return to listener.
  3: [DESTROY           ] Destroy the process

Debug  (type H for help)

("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg>
 #<STANDARD-GENERIC-FUNCTION CLIM:COMMAND-TABLE-NAME (1) {284FF439}> (NIL))
Source: Error finding source:
Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM:  Source file no longer exists:
  target:pcl/braid.lisp.
0]

I use the latest McCLIM CVS sources with CMUCL Snapshot 2005-01 under
Slackware Linux 10.0.


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


From boris at math.ubc.ca  Sun Jan 23 09:49:55 2005
From: boris at math.ubc.ca (Boris Tschirschwitz)
Date: Sun, 23 Jan 2005 01:49:55 -0800 (PST)
Subject: [mcclim-devel] Re: beagle
In-Reply-To: <Pine.GSO.4.61.0501221949460.18345@pascal.math.ubc.ca>
References: <Pine.GSO.4.61.0501221949460.18345@pascal.math.ubc.ca>
Message-ID: <Pine.GSO.4.61.0501230149030.19892@pascal.math.ubc.ca>

Hey.

Trying to compile the beagle backend to test climacs, I noticed that the load 
paths are hardwired to 'Users/duncan/...'.

Is there any reason for keeping this.
If not, is there already a patch somewhere, or would one be welcome?

Boris.



From ch-mcclim at bobobeach.com  Thu Jan 27 00:34:33 2005
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Wed, 26 Jan 2005 16:34:33 -0800
Subject: [mcclim-devel] find-keystroke-item slowness
In-Reply-To: <mailman.0.1106773669.17551.mcclim-devel@common-lisp.net>
References: <mailman.0.1106773669.17551.mcclim-devel@common-lisp.net>
Message-ID: <3717BA2A-6FFB-11D9-9E87-000D93AD286C@bobobeach.com>


Dear mcclim-devel,

It looks like find-keystroke-item is doing a lot of work (linear search 
through the keystrokes) every time there's a key event. I know this is 
the lispy way to do things, and clim wants to be flexible enough to 
provide other tests besides event-matches-gesture-name-p, but this 
seems like an awful lot of work for every key stroke. Am I missing 
something here?

BTW, I bring this up to try to address the generally poor response I 
get typing in climacs with the beagle back end.

Thanks,

Cyrus



From strandh at labri.fr  Thu Jan 27 04:52:18 2005
From: strandh at labri.fr (Robert Strandh)
Date: Thu, 27 Jan 2005 05:52:18 +0100
Subject: [mcclim-devel] find-keystroke-item slowness
In-Reply-To: <3717BA2A-6FFB-11D9-9E87-000D93AD286C@bobobeach.com>
References: <mailman.0.1106773669.17551.mcclim-devel@common-lisp.net>
	<3717BA2A-6FFB-11D9-9E87-000D93AD286C@bobobeach.com>
Message-ID: <16888.29570.805706.757534@serveur5.labri.fr>

Cyrus Harmon writes:
 > 
 > Dear mcclim-devel,
 > 
 > It looks like find-keystroke-item is doing a lot of work (linear search 
 > through the keystrokes) every time there's a key event. I know this is 
 > the lispy way to do things, and clim wants to be flexible enough to 
 > provide other tests besides event-matches-gesture-name-p, but this 
 > seems like an awful lot of work for every key stroke. Am I missing 
 > something here?
 > 
 > BTW, I bring this up to try to address the generally poor response I 
 > get typing in climacs with the beagle back end.

I seriously doubt that find-keystroke-item is the source of your
problem.  While you are right, that it is doing a sequential search,
it does so at interaction speed which is thousands of times slower.

Have you profiled it to be sure that this is really the source of the
poor response? 

-- 
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 ch-mcclim at bobobeach.com  Thu Jan 27 08:29:46 2005
From: ch-mcclim at bobobeach.com (Cyrus Harmon)
Date: Thu, 27 Jan 2005 00:29:46 -0800
Subject: [mcclim-devel] find-keystroke-item slowness
In-Reply-To: <16888.29570.805706.757534@serveur5.labri.fr>
References: <mailman.0.1106773669.17551.mcclim-devel@common-lisp.net>
	<3717BA2A-6FFB-11D9-9E87-000D93AD286C@bobobeach.com>
	<16888.29570.805706.757534@serveur5.labri.fr>
Message-ID: <99ECFA1E-703D-11D9-9E87-000D93AD286C@bobobeach.com>


Ok, here's where I admit to not really knowing how to use a profiler 
for lisp code :-). But, keystroke processing seems like a pretty 
fundamental part of what an editor needs to do.

70 wpm ~= 400 char/min = 6 char/sec. We're looking at ~100 things on 
the list per char, so we're doing roughly 1000 comparisons per second. 
Not good.

Admittedly, (time ...) doesn't show that this isn't a bottleneck, but 
something somewhere between pressing the keystrokes and displaying the 
corresponding characters is slow. Plus, we're apparently (with openmcl 
at least) 500 bytes or so per trip through here. If I type 1000 
characters, I've just consed up 500kb of stuff I need to GC? I guess 
memory allocation is fast, and the GC quick too, but it seems like we 
could be doing a hash lookup here and not consing.

If you've got better places for me to look for the bottlenecks between 
typing and display, let me know.

Thanks,

Cyrus

On Jan 26, 2005, at 8:52 PM, Robert Strandh wrote:
> I seriously doubt that find-keystroke-item is the source of your
> problem.  While you are right, that it is doing a sequential search,
> it does so at interaction speed which is thousands of times slower.
>
> Have you profiled it to be sure that this is really the source of the
> poor response?



From csr21 at cam.ac.uk  Thu Jan 27 08:51:38 2005
From: csr21 at cam.ac.uk (Christophe Rhodes)
Date: Thu, 27 Jan 2005 08:51:38 +0000
Subject: [mcclim-devel] find-keystroke-item slowness
In-Reply-To: <99ECFA1E-703D-11D9-9E87-000D93AD286C@bobobeach.com> (Cyrus
	Harmon's message of "Thu, 27 Jan 2005 00:29:46 -0800")
References: <mailman.0.1106773669.17551.mcclim-devel@common-lisp.net>
	<3717BA2A-6FFB-11D9-9E87-000D93AD286C@bobobeach.com>
	<16888.29570.805706.757534@serveur5.labri.fr>
	<99ECFA1E-703D-11D9-9E87-000D93AD286C@bobobeach.com>
Message-ID: <sqsm4nmezp.fsf@cam.ac.uk>

Cyrus Harmon <ch-mcclim at bobobeach.com> writes:

> Ok, here's where I admit to not really knowing how to use a profiler
> for lisp code :-). 

I don't know what facilities OpenMCL provides for profiling.  However,
other implementations provide multiple methods for finding out where
time is spent; even if you're not using those implementations for
development, you can use them to get an idea where the bottleneck is.

> But, keystroke processing seems like a pretty
> fundamental part of what an editor needs to do.

Don't judge by what seems to be obvious.  Really.  You will be wrong.

> 70 wpm ~= 400 char/min = 6 char/sec. We're looking at ~100 things on
> the list per char, so we're doing roughly 1000 comparisons per
> second. Not good.

* (defvar *magic* (cons nil nil))
* (time (let ((x (cons nil nil))) (dotimes (i 1000000) (eql x *magic*))))

Evaluation took:
  0.167 seconds of real time
  0.166975 seconds of user run time

so 1000 comparisons will take about 0.0002 seconds.  That leaves
0.9998 seconds for other processing.  I'm pretty sure that 1000
comparisons is truly insignificant, but on the other hand I haven't
measured your setup, only mine.

> If you've got better places for me to look for the bottlenecks
> between typing and display, let me know.

Use a profiler.  Really.  Don't guess.

Cheers,

Christophe


From moore at bricoworks.com  Thu Jan 27 09:53:20 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Thu, 27 Jan 2005 10:53:20 +0100
Subject: [mcclim-devel] Confused by with-room-for-graphics
Message-ID: <46D60BDA-7049-11D9-BEEE-000A959839F8@bricoworks.com>

In the course of fixing a replay problem in with-room-for-graphics I 
took it upon myself to rewrite it to be consistent with the spec and 
the Franz manual, but now I'm thoroughly confused, especially by the 
menu drawing example. I had believed that the origin of the local 
coordinate system would be placed at the current cursor, possibly 
offset vertically by the height (if supplied) or by the maximum y value 
in the first quadrant case, even if this would result in some output 
with negative x coordinates being lost of the left edge of the screen. 
But  that means that the menu example in the Franz manual would lose 
the North and West points of the compass, which can't be right.

Can people with classic CLIM try this function in a listener (I believe 
classic CLIM has such a thing) and try (draw-compass *standard-output* 
'symbol t) and
(draw-compass *standard-output* nil)? I would like to know if  the 
entire compass is visible and if it overlaps other graphics in the 
output stream.

(defun draw-compass (stream &optional (type 'symbol) (quadrant nil))
   (labels ((draw-compass-point (stream type symbol x y)
              (clim:with-output-as-presentation (stream symbol type)
                (clim:draw-text* stream (symbol-name symbol) x y
                                 :align-x :center :align-y :center
                                 :text-style '(:sans-serif :roman 
:large)))))
     (clim:with-room-for-graphics (stream :first-quadrant quadrant)
       (clim:draw-line* stream 0 25 0 -25 :line-thickness 2)
       (clim:draw-line* stream 25 0 -25 0 :line-thickness 2)
       (dolist (point '((n 0 -30) (s 0 30) (e 30 0) (w -30 0)))
         (apply #'draw-compass-point stream type point)))))

Thanks a lot,
Tim



From daly at idsi.net  Thu Jan 27 12:02:36 2005
From: daly at idsi.net (root)
Date: Thu, 27 Jan 2005 07:02:36 -0500
Subject: [mcclim-devel] find-keystroke-item slowness
In-Reply-To: <sqsm4nmezp.fsf@cam.ac.uk> (message from Christophe Rhodes on
	Thu, 27 Jan 2005 08:51:38 +0000)
References: <mailman.0.1106773669.17551.mcclim-devel@common-lisp.net>
	<3717BA2A-6FFB-11D9-9E87-000D93AD286C@bobobeach.com>
	<16888.29570.805706.757534@serveur5.labri.fr>
	<99ECFA1E-703D-11D9-9E87-000D93AD286C@bobobeach.com>
	<sqsm4nmezp.fsf@cam.ac.uk>
Message-ID: <200501271202.j0RC2aM30509@localhost.localdomain>

Cyrus,

I might suggest using a program called valgrind.
You can run other programs under it and it will
give you useful profile information.

Tim Daly


From pw at snoopy.mv.com  Thu Jan 27 12:08:10 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Thu, 27 Jan 2005 07:08:10 -0500
Subject: [mcclim-devel] Confused by with-room-for-graphics
Message-ID: <20050127120810.23306.qmail@copper.mv.net>

 
> Can people with classic CLIM try this function in a listener (I believe 
> classic CLIM has such a thing) and try (draw-compass *standard-output* 
> 'symbol t) and
> (draw-compass *standard-output* nil)? I would like to know if  the 
> entire compass is visible and if it overlaps other graphics in the 
> output stream.

I don't use a clim listener but I ran the test in an application-pane.

The first case draws a compass with S on top and N at bottom.
The second case draws it with N at top and S at bottom.
Lines of text around calls appear as expected.
Calling draw-compass after outputting some text but no terminating newline
results with the compass drawn to the right of that text with the top of
the N seemingly aligned with the top of the text string and the left of
the W aligned with the end of text. I can try and get more precise
alignment of the bounding box if you need that.

Let me know if you really need the test run in a listener. I think there 
is one in the clim demo directory.

Paul



From pw at snoopy.mv.com  Thu Jan 27 12:26:06 2005
From: pw at snoopy.mv.com (Paul Werkowski)
Date: Thu, 27 Jan 2005 07:26:06 -0500
Subject: [mcclim-devel] Confused by with-room-for-graphics
Message-ID: <20050127122606.23810.qmail@copper.mv.net>

 Calling draw-compass after outputting some text but no terminating newline
> results with the compass drawn to the right of that text with the top of
> the N seemingly aligned with the top of the text string and the left of
> the W aligned with the end of text.

To be clear, that last statement was about the second test, with 
the quadrant parameter NIL (North on top).

Paul



From moore at bricoworks.com  Thu Jan 27 12:46:31 2005
From: moore at bricoworks.com (Timothy Moore)
Date: Thu, 27 Jan 2005 13:46:31 +0100
Subject: [mcclim-devel] Confused by with-room-for-graphics
In-Reply-To: <20050127120810.23306.qmail@copper.mv.net>
References: <20050127120810.23306.qmail@copper.mv.net>
Message-ID: <787B1D5B-7061-11D9-BEEE-000A959839F8@bricoworks.com>


On Jan 27, 2005, at 1:08 PM, Paul Werkowski wrote:

>
>> Can people with classic CLIM try this function in a listener (I 
>> believe
>> classic CLIM has such a thing) and try (draw-compass *standard-output*
>> 'symbol t) and
>> (draw-compass *standard-output* nil)? I would like to know if  the
>> entire compass is visible and if it overlaps other graphics in the
>> output stream.
>
> I don't use a clim listener but I ran the test in an application-pane.
>
Thank you very much. I think it's clear that with-room-for-graphics 
never lets its output extend above and to the left of the initial 
cursor position. The language in the spec about the placement of (0,0) 
is more of a minimum guarantee.

> Let me know if you really need the test run in a listener. I think 
> there
> is one in the clim demo directory.
>
That's not necessary.

Tim



From rpgoldman at real-time.com  Thu Jan 27 17:58:47 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 27 Jan 2005 11:58:47 -0600
Subject: [mcclim-devel] Problem with PRECACHE-ICONS in CLIM-LISTENER on
 Allegro 6.2 left-clicking field in ACCEPTING-VALUES dialog
In-Reply-To: <87ekgea8o3.fsf@plato.moon.paoloamoroso.it>
References: <87ekgea8o3.fsf@plato.moon.paoloamoroso.it>
Message-ID: <16889.11223.734103.34903@gargle.gargle.HOWL>


I was trying to replicate this bug, and I find now that loading the
clim listener crashes when it's unable to find a compiled version of 
"/home/rpg/lisp/mcclim/Apps/Listener/icons/CVS".  

As far as I can tell, this is because the REMOVE-IF #'directoryp in
PRECACHE-ICONS is not working for me.

Here's the unpleasant behavior that's responsible for the bug:

[1] CLIM-LISTENER(9): (setf pn *)
#p"/home/rpg/lisp/mcclim/Apps/Listener/icons/CVS"
[1] CLIM-LISTENER(10): (directoryp pn)
NIL
[1] CLIM-LISTENER(11): (pathname-name pn)
"CVS"

The relevant code snippet:

; There has to be a better way..
(defun directoryp (pathname)
  "Returns pathname when supplied with a directory, otherwise nil"
  (if (or (pathname-name pathname) (pathname-type pathname))
      nil
      pathname))

Reasonable-patch-p?

(defun directoryp (pathname)
  "Returns pathname when supplied with a directory, otherwise nil"
  #+allegro (excl:file-directory-p pathname)
  #-allegro
  (if (or (pathname-name pathname) (pathname-type pathname))
      nil
      pathname))

Cheers,
r


From rpgoldman at real-time.com  Thu Jan 27 18:00:34 2005
From: rpgoldman at real-time.com (rpgoldman at real-time.com)
Date: Thu, 27 Jan 2005 12:00:34 -0600
Subject: [mcclim-devel] Problem with PRECACHE-ICONS in CLIM-LISTENER on
	Allegro 6.2 left-clicking field in ACCEPTING-VALUES dialog
In-Reply-To: <16889.11223.734103.34903@gargle.gargle.HOWL>
References: <87ekgea8o3.fsf@plato.moon.paoloamoroso.it>
	<16889.11223.734103.34903@gargle.gargle.HOWL>
Message-ID: <16889.11330.984209.749667@gargle.gargle.HOWL>


Argh.  Sorry about the command line --- had started out to edit
Paolo's message, and didn't successfully remove all of his command
line...



From sketerpot at gmail.com  Thu Jan 27 20:52:25 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Thu, 27 Jan 2005 13:52:25 -0700
Subject: [mcclim-devel] Customizing interactor panes
Message-ID: <7e267a92050127125273988289@mail.gmail.com>

I'm writing a GUI for a chemistry program with McCLIM. My problem is
that I want the user to be able to type commands into the interactor
pane in a special syntax, which I have written a parser for. For
example, typing "Krypton" should call the Inspect Element command on
the element called "Krypton". Typing "12 g C H4" should display how
many moles of methane there are in 12 g. There's more like that, but I
have the code to handle it all written---except for the code that
hooks it into an interactor pane.

There's a way of getting an interactor pane to differentiate between
commands and s-expressions, for use in a listener, so I think that
what I want is possible. Can anybody tell me how?

-Peter


From rpgoldman at sift.info  Thu Jan 27 21:59:13 2005
From: rpgoldman at sift.info (Robert P. Goldman)
Date: Thu, 27 Jan 2005 15:59:13 -0600
Subject: [mcclim-devel] patch to fix-acl.lisp
Message-ID: <16889.25649.499268.475421@gargle.gargle.HOWL>


I am not at all sure that this is The Right Thing, but I found that
the fix-acl code that makes the clim-mop package didn't work for me,
because it assumed that the right thing was to export all the external
symbols from the CLOS package from CLIM-MOP.  But some of the symbols
we want seem to actually be in the COMMON-LISP package, instead.

Anyway, here's a proposed fix.  Please let me know if I've committed
some solecism or other:

Index: fix-acl.lisp
===================================================================
RCS file: /project/mcclim/cvsroot/mcclim/Lisp-Dep/fix-acl.lisp,v
retrieving revision 1.9
diff -u -F^(def -r1.9 fix-acl.lisp
--- fix-acl.lisp	21 Mar 2003 15:15:09 -0000	1.9
+++ fix-acl.lisp	27 Jan 2005 21:56:35 -0000
@@ -5,15 +5,49 @@
 ;;; Needed to keep ACL from issuing warnings about toplevel (shadow ...) forms
 (setq comp:*cltl1-compile-file-toplevel-compatibility-p* nil)
 
-(require :loop)
+(eval-when (:compile-toplevel :load-toplevel :execute)
+  (require :loop)
+  (require :mop))
 
 (defpackage :clim-mop
-  (:use :clos))
-
+  (:use :clos :common-lisp)
+  (:export
+   #:validate-superclass
+   #:class-finalized-p
+   #:finalize-inheritance
+   #:class-prototype
+   #:class-name
+   #:class-precedence-list
+   #:class-direct-superclasses
+   #:class-direct-subclasses
+   #:class-direct-slots
+   "CLASS-SLOTS"
+   "SLOT-DEFINITION-NAME"
+   "SLOT-DEFINITION-TYPE"
+   "SLOT-DEFINITION-INITARGS"
+   "SLOT-DEFINITION-INITFUNCTION"
+   "SLOT-DEFINITION-INITFORM"
+   "SLOT-DEFINITION-READERS"
+   "SLOT-DEFINITION-WRITERS"
+   "SLOT-DEFINITION-ALLOCATION"
+   #:ensure-class
+   #:funcallable-standard-class
+   #:method-specializers
+   #:method-qualifiers
+   #:method-lambda-list
+   #:method-generic-function
+   #:generic-function-methods
+   #:generic-function-name
+   "GENERIC-FUNCTION-LAMBDA-LIST"
+   "GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER"
+   #:eql-specializer
+   #:eql-specializer-object
+   #:intern-eql-specializer
+   #:compute-applicable-methods-using-classes))
 
-(eval-when (:compile-toplevel :load-toplevel :execute)
-  (do-external-symbols (sym :clos)
-	(export sym :clim-mop)))
+;;;(eval-when (:compile-toplevel :load-toplevel :execute)
+;;;  (do-external-symbols (sym :clos)
+;;;	(export sym :clim-mop)))
 
 (eval-when (:compile-toplevel :load-toplevel :execute)
   (export '(clim-lisp-patch::defclass)



From ahefner at gmail.com  Thu Jan 27 22:59:36 2005
From: ahefner at gmail.com (Andy Hefner)
Date: Thu, 27 Jan 2005 17:59:36 -0500
Subject: [mcclim-devel] Customizing interactor panes
In-Reply-To: <7e267a92050127125273988289@mail.gmail.com>
References: <7e267a92050127125273988289@mail.gmail.com>
Message-ID: <31ffd3c405012714597d72c3bc@mail.gmail.com>

This sort of thing is really determined by what the top-level loop of
the application does rather than any property of the interactor pane.
If you look at the top-level function in the listener, it simply peeks
at the first character typed and then decides whether to read a
command or a lisp form based on that. Unfortunately this is a rather
low-level way of doing things and at timess undermine some of the nice
features that McCLIM would normally provide (keyboard accelerator
gestures, completion, etc). I don't mind working around this to retain
absolute control, but I'd recommend a different approach.

CLIM contains an "or" presentation type which allows you to accept one
of a number of types. The default accept method for this type attempts
to read the first type in the list textually. If the accept method for
the first type in the list signals a parse error, it tries to read as
the next type, and so on. What might work for you is to define a
presentation type for elements and one for whatever else as "12g C
H4", with accept methods for each type which call your parser. Then
you can write a top-level loop that accepts '(or command element
whatever-else..) and examines second value returned (presentation type
of input) to decide what to do (call execute-frame-command, inpect
element, etc).

I haven't made much use of this technique, but it seems like right way
to do it. I'm concerned that the command parser may continue reading
and block you from entering things such as "Krypton". Things that
don't resemble command names, such as "12 g C H4", should work. If
this is indeed a problem, I'm sure we can find a way to make it work.


On Thu, 27 Jan 2005 13:52:25 -0700, Peter Scott <sketerpot at gmail.com> wrote:
> I'm writing a GUI for a chemistry program with McCLIM. My problem is
> that I want the user to be able to type commands into the interactor
> pane in a special syntax, which I have written a parser for. For
> example, typing "Krypton" should call the Inspect Element command on
> the element called "Krypton". Typing "12 g C H4" should display how
> many moles of methane there are in 12 g. There's more like that, but I
> have the code to handle it all written---except for the code that
> hooks it into an interactor pane.
> 
> There's a way of getting an interactor pane to differentiate between
> commands and s-expressions, for use in a listener, so I think that
> what I want is possible. Can anybody tell me how?


From strandh at labri.fr  Sat Jan 29 07:28:57 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sat, 29 Jan 2005 08:28:57 +0100
Subject: [mcclim-devel] Adding the inspector application to McCLIM
Message-ID: <16891.15161.44642.797897@serveur5.labri.fr>

Hello, 

I am thinking of adding the rudimentary inspector application that I 
started writing as an application in the McCLIM tree.  This would
allow for other people to work on it without my having to apply
patches, and of course it would be in a CVS tree. 

Any objections?
-- 
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  Sun Jan 30 13:51:46 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Sun, 30 Jan 2005 14:51:46 +0100
Subject: [mcclim-devel] INSPECTOR::CLASS-SLOTS: no MOP error when evaluating
 sample Inspector form
Message-ID: <87acqr2ff1.fsf@plato.moon.paoloamoroso.it>

When I evaluate the sample Inspector form in Apps/Inspector/INSTALL:

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

An incomplete application frame appears, and I get the error with
backtrace included below.  I use the latest McCLIM CVS sources with
CMUCL Snapshot 2005-01 under Slackware Linux 10.0.


Paolo

---------------------------------------------------------------------
Error in function INSPECTOR::CLASS-SLOTS:  no MOP
   [Condition of type SIMPLE-ERROR]

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

Debug  (type H for help)

(INSPECTOR::CLASS-SLOTS #<unused-arg>)
Source:
; File: /home/paolo/src/mcclim/Apps/Inspector/inspector.lisp
(ERROR "no MOP")
0] backtrace

0: (INSPECTOR::CLASS-SLOTS #<unused-arg>)
1: ((LABELS #:.CONT.29
      (FLET #:CONTINUATION32
        #))
    #<unused-arg>)
2: ((FLET #:CONTINUATION15
      (FLET #:CONTINUATION3
        CLIM-INTERNALS::INVOKE-FORMATTING-TABLE))
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>)
3: ((METHOD CLIM:INVOKE-WITH-OUTPUT-RECORDING-OPTIONS NIL
     (CLIM:OUTPUT-RECORDING-STREAM T T T))
    #<unused-arg> #<unused-arg>
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
    #<Closure Over Function (FLET #:CONTINUATION15
                              #)
      {589B8FB1}>
    ...)
4: ((FLET #:CONTINUATION3
      CLIM-INTERNALS::INVOKE-FORMATTING-TABLE)
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
    #<CLIM:STANDARD-TABLE-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0 {589B8E45}>)
5: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL
     (CLIM:OUTPUT-RECORDING-STREAM T T T))
    (#() . #(#)) #<unused-arg>
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
    #<Closure Over Function (FLET #:CONTINUATION3
                              CLIM-INTERNALS::INVOKE-FORMATTING-TABLE)
      {589B8761}>
    ...)
6: ((FLET #:CONTINUATION32
      (FLET #:CONTINUATION37
        #))
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}> #<unused-arg>)
7: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL
     (CLIM:OUTPUT-RECORDING-STREAM T T T))
    (#() . #(#)) #<unused-arg>
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
    #<Closure Over Function (FLET #:CONTINUATION32
                              #)
      {589B7FD1}>
    ...)
8: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL
     (CLIM:OUTPUT-RECORDING-STREAM T T T))
    (#() . #(#)) #<unused-arg>
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
    #<Closure Over Function (FLET #:CONTINUATION37
                              #)
      {58381DE1}>
    ...)
9: ((FLET #:CONTINUATION15
      (FLET #:CONTINUATION3
        CLIM-INTERNALS::INVOKE-FORMATTING-TABLE))
    #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>)
10: ((METHOD CLIM:INVOKE-WITH-OUTPUT-RECORDING-OPTIONS NIL
      (CLIM:OUTPUT-RECORDING-STREAM T T T))
     #<unused-arg> #<unused-arg>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
     #<Closure Over Function (FLET #:CONTINUATION15
                               #)
       {58380F71}>
     ...)
11: ((FLET #:CONTINUATION3
       CLIM-INTERNALS::INVOKE-FORMATTING-TABLE)
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
     #<CLIM:STANDARD-TABLE-OUTPUT-RECORD X 0.0d0:0.0d0 Y 0.0d0:0.0d0
       {5838032D}>)
12: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL
      (CLIM:OUTPUT-RECORDING-STREAM T T T))
     (#() . #(#)) #<unused-arg>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
     #<Closure Over Function (FLET #:CONTINUATION3
                               CLIM-INTERNALS::INVOKE-FORMATTING-TABLE)
       {5837F961}>
     ...)
13: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL
      (CLIM:OUTPUT-RECORDING-STREAM T T T))
     (#() . #(#)) #<unused-arg>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>
     #<Closure Over Function (FLET #:CONTINUATION149
                               )
       {58295A01}>
     ...)
14: ((METHOD INSPECTOR::INSPECT-OBJECT NIL (STANDARD-OBJECT T)) (#() . #(#))
     #<unused-arg> #<INSPECTOR::INSPECTOR {589A0D6D}>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>)
15: ((METHOD INSPECTOR::INSPECT-OBJECT (:AROUND) (T T)) #<unused-arg>
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {58C640B9}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL
                                 :FUNCTION #
                                 :PV-CELL NIL
                                 :NEXT-METHOD-CALL NIL
                                 :ARG-INFO #)
          :ARG-INFO (2))
     #<INSPECTOR::INSPECTOR {589A0D6D}>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>)
16: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G6398 G6399 G6400)" #<unused-arg>
     #<unused-arg> #<INSPECTOR::INSPECTOR {58A0AD4D}>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}> ...)
17: ((METHOD CLIM:REDISPLAY-FRAME-PANE (:AROUND) (CLIM:APPLICATION-FRAME T))
     (#(21 21) . #())
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Closure Over Function "LAMBDA (.KEYARGS-START. .VALID-KEYS. G6398 G6399 G6400)"
                      {5827E9B9}>
          :PV-CELL NIL
          :NEXT-METHOD-CALL NIL
          :ARG-INFO (2 . T))
     #<INSPECTOR::INSPECTOR {58A0AD4D}>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}> ...)
18: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM:APPLICATION-PANE INSPECTOR::APP {58C93555}>)
19: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM-INTERNALS::BORDER-PANE "(Unnamed Pane)" {58CAEC25}>)
20: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM:VRACK-PANE "(Unnamed Pane)" {58CAEB65}>)
21: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM-EXTENSIONS:VIEWPORT-PANE "(Unnamed Pane)" {58CAEC15}>)
22: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM:SCROLLER-PANE "(Unnamed Pane)" {58CAEBE5}>)
23: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM:VRACK-PANE "(Unnamed Pane)" {58CAEBA5}>)
24: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM:VRACK-PANE "(Unnamed Pane)" {58C7CB6D}>)
25: ((METHOD CLIM:MAP-OVER-SHEETS NIL (T CLIM:BASIC-SHEET)) (#() . #(#))
     #<unused-arg>
     #<Closure Over Function "DEFMETHOD REDISPLAY-FRAME-PANES (APPLICATION-FRAME)"
       {5806EC69}>
     #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE CLIM-INTERNALS::TOP-LEVEL-SHEET
       {581106D5}>)
26: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#() . #(# # # # # ...)) #<unused-arg> #<INSPECTOR::INSPECTOR {58A0AD4D}>
     NIL)
27: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4920)" #<unused-arg> #<unused-arg>
     #<INSPECTOR::INSPECTOR {58A0AD4D}> NIL)
28: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME))
     (#(20) . #()) #<unused-arg> #<INSPECTOR::INSPECTOR {58A0AD4D}>
     #<unused-arg>)
29: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME))
     (#(16 15) . #(#))
     #S(PCL::FAST-METHOD-CALL
          :FUNCTION #<Function # {11682759}>
          :PV-CELL (# . #)
          :NEXT-METHOD-CALL NIL
          :ARG-INFO (1 . T))
     #<INSPECTOR::INSPECTOR {58A0AD4D}> NIL)
30: (INSPECTOR::INSPECTOR #<INSPECTOR::INSPECTOR {589A0D6D}>)
31: (INTERACTIVE-EVAL
     (INSPECTOR::INSPECTOR
      (CLIM:MAKE-APPLICATION-FRAME 'INSPECTOR::INSPECTOR :OBJ 20)))
32: (LISP::%TOP-LEVEL)
33: ((LABELS LISP::RESTART-LISP
       SAVE-LISP))

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

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


From strandh at labri.fr  Sun Jan 30 16:44:41 2005
From: strandh at labri.fr (Robert Strandh)
Date: Sun, 30 Jan 2005 17:44:41 +0100
Subject: [mcclim-devel] INSPECTOR::CLASS-SLOTS: no MOP error when evaluating
	sample Inspector form
In-Reply-To: <87acqr2ff1.fsf@plato.moon.paoloamoroso.it>
References: <87acqr2ff1.fsf@plato.moon.paoloamoroso.it>
Message-ID: <16893.3833.386620.987984@serveur5.labri.fr>

Paolo Amoroso writes:
 > When I evaluate the sample Inspector form in Apps/Inspector/INSTALL:
 > 
 >   (inspector::inspector (clim:make-application-frame 'inspector::inspector :obj 20))
 > 
 > An incomplete application frame appears, and I get the error with
 > backtrace included below.  I use the latest McCLIM CVS sources with
 > CMUCL Snapshot 2005-01 under Slackware Linux 10.0.

Yes, simply because nobody put in the code for CMUCL yet.

-- 
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 matthieu.villeneuve at free.fr  Sun Jan 30 20:15:42 2005
From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr)
Date: Sun, 30 Jan 2005 21:15:42 +0100
Subject: [mcclim-devel] INSPECTOR::CLASS-SLOTS: no MOP error when
	evaluating sample Inspector form
In-Reply-To: <16893.3833.386620.987984@serveur5.labri.fr>
References: <87acqr2ff1.fsf@plato.moon.paoloamoroso.it>
	<16893.3833.386620.987984@serveur5.labri.fr>
Message-ID: <1107116142.41fd406e348d5@imp5-q.free.fr>

Quoting Robert Strandh <strandh at labri.fr>:
> Paolo Amoroso writes:
>  > When I evaluate the sample Inspector form in Apps/Inspector/INSTALL:
>  >
>  >   (inspector::inspector (clim:make-application-frame 'inspector::inspector
> :obj 20))
>  >
>  > An incomplete application frame appears, and I get the error with
>  > backtrace included below.  I use the latest McCLIM CVS sources with
>  > CMUCL Snapshot 2005-01 under Slackware Linux 10.0.
>
> Yes, simply because nobody put in the code for CMUCL yet.

Here is a patch that seems to do the job.


--
Matthieu Villeneuve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inspector-cmucl.patch
Type: application/octet-stream
Size: 2077 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050130/cab14e03/attachment.obj>

From asf at boinkor.net  Mon Jan 31 13:28:23 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 31 Jan 2005 14:28:23 +0100
Subject: [mcclim-devel] asdf-install ready mcclim.asd
Message-ID: <87mzup918o.wl%asf@boinkor.net>

Hello,

I spent the last day hacking the McCLIM system definition.

My goals were:

  * Adding real dependency information for files, to improve the
    McCLIM user experience (it's notorious for its long compile cycles
    after a cvs up)
  * Making it ASDF-INSTALLable, via a system called :MCCLIM that pulls
    in the :CLIM system and a suitable backend

The .asd file at <URL:http://boinkor.net/lisp/mcclim.asd> is the
result. (Not attached because common-lisp.net doesn't allow .asd files
in attachments.)

As you can see, this drops support for all non-ASDF defsystems, and
gets us halfway through the first goal - I couldn't load all systems
to get dependency information from them (clim-opengl, clim-beagle and
scigraph), but the bigger systems like CLIM-CORE and CLIM are fully
working. After a change to setf-star.lisp, ASDF now recompiles 6 files
instead of 20. (-:

The second goal was easier: what I did was move the system definitions
for clim-clx, clim-opengl and beagle (now clim-beagle for consistency)
into the mcclim.asd file, and frobnicated the CLIM-LOOKS system to
depend on the correct backend system in the right circumstances.

I'm not absolutely sure if CLIM-LOOKS' behavior is correct for Mac
users (it loads beagle). If you have an MCL or OpenMCL installation,
so please test. Really, I only tested it on Linux/x86/X11/SBCL. Other
combinations were not tested. If you want to find out if it will work
for you, install it and run it yourself.

To install the system, follow these steps:

 1. put the mcclim.asd file into your McCLIM installation directory
 2. symlink it to a directory in your ASDF:*CENTRAL-REPOSITORY* (for
    SBCL users, this is ~/.sbcl/systems)
 3. On the lisp REPL, (asdf:oos 'asdf:load-op :mcclim)


If anybody does a snapshot of mcclim with this .asd file and puts the
ASDF-INSTALL link on http://cliki.net/mcclim, people will also be able
to asdf-install McClim.

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


From rm at seid-online.de  Mon Jan 31 14:09:01 2005
From: rm at seid-online.de (rm at seid-online.de)
Date: Mon, 31 Jan 2005 15:09:01 +0100
Subject: [mcclim-devel] Apps/Inspector
Message-ID: <20050131140901.GF8106@seid-online.de>


Hello List,

i just did an cvs update to have a look at 
the new Inspector but unfortunately the code
doesn't show up at all :-(

Any idea what's happening?

  TIA Ralf Mattes


From rudi at constantly.at  Mon Jan 31 14:42:51 2005
From: rudi at constantly.at (Rudi Schlatte)
Date: Mon, 31 Jan 2005 15:42:51 +0100
Subject: [mcclim-devel] Apps/Inspector
In-Reply-To: <20050131140901.GF8106@seid-online.de>
References: <20050131140901.GF8106@seid-online.de>
Message-ID: <541e5e4e19e2cf9c22b4616051773010@constantly.at>


On 31. J?n 2005, at 15:09, rm at seid-online.de wrote:
> i just did an cvs update to have a look at
> the new Inspector but unfortunately the code
> doesn't show up at all :-(
>
> Any idea what's happening?

cvs update -dP worked for me.  Did you perhaps forget the -d parameter?

Rudi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050131/ca476fee/attachment.sig>

From matthieu.villeneuve at free.fr  Mon Jan 31 14:42:39 2005
From: matthieu.villeneuve at free.fr (matthieu.villeneuve at free.fr)
Date: Mon, 31 Jan 2005 15:42:39 +0100
Subject: [mcclim-devel] Apps/Inspector
In-Reply-To: <20050131140901.GF8106@seid-online.de>
References: <20050131140901.GF8106@seid-online.de>
Message-ID: <1107182559.41fe43df701bc@imp3-q.free.fr>

Hello,

Selon rm at seid-online.de:
>
> Hello List,
>
> i just did an cvs update to have a look at
> the new Inspector but unfortunately the code
> doesn't show up at all :-(
>
> Any idea what's happening?

Did you use the -d option with cvs update? It is required so that
cvs update builds directories that do not exist on your local source
directory (and the inspector code is in a new 'Apps/Inspector'
directory).


--
Matthieu Villeneuve


From amoroso at mclink.it  Mon Jan 31 18:01:44 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 31 Jan 2005 19:01:44 +0100
Subject: [mcclim-devel] asdf-install ready mcclim.asd
References: <87mzup918o.wl%asf@boinkor.net>
Message-ID: <87is5dbhpz.fsf@plato.moon.paoloamoroso.it>

Andreas Fuchs <asf at boinkor.net> writes:

> I spent the last day hacking the McCLIM system definition.
>
> My goals were:
>
>   * Adding real dependency information for files, to improve the
>     McCLIM user experience (it's notorious for its long compile cycles
>     after a cvs up)
[...]
> The .asd file at <URL:http://boinkor.net/lisp/mcclim.asd> is the
> result. (Not attached because common-lisp.net doesn't allow .asd files
[...]
> working. After a change to setf-star.lisp, ASDF now recompiles 6 files
> instead of 20. (-:

I tried doing fresh--i.e. with no previous fasl files--builds from
source with both the McCLIM stock system definition in system.lisp,
and yours in mcclim.asd.  In the former case I evaluated:

  (time (asdf:operate 'asdf:load-op :clim-clx-user))

with the following results:

; Evaluation took:
;   105.52 seconds of real time
;   98.77198 seconds of user run time
;   5.588151 seconds of system run time
;   295,305,900,480 CPU cycles
;   [Run times include 17.97 seconds GC run time]
;   76 page faults and
;   2,846,968,944 bytes consed.
;
NIL

With your system definition I did two fresh builds:

  (time (asdf:operate 'asdf:load-op :mcclim))

with these results:

; Evaluation took:
;   114.92 seconds of real time
;   107.795616 seconds of user run time
;   6.215055 seconds of system run time
;   321,613,490,332 CPU cycles
;   [Run times include 19.19 seconds GC run time]
;   0 page faults and
;   2,926,042,568 bytes consed.
;
NIL

; Evaluation took:
;   105.63 seconds of real time
;   100.02179 seconds of user run time
;   5.436173 seconds of system run time
;   295,608,660,228 CPU cycles
;   [Run times include 18.29 seconds GC run time]
;   0 page faults and
;   2,927,419,672 bytes consed.
;
NIL

I use the latest McCLIM CVS sources with CMUCL Snapshot 2005-01 under
Slackware Linux 10.0, running on a 2.8 GHz Pentium IV with 2 GB of
RAM.


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


From asf at boinkor.net  Mon Jan 31 19:13:00 2005
From: asf at boinkor.net (Andreas Fuchs)
Date: Mon, 31 Jan 2005 20:13:00 +0100
Subject: [mcclim-devel] asdf-install ready mcclim.asd
In-Reply-To: <87is5dbhpz.fsf@plato.moon.paoloamoroso.it>
References: <87mzup918o.wl%asf@boinkor.net>
	<87is5dbhpz.fsf@plato.moon.paoloamoroso.it>
Message-ID: <87k6pt8lab.wl%asf@boinkor.net>

Today, Paolo Amoroso <amoroso at mclink.it> wrote:
> I tried doing fresh--i.e. with no previous fasl files--builds from
> source with both the McCLIM stock system definition in system.lisp,
> and yours in mcclim.asd.  In the former case I evaluated:
>
> (time (asdf:operate 'asdf:load-op :clim-clx-user))
>
> with the following results:
>
> ; Evaluation took:
> ;   105.52 seconds of real time
> ;   98.77198 seconds of user run time
> ;   5.588151 seconds of system run time
> ;   295,305,900,480 CPU cycles
> ;   [Run times include 17.97 seconds GC run time]
> ;   76 page faults and
> ;   2,846,968,944 bytes consed.
> ;
> NIL
>
> With your system definition I did two fresh builds:
>
> (time (asdf:operate 'asdf:load-op :mcclim))
>
> with these results:
>
> ; Evaluation took:
> ;   114.92 seconds of real time
> ;   107.795616 seconds of user run time
> ;   6.215055 seconds of system run time
> ;   321,613,490,332 CPU cycles
> ;   [Run times include 19.19 seconds GC run time]
> ;   0 page faults and
> ;   2,926,042,568 bytes consed.
> ;
> NIL
>
> ; Evaluation took:
> ;   105.63 seconds of real time
> ;   100.02179 seconds of user run time
> ;   5.436173 seconds of system run time
> ;   295,608,660,228 CPU cycles
> ;   [Run times include 18.29 seconds GC run time]
> ;   0 page faults and
> ;   2,927,419,672 bytes consed.
> ;
> NIL
> 
> I use the latest McCLIM CVS sources with CMUCL Snapshot 2005-01
> under Slackware Linux 10.0, running on a 2.8 GHz Pentium IV with 2
> GB of RAM.

So it worked (-:

Of course, with a fresh build, there won't be any performance
improvements in build time - quite to the contrary, the additional
dependency information adds a bit of overhead.

The real improvements happen if you happen to touch just one file in
an already-built McCLIM installation, like setf-star.lisp that I
mentioned (requires 14 fewer files to be rebuilt, compared to
system.lisp), or repaint.lisp (7 fewer files).

By the way, I have put up an asdf-installable tarball of yesterday's
McCLIM CVS checkout (non-anonymous CVS, though).

Testers, get it via ASDF-INSTALL by running:

(asdf-install:install "http://boinkor.net/lisp/mcclim/mcclim-2005-01-31.tar.gz")

on your favorite lisp REPL. One pitfall: remove old links to
system.lisp from your asdf:*central-registry* directories. I had to
remove symlinks called clim.asd, clim-clx.asd, clim-clx-user.asd and
clim-listener.asd.

Nice test case after you installed it:

(asdf:oos 'asdf:load-op :clim-examples)
(clim-demo::run-test 'clim-demo::method-browser)

and enter clim:note-sheet-grafted (-:

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


From amoroso at mclink.it  Mon Jan 31 19:44:08 2005
From: amoroso at mclink.it (Paolo Amoroso)
Date: Mon, 31 Jan 2005 20:44:08 +0100
Subject: [mcclim-devel] asdf-install ready mcclim.asd
References: <87mzup918o.wl%asf@boinkor.net>
	<87is5dbhpz.fsf@plato.moon.paoloamoroso.it>
	<87k6pt8lab.wl%asf@boinkor.net>
Message-ID: <87651dz8mv.fsf@plato.moon.paoloamoroso.it>

Andreas Fuchs <asf at boinkor.net> writes:

> The real improvements happen if you happen to touch just one file in
> an already-built McCLIM installation, like setf-star.lisp that I

Here are some tests done after rebuilding my brain from source--yes,
fresh build...

On the same machine and setup, touching setf-star.lisp with McCLIM's
system definition in system.lisp:

  (time (asdf:operate 'asdf:load-op :clim-clx-user))

; Evaluation took:
;   53.7 seconds of real time
;   49.69545 seconds of user run time
;   3.013542 seconds of system run time
;   150,293,052,412 CPU cycles
;   [Run times include 8.22 seconds GC run time]
;   65 page faults and
;   1,468,144,312 bytes consed.
;
NIL

With your defsystem in mcclim.asd:

  (time (asdf:operate 'asdf:load-op :mcclim))

; Evaluation took:
;   30.71 seconds of real time
;   29.042583 seconds of user run time
;   1.57676 seconds of system run time
;   85,941,184,796 CPU cycles
;   [Run times include 4.61 seconds GC run time]
;   0 page faults and
;   827,465,488 bytes consed.
;
NIL


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


From sketerpot at gmail.com  Mon Jan 31 21:15:44 2005
From: sketerpot at gmail.com (Peter Scott)
Date: Mon, 31 Jan 2005 14:15:44 -0700
Subject: [mcclim-devel] Inspector MOP
Message-ID: <7e267a9205013113155951458@mail.gmail.com>

The Inspector is nice, but its MOP code is a thin layer of abstraction
over the MOPs of SBCL and OpenMCL. If you're not running one of those,
it gives you a "No MOP" error. Matthieu Villeneuve's patch adds
support for CMUCL, but it seems like suplication of the work already
done with CLIM-MOP.

Here's a patch that deletes the compatibility code and changes
everything to use CLIM-MOP. It works for me on SBCL 0.8.16. If it
breaks anything, let me know.

-Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inspector-mop.patch
Type: text/x-patch
Size: 3425 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050131/f2b628bb/attachment.bin>