Logs: freenode/#xmonad
| 2020-12-15 14:14:10 | <Solid> | oh do take your time; no rush in xmonad land :) |
| 2020-12-15 14:14:15 | <Liskni_si> | possibly because one needs to learn a lot of stuff before it starts to make sense |
| 2020-12-15 14:17:31 | <Liskni_si> | for people like me who already know the concepts and all the troubles, systemd is a welcome abstraction, but it sure can be intimidating |
| 2020-12-15 14:17:38 | <Liskni_si> | just like any part of the modern desktop :-) |
| 2020-12-15 14:18:36 | <mc47> | It is intimidating, I remember it took me so much time to make xmonad work with KDE and understand what's going on |
| 2020-12-15 14:18:42 | kmicu | mumbles something about modern desktop defining rules in js and pulling in Rust to compile Spidermonkey. |
| 2020-12-15 14:20:09 | × | tugrik quits (~username@war.funkyjesus.org) (Quit: WeeChat 2.9) |
| 2020-12-15 14:22:14 | <geekosaur> | dunno, I keeep hearing about systemd viruses and wondering if we'd been better off with sysvinit |
| 2020-12-15 14:27:55 | <mc47> | Liskni_si I'm looking at your dotfiles, in particular the killPid function; do you think we should implement something similar, or is it enough to just traverse the PIDs and send sigTERM? |
| 2020-12-15 14:30:36 | → | growpotkin joins (~growpotki@130-45-30-154.dyn.grandenetworks.net) |
| 2020-12-15 14:30:55 | → | mrbirkov joins (uid453780@gateway/web/irccloud.com/x-edxiwdvttjunrmar) |
| 2020-12-15 14:34:47 | <Solid> | I'm not sure what race_ even does if xmonad is not compiled with -threaded |
| 2020-12-15 14:34:53 | <Solid> | which afaik it's not by default |
| 2020-12-15 14:39:10 | × | geekosaur quits (ac3a8b12@172.58.139.18) (Remote host closed the connection) |
| 2020-12-15 14:40:52 | <Liskni_si> | I had to make it more complex because my xmonad would get stuck in endless wait sometimes |
| 2020-12-15 14:41:26 | → | sfrique joins (~sfrique@189.122.177.88) |
| 2020-12-15 14:41:58 | <mc47> | ah alright |
| 2020-12-15 14:45:13 | → | tugrik joins (~username@war.funkyjesus.org) |
| 2020-12-15 14:46:30 | <Solid> | it may be worth sending a sigKILL if the sigTERM wasn't successful |
| 2020-12-15 14:47:23 | <Solid> | `signalProcess` should throw an IOError if something goes wrong on the sigTERM |
| 2020-12-15 14:48:14 | <Liskni_si> | it's not going to give you an error if xmobar decides to ignore the sigterm |
| 2020-12-15 14:48:23 | <Solid> | oh I see |
| 2020-12-15 14:51:47 | × | berberman_ quits (~berberman@unaffiliated/berberman) (Ping timeout: 260 seconds) |
| 2020-12-15 14:52:25 | → | berberman joins (~berberman@unaffiliated/berberman) |
| 2020-12-15 15:33:24 | → | seschwar joins (~seschwar@unaffiliated/seschwar) |
| 2020-12-15 15:33:47 | × | cfricke quits (~cfricke@unaffiliated/cfricke) (Ping timeout: 260 seconds) |
| 2020-12-15 15:43:42 | × | lally quits (sid388228@gateway/web/irccloud.com/x-udblkappiwdfbwqx) (Ping timeout: 260 seconds) |
| 2020-12-15 15:46:18 | → | lally joins (sid388228@gateway/web/irccloud.com/x-qptpvlldxpkwwzmr) |
| 2020-12-15 15:56:05 | <Solid> | just wondering; why do we use Data.Map instead of Data.Map.Strict |
| 2020-12-15 15:56:37 | <Solid> | basically all of the uses I've come across would be better modelled by a strict map |
| 2020-12-15 15:57:52 | <Liskni_si> | no idea |
| 2020-12-15 15:58:24 | <Liskni_si> | we also use String instead of ByteString or Text :-/ |
| 2020-12-15 15:59:01 | <Solid> | well, we can put that down to historical baggage :P |
| 2020-12-15 15:59:25 | <Solid> | actually, maybe the strict/lazy map split didn't exist either back in the day |
| 2020-12-15 16:04:13 | <al3x27> | is there an example how to use loghook (which i now use for xmobar) to log to sndErr? |
| 2020-12-15 16:04:47 | <al3x27> | stdErr |
| 2020-12-15 17:01:55 | → | geekosaur joins (42d52137@66.213.33.55) |
| 2020-12-15 17:06:15 | <geekosaur> | fwiw Data.Map.Strict also did not exist in the early days of xmonad |
| 2020-12-15 17:07:04 | <geekosaur> | may have to watch out for compatibility breaks if we change it at this point, though |
| 2020-12-15 17:20:42 | <geekosaur> | al3x27, possibly somewhere in DynamicLog to show DynamicLogString or w/e |
| 2020-12-15 17:21:18 | <geekosaur> | generally logging to stderr means you'r debugging and I at least tried to hide that in debug modules rather than make users futz with stdErr directly |
| 2020-12-15 17:22:57 | <al3x27> | geekosaur: i'm a new xmonad user, and still can't always follow what all the haskell does, so having some way of seeing values etc might help to muddle thru |
| 2020-12-15 17:23:05 | <al3x27> | thanks, btw |
| 2020-12-15 17:23:58 | <geekosaur> | the basic mechanism is: io $ hPutStrLn stdErr "whatever" |
| 2020-12-15 17:24:43 | <geekosaur> | (where `io` is just an alias / shorthand for `liftIO`) |
| 2020-12-15 17:25:05 | <geekosaur> | you may also find the Debug.Trace module of interest |
| 2020-12-15 17:29:16 | <al3x27> | geekosaur: i can work with that, thanks! |
| 2020-12-15 17:31:14 | → | jamik joins (~james@d75-159-1-216.abhsia.telus.net) |
| 2020-12-15 17:37:34 | <jamik> | Hey guys, why is xmonad intent on creating a ~/.xmonad directory when I have a $XDG_CONFIG_HOME/xmonad directory? Also I'm having trouble recompiling (https://dpaste.com/BAMJBV5VU). I tried using ghci to run `:set -package xmonad` to no avail. I know it's likely something basic but I'm not too familiar with ghc. |
| 2020-12-15 17:40:39 | <geekosaur> | is $XDG_CONFIG_HOME set when xmonad starts? also, how did you install xmonad? |
| 2020-12-15 17:41:01 | <geekosaur> | if you used stack or cabal v2+ then you need a build script |
| 2020-12-15 17:42:15 | <geekosaur> | although "hidden package" sounds like it's there but disabled, possibly in the global package scope from a system package manager. this may again require a build script |
| 2020-12-15 17:43:04 | <Solid> | if it's hidden you can try `ghc-pkg expose xmonad` |
| 2020-12-15 17:44:10 | <geekosaur> | if it's in global scope that will require sudo… or preferably some other solution |
| 2020-12-15 17:44:40 | <jamik> | Ah yes I forgot to mention I have installed xmonad with its ebuild in the main Gentoo portage tree, though it shows up in the output of ghc-pkg list. Yes $XDG_CONFIG_HOME is set and when I rm -r ~/.xmonad before recompiling it will look in the correct place initially (e.g. "$XDG_CONFIG_HOME/xmonad/build does not exist, using ghc) but it will then create ~/.xmonad anyway. |
| 2020-12-15 17:45:00 | <geekosaur> | I'm unclear but get the impression the global package scope defaults hidden in recent ghc, to try to avoid it messing with builds |
| 2020-12-15 17:45:34 | <geekosaur> | hm. some extension perhaps still uses it? are there any possibly hidden files in ~/.xmonad afterward? |
| 2020-12-15 17:46:22 | <jamik> | Solid: I ran ghc-pkg expose xmonad previously but I it didn't seem to change anything |
| 2020-12-15 17:46:24 | <geekosaur> | every so often we find an extension which does that and which didn't get updated, and if ~/.xmonad exists it gets used so we don't break existing configs |
| 2020-12-15 17:46:42 | <jamik> | Yeah it dumps the xmonad.errors file there |
| 2020-12-15 17:46:53 | <jamik> | but no hidden files |
| 2020-12-15 17:49:18 | <jamik> | I'm fine with using ~/.xmonad for now but I'd like to get the recompilation working, I don't understand why xmonad is considered hidden after running ghc-pkg expose on it |
| 2020-12-15 17:49:58 | <geekosaur> | well, I just partially answered one unrelated question, trying to check if were doing that wrong for some reason (still checking) |
| 2020-12-15 17:51:40 | <jamik> | Thank you for your help, it's been bothering me.. |
| 2020-12-15 17:53:58 | <geekosaur> | I can't see why we would be since the file is created on any rebuild, so putting it in the wrong place should have been fairly obvous |
| 2020-12-15 17:55:50 | <al3x27> | jamik: as far as XDG_CONFIG_HOME is concerned, xmonad doesn't care, but you can 'force' xmonad to do the right thing using XMONAD_CONFIG_DIR etc (see http://ix.io/2IbD for a variation) |
| 2020-12-15 17:56:41 | <Solid> | al3x27: xmonad does care about XDG_{CONFIG,DATA,CACHE}_HOME |
| 2020-12-15 17:57:18 | <Solid> | it just prefers the XMONAD_ env variables or ~/.xmonad, if any of these exist |
| 2020-12-15 17:57:37 | <jamik> | Yeah I read the order of consideration is $XMONAD_CONFIG_DIR > $XDG_CONFIG_HOME/xmonad > ~/.xmonad |
| 2020-12-15 17:57:44 | <geekosaur> | except in this case it seems to be creating ~/.xmonad afterward |
| 2020-12-15 17:58:10 | <geekosaur> | I just confirmed it's doing the right thing, not forcing it into ~/.xmonad unless for some reason $XMONAD_DATA_DIR is set |
| 2020-12-15 17:58:21 | <geekosaur> | wit xmonad.errors, that is |
| 2020-12-15 17:59:38 | × | mrbirkov quits (uid453780@gateway/web/irccloud.com/x-edxiwdvttjunrmar) (Quit: Connection closed for inactivity) |
| 2020-12-15 18:00:08 | <jamik> | so it always writes errors to ~/.xmonad, even if it tries to recompile using $XDG_CONFIG_HOME/xmonad? That would be the behaviour I'm getting |
| 2020-12-15 18:00:52 | <geekosaur> | no, it should be using wherever xmonad-$arch-$os is found (or written) which should be based on where xmonad.hs is found |
| 2020-12-15 18:01:44 | <geekosaur> | last time something like this came up we found an extension writing a data file to ~/.xmonad directly instead of using the functions to find the appropriate directory, but you say that's not happening here |
| 2020-12-15 18:02:27 | <jamik> | Yeah I'm just trying to test recompiling the default config |
| 2020-12-15 18:04:39 | <jamik> | I have not yet run xmonad successfully on this machine, I just ran find / xmonad-x86_64-linux and it didn't find anything |
| 2020-12-15 18:04:54 | <Solid> | this is seriously weird; it sets all the dirs at the start of the recompilation, so if ~/.xmonad doesn't exist when you start the recompile nothing should be created |
| 2020-12-15 18:05:30 | <Solid> | jamik: just to make sure, you do have XDG_DATA_HOME set? |
| 2020-12-15 18:06:03 | <Solid> | or, if not, ~/.local/share exists |
| 2020-12-15 18:06:05 | <jamik> | No I don't have $XDG_DATA_HOME set, I have $XDG_CONFIG_HOME set |
| 2020-12-15 18:06:09 | <geekosaur> | hm, actually this looks to me like, if the comments are right, you have to have precreated $XDG_DATA_DIR/xmonad or it will create ~/.xmonad |
| 2020-12-15 18:06:26 | <geekosaur> | not just $XDG_CONFIG_DIR/xmonad |
| 2020-12-15 18:06:53 | <Solid> | oh right, it's ~/.local/share/xmonad that has to exist |
| 2020-12-15 18:06:58 | <jamik> | Ahh |
| 2020-12-15 18:07:07 | <jamik> | okay I'll create that |
| 2020-12-15 18:07:42 | <geekosaur> | I wonder if there is a way to fix this that doesn't screw over anyone with an existing config but some other files in XDG locations |
| 2020-12-15 18:08:06 | <jamik> | okay so that problem is solved, thanks guys! Now the package (XMonad) is still hidden and compilation is still unsuccessful |
| 2020-12-15 18:08:19 | <geekosaur> | suppose ideally we'd check for where xmonad.hs is found and set the rest based on that instead of checking separately for each one |
| 2020-12-15 18:09:07 | <jamik> | I didn't even realize xmonad was trying to use the data dir |
| 2020-12-15 18:09:20 | <jamik> | I just assumed it would throw everything in the config dir |
| 2020-12-15 18:09:29 | <Solid> | how would you do the data-dir/cfg-dir split in that case? |
| 2020-12-15 18:10:44 | <jamik> | Me? I wouldn't, I was simply ignorant of how xmonad works. The other WMs I use don't have such a split |
| 2020-12-15 18:10:53 | <geekosaur> | we used to not do that. and arguably we're still doing it wrong because the compiled config is cache, not data (it can be regenerated by recompiling) |
| 2020-12-15 18:10:56 | <Solid> | nono, sorry, I was talking to geekosaur |
| 2020-12-15 18:11:07 | <Solid> | jamik: in that case you should also create $XDG_CACHE_DIR/xmonad, as some extensions use that |
| 2020-12-15 18:11:12 | <geekosaur> | but we've kinda halfassed the whole XDG thing |
| 2020-12-15 18:12:22 | <Solid> | CACHE_HOME* |
| 2020-12-15 18:12:31 | <Solid> | too many xdg variables |
All times are in UTC.