Newest at the top
| 2026-07-03 11:33:13 +0000 | pfc | (~pfc@user/pfc) (Ping timeout: 247 seconds) |
| 2026-07-03 11:32:46 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 244 seconds) |
| 2026-07-03 11:28:33 +0000 | Googulator | (~Googulato@team.broadbit.hu) |
| 2026-07-03 11:28:16 +0000 | Googulator | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2026-07-03 11:00:48 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-07-03 10:59:02 +0000 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-07-03 10:55:35 +0000 | tromp | (~textual@2001:1c00:340e:2700:79a4:d68c:bc23:a22) |
| 2026-07-03 10:55:20 +0000 | Googulator | (~Googulato@team.broadbit.hu) |
| 2026-07-03 10:55:18 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) dibblego |
| 2026-07-03 10:55:18 +0000 | dibblego | (~dibblego@157.211.3.209) (Changing host) |
| 2026-07-03 10:55:18 +0000 | dibblego | (~dibblego@157.211.3.209) |
| 2026-07-03 10:54:19 +0000 | dibblego | (~dibblego@haskell/developer/dibblego) (Ping timeout: 264 seconds) |
| 2026-07-03 10:46:15 +0000 | tromp | (~textual@2001:1c00:340e:2700:79a4:d68c:bc23:a22) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-07-03 10:44:29 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-07-03 10:44:19 +0000 | Vizious | (~bes@user/Vizious) Vizious |
| 2026-07-03 10:42:58 +0000 | <danza> | yep that works, sorry for not updating. Such flags are also explained rather clearly in :help. Thanks probie. About the bytes, i assume that's allocated memory |
| 2026-07-03 10:42:55 +0000 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 264 seconds) |
| 2026-07-03 10:42:11 +0000 | <yahb2> | 5000050000 ; (0.01 secs, 8,874,152 bytes) |
| 2026-07-03 10:42:11 +0000 | <probie> | % sum [1..100000] |
| 2026-07-03 10:42:02 +0000 | <yahb2> | <no output> |
| 2026-07-03 10:42:02 +0000 | <probie> | % :set +s |
| 2026-07-03 10:42:02 +0000 | Vizious | (~bes@user/Vizious) (Ping timeout: 251 seconds) |
| 2026-07-03 10:40:17 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-07-03 10:36:24 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-07-03 10:34:57 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-07-03 10:33:51 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-07-03 10:22:22 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 255 seconds) |
| 2026-07-03 10:16:02 +0000 | Googulator | (~Googulato@team.broadbit.hu) (Ping timeout: 245 seconds) |
| 2026-07-03 10:14:50 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-07-03 10:11:54 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-07-03 10:10:54 +0000 | <danza> | i'll try that, cheers mauke |
| 2026-07-03 10:10:28 +0000 | <mauke> | ? |
| 2026-07-03 10:10:27 +0000 | <mauke> | :set +s |
| 2026-07-03 10:07:23 +0000 | <danza> | is there a simple way to time the execution of a command in GHCI? |
| 2026-07-03 09:46:43 +0000 | <tomsmeding> | interesting, I have to go now though |
| 2026-07-03 09:46:30 +0000 | <tomsmeding> | IIRC it doesn't create a new entry |
| 2026-07-03 09:45:35 +0000 | <tomsmeding> | this depends on whether a new readTVar creates a new transaction entry (to be checked during the commit phase) or if it replaces the existing one |
| 2026-07-03 09:45:10 +0000 | <tomsmeding> | hm no, the transaction should still be small because you're repeatedly reading the same TVars |
| 2026-07-03 09:44:57 +0000 | <jaror> | probably |
| 2026-07-03 09:43:52 +0000 | <tomsmeding> | jaror: wouldn't that be because now you're creating a gigantic transaction that is almost certain to get contested by someone? |
| 2026-07-03 09:42:00 +0000 | <jaror> | More like 50x |
| 2026-07-03 09:41:23 +0000 | <jaror> | And if I lower the busy work to `fib 15` the difference gets even larger |
| 2026-07-03 09:39:07 +0000 | <jaror> | Almost a 10x slowdown |
| 2026-07-03 09:38:57 +0000 | <jaror> | https://paste.tomsmeding.com/qyjpWpVb |
| 2026-07-03 09:36:38 +0000 | <jaror> | I am seeing much larger slowdown if I do this instead: atomically (let loop = do xs <- flushTQueue q; if xs == [] then loop else pure xs in loop) |
| 2026-07-03 09:33:04 +0000 | machinedgod | (~machinedg@d108-173-95-19.abhsia.telus.net) machinedgod |
| 2026-07-03 09:29:16 +0000 | <tomsmeding> | even if you get multiple TQueue entries per query, and even if you have some degenerate scheduler situations, that doesn't blow up your runtime to _half an hour_ |
| 2026-07-03 09:28:51 +0000 | <tomsmeding> | comerijn: there are a bunch of things that can decrease performance when you have a busy loop like this going on, but absentia was complaining that sending 5000 insert queries to postgres took half an hour |
| 2026-07-03 09:28:51 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-07-03 09:26:54 +0000 | <jaror> | yeah that could be it |