Newest at the top
| 2026-04-10 11:05:23 +0000 | ec | (~ec@gateway/tor-sasl/ec) ec |
| 2026-04-10 11:04:48 +0000 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 265 seconds) |
| 2026-04-10 11:03:27 +0000 | tromp | (~textual@2001:1c00:340e:2700:8dcf:a6d6:339b:7a0) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-10 10:57:31 +0000 | m | (~travltux@user/travltux) travltux |
| 2026-04-10 10:54:04 +0000 | m | (~travltux@user/travltux) (Quit: WeeChat 4.7.2) |
| 2026-04-10 10:51:32 +0000 | puke | (~puke@user/puke) (Ping timeout: 250 seconds) |
| 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" |