Got it to compile with stack LTS-15.5 #1
Conversation
Most of the changes are due to the Pretty class that was added, it seems, in v2.2.0.1-tgt. There were some slightly trickier cases around some data types that don't seem to be used anymore and changes to the Package/ GenericPackge records. Open questions: - This doesn't pass all the tests. The main failures seem to be around quoting in certain rendering situations and in error reporting - Relatedly, how should the new-ish ParseResult monad be incorporated? I opted for parseGenericPackageDescriptionMaybe because I didn't want to infect the rest of the module with an API change, but it's unclear how to exactly recover the old behavior. - Is the style where it needs to be (whitespace/ indentation, ...)?
|
Hello Will. Thank you for stopping by. I shall look into it as soon as I can. Please remind me if I show no activity in a few days. |
|
@wbadart Would you agree to bump the version number? Currently it goes backwards! Then I am going to merge it and see what happens. It was never intended to be a perfect package from my side — good enough that it runs. Surely I would also welcome any future work on this, all kinds of fixing and polishing, but I would rate that as low priority. |
|
Ha, didn't even notice that. Would definitely agree. |
|
Awesome. Let me know if you're able to make any progress on the unit tests (like I mentioned in the commit message, I think the failures are mostly related to quoting and error messaging). I'll be working on them from my end as time permits. |
Hey @kindaro, I've been trying to get yamadapc's hpack-convert to compile with a more modern stack snapshot. After struggling a bit, I saw that you opened yamadapc#16, which gets most of the way there for LTS-15.5. Here are some tweaks that get the package to compile all the way. (Still having some issues w/ the unit tests, see 3e43406 for details.)
Please let me know your thoughts!