| 28 Aug 2025 |
|  Las changed their profile picture. | 20:36:52 |
 emily | right | 20:36:55 |
| emily | we should be defaulting to LLVM 21 for 25.11, hopefully | 20:37:39 |
| Las removed their profile picture. | 20:40:53 |
 Artem | In reply to @sternenseemann:systemli.org
Thibaut: we are updating to the latest version of dhall as part of https://github.com/NixOS/nixpkgs/pull/429810. We could use some help fixing build failures in the dhall-related packages: https://hydra.nixos.org/eval/1818002?filter=dhall&compare=1817909&full= I took a brief look at the hydra log linked. I only saw logs for three failed jobs and from those one is the text/show issue and another one is too strict upper bound on data-defaylt that was PRed recently but has no progress in merging :-( i pinged them on that PR: https://github.com/dhall-lang/dhall-haskell/pull/2659#issuecomment-3234999428 | 21:37:33 |
 Thibaut | I think adding a data-default == 0.7.1.3 and adding it to the failed packages' override could work, I'm checking on dhall-lsp-server | 21:41:02 |
| Thibaut | Redacted or Malformed Event | 23:15:20 |
| Thibaut | it's not enough | 23:15:42 |
| 29 Aug 2025 |
|  @luna-null:matrix.org left the room. | 02:40:19 |
|  @zeorin:matrix.org left the room. | 07:03:56 |
 sterni (he/him) | downgrading data-default is not a good option anyways since it is likely to cause issues elsewhere | 10:41:45 |
| sterni (he/him) | We can do the bound adjustment via patches/overrides as well, we don't need to wait for upstream | 10:43:00 |
 Uraraka ~ Ochaco | Ughh I've had terrible trouble with data-default-class vs data-default. Had to update bounds for another package because of the incompatible update. | 10:58:40 |
| Thibaut | despite the patches, jailbreaks, I end up with this issue:
> src/Dhall/LSP/Util.hs:16:16: error: [GHC-87543]
> Ambiguous occurrence ‘show’.
> It could refer to
> either ‘Prelude.show’,
> imported from ‘Prelude’ at src/Dhall/LSP/Util.hs:3:8-21
> (and originally defined in ‘ghc-internal-9.1002.0:GHC.Internal.Show’),
> or ‘Data.Text.show’,
> imported from ‘Data.Text’ at src/Dhall/LSP/Util.hs:11:1-16.
> |
> 16 | tshow = pack . show
is it fine if I patch it as tshow = pack . Prelude.show?
| 11:15:33 |
| Artem | In reply to @thibaut:fsl.sh
despite the patches, jailbreaks, I end up with this issue:
> src/Dhall/LSP/Util.hs:16:16: error: [GHC-87543]
> Ambiguous occurrence ‘show’.
> It could refer to
> either ‘Prelude.show’,
> imported from ‘Prelude’ at src/Dhall/LSP/Util.hs:3:8-21
> (and originally defined in ‘ghc-internal-9.1002.0:GHC.Internal.Show’),
> or ‘Data.Text.show’,
> imported from ‘Data.Text’ at src/Dhall/LSP/Util.hs:11:1-16.
> |
> 16 | tshow = pack . show
is it fine if I patch it as tshow = pack . Prelude.show?
This is a problem with many packages :-( | 11:22:57 |
| sterni (he/him) | The best solution is probably to submit a proper patch for this to upstream, using CPP. You'd want to use Text.show for text >= 2.1.2 and keep the current code for Text < 2.1.2. | 11:32:49 |
| sterni (he/him) | Prelude.show would work, I guess, though it is a bit silly to implement tshow yourself if Data.Text exposes it now | 11:33:59 |
| Artem | I don't think you need any CPP: with proper qualifications it should be perfectly backwards compatible. | 13:19:25 |
| sterni (he/him) | sure | 16:04:05 |
| sterni (he/him) | * ~~sure~~ | 16:04:30 |
| sterni (he/him) | * sure | 16:04:35 |
|  magic_rb changed their profile picture. | 19:30:45 |
| Artem | all this text's show fallout is due to the fact that in Haskell you can't require people to import qualified. See, certain modules, including Data.Text, are designed to be imported qualified. They will say so in the documentation. But this is only a guideline. It's impossible to enforce. So, anyone who ignored this guideline, imported Data.Text unqualified, and also happened to use show from Prelude, gets blown out... And the good fix is to import Data.Text qualified and update the usages of stuff from there. An easy fix is to update the usages of show to Prelude.show. None if these two are one-line fix in general, sadly. | 19:38:03 |
 maralorn | I mean I kinda think importing without import lists or unqualified should be prevented by a linter on hackage upload. | 19:43:05 |
| emily | sometimes you do want that (modules specifically designed as preludes), no? | 19:43:40 |
| emily | even in Rust people sometimes do glob imports for that case | 19:43:52 |
| maralorn | Yeah, fair. | 19:51:03 |
 toonn | Importing Data.Text unqualified would also not be a problem if people actually stuck to the PVP. | 19:52:10 |
| maralorn | I mean for us in nixpkgs that wouldn’t really help, we would normally be forced to do a jailbreak anyway and then it wouldn’t compile. Although I agree it is better. | 19:53:57 |
| toonn | Well, yeah, but that's going beyond what Hackage and the package maintainers explicitly support. | 20:23:08 |
