Newest at the top
| 2025-02-01 23:45:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-01 23:42:36 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-01 23:41:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-01 23:38:18 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-01 23:30:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-01 23:29:33 +0100 | lisbeths | (~user@c-174-164-24-226.hsd1.wa.comcast.net) (Ping timeout: 245 seconds) |
| 2025-02-01 23:27:00 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-02-01 23:26:23 +0100 | <geekosaur> | (that said, what I asked for wasn't merely Haskell buit highly xmonad-specific which probably stacked the deck against it) |
| 2025-02-01 23:26:06 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Quit: peterbecich) |
| 2025-02-01 23:26:05 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-01 23:25:16 +0100 | <geekosaur> | (it = chatgpt) |
| 2025-02-01 23:25:07 +0100 | <geekosaur> | (I did try it once and it failed miserably) |
| 2025-02-01 23:24:53 +0100 | <geekosaur> | possibly someone should assemble one |
| 2025-02-01 23:24:44 +0100 | <geekosaur> | L29Ah, not that I'm aware of, just a lot of anecdata |
| 2025-02-01 23:23:52 +0100 | <sim590> | geekosaur: right. Got it. |
| 2025-02-01 23:23:33 +0100 | <sim590> | Leary: right. I see! |
| 2025-02-01 23:22:33 +0100 | <geekosaur> | so most stuff should be in IO and you dive into STM when needed |
| 2025-02-01 23:22:30 +0100 | <Leary> | sim590: I suggest `newtype YourAppT f a = YourAppT (ReaderT (TVar YourState) f a)`, so you can instantiate `f` at either `IO` or `STM` as convenient. In particular, writing STM-only functions in `YourAppT STM` means you can compose them without loss of atomicity. |
| 2025-02-01 23:22:16 +0100 | <geekosaur> | you don't want your STM transactions to be too big (and transactions can't be shared across threads for what I hope are obvious reasons) or they'll be more prone to deadlocking |
| 2025-02-01 23:22:02 +0100 | <sim590> | Thanks! |
| 2025-02-01 23:21:59 +0100 | <sim590> | OK. That makes sense. |
| 2025-02-01 23:21:00 +0100 | <geekosaur> | right, when you want to use STM, you use `atomically` which runs an STM transaction and gives you back an IO action |
| 2025-02-01 23:20:13 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2025-02-01 23:19:12 +0100 | <sim590> | OK. So, to resume, I would need to have my newtype as `ReaderT (TVar MyState) IO a` and I don't need to put STM anywhere in there. That's what was buggin gme. |
| 2025-02-01 23:18:36 +0100 | <L29Ah> | is there a dataset to benchmark LLM Haskell coding capability? |
| 2025-02-01 23:18:18 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 245 seconds) |
| 2025-02-01 23:16:36 +0100 | <geekosaur> | anyway you would use newTVarIO to get the TVar, then use atomically in IO to work with it |
| 2025-02-01 23:16:15 +0100 | <sim590> | Leary: Right. So, if I don't want to risk that, I should use TVar. |
| 2025-02-01 23:15:56 +0100 | connrs | (~connrs@user/connrs) (Read error: Connection reset by peer) |
| 2025-02-01 23:15:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-02-01 23:15:19 +0100 | <sim590> | need to* |
| 2025-02-01 23:15:09 +0100 | <sim590> | geekosaur: oh right. I actually thought to something close to that reasoning. I relized I didn't read to write the state anymore. |
| 2025-02-01 23:14:12 +0100 | <geekosaur> | also I'd note that since you don't need to switch MVars, you probably want to use ReaderT instead of StateT |
| 2025-02-01 23:14:05 +0100 | <Leary> | sim590: If you make a mistake with MVar---and the bar for correctness here is much higher than it looks due to pitfalls of exception handling---your program will be bogged down in deadlocks that are quite difficult to debug. |
| 2025-02-01 23:13:57 +0100 | <sim590> | Is it possible to not use it correctly? I saw readTVar, but also readTVarIO. I didn't see how I could put STM inside my newtype signature, so I was just thinking to use readTVarIO. Is that gonna play well with the features you just talked about for TVar ? |
| 2025-02-01 23:13:52 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) hgolden |
| 2025-02-01 23:12:15 +0100 | <geekosaur> | MVar requires you to make sure you do everything correctly, especially if you have multiple of them. TVar more or less handles this automatically, retrying transactions as needed. So it's less error-prone |
| 2025-02-01 23:12:10 +0100 | <sim590> | Context: MyState contains a Map of values that either concurrently called callbacks are gonna possibly modify in addition to some user's call to a a function on the main thread that would explicitly modify the state. |
| 2025-02-01 23:10:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-01 23:10:42 +0100 | hgolden | (~hgolden@2603:8000:9d00:3ed1:6ff3:8389:b901:6363) (Remote host closed the connection) |
| 2025-02-01 23:10:41 +0100 | <sim590> | I can make sure to access properly the data by doing `takeMVar` when I need it and `putMVar` when I'm finished modifying it. I have the impression that it is equivalent to using stm's `modifyTVar`. Am I mistaken? Why should I really avoid using MVar over TVar ? |
| 2025-02-01 23:10:39 +0100 | <sim590> | I'm realizing that I need to use a concurrent access capable datatype for the state of my application in order to modify/read the state on different threads. At first I had a new type around `StateT MyState IO a`. So I think I can change it to `StateT (MVar MyState) IO a`. But I read on stackoverflow that for updating data, I should use TVar instead, but I don't see why. If I understand correctly, |
| 2025-02-01 23:06:16 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) (Remote host closed the connection) |
| 2025-02-01 22:59:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-02-01 22:56:48 +0100 | connrs | (~connrs@user/connrs) connrs |
| 2025-02-01 22:55:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-02-01 22:53:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-01 22:49:54 +0100 | connrs | (~connrs@user/connrs) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-02-01 22:49:34 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-01 22:43:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |