Closed stuart-little closed 2 years ago
I think it would be good to check how this package is affected by the GHC optimization changes around withForeignPtr
(used for example in hBlockCopy
). Is the performance significantly reduced? Should unsafeWithForeignPtr
be used instead?
Please make available as soon as possible on GHC 9. You can always later release a faster version.
@pjljvandelaar MissingH already works for GHC 9 since a hackage revision was made by a trustee: https://github.com/haskell-infra/hackage-trustees/issues/306
Almost: it still complaints about random (>=1.0.1.1 && <1.2). See https://github.com/haskell-hvr/missingh/issues/56
Ok, I see why it would be useful to have another bump to have it working on Stackage Nightly. But as I mentioned, strictly speaking, it does work on GHC 9. Just wanted to point that out. Try e.g.:
cabal install MissingH --lib
Ok, I see why it would be useful to have another bump to have it working on Stackage Nightly. But as I mentioned, strictly speaking, it does work on GHC 9. Just wanted to point that out. Try e.g.:
cabal install MissingH --lib
This still does not work.. Here's me running it, having just done a cabal update
:
$ cabal install --lib MissingH
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: MissingH-1.4.3.0 (user goal)
[__1] trying: base-4.15.0.0/installed-4.15.0.0 (user goal)
[__2] next goal: process (user goal)
[__2] rejecting: process-1.6.12.0 (constraint from user target requires
==1.6.11.0)
[__2] trying: process-1.6.11.0/installed-1.6.11.0
[__3] next goal: random (user goal)
[__3] rejecting: random-1.2.0 (conflict: MissingH => random>=1.0.1.1 && <1.2)
[__3] rejecting: random-1.1, random-1.0.1.1, random-1.0.1.0, random-1.0.0.3,
random-1.0.0.2, random-1.0.0.1, random-1.0.0.0, random-1.0.1.3 (constraint
from user target requires ==1.2.0)
[__3] fail (backjumping, conflict set: MissingH, random)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, haskell98, process, MissingH,
random
Try running with --minimize-conflict-set to improve the error message.
So as per @pjljvandelaar 's comment, there's a complaint about random
.
The problem here is that you already have stuff in your ghc environment that forces random to be 1.2.0, however that conflicts with the constraints on missingh. So the issue is not that missingh cannot build with ghc 9.0.1, but rather that it should have its bounds on random bumped to build with other things as well.
E.g. with ghc 9.0.1 this works for me cabal repl --build-depends=MissingH
why argue instead of bumping version to bypass the issue? I hit it also and now I have to do fork. :(
If the change is only to bounds, you can work around this locally with --allow-newer (https://cabal.readthedocs.io/en/3.4/cabal-project.html#cfg-field-allow-newer). If your testing reveals this does work with just a bump to random, then please open a PR here for a bump to random (and also, because missingh is not very actively maintained, file an issue with the trustees: https://github.com/haskell-infra/hackage-trustees/issues).
For the record, nobody argued against a bump to random. This issue was just not about that, it was about a bump to base, which was done on hackage already.
For the record, time
is also used with an restrictive upper bound:
MissingH-1.4.3.0$ cabal outdated
Outdated dependencies:
random >=1.0.1.1 && <1.2 (latest: 1.2.0)
time >=1.4 && <1.10 (latest: 1.12)
If somebody manages to take over this library, please note that the suggested base bound wouldn't be sufficient to support GHC 9.2. So if it is bumped, may as well bump even further.
I revised the bounds to allow GHC 9.2: https://hackage.haskell.org/package/MissingH-1.4.3.0/revisions/
I'm on
ghc v9.0.1
(which hasbase 4.15
) andcabal v3.4.0.0
.MissingH
is currently inaccessible throughcabal
, because it asks forbase <4.15
.Is that version being held back for technical reasons, or is it a matter of just bumping it up?