Newest at the top
| 2026-01-03 19:33:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-01-03 19:32:14 +0100 | Inline | (~User@cgn-195-14-221-74.nc.de) Inline |
| 2026-01-03 19:29:57 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2026-01-03 19:28:36 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-03 19:20:16 +0100 | wennefer0 | (~wennefer0@user/wennefer0) (Client Quit) |
| 2026-01-03 19:18:38 +0100 | wennefer0 | (~wennefer0@user/wennefer0) wennefer0 |
| 2026-01-03 19:17:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-01-03 19:12:52 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-03 19:09:40 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-01-03 19:08:03 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
| 2026-01-03 19:05:41 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-01-03 19:05:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-03 19:01:50 +0100 | wennefer0 | (~wennefer0@user/wennefer0) (Client Quit) |
| 2026-01-03 19:00:56 +0100 | wennefer0 | (~wennefer0@user/wennefer0) wennefer0 |
| 2026-01-03 18:57:15 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 240 seconds) |
| 2026-01-03 18:57:00 +0100 | wennefer0 | (~wennefer0@user/wennefer0) (Client Quit) |
| 2026-01-03 18:56:21 +0100 | wennefer0 | (~wennefer0@user/wennefer0) wennefer0 |
| 2026-01-03 18:54:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2026-01-03 18:52:16 +0100 | <EvanR> | who would use UnsafeMkChunk512 irresponsibly when it says Unsafe all over it?? xD |
| 2026-01-03 18:50:16 +0100 | <Leary> | That's not extra paranoia, that's the basic level. |
| 2026-01-03 18:49:35 +0100 | <EvanR> | for extra paranoia don't export UnsafeMkChunk512 at least in a public API |
| 2026-01-03 18:49:22 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-01-03 18:48:39 +0100 | <EvanR> | then internal code only uses UnsafeMkChunk512 when it is definitely the case that the chunk has that length. Parsers bear a lot of burden |
| 2026-01-03 18:47:55 +0100 | merijn | (~merijn@62.45.136.136) (Ping timeout: 240 seconds) |
| 2026-01-03 18:46:38 +0100 | <Leary> | Yes, something like `newtype Chunk512 = UnsafeMkChunk512 Text; parseChunk512 :: [Char] -> Maybe (Chunk512, [Char])`. |
| 2026-01-03 18:44:46 +0100 | <Milan_Vanca> | Leary: Hmm not sure if I want to rewrite my algo now.. But I might try it later when I am bored. So basically you would "pad" only when last block is not 512 and in moment you parse it to some datatype? |
| 2026-01-03 18:43:32 +0100 | <EvanR> | but shows how hard it can be to verify code even when the language forces you to think about the cases |
| 2026-01-03 18:43:27 +0100 | merijn | (~merijn@62.45.136.136) merijn |
| 2026-01-03 18:43:09 +0100 | <EvanR> | this was very rare which is good |
| 2026-01-03 18:42:45 +0100 | wennefer0 | (~wennefer0@user/wennefer0) (Client Quit) |
| 2026-01-03 18:42:28 +0100 | <EvanR> | ... no |
| 2026-01-03 18:42:27 +0100 | <Milan_Vanca> | EvanR: SO internal GHC error? |
| 2026-01-03 18:42:08 +0100 | <Milan_Vanca> | EvanR: Was the error *** Exception: Prelude.head: empty list ?? :D Just kidding :D |
| 2026-01-03 18:42:03 +0100 | ljdarj1 | ljdarj |
| 2026-01-03 18:42:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
| 2026-01-03 18:41:55 +0100 | wennefer0 | (~wennefer0@user/wennefer0) wennefer0 |
| 2026-01-03 18:40:40 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2026-01-03 18:40:16 +0100 | <EvanR> | very sad |
| 2026-01-03 18:40:15 +0100 | <Leary> | Milan_Vanca: I would not pad the list, but parse fixed-size chunks from the list into a (dense) bespoke type with your invariant. That type would then have fast, safe operations written in terms of unsafe or partial functions. |
| 2026-01-03 18:40:08 +0100 | <EvanR> | GHC has crashed on my with "the impossible happened" xD |
| 2026-01-03 18:39:51 +0100 | <Milan_Vanca> | Leary: Oookey I can see that.. I will try to document "imposible" cases |
| 2026-01-03 18:39:35 +0100 | <EvanR> | also Leary is also right |
| 2026-01-03 18:38:41 +0100 | <EvanR> | just trace backwards where this nothing might have come from and see that it is ... nowhere |
| 2026-01-03 18:38:36 +0100 | <Milan_Vanca> | EvanR: :( So true... My day to day job is with these dynamic languages. |
| 2026-01-03 18:38:31 +0100 | wennefer0 | (~wennefer0@user/wennefer0) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2026-01-03 18:38:22 +0100 | <EvanR> | since you're dealing with a very specific algorithm, it is possible and somebody has probably done it 1000 times |
| 2026-01-03 18:37:28 +0100 | <Milan_Vanca> | EvanR: This idea of proofing is interesting, but I am not proficient at math and cannot even imagine how could I proof that something will or won't happen. However I have a strong gut feeling :D |
| 2026-01-03 18:37:25 +0100 | <Leary> | The problem with "this case is impossible anyway" is that you can be wrong, or code elsewhere can change that breaks it. When that happens, you will really want to see a runtime error that points precisely to the code that threw it, not a "*** Exception: Maybe.fromJust: Nothing" which could have come from anywhere. |
| 2026-01-03 18:37:02 +0100 | <EvanR> | and somehow runs the world |
| 2026-01-03 18:36:51 +0100 | <EvanR> | it sounds scary until you realize every line of dynamically typed code is using this mentality |