Newest at the top
| 2026-05-25 18:51:53 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2026-05-25 18:51:53 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) terrorjack |
| 2026-05-25 18:50:42 +0000 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2026-05-25 18:48:27 +0000 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2026-05-25 18:48:19 +0000 | terrorjack | (~terrorjac@2a01:4f8:271:2d98::2) (Quit: The Lounge - https://thelounge.chat) |
| 2026-05-25 18:47:24 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-25 18:46:10 +0000 | gmg | (~user@user/gehmehgeh) (Ping timeout: 252 seconds) |
| 2026-05-25 18:43:31 +0000 | Inline | (~noOne@ipservice-092-208-182-236.092.208.pools.vodafone-ip.de) (Ping timeout: 264 seconds) |
| 2026-05-25 18:43:30 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |
| 2026-05-25 18:41:17 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-05-25 18:36:09 +0000 | merijn | (~merijn@62.45.136.136) (Ping timeout: 252 seconds) |
| 2026-05-25 18:35:44 +0000 | Jacqueline__ | (uid751191@id-751191.helmsley.irccloud.com) |
| 2026-05-25 18:33:23 +0000 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-05-25 18:30:38 +0000 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2026-05-25 18:29:24 +0000 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-05-25 18:24:24 +0000 | sm__ | (~sm@2601:644:8280:ec80:10de:e505:94cc:fb5a) (Client Quit) |
| 2026-05-25 18:20:50 +0000 | sm__ | (~sm@2601:644:8280:ec80:10de:e505:94cc:fb5a) |
| 2026-05-25 18:20:09 +0000 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2026-05-25 18:19:58 +0000 | Raito_Bezarius | (~Raito@libera/contributor/wireguard.tunneler.raito-bezarius) Raito_Bezarius |
| 2026-05-25 18:18:16 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-05-25 18:13:34 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-25 18:12:42 +0000 | sm__ | (~sm@2601:644:8280:ec80:c9b:ab8c:3e8e:da44) (Client Quit) |
| 2026-05-25 18:11:35 +0000 | sm__ | (~sm@2601:644:8280:ec80:c9b:ab8c:3e8e:da44) |
| 2026-05-25 18:09:29 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 245 seconds) |
| 2026-05-25 18:08:58 +0000 | <int-e> | tomsmeding: It's a bit more complicated than the basic WRC example because in the GHC runtime reading old values is generally okay. So to actually cause trouble it has to read not-yet-propagated ("future") values instead. |
| 2026-05-25 18:02:36 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-05-25 17:59:04 +0000 | Eoco | (~ian@128.101.131.218) Eoco |
| 2026-05-25 17:58:02 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-05-25 17:57:33 +0000 | sm__ | (~sm@2601:644:8280:ec80:f80f:4c71:49ff:3397) (Quit: sm__) |
| 2026-05-25 17:55:56 +0000 | <tomsmeding> | (now actually afk) |
| 2026-05-25 17:55:43 +0000 | <tomsmeding> | (funny sidenote: ARMv7 allowed this behaviour; an early spec for ARMv8 also did, but it was considered too hard to reason about and actual silicon manufacturers didn't end up using the flexibility, so the ARMv8 spec was revised to require causality) |
| 2026-05-25 17:55:36 +0000 | ricardomaps | (~ricardoma@179.154.171.223) |
| 2026-05-25 17:50:40 +0000 | tomsmeding | is afk for a while |
| 2026-05-25 17:50:37 +0000 | sm__ | (~sm@2601:644:8280:ec80:f80f:4c71:49ff:3397) |
| 2026-05-25 17:50:18 +0000 | <tomsmeding> | this stuff is way too subtle |
| 2026-05-25 17:50:06 +0000 | <int-e> | it was clearer in my head ;) |
| 2026-05-25 17:49:53 +0000 | <tomsmeding> | ah! There we go |
| 2026-05-25 17:48:53 +0000 | <int-e> | tomsmeding: https://paste.tomsmeding.com/IjEujBEA |
| 2026-05-25 17:48:07 +0000 | <tomsmeding> | because those two formulations sound too close in meaning to me :p |
| 2026-05-25 17:47:46 +0000 | <int-e> | aha! let me rephrase those... |
| 2026-05-25 17:47:06 +0000 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 242 seconds) |
| 2026-05-25 17:46:41 +0000 | <tomsmeding> | you're making a distinction between "evaluate t2 to r1" and "evaluate t2, get r1"? |
| 2026-05-25 17:46:23 +0000 | <int-e> | x is t1 |
| 2026-05-25 17:46:16 +0000 | <int-e> | the `1` value is `r1`; y is t2. |
| 2026-05-25 17:45:44 +0000 | <tomsmeding> | (if the read from y yielded 0, then x = 0 is perfectly fine and unsurprising) |
| 2026-05-25 17:45:16 +0000 | <tomsmeding> | (i.e. your analogue to "read y, yielding 1" is implicit, and I'd like it to be explicit) |
| 2026-05-25 17:45:15 +0000 | <int-e> | while if it read it from t1 then release ordering from thread 1 would ensure that tht data is there |
| 2026-05-25 17:44:54 +0000 | <int-e> | yeah. but it gets it from t2, written by thread 2, and only causality links it to the local heap data of thread 1 |
| 2026-05-25 17:44:14 +0000 | <tomsmeding> | int-e: still, the point here is that thread 3 does get the <IND r1>, right? If it doesn't, then it just evaluates t2 to r1 itself and that's that |
| 2026-05-25 17:43:10 +0000 | <tomsmeding> | nah |