Newest at the top
2025-08-07 00:24:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
2025-08-07 00:23:43 +0200 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 245 seconds) |
2025-08-07 00:21:26 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
2025-08-07 00:19:45 +0200 | merijn | (~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 +0200 | Frostillicus | (~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 +0200 | Frostillicus | (~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 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-08-07 00:05:30 +0200 | sp1ff```` | (~user@c-24-21-190-184.hsd1.wa.comcast.net) (Remote host closed the connection) |
2025-08-07 00:04:17 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-08-07 00:02:28 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 245 seconds) |
2025-08-06 23:55:18 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
2025-08-06 23:53:21 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-08-06 23:49:50 +0200 | phma | (~phma@2001:5b0:211f:e928:45c9:c5e:3037:5ac6) |
2025-08-06 23:48:48 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-08-06 23:45:47 +0200 | phma | (phma@2001:5b0:2144:2fc8:608e:cd2e:a6ba:e92f) (Read error: Connection reset by peer) |
2025-08-06 23:38:57 +0200 | tromp | (~textual@2001:1c00:3487:1b00:788c:1b3f:625a:cce3) (Quit: My iMac has gone to sleep. ZZZzzz…) |
2025-08-06 23:38:14 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-08-06 23:37:16 +0200 | weary-traveler | (~user@user/user363627) user363627 |
2025-08-06 23:37:07 +0200 | phma | (phma@2001:5b0:2144:2fc8:608e:cd2e:a6ba:e92f) |
2025-08-06 23:37:06 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) (Ping timeout: 276 seconds) |
2025-08-06 23:33:48 +0200 | phma | (phma@2001:5b0:211f:bd18:75ac:c42:f158:ecd7) (Read error: Connection reset by peer) |
2025-08-06 23:33:24 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-08-06 23:32:07 +0200 | trickard_ | 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 +0200 | jmcantrell | (~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 +0200 | Frostillicus | (~Frostilli@pool-71-174-119-69.bstnma.fios.verizon.net) |
2025-08-06 23:26:09 +0200 | Frostillicus | (~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 +0200 | merijn | (~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 |