2025/09/28

Newest at the top

2025-09-28 04:56:29 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 04:54:41 +0200elnegro(elnegro@r186-50-77-161.dialup.adsl.anteldata.net.uy) elnegro
2025-09-28 04:53:10 +0200remmie(ianremsen@tilde.team) (Ping timeout: 244 seconds)
2025-09-28 04:50:23 +0200td_(~td@i5387092C.versanet.de) td_
2025-09-28 04:48:07 +0200td_(~td@i53870915.versanet.de) (Ping timeout: 240 seconds)
2025-09-28 04:46:27 +0200ljdarj(~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 +0200xff0x(~xff0x@2405:6580:b080:900:6b5a:7de1:ba67:bc14) (Ping timeout: 250 seconds)
2025-09-28 04:45:37 +0200merijn(~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 +0200merijn(~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 +0200talismanick(~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 +0200Googulator17(~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu) (Quit: Client closed)
2025-09-28 04:35:39 +0200Googulator80(~Googulato@2a01-036d-0106-03fa-f110-0864-c42c-107f.pool6.digikabel.hu)
2025-09-28 04:32:33 +0200talismanick(~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 +0200trickard_(~trickard@cpe-50-98-47-163.wireline.com.au)
2025-09-28 04:29:44 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-09-28 04:28:14 +0200trickard(~trickard@cpe-50-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2025-09-28 04:27:41 +0200 <Leary> slondr: Close over a simple `IORef` instead? E.g. pass in a partially applied `mkCallBack :: IORef YourState -> CallBackType`.
2025-09-28 04:24:55 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 04:21:21 +0200remmie(ianremsen@tilde.team) remsense
2025-09-28 04:18:02 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-09-28 04:16:00 +0200 <slondr> My first thought was to use forkIO to spawn a separate thread for maintaining state in a simple call/response recursive function, then build my callback function as a closure over a channel to this thread. But that seems like it might be overkill
2025-09-28 04:14:52 +0200 <slondr> as in, I'm passing a callback function to a library, but I want my callback function to accumulate some context each time it's called
2025-09-28 04:14:50 +0200remmie(ianremsen@tilde.team) (Ping timeout: 248 seconds)
2025-09-28 04:14:23 +0200 <slondr> What's the best way to maintain/mutate state across calls of a function where I can't modify the function signature?
2025-09-28 04:13:15 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 04:10:16 +0200banner(~banner@1.41.210.25)
2025-09-28 04:07:13 +0200trickard_trickard
2025-09-28 04:05:33 +0200op_4(~tslil@user/op-4/x-9116473) op_4
2025-09-28 04:05:04 +0200op_4(~tslil@user/op-4/x-9116473) (Remote host closed the connection)
2025-09-28 04:02:25 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds)
2025-09-28 03:57:27 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 03:56:16 +0200vanishingideal(~vanishing@user/vanishingideal) vanishingideal
2025-09-28 03:51:04 +0200Tuplanolla(~Tuplanoll@91-159-187-167.elisa-laajakaista.fi) (Ping timeout: 255 seconds)
2025-09-28 03:50:11 +0200comonad(~comonad@p200300d02709a80002b1d060aa1cc9d9.dip0.t-ipconnect.de)
2025-09-28 03:50:05 +0200talismanick(~user@2601:644:937c:ed10::c8dc) talismanick
2025-09-28 03:48:27 +0200comonad(~comonad@p200300d027244d00b442e34853d3dae3.dip0.t-ipconnect.de) (Ping timeout: 250 seconds)
2025-09-28 03:46:31 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds)
2025-09-28 03:42:58 +0200talismanick(~user@2601:644:937c:ed10::c8dc) (Read error: Connection reset by peer)
2025-09-28 03:42:42 +0200arandombit(~arandombi@user/arandombit) arandombit
2025-09-28 03:41:39 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-09-28 03:35:41 +0200weary-traveler(~user@user/user363627) user363627
2025-09-28 03:30:53 +0200talismanick(~user@2601:644:937c:ed10::c8dc) talismanick