2025/08/06

Newest at the top

2025-08-07 00:24:38 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds)
2025-08-07 00:23:43 +0200infinity0(~infinity0@pwned.gg) (Ping timeout: 245 seconds)
2025-08-07 00:21:26 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2025-08-07 00:19:45 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-08-07 00:18:39 +0200 <karenw> Ah, I was using allocaBytes
2025-08-07 00:17:29 +0200 <EvanR> allocaArray
2025-08-07 00:16:57 +0200 <EvanR> note if you were the one who created the array for temporary purposes, there's a "bracket" for that too
2025-08-07 00:16:18 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 252 seconds)
2025-08-07 00:14:25 +0200 <EvanR> this is what I gather from looking at the code for peekArray
2025-08-07 00:14:10 +0200 <EvanR> it seems to be the first thing, which means the array can go to hell
2025-08-07 00:14:08 +0200 <karenw> Yes, that's what I'm asking, I think. Is peekArray lazy or strict
2025-08-07 00:13:45 +0200 <EvanR> the critical thing to wonder about is if the list and the values are all constructed before peekArray finishes, or if it's doing some weird lazy I/O
2025-08-07 00:12:43 +0200 <karenw> So I can let the c memory get freed?
2025-08-07 00:12:05 +0200 <EvanR> that were marshalled from the FFI world
2025-08-07 00:11:47 +0200 <EvanR> it yields a haskell list of haskell values
2025-08-07 00:11:20 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-08-07 00:09:40 +0200 <karenw> Does peekArray copy the values to haskell-owned memory, or do I need to keep the c-owned memory around?
2025-08-07 00:09:09 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-08-07 00:05:30 +0200sp1ff````(~user@c-24-21-190-184.hsd1.wa.comcast.net) (Remote host closed the connection)
2025-08-07 00:04:17 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-08-07 00:02:28 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 245 seconds)
2025-08-06 23:55:18 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-08-06 23:53:21 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)
2025-08-06 23:49:50 +0200phma(~phma@2001:5b0:211f:e928:45c9:c5e:3037:5ac6)
2025-08-06 23:48:48 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-08-06 23:45:47 +0200phma(phma@2001:5b0:2144:2fc8:608e:cd2e:a6ba:e92f) (Read error: Connection reset by peer)
2025-08-06 23:38:57 +0200tromp(~textual@2001:1c00:3487:1b00:788c:1b3f:625a:cce3) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-08-06 23:38:14 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds)
2025-08-06 23:37:16 +0200weary-traveler(~user@user/user363627) user363627
2025-08-06 23:37:07 +0200phma(phma@2001:5b0:2144:2fc8:608e:cd2e:a6ba:e92f)
2025-08-06 23:37:06 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds)
2025-08-06 23:33:48 +0200phma(phma@2001:5b0:211f:bd18:75ac:c42:f158:ecd7) (Read error: Connection reset by peer)
2025-08-06 23:33:24 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-08-06 23:32:07 +0200trickard_trickard
2025-08-06 23:31:41 +0200 <mauke> karenw: looks plausible, at least
2025-08-06 23:30:21 +0200 <monochrom> I recently did a bracket inception. I had bracket (foo x) hClose, where foo x is itself a bracketOnError (bar y) close
2025-08-06 23:29:28 +0200 <karenw> So it overall looks like this? https://pastebin.com/FGwTHa8x
2025-08-06 23:29:07 +0200 <mauke> readFile "lol"
2025-08-06 23:28:39 +0200jmcantrell(~weechat@user/jmcantrell) (Ping timeout: 276 seconds)
2025-08-06 23:28:20 +0200 <monochrom> Oh it's always like `bracket (openFile filename ReadWriteMode) hClose (\h -> ...)`
2025-08-06 23:27:59 +0200 <mauke> withInstance x = bracket (createInstance x) destroyInstance
2025-08-06 23:27:36 +0200 <karenw> Hmm, `withInstance = bracket createInstance destroyInstance`, but `createInstance` needs an `instanceCreateInfo` argument too...
2025-08-06 23:26:25 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net)
2025-08-06 23:26:09 +0200Frostillicus(~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 248 seconds)
2025-08-06 23:26:06 +0200 <monochrom> The later actually spoiled some entitled millenials. Their code had a lot of openFile but never hClose. They were like "why unthreaded RTS doesn't work" as if it was not their fault.
2025-08-06 23:24:29 +0200 <monochrom> But I recognize that life is not always ideal. If your use sites can't use the bracket pattern, then explicit release is the next resort. The last resort is that, if you use the threaded runtime, GC is periodically run when idle, including finalizers.
2025-08-06 23:22:48 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds)
2025-08-06 23:22:04 +0200 <mauke> RAII is more flexible
2025-08-06 23:21:35 +0200 <monochrom> The bracket pattern is best because it is what C++ RAII dreams of. When execution leaves the scope, whether by "normal return" or "exception killed me", the release is done, you will not leak.
2025-08-06 23:20:35 +0200 <mauke> withFoo = bracket acquireFoo releaseFoo