Skip to content
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

Allow base 4.12, as released with GHC 8.6. #15

Merged
merged 2 commits into from
Oct 3, 2018

Conversation

quasicomputational
Copy link
Contributor

There's actually an old version of vector-binary-instances that the
solver is able to use on GHC 8.6, but I presume that the latest
version would be better to use if possible.

This also adds 8.6 to the Travis configuration.

There's actually an old version of vector-binary-instances that the
solver is able to use on GHC 8.6, but I presume that the latest
version would be better to use if possible.

This also adds 8.6 to the Travis configuration.
@bgamari
Copy link
Collaborator

bgamari commented Oct 1, 2018

This seems to break CI.

@quasicomputational
Copy link
Contributor Author

quasicomputational commented Oct 2, 2018

@bgamari Can you trigger a build of master, please?

I don't think that this PR is causing it; rather, at some point since the last Travis run, criterion has grown a necessary transitive dependency on vector-binary-instances and cabal-install doesn't like the apparent cycle.

At the component level this is actually feasible (i.e., not a cycle), and haskell/cabal#1575 is tracking that.

Edit: Actually, I think it might not be manifesting on master. criterion 1.5.1.0 is the only version that works on GHC 8.6, and that requires statistics == 0.15.*. The vector-binary-instances dependency was added in statistics 0.10.4.0, it seems. I think what happens is that, on older GHCs, an earlier version of criterion is picked with a low enough statistics bound that the vector-binary-instances dependency isn't present. Without that option, it fails as we see here.

@quasicomputational
Copy link
Contributor Author

Actually, thinking on it more, the bug should trigger on master, since it's also affecting the 7.10 and 8.0 builders. I'm not entirely sure why the solver isn't finding solutions that it previously could - maybe revisions?

@quasicomputational
Copy link
Contributor Author

quasicomputational commented Oct 2, 2018

I've got it and it's alarmingly simple: the previous .travis.yml script doesn't build the benchmarks, but the new one does. I don't know how to get the regeneration script to do that; there is a --no-no-tests-no-bench but no corresponding --no-tests-no-bench flag? Uncommenting the commented out env line doesn't stick through regenerations, either.

@RyanGlScott
Copy link
Contributor

Indeed, I don't believe such an option exists. That being said, I don't think we should let this issue be a blocker. For the time being, I think manually removing any uses of --enable-benchmarks would be the simplest solution.

In the long term, what we should look into is putting the benchmarks into a separate .cabal file (à la primitive) and build the benchmarks as a separate component. This would avoid dependency cycles, since we could simply build criterion afresh each time based on the in-place version of vector-binary-instances. (If rebuilding many dependencies on each Travis build is a concern, we could alternatively switch over to using gauge instead, which does not depend on vector-binary-instances.)

@quasicomputational
Copy link
Contributor Author

Sounds sensible. I've gone ahead and hand-edited .travis.yml.

@RyanGlScott
Copy link
Contributor

I've opened #16 to get rid of the manual hacks we had to put in the generated .travis.yml file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants