stumpwm-devel
[Top][All Lists]
Advanced

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

Re: [STUMP] Too slow popups with Eclipse


From: Luca Capello
Subject: Re: [STUMP] Too slow popups with Eclipse
Date: Fri, 12 Oct 2007 14:58:20 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux)

Hello!

On Fri, 12 Oct 2007 01:19:10 +0200, 
> On Thu, Oct 11, 2007, Daniel Clemente wrote:
[a lot of not-necessary quote]
> Sounds like you just volunteered. I find that the best people to
> improve the quality of installation are people who actually install.

This depends on which *nix distribution you install StumpWM.  I'd bet
that I, as the Debian StumpWM maintainer, know better how to install
StumpWM on Debian, but not on Gentoo/Fedora/other-unixes.

> At some point we will have a Debian package with a functioning
> executable (preferably clisp) and no one will complain about these
> issues

With my Debian StumpWM maintainer hat on, this won't be the case.  I
don't want to provide N packages for every CL implementation StumpWM
works on and I don't think that, once StumpWM has been ASDF compiled
the first time, a start-up time of 5s is a problem.

> or even realize that StumpWM is written in Common Lisp. I think Lisp
> software in general suffers from user-unfriendliness.

And this is why solutions like cl-launch [2] exists.

> If you'd like to provide a pre-compiled CVS clisp package for people
> to use, that would be a great help--but it won't help everybody.

Please don't, for the reasons explained above.  If there're problems
in how StumpWM (and CL in general) is managed in Debian, please file
them to the Debian BTS [3] and the Debian CL group [4] will try to
solve them.

> Detailed instructions regarding SBCL and clisp, while useful, are
> really outside the scope of StumpWM's documentation. It would be
> better to eliminate such digressions and instead point to some
> external resource.

Since StumpWM is *supposed* to work with any CL implementation [5]
(read the "a common lisp distribution."...), how to solve problems
StumpWM has with particular CL implementations should be documented in
StumpWM, not elsewhere.

> Everyone agrees that StumpWM could be easier to get running,

I don't see how the following is considered difficult, which doesn't
even require StumpWM to be compiled (assuming that the CL
implementation and the dependencies don't have any bug):

 $ [install StumpWM dependencies]
 $ /your/cl/implementation
 * (asdf:oos 'asdf:load-op 'stumpwm)
 * (stumpwm:stumpwm)

Thx, bye,
Gismo / Luca

Footnotes: 
[1] 5s is the time that passes from when I launch /usr/bin/stumpwm [6]
    to the appearence of the StumpWM greeting message in a Xnest
    session on my ThinkPad X60 [7] underclocked at 1GHz
[2] http://www.cliki.net/cl-launch
[3] http://bugs.debian.org
[4] http://cl-debian.alioth.debian.org
[5] 
http://git.savannah.nongnu.org/gitweb/?p=stumpwm.git;a=blob;f=README;h=90cfa2a218cb2690726a597179e43d1950d6a7ec;hb=HEAD
[6] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=49;bug=356948
[7] http://luca.pca.it/projects/ibm/x60_1706-gmg/




reply via email to

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