Newest at the top
| 2025-12-27 18:35:25 +0100 | <pie_> | *design out all the errors its designed to handle, fall back to remote external intervention for whatever else |
| 2025-12-27 18:34:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 18:34:54 +0100 | <pie_> | just remove all the errors? :P |
| 2025-12-27 18:34:47 +0100 | <pie_> | idk, what do they do in embedded space software or whatever |
| 2025-12-27 18:34:34 +0100 | <pie_> | i wouldnt mind if i could read up on a thorough discussion of these kinds of things |
| 2025-12-27 18:34:18 +0100 | <pie_> | what if i dont want my programs to crash? (put a restarting wrapper around it? - so like presumably whatever erlang does i guess?) |
| 2025-12-27 18:33:49 +0100 | wennefer0_______ | (~wennefer0@user/wennefer0) wennefer0 |
| 2025-12-27 18:31:52 +0100 | <pie_> | ok sure i guess some of the stuff you would start with is the difference between invalid programs, and runtime errors / that you want to fail fast to prevent invalid state propagation, .. |
| 2025-12-27 18:31:40 +0100 | <monochrom> | In many cases, there is a reasonable plan B. The details depends on the actual code and/or the actual specification. |
| 2025-12-27 18:30:52 +0100 | <pie_> | so like, what does "good error handling design" look like in software engineering? |
| 2025-12-27 18:30:32 +0100 | <pie_> | (alternatively, what do i read on this) |
| 2025-12-27 18:30:32 +0100 | <pie_> | but like how do you do stuff properly if you dont want your programs to just fail |
| 2025-12-27 18:30:32 +0100 | <pie_> | ok maybe today if i thought about it i could do a little better; just crash the program if you run into an issue (which is what happens when you dont catch an exception i guess) |
| 2025-12-27 18:30:32 +0100 | <pie_> | beyond the equivalent of catching an error and doing nothing with it or putting a todo there or something |
| 2025-12-27 18:30:32 +0100 | <pie_> | this is really basic but i never understood how to do error handling in software properly |
| 2025-12-27 18:30:17 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 18:29:50 +0100 | <haskellbridge> | <Liamzee> life is fun, now i'm deliberately trying to vibecode segfaults on a Apple Silicon Mac |
| 2025-12-27 18:21:09 +0100 | annamalai | (~annamalai@157.32.142.174) annamalai |
| 2025-12-27 18:20:50 +0100 | annamalai | (~annamalai@157.32.142.174) (Remote host closed the connection) |
| 2025-12-27 18:20:00 +0100 | annamalai | (~annamalai@157.32.142.174) annamalai |
| 2025-12-27 18:18:58 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 255 seconds) |
| 2025-12-27 18:12:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 18:11:16 +0100 | Everything | (~Everythin@172-232-54-192.ip.linodeusercontent.com) Everything |
| 2025-12-27 18:03:53 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-27 17:58:31 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 17:58:03 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 260 seconds) |
| 2025-12-27 17:57:06 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) m1dnight |
| 2025-12-27 17:50:20 +0100 | annamalai | (~annamalai@157.32.132.241) (Ping timeout: 245 seconds) |
| 2025-12-27 17:48:09 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-27 17:45:30 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) () |
| 2025-12-27 17:42:44 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 17:35:22 +0100 | ttybitnik | (~ttybitnik@user/wolper) ttybitnik |
| 2025-12-27 17:31:43 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 17:27:00 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 17:26:43 +0100 | sroso | (~sroso@user/SrOso) SrOso |
| 2025-12-27 17:23:04 +0100 | <ncf> | thanks |
| 2025-12-27 17:22:41 +0100 | <haskellbridge> | <Zemyla> https://duplode.github.io/posts/every-distributive-is-representable.html |
| 2025-12-27 17:20:37 +0100 | <haskellbridge> | <Zemyla> And that's basically the id function for a representable. |
| 2025-12-27 17:20:19 +0100 | <haskellbridge> | <Zemyla> You can use collect somehow to make g (g Any -> Any), then fmap unsafeCoerce to g (GRep g), which is safe because of parametricity. |
| 2025-12-27 17:19:18 +0100 | <haskellbridge> | <Zemyla> Actually, a "generic" Rep type is newtype GRep g = GRep { runGRep :: forall a. g a -> a } I remember reading an article about it. |
| 2025-12-27 17:17:00 +0100 | m1dnight | (~m1dnight@d8D861A17.access.telenet.be) (Ping timeout: 245 seconds) |
| 2025-12-27 17:16:10 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-12-27 17:13:15 +0100 | <ncf> | at least i don't think one can prove this "internally", as in write an instance Distributive g => Representable g |
| 2025-12-27 17:12:33 +0100 | <ncf> | edwardk: in Data.Distributive you wrote that "Categorically every Distributive functor is actually a right adjoint". do you have a proof of this somewhere? |
| 2025-12-27 17:11:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 17:05:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-27 17:05:00 +0100 | rainbyte | (~rainbyte@186.22.19.214) rainbyte |
| 2025-12-27 17:03:28 +0100 | rainbyte | (~rainbyte@186.22.19.214) (Read error: Connection reset by peer) |
| 2025-12-27 16:59:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 16:48:32 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |