Newest at the top
| 2024-05-15 16:07:19 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-05-15 16:06:49 +0200 | lortabac | (~lortabac@37.166.188.80) |
| 2024-05-15 16:06:28 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2024-05-15 16:03:34 +0200 | ystael | (~ystael@user/ystael) |
| 2024-05-15 15:44:05 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) |
| 2024-05-15 15:39:54 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 255 seconds) |
| 2024-05-15 15:38:59 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-05-15 15:35:55 +0200 | waleee | (~waleee@h-176-10-144-38.NA.cust.bahnhof.se) |
| 2024-05-15 15:31:45 +0200 | raehik | (~raehik@rdng-25-b2-v4wan-169990-cust1344.vm39.cable.virginm.net) |
| 2024-05-15 15:28:00 +0200 | demon-cat | (~demon-cat@dund-15-b2-v4wan-169642-cust1347.vm6.cable.virginm.net) (Ping timeout: 268 seconds) |
| 2024-05-15 15:25:13 +0200 | danse-nr3 | (~danse-nr3@fi-19-195-11.service.infuturo.it) |
| 2024-05-15 15:24:28 +0200 | yin | zzz |
| 2024-05-15 15:06:11 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-05-15 15:05:59 +0200 | danza | (~francesco@fi-19-195-11.service.infuturo.it) (Ping timeout: 264 seconds) |
| 2024-05-15 14:57:17 +0200 | danza | (~francesco@fi-19-195-11.service.infuturo.it) |
| 2024-05-15 14:56:56 +0200 | cfricke | (~cfricke@user/cfricke) |
| 2024-05-15 14:53:49 +0200 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
| 2024-05-15 14:48:00 +0200 | random-jellyfish | (~developer@user/random-jellyfish) |
| 2024-05-15 14:45:38 +0200 | danse-nr3 | (~danse-nr3@fi-19-195-11.service.infuturo.it) (Ping timeout: 252 seconds) |
| 2024-05-15 14:42:13 +0200 | califax | (~califax@user/califx) |
| 2024-05-15 14:41:15 +0200 | danse-nr3 | (~danse-nr3@fi-19-195-11.service.infuturo.it) |
| 2024-05-15 14:40:12 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2024-05-15 14:39:35 +0200 | danse-nr3 | (~danse-nr3@fi-19-195-11.service.infuturo.it) (Ping timeout: 268 seconds) |
| 2024-05-15 14:30:26 +0200 | danse-nr3 | (~danse-nr3@fi-19-195-11.service.infuturo.it) |
| 2024-05-15 14:29:32 +0200 | gorignak | (~gorignak@user/gorignak) (Read error: Connection reset by peer) |
| 2024-05-15 14:18:59 +0200 | gorignak | (~gorignak@user/gorignak) |
| 2024-05-15 14:05:30 +0200 | talukara | (~talukara@user/talukara) |
| 2024-05-15 13:59:25 +0200 | danse-nr3 | (~danse-nr3@151.47.35.197) (Ping timeout: 272 seconds) |
| 2024-05-15 13:53:16 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) |
| 2024-05-15 13:52:47 +0200 | Maxdamantus | (~Maxdamant@user/maxdamantus) (Ping timeout: 264 seconds) |
| 2024-05-15 13:51:29 +0200 | rvalue- | rvalue |
| 2024-05-15 13:51:20 +0200 | koz | (~koz@121.99.240.58) |
| 2024-05-15 13:50:33 +0200 | koz | (~koz@121.99.240.58) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2024-05-15 13:48:39 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 272 seconds) |
| 2024-05-15 13:47:32 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-05-15 13:46:41 +0200 | destituion | (~destituio@85.221.111.174) |
| 2024-05-15 13:43:31 +0200 | xdminsy | (~xdminsy@117.147.70.240) |
| 2024-05-15 13:42:40 +0200 | acidjnk_new | (~acidjnk@p200300d6e714dc380dd5b841c8115985.dip0.t-ipconnect.de) |
| 2024-05-15 13:41:39 +0200 | ddellacosta | (~ddellacos@ool-44c73d29.dyn.optonline.net) (Quit: WeeChat 4.2.1) |
| 2024-05-15 13:38:25 +0200 | yin | (~yin@user/zero) |
| 2024-05-15 13:38:00 +0200 | zero | (~yin@user/zero) (Quit: leaving) |
| 2024-05-15 13:37:10 +0200 | <carbolymer> | memory model |
| 2024-05-15 13:37:01 +0200 | <carbolymer> | [Leary]: That memory is exactly what I was looking for. Thanks! |
| 2024-05-15 13:35:31 +0200 | <[Leary]> | It's more "complicated" to get your guarantees from IORefs and MVars than from STM, and that's when it's even possible. Concurrent programs need every guarantee they can get their hands on. |
| 2024-05-15 13:34:33 +0200 | <[Leary]> | Well, you can start by pointing them here: https://hackage.haskell.org/package/base-4.19.1.0/docs/Data-IORef.html#memmodel |
| 2024-05-15 13:33:28 +0200 | cfricke | (~cfricke@user/cfricke) (Ping timeout: 255 seconds) |
| 2024-05-15 13:31:57 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-05-15 13:27:52 +0200 | <carbolymer> | [Leary]: that's my intuition. I've used STM for my change, got challenged on a PR "that's complicated, what's wrong with IORef?", so I'm trying to estimate how many footguns can I fit between IORef and MVar. |
| 2024-05-15 13:26:22 +0200 | <[Leary]> | carbolymer: If you build a concurrent system by duct-taping MVars and IORefs together, you're just asking to suffer. Broadly speaking, I do expect `atomicModifyIORef r f >> readySetGo` and `await >> atomicModifyIORef r (\v -> (v, v))` to work out, but /really/, just use STM. |
| 2024-05-15 13:25:28 +0200 | kspalaiologos | (~kspalaiol@user/kspalaiologos) (Quit: Leaving) |