Executive summary: McCLIM combines classy conservative 70s graphic
monochorme display looks with cool futuristic 2*10^9 CPU cycles per second
computational hunger.
I tried McCLIM the other day, specifically its calculator and addressbook
demos. It appears that when they are waiting for user input, they eat up
close to 100% of CPU cycles. Does anyone know why? Are they DOS ports?
Neo-LISPer wrote:
> Executive summary: McCLIM combines classy conservative 70s graphic
> monochorme display looks with cool futuristic 2*10^9 CPU cycles per
second
> computational hunger.
It is simply trying to remain faithful to CLIM.
--tim
From: Christophe Rhodes
Subject: Re: McCLIM - a system of contrasts
Date:
Message-ID: <sqfz3ahktn.fsf@cam.ac.uk>
"Tim Bradshaw" <··········@tfeb.org> writes:
> Neo-LISPer wrote:
>> Executive summary: McCLIM combines classy conservative 70s graphic
>> monochorme display looks with cool futuristic 2*10^9 CPU cycles per
>> second
>> computational hunger.
>
> It is simply trying to remain faithful to CLIM.
Who is the greater fool? The fool or he who follows him?
Christophe
Neo-LISPer <··········@yahoo.com> wrote in message news:<··················@yahoo.com>...
> Executive summary: McCLIM combines classy conservative 70s graphic
> monochorme display looks with cool futuristic 2*10^9 CPU cycles per second
> computational hunger.
As one of the many people who have devoted a great deal of time to
developing McCLIM, I thank you for your thoughtful and erudite
contribution.
CLIM is a comprehensive and featureful design. Given the limited
developer resources of the McCLIM project, the focus has generally
been toward fully implementing the spec, which we are quite close to.
It is largely a labor of love. Along the way some graphical bells and
whistles have been overlooked, and of course we aim to improve things
in the future. Having said that, "70s graphic monochorme display
looks" is a bit harsh. Further, in my opinion these crude demos show
little of what McCLIM is currently capable of.
The CLIM drawing, layout, and event handling APIs are well designed
and make implementing new gadget classes exceptionally easy and fun.
Improving the look and feel of existing gadgets is largely a matter of
adding a bevel here, a shadow there, etc. It could be fun and
rewarding work for an eager volunteer with a good eye.
> I tried McCLIM the other day, specifically its calculator and addressbook
> demos. It appears that when they are waiting for user input, they eat up
> close to 100% of CPU cycles. Does anyone know why? Are they DOS ports?
You have probably encountered a CMUCL "feature" related to its
implementation of multiprocessing. If you read the documentation in
INSTALL.CMU, you will find an explanation and solution.
Neo-LISPer <··········@yahoo.com> writes:
> Executive summary: McCLIM combines classy conservative 70s graphic
> monochorme display looks with cool futuristic 2*10^9 CPU cycles per second
> computational hunger.
>
>
> I tried McCLIM the other day, specifically its calculator and addressbook
> demos. It appears that when they are waiting for user input, they eat up
> close to 100% of CPU cycles. Does anyone know why? Are they DOS ports?
Well, no.
I can't argue with the first part of your executive summary, but the
performance problems you describe were fixed a long time ago in
McCLIM. It's certainly our (perhaps my) fault that we haven't made a
release in some time. I'd recommend the CVS McCLIM; if the problems
persist, let us know.
Tim
On Mon, 15 Nov 2004 03:45:38 -0800, Neo-LISPer wrote:
> I tried McCLIM the other day, specifically its calculator and
> addressbook demos. It appears that when they are waiting for user input,
> they eat up close to 100% of CPU cycles. Does anyone know why? Are they
> DOS ports?
If you are using CMUCL, you might need to start the idle and
top-level-loops, like this (before you start the demo):
(mp::startup-idle-and-top-level-loops)
or like this (from McCLIM's INSTALL.CMU):
(setf mp::*idle-process* mp::*initial-process*)
At least that's what I had to do to make the 100% cpu time thing stop last
time I was using McCLIM on cmucl.
Good luck,
--
Andreas Fuchs, <···@boinkor.net>, ···@jabber.at, antifuchs
Neo-LISPer <··········@yahoo.com> writes:
> Executive summary: McCLIM combines classy conservative 70s graphic
> monochorme display looks with cool futuristic 2*10^9 CPU cycles per second
> computational hunger.
You may want to try Cello.
> I tried McCLIM the other day, specifically its calculator and addressbook
> demos. It appears that when they are waiting for user input, they eat up
> close to 100% of CPU cycles. Does anyone know why? Are they DOS ports?
"Make it work first before you make it work fast" -- Bruce Whiteside
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface