Bump bounds to build with GHC 9.8, and fix base64 support

[thomasjm]

Bumps a few bounds to build with GHC 9.8 on the latest Stackage resolver (nightly-2024-07-22).

Also fixes the support for base64 > 0.4. The initial support was landed in https://github.com/qnikst/HaskellNet/pull/91, but seems not to match what eventually happened in the base64 package. Version 0.5 never existed, as the version was bumped all the way to 1.0 with a breaking API change.

Also checks in a small stack.yaml file to make it easy to test with the latest resolver.

[thomasjm]

Hi @qnikst, any chance you could take a look at this? It would be great to get a GHC 9.8 compatible version on Hackage.

[qnikst]

Thanks for PR! I agree with comments of @intricate.

<0.5 was for purpose, the same is <1.1 in the current. For the support we should either drop all CPP checks of base64 in the codebase or extend it to keep support of the wider range. In the current case I don’t see a huge need in the wider range.

for splitting PR I’m ok with updating stack and base64 in one PR, as commits are separate and they are logically related.

once that will be done I’ll be happy to merge, fix CI and release a new version.

[thomasjm]

Cool!

<0.5 was for purpose, the same is <1.1 in the current. For the support we should either drop all CPP checks of base64 in the codebase or extend it to keep support of the wider range.

Now that I look at this again, I'm not sure why I removed some of the CPP. I think it might be slightly incorrect on master due to #91. Anyway, I think I'd actually favor keeping the wider range. This package makes pretty minor use of base64, so we can do this at the cost of only a few lines of CPP.

I think this is worth doing, since current Stackage release generations still use base64-0.4.2.4 or similar -- such as LTS 22.44 for the GHC 9.6 series, released 3 weeks ago.

Does that sound okay @qnikst ? Let me know and I'll add (correct) CPP to support all versions.

[qnikst]

Sounds great, thanks @thomasjm!

[thomasjm]

Okay @qnikst, this is ready for another look. I figured out why I removed the CPP, it is not necessary for the encode direction since the API didn't change; it remains needed for the decode direction.

I did a couple more things which you can see commit by commit:

• Fix some minor warnings. A name shadowing issue, a redundant import, and some redundant cases that are detected and warned about by modern GHCs.
• I exported the functions fetchPeek and fetchRPeek, which are not used locally and not exported. They sort of look intended for external consumption. You can ignore this commit if you don't want to export them.
• I took the liberty of modernizing the CI, using the approach I use in my other projects. The matrix tests Cabal and Stack. Cabal gets tested on Linux and MacOS. GHC versions are all green from 8.10.7 to 9.12.2.

[thomasjm]

Hi @qnikst, this should be ready to go!

[qnikst]

Great job, thanks!