Newest at the top
2025-09-28 05:46:13 +0200 | <slondr> | indeed it did! now I can read and write to an IORef from within the library's invokation of the callback. this is awesome |
2025-09-28 05:45:42 +0200 | Googulator80 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) |
2025-09-28 05:45:33 +0200 | Googulator80 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-28 05:37:59 +0200 | trickard_ | trickard |
2025-09-28 05:35:25 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
2025-09-28 05:31:26 +0200 | <slondr> | Hey that may have worked |
2025-09-28 05:30:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 05:28:57 +0200 | xff0x | (~xff0x@2405:6580:b080:900:bd6b:8e9b:54f4:4d4b) |
2025-09-28 05:24:42 +0200 | Googulator80 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) |
2025-09-28 05:24:24 +0200 | Googulator80 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-28 05:20:00 +0200 | mrvdb | (~mrvdb@2001:19f0:5000:8582:5400:ff:fe07:3df5) mrvdb |
2025-09-28 05:19:56 +0200 | _0xa | (~user@user/0xa/x-3134607) _0xa |
2025-09-28 05:19:56 +0200 | _0xa | (~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) (Changing host) |
2025-09-28 05:19:56 +0200 | _0xa | (~user@2001:19f0:5001:2ba8:5400:1ff:feda:88fc) |
2025-09-28 05:19:43 +0200 | _0xa | (~user@user/0xa/x-3134607) (Ping timeout: 255 seconds) |
2025-09-28 05:19:27 +0200 | mrvdb | (~mrvdb@2001:19f0:5000:8582:5400:ff:fe07:3df5) (Ping timeout: 250 seconds) |
2025-09-28 05:19:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-09-28 05:14:33 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 05:10:54 +0200 | <slondr> | oh! if I partially-apply the function from within an IO context, I get a de-IO'd version of the function - maybe this is the key |
2025-09-28 05:10:20 +0200 | Axman6 | (~Axman6@user/axman6) Axman6 |
2025-09-28 05:06:53 +0200 | cyphase | (~cyphase@user/cyphase) cyphase |
2025-09-28 05:05:48 +0200 | <dcpagan> | I got a reduction stack overflow from type-level shenanigans. Wat do? |
2025-09-28 05:02:59 +0200 | cyphase_eviltwin | (~cyphase@user/cyphase) (Remote host closed the connection) |
2025-09-28 05:02:55 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-09-28 05:02:34 +0200 | elnegro | (elnegro@r186-50-77-161.dialup.adsl.anteldata.net.uy) (Remote host closed the connection) |
2025-09-28 05:01:30 +0200 | remmie | (ianremsen@tilde.team) remsense |
2025-09-28 04:56:29 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 04:54:41 +0200 | elnegro | (elnegro@r186-50-77-161.dialup.adsl.anteldata.net.uy) elnegro |
2025-09-28 04:53:10 +0200 | remmie | (ianremsen@tilde.team) (Ping timeout: 244 seconds) |
2025-09-28 04:50:23 +0200 | td_ | (~td@i5387092C.versanet.de) td_ |
2025-09-28 04:48:07 +0200 | td_ | (~td@i53870915.versanet.de) (Ping timeout: 240 seconds) |
2025-09-28 04:46:27 +0200 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
2025-09-28 04:45:53 +0200 | <slondr> | Hmm, I agree that this approach seems rather fundamentally flawed, but I feel at the whim of the library here sadly |
2025-09-28 04:45:39 +0200 | xff0x | (~xff0x@2405:6580:b080:900:6b5a:7de1:ba67:bc14) (Ping timeout: 250 seconds) |
2025-09-28 04:45:37 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
2025-09-28 04:45:36 +0200 | <dcpagan> | How do I safely decrement a type-level natural number? |
2025-09-28 04:45:08 +0200 | <Leary> | Not without `unsafePerformIO`. You probably need to change your approach. |
2025-09-28 04:40:41 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-28 04:39:23 +0200 | <slondr> | is there maybe a way to modify external state without it affecting the return value of the function? I suppose I could rebuild the callback function into something slightly different every time if so |
2025-09-28 04:37:56 +0200 | talismanick | (~user@2601:644:937c:ed10::c8dc) talismanick |
2025-09-28 04:37:43 +0200 | <slondr> | ah, ok |
2025-09-28 04:37:27 +0200 | <Leary> | If you're in a pure context, the function must do the same thing every time it's called; it can have no internal state. |
2025-09-28 04:37:18 +0200 | <Leary> | In a pure function? No, but in that case you can't do anything with channels either. |
2025-09-28 04:35:42 +0200 | Googulator17 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) (Quit: Client closed) |
2025-09-28 04:35:39 +0200 | Googulator80 | (~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) |
2025-09-28 04:32:33 +0200 | talismanick | (~user@2601:644:937c:ed10::c8dc) (Read error: Connection reset by peer) |
2025-09-28 04:32:22 +0200 | <slondr> | Hmm, can I reference IORefs in a non-IO function? |
2025-09-28 04:30:54 +0200 | trickard_ | (~trickard@cpe-50-98-47-163.wireline.com.au) |
2025-09-28 04:29:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
2025-09-28 04:28:14 +0200 | trickard | (~trickard@cpe-50-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |