"J. David Smith" <emall...@archlinux.us> writes: > I've actually had issues in Arch where, after an SBCL upgrade, I was > forced to recompile before it'd load my stump config. Dunno if the > core problem was the upgrade or something else entirely, but > recompiling fixed it.
Yeah, I got so many "XXXX was compiled with a previous version of SBCL" errors that I got into the habit of recompiling every time. I don't think stump itself ever produced those errors, but cl-ppcre or other commonly-used packages. > On Tue, Feb 18, 2014 at 12:25 AM, Sam Kleinman <s...@tychoish.com> > wrote: > > > Just to clarify how compiling stump works (on arch): > > You can upgrade SBCL and unless you recompile/upgrade stump with > the new > version of SBCL you won't get the benefit of any changes to SBCL. > At the > same time, you don't *need* to recompile stump when you upgrade > SBCL: it > will continue to run without issue, but it's usually a good idea > to > recompile. > > Cheers, > sam > > > On Saturday, February 15 2014, 11:41:28, Eric Abrahamsen wrote: > > > David Bjergaard <dbjerga...@gmail.com> writes: > > > >> Hi Eric, > >> > >> It sounds like the problem is "fixing itself." If you suspect > that it > >> really is the version of sbcl, could you please post the > version you > >> were using? I'm running with 1.1.1.0.debian, and don't have > any > >> issues. I see that you are now running the bleeding edge of > sbcl. > >> > >> Another step would be rolling back to the version before you > started > >> noticing the lag, and seeing if that fixes the issue. If it > does we can > >> document this as a known issue on the wiki. > >> > >> Thanks for investigating/reporting this, I suspect as this > buggy sbcl > >> version propagates through various repos we may see more > reports similar > >> to yours. > > > > Yeah, I have no idea at this point. The arch sbcl package had > been at > > 1.1.14 previously. I downgraded back to 1.1.14, and then to > 1.1.12, and > > my highly-unscientific testing methods showed no particular > slowdown. I > > never succeeded compiling with clisp, despite following several > recipes > > mentioned on the wiki and other places. > > > > The problem is I saw the slowdown after a _stumpwm_ upgrade, > not an sbcl > > upgrade. Perhaps I didn't do a "make clean" when I rebuilt and > was > > somehow running uncompiled files, or else it was smurfs. Sorry > for the > > noise! > > > >> Cheers, > >> > >> Dave > >> > >> Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> > >>> Ruthard Baudach <ruthard.baud...@web.de> writes: > >>> > >>>>>== Auszüge aus der Nachricht von Eric Abrahamsen vom > 2014-02-10 08:09: > >>>>> This could totally be my imagination, but since there have > been so many > >>>>> updates recently, I thought I'd check in and see what other > people > >>>>> think... > >>>>> > >>>>> I'm running stump on archlinux, with no desktop manager. My > subjective > >>>>> feeling is that I'm getting a lot of tardy prefix keypress > detection > >>>>> from stumpwm: I hit "C-t c", which should run-or-raise my > terminal, and > >>>>> instead a "c" gets sent to the focused window, and then > stump picks up the > >>>>> "C-t" and waits for further input. This can be pretty > annoying, for > >>>>> instance when emacs/gnus is focused and the unintentional > "c" marks the > >>>>> group under point as completely read. > >>>>> > >>>>> Has this gotten worse recently, or am I dreaming? If I am > dreaming, is > >>>>> there any way to block key input so that, even if stump is > slow, it > >>>>> still consumes further keypresses? > >>>> > >>>> I do not have this issue, but had it using C-t as prefix key > -- it's too > >>>> uncomfortable for me to use it all the time. > >>>> > >>>> I'm using the Windows key as prefix key: > >>>> > >>>> .stumpwmrc: > >>>> ---------------------->%------------------- > >>>> (run-shell-command "xmodmap -e \"keycode 133 = F20\"") > >>>> (run-shell-command "xmodmap -e \"clear Mod4\"") > >>>> (set-prefix-key (kbd "F20")) > >>>> ---------------------->%------------------- > >>> > >>> Thanks! But the fact remains that you're still using an > escape key: > >>> a single keypress that has to be caught by Stumpwm before it > will read > >>> what follows. It doesn't seems like which particular escape > key you're > >>> using should matter. > >>> > >>> Arch just updated SBCL to 1.1.15, and the problem seems > significantly > >>> better, though I'll want to give it a few days to see. I > swear it wasn't > >>> my imagination! > >>> > >>> E > >>> > >>> > >>> _______________________________________________ > >>> Stumpwm-devel mailing list > >>> Stumpwm-devel@nongnu.org > >>> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel > >> > >> _______________________________________________ > >> Stumpwm-devel mailing list > >> Stumpwm-devel@nongnu.org > >> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel > > > > > > _______________________________________________ > > Stumpwm-devel mailing list > > Stumpwm-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel > > > -- > Sam Kleinman (tychoish): > - ga...@tychoish.com > - tychoish <http://tychoish.com/> > "don't get it right, get it written" -- james thurber > > _______________________________________________ > Stumpwm-devel mailing list > Stumpwm-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel > > > > > _______________________________________________ > Stumpwm-devel mailing list > Stumpwm-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
