I often use stump + emacsclient + slime. What happens is that I connect to stump via slime/swank, and whenever the hang occurs I switch to a virtual terminal, attach to the running emacs server (so make sure that was running before hand) and then switch the sldb buffer.
On 11/12/2014 06:12 PM, David Bjergaard wrote: > Hi Jim, > > I have to admit, I've never considered the magnitude of the number of > windows your trying to manage when writing code for StumpWM. That being > said I haven't written much of it, so hopefully we can sort things out. > > There are two options: > 1. Start with the git head and roll back commits until you see the older > behavior. (This could be potentially painful depending on how far > back you have to go and how hard it is to get your 120 windows back > open) > 2. Take the 0.9.9 version and replace files that changed a lot with the > 0.9.8 version until the problem goes away. Many of the changes that > were made were incremental and single files specific, but you could > end up with an unbuildable system by just substituting files. Off the > top of my head color.lisp and module.lisp changed the most, there > were also a bunch of bug fixes to fix unhandled crashes but these > were minor and shouldn't have caused a change in how stumpwm listens > for events. > 3. (speculating) Find a way to interrupt the stumpwm process when the > hang occurs and get a stack trace that we can debug with. I'm not > sure how to do this exactly, maybe someone else can comment. > > Of course there are the "standard" debugging steps: > 1. Make sure this problem is still present with an clean .xinitrc (just > "exec /path/to/stumpwm") > 2. Use an empty .stumpwmrc (just to make sure its not code you wrote) > 3. Set the debug level high and redirect it to a file > 4. Provide us with your linux version/distro, the lisp flavor and > version (sbcl, ecl, clisp) > 5. Finally, since the module system is so new, let us know what modules > you are using. There is a known problem with the truetype font > module that makes stumpwm very sluggish even on moderately old > systems. > > Finally: four monitors, 60 windows?! I can't decide if I'm supremely > jealous or very frightened. > > Good Luck! > > Dave > > > Jim Greenleaf <jgreenl...@belvederetrading.com> writes: > >> In my excitement about the module architecture, I updated from stumpwm >> 0.9.8 to the tagged 0.9.9, and have encountered a performance >> regression: >> >> Frequently, my UI hangs, including mouse movement and text entry into >> emacs (the keyboard events don't get queued up, they are simply lost), >> and if I have a process monitor open before this occurs, I can briefly >> see my Xorg.bin server pinning a CPU in kernel-space, after I start >> getting UI output again. >> >> In terms of things I am doing atypically, I do have 61 windows open (I >> had around 120 back in version 0.9.8 with no issues) with 8 actively >> displayed at any given time, across four screens. >> >> What steps do you lot suggest taking to more accurately isolate this >> regression? >> >> ________________________________ >> >> Confidentiality Notice >> The information transmitted in this electronic mail (e-mail) is the >> property of Belvedere Trading LLC. This e-mail is intended only for >> the person or entity to which it is addressed and may contain material >> that is confidential, privileged or otherwise protected by law. Any >> review, retention, retransmission, dissemination or other use of, or >> taking any action in reliance upon, this information by persons or >> entities other than the intended recipient is STRICTLY PROHIBITED. If >> you received this e-mail in error, please alert the sender by reply >> e-mail and then delete this e-mail and any attachments in their >> entirety, whether in electronic or hard copy format. >> >> All messages sent to and from this e-mail address may be monitored as >> permitted by applicable law and regulations to ensure compliance with >> our internal policies and to protect our business. Emails are not >> secure and cannot be guaranteed to be error free as they can be >> intercepted, amended, lost or destroyed, or contain viruses. You are >> deemed to have accepted these risks if you communicate with us by >> email. >> >> _______________________________________________ >> 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
