Newest at the top
| 2025-10-26 21:58:59 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-26 21:51:57 +0100 | rachelambda8 | (~rachelamb@cust-95-80-25-71.csbnet.se) |
| 2025-10-26 21:49:03 +0100 | trickard__ | trickard |
| 2025-10-26 21:49:02 +0100 | trickard | (~trickard@cpe-50-98-47-163.wireline.com.au) (Ping timeout: 240 seconds) |
| 2025-10-26 21:48:33 +0100 | trickard__ | (~trickard@cpe-55-98-47-163.wireline.com.au) |
| 2025-10-26 21:47:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-10-26 21:47:06 +0100 | pr1sm | (~pr1sm@24.91.163.31) |
| 2025-10-26 21:43:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-26 21:42:50 +0100 | Lycurgus | (~juan@user/Lycurgus) Lycurgus |
| 2025-10-26 21:42:22 +0100 | pr1sm | (~pr1sm@24.91.163.31) (Ping timeout: 240 seconds) |
| 2025-10-26 21:37:54 +0100 | pr1sm | (~pr1sm@24.91.163.31) |
| 2025-10-26 21:36:15 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) {-d0t-} |
| 2025-10-26 21:32:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-10-26 21:30:50 +0100 | _d0t | (~{-d0t-}@user/-d0t-/x-7915216) (Ping timeout: 244 seconds) |
| 2025-10-26 21:30:31 +0100 | werneta | (~werneta@71.83.160.242) werneta |
| 2025-10-26 21:27:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-26 21:22:09 +0100 | pr1sm | (~pr1sm@24.91.163.31) (Ping timeout: 244 seconds) |
| 2025-10-26 21:21:22 +0100 | <davean> | If it had more than one option I think it might lend its self more to a time thing |
| 2025-10-26 21:21:07 +0100 | <davean> | omentic: its not even a time thing |
| 2025-10-26 21:19:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-10-26 21:18:42 +0100 | <omentic> | how long does it usually take for a hackage package to get in a stackage LTS? |
| 2025-10-26 21:16:59 +0100 | pr1sm | (~pr1sm@24.91.163.31) |
| 2025-10-26 21:16:02 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) (Quit: pillow time) |
| 2025-10-26 21:14:46 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-10-26 21:13:37 +0100 | bggd | (~bgg@2a01:e0a:819:1510:d163:624e:1256:4e49) |
| 2025-10-26 21:13:24 +0100 | <omentic> | stack slander revoked |
| 2025-10-26 21:13:13 +0100 | <omentic> | yeah i got that output mixed up with when i was trying to use >= instead of * debugging the resolver issue |
| 2025-10-26 21:12:36 +0100 | <omentic> | int-e: oh, you're absolutely right, my bad |
| 2025-10-26 21:12:15 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2025-10-26 21:12:05 +0100 | <int-e> | omentic: hmm, are you sure it's not just restricting it to a single major release? It's effectively 3.8.* |
| 2025-10-26 21:11:18 +0100 | <omentic> | and turns out the didn't-consider-versions issue was my resolver. but i wish it told me these things. |
| 2025-10-26 21:10:52 +0100 | <omentic> | turns out that < 3.9 bound is just because pandoc >= 3.9 does not exist lmfao |
| 2025-10-26 21:10:27 +0100 | <omentic> | davean: hm, i was a little mystified honestly. i saw one bound i had specified (pandoc >= 3.8) but stack inserted another bound (pandoc < 3.9) and didn't tell me where it came from, and also did not consider versions i thought it should consider and didn't tell me why |
| 2025-10-26 21:09:28 +0100 | <davean> | int-e: right but you get that with package versioning to start with |
| 2025-10-26 21:09:03 +0100 | <int-e> | I think the intent is that if your software had a build plan and worked with LTS-20.1 then it will still compile and work with LTS-20.26, thanks to curation (with strong reliance on the package versioning policy) |
| 2025-10-26 21:08:52 +0100 | <davean> | Though thats the same idea as a type system so I don't get why they're confused about that if they're using Haskell. |
| 2025-10-26 21:08:34 +0100 | <davean> | Well I guess i know one thing people find confusing about versions, and thats that they don't understand constraint solvers so they're mystified by the constraitn conflicts cabal spits out apparently? |
| 2025-10-26 21:07:55 +0100 | <davean> | IMO it makes it much harder, because as soon as you need something else you've broken the entire model |
| 2025-10-26 21:07:01 +0100 | <monochrom> | s/stable/conservative/ would be more accurate IMO |
| 2025-10-26 21:06:57 +0100 | <davean> | I have no fucking clue man, I've never understood. People get really upset about it though |
| 2025-10-26 21:06:41 +0100 | <omentic> | hm, interesting... do you know why specifying versions is hard? |
| 2025-10-26 21:06:19 +0100 | <davean> | So you can ahve an entire system that means you don't have to because there aren't options :-p |
| 2025-10-26 21:05:57 +0100 | <davean> | Ah, apparently specifying versions is REALLY REALLY hard and confusing. |
| 2025-10-26 21:05:40 +0100 | <davean> | What it means is that if you don't set your version bounds you still get the sameish thing over time |
| 2025-10-26 21:05:19 +0100 | <omentic> | i see it's meant to be stable but i'm not sure what that means. what makes something that is *not* based on stackage unstable? what's wrong with specifying specific versions of your dependencies? |
| 2025-10-26 21:05:15 +0100 | trickard_ | trickard |
| 2025-10-26 21:05:06 +0100 | <davean> | omentic: it gives you 0 or 1 versions of the packages on hackage. |
| 2025-10-26 21:03:20 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-10-26 21:02:09 +0100 | <davean> | Its a specific set of packages from hackage. |
| 2025-10-26 21:00:29 +0100 | <omentic> | (oops, sorry) what's stackage wrt. hackage? |