Newest at the top
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) |
2024-05-15 13:23:11 +0200 | zero | (~yin@user/zero) |
2024-05-15 13:18:42 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
2024-05-15 13:17:11 +0200 | <danse-nr3> | i don't use them much. Values are bound in the monad so that's their visibility? But execution order depends on evaluation and, i think, optimization flags |
2024-05-15 13:13:42 +0200 | xff0x | (~xff0x@2405:6580:b080:900:8cc9:e47c:f89a:15ee) |
2024-05-15 13:10:43 +0200 | chele | (~chele@user/chele) |
2024-05-15 13:03:39 +0200 | <carbolymer> | sry, I meant readIORef :) |
2024-05-15 13:03:17 +0200 | <lambdabot> | Read a => String -> IO a |
2024-05-15 13:03:16 +0200 | <danse-nr3> | :t readIO |
2024-05-15 13:02:15 +0200 | Lord_of_Life_ | Lord_of_Life |
2024-05-15 13:01:27 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 260 seconds) |
2024-05-15 13:00:53 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) |
2024-05-15 13:00:12 +0200 | <carbolymer> | are there are any guarantees for execution order and values visibility when using both readMVar and readIO? meaning: https://bpa.st/3DMA |
2024-05-15 12:56:05 +0200 | barak | (~barak@2a0d:6fc2:68c1:7200:3cf2:a87d:a02b:3e21) (Ping timeout: 272 seconds) |
2024-05-15 12:54:19 +0200 | fendor | (~fendor@2a02:8388:1605:ce00:24e2:c141:1f86:a346) |
2024-05-15 12:51:29 +0200 | <danse-nr3> | the new cradle lib looks nice |
2024-05-15 12:47:31 +0200 | poscat | (~poscat@user/poscat) |
2024-05-15 12:47:16 +0200 | poscat | (~poscat@user/poscat) (Quit: Bye) |