Newest at the top
| 2026-01-23 14:44:08 +0100 | comonad | (~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de) |
| 2026-01-23 14:41:44 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 240 seconds) |
| 2026-01-23 14:41:01 +0100 | trickard_ | (~trickard@cpe-93-98-47-163.wireline.com.au) |
| 2026-01-23 14:40:48 +0100 | trickard_ | (~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2026-01-23 14:38:57 +0100 | <geekosaur> | (if the newlines had gone through) |
| 2026-01-23 14:38:49 +0100 | <geekosaur> | also you used too many lines, it would have been pastebinned |
| 2026-01-23 14:38:14 +0100 | wennefer0 | (~wennefer0@user/wennefer0) (Read error: Connection reset by peer) |
| 2026-01-23 14:38:11 +0100 | <haskellbridge> | <geekosaur> got the newline, inserted a space as well ☹️ |
| 2026-01-23 14:37:46 +0100 | <haskellbridge> | @botsnack |
| 2026-01-23 14:37:46 +0100 | <haskellbridge> | <geekosaur> . |
| 2026-01-23 14:35:36 +0100 | Zemy_ | (~Zemy@2600:100c:b0a7:500d:4426:a6ff:feb6:d198) (Ping timeout: 265 seconds) |
| 2026-01-23 14:31:54 +0100 | Zemy | (~Zemy@72.178.108.235) |
| 2026-01-23 14:30:57 +0100 | Zemy | (~Zemy@72.178.108.235) (Read error: Connection reset by peer) |
| 2026-01-23 14:30:57 +0100 | Zemy_ | (~Zemy@2600:100c:b0a7:500d:4426:a6ff:feb6:d198) |
| 2026-01-23 14:28:54 +0100 | qqq | (~qqq@185.54.21.105) |
| 2026-01-23 14:27:19 +0100 | trickard_ | (~trickard@cpe-93-98-47-163.wireline.com.au) |
| 2026-01-23 14:27:05 +0100 | trickard | (~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2026-01-23 14:21:46 +0100 | <haskellbridge> | <Zemyla> I used newlines, and it still didn't work. D: |
| 2026-01-23 14:21:31 +0100 | <haskellbridge> | <Zemyla> So you need a newtype to fold over both lists. @let newtype Z a b = Z { runZ :: a -> (Z a b -> b) -> b } @let zipF :: [a] -> [b] -> [(a, b)]; zipF xs ys = foldr (\a ak bk -> runZ bk a ak) (const []) xs $ foldr (\b bk -> Z $ \a ak -> (a, b):ak bk) (Z $ _ _ -> []) ys |
| 2026-01-23 14:19:04 +0100 | bggd_ | (~bgg@2a01:e0a:fd5:f510:5241:8daa:4da4:a780) (Ping timeout: 260 seconds) |
| 2026-01-23 14:14:17 +0100 | Googulator25 | (~Googulato@team.broadbit.hu) (Ping timeout: 272 seconds) |
| 2026-01-23 14:10:39 +0100 | Googulator63 | (~Googulato@team.broadbit.hu) |
| 2026-01-23 14:07:35 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2026-01-23 14:01:55 +0100 | img | (~img@user/img) img |
| 2026-01-23 14:00:41 +0100 | img | (~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in) |
| 2026-01-23 13:56:30 +0100 | <tomsmeding> | I recommended atomicModifyIORef' more because it does what it does well, and doesn't suggest it can do any more than it does :p |
| 2026-01-23 13:56:24 +0100 | <merijn> | once you're planning to update every N milliseconds, that's when I'd consider thinking about performance implications |
| 2026-01-23 13:55:43 +0100 | <merijn> | if it's sub-second then it *might* matter |
| 2026-01-23 13:55:31 +0100 | <tomsmeding> | ^ |
| 2026-01-23 13:55:25 +0100 | <merijn> | If your update frequencies is measures in "once every few seconds" (or less frequent) the performance difference between any of the solutions is essentially irrelevant |
| 2026-01-23 13:55:13 +0100 | <tomsmeding> | merijn: as I said: if you only ever need to read, yes, life is easy :p |
| 2026-01-23 13:54:20 +0100 | <merijn> | bwe: tbh, "not very fast" here still means "pretty goddamn fast" |
| 2026-01-23 13:53:51 +0100 | <merijn> | tomsmeding: readMVar is non blocking on full MVars |
| 2026-01-23 13:52:35 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 265 seconds) |
| 2026-01-23 13:47:25 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 264 seconds) |
| 2026-01-23 13:42:00 +0100 | fp | (~Thunderbi@2001:708:150:10::9d7e) fp |
| 2026-01-23 13:39:37 +0100 | danz20169 | (~danza@user/danza) (Quit: got to go) |
| 2026-01-23 13:39:25 +0100 | fp | (~Thunderbi@2001:708:150:10::9d7e) (Ping timeout: 244 seconds) |
| 2026-01-23 13:38:31 +0100 | DetourNe- | DetourNetworkUK |
| 2026-01-23 13:38:11 +0100 | <bwe> | tomsmeding: ok, thanks. |
| 2026-01-23 13:36:47 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-01-23 13:36:14 +0100 | DetourNe- | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-01-23 13:31:53 +0100 | <tomsmeding> | bwe: it kind of sounds like atomicModifyIORef' is good enough; if it isn't, come back |
| 2026-01-23 13:31:31 +0100 | <bwe> | tomsmeding: I simply need to update a state from db. Effectively swapping the old data for the new data. I am not sure how can I tell right now whether the type of atomicModifyIORef' fits my use case, though. |
| 2026-01-23 13:31:20 +0100 | <tomsmeding> | (you can get correct + fast + convenient if you never need to communicate between threads! Read-only shared data works very well ;p) |
| 2026-01-23 13:28:28 +0100 | <tomsmeding> | TVar is convenient and correct across the board (programming with STM is great!), but depending on your application's behaviour it may not be very fast |
| 2026-01-23 13:27:49 +0100 | <tomsmeding> | IORefs are plenty convenient if all you need is atomicModifyIORef', but they are rather limited otherwise |
| 2026-01-23 13:27:31 +0100 | <tomsmeding> | bwe: it's more how you use them, although neither MVar nor TVar are particularly fast (STM is just the framework around TVar so not a separate thing) |
| 2026-01-23 13:26:38 +0100 | <bwe> | tomsmeding: how would we categorize MVar, TVar, STM, IORef into two out of three of: correct, fast, convenient? |
| 2026-01-23 13:26:37 +0100 | <tomsmeding> | bwe: if the type of atomicModifyIORef' (mind the ') is good enough for you, it's almost guaranteed to be the fastest option |