Newest at the top
| 2025-06-24 10:56:03 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-06-24 10:51:15 +0200 | AlexNoo | (~AlexNoo@178.34.163.228) (Quit: Leaving) |
| 2025-06-24 10:49:22 +0200 | AlexZenon | (~alzenon@178.34.163.228) (Quit: ;-) |
| 2025-06-24 10:45:09 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-06-24 10:41:32 +0200 | jcarpenter2 | (~lol@96.78.87.197) |
| 2025-06-24 10:40:03 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b960:bc51:80a4:4f7b:b6fb) (Ping timeout: 276 seconds) |
| 2025-06-24 10:34:25 +0200 | soverysour | (~soverysou@user/soverysour) (Ping timeout: 248 seconds) |
| 2025-06-24 10:32:29 +0200 | trickard_ | trickard |
| 2025-06-24 10:30:00 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3605-68d5-9ce1-6c41-bae0-8a0f.rev.sfr.net) (Remote host closed the connection) |
| 2025-06-24 10:29:05 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-06-24 10:25:21 +0200 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
| 2025-06-24 10:24:20 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3605-68d5-9ce1-6c41-bae0-8a0f.rev.sfr.net) alexherbo2 |
| 2025-06-24 10:23:52 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3605-68d5-9ce1-6c41-bae0-8a0f.rev.sfr.net) (Remote host closed the connection) |
| 2025-06-24 10:20:43 +0200 | soverysour | (~soverysou@user/soverysour) soverysour |
| 2025-06-24 10:20:43 +0200 | soverysour | (~soverysou@84.232.150.142) (Changing host) |
| 2025-06-24 10:20:42 +0200 | soverysour | (~soverysou@84.232.150.142) |
| 2025-06-24 10:19:32 +0200 | prdak | (~Thunderbi@user/prdak) (Quit: prdak) |
| 2025-06-24 10:06:36 +0200 | <[exa]> | yeah that I don't need |
| 2025-06-24 10:06:33 +0200 | <tomsmeding> | but if you don't need that then it doesn't matter |
| 2025-06-24 10:06:26 +0200 | <tomsmeding> | well it means that you can't do the simultaneous STM waiting trick |
| 2025-06-24 10:06:22 +0200 | ft | (~ft@p3e9bc4ba.dip0.t-ipconnect.de) (Quit: leaving) |
| 2025-06-24 10:06:03 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
| 2025-06-24 10:05:51 +0200 | <[exa]> | on the other side folks have the choice to adapt it |
| 2025-06-24 10:05:51 +0200 | <tomsmeding> | make sense |
| 2025-06-24 10:05:35 +0200 | <[exa]> | like, the worker is a totally IO so doesn't make much sense to do anything else in there |
| 2025-06-24 10:05:20 +0200 | <tomsmeding> | [exa]: ActionT is just a ReaderT, so if it's ActionT IO then you can unlift it to normal IO |
| 2025-06-24 10:04:24 +0200 | <tomsmeding> | [exa]: so you choose the IO option? :P |
| 2025-06-24 10:02:37 +0200 | [exa] | hides back to his cellar |
| 2025-06-24 10:02:26 +0200 | [exa] | will send through a function that sets the mvar |
| 2025-06-24 10:02:18 +0200 | [exa] | suddenly becomes ultrafunctional |
| 2025-06-24 10:01:51 +0200 | trickard_ | (~trickard@cpe-52-98-47-163.wireline.com.au) |
| 2025-06-24 10:01:16 +0200 | <[exa]> | MVar it is. |
| 2025-06-24 10:01:14 +0200 | trickard | (~trickard@cpe-52-98-47-163.wireline.com.au) (Ping timeout: 245 seconds) |
| 2025-06-24 10:01:13 +0200 | <[exa]> | anyway there's probably scotty on the other side so I assume I might need to pull in ActionT, which ain't super cool |
| 2025-06-24 10:00:35 +0200 | <[exa]> | didn't notice that |
| 2025-06-24 10:00:33 +0200 | <[exa]> | ha, multiple results, good |
| 2025-06-24 09:59:11 +0200 | AlexNoo_ | AlexNoo |
| 2025-06-24 09:57:14 +0200 | prdak | (~Thunderbi@user/prdak) prdak |
| 2025-06-24 09:56:46 +0200 | <tomsmeding> | If IO, then you can't use it as part of a larger STM transaction, like Leary's usecase of waiting on multiple results simultaneously |
| 2025-06-24 09:56:28 +0200 | <tomsmeding> | what monad would that response-sending function run in? If STM then as a consumer you're limited to STM stuff, i.e. you can't send the response onto the network immediately |
| 2025-06-24 09:56:07 +0200 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
| 2025-06-24 09:55:49 +0200 | <[exa]> | :D |
| 2025-06-24 09:55:47 +0200 | <[exa]> | yeah, currently wondering what would that additional flexibility be |
| 2025-06-24 09:55:25 +0200 | <tomsmeding> | [exa]: I guess that depends on whether you will be making use of that additional flexibility |
| 2025-06-24 09:52:13 +0200 | <[exa]> | Leary: still kinda wondering about the design space; why not send through a response-sending function instead of the TMVar? |
| 2025-06-24 09:51:57 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
| 2025-06-24 09:50:10 +0200 | alexherbo2 | (~alexherbo@2a02-8440-3605-68d5-9ce1-6c41-bae0-8a0f.rev.sfr.net) alexherbo2 |
| 2025-06-24 09:48:09 +0200 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-06-24 09:43:36 +0200 | <tomsmeding> | the name is also not too shabby for such an example ("embedLogicT") |
| 2025-06-24 09:42:50 +0200 | <tomsmeding> | magic_rb: for similar results as monochrom's example but a little more complex, expand the LogicT newtype in the type of embedLogicT https://hackage-content.haskell.org/package/logict-0.8.2.0/docs/Control-Monad-Logic.html#v:embedLo… |