Logs: freenode/#haskell
| 2021-03-08 12:37:45 | → | Suigintou joins (~Suigintou@178.239.168.171) |
| 2021-03-08 12:38:22 | → | berberman joins (~berberman@unaffiliated/berberman) |
| 2021-03-08 12:39:15 | × | berberman quits (~berberman@unaffiliated/berberman) (Max SendQ exceeded) |
| 2021-03-08 12:40:18 | → | tinhatcat joins (~tsranso@108-91-101-161.lightspeed.gnvlsc.sbcglobal.net) |
| 2021-03-08 12:40:51 | → | machinedgod joins (~machinedg@135-23-192-217.cpe.pppoe.ca) |
| 2021-03-08 12:41:09 | → | berberman joins (~berberman@unaffiliated/berberman) |
| 2021-03-08 12:43:57 | × | tinhatcat quits (~tsranso@108-91-101-161.lightspeed.gnvlsc.sbcglobal.net) (Client Quit) |
| 2021-03-08 12:47:59 | → | mayleesia joins (4e37fceb@dynamic-078-055-252-235.78.55.pool.telefonica.de) |
| 2021-03-08 12:52:13 | → | chisui joins (5882391a@mue-88-130-57-026.dsl.tropolys.de) |
| 2021-03-08 12:53:20 | × | usr25 quits (~usr25@unaffiliated/usr25) (Quit: Leaving) |
| 2021-03-08 12:54:19 | → | nineonine joins (~nineonine@2604:3d08:7785:9600:d8fe:8116:376f:ddd2) |
| 2021-03-08 12:55:29 | → | m2rrorbird joins (~dwsjeid91@m83-187-177-242.cust.tele2.se) |
| 2021-03-08 12:55:40 | × | mirrorbird quits (~dwsjeid91@2a00:801:42b:7529:141c:bbbc:ad74:9e2c) (Remote host closed the connection) |
| 2021-03-08 12:56:07 | × | kafl quits (~kafl@unaffiliated/kafl) (Ping timeout: 272 seconds) |
| 2021-03-08 12:56:25 | × | Pickchea quits (~private@unaffiliated/pickchea) (Ping timeout: 256 seconds) |
| 2021-03-08 12:58:02 | <chisui> | Hey, is there an alternative to `modifyIORef'` where the modifying function returns an `IO a`? |
| 2021-03-08 13:00:02 | × | nineonine quits (~nineonine@2604:3d08:7785:9600:d8fe:8116:376f:ddd2) (Ping timeout: 264 seconds) |
| 2021-03-08 13:02:16 | <merijn> | chisui: That'd lead to race conditions, though |
| 2021-03-08 13:02:32 | <merijn> | chisui: I mean you can just "readIORef, do stuff, writeIORef" |
| 2021-03-08 13:02:39 | <lemmih> | chisui: No but you can write it yourself. It cannot be atomic, though. |
| 2021-03-08 13:03:02 | → | urodna joins (~urodna@unaffiliated/urodna) |
| 2021-03-08 13:03:32 | <chisui> | lemmih: what if I need somthing that is atomic? |
| 2021-03-08 13:03:42 | <merijn> | chisui: "don't use IORef" |
| 2021-03-08 13:03:45 | <lemmih> | chisui: Use an MVar. |
| 2021-03-08 13:03:49 | <merijn> | Or TVar |
| 2021-03-08 13:03:57 | → | ADG1089__ joins (~aditya@223.226.235.12) |
| 2021-03-08 13:04:03 | → | Aphex joins (uid70120@gateway/web/irccloud.com/x-rbipwsxddmowtxzn) |
| 2021-03-08 13:04:05 | <chisui> | Ah, Thanks lemmih, merjin |
| 2021-03-08 13:04:18 | <chisui> | *merijn |
| 2021-03-08 13:04:59 | <hpc> | and to answer the natural next question, MVar/TVar depends on if you want to lock or retry when threads are going after the same resource |
| 2021-03-08 13:05:08 | <hpc> | MVar locks, TVar uses transactions |
| 2021-03-08 13:06:02 | <merijn> | tbh, TVar locks too, but differently ;) |
| 2021-03-08 13:06:07 | <hpc> | personally, whenever i need to use an IORef i automatically use MVar instead |
| 2021-03-08 13:06:10 | <hpc> | heh |
| 2021-03-08 13:06:31 | <hpc> | even in single-threaded applications |
| 2021-03-08 13:06:38 | <merijn> | Yeah, IORef's are risky business |
| 2021-03-08 13:07:03 | → | jacks2 joins (~bc8134e3@217.29.117.252) |
| 2021-03-08 13:07:06 | <chisui> | Does IORef have any significant performance advantage above MVar? |
| 2021-03-08 13:07:09 | <merijn> | hpc: No clue, but tbh you shouldn't really use the single threaded runtime anyway, too many broken corner cases |
| 2021-03-08 13:07:16 | → | geekosaur joins (82650c7a@130.101.12.122) |
| 2021-03-08 13:07:16 | <merijn> | chisui: Define significant |
| 2021-03-08 13:07:33 | <merijn> | What are you doing and why do you think the MVar overhead might be a bottle neck? |
| 2021-03-08 13:07:40 | <hpc> | merijn: oh, i don't mean the single-threaded RTS, i just mean when i know my code doesn't have more than one thread |
| 2021-03-08 13:07:59 | <merijn> | hpc: The multi-threaded RTS has to lock anyway, no? |
| 2021-03-08 13:08:14 | <merijn> | hpc: Or do you expect it to detect and special case the single thread scenario? |
| 2021-03-08 13:08:30 | <chisui> | merijn I writing logic solver and the Cells are currently IORefs |
| 2021-03-08 13:08:58 | <hpc> | maybe you're misparsing what i wrote? "even when my code doesn't use threads, i use MVar instead of IORef" |
| 2021-03-08 13:09:17 | <hpc> | (not "TVar locks too even in single-threaded applications") |
| 2021-03-08 13:09:22 | <merijn> | hpc: Ah! |
| 2021-03-08 13:09:49 | <hpc> | clearly irc needs threaded conversations :P |
| 2021-03-08 13:10:14 | <merijn> | ugh, no |
| 2021-03-08 13:11:28 | <jacks2> | what about atomicModifyIORef? |
| 2021-03-08 13:11:43 | <merijn> | jacks2: That doesn't allow IO modification |
| 2021-03-08 13:11:56 | <jacks2> | what do you mean? |
| 2021-03-08 13:12:03 | <jacks2> | :t atomicModifyIORef |
| 2021-03-08 13:12:05 | <lambdabot> | error: Variable not in scope: atomicModifyIORef |
| 2021-03-08 13:12:14 | <jacks2> | atomicModifyIORef :: IORef a -> (a -> (a, b)) -> IO b |
| 2021-03-08 13:12:28 | <merijn> | jacks2: The original question was how to use 'a -> IO a' for modifyIORef |
| 2021-03-08 13:12:31 | <hpc> | you have the power of (a -> a) |
| 2021-03-08 13:12:35 | <merijn> | Rather theen "a -> a" |
| 2021-03-08 13:13:23 | <jacks2> | so how does STM help here? you can't use IO in STM transaction either |
| 2021-03-08 13:15:17 | <chisui> | The long and short is, I only want to modify a Ref if it satisfies a certain condition. The modification requires the value of other References though. I don't need transactions |
| 2021-03-08 13:15:20 | → | LKoen_ joins (~LKoen@194.250.88.92.rev.sfr.net) |
| 2021-03-08 13:16:37 | <merijn> | jacks2: The answer was "you can't use IORef" |
| 2021-03-08 13:16:49 | <merijn> | jacks2: So use TVar/MVar instead of IORef |
| 2021-03-08 13:17:00 | <merijn> | chisui: Sounds like you do |
| 2021-03-08 13:17:27 | <chisui> | merijn: how so? |
| 2021-03-08 13:18:04 | <merijn> | You said you needed something atomic for updating IORefs |
| 2021-03-08 13:18:28 | <merijn> | If your atomic thing depends on the value of 1 or more other references, the only way to do that atomically is via transactions |
| 2021-03-08 13:19:06 | <jacks2> | merijn, right, but modifyTVar also accepts (a -> a). modifyMVar accepts (a -> IO a), if that is really needed |
| 2021-03-08 13:19:18 | <merijn> | jacks2: You don't use modifyTVar |
| 2021-03-08 13:19:28 | <merijn> | jacks2: You can "read, compute, write" a TVar atomically |
| 2021-03-08 13:19:38 | <merijn> | Like, that's the entire point of STM :p |
| 2021-03-08 13:20:24 | <chisui> | merijn: It's a propagator network. It's ok if the values from other Cells are old but the value of the current one has to be current. |
| 2021-03-08 13:20:51 | <chisui> | *the value of the one being modified has to be current |
| 2021-03-08 13:21:06 | <jacks2> | merijn, we obviously some trouble communicating what me mean in here. you said " <merijn> jacks2: The original question was how to use 'a -> IO a' for modifyIORef" "<merijn> Rather theen "a -> a"" |
| 2021-03-08 13:21:18 | <jacks2> | TVar doesn't let you do that, just like IORef doesn't |
| 2021-03-08 13:21:30 | → | astroanax joins (astroanax@gateway/shell/ircnow/x-zpthsvfoipdugkpc) |
| 2021-03-08 13:21:35 | <jacks2> | so how is it an improvement? |
| 2021-03-08 13:21:53 | <merijn> | jacks2: Both me and Lemmih remarked that you can do "read, compute, write" with IORef, but it is not atomic |
| 2021-03-08 13:22:07 | <merijn> | The follow up was "i need atomic", followed by "then you need TVar" |
| 2021-03-08 13:22:30 | <jacks2> | how can you do that atomically with TVar, when you can't use IO in transaction? |
| 2021-03-08 13:22:31 | <merijn> | jacks2: You seem overfocussed on "modify<X>Var" over "what type do you need for the desired semantics" |
| 2021-03-08 13:23:00 | <merijn> | Anyway, this is slowly turning in an entire orthogonal discussion from chisui's problem |
| 2021-03-08 13:23:29 | <merijn> | chisui: But then you can easily solve things, no? |
| 2021-03-08 13:24:00 | <merijn> | chisui: construct "IO a" that reads all old cells, then "atomicModifyIORef" the current cell based on the (possibly) old reads from old cells |
| 2021-03-08 13:24:02 | <chisui> | My question is answered :D I'll use MVars and will be done with it |
| 2021-03-08 13:24:19 | <jacks2> | merijn, let me put this as plainly as possible, what does TVar offer over atomicModifyIORef in this situation? absolutely nothing |
| 2021-03-08 13:24:43 | <merijn> | chisui: "readOldCells :: IO Values" "updateFun :: Values -> (Values, ())" |
| 2021-03-08 13:24:54 | <merijn> | jacks2: The ability to read other references atomically during an update |
| 2021-03-08 13:25:02 | × | stree quits (~stree@68.36.8.116) (Ping timeout: 260 seconds) |
| 2021-03-08 13:25:07 | → | Yumasi joins (~guillaume@2a01cb0506313c00e14be01ac4a050f7.ipv6.abo.wanadoo.fr) |
| 2021-03-08 13:25:17 | <jacks2> | "other references" wasn't part of the question |
| 2021-03-08 13:25:38 | <chisui> | merijn: this way I would have to evaluate `readOldCells` regardless of whether or not I need to actually update the current cell through |
| 2021-03-08 13:26:00 | <merijn> | chisui: eh, "updateFun :: Values -> Foo -> (Foo, ())" and then "readOldCells >>= \v -> atomicModifyIORef (updateFun v)" |
| 2021-03-08 13:27:02 | <chisui> | merijn: That would still require readOldCells to always be executed. |
| 2021-03-08 13:27:14 | <merijn> | jacks2: So? It was mentioned later. People are not robots and ask wrong, incomplete questions and expect people to extrapolate from context, rather than acting like genies and answering questions "as asked", rahter then "as intended" |
| 2021-03-08 13:27:35 | <merijn> | chisui: tbh, the atomic STM approach is probably cheaper than MVar if you don't expect many conflicting updates to the same cells |
| 2021-03-08 13:28:03 | <merijn> | chisui: STM uses optimistic locking so uncontested updates have almost no overhead |
| 2021-03-08 13:28:27 | <merijn> | chisui: But that depends on many conflicting updates you expect to happen |
All times are in UTC.