Newest at the top
| 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) |
| 2024-05-15 12:45:27 +0200 | kspalaiologos | (~kspalaiol@user/kspalaiologos) |
| 2024-05-15 12:38:06 +0200 | acidjnk_new | (~acidjnk@p200300d6e714dc38450b2d9b476c9077.dip0.t-ipconnect.de) (Ping timeout: 268 seconds) |
| 2024-05-15 12:37:22 +0200 | rosco | (~rosco@yp-146-6.tm.net.my) (Quit: Lost terminal) |
| 2024-05-15 12:37:01 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-05-15 12:35:08 +0200 | mei | (~mei@user/mei) |
| 2024-05-15 12:32:44 +0200 | mei | (~mei@user/mei) (Remote host closed the connection) |
| 2024-05-15 12:25:48 +0200 | libertyprime | (~libertypr@118-92-68-68.dsl.dyn.ihug.co.nz) (Quit: leaving) |
| 2024-05-15 12:23:37 +0200 | xff0x | (~xff0x@125x103x176x34.ap125.ftth.ucom.ne.jp) (Ping timeout: 268 seconds) |
| 2024-05-15 12:23:24 +0200 | phma | (~phma@host-67-44-208-51.hnremote.net) |
| 2024-05-15 12:17:55 +0200 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2024-05-15 12:16:38 +0200 | p3n | (~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) |
| 2024-05-15 12:16:22 +0200 | p3n | (~p3n@217.198.124.246) (Ping timeout: 246 seconds) |
| 2024-05-15 12:08:30 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Ping timeout: 268 seconds) |
| 2024-05-15 12:06:30 +0200 | dezalator | (~dezalator@77-254-94-95.dynamic.inetia.pl) |
| 2024-05-15 12:00:02 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) |
| 2024-05-15 11:53:02 +0200 | phma | (~phma@host-67-44-208-11.hnremote.net) (Read error: Connection reset by peer) |
| 2024-05-15 11:47:54 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |