Newest at the top
| 2025-11-14 21:29:53 +0100 | <haskellbridge> | <Zemyla> Yeah, it'd definitely be a different language, one more like Rust. |
| 2025-11-14 21:20:50 +0100 | deptype | (~deptype@2406:b400:3a:73c2:566e:3c9f:8ac3:f831) |
| 2025-11-14 21:20:35 +0100 | deptype | (~deptype@2406:b400:3a:73c2:10ea:4f19:b27b:3bbc) (Remote host closed the connection) |
| 2025-11-14 21:16:13 +0100 | Square3 | (~Square@user/square) (Ping timeout: 264 seconds) |
| 2025-11-14 21:16:06 +0100 | polykernel_ | polykernel |
| 2025-11-14 21:16:06 +0100 | polykernel | (~polykerne@user/polykernel) (Ping timeout: 256 seconds) |
| 2025-11-14 21:14:12 +0100 | shr\ke | (~shrike@user/shrke:31298) shr\ke |
| 2025-11-14 21:14:12 +0100 | shr\ke | (~shrike@user/paxhumana) (Changing host) |
| 2025-11-14 21:14:12 +0100 | shr\ke | (~shrike@user/paxhumana) paxhumana |
| 2025-11-14 21:13:53 +0100 | polykernel_ | (~polykerne@user/polykernel) polykernel |
| 2025-11-14 21:13:03 +0100 | Lycurgus | (~juan@user/Lycurgus) (Quit: alsoknownas.renjuan.org ( juan@acm.org )) |
| 2025-11-14 21:11:47 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 21:08:42 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2025-11-14 21:07:10 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 21:06:47 +0100 | <EvanR> | maximum number of elements submitted in the request |
| 2025-11-14 21:06:31 +0100 | fp | (~Thunderbi@2001-14ba-6e24-3000--19a.rev.dnainternet.fi) fp |
| 2025-11-14 21:06:26 +0100 | <EvanR> | maximum request body, maximum numeric field values, assuming the body can be decoded, which itself has limits baked into the parser |
| 2025-11-14 21:05:20 +0100 | <EvanR> | it sounds infeasible until you think about how a web service handler is defacto designed with a whole page of limits and guardrails |
| 2025-11-14 21:04:12 +0100 | <EvanR> | a simple version would simply not run a program known to need X memory if you can't reserve X memory at startup |
| 2025-11-14 21:03:32 +0100 | <EvanR> | tracking memory usage in the type system is a possibility. Probably not in haskell which relies heavily on allocating willy nilly |
| 2025-11-14 21:00:12 +0100 | deptype | (~deptype@2406:b400:3a:73c2:10ea:4f19:b27b:3bbc) |
| 2025-11-14 20:58:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-11-14 20:57:57 +0100 | deptype__ | (~deptype@124.123.128.236) (Ping timeout: 256 seconds) |
| 2025-11-14 20:56:19 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) (Ping timeout: 260 seconds) |
| 2025-11-14 20:55:44 +0100 | ZLima12_ | (~zlima12@user/meow/ZLima12) ZLima12 |
| 2025-11-14 20:53:27 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-11-14 20:53:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-11-14 20:52:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-11-14 20:44:07 +0100 | jmcantrell | (~weechat@user/jmcantrell) (Ping timeout: 264 seconds) |
| 2025-11-14 20:40:31 +0100 | mreh | (~matthew@host86-146-25-125.range86-146.btcentralplus.com) (Quit: Lost terminal) |
| 2025-11-14 20:39:43 +0100 | eron | (~eron@187.56.155.181) lidenbrock |
| 2025-11-14 20:39:10 +0100 | <haskellbridge> | <loonycyborg> But things like integer overflow and divide by zero are deterministic and can be considered separate form of resulting value. |
| 2025-11-14 20:38:21 +0100 | <haskellbridge> | <loonycyborg> And trying to handle them purely would violate all sort of things like referential transparency :P |
| 2025-11-14 20:36:24 +0100 | <haskellbridge> | <loonycyborg> Some of them most definitely aren't |
| 2025-11-14 20:34:03 +0100 | <davean> | Lots of quality software handles these signals. Thats not the point though, the point is that exceptions in pure code *are not deterministic* |
| 2025-11-14 20:32:46 +0100 | <davean> | Actually there is a clear signal if you don't have overcommit, you get an alloc fail |
| 2025-11-14 20:32:18 +0100 | <haskellbridge> | <loonycyborg> In practice any OOM handlers don't get much workout either. If PC runs out of memory OS either moves things to swapfile or kills some processes with signal that can't be trapped |
| 2025-11-14 20:31:30 +0100 | notzmv | (~umar@user/notzmv) (Ping timeout: 244 seconds) |
| 2025-11-14 20:27:49 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-11-14 20:27:33 +0100 | <haskellbridge> | <loonycyborg> Handling out-of-memory conditions is notoriously hard problem. In this OOM state you can't rely on any functions that allocate more memory for any reason. |
| 2025-11-14 20:25:24 +0100 | haltingsolver | (~cmo@2604:3d09:207f:8000::d1dc) (Ping timeout: 260 seconds) |
| 2025-11-14 20:25:21 +0100 | <haskellbridge> | <loonycyborg> Unless runtime handles it transparently for the program. |
| 2025-11-14 20:24:51 +0100 | <haskellbridge> | <loonycyborg> This will have to be done in IO monad in any case. |
| 2025-11-14 20:21:55 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2025-11-14 20:21:40 +0100 | humasect_ | (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2025-11-14 20:18:38 +0100 | Square3 | (~Square@user/square) Square |
| 2025-11-14 20:15:45 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
| 2025-11-14 20:14:16 +0100 | <davean> | I mean you can see it failed, free memory, and then try again |
| 2025-11-14 20:12:43 +0100 | <haskellbridge> | <loonycyborg> I guess we could track memory as extra value(s) and make things pure that way but that would be just excessively complex :P |
| 2025-11-14 20:10:15 +0100 | <haskellbridge> | <loonycyborg> while memory overflow handling depends on other parameters that we don't track so it cannot ever be pure |