Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→
Page 1 .. 17420 17421 17422 17423 17424 17425 17426 17427 17428 17429 17430 .. 17998
— 1,799,800 events total
2026-01-23 11:57:16 <int-e> Do we have any canonical STM horror story (along the lines of "it worked great until we ran it in production with 50 simultaneous threads and then it spent 90% of its time retrying STM transactions"?)
2026-01-23 11:57:22 <tomsmeding> concurrent programming: correct, fast, convenient; pick 2
2026-01-23 11:57:27 <ncf> Leary: i didn't mean to encapsulate general recursion tbh, only to point out that the clarity of expressing things in terms of (co)algebras needn't come at the price of general recursion
2026-01-23 11:57:29 × fp quits (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 265 seconds)
2026-01-23 11:57:29 fp1 is now known as fp
2026-01-23 11:57:54 <tomsmeding> int-e: I'm not aware of any, I'm an academic
2026-01-23 12:00:51 <tomsmeding> Axman6: MVar doesn't implement Ord, only Eq
2026-01-23 12:01:37 → Googulator23 joins (~Googulato@team.broadbit.hu)
2026-01-23 12:03:09 <tomsmeding> (you may be thinking of ForeignPtr, which does implement Ord)
2026-01-23 12:05:33 × comonad quits (~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2026-01-23 12:10:54 → Googulator25 joins (~Googulato@team.broadbit.hu)
2026-01-23 12:10:54 × Googulator23 quits (~Googulato@team.broadbit.hu) (Quit: Client closed)
2026-01-23 12:17:59 <merijn> int-e: Almost surely
2026-01-23 12:18:10 <merijn> int-e: Bad STM design can easily cause that
2026-01-23 12:20:35 <merijn> tomsmeding: MVar doesn't have to ever lock and queue if you don't want to, though
2026-01-23 12:25:13 <tomsmeding> merijn: what do you mean?
2026-01-23 12:25:28 × hakutaku quits (~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2026-01-23 12:26:02 <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 12:26:18 → xff0x joins (~xff0x@2405:6580:b080:900:3b58:3b23:6c7:a174)
2026-01-23 12:26:37 <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 12:26:38 <bwe> tomsmeding: how would we categorize MVar, TVar, STM, IORef into two out of three of: correct, fast, convenient?
2026-01-23 12:27:31 <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 12:27:49 <tomsmeding> IORefs are plenty convenient if all you need is atomicModifyIORef', but they are rather limited otherwise
2026-01-23 12:28:28 <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 12:31:20 <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 12:31:31 <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 12:31:53 <tomsmeding> bwe: it kind of sounds like atomicModifyIORef' is good enough; if it isn't, come back
2026-01-23 12:36:14 → DetourNe- joins (~DetourNet@user/DetourNetworkUK)
2026-01-23 12:36:47 × DetourNetworkUK quits (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer)
2026-01-23 12:38:11 <bwe> tomsmeding: ok, thanks.
2026-01-23 12:38:31 DetourNe- is now known as DetourNetworkUK
2026-01-23 12:39:25 × fp quits (~Thunderbi@2001:708:150:10::9d7e) (Ping timeout: 244 seconds)
2026-01-23 12:39:37 × danz20169 quits (~danza@user/danza) (Quit: got to go)
2026-01-23 12:42:00 → fp joins (~Thunderbi@2001:708:150:10::9d7e)
2026-01-23 12:47:25 × vanishingideal quits (~vanishing@user/vanishingideal) (Ping timeout: 264 seconds)
2026-01-23 12:52:35 × CiaoSen quits (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 265 seconds)
2026-01-23 12:53:51 <merijn> tomsmeding: readMVar is non blocking on full MVars
2026-01-23 12:54:20 <merijn> bwe: tbh, "not very fast" here still means "pretty goddamn fast"
2026-01-23 12:55:13 <tomsmeding> merijn: as I said: if you only ever need to read, yes, life is easy :p
2026-01-23 12:55:25 <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 12:55:31 <tomsmeding> ^
2026-01-23 12:55:43 <merijn> if it's sub-second then it *might* matter
2026-01-23 12:56:24 <merijn> once you're planning to update every N milliseconds, that's when I'd consider thinking about performance implications
2026-01-23 12:56:30 <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:00:41 × img quits (~img@user/img) (Quit: ZNC 1.10.1 - https://znc.in)
2026-01-23 13:01:55 → img joins (~img@user/img)
2026-01-23 13:07:35 → karenw joins (~karenw@user/karenw)
2026-01-23 13:10:39 → Googulator63 joins (~Googulato@team.broadbit.hu)
2026-01-23 13:14:17 × Googulator25 quits (~Googulato@team.broadbit.hu) (Ping timeout: 272 seconds)
2026-01-23 13:19:04 × bggd_ quits (~bgg@2a01:e0a:fd5:f510:5241:8daa:4da4:a780) (Ping timeout: 260 seconds)
2026-01-23 13:21:31 <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 13:21:46 <haskellbridge> <Zemyla> I used newlines, and it still didn't work. D:
2026-01-23 13:27:05 × trickard quits (~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 13:27:19 → trickard_ joins (~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 13:28:54 → qqq joins (~qqq@185.54.21.105)
2026-01-23 13:30:57 → Zemy_ joins (~Zemy@2600:100c:b0a7:500d:4426:a6ff:feb6:d198)
2026-01-23 13:30:57 × Zemy quits (~Zemy@72.178.108.235) (Read error: Connection reset by peer)
2026-01-23 13:31:54 → Zemy joins (~Zemy@72.178.108.235)
2026-01-23 13:35:36 × Zemy_ quits (~Zemy@2600:100c:b0a7:500d:4426:a6ff:feb6:d198) (Ping timeout: 265 seconds)
2026-01-23 13:37:46 <haskellbridge> <geekosaur> .
2026-01-23 13:37:46 <haskellbridge> @botsnack
2026-01-23 13:38:11 <haskellbridge> <geekosaur> got the newline, inserted a space as well ☹️
2026-01-23 13:38:14 × wennefer0 quits (~wennefer0@user/wennefer0) (Read error: Connection reset by peer)
2026-01-23 13:38:49 <geekosaur> also you used too many lines, it would have been pastebinned
2026-01-23 13:38:57 <geekosaur> (if the newlines had gone through)
2026-01-23 13:40:48 × trickard_ quits (~trickard@cpe-93-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-01-23 13:41:01 → trickard_ joins (~trickard@cpe-93-98-47-163.wireline.com.au)
2026-01-23 13:41:44 × machinedgod quits (~machinedg@d75-159-126-101.abhsia.telus.net) (Ping timeout: 240 seconds)
2026-01-23 13:44:08 → comonad joins (~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de)
2026-01-23 13:51:20 <haskellbridge> <Zemyla> But what this does is fold the lists into a pair of coroutines which interleave.
2026-01-23 13:56:04 → Zemy_ joins (~Zemy@2600:100c:b0a7:500d:6465:32ff:febf:6476)
2026-01-23 13:58:18 × Zemy quits (~Zemy@72.178.108.235) (Ping timeout: 252 seconds)
2026-01-23 14:02:25 × fp quits (~Thunderbi@2001:708:150:10::9d7e) (Ping timeout: 245 seconds)
2026-01-23 14:03:11 → hakutaku joins (~textual@chen.yukari.eu.org)
2026-01-23 14:04:22 → fp joins (~Thunderbi@2001:708:20:1406::1370)
2026-01-23 14:09:24 → Zemy joins (~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 14:12:09 × Zemy_ quits (~Zemy@2600:100c:b0a7:500d:6465:32ff:febf:6476) (Ping timeout: 260 seconds)
2026-01-23 14:12:25 → Zemy_ joins (~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 14:15:57 × Zemy quits (~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 250 seconds)
2026-01-23 14:18:27 → Zemy joins (~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 14:21:09 × Zemy_ quits (~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 250 seconds)
2026-01-23 14:22:29 → Zemy_ joins (~Zemy@mobile-107-80-206-40.mycingular.net)
2026-01-23 14:22:37 → Core6390 joins (~Zemy@2600:100c:b0a7:500d:444d:5bff:fe79:c99d)
2026-01-23 14:23:17 → Core8830 joins (~Zemy@12.50.228.210)
2026-01-23 14:25:03 × Zemy quits (~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 250 seconds)
2026-01-23 14:26:09 × ZLima12 quits (~zlima12@user/meow/ZLima12) (Ping timeout: 260 seconds)
2026-01-23 14:26:49 × Core6390 quits (~Zemy@2600:100c:b0a7:500d:444d:5bff:fe79:c99d) (Ping timeout: 246 seconds)
2026-01-23 14:26:49 × Zemy_ quits (~Zemy@mobile-107-80-206-40.mycingular.net) (Ping timeout: 246 seconds)
2026-01-23 14:28:48 → ZLima12 joins (~zlima12@user/meow/ZLima12)
2026-01-23 14:32:13 × Core8830 quits (~Zemy@12.50.228.210) (Read error: Connection reset by peer)
2026-01-23 14:32:23 → Zemy joins (~Zemy@2600:100c:b0a7:500d:9c2b:5aff:fe6b:6dd6)
2026-01-23 14:32:52 → Zemy_ joins (~Zemy@syn-192-198-252-043.biz.spectrum.com)
2026-01-23 14:34:51 × Zemy quits (~Zemy@2600:100c:b0a7:500d:9c2b:5aff:fe6b:6dd6) (Read error: Connection reset by peer)
2026-01-23 14:35:02 → Zemy joins (~Zemy@2600:100c:b0a7:500d:9051:50ff:fef4:1dd3)
2026-01-23 14:36:35 × Zemy_ quits (~Zemy@syn-192-198-252-043.biz.spectrum.com) (Read error: Connection reset by peer)
2026-01-23 14:37:01 → Zemy_ joins (~Zemy@syn-192-198-252-043.biz.spectrum.com)
2026-01-23 14:39:33 × Zemy quits (~Zemy@2600:100c:b0a7:500d:9051:50ff:fef4:1dd3) (Ping timeout: 252 seconds)
2026-01-23 14:40:16 × Zemy_ quits (~Zemy@syn-192-198-252-043.biz.spectrum.com) (Read error: Connection reset by peer)
2026-01-23 14:40:22 → Zemy joins (~Zemy@2600:100c:b0a7:500d:c49:b7ff:fe30:b590)
2026-01-23 14:40:52 → Zemy_ joins (~Zemy@12.50.228.210)
←Prev  Next→
Page 1 .. 17420 17421 17422 17423 17424 17425 17426 17427 17428 17429 17430 .. 17998

All times are in UTC.