freenode/#stumpwm - IRC Chatlog
Search
16:45:17
travis-ci
Change view : https://github.com/stumpwm/stumpwm/compare/0a104b41bbee...5588e0d4f9f1
17:29:03
defaultxr
getting a weird crash/error after updating stumpwm from f6966cabdf7cdc3cdecf88dfaaf8a90845264c5d to 0a104b41bbee5163f6c4deedcf06801b4ce09ad1 http://ix.io/1RUs . haven't tried the latest commit but seems to happen when i run (set-frame-font "FONT") in emacs, using a truetype font. also seems to be caused by something in my stumpwm.d/init.lisp but haven't narrowed it down yet... anyone else notice a similar
18:30:02
scottj
loke: 3270 is a nice font. there's a version named "IBM 3270" that won't be first :)
18:31:59
defaultxr
scottj: found a reproducer. only the following in init.lisp: (setf *normal-border-width* 0) . then C-t ! emacs -Q . crash.
18:37:47
scottj
defaultxr: you might want to log out the value of (list (xlib:drawable-height (window-parent win)) height wy) at the end of maximize-window
18:44:49
scottj
sorry if this is a wild goose chase, it normally is when I'm debugging my own issues :)
18:51:10
defaultxr
i had it write to a file, maybe maximize-window is being called multiple times and overwriting the value when it crashes
18:53:23
defaultxr
and yeah, it still just says (1080 1080 0) and nothing else even when i have :if-exists :append
19:00:39
defaultxr
hmm, but the error in my paste seems to show that it's happening inside the xlib:change-property, doesn't it?
19:00:43
defaultxr
if i move the (with-open-file ...) to before (xlib:change-property ...) i get the following in the output
19:13:02
defaultxr
well, it doesn't get to the root of the problem, but wrapping the (- (xlib:drawable...)) calls in (max 0 ...) does seem to prevent the crash
19:13:33
scottj
defaultxr: there are two lines added by that commit, the xlib:window-priority line and the group-raised-window line, you could try commenting them out one at a time and see which is the offending line. I'm guessing the window-priority one.
19:13:54
scottj
defaultxr: fwiw, I think you can remove both lines and stumpwm will work fine afaict
19:16:28
defaultxr
i also find that commit weird because i am using dunst and haven't had any problems with it being covered by other windows
19:18:28
defaultxr
well, just commenting out the (xlib:window-priority ...) part doesn't stop the error
19:23:01
defaultxr
argh, now it seems to be happening even if i checkout f6966ca... sorry, maybe it wasn't that commit... let me see if i can figure out when it actually started
19:29:29
defaultxr
this isn't making much sense. i reverted all the way back to b95e172 and it's still happening.
19:33:35
defaultxr
the font triggered it before but now i'm able to reproduce just by starting emacs -Q
19:35:58
defaultxr
so you didn't try with just the (setf *normal-border-width* 0) in your init.lisp/stumpwmrc?
22:07:19
PuercoPop
defaultxr: Do you know how to reproduce the problem with maximize-window? It happens to me on my laptop when opening Pharo Launcher, but not with any other app. I just wrap the width calculations with a (max .. 0) as you say when setting the :_NET_FRAME_EXTENTS prop. But it only happens in this machine with and with Pharo Launcher I haven't been able to pin down why
22:08:28
PuercoPop
Although I've experienced that issue for quite a while so I'm sure it is wasn't a recent change
22:10:18
defaultxr
hi PuercoPop! for me it seems to be happening with emacs 26.2 with `emacs -Q` and a stumpwmrc that only has `(setf *normal-border-width* 0)`. that is all i need to reproduce it... i'm not really sure what else is contributing to the problem sadly
22:11:10
defaultxr
i almost get the feeling that maybe it is caused by something else, like xorg, my drivers (amdgpu), or the kernel (just a hunch, probably not actually the case though)
22:11:50
defaultxr
and yeah, i thought it was due to a recent change in stumpwm but then i checkout'd some older versions and it seemed to happen with them too
22:13:05
defaultxr
i'm running linux 5.2.8, xorg-server-common 1.20.5, emacs 26.2, and the latest stumpwm commit
22:14:44
defaultxr
i also have an external monitor connected, same resolution (1920x1080) as the main one.. but i'm just throwing things out there tbh, i really have no idea
22:17:15
defaultxr
what's weird is that stumpwm seems to crash once, restart, and then crash again (and then the second time is down for the count). i guess that is why when i did the (with-open-file ...) thing above, it showed (1080 1081 0) twice
22:20:44
PuercoPop
Yeah, this bug and the loosing the zoom window are the two bugs that bother me the most
22:25:11
defaultxr
yeah, the bugs make me look forward to when ulubis or paulownia are more usable (it's too bad they both seem a bit dormant at the moment..)
22:25:44
defaultxr
though i'm guessing most of the problems with stump are due to X being weird and complicated more than anything else
22:28:23
defaultxr
here's the debug output from (setf *debug-level* 20) (redirect-all-output ...): http://ix.io/1RWx
22:33:22
PuercoPop
defaultxr: I think most issues are due to it being a long-lived messy code base more than than anything X11 related. I do like that ulubis sues CEPL for the composting, although I would prefer if it used less C-wrappers
22:35:42
defaultxr
that's a good point. stumpwm is from before quicklisp was even a thing so i guess cruft is inevitable with that age
22:36:15
defaultxr
and yeah, dealing with C wrappers is one of my least favorite parts of lisping :P
22:38:08
defaultxr
CEPL seems cool, but i haven't been able to get into it since i know next to nothing about opengl (sadly)
22:45:25
PuercoPop
defaultxr: same, in fact my laptop's video card is too old to run CEPL I've only been able to run it recently at home.
22:49:43
defaultxr
that's unfortunate... i don't even know how recent cepl's required opengl version is, so i have no idea how old that makes your laptop...
22:49:55
defaultxr
i got a new laptop recently, all AMD, and it's definitely been the least trouble i've had hardware-wise on linux... so if you're considering getting a new one, i'd definitely suggest finding an all-AMD system if possible :)
22:55:10
PuercoPop
its ~2012ish. I got to get a new one soon. One of the helixes of the fan broke. This makes the fan loose its balance and hit the surrounding plastic and making a somewhat loud noise.