Hello,
I am learning CLIM, using LW's CLIM and McCLIM. Assuming this is the
right place discuss this issue, here are a few questions:
1) Is there a mailing list dedicated to McCLIM ? I tried to send a
mail to free-clim-request at mikemac.com and free-clim at mikemac.com
without success.
2) When I run a demo that comes with McCLIM (snapshot 12/06/03) with
CMUCL 18e, the lisp process use 100% of the CPU even if the
application does nothing. Is there something specific to CMUCL that
must be done to avoid this ?
3) My first CLIM test is very minimalist:
(define-application-frame test1 ()
((state :initform '(a b c) :accessor state)
(counter :initform 0 :accessor counter))
(:panes
(in :interactor)))
When I run it with CMUCL/McCLIM I get the folowing error:
(It works as expected with LW/CLIM)
* (run-frame-top-level (make-application-frame 'test1))
NIL fell through ECASE expression. Wanted one of ().
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
("DEFINE-APPLICATION-FRAME TEST1" #<unused-arg> #<unused-arg>
#<CLIM-CLX::CLX-FRAME-MANAGER {4841F275}> #<TEST1 {48417C0D}>)
Source:
; File: /home/tl/Projects/sandbox/clim-test.lisp
(DEFINE-APPLICATION-FRAME TEST1
NIL
((STATE :INITFORM '# :ACCESSOR STATE)
(COUNTER :INITFORM 0 :ACCESSOR COUNTER))
(:PANES (IN :INTERACTOR)))
0] (lisp-implementation-version)
"18e"
What's wrong with my test ?
Any help will be much appreciated.
Thibault Langlois
·················@di.fc.ul.pt (Thibault Langlois) writes:
> Hello,
>
> I am learning CLIM, using LW's CLIM and McCLIM. Assuming this is the
> right place discuss this issue, here are a few questions:
>
> 1) Is there a mailing list dedicated to McCLIM ? I tried to send a
> mail to free-clim-request at mikemac.com and free-clim at mikemac.com
> without success.
free-clim is the right mailing list; there isn't a "free-clim-request
at mikemac.com" AFAIK; you could try sending mail to mikemac himself.
>
> 2) When I run a demo that comes with McCLIM (snapshot 12/06/03) with
> CMUCL 18e, the lisp process use 100% of the CPU even if the
> application does nothing. Is there something specific to CMUCL that
> must be done to avoid this ?
Not really. This is an unfortunate artifact of CMUCL threads and
McCLIM's queue mechanism. Note that the application is still quite
responsive despite eating up all the CPU :)
> 3) My first CLIM test is very minimalist:
>
> (define-application-frame test1 ()
> ((state :initform '(a b c) :accessor state)
> (counter :initform 0 :accessor counter))
> (:panes
> (in :interactor)))
>
> When I run it with CMUCL/McCLIM I get the folowing error:
> (It works as expected with LW/CLIM)
>
> * (run-frame-top-level (make-application-frame 'test1))
> NIL fell through ECASE expression. Wanted one of ().
>
...
>
> What's wrong with my test ?
>
> Any help will be much appreciated.
I believe the problem is that you haven't defined any layouts. We
(McCLIM) aren't defaulting this correctly.
Tim
Timothy Moore <·····@bricoworks.com> wrote in message news:<············@216.39.145.192>...
> ·················@di.fc.ul.pt (Thibault Langlois) writes:
>
> > Hello,
> >
> > I am learning CLIM, using LW's CLIM and McCLIM. Assuming this is the
> > right place discuss this issue, here are a few questions:
> >
> > 1) Is there a mailing list dedicated to McCLIM ? I tried to send a
> > mail to free-clim-request at mikemac.com and free-clim at mikemac.com
> > without success.
>
> free-clim is the right mailing list; there isn't a "free-clim-request
> at mikemac.com" AFAIK; you could try sending mail to mikemac himself.
>
Thanks.
> >
> > 2) When I run a demo that comes with McCLIM (snapshot 12/06/03) with
> > CMUCL 18e, the lisp process use 100% of the CPU even if the
> > application does nothing. Is there something specific to CMUCL that
> > must be done to avoid this ?
>
> Not really. This is an unfortunate artifact of CMUCL threads and
> McCLIM's queue mechanism. Note that the application is still quite
> responsive despite eating up all the CPU :)
>
That's right but other application are competing with cmucl... Is
there another CL implementation that do not have this problem ?
You say that the problem is due to McCLIM queue mechanism and to the
way CMUCL threads are implemented, does it mean that it cannot be
fixed ?
Is there a prefered CL implementation to run McCLIM ?
> > 3) My first CLIM test is very minimalist:
> >
> > (define-application-frame test1 ()
> > ((state :initform '(a b c) :accessor state)
> > (counter :initform 0 :accessor counter))
> > (:panes
> > (in :interactor)))
> >
> > When I run it with CMUCL/McCLIM I get the folowing error:
> > (It works as expected with LW/CLIM)
> >
> > * (run-frame-top-level (make-application-frame 'test1))
> > NIL fell through ECASE expression. Wanted one of ().
> >
> ...
> >
> > What's wrong with my test ?
> >
> > Any help will be much appreciated.
>
> I believe the problem is that you haven't defined any layouts. We
> (McCLIM) aren't defaulting this correctly.
>
That's right. Adding :layouts make it work:
(define-application-frame test1 ()
((state :initform '(a b c) :accessor state)
(counter :initform 0 :accessor counter))
(:panes
(in :interactor))
(:layouts
(default
(vertically ()
in))))
Thibault
On 2003-06-24, Thibault Langlois <·················@di.fc.ul.pt> wrote:
>> Not really. This is an unfortunate artifact of CMUCL threads and
>> McCLIM's queue mechanism. Note that the application is still quite
>> responsive despite eating up all the CPU :)
>>
>
> That's right but other application are competing with cmucl... Is
> there another CL implementation that do not have this problem ?
Probably any which uses operating-system level threads. Recent versions
of OpenMCL and SBCL, probably. I don't know about the commercial ones
because I haven't tried McCLIM with them yet.
> You say that the problem is due to McCLIM queue mechanism and to the
> way CMUCL threads are implemented, does it mean that it cannot be
> fixed ?
It can be worked around. Try evaluating
(mp::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS)
before run-frame-top-level.
> Is there a prefered CL implementation to run McCLIM ?
Right now I guess that would be cmucl. As soon as the deadlocking
problems in sbcl/mt (or are they in clx?) are fixed, it might as well be
SBCL. I also heard that Tim Moore does his McCLIM hacking in OpenMCL.
--
Andreas Fuchs, <···@void.at>, ···@jabber.at, antifuchs
Andreas Fuchs <···@void.at> wrote in message news:<··············@ID-47635.news.dfncis.de>...
> On 2003-06-24, Thibault Langlois <·················@di.fc.ul.pt> wrote:
> >> Not really. This is an unfortunate artifact of CMUCL threads and
> >> McCLIM's queue mechanism. Note that the application is still quite
> >> responsive despite eating up all the CPU :)
> >>
> >
> > That's right but other application are competing with cmucl... Is
> > there another CL implementation that do not have this problem ?
>
> Probably any which uses operating-system level threads. Recent versions
> of OpenMCL and SBCL, probably. I don't know about the commercial ones
> because I haven't tried McCLIM with them yet.
>
> > You say that the problem is due to McCLIM queue mechanism and to the
> > way CMUCL threads are implemented, does it mean that it cannot be
> > fixed ?
>
> It can be worked around. Try evaluating
>
> (mp::STARTUP-IDLE-AND-TOP-LEVEL-LOOPS)
>
> before run-frame-top-level.
It works ! Thanks.
>
> > Is there a prefered CL implementation to run McCLIM ?
>
> Right now I guess that would be cmucl. As soon as the deadlocking
> problems in sbcl/mt (or are they in clx?) are fixed, it might as well be
> SBCL. I also heard that Tim Moore does his McCLIM hacking in OpenMCL.
OK. I'll stay with CMUCL
Thibault