| 2023-04-17 00:05:43 +0200 | <jaspion[m]> | <mc47[m]> "Can you maybe send an exmaple..." <- import Control.Monad... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/abe50b3bd7460b3ee3798c6146d4b671accd…>) |
| 2023-04-17 01:09:33 +0200 | JonathanWatson[m | (~jjwmatrix@2001:470:69fc:105::2:a544) |
| 2023-04-17 01:12:14 +0200 | <JonathanWatson[m> | does anyone know where i can find old issues(?) for xmonad before it was on git? |
| 2023-04-17 01:12:40 +0200 | <JonathanWatson[m> | for example, #598 in this commit |
| 2023-04-17 01:12:41 +0200 | JonathanWatson[m | uploaded an image: (199KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/OOYThaNfLwQjsRPdscovbgyE/image.png > |
| 2023-04-17 01:13:27 +0200 | <vrs> | https://code.google.com/archive/p/xmonad/issues |
| 2023-04-17 01:13:50 +0200 | <JonathanWatson[m> | thank you! |
| 2023-04-17 01:18:09 +0200 | <vrs> | yw |
| 2023-04-17 01:18:21 +0200 | <vrs> | contains references to bugs such as the dreaded #4 |
| 2023-04-17 01:18:35 +0200 | <JonathanWatson[m> | by the way, what version control system was xmonad on before? i assume it was darcs but the google code archive page says "svn-based" |
| 2023-04-17 01:18:57 +0200 | <geekosaur> | we weren't in google code, we were on code.haskell.org which was darcs |
| 2023-04-17 01:19:19 +0200 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2023-04-17 01:19:35 +0200 | <geekosaur> | https://archives.haskell.org/code.haskell.org/xmonad/ https://archives.haskell.org/code.haskell.org/XMonadContrib/ |
| 2023-04-17 01:20:08 +0200 | <geekosaur> | it had no bug tracker so we used google code for that |
| 2023-04-17 01:23:01 +0200 | <JonathanWatson[m> | i ask as my current dissertation task is to update between about 100 versions of xmonad with my dynamic software updating system and i have been using git commits as versions of the program |
| 2023-04-17 01:23:23 +0200 | <JonathanWatson[m> | but now i appear to be on the darcs equivalent of commits |
| 2023-04-17 01:23:56 +0200 | <geekosaur> | I converted the darcs repos to git when I transferred us to github because c.h.o was being shut down |
| 2023-04-17 01:24:11 +0200 | <geekosaur> | so we should have all the darcs commits as well |
| 2023-04-17 01:24:52 +0200 | <JonathanWatson[m> | are there any major differences from git commits? |
| 2023-04-17 01:26:18 +0200 | <geekosaur> | darcs has a fancy "patch theory" for its "commits"/patches |
| 2023-04-17 01:26:28 +0200 | <geekosaur> | but I don't know much in the way of details |
| 2023-04-17 01:27:21 +0200 | <JonathanWatson[m> | i suppose if its been converted to git i can continue to use git reasoning |
| 2023-04-17 01:27:28 +0200 | <geekosaur> | I think it's an algebra |
| 2023-04-17 01:27:44 +0200 | <geekosaur> | but yes, the converted stuff should behave like git |
| 2023-04-17 01:28:24 +0200 | <JonathanWatson[m> | ok that should be fine |
| 2023-04-17 01:29:30 +0200 | <geekosaur> | I would expect things like cherrypicking to behave oddly but as far as just checking out commits is concerned it shouldn't matter |
| 2023-04-17 01:34:10 +0200 | <JonathanWatson[m> | yeah i'm only extracting the state of repository at pairs of commits where one commit is an ancestor of another and comparing them |
| 2023-04-17 01:47:05 +0200 | hightower2 | (~hightower@213.149.61.117) |
| 2023-04-17 02:41:39 +0200 | ft | (~ft@87.122.10.136) (Ping timeout: 260 seconds) |
| 2023-04-17 02:43:04 +0200 | ft | (~ft@i59F54987.versanet.de) |
| 2023-04-17 04:09:04 +0200 | td_ | (~td@i53870922.versanet.de) (Ping timeout: 248 seconds) |
| 2023-04-17 04:10:47 +0200 | td_ | (~td@i53870920.versanet.de) |
| 2023-04-17 04:46:29 +0200 | catman | (~catman@user/catman) |
| 2023-04-17 07:00:25 +0200 | catman | (~catman@user/catman) (Ping timeout: 240 seconds) |
| 2023-04-17 07:52:19 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 250 seconds) |
| 2023-04-17 07:54:20 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-17 07:58:37 +0200 | catman | (~catman@user/catman) |
| 2023-04-17 08:31:07 +0200 | catman | (~catman@user/catman) (Quit: WeeChat 3.8) |
| 2023-04-17 08:45:37 +0200 | mncheckm | (~mncheck@193.224.205.254) |
| 2023-04-17 09:14:52 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 252 seconds) |
| 2023-04-17 09:16:53 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-17 09:35:27 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2023-04-17 09:47:40 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:555f:6245:cbff:fe9f:48b1) |
| 2023-04-17 11:00:06 +0200 | murchadha[m] | (~murdchadh@2001:470:69fc:105::3:3103) (Quit: You have been kicked for being idle) |
| 2023-04-17 11:00:07 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) (Quit: You have been kicked for being idle) |
| 2023-04-17 11:00:07 +0200 | unclechu | (~unclechu@2001:470:69fc:105::354) (Quit: You have been kicked for being idle) |
| 2023-04-17 11:30:36 +0200 | noze | (~user@2001:41d0:a:21f1::1) (Quit: ERC 5.4 (IRC client for GNU Emacs 28.2)) |
| 2023-04-17 11:31:08 +0200 | noze | (~user@2001:41d0:a:21f1::1) |
| 2023-04-17 12:00:50 +0200 | hightower3 | (~hightower@213.149.61.95) |
| 2023-04-17 12:03:01 +0200 | hightower2 | (~hightower@213.149.61.117) (Ping timeout: 240 seconds) |
| 2023-04-17 12:17:23 +0200 | noze | (~user@2001:41d0:a:21f1::1) (Ping timeout: 256 seconds) |
| 2023-04-17 12:22:23 +0200 | noze | (~user@2001:41d0:a:21f1::1) |
| 2023-04-17 12:28:53 +0200 | thyriaen | (~thyriaen@2a01:aea0:dd4:555f:6245:cbff:fe9f:48b1) (Quit: Leaving) |
| 2023-04-17 14:04:48 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) (Ping timeout: 248 seconds) |
| 2023-04-17 16:52:59 +0200 | amenonsen | (~amenonsen@pitta.toroid.org) (Ping timeout: 264 seconds) |
| 2023-04-17 17:01:45 +0200 | sadmax | (~user@64.130.91.66) |
| 2023-04-17 17:11:22 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 3.8) |
| 2023-04-17 17:15:30 +0200 | abhixec | (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) (Ping timeout: 260 seconds) |
| 2023-04-17 17:49:03 +0200 | <JonathanWatson[m> | does anyone know how i can benchmark xmonad? i would like to give xmonad many keypresses via xdotool and see how long it takes xmonad to execute them all, but i don't know how to find out when this is |
| 2023-04-17 17:50:18 +0200 | <JonathanWatson[m> | i changed the NextLayout event to take five seconds and xdotool finishes immediately rather than wait for the five seconds |
| 2023-04-17 17:50:51 +0200 | <geekosaur> | xdotool doesn't know how to wait for results of key actions; it just sends the event and exits |
| 2023-04-17 17:51:04 +0200 | liskin[m] | (~liskinmat@2001:470:69fc:105::768) |
| 2023-04-17 17:51:19 +0200 | unclechu | (~unclechu@2001:470:69fc:105::354) |
| 2023-04-17 17:51:23 +0200 | <geekosaur> | (it doesn't even know what the result would be and therefore what to wait for) |
| 2023-04-17 17:53:25 +0200 | <JonathanWatson[m> | is there anything that could work without modifying xmonad itself? |
| 2023-04-17 17:53:41 +0200 | <geekosaur> | nope |
| 2023-04-17 17:53:42 +0200 | <JonathanWatson[m> | since any change i make probably needs to also be made to 96 other versions of xmonad |
| 2023-04-17 17:55:05 +0200 | <geekosaur> | and you would also need to modify xdotool, since as I said it has no idea of what to wait for. worse, xmonad can't even tell that xdotool sent the event and that it should send some response back; the event will have the `send_event` flag set, but no indication of what sent it |
| 2023-04-17 17:55:14 +0200 | <mc47[m]> | You can probably create a function that takes a label and `X a` and prints the label with how much it took to execute the action to a file or to stderr |
| 2023-04-17 17:55:52 +0200 | <mc47[m]> | Oh and Haskell laziness should be considered as well |
| 2023-04-17 17:56:10 +0200 | <geekosaur> | very little in xmonad is lazy since everything does IO actions… |
| 2023-04-17 17:56:49 +0200 | <mc47[m]> | But you'd need to wrape every action |
| 2023-04-17 17:57:57 +0200 | <JonathanWatson[m> | i think the easiest method for my purposes it to send like 1000 keypresses and then wait for the screen to stop changing for five seconds |
| 2023-04-17 17:58:01 +0200 | <JonathanWatson[m> | and then subtract five |
| 2023-04-17 17:59:14 +0200 | <JonathanWatson[m> | but then i need to make sure that i am sending the keypresses faster than xmonad is handling them and i need to check that that many keypresses can be queued |
| 2023-04-17 17:59:33 +0200 | <JonathanWatson[m> | and i also need to figure out how to actually check that the screen hasn't changed for five seconds |
| 2023-04-17 18:00:03 +0200 | <geekosaur> | that's actually the easiest part: select expose events on the root window and all children |
| 2023-04-17 18:01:26 +0200 | <JonathanWatson[m> | can i do that from outside of xmonad? |
| 2023-04-17 18:01:42 +0200 | <geekosaur> | yes |
| 2023-04-17 18:01:51 +0200 | <geekosaur> | (and must, in fact) |
| 2023-04-17 18:03:42 +0200 | <JonathanWatson[m> | is xmonad an X client? |
| 2023-04-17 18:05:50 +0200 | <geekosaur> | yes |
| 2023-04-17 18:06:04 +0200 | <JonathanWatson[m> | i'm haven't been sure exactly where it comes into the x window manager pipeline since it doesn't seem to be the server but isn't a normal program |
| 2023-04-17 18:06:47 +0200 | <geekosaur> | the only thing that makes a window manager special is that it selects SubstructureRedirectMask on the root window and all children. it's a bit hacky |
| 2023-04-17 18:07:17 +0200 | <JonathanWatson[m> | ok |
| 2023-04-17 18:07:53 +0200 | <JonathanWatson[m> | now i assume when i use xdotool to send keys they get sent to the x server and then the x server sends them to the x clients like xmonad to be consumed |
| 2023-04-17 18:08:57 +0200 | <geekosaur> | correct, with one small modification: xmonad uses passive key grabs, so when the server receives one of the grabbed keys it gives xmonad a full keyboard drab and sends all key events including the triggering event to it |
| 2023-04-17 18:09:25 +0200 | <geekosaur> | which is why you don't have to worry about focused windows |
| 2023-04-17 18:09:28 +0200 | <JonathanWatson[m> | oh ok |
| 2023-04-17 18:10:15 +0200 | <JonathanWatson[m> | my worry is that if i just run xdotool many times then the time taken for the benchmark to finish is the amount of time it takes xdotool to send that |
| 2023-04-17 18:10:25 +0200 | <JonathanWatson[m> | because it has a bit of a delay |
| 2023-04-17 18:10:37 +0200 | <geekosaur> | if all you're doing is timing xdotool, then yes that is exactly what will happen |
| 2023-04-17 18:11:12 +0200 | <JonathanWatson[m> | but if i could just send all of the keypresses to the x server at once and have them queued, then the limiting factor would just be the amount of time it takes for the x server to send the commands to xmonad and xmonad to execute them |
| 2023-04-17 18:11:43 +0200 | <JonathanWatson[m> | although the x server sending the commands might still be a limiting factor but i feel like less so? |
| 2023-04-17 18:11:46 +0200 | <geekosaur> | right, but detecting that is a problem |
| 2023-04-17 18:12:28 +0200 | <geekosaur> | they'll just sit in the AF_UNIX socket connecting xmonad to the X server until consumed by XNextEvent |
| 2023-04-17 18:12:33 +0200 | <JonathanWatson[m> | as in detecting that the commands have been executed? |
| 2023-04-17 18:12:37 +0200 | <geekosaur> | yes |
| 2023-04-17 18:13:37 +0200 | sadmax | (~user@64.130.91.66) (Remote host closed the connection) |
| 2023-04-17 18:13:43 +0200 | <geekosaur> | we don't have a hook that is executed just before the core does XNextEvent |
| 2023-04-17 18:13:56 +0200 | <JonathanWatson[m> | well i hope that once i stop queuing them, the display will keep flashing until all of the commands have been handled (at least no delays for more than five seconds) |
| 2023-04-17 18:14:11 +0200 | <geekosaur> | but if the key you send switches workspaces you could use an xmonad.hs which logs the time in its logHook or something |
| 2023-04-17 18:14:59 +0200 | <geekosaur> | note that it won't work well to time something that does a spawn because xmonad does a fork() to spawn the command and you won't get any timing after that |
| 2023-04-17 18:15:14 +0200 | <geekosaur> | (double fork(), in fact) |
| 2023-04-17 18:15:53 +0200 | werneta | (~werneta@70-142-214-115.lightspeed.irvnca.sbcglobal.net) |
| 2023-04-17 18:16:33 +0200 | <JonathanWatson[m> | well i was hoping not to time individual commands |
| 2023-04-17 18:16:46 +0200 | <JonathanWatson[m> | but just time how long it takes to do all of them |
| 2023-04-17 18:16:57 +0200 | <JonathanWatson[m> | and then compare that with the time for a potentially slower version of xmonad |
| 2023-04-17 18:38:45 +0200 | berberman_ | (~berberman@user/berberman) (Ping timeout: 256 seconds) |
| 2023-04-17 18:47:22 +0200 | <JonathanWatson[m> | also i have found an easy way to queue the commands now |
| 2023-04-17 18:47:50 +0200 | <JonathanWatson[m> | just send SIGSTOP, send all the commands to the x server with xdotool, then send SIGCONT |
| 2023-04-17 19:52:32 +0200 | amenonsen | (~amenonsen@pitta.toroid.org) |
| 2023-04-17 20:04:11 +0200 | berberman | (~berberman@user/berberman) |
| 2023-04-17 20:45:45 +0200 | kaskal | (~kaskal@213-147-166-209.nat.highway.webapn.at) (Ping timeout: 240 seconds) |
| 2023-04-17 20:51:58 +0200 | catman | (~catman@user/catman) |
| 2023-04-17 21:16:32 +0200 | kaskal | (~kaskal@2001:4bb8:2cc:efb3:2d42:311d:d744:4a5) |
| 2023-04-17 22:41:07 +0200 | catman | (~catman@user/catman) (Ping timeout: 276 seconds) |
| 2023-04-17 23:46:49 +0200 | stellacy | (~stellacy@gateway/tor-sasl/stellacy) |
