Logs on 2022-06-16 (liberachat/#xmonad)
| 00:07:48 | × | hipurus quits (~Guest9@184.4.83.175) (Quit: Client closed) |
| 00:15:07 | × | werneta quits (~werneta@137.79.230.15) (Ping timeout: 260 seconds) |
| 00:16:52 | → | werneta joins (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 00:21:10 | × | werneta quits (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 00:21:54 | → | werneta joins (~werneta@137.79.230.15) |
| 00:26:38 | × | stackdroid18 quits (~stackdroi@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 01:00:22 | × | benin quits (~benin@183.82.27.33) (Ping timeout: 246 seconds) |
| 01:02:43 | → | benin joins (~benin@183.82.204.191) |
| 01:53:40 | vrs_ | is now known as vrs |
| 01:56:27 | <byorgey> | geekosaur: ms teams for linux works fine for me under xmonad |
| 01:56:52 | → | ocelot__ joins (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) |
| 01:56:59 | <byorgey> | I mean, it doesn't seem any crappier than it would be under any other window manager |
| 01:58:15 | × | ocelot__ quits (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) (Client Quit) |
| 01:58:32 | × | ocelot_ quits (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) (Remote host closed the connection) |
| 01:59:01 | → | ocelot_ joins (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) |
| 01:59:31 | × | ocelot_ quits (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) (Client Quit) |
| 02:00:12 | → | ocelot_ joins (~ocelot@50-78-208-189-static.hfc.comcastbusiness.net) |
| 02:02:32 | × | banc quits (banc@gateway/vpn/airvpn/banc) (Ping timeout: 248 seconds) |
| 02:10:33 | × | td_ quits (~td@muedsl-82-207-238-033.citykom.de) (Ping timeout: 256 seconds) |
| 02:12:32 | → | td_ joins (~td@muedsl-82-207-238-107.citykom.de) |
| 02:23:20 | → | banc joins (banc@gateway/vpn/airvpn/banc) |
| 02:30:41 | × | benin quits (~benin@183.82.204.191) (Ping timeout: 246 seconds) |
| 03:19:49 | → | steve__ joins (~steve@ool-182c2b80.dyn.optonline.net) |
| 04:07:58 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4588) |
| 06:07:39 | × | sundbry quits (~quassel@99-42-143-129.lightspeed.sntcca.sbcglobal.net) (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) |
| 07:10:33 | → | dschrempf joins (~dominik@mobiledyn-62-240-134-11.mrsn.at) |
| 07:33:20 | → | jaklt[m] joins (~jaklttchn@2001:470:69fc:105::a42) |
| 08:08:25 | → | benin joins (~benin@183.82.28.222) |
| 08:39:52 | × | defjam quits (~eb0t@33bac70c.skybroadband.com) (Ping timeout: 248 seconds) |
| 08:41:51 | → | defjam joins (~eb0t@33bac63e.skybroadband.com) |
| 08:48:59 | → | fdnick` joins (~user@2a02:8109:a140:e0a:cf84:f4c7:382a:dcd8) |
| 09:00:09 | × | kwer[m] quits (~kwermatri@2001:470:69fc:105::1:4da1) (Quit: You have been kicked for being idle) |
| 09:00:16 | × | jmac123[m] quits (~jmac123ma@2001:470:69fc:105::1:eaf0) (Quit: You have been kicked for being idle) |
| 09:12:15 | → | gdd joins (~gdd@2001:470:1f13:187:c211:ee4c:6eca:b634) |
| 09:38:08 | → | fdnick`` joins (~user@2a02:8109:a140:e0a:273f:3891:babf:2556) |
| 09:41:30 | × | dschrempf quits (~dominik@mobiledyn-62-240-134-11.mrsn.at) (Quit: WeeChat 3.5) |
| 09:42:13 | × | fdnick` quits (~user@2a02:8109:a140:e0a:cf84:f4c7:382a:dcd8) (Ping timeout: 258 seconds) |
| 09:47:45 | → | alternateved joins (~alternate@194.99.105.235) |
| 10:05:19 | × | alternateved quits (~alternate@194.99.105.235) (Read error: Connection reset by peer) |
| 10:05:45 | → | alternateved joins (~alternate@194.99.105.235) |
| 10:14:58 | ← | fdnick`` parts (~user@2a02:8109:a140:e0a:273f:3891:babf:2556) (ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)) |
| 11:14:59 | × | mvk quits (~mvk@2607:fea8:5ce3:8500::4588) (Ping timeout: 258 seconds) |
| 11:43:52 | × | steve__ quits (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 248 seconds) |
| 12:07:18 | × | benin quits (~benin@183.82.28.222) (Quit: The Lounge - https://thelounge.chat) |
| 12:24:18 | → | dschrempf joins (~dominik@mobiledyn-62-240-134-11.mrsn.at) |
| 12:42:07 | → | SevenCircle[m] joins (~sevencirc@2001:470:69fc:105::2:2ee4) |
| 14:32:17 | × | dschrempf quits (~dominik@mobiledyn-62-240-134-11.mrsn.at) (Quit: WeeChat 3.5) |
| 16:02:10 | → | mvk joins (~mvk@2607:fea8:5ce3:8500::4588) |
| 16:14:26 | → | stackdroid18 joins (14094@user/stackdroid) |
| 16:54:54 | → | neoatnebula joins (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) |
| 16:55:26 | × | neoatnebula quits (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) (Client Quit) |
| 16:56:05 | → | neoatnebula joins (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) |
| 17:27:22 | × | neoatnebula quits (~neoatnebu@2409:4071:4d8f:ce27:ead8:44cb:83ba:d42f) (Quit: Client closed) |
| 17:46:41 | × | terrorjack quits (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 17:49:32 | → | terrorjack joins (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 18:04:53 | <lyiriyah[m]> | Hi, I have an odd issue. |
| 18:04:53 | <lyiriyah[m]> | There's a discrepancy |
| 18:05:16 | <lyiriyah[m]> | * a discrepancy between the window name shown in xmobar and the window name shown in _NET_WM_NAME by `xprop`. |
| 18:06:21 | <geekosaur> | _NET_WM_NAME changes dynamically and doesn't typically force the logHook to be rerun |
| 18:07:00 | <geekosaur> | (this can also affect taskbars and such unless they specifically watch _NET_WM_NAME) |
| 18:07:46 | <lyiriyah[m]> | Oh wait, I see what's happening. The title's being read from WM_CLASS |
| 18:07:57 | <lyiriyah[m]> | Is there any way to change this somehow? |
| 18:08:25 | <lyiriyah[m]> | It's slightly annoying because all my librewolf windows have the same name... |
| 18:08:51 | <geekosaur> | huh? you should doublecheck your logHook in that case |
| 18:12:34 | <lyiriyah[m]> | I don't have a logHook configured, I'm using X.H.StatusBar |
| 18:13:50 | lyiriyah[m] | sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/2e47fc4a6a03a22616085d8bb259ab616795831c |
| 18:19:44 | <geekosaur> | what's `ppC`? |
| 18:19:58 | <lyiriyah[m]> | My ppConfig |
| 18:21:05 | <geekosaur[m]> | right, but what is its value? |
| 18:21:29 | <lyiriyah[m]> | One sec |
| 18:24:31 | lyiriyah[m] | sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/f988ad70f0c2af276979ab959e0847972a017abd |
| 18:25:16 | <lyiriyah[m]> | According to the source the default value of `ppTitle` is `shorten 80` |
| 18:32:44 | <lyiriyah[m]> | X.L.Tabbed has the same issue which leads me to believe it's something going wrong in X.U.NamedWindows |
| 18:32:48 | <geekosaur[m]> | it uses `getName`, not `getNameWMClass`. `getName` does the right thing unless you've used `NamedWindow` to rename it |
| 18:33:42 | <geekosaur[m]> | thing is, I get the window title and use Tabbed here, and both behave correctly |
| 18:33:48 | <geekosaur[m]> | xmonad git |
| 18:34:14 | <lyiriyah[m]> | Hmm, odd |
| 18:38:14 | <lyiriyah[m]> | It's definitely reading `WM_CLASS`. Changing that property with `xdotool selectwindow set_window --classname "test"` also changes the title |
| 18:38:53 | <geekosaur[m]> | you don't happen to have a `lib` subdirectory in your xmonad configuration, do you? |
| 18:39:05 | <lyiriyah[m]> | No, I don't |
| 18:41:31 | <geekosaur[m]> | (you can override xmonad modules there, including XMonad.Util.NamedWindow, and I've been known to do that for development or debugging and then forget about it 😀) |
| 18:41:39 | <lyiriyah[m]> | Ah |
| 18:42:47 | <lyiriyah[m]> | I do have a build script:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/ef55ff986e8eec820c89cd40474f18f1c9f4fc32) |
| 18:43:28 | <geekosaur[m]> | it shouldn't unless you also have a possibly customized xmonad-contrib source tree around |
| 18:43:56 | <lyiriyah[m]> | I do have a contrib source tree but I haven't customised it |
| 18:44:18 | <geekosaur[m]> | actually I wonder if you even need that build script these days, we support stack config directly as long as a stack.yaml is present, which you'd need for that to work anyway |
| 18:44:54 | <lyiriyah[m]> | Don't think I do -- it's just a holdover from older configs |
| 18:46:34 | <geekosaur[m]> | you might verify the local contrib source tree isn't in use, or if it is, that NamedWindows.hs hasn't been edited |
| 18:49:16 | <lyiriyah[m]> | It hasn't been edited, no |
| 18:59:10 | <geekosaur[m]> | I can't help but think that `getNameWMClass` being right next to `getName` is related, but I'd be really concerned if this is a link error of some kind |
| 19:01:51 | <lyiriyah[m]> | Yeah... |
| 19:03:57 | <geekosaur[m]> | poking around locally and mine is definitely working correctly. are you on 0.17.0 or git? |
| 19:04:03 | <lyiriyah[m]> | git |
| 19:05:47 | <geekosaur[m]> | I traced through git's code and it's correct. sigh |
| 19:06:13 | <geekosaur[m]> | didn't get broken by the rewrite to simplify status bar support or anything like that |
| 19:11:35 | <geekosaur[m]> | don't suppose Solid is about by any chance? |
| 19:13:45 | <geekosaur[m]> | hm. what version of ghc? we've been having some weird problems with 9.0.1 and later, although if this turns out to be related then things are much worse than anyone imagined… |
| 19:14:08 | <lyiriyah[m]> | 8.10.7 |
| 19:14:42 | <lyiriyah[m]> | Wait, that's `ghc --version`, `stack ghc -- --version` gives me 9.0.2 |
| 19:16:02 | <geekosaur[m]> | just for grins and giggles, try seeing if it happens with 8.10.7 (change the resolver to lts 18.28) |
| 19:17:13 | <lyiriyah[m]> | Alright, rebuilding now |
| 19:20:12 | <Solid> | geekosaur[m]: am here, what's up? |
| 19:20:59 | <Solid> | guess I should read the backlog :) |
| 19:21:30 | <lyiriyah[m]> | I'm having an issue where X.U.NamedWindows is reading window titles from WM_CLASS instead of _NET_WM_NAME or WM_NAME |
| 19:22:18 | <lyiriyah[m]> | Solid |
| 19:22:56 | <geekosaur> | I've been through the code several times and it seems to be doing the right thing, plus it's working properly here. was wondering if you might have some additional ideas |
| 19:24:41 | <geekosaur[m]> | (sorry for jumping between irc and matrix, had a potential problem to deal with in another channel) |
| 19:25:07 | <Solid> | lyiriyah[m]: could you post your entire config? I'd like to first see if I can actually reproduce this |
| 19:25:11 | × | stackdroid18 quits (14094@user/stackdroid) (Quit: hasta la vista... tchau!) |
| 19:26:15 | <lyiriyah[m]> | https://git.envs.net/lyiriyah/xmonad-config/src/branch/zenbook-duo/xmonad.hs |
| 19:31:38 | <Solid> | mh, still building, but I can see that getName _does_ call getClassHint in case everything else (_NET_WM_NAME and WM_CLASS, that is) fails |
| 19:32:18 | <geekosaur[m]> | except it shouldn't be failing, since it works with xprop |
| 19:33:14 | <geekosaur[m]> | mrr, I really hope this doesn't turn out to be the same problem as #389 |
| 19:33:28 | <geekosaur[m]> | if it goes away with 8.10.7 we got a definite ghc hot potato |
| 19:34:04 | <geekosaur[m]> | problem with FFI most likely |
| 19:35:13 | <Solid> | I run 9.0.2 myself and it's totally fine here |
| 19:35:19 | <Solid> | so probably not the GHC thing |
| 19:36:05 | <geekosaur[m]> | keep in mind I couldn't reproduce the crash locally with my config and 9.2.2, and you'd think if any config would provoke it, it'd be my monstrosity |
| 19:36:27 | <lyiriyah[m]> | I've rebuilt with 8.10.7 and it's still occuring |
| 19:36:35 | <lyiriyah[m]> | s/occuring/occurring/ |
| 19:36:38 | <geekosaur[m]> | while abastro reproduced it with a near minimal config |
| 19:36:54 | <geekosaur[m]> | I'm not sure if that's good news or bad |
| 19:37:05 | <Solid> | (I could actually reproduce that today (at some point, right now it's stable again ._.) but I also had to play around with xft stuff) |
| 19:38:02 | <Solid> | lyiriyah[m]: I guess your best bet would be to play around with getName and getNameWmClass in a stack ghci session or something and perhaps print the exception that occurs |
| 19:41:22 | × | terrorjack quits (~terrorjac@2a01:4f8:1c1e:509a::1) (Quit: The Lounge - https://thelounge.chat) |
| 19:43:40 | → | terrorjack joins (~terrorjac@2a01:4f8:1c1e:509a::1) |
| 19:46:27 | <lyiriyah[m]> | <Solid> "lyiriyah: I guess your best..." <- Can you give me some pointers on how I'd go about this? |
| 19:48:54 | <geekosaur[m]> | that'll be difficult because it's in X, not IO |
| 19:49:01 | <geekosaur[m]> | not even MonadIO |
| 19:52:40 | → | steve__ joins (~steve@ool-182c2b80.dyn.optonline.net) |
| 19:55:36 | <lyiriyah[m]> | hmm |
| 20:00:48 | <Solid> | I would just copy the relevant parts out of getName |
| 20:01:04 | <Solid> | all you need is to call openDisplay, really |
| 20:01:28 | <Solid> | all the rest is X11 functions that are in IO natively |
| 20:01:33 | × | gdd quits (~gdd@2001:470:1f13:187:c211:ee4c:6eca:b634) (Remote host closed the connection) |
| 20:03:30 | <Solid> | I wish I could offer a few more pointers (heh) but I'm dead tired and will go to bed now |
| 20:03:43 | <lyiriyah[m]> | Good night |
| 20:14:45 | <geekosaur[m]> | oh god, I hope I haven't just found it |
| 20:15:50 | <geekosaur[m]> | `getTextProperty`, when I chased it down, uses a `CString`. which has a trailing `NUL`. but X11 properties are counted strings |
| 20:17:15 | <geekosaur[m]> | which means (a) we usually get lucky with trailing `NUL`s (b) we probably poke a `NUL` where it doesn't belong, which would explain GC crashes |
| 20:18:11 | <lyiriyah[m]> | Any idea how I could see if this is the issue? |
| 20:20:06 | <geekosaur[m]> | not easily. I need to doublecheck that something that is a `CString` is assumed to have trailing `NUL`. but I'm pretty sure there's a separate `CStringLen` for this case |
| 20:31:53 | <geekosaur[m]> | mm, looks like it's okay aside from not being thread safe (and nobody allocates or frees the string so it must be internal, which makes me wonder if there's a length limit…) |
| 20:32:19 | <geekosaur[m]> | wonder if we should switch to the raw property interface so we have control over that |
| 20:35:27 | <geekosaur[m]> | `openDisplay [] >>= \d -> getTextProperty d `_windowid_`"_NET_WM_NAME" >>= print . tp_value` where _windowid_ comes from xwininfo |
| 20:36:38 | <geekosaur[m]> | assuming a `CString` has a `Show` instance |
| 20:37:26 | <geekosaur[m]> | (wat, why does this think I changed X11) |
| 20:37:53 | <geekosaur[m]> | oh, wrong directory 👀 |
| 20:39:19 | <geekosaur[m]> | and I think that needs to be an Atom, not a string |
| 20:39:45 | <geekosaur[m]> | yep |
| 20:43:28 | <geekosaur[m]> | well, that "worked" but the Show instance just prints the pointer. not real helpful |
| 20:45:43 | <geekosaur[m]> | *Main Foreign.C.String> openDisplay [] >>= \d -> internAtom d "_NET_WM_NAME" False >>= \a -> getTextProperty d 0x400001f a >>= peekCString . tp_value >>= print |
| 20:45:43 | <geekosaur[m]> | "Element [2] | xmonad - Google Chrome" |
| 20:47:36 | lyiriyah[m] | sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/3753f1e3a3e363a76fd797aee04d7502182281ab |
| 20:47:46 | <lyiriyah[m]> | oh the window doesn't exist |
| 20:47:50 | <lyiriyah[m]> | 🤦 |
| 20:47:54 | <lyiriyah[m]> | it's been a long day |
| 20:48:08 | <geekosaur[m]> | the window ID I used was for my Element app window, you need to use xwininfo to get the window ID for some window on your desktop |
| 20:48:20 | <geekosaur[m]> | which I mentioned earlier |
| 20:49:17 | <lyiriyah[m]> | Ok, when I actually use a window that exists that does work on my end |
| 20:53:31 | <geekosaur[m]> | I still need to check that when we *set* a property we're not doing something stupid, since I'm not yet sure `NUL` is handled sanely on either the Haskell or the X11 end |
| 20:53:55 | <lyiriyah[m]> | Alright |
| 20:54:15 | <lyiriyah[m]> | Thanks for your help, by the way (you too Solid) |
| 20:54:50 | <geekosaur[m]> | I do worry about the thread unsafeness of this stuff; I hope you aren't configured to link with `-threaded` or things may be going very wrong (although we don't use threads so they *shouldn't* be — famous last words…) |
| 20:56:25 | <geekosaur[m]> | actually I think with `threaded` it may be being run in a different thread by the IO manager even if we don't make new Haskell threads, so |
| 20:56:43 | <geekosaur[m]> | s/`/`-/ |
| 21:00:11 | <geekosaur[m]> | mm, `XSetTextProperty` doesn't require a `NUL`, it uses `nitems`, good. |
| 21:05:01 | <geekosaur[m]> | and the other side uses a `CStringLen`. we're golden |
| 21:05:38 | <geekosaur[m]> | some ways I wish we weren't, though, it'd be good to find a smoking gun for all the 9.x crashes |
| 21:09:44 | <geekosaur[m]> | you might have to patch NamedWindows.hs to show what's happening |
| 21:16:28 | <lyiriyah[m]> | Alright, I can do that |
| 21:41:50 | × | alternateved quits (~alternate@194.99.105.235) (Remote host closed the connection) |
| 21:46:09 | → | gdd joins (~gdd@2001:470:1f13:187:49b9:231c:6a88:73db) |
| 21:50:45 | → | Guest67 joins (~Guest67@2607:fea8:7ca0:2270:6044:2b47:5cac:b70f) |
| 22:48:46 | <liskin> | geekosaur[m]: the main thread is bound, and you can't fork a thread while staying inside of the X monad, and most people don't run xmonad with -threaded, so… |
| 22:49:47 | <liskin> | but yeah with -threaded and manually forking a thread in IO and calling thread unsafe function that use global storage, things might go awry |
| 22:50:22 | <liskin> | but then maybe the current Xlib uses thread-local storage? it certainly does use mutexes to protect its own shared data |
| 22:52:58 | <geekosaur> | only if so enabled, which is a call I don't recall us making (and it slows X11 down a lot) |
| 22:53:37 | <geekosaur> | but the real worry is internal state (that is, a static buffer). and we have modules which fork threads that open their own connections to the X server |
| 22:54:14 | <geekosaur> | I don't offhand recall any of those calling directly or indirectly XGetTextProperty, but if any do there's one source of problems |
| 22:54:33 | <geekosaur> | the other potential source is of course that presumably static buffer… and buffer overflows |
| 22:54:58 | <geekosaur> | since there's no evident call to XFree anywhere, I have to assume it's static and therefore overflowable |
| 22:55:42 | <geekosaur> | but I don't really want to dig into Xlib source to find out |
| 23:01:22 | <geekosaur> | flip side, we've never heard of problems here before, so it either can't be too bad or is really hard to hit in most cases (but that leaves why lyiriyah[m] would be hitting it so consistently, which is some of what makes me wonder if `-threaded` might be involved) |
| 23:03:56 | <liskin> | it's enabled by default since last xlib or two |
| 23:04:03 | <geekosaur> | oh |
| 23:04:20 | <geekosaur> | surprised I haven't heard any bitching about performance |
| 23:14:13 | × | steve__ quits (~steve@ool-182c2b80.dyn.optonline.net) (Ping timeout: 246 seconds) |
| 23:33:39 | <geekosaur> | oh wait,m they included their build script, and no `-threaded` |
| 23:34:07 | <geekosaur> | sigh. I have no clue why `getName` would be taking the fallback path through `WM_CLASS` |
| 23:37:42 | × | Guest67 quits (~Guest67@2607:fea8:7ca0:2270:6044:2b47:5cac:b70f) (Quit: Client closed) |
All times are in UTC on 2022-06-16.