[mcclim-devel] cpu constantly at 99% with just a simple GUI open
Hi, I build a very small GUI based on the calculator example. But when starting the GUI the CPU is constantly at 99%. Is this normal? Is there some configuration option to get a different behaviour? Does McCLIM use some kind of polling internally? And is there some hope that this might change in the future? Some day I would like to experiment with some realtime application and a busy CPU probably wouldn't be something good :) Thank you, Dietrich By the way: Rick Taube, the author of "lambda-gtk" and "common music" recently seemed to have switched from lambda-gtk to a C++ based gui (using "juce") which seems to communicate with his lisp code via a socket. I suppose that his main reason was the audio functionality which is part of "juce" and the possibility to easily use the same code for Windows, Mac and Linux. But another reason might have been a better realtime behaviour compared to the lambda-gtk gui. Would this be a better way to go?
Dietrich Bollmann <diresu@web.de> writes:
Hi,
I build a very small GUI based on the calculator example. But when starting the GUI the CPU is constantly at 99%.
Is this normal?
No, it is not.
Is there some configuration option to get a different behaviour? Does McCLIM use some kind of polling internally? And is there some hope that this might change in the future?
Are you using a single-threaded Lisp? I recall from ages past that this behaviour may occur under such circumstances, but I haven't used such a Lisp in a long time myself.
Some day I would like to experiment with some realtime application and a busy CPU probably wouldn't be something good :)
It also contributes to global warming! McCLIM kills polar bears!
By the way: Rick Taube, the author of "lambda-gtk" and "common music" recently seemed to have switched from lambda-gtk to a C++ based gui (using "juce") which seems to communicate with his lisp code via a socket. I suppose that his main reason was the audio functionality which is part of "juce" and the possibility to easily use the same code for Windows, Mac and Linux. But another reason might have been a better realtime behaviour compared to the lambda-gtk gui. Would this be a better way to go?
If you need behaviour like this, then yes, it's a good way to go. For McCLIM, I'm not interested in having too much non-Lisp code around, but a backend can talk to whatever it want. In fact, the CLX backend talks to a C program (the X-server) anyway. I like keeping as much in Lisp as possible (and I consider the fact that the X-server is not written in Lisp to be a more or less temporary problem, and at least one that can be solved independently of McCLIM itself). -- \ Troels /\ Henriksen
I'm only aware of this occuring if you use CMUCL, in which case you need to execute (mp::startup-idle-and-top-level-loops) before running your CLIM program due to an implementation quirk. This still isn't ideal, as (at least in my experience with various several year old versions of CMUCL) it introduces a noticable latency in event handling (such as menus becoming sluggish). My advice in this case is to use SBCL instead. If in fact you are not using SBCL then this is a bug that ought to be investigated.
Hi Troels and Andy :) Thank you for answering so fast! On Mon, 2008-02-18 at 17:01 +0100, Troels Henriksen wrote:
I build a very small GUI based on the calculator example. But when starting the GUI the CPU is constantly at 99%.
Is this normal?
No, it is not.
I am relieved :)
Are you using a single-threaded Lisp? I recall from ages past that this behaviour may occur under such circumstances, but I haven't used such a Lisp in a long time myself.
I am using cmucl and clim on Debian sid - both installed from the Debian packages. It seems that cmucl does not have native threads on Linux: - from http://www.cons.org/cmucl/FAQ.html Compared with SBCL (a fork from the CMUCL implementation), CMUCL a different set of features (it includes a Motif interface, but does not have SBCL's native threads on Linux/x86 platforms, nor Unicode support). CMUCL has a faster compiler, but compiled code runs at a similar speed to SBCL-generated code. SBCL is closer to the ANSI CL specification in some respects, and generally emits more warnings about ANSI-compliance. SBCL runs on a larger number of platforms than CMUCL, and in general is more actively developed than CMUCL. - from http://sbcl.sourceforge.net/history.html CMUCL and SBCL each have their own unique set of features: for instance, SBCL features native machine threads on Linux/x86 (CMU has userspace threads), and CMUCL has the generational garbage collector on SPARC/Solaris. But in general the user-visible difference isn't huge, since most visible bug fixes and improvements are actively ported between the two systems. Could this be related? On Mon, 2008-02-18 at 11:24 -0500, Andy Hefner wrote:
I'm only aware of this occuring if you use CMUCL, in which case you need to execute (mp::startup-idle-and-top-level-loops) before running your CLIM program due to an implementation quirk. This still isn't ideal, as (at least in my experience with various several year old versions of CMUCL) it introduces a noticable latency in event handling (such as menus becoming sluggish). My advice in this case is to use SBCL instead.
I executed (mp::startup-idle-and-top-level-loops) before running the CLIM program - without any positive result: the CPU is still at 98% when I start the clim examples. I after installed SBCL, also using the Debian package. But when trying to load/compile the clim demo I got tons of errors. Here what I did: (from /usr/share/doc/cl-mcclim-examples/README.Debian ) (asdf:oos 'asdf:load-op :clim-examples) (clim-demo::demodemo) ...and here some of the errors: The value :LOCKED is not of type (OR NULL SB-THREAD:THREAD). The function CLIM-SYS:MAKE-LOCK is undefined. There is no class named CLIM:WINDOW-REPAINT-EVENT. There is no class named CLIM:KEY-PRESS-EVENT. There is no class named CLIM:POINTER-BUTTON-PRESS-EVENT. ...and so on and so on... Probably the sbcl and the clim packages do not match? Should I install sbcl and clim from the sources? Do you have some other idea how to proceed? Which lisp do clim developers use? Should I switch to sbcl or some other lisp when using clim? Thanks for your help, Dietrich
Here are the cmucl / sbcl / mcclim versions I used: $ cmucl ... CMU Common Lisp CVS 19d 19d-release (19D), ... ... $ sbcl --version SBCL 1.0.14.debian $ g :version /usr/share/common-lisp/source/mcclim/mcclim.asd /usr/share/common-lisp/source/mcclim/mcclim.asd: :version "0.9.5" So all of them seem to be the most recent version. Dietrich
Hi, Quoting Dietrich Bollmann (diresu@web.de):
Here are the cmucl / sbcl / mcclim versions I used:
$ cmucl ... CMU Common Lisp CVS 19d 19d-release (19D), ... ...
$ sbcl --version SBCL 1.0.14.debian
$ g :version /usr/share/common-lisp/source/mcclim/mcclim.asd /usr/share/common-lisp/source/mcclim/mcclim.asd: :version "0.9.5"
So all of them seem to be the most recent version.
my impression is that few McCLIM developers are familiar with the packages included in Debian. Have you considered building your own SBCL and McCLIM, using the CVS version of McCLIM? d.
Hi David and Troels :) To David: So you are "neither antifuchs nor athas, no." - ok, but you are the person I was thinking about when asking my strange question. And by the way, I found your name today once again when reading about mcclim's gtk bindings :) - sorry for not remembering names better. (And sorry to other readers for this probably unnecessary and mysterious part of my message.) Concerning my newest mcclim adventures (and David's question from yesterday): I finally installed mcclim today following the indications on page http://mcclim.cliki.net/GettingStarted . Only one thing I had to do differently: I downloaded clx from http://common-lisp.net/~crhodes/clx and not, as written in the GettingStarted-guide, from http://verisons.telent.net/clx as the latter didn't work. When trying to test the system from the clim example programs the "DemoDemo" window popped up and I could start one of the demos. Thereafter things stopped to work and the windows to repaint. An exception, appended to this message, was signalled. In the exception message I could read: ...(possible package problem)... Ok, but how to find the one combination of packages which works? Should I rather follow some other installation instructions, use some other tool (clbuild ?), ...? Greetings from my little room where I am happy to sit at my computer hiding from an unfriendly stormy, cold and rainy night outside. Dietrich ============================================================ The error message I got ------------------------------------------------------------ The function DREI-BUFFER::DELETE-ELEMENTS* is undefined. [Condition of type UNDEFINED-FUNCTION] Restarts: 0: [ABORT] Return to application command loop 1: [ABORT] Return to SLIME's top level. 2: [ABORT] Exit debugger, returning to top level. Backtrace: 0: ("bogus stack frame") 1: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) #<unavailable argument> #<unavailable argument> #<DREI::EXTENDED-STANDARD-BUFFER size:0 {D9D03F1}> 0 0) 2: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) #<unavailable argument> #<unavailable argument> #<DREI:DREI-BUFFER size:0 {D7A2E89}> 0 0) 3: ((LAMBDA NIL)) 4: ((SB-PCL::FAST-METHOD DREI:INVOKE-PERFORMING-DREI-OPERATIONS (DREI:DREI FUNCTION)) #<unavailable argument> #<unavailable argument> #<CLIM-INTERNALS::DREI-TEXT-FIELD-SUBSTRATE TEXTUAL-DREI-SYNTAX-VIEW {B4FD5E9}> #<CLOSURE (LAMBDA NIL) {B0227CD}>)[:EXTERNAL] 5: ((SB-PCL::FAST-METHOD (SETF CLIM:GADGET-VALUE) (T DREI:DREI-GADGET-PANE)) #<unavailable argument> #<unavailable argument> "2" #<CLIM-INTERNALS::DREI-TEXT-FIELD-SUBSTRATE TEXTUAL-DREI-SYNTAX-VIEW {B4FD5E9}>)[:EXTERNAL] 6: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE-COUNT.)) #<unused argument> #<unused argument> "2" #<CLIM-INTERNALS::DREI-TEXT-FIELD-SUBSTRATE TEXTUAL-DREI-SYNTAX-VIEW {B4FD5E9}> -303822752 0) 7: (CLIM-INTERNALS::INVOKE-CALLBACK #<CLIM:PUSH-BUTTON-PANE CLIM-DEMO::TWO {B4D4521}> #<CLOSURE (LAMBDA (CLIM:GADGET)) {B4D1525}>)[:EXTERNAL] 8: ((SB-PCL::FAST-METHOD CLIM:HANDLE-EVENT (CLIM:PUSH-BUTTON-PANE CLIM:POINTER-BUTTON-RELEASE-EVENT)) #(26 NIL 49 NIL) #<unavailable argument> #<CLIM:PUSH-BUTTON-PANE CLIM-DEMO::TWO {B4D4521}> #<unavailable argument>) 9: (CLIM-EXTENSIONS:SIMPLE-EVENT-LOOP #<CLIM-DEMO::CALCULATOR {B442D71}>) 10: (CLIM-EXTENSIONS:SIMPLE-EVENT-LOOP)[:EXTERNAL] 11: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL (CLIM:APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<CLIM-DEMO::CALCULATOR {B442D71}>)[:EXTERNAL] 12: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-C::&OPTIONAL-DISPATCH #) {C6BF405}> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<CLIM-DEMO::CALCULATOR {B442D71}>)[:EXTERNAL] 13: ((LAMBDA (&REST IGNORE))) 14: (CLIM-INTERNALS::INVOKE-CALLBACK #<CLIM:PUSH-BUTTON-PANE "(Unnamed Pane)" {D7D5759}> #<CLOSURE (SB-C::&OPTIONAL-DISPATCH (LAMBDA #)) {D837A5D}>)[:EXTERNAL] 15: ((SB-PCL::FAST-METHOD CLIM:HANDLE-EVENT (CLIM:PUSH-BUTTON-PANE CLIM:POINTER-BUTTON-RELEASE-EVENT)) #(26 NIL 49 NIL) #<unavailable argument> #<CLIM:PUSH-BUTTON-PANE "(Unnamed Pane)" {D7D5759}> #<unavailable argument>) 16: (CLIM-EXTENSIONS:SIMPLE-EVENT-LOOP #<CLIM-DEMO::DEMODEMO {AD848C1}>) 17: (CLIM-EXTENSIONS:SIMPLE-EVENT-LOOP #<CLIM-DEMO::DEMODEMO {AD848C1}>)[:EXTERNAL] 18: ((SB-PCL::FAST-METHOD CLIM:READ-FRAME-COMMAND :AROUND (CLIM:APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-C::&OPTIONAL-DISPATCH #) {C6BBE9D}> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<CLIM-DEMO::DEMODEMO {AD848C1}>)[:EXTERNAL] 19: ((SB-PCL::FAST-METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL (CLIM:APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<CLIM-DEMO::DEMODEMO {AD848C1}>)[:EXTERNAL] 20: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL (CLIM:APPLICATION-FRAME)) #<unavailable argument> #<unavailable argument> #<CLIM-DEMO::DEMODEMO {AD848C1}>)[:EXTERNAL] 21: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-C::&OPTIONAL-DISPATCH #) {C6BF405}> :PV NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<CLIM-DEMO::DEMODEMO {AD848C1}>)[:EXTERNAL] 22: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CLIM-DEMO::RUN-TEST (QUOTE CLIM-DEMO::DEMODEMO)) #<NULL-LEXENV>) 23: ((LAMBDA NIL)) 24: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA NIL) {AD82605}>) 25: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA NIL) {AD82605}>) 26: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:INTERACTIVE-EVAL "(clim-demo::run-test 'clim-demo::demodemo)") #<NULL-LEXENV>) 27: ((LAMBDA NIL)) 28: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {AD7F2F5}>) 29: ((LAMBDA NIL)) 30: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<FUNCTION (LAMBDA NIL) {AA7AC5D}>) 31: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {AFCDBD1}> #<CLOSURE (LAMBDA NIL) {AD7E0C5}>) 32: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {AFCDBD1}> #<FUNCTION (LAMBDA NIL) {AA7AC5D}>) 33: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {AFCDBD1}>) 34: (SWANK::PROCESS-AVAILABLE-INPUT #<SB-SYS:FD-STREAM for "a socket" {AFCCF19}> #<CLOSURE (LAMBDA NIL) {AD7E0B5}>) 35: ((FLET SWANK::HANDLER)) 36: ((LAMBDA (SWANK-BACKEND::_)) #<unused argument>) 37: (SB-IMPL::SUB-SERVE-EVENT #<unavailable argument> #<unavailable argument> NIL) 38: (SB-SYS:WAIT-UNTIL-FD-USABLE 0 :INPUT NIL) 39: (SB-IMPL::REFILL-INPUT-BUFFER #<SB-SYS:FD-STREAM for "standard input" {A7BCC21}>) 40: (SB-IMPL::INPUT-CHAR/UTF-8 #<SB-SYS:FD-STREAM for "standard input" {A7BCC21}> NIL #:EOF-OBJECT) 41: (READ-CHAR #<SB-SYS:FD-STREAM for "standard input" {A7BCC21}> NIL #:EOF-OBJECT #<unused argument>) 42: (READ-CHAR #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {90C9E31}> NIL #:EOF-OBJECT #<unused argument>) 43: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {90C9E31}> NIL (NIL) T) 44: (READ-PRESERVING-WHITESPACE #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {90C9E31}> NIL (NIL) NIL) 45: (READ #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {90C9E31}> NIL (NIL) NIL) 46: (SB-IMPL::REPL-READ-FORM-FUN #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDIN* {90C9E31}> #<unavailable argument>) 47: (SB-IMPL::REPL-FUN NIL) 48: (SB-IMPL::REPL-FUN NIL)[:EXTERNAL] 49: ((LAMBDA NIL)) 50: ((LAMBDA NIL))[:EXTERNAL] 51: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (LAMBDA NIL) {A816035}>) 52: (SB-IMPL::TOPLEVEL-REPL NIL) 53: (SB-IMPL::TOPLEVEL-INIT) 54: ((LABELS SB-IMPL::RESTART-LISP)) ============================================================ ...and the end of my emacs slime repl buffer output (puh!)... ------------------------------------------------------------ ...snip... STYLE-WARNING: slot names with the same SYMBOL-NAME but different SYMBOL-PACKAGE (possible package problem) for class #<STANDARD-CLASS LOGIC-CUBE-PANE>: (CLIM-INTERNALS::BACKGROUND BACKGROUND) STYLE-WARNING: slot names with the same SYMBOL-NAME but different SYMBOL-PACKAGE (possible package problem) for class #<STANDARD-CLASS CALCULATOR>: (CLIM-INTERNALS::STATE STATE) STYLE-WARNING: Implicitly creating new generic function DISPLAY-FONT-PREVIEW. ;;;; (clim-demo::run-test 'clim-demo::demodemo) ... STYLE-WARNING: slot names with the same SYMBOL-NAME but different SYMBOL-PACKAGE (possible package problem) for class #<STANDARD-CLASS CLIM-DEMO::LOGIC-CUBE-PANE>: (CLIM-INTERNALS::BACKGROUND CLIM-DEMO::BACKGROUND) STYLE-WARNING: slot names with the same SYMBOL-NAME but different SYMBOL-PACKAGE (possible package problem) for class #<STANDARD-CLASS CLIM-DEMO::LOGIC-CUBE-PANE>: (CLIM-INTERNALS::BACKGROUND CLIM-DEMO::BACKGROUND) CL-USER> ============================================================ On Tue, 2008-02-19 at 19:15 +0100, David Lichteblau wrote:
Hi,
Quoting Dietrich Bollmann (diresu@web.de):
Here are the cmucl / sbcl / mcclim versions I used:
$ cmucl ... CMU Common Lisp CVS 19d 19d-release (19D), ... ...
$ sbcl --version SBCL 1.0.14.debian
$ g :version /usr/share/common-lisp/source/mcclim/mcclim.asd /usr/share/common-lisp/source/mcclim/mcclim.asd: :version "0.9.5"
So all of them seem to be the most recent version.
my impression is that few McCLIM developers are familiar with the packages included in Debian.
Have you considered building your own SBCL and McCLIM, using the CVS version of McCLIM?
d.
On Tue, 2008-02-19 at 20:36 +0100, Troels Henriksen wrote:
Dietrich Bollmann <diresu@web.de> writes:
So all of them seem to be the most recent version.
McCLIM 0.9.5 has (several) problems with various different versions of SBCL - in fact, unless you use the current SBCL from just around the time McCLIM 0.9.5 was released, you'll likely have trouble.
It is *really* recommended to get CVS McCLIM. It should even work with many versions of SBCL (though the lock-thing mentioned in your post may require a semirecent SBCL, I don't recall the details of that particular problem).
Quoting Dietrich Bollmann (diresu@web.de):
When trying to test the system from the clim example programs the "DemoDemo" window popped up and I could start one of the demos. Thereafter things stopped to work and the windows to repaint.
This is unrelated to the error you mentioned, but does your SBCL have sb-thread support enabled? I seem to recall that demodemo might hang when used without threads.
An exception, appended to this message, was signalled.
In the exception message I could read: ...(possible package problem)...
Ok, but how to find the one combination of packages which works?
Which one of the demos is that? I just tried some of them, and indeed Troels' recent climacs changes must have caused some trouble. I noticed that the tab layout demo signals a flexichain error. But I didn't see the error you got. Some of the demos worked fine for me, including clim-fig, the calculator, the address book, the logic cube, ...
Should I rather follow some other installation instructions, use some other tool (clbuild ?), ...?
That is also an option. I recently updated http://mcclim.cliki.net/Getting%20started%20using%20clbuild for current clbuild. d.
Hi David, On Sat, 2008-02-23 at 12:40 +0100, David Lichteblau wrote:
Quoting Dietrich Bollmann (diresu@web.de):
When trying to test the system from the clim example programs the "DemoDemo" window popped up and I could start one of the demos. Thereafter things stopped to work and the windows to repaint.
This is unrelated to the error you mentioned, but does your SBCL have sb-thread support enabled? I seem to recall that demodemo might hang when used without threads.
Probably I did not: no `sb-thread' found when evaluating `*features*'... Thanks. I will rebuild sbcl with sb-thread enabled next week and try again. By the way: When searching for documentation about how to install mcclim I haven't seen any hint indicating the need to do so. The same lack of information when searching for instructions about how to enable `sb-thread'. I finally found them hidden in the sbcl INSTALL file when grepping for `sb-thread' though. Both is probably my fault as others do not seem to have the same problems. But some more information might make things easier for people like me :) (I don't mean to complain - this is just meant as an idea about how to make the world a better place :)
An exception, appended to this message, was signalled.
In the exception message I could read: ...(possible package problem)...
Ok, but how to find the one combination of packages which works?
Which one of the demos is that?
I just tried some of them, and indeed Troels' recent climacs changes must have caused some trouble. I noticed that the tab layout demo signals a flexichain error. But I didn't see the error you got.
Some of the demos worked fine for me, including clim-fig, the calculator, the address book, the logic cube, ...
As far as I remember it was the calculator. I also tried the drawing tool (first example button) and I think a similar exception message was shown.
Should I rather follow some other installation instructions, use some other tool (clbuild ?), ...?
That is also an option. I recently updated http://mcclim.cliki.net/Getting%20started%20using%20clbuild for current clbuild.
Thanks, but if all of you use the cvs directly I probably better do the same? It would be nice if the sbcl and clim packages for Debian etc. would be updated on a regular basis also. This would make things much easier for the rest of the world - which would be the best publicity for lisp. Thanks for your help - I probably would have spend a week to find a way out of my problems without your help :) Dietrich
d.
Dietrich Bollmann <diresu@web.de> writes:
As far as I remember it was the calculator.
I also tried the drawing tool (first example button) and I think a similar exception message was shown.
Everything that uses the text-editing substrate will fail. The calculator uses it for the display (which is OK), and the drawing tool, provided you mean CLIM-FIG, uses it as a status-bar, which is really not how it's supposed to be used, but whatever. To fix it, you must install the CVS version Flexichain library. This is a temporary problem until the next release of Flexichain (after which the asdf-installable version will work just fine). -- \ Troels /\ Henriksen
Hi Troels and David, Originally I wanted to answer to your emails when everything works ... but as there are new problems which make it impossible to use sbcl on my computer I will switch back to cmucl for a while and postpone the development of the gui until sbcl works again. As this might take some time I thought I rather answer to your last emails now. Following your suggestions I installed sbcl, the lisp userland and mcclim with clbuild - and beside some minor problems (inbetween them the crashing of more or less half of the mcclim demodemo examples) things seemed to work somehow. As I only need very simple gui functionality, I decided to give it a try and ported my code from cmucl to sbcl as you told me that this is the lisp implementation which currently works best with mcclim. Unfortunately since yesterday there is a new problem with an updated version of libc6 on debian which renders sbcl unusable on my computer (See the thread "[Sbcl-devel] SBCL hanging seemingly randomly", http://sourceforge.net/mailarchive/forum.php?thread_name=1204420182.4466.42.camel%40hake&forum_name=sbcl-devel ) and I will switch back to cmucl and postpone the development of the gui until things work again. Thanks a lot for your help and the efforts you put into mcclim! Probably until some time later, Dietrich On Sun, 2008-02-24 at 01:51 +0100, Troels Henriksen wrote:
Dietrich Bollmann <diresu@web.de> writes:
As far as I remember it was the calculator.
I also tried the drawing tool (first example button) and I think a similar exception message was shown.
Everything that uses the text-editing substrate will fail. The calculator uses it for the display (which is OK), and the drawing tool, provided you mean CLIM-FIG, uses it as a status-bar, which is really not how it's supposed to be used, but whatever.
To fix it, you must install the CVS version Flexichain library. This is a temporary problem until the next release of Flexichain (after which the asdf-installable version will work just fine).
Dietrich Bollmann <diresu@web.de> writes:
So all of them seem to be the most recent version.
McCLIM 0.9.5 has (several) problems with various different versions of SBCL - in fact, unless you use the current SBCL from just around the time McCLIM 0.9.5 was released, you'll likely have trouble. It is *really* recommended to get CVS McCLIM. It should even work with many versions of SBCL (though the lock-thing mentioned in your post may require a semirecent SBCL, I don't recall the details of that particular problem). -- \ Troels /\ Henriksen
participants (4)
-
Andy Hefner -
David Lichteblau -
Dietrich Bollmann -
Troels Henriksen