Newest at the top
| 2025-11-14 21:51:23 +0100 | tomsmeding | forces fgarcia's thunk |
| 2025-11-14 21:51:12 +0100 | djspacewhale | (~djspacewh@user/djspacewhale) djspacewhale |
| 2025-11-14 21:49:04 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-11-14 21:48:48 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Read error: Connection reset by peer) |
| 2025-11-14 21:47:52 +0100 | fgarcia | causes a thunk |
| 2025-11-14 21:47:49 +0100 | fp | (~Thunderbi@2001-14ba-6e24-3000--19a.rev.dnainternet.fi) (Quit: fp) |
| 2025-11-14 21:44:51 +0100 | karenw | (~karenw@user/karenw) karenw |
| 2025-11-14 21:40:53 +0100 | deptype | (~deptype@2406:b400:3a:73c2:cdc4:150f:4f12:1dd1) |
| 2025-11-14 21:40:40 +0100 | deptype | (~deptype@2406:b400:3a:73c2:566e:3c9f:8ac3:f831) (Remote host closed the connection) |
| 2025-11-14 21:35:41 +0100 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2025-11-14 21:34:42 +0100 | eron | (~eron@187.56.155.181) (Quit: Client closed) |
| 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 |