-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with GHC 9.2 #53
Comments
I suspect this has to do with the change of internal representation of bytestring:
It appears impossible to put a version bound on xeno to be lower then 0.11.0.0 due to the base restriction.
But I think going forward we should fix the offset like it is for the new bytestring anyway, |
Here's a potential non-backwards-compatible fix. I'd appreciate a review. Tests pass but I didn't think too hard about what I was doing. |
@avieth if you want, open a PR. you can use this trick to make it backwards compatible: #if MIN_VERSION_bytestring(0,11,0)
NEW_CODE
#else
OLD_CODE
#endif It's best to factor that out in a dedicated function per branch, but inline also works. |
First of all, thank you everyone for looking at this and @avieth for getting the ball rolling on a PR. I have a funny feeling about that |
Pull request here featuring backwards compatibility.
Should be fine I think. The |
Closed via #56 . Thanks all! |
Forgot to say, I've published xeno 0.5 with the fix in, try it out ! |
I was trying to check my package
xlsx
with GHC 9.2 and found it failing at https://github.com/qrilka/xlsx/blob/master/test/Main.hs#L57 which usesxeno
-based fast parsing. Quick look shows some odd results fromxeno
.I tried
xeno
with GHC 9.2.1 and with the followingstack.yaml
I get a failure
The text was updated successfully, but these errors were encountered: