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 #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.

[intricate]

Hey @qnikst, would you be open to looking at this?

If there are any changes that you'd suggest for this PR, and @thomasjm isn't available to implement them, I'd be happy to do it.

[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.

[intricate]

This looks good to me.

edit: Nevermind my comment about non-exhaustive pattern matches.

[intricate]

Sorry about my previous comment on these non-exhaustive pattern matches.

I didn't notice that some of these patterns are being matched at the sendCommand function-definition "level" and then redundantly being matched in this case again.

I wonder if this should be further addressed in a follow up. To make this code more clear, it seems like there should only be one definition of sendCommand and a single case pattern match on command.

[thomasjm]

Recent GHC versions understand these matches are redundant and warn about them, so I was just fixing a couple warnings. Further refactoring could certainly happen as a follow-up.

[thomasjm]

Hi @qnikst, this should be ready to go!

[qnikst]

Great job, thanks!