Newest at the top
2025-09-26 13:38:40 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Client Quit) |
2025-09-26 13:37:32 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
2025-09-26 13:36:01 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Client Quit) |
2025-09-26 13:35:41 +0200 | Lord_of_Life_ | Lord_of_Life |
2025-09-26 13:34:47 +0200 | <tomsmeding> | hence the partial-order-of-errors idea where you store only the maxima |
2025-09-26 13:34:21 +0200 | <tomsmeding> | anyway |
2025-09-26 13:34:19 +0200 | <tomsmeding> | merijn: if I'm understanding [exa]'s use case correctly, the idea is that an auth error in some component is useful to report (credentials should be fixed), and a timeout is also useful (retry may help), but if later we find out that something in the config of that component is just broken, the error "config should be fixed" overrides the other ones because a changed config changes everything |
2025-09-26 13:33:19 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
2025-09-26 13:33:01 +0200 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 264 seconds) |
2025-09-26 13:32:53 +0200 | Lord_of_Life_ | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
2025-09-26 13:32:35 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) |
2025-09-26 13:32:00 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Client Quit) |
2025-09-26 13:29:38 +0200 | <merijn> | [exa]: I mean, the exception system lets you create hierarchical inheritance like behaviour for exceptions, so maybe try something along those lines? |
2025-09-26 13:29:16 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Client Quit) |
2025-09-26 13:28:43 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) lortabac |
2025-09-26 13:28:09 +0200 | <tomsmeding> | if you do my `reduce` in (<>), then you can reduce the O(n^2) to O(n * m) because you can assume that no redundancies exist within one argument to (<>) |
2025-09-26 13:25:43 +0200 | lortabac | (~lortabac@2a01:e0a:541:b8f0:55ab:e185:7f81:54a4) (Quit: WeeChat 4.5.2) |
2025-09-26 13:25:34 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
2025-09-26 13:23:20 +0200 | <tomsmeding> | I guess that's called directed graph reachability |
2025-09-26 13:23:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-09-26 13:23:06 +0200 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
2025-09-26 13:22:56 +0200 | <tomsmeding> | I wonder if there's a neat way to implement (<) on a partial order by only specifying the pairs that generate the order, i.e. without having to manually deal with transitivity |
2025-09-26 13:21:07 +0200 | <tomsmeding> | (that's not to say you should not do the rename in your case, I dunno the context and don't need to know it :P) |
2025-09-26 13:20:37 +0200 | <tomsmeding> | also there's plenty precedent for errors not being fatal, see compiler errors |
2025-09-26 13:20:01 +0200 | <tomsmeding> | just makes all the names longer |
2025-09-26 13:19:49 +0200 | <tomsmeding> | I don't think s/Error/Recommendation/g changes anything in the above |
2025-09-26 13:19:34 +0200 | [exa] | goes back to the cave to rethink again |
2025-09-26 13:19:15 +0200 | <[exa]> | I might really want to reword the whole problem to recommendations instead of the error/exception wording, it makes interpretation much easier |
2025-09-26 13:18:32 +0200 | <tomsmeding> | math! |
2025-09-26 13:18:26 +0200 | <tomsmeding> | neat |
2025-09-26 13:18:13 +0200 | <[exa]> | so yeah partial order it is |
2025-09-26 13:18:09 +0200 | <[exa]> | I have one error where there's timeout in one service and auth failure in another, and both need to be handled (someone needs to tell admins to check credentials, and someone else needs to delay the retry), and they both occlude a few other errors/warnings |
2025-09-26 13:18:07 +0200 | <tomsmeding> | you still have to define your partial order of course |
2025-09-26 13:17:59 +0200 | <tomsmeding> | you can probably do better than O(n^2) somehow, but this may well be "good enough" |
2025-09-26 13:17:38 +0200 | <tomsmeding> | then you could choose to run `reduce` in the (<>) on Errors (if you make it a newtype), or you could run `reduce` at the end once only |
2025-09-26 13:17:12 +0200 | <tomsmeding> | perhaps a stupid slow but working version of that lattice approach is: type Errors = Set Error; then have `reduce :: Errors -> Errors` that loops over all pairs (e1, e2) in the set (i.e. it's O(n^2)) and if e1 < e2 in your partial order, then e1 is removed from the set |
2025-09-26 13:16:09 +0200 | <[exa]> | now if I could have more maxima, I guess interpretation is gonna be harder but it solves the issue |
2025-09-26 13:15:53 +0200 | <[exa]> | yeah you know what, I thought I can live with the ordering of the errors but I was hitting a problem where I didn't know what the useful maxima would be |
2025-09-26 13:15:22 +0200 | <tomsmeding> | lattice ~ partial order in my mind |
2025-09-26 13:15:12 +0200 | <tomsmeding> | if you want more detail you can either add fields to the RetryNeeded/ReconfigNeeded constructors, or instead transpose the thing and have `data Error` be the long sum type of actual fine-grained errors, and have `isRetryNeeded :: Error -> Bool` and `isReconfigNeeded :: Error -> Bool` |
2025-09-26 13:15:12 +0200 | <[exa]> | hm lattice |
2025-09-26 13:15:05 +0200 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
2025-09-26 13:13:45 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer) |
2025-09-26 13:13:39 +0200 | <tomsmeding> | if your errors are not linearly ordered then I wonder if there's some clever kind of lattice-based deduplication algorithm you could run on the Set Error :p |
2025-09-26 13:12:54 +0200 | <haskellbridge> | <sm> if you can meaningfully collect and list them all, that could be another approach |
2025-09-26 13:11:54 +0200 | <[exa]> | so kinda scanning for possibilities |
2025-09-26 13:11:46 +0200 | <[exa]> | yeah I got to a situation where handing the error combinations by one is a bit to much |
2025-09-26 13:11:41 +0200 | trickard_ | (~trickard@cpe-50-98-47-163.wireline.com.au) |
2025-09-26 13:11:39 +0200 | <tomsmeding> | if you just want the maximum, type Errors = Data.Monoid.Max Error |
2025-09-26 13:11:07 +0200 | <haskellbridge> | <sm> [exa] I think that gets pretty complicated and a more sequential / prioritised handling of single errors can be more practical |