-
Notifications
You must be signed in to change notification settings - Fork 19
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
WIP: move to Cabal 2.2 #42
Conversation
Wow, this is quite a PR! Give me a bit of time to review it, but I'll take a look. Thanks! |
If it makes it less intimidating, by lines changed it's about 50% generated by |
d3d6cc8
to
81325f4
Compare
I've fixed the code style, and there's a bare-bones test that ought to exercise all the SPDX code going both ways (and which indeed found some bugs). Thoughts particularly wanted on the Dhall-side API for SPDX things; have a look at |
I haven't forgotten about this, but I'm really short on time atm. I will try and get to it soon! |
47f9e31
to
07c6e4d
Compare
I think this is gonna be good to go. Can you merge in |
I'll rebase once #64 lands. |
Actually, #64 shouldn't cause a big merging headache, so I'll go ahead and rebase now and see what the damage is. |
07c6e4d
to
322f2e3
Compare
I'll push a commit that fixes the Nix stuff. |
I've just realised that all those SPDX licenses are going to blow up |
@Gabriel439 The above build has failed because Hydra is out of disk space. You might want to enable automatic GC. |
@ocharles: I do enable automatic GC. It's just that the machine only has 20 GB of disk space. I'm going to try to upgrade the disk space |
02363be
to
21d31d0
Compare
This PR is severely damaging performance (factor of ~5 slowdown over HEAD running the tests), which I assume is because of the enormous On master:
On this branch:
|
I have been investigating the performance woes, and it's Dhall's typechecking that's taking 90% of the time when I convert My current theory is that this is mostly due to how, when the I've also got a tiny little patch that's an immediate 40% win, but it definitely doesn't solve the problem and the performance is still totally unacceptable. |
3363e35
to
2136e65
Compare
I've opened dhall-lang/dhall-haskell#412 about the performance issue. Looks like it might be entirely a |
I think either way, it'd be good to get this in as it's a pretty huge branch. Could you get the conflicts resolved? |
The biggest change is the introduction of SPDX licenses, which have to be reflected in Dhall; about half of the lines added are just license identifiers.
f95e67a
to
341d7b8
Compare
Rebased and squashed down. |
Here's the test suite's output with dhall-lang/dhall-haskell#420 applied on top of dhall-haskell HEAD:
So, in a bizarre coincidence, we're back to roughly where we were, performance-wise, though some of the individual test numbers have moved and we're running more tests now (though I wouldn't be surprised if that was more due to the parser speed-ups than the typechecking ones). I was half hoping that fixing the big performance loss would've improved things over-all in a big way, but I guess we're not so lucky. |
Merged! 🎉 Thanks so much for this contribution, it looks like a lot of work went into this. |
It compiles and
dhall-to-cabal dhall-to-cabal.dhall
works, but:VersionRange
is handled, and I've tried to make it sane and ergonomic.