Newest at the top
| 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 |
| 2026-01-23 13:26:18 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3b58:3b23:6c7:a174) |
| 2026-01-23 13:26:02 +0100 | <bwe> | Axman6, mauke: that's exactly what I want to do, I know when I've got new data and only then want to update the IORef / MVar. -- So if I only want to swap something out, I'd be fine with an IORef? |
| 2026-01-23 13:25:28 +0100 | hakutaku | (~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2026-01-23 13:25:13 +0100 | <tomsmeding> | merijn: what do you mean? |
| 2026-01-23 13:20:35 +0100 | <merijn> | tomsmeding: MVar doesn't have to ever lock and queue if you don't want to, though |
| 2026-01-23 13:18:10 +0100 | <merijn> | int-e: Bad STM design can easily cause that |
| 2026-01-23 13:17:59 +0100 | <merijn> | int-e: Almost surely |
| 2026-01-23 13:10:54 +0100 | Googulator23 | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2026-01-23 13:10:54 +0100 | Googulator25 | (~Googulato@team.broadbit.hu) |
| 2026-01-23 13:05:33 +0100 | comonad | (~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2026-01-23 13:03:09 +0100 | <tomsmeding> | (you may be thinking of ForeignPtr, which does implement Ord) |
| 2026-01-23 13:01:37 +0100 | Googulator23 | (~Googulato@team.broadbit.hu) |
| 2026-01-23 13:00:51 +0100 | <tomsmeding> | Axman6: MVar doesn't implement Ord, only Eq |
| 2026-01-23 12:57:54 +0100 | <tomsmeding> | int-e: I'm not aware of any, I'm an academic |