Newest at the top
| 2024-04-30 21:14:50 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 21:14:33 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Quit: peterbecich) |
| 2024-04-30 21:13:55 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) |
| 2024-04-30 21:11:45 +0200 | xal | (~xal@mx1.xal.systems) |
| 2024-04-30 21:11:40 +0200 | rvalue- | rvalue |
| 2024-04-30 21:11:15 +0200 | <sm> | you want the friction of writing and updating tests to be as low as possible, obviously |
| 2024-04-30 21:10:21 +0200 | <sm> | probie I like to have test code as close to tested code as possible without obscuring the latter too much. These things are in tension, at least with typical tools. Currently I have three tiers: a little bit of doctest code in function haddocks; a bit more HUnit test code at the bottom of each module; and more extensive functional tests under test/* |
| 2024-04-30 21:10:01 +0200 | <tomsmeding> | but exactly what values are GC roots does not really reflect well to the haskell source world, I guess |
| 2024-04-30 21:09:29 +0200 | <tomsmeding> | I know pretty well from what points this data structure is reachable, so if there was some technique I could use to mark certain GC roots as "don't traverse from here, just assume this live", there's a decent chance I could make that work |
| 2024-04-30 21:09:09 +0200 | xal | (~xal@mx1.xal.systems) () |
| 2024-04-30 21:08:31 +0200 | rvalue | (~rvalue@user/rvalue) (Ping timeout: 256 seconds) |
| 2024-04-30 21:08:07 +0200 | <tomsmeding> | perhaps this is just something that would be hard to design an API for |
| 2024-04-30 21:07:35 +0200 | rvalue- | (~rvalue@user/rvalue) |
| 2024-04-30 21:07:10 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 21:07:04 +0200 | <tomsmeding> | there's literally an MVar there in the API in `ghc-compact` |
| 2024-04-30 21:06:51 +0200 | <tomsmeding> | so it's not really suitable for me |
| 2024-04-30 21:06:45 +0200 | <tomsmeding> | `compactAdd` takes a lock on the compact region |
| 2024-04-30 21:06:33 +0200 | <monochrom> | Does the current compact region already works under parallelism? |
| 2024-04-30 21:06:22 +0200 | infinity0 | (~infinity0@pwned.gg) |
| 2024-04-30 21:05:29 +0200 | <tomsmeding> | can I prevent that? |
| 2024-04-30 21:05:24 +0200 | <tomsmeding> | as-is, if I don't set the GC nursery size obscenely high (like 4GB), during construction phase the GC repeatedly traverses the whole thing uselessly, and ends up taking >60% of the total program runtime |
| 2024-04-30 21:05:23 +0200 | yin | (~yin@user/zero) (Ping timeout: 264 seconds) |
| 2024-04-30 21:04:44 +0200 | <tomsmeding> | then in the second phase of the program I consume this entire data structure, and afterwards the GC can collect it |
| 2024-04-30 21:04:28 +0200 | <tomsmeding> | the structure has lots of internal sharing |
| 2024-04-30 21:04:17 +0200 | <tomsmeding> | I have a program that, while in its "construction phase", builds up a large data structure in parallel; it's only added to, no part of the data structure can ever be collected by the GC in this program phase |
| 2024-04-30 21:04:16 +0200 | infinity0 | (~infinity0@pwned.gg) (Remote host closed the connection) |
| 2024-04-30 21:03:24 +0200 | <tomsmeding> | is t here a compact region like thing that you can add to in parallel? |
| 2024-04-30 21:02:36 +0200 | peterbecich | (~Thunderbi@47.229.123.186) |
| 2024-04-30 21:00:35 +0200 | yin | (~yin@user/zero) |
| 2024-04-30 20:59:47 +0200 | TheOneWhoFuncts | (~Thunderbi@14.98.244.193) (Client Quit) |
| 2024-04-30 20:58:43 +0200 | yin | (~yin@user/zero) (Ping timeout: 260 seconds) |
| 2024-04-30 20:58:43 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) (Ping timeout: 260 seconds) |
| 2024-04-30 20:58:30 +0200 | TheOneWhoFuncts | (~Thunderbi@14.98.244.193) |
| 2024-04-30 20:56:50 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-04-30 20:55:48 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-04-30 20:54:32 +0200 | peterbecich | (~Thunderbi@47.229.123.186) (Ping timeout: 268 seconds) |
| 2024-04-30 20:54:12 +0200 | tri | (~tri@ool-18bbef1a.static.optonline.net) |
| 2024-04-30 20:49:12 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) |
| 2024-04-30 20:47:42 +0200 | chiselfuse | (~chiselfus@user/chiselfuse) (Remote host closed the connection) |
| 2024-04-30 20:43:00 +0200 | iteratee | (~kyle@162.218.222.207) (Ping timeout: 252 seconds) |
| 2024-04-30 20:40:37 +0200 | <mauke> | return wraps the result of f |
| 2024-04-30 20:34:24 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Read error: Connection reset by peer) |
| 2024-04-30 20:34:19 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-04-30 20:32:37 +0200 | tomboy64 | (~tomboy64@user/tomboy64) |
| 2024-04-30 20:31:36 +0200 | <yin> | MTL: https://www.youtube.com/watch?v=6pDH66X3ClA |
| 2024-04-30 20:30:41 +0200 | <EvanR> | square peg square hole |
| 2024-04-30 20:30:10 +0200 | <lambdabot> | Maybe Int |
| 2024-04-30 20:30:09 +0200 | <EvanR> | :t (Just 'c' >>=) (return . ord) |
| 2024-04-30 20:29:21 +0200 | <lambdabot> | Monad m => Char -> m Int |
| 2024-04-30 20:29:20 +0200 | <EvanR> | :t (return . ord) |