2025/05/13

Newest at the top

2025-05-14 01:08:38 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds)
2025-05-14 01:07:50 +0200ljdarj1ljdarj
2025-05-14 01:07:49 +0200ljdarj(~Thunderbi@user/ljdarj) (Ping timeout: 276 seconds)
2025-05-14 01:05:11 +0200ljdarj1(~Thunderbi@user/ljdarj) ljdarj
2025-05-14 01:03:58 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-14 01:00:58 +0200 <xeno11> tomsmeding: , int-e: *
2025-05-14 01:00:31 +0200 <xeno11> tomsmeding:,int-e: thanks for the help, much appreciated
2025-05-14 01:00:18 +0200 <int-e> sure but then you're bound to clash with ghc-up eventually
2025-05-14 00:59:55 +0200 <geekosaur> it should probably go in ghc's settings file fwiw
2025-05-14 00:58:03 +0200 <int-e> and not in some project-related file
2025-05-14 00:57:51 +0200 <int-e> it really is a thing that pretty much unambiguously belongs in ~/.cabal/config
2025-05-14 00:57:35 +0200halloy5771(~halloy577@205.175.106.139) (Read error: Connection reset by peer)
2025-05-14 00:57:11 +0200 <sim590> At least, we can put it in `cabal.project`, so it's not shipped anywhere.
2025-05-14 00:57:11 +0200 <int-e> (and you'll run into this with *every* haskell project as long as you use this particular ghc, and probably other versions shipped with ghc-up too)
2025-05-14 00:56:06 +0200 <int-e> it's a local configuration so putting it into the project is wrong
2025-05-14 00:56:03 +0200 <sim590> I thought ourproject.cabal in the `ghc-options:` section.
2025-05-14 00:55:44 +0200 <sim590> int-e: It would not be in the invocation, but in a config file in the project repo.
2025-05-14 00:55:01 +0200 <int-e> sim590: which is what cabal would do if you instructed it accordingly, and doing it in the config file feels less painful than doing it on every invokation
2025-05-14 00:54:25 +0200 <sim590> So we could just protect ourselves with an option in a `cabal.project` file or literally inside the cabal file.
2025-05-14 00:53:54 +0200 <sim590> int-e: isn't it possible to just pass an option to GHC to force not using ld.gold, but stick to plain ld ?
2025-05-14 00:53:02 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds)
2025-05-14 00:52:55 +0200 <int-e> glhf
2025-05-14 00:52:30 +0200 <int-e> sim590: Anyway. The path of least resistance is to install ld.gold (it may be deprecated but it works as a linker). The next easiest idea is to tweak, hmm, ld-location I suppose in ~/.cabal/config. After that it's editing the settings file inside the ghc distribution and after that it's finding a "better" ghc package.
2025-05-14 00:52:28 +0200 <haskellbridge> <sm> and, welcome
2025-05-14 00:52:00 +0200 <haskellbridge> <sm> hi zarek, cardano has lots of getting started and learning haskell resources doesn't it; we don't know them all here
2025-05-14 00:49:36 +0200 <zarek> I remember this is how I solved my problems with ghcup and rest of haskell, but if this isn't solution than I don't know
2025-05-14 00:48:23 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn
2025-05-14 00:48:06 +0200machinedgod(~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod
2025-05-14 00:47:33 +0200 <int-e> zarek: it's irrelevant anyway: --with-ghc=/home/xkappel/.ghcup/bin/ghc
2025-05-14 00:47:06 +0200 <sim590> I only got issues with debian when dist-upgrading (same as xeno11). I guess that the `binutils-gold` was removed when we did a `dist-upgrade` and that confused everything.
2025-05-14 00:46:27 +0200 <sim590> But I actually didn't have any issue on Arch.
2025-05-14 00:46:15 +0200 <sim590> zarek: One of my machines I use have arch and the other has debian.
2025-05-14 00:45:56 +0200 <EvanR> forwarding that link to the other channel looks interesting
2025-05-14 00:45:44 +0200 <int-e> (the trouble is elsewhere)
2025-05-14 00:45:28 +0200 <int-e> zarek: ironically that would likely use a linker that's actually installed
2025-05-14 00:44:57 +0200 <int-e> sim590: you can override the linker in your cabal config, that's probably the easier route for making progress right now
2025-05-14 00:44:32 +0200 <zarek> sim590: by any chance did you install ghc by pacman in arch linux? If yes, thank I suggest nuke everything and install everything from curl link
2025-05-14 00:44:25 +0200 <sim590> int-e: yep.
2025-05-14 00:44:20 +0200Lord_of_Life_Lord_of_Life
2025-05-14 00:44:09 +0200 <int-e> sim590: maybe. afaics you're using ghc-up so you're relying on that upstream's build configuration
2025-05-14 00:43:58 +0200 <EvanR> there is #haskell-game and HaskellGameDev discord, with its own links and references, though things have slowed down in the last few months
2025-05-14 00:43:26 +0200 <sim590> int-e: So, it's something that would be likely to change by itself if GHC was upgraded, right?
2025-05-14 00:43:06 +0200Lord_of_Life(~Lord@user/lord-of-life/x-2819915) (Ping timeout: 272 seconds)
2025-05-14 00:42:54 +0200Lord_of_Life_(~Lord@user/lord-of-life/x-2819915) Lord_of_Life
2025-05-14 00:42:30 +0200 <zarek> EvanR: Would you recommend some library for it or blog post/book about programming game in haskell? I only today saw this video about programming game in haskell in haskell https://www.youtube.com/watch?v=1MNTerD8IuI&list=PLcGKfGEEONaCyiY7-IV6boavjCIG7q1vd&
2025-05-14 00:42:23 +0200 <int-e> Or, technically, not the binary but the `settings` files it ships with. So if you feel adventerous you can change that.
2025-05-14 00:41:19 +0200 <int-e> sim590: my guess is that using ld.gold is baked into the ghc binary you're using. that's what the ghc --info comment was about
2025-05-14 00:40:11 +0200 <sim590> int-e, tomsmeding: seems like ld.gold is deprecated apprently. But cabal still uses it by default? Shouldn't it stop to use it at some point?
2025-05-14 00:39:47 +0200 <zarek> EvanR: Yes, I'm also interested
2025-05-14 00:37:37 +0200merijn(~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds)