Newest at the top
| 2026-04-10 10:40:34 +0000 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-04-10 10:40:22 +0000 | Pozyomka_ | (~pyon@user/pyon) (Ping timeout: 256 seconds) |
| 2026-04-10 10:27:54 +0000 | Googulator85 | (~Googulato@team.broadbit.hu) |
| 2026-04-10 10:25:58 +0000 | czan | (~czan@user/mange) czan |
| 2026-04-10 10:22:13 +0000 | srazkvt | (~sarah@user/srazkvt) srazkvt |
| 2026-04-10 10:20:21 +0000 | danza | (~danza@user/danza) (Ping timeout: 246 seconds) |
| 2026-04-10 10:18:06 +0000 | craunts795335385 | (~craunts@152.32.99.2) |
| 2026-04-10 10:17:40 +0000 | Pozyomka | (~pyon@user/pyon) (Ping timeout: 245 seconds) |
| 2026-04-10 10:17:27 +0000 | Pozyomka_ | (~pyon@user/pyon) pyon |
| 2026-04-10 10:16:59 +0000 | craunts795335385 | (~craunts@152.32.99.2) (Quit: The Lounge - https://thelounge.chat) |
| 2026-04-10 10:10:52 +0000 | uli-fem | (~uli-fem@115.128.112.118) (Ping timeout: 268 seconds) |
| 2026-04-10 10:04:23 +0000 | <Milan_Vanca> | really? I didn't know that |
| 2026-04-10 10:04:03 +0000 | <merijn> | Although rust's stuff is heavily cabal inspired afaik |
| 2026-04-10 10:03:47 +0000 | <merijn> | and maybe Rust? |
| 2026-04-10 10:03:42 +0000 | <merijn> | haskell's :p |
| 2026-04-10 10:03:13 +0000 | Enrico63 | (~Enrico63@host-212-171-80-94.retail.telecomitalia.it) (Quit: Client closed) |
| 2026-04-10 10:02:59 +0000 | <Milan_Vanca> | merijn: Anyway when you said not to look up to python packaging. Are there other systems you might recommend? |
| 2026-04-10 10:01:43 +0000 | Square3 | (~Square@user/square) Square |
| 2026-04-10 09:55:53 +0000 | craunts795335385 | (~craunts@152.32.99.2) |
| 2026-04-10 09:55:17 +0000 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 244 seconds) |
| 2026-04-10 09:54:47 +0000 | craunts795335385 | (~craunts@152.32.99.2) (Client Quit) |
| 2026-04-10 09:53:23 +0000 | <Milan_Vanca> | Yeah.. runtime bugs are always possible.. I should start writing more tests :D |
| 2026-04-10 09:52:39 +0000 | craunts795335385 | (~craunts@152.32.99.2) |
| 2026-04-10 09:51:26 +0000 | <Milan_Vanca> | merijn: If I "allow-newer" then the "worst" case is that type's won't match and it just won't compile right? Should I also expect runtime bugs? I mean there is always posibility to use "untested" version. |
| 2026-04-10 09:49:38 +0000 | <merijn> | Milan_Vanca: It's not so much about not using latest because of being buggy, but just because dealing with the ecosystem not being instantly ready is too much of a hassle |
| 2026-04-10 09:48:49 +0000 | <merijn> | Oh, I'm not saying you shouldn't use/test the latest version. Just be aware that that comes with a lot of --allow-newer overrides until adoption goes wider :p |
| 2026-04-10 09:44:58 +0000 | <Milan_Vanca> | But also maybe I like to live on edge...There is also .NET MAUI "production ready" for few years but still unusable... |
| 2026-04-10 09:43:41 +0000 | <Milan_Vanca> | merijn: Your stance about not using latest version are quite strong. And I kind of agree when one develops mission critical application. But also somebody needs to use and test latest version to iron out all issues. I don't want to believe that "Suitable for use/LTS" is really that buggy. |
| 2026-04-10 09:34:36 +0000 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2026-04-10 09:33:04 +0000 | <gentauro> | anyway, just renamed the field and no probs :) |
| 2026-04-10 09:32:24 +0000 | <merijn> | And there's often not a really big reason to adopt the bleeding edge while that happens |
| 2026-04-10 09:32:05 +0000 | <merijn> | It generally takes 9 months to a year for a new GHC version to percolate through to for the majority of the ecosystem to |
| 2026-04-10 09:31:58 +0000 | <gentauro> | tomsmeding: yeah, I road that piece of documentation and I didn't get any wiser … |
| 2026-04-10 09:31:13 +0000 | <Milan_Vanca> | That is one way granted |
| 2026-04-10 09:30:46 +0000 | <merijn> | And then all your --allow-newer problems should hopefully disappear |
| 2026-04-10 09:29:16 +0000 | <merijn> | I'd probably pick 9.10 or 9.12 atm |
| 2026-04-10 09:28:57 +0000 | <merijn> | Milan_Vanca: at any rate, unless there is a specific bug blocking you OR new feature you need from the latest GHC I would never recommend using the latest version |
| 2026-04-10 09:28:36 +0000 | <Milan_Vanca> | you have sandbox and then solve dependencies there... |
| 2026-04-10 09:28:06 +0000 | <merijn> | Milan_Vanca: Most Python tooling just looks at your flat list of dependencies and goes "check, lemme use that" |
| 2026-04-10 09:28:00 +0000 | <Milan_Vanca> | Okey I mean poetry |
| 2026-04-10 09:27:43 +0000 | <merijn> | Milan_Vanca: Oh god no |
| 2026-04-10 09:27:37 +0000 | <Milan_Vanca> | merijn: I read your note about building DAG and trying to satisfy all dependencies.. But python must do the same |
| 2026-04-10 09:27:34 +0000 | <merijn> | Milan_Vanca: 2) unlike python's "everything is globally installed" OR "you gotta manually sandbox each project", cabal creates "on-demand" per-project projections of everything installed globally |
| 2026-04-10 09:25:26 +0000 | <merijn> | I personally always used "second to latest" |
| 2026-04-10 09:25:14 +0000 | <merijn> | I would not use the latest GHC, tbh |
| 2026-04-10 09:25:07 +0000 | <merijn> | Milan_Vanca: Right, so that's bleeding edge :p |
| 2026-04-10 09:25:00 +0000 | <merijn> | that means that if a package claims to work (no upper bound), but doesn't you break everything |
| 2026-04-10 09:24:57 +0000 | <Milan_Vanca> | merijn: No I use ghc 9.14 and many libs just don't support that yet. |
| 2026-04-10 09:24:39 +0000 | <merijn> | Milan_Vanca: Some important differences between cabal and python's tooling: 1) cabal creates a DAG of dependencies with version constraints and tries to solve it to find a combination of dependency versions that makes every transitive dependency happy |
| 2026-04-10 09:24:02 +0000 | <Milan_Vanca> | tomsmeding: but can't we say in cabal to cap some max version and thus no need for fork? |