Newest at the top
| 2025-09-16 05:49:15 +0200 | <hololeap> | I'd never typed "haskell" into the search bar for podcasts before that |
| 2025-09-16 05:48:18 +0200 | <hololeap> | I recently discovered the Haskell Interlude podcast |
| 2025-09-16 05:48:18 +0200 | <StatisticalIndep> | I wonder if it’s possible to be very cheeky, and point a … uuum… completely unrelated (I swear) pointer to that same compact region, and write different values into variables, without telling the runtime. :D |
| 2025-09-16 05:45:06 +0200 | meinside | (uid24933@id-24933.helmsley.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-09-16 05:45:03 +0200 | Axman6 | (~Axman6@user/axman6) (Ping timeout: 240 seconds) |
| 2025-09-16 05:44:44 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-16 05:40:17 +0200 | <hololeap> | that makes sense |
| 2025-09-16 05:40:06 +0200 | <hololeap> | I see |
| 2025-09-16 05:39:57 +0200 | <geekosaur> | which makes them effectively immmutable |
| 2025-09-16 05:39:46 +0200 | <geekosaur> | I mean, they "do" but the contents of the IORef must also be in the same compact region |
| 2025-09-16 05:39:31 +0200 | <geekosaur> | not usefully |
| 2025-09-16 05:39:22 +0200 | <hololeap> | do they work with IORefs? |
| 2025-09-16 05:39:05 +0200 | <geekosaur> | in particular, once a pointer is found to point into a compact region, it's immediately dropped from consideration |
| 2025-09-16 05:38:08 +0200 | <geekosaur> | and the nature of that special casing is why they have so many restrictions, so they don't mess up GC too much (since the whole point of them is to get stuff out of GC's mitts) |
| 2025-09-16 05:37:29 +0200 | <geekosaur> | they work with anything but they're again special-cased |
| 2025-09-16 05:37:07 +0200 | <hololeap> | geekosaur: do compact regions only work with ByteArray# |
| 2025-09-16 05:35:55 +0200 | <hololeap> | it's cool they got it working as well as they did, but yeah, it seems like it was a huge hassle |
| 2025-09-16 05:32:13 +0200 | <StatisticalIndep> | hololeap: Wow, they practically went to managing their memory manually, but with the GC becoming more of a problem than a use. So as if one would write it in C, but with a GC ghost attacking at night and reaping souls. XD … Yeah, definitely not the route I want to go. XD |
| 2025-09-16 05:25:22 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Remote host closed the connection) |
| 2025-09-16 05:24:50 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-09-16 05:22:12 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2025-09-16 05:19:43 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-16 05:16:56 +0200 | <StatisticalIndep> | In any case, (mmapWithFilePtr "mm" ReadWrite Nothing $ \ (p, _) -> sequence_ $ zipWith (\ c i -> poke (plusPtr p i) c) "ME GO TOO FAR!" [0..]) works nicely enough. ;) (Yes, I know this will break with multi-byte chars.) |
| 2025-09-16 05:13:13 +0200 | <hololeap> | made me remember this: https://www.channable.com/tech/lessons-in-managing-haskell-memory |
| 2025-09-16 05:11:14 +0200 | aforemny_ | (~aforemny@i59F4C711.versanet.de) (Ping timeout: 256 seconds) |
| 2025-09-16 05:10:38 +0200 | aforemny | (~aforemny@2001:9e8:6cce:4800:55ab:c43e:17dc:ff6c) aforemny |
| 2025-09-16 05:08:40 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-09-16 05:08:33 +0200 | <geekosaur> | GC assumes pinned memory is an exception, not the rule |
| 2025-09-16 05:07:21 +0200 | <geekosaur> | we do actually have such a thing as pinned memory, but it's only applicable to ByteArray# and it's handled via an exception list (and I seem to recall hearing of programs that heavily use ByteStrings getting slow because the exception list isn't very efficient?) |
| 2025-09-16 05:05:50 +0200 | <StatisticalIndep> | geekosaur: Oh, I forgot about GC. Okay, that seals the deal. All those features are more valuable than having that bit of non-marshalled mapping elegance. |
| 2025-09-16 05:04:31 +0200 | <StatisticalIndep> | hololeap: It also makes sense from a standpoint of variables being constants in Haskell, and there hence being no such thing as an “insertion”. (The tree has to be reconstructed from the zipper instead.) |
| 2025-09-16 05:04:28 +0200 | <geekosaur> | and probably make it a lot more expensive, if it has to check if every pointer actually lives in the heap or not |
| 2025-09-16 05:04:25 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2025-09-16 05:04:25 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:21ee:ceac:8353:7a15) (Changing host) |
| 2025-09-16 05:04:25 +0200 | arandombit | (~arandombi@2603:7000:4600:ffbe:21ee:ceac:8353:7a15) |
| 2025-09-16 05:04:08 +0200 | <geekosaur> | hypothetically could be done. would really complicate GC, though |
| 2025-09-16 05:03:56 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-16 05:03:14 +0200 | <StatisticalIndep> | I just wish I could tell Haskell: to point every pointer to an Int, in e.g. a fixey list of Ints, to a pointer location in a block of mmapped data that contains unboxed ints in exactly the same format as GHC expects them. |
| 2025-09-16 05:01:51 +0200 | <hololeap> | makes sense that Map is a binary tree, given the (Ord k) constraint on most operations |
| 2025-09-16 05:01:15 +0200 | <StatisticalIndep> | Yep. |
| 2025-09-16 05:00:55 +0200 | <geekosaur> | which is another reason you must marshal/unmarshal, because it's asking far too much for other languages to have to figure out how Map is a size-balanced binary tree or Seq is a fingertree, etc. |
| 2025-09-16 04:59:48 +0200 | <StatisticalIndep> | Ah, yes, i remembered something like that! |
| 2025-09-16 04:59:35 +0200 | <geekosaur> | Maps are actually more complex than that: "The implementation of Map is based on size balanced binary trees (or trees of bounded balance)" (from the documentation) |
| 2025-09-16 04:58:50 +0200 | StatisticalIndep | (~Statistic@2a02:3035:666:b7d5:4e00:1517:7b0c:d0aa) |
| 2025-09-16 04:58:38 +0200 | StatisticalIndep | (~Statistic@2a02:3035:666:b7d5:4e00:1517:7b0c:d0aa) (Quit: Client closed) |
| 2025-09-16 04:58:26 +0200 | <StatisticalIndep> | I probably expect a Map to internally be stored as an array of pointers, with pointers to keys and to values being interleaved? Or something a bit smarter with fewer pointers. ;) |
| 2025-09-16 04:56:28 +0200 | <geekosaur> | (if you don't have optimization enabled, even the strict values have them, but optimization unboxes whenever possible) |
| 2025-09-16 04:55:56 +0200 | <geekosaur> | right, and all those pointers introduce places where a value could be computed lazily |
| 2025-09-16 04:55:22 +0200 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 256 seconds) |
| 2025-09-16 04:54:59 +0200 | <geekosaur> | *Data.Map.Map |