Newest at the top
| 2025-12-27 20:50:31 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 20:49:18 +0100 | morj | (~morj@user/morj) (Quit: Konversation terminated!) |
| 2025-12-27 20:48:47 +0100 | lockna | (~lockna@193-81-168-132.hdsl.highway.telekom.at) lockna |
| 2025-12-27 20:45:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 20:41:17 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2025-12-27 20:40:47 +0100 | morj | (~morj@user/morj) morj |
| 2025-12-27 20:35:40 +0100 | Lord_of_Life_ | Lord_of_Life |
| 2025-12-27 20:35:21 +0100 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 250 seconds) |
| 2025-12-27 20:34:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-27 20:34:22 +0100 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2025-12-27 20:30:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 20:27:19 +0100 | <pie_> | <geenvoud> pie_: that'll be a certain westley weimer https://dl.acm.org/doi/10.1145/1330017.1330019 |
| 2025-12-27 20:25:22 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2025-12-27 20:22:00 +0100 | <pie_> | i dont suppose anyone knows who this is https://www.youtube.com/watch?v=NfXt_Eb0ZU8 |
| 2025-12-27 20:18:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 20:14:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 20:06:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-27 20:00:25 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:59:04 +0100 | lockna_ | (~lockna@193-81-168-132.hdsl.highway.telekom.at) (Remote host closed the connection) |
| 2025-12-27 19:49:29 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-12-27 19:49:07 +0100 | araujo | (~araujo@216.73.163.51) (Quit: araujo) |
| 2025-12-27 19:44:46 +0100 | ystael | (~ystael@user/ystael) ystael |
| 2025-12-27 19:44:39 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:41:11 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-12-27 19:39:53 +0100 | ss4 | (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds) |
| 2025-12-27 19:38:25 +0100 | ystael | (~ystael@user/ystael) (Ping timeout: 264 seconds) |
| 2025-12-27 19:37:25 +0100 | comonad | (~comonad@p200300d02720e400847046dc37dbdd66.dip0.t-ipconnect.de) (Quit: WeeChat 4.7.0-dev) |
| 2025-12-27 19:36:28 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-12-27 19:34:02 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 256 seconds) |
| 2025-12-27 19:29:01 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:24:40 +0100 | <sm> | it is the best exemplar of the "monitor subsystems and restart them when they fail" strategy |
| 2025-12-27 19:22:27 +0100 | <sm> | also, Erlang is an excellent thing to read about |
| 2025-12-27 19:22:11 +0100 | <sm> | pie_ , you're on the right track - it's good to think about the kinds of errors and how you want to handle each; there are multiple error handling strategies. |
| 2025-12-27 19:21:57 +0100 | <pie_> | im too dumb to reinvent the wheel, thats why im asking :> |
| 2025-12-27 19:21:41 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 250 seconds) |
| 2025-12-27 19:20:54 +0100 | <monochrom> | Alterantively use Haskell's STM. :) |
| 2025-12-27 19:19:50 +0100 | <monochrom> | Easier said than done, sure. That's why you outsource it to a mature relational database, rather than bothering to code up your own. |
| 2025-12-27 19:18:41 +0100 | <monochrom> | That would be when an error in the middle of something causes invalid states. The solution is to undo that unfinished something. |
| 2025-12-27 19:18:13 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2025-12-27 19:18:07 +0100 | ss4 | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-12-27 19:17:03 +0100 | <monochrom> | Another scenerio is much more complex but also a solved problem so you should not re-invent the wheel. Relational databases, transactions, and the choice to rollback a transaction (because you detect an invalidity). |
| 2025-12-27 19:14:46 +0100 | <pie_> | but i guess i was implicitly also thinking about things like services |
| 2025-12-27 19:14:37 +0100 | <pie_> | makes sense |
| 2025-12-27 19:14:30 +0100 | <pie_> | and ok for cli applications |
| 2025-12-27 19:14:20 +0100 | <pie_> | like yes ive seen gui applications that pop up an exception window (for stuff thats not the failure to open a file) and let you try to continue anyway |
| 2025-12-27 19:13:53 +0100 | <pie_> | but if you explain it that way, sure |
| 2025-12-27 19:13:47 +0100 | <pie_> | well, its not so obvious to my puny brain |
| 2025-12-27 19:13:15 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-27 19:12:07 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-12-27 19:11:54 +0100 | <monochrom> | But taking a step back, those are just logical conclusions of the respective specifications. The first case has already required non-interactiveness, so you can only give up. The second case has already specified a GUI, implying that you never exit unless the user tells you to. It is common sense, there is no need to read a book about it. |