stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[STUMP] Re: Lisp crashes with stumpwm


From: Milan Zamazal
Subject: [STUMP] Re: Lisp crashes with stumpwm
Date: Wed, 16 Jan 2008 19:11:25 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)

>>>>> "BF" == Bob Farrell <address@hidden> writes:

    BF> For what it's worth, I ran StumpWM with the debian sid SBCL
    BF> package (i.e. threaded) for months without any problems. 

Finally some encouraging information! :-)

Yesterday I tried to run StumpWM SBCL compiled without sb-thread and
sb-futex (just to be sure) and it was more stable than the multithreaded
version.  But my keyboard (and the whole window manager I guess) has
frozen two times during the evening, I had to kill the SBCL process from
another terminal to remedy the situation.  SBCL reported absolutely
nothing about the problem.  So that didn't work for me either.

Today I tried to run StumpWM with standard Debian multithreaded SBCL,
but without the mode line and with swank connection disabled.  And it
has been running for the whole day without any problem!  If it survives
till morning, I'll try to enable swank tomorrow and will see.  So far it
seems timers and only timers are source of the problem.

    BF> I run Clisp now (it takes a little bit of twiddling to get it
    BF> working, so if you can't figure it out, you should probably come
    BF> and harass someone on IRC) 

I think it runs with the latest Debian CLISP without any special setup
steps needed.  But it suffers from some significant CPU cycles
consumption as I described in previous posts.  I may try to run it
without mode line too, perhaps it helps.
    
    BF> A lot of people seem to have trouble with SBCL threads so it'd
    BF> perhaps be useful to try and find out if there's any singular
    BF> difference between the setups of those who have problems and
    BF> those who don't.

Do you use StumpWM mode line?

    BF> Unfortunately that's more the responsibility of the SBCL
    BF> devs/users than it is of StumpWM's. 

Yes, but we should try to isolate the problem first.

    BF> Besides, you're the first person I've heard complaining about
    BF> the idea of building a custom, non-threaded SBCL. ;-)

Well, I always laughed at C++ programs requiring certain g++ versions to
get compiled.  And now I can see there is a CL program that requires
custom compiler + runtime to get run!  Somewhat embarrassing... (and
impractical too). ;-)

Regards,

Milan Zamazal





reply via email to

[Prev in Thread] Current Thread [Next in Thread]