Would it be possible to port to GHC 9.6?

[Mikolaj]

I wonder, perhaps relaxing the strict bound would suffice?

[infinity0]

I'm on holiday for a couple months and won't have much time to test this in depth, but could probably find some time to look at a PR and the resulting CI results. Or can deal with this myself once I'm back if you are happy to wait.

[Mikolaj]

It appears we are blocked on vector-binary-instances anyway. :(

[Mikolaj]

But thank you. :)

[Mikolaj]

I think it's possible we are now only blocked on our bound on strict. Could it be relaxed, perhaps just via a Hackage revision?

[erikd]

I currently have the following in my cabal.project file:

allow-newer:
    strict-containers:strict

[infinity0]

If it's just a simple case of relaxing the version bound feel free to open a PR that will run CI. I'm completely context-swapped out of Haskell atm.

[erikd]

@infinity0 PR is #13

I am also a Hackage trustee so I can do a metadata edit for this if you would like me to.

[infinity0]

Sure feel free & thanks! I'll leave this issue open to track adding 9.6 to CI in the future, once ghcup supports it.

[erikd]

Sure feel free & thanks! I'll leave this issue open to track adding 9.6 to CI in the future, once ghcup supports it.

Done

[phadej]

@infinity0 could we move this repository of out haskellari. I'd like to keep only actually (actively) maintained repositories in the organization, and I didn't like idea of adding strict-containers here to begin with.

[erikd]

@phadej Where do you propose moving it? The https://github.com/haskell group might be appropriate.

[phadej]

@erikd anywhere @infinity0 (as the only Hackage maintainer) seems fit. Out of haskellari.

[infinity0]

What concrete problem do you have with how I am maintaining this repo currently?

Might I remind you that I originally only agreed to move strict from the haskell-strict organisation to here if it was more collaboratively maintained, rather than just you deciding what should be in-or-out. If we move strict-containers away from here, I think strict should also be moved away from here, they form a related set of packages. We could them move into the old haskell-strict organisation if haskell isn't willing to accept them.

FWIW the easiest option is to leave things as they are, that is my preferred option.

[phadej]

This is about strict-containers, not strict.

strict is (collaboratively) maintained.

, they form a related set of packages.

They don't. strict-containers depend on strict, sure. But that's about it. Containers (Map, Set, ...) weren't part of original https://hackage.haskell.org/package/strict-base-types, nor they should IMO.

[erikd]

@infinity0 I am willing to take over maintainer ship of this package if you are too busy.

The specific problems I have with this package is that dependencies are not updated in a timely manner (#15). Currently using allow-newer but do not like to commit that to master.

[infinity0]

@erikd I just invited you to collaborate on this repo and also have added you to the hackage maintainers' group for this package. Feel free to bump the dependencies and release new versions.

Updating the actual upstream/contrib libraries are much more complex, because of the patching process. I described it previously in #14. Please do ask questions if any part of it isn't clear - or just leave it be for the time being. (Also, we can drop the vector part of it now, see #16.)

If the https://github.com/haskell group is happy to accept this package I'd be happy to move it there, but in the meantime would prefer to have it co-maintained within this group. Bear in mind it is not a "normal" haskell package and involves those hacky patches that require a different skill-set to maintain.

[erikd]

Version on master and on Hackage compiles with ghc < 9.10.