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

pretty up src/Stack/Package.hs #3384

Merged
merged 13 commits into from
Aug 29, 2017

Conversation

kadoban
Copy link
Collaborator

@kadoban kadoban commented Aug 24, 2017

Use $pretty* functions where appropriate in src/Stack/Package.hs.

Related to #2650

b85364d is probably the commit most in need of review, had to do some things I barely understood to get that working.

  • Any changes that could be relevant to users have been recorded in the ChangeLog.md
  • The documentation has been updated, if necessary.

@kadoban
Copy link
Collaborator Author

kadoban commented Aug 24, 2017

Hmm, somehow I thought there was more to do in that module. This might be less WIP than I thought. I still haven't really reviewed my work though, and there's a few TODOs I added that I can maybe resolve if I look around a bit. Will try to do that tomorrow.

@kadoban kadoban force-pushed the pretty-s-s-package branch 2 times, most recently from 3fa7078 to 312f14d Compare August 24, 2017 16:49
@kadoban kadoban changed the title [WIP] pretty up src/Stack/Package.hs pretty up src/Stack/Package.hs Aug 24, 2017
@mgsloan
Copy link
Contributor

mgsloan commented Aug 24, 2017

LGTM! Just one comment to address. I like the Ctx refactoring.

where
dispPoss = styleFile . fromString . toFilePath
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think display can be used instead because there is an instance for Path t File.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, thanks!

@kadoban
Copy link
Collaborator Author

kadoban commented Aug 24, 2017

Did that one change, nice catch.

Cool, thanks. Was hoping that Ctx part made sense. I might actually be getting a handle on what those Has* typeclasses mean, heh. They seem quite nice in practice. Need to learn more lens sometime still though.

showName (DotCabalMain fp) = fp
showName (DotCabalFile fp) = fp
showName (DotCabalCFile fp) = fp
dispOne = fromString . toFilePath
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is unfortunate, I can't figure out exactly why this can't be display instead of dispOne in this function. I get the error:

    • Couldn't match type ‘Ann (Path b t)’ with ‘AnsiAnn’
      Expected type: Path b t -> AnsiDoc
        Actual type: Path b t -> Doc (Ann (Path b t))
    • In the first argument of ‘map’, namely ‘display’
      In the first argument of ‘bulletedList’, namely
        ‘(map display rest)’
      In the second argument of ‘(<>)’, namely
        ‘bulletedList (map display rest)’
    • Relevant bindings include
        rest :: [Path b t] (bound at src/Stack/Package.hs:1146:29)
        candidate :: Path b t (bound at src/Stack/Package.hs:1146:19)
        warnMultiple :: DotCabalDescriptor
                        -> Path b t -> [Path b t] -> m ()
          (bound at src/Stack/Package.hs:1146:1)

when I try.

Copy link
Collaborator Author

@kadoban kadoban Aug 24, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Must be something about Path b t being polymorphic? A little confused. Adding a Display (Path b t) constraint to the function type doesn't help either.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's because it's polymorphic. I think adding Display (Path b t) to the function's constraints should solve the problem. Alternatively, just make it monomorpic, I think it's just used for (Path Abs File) or something.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, thanks for looking at it. I thought I tried that constraint and got the same error. Very possible I screwed it up though. I'll investigate more.

@mgsloan
Copy link
Contributor

mgsloan commented Aug 28, 2017

LGTM. Nice idea to use hlint for this! Though, I think there could be cases where fromString . toFilePath is used to create a type other than AnsiDoc. Not a big deal though, lets see if those cases ever crop up.

Will need to be updated due to changes merged in #3389

showName (DotCabalMain fp) = fp
showName (DotCabalFile fp) = fp
showName (DotCabalCFile fp) = fp
dispOne = fromString . toFilePath
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's because it's polymorphic. I think adding Display (Path b t) to the function's constraints should solve the problem. Alternatively, just make it monomorpic, I think it's just used for (Path Abs File) or something.

@kadoban kadoban force-pushed the pretty-s-s-package branch from 95eb29d to 1ee0583 Compare August 29, 2017 06:11
@kadoban
Copy link
Collaborator Author

kadoban commented Aug 29, 2017

LGTM. Nice idea to use hlint for this! Though, I think there could be cases where fromString . toFilePath is used to create a type other than AnsiDoc. Not a big deal though, lets see if those cases ever crop up.

Thanks! Yeah, hopefully not many. If there's only a few we can just add exceptions for them. Can definitely re-evaluate if they pop up all over.

Will need to be updated due to changes merged in #3389

Hopefully just did that, crossing fingers for the CI builds.

Edit: hmm, not going to build. Will have a bit more work to do unfortunately. Need to either make the pretty* function types more general, or make a lot of the functions in s/S/Package.hs more specific. Or something.

@mgsloan
Copy link
Contributor

mgsloan commented Aug 29, 2017

Generalizing to something like (HasCallStack, HasRunner env, MonadReader env m, MonadLogger m) should do the trick

@kadoban kadoban force-pushed the pretty-s-s-package branch from 1ee0583 to 0722dd5 Compare August 29, 2017 13:45
@kadoban
Copy link
Collaborator Author

kadoban commented Aug 29, 2017

Yep, that seemed to do the trick, thanks. Now to investigate that Display (Path b t) thing while waiting for CI.

@mgsloan
Copy link
Contributor

mgsloan commented Aug 29, 2017

Cool, looks like CI is passing, feel free to merge this.

@kadoban
Copy link
Collaborator Author

kadoban commented Aug 29, 2017

That works, I'll just come back to the Display thing for Path b t later, there's a TODO in there at least. can't seem to figure that one out though, heh.

On to finishing up terminal detection I hope :)

@kadoban kadoban merged commit 2fbc3e9 into commercialhaskell:master Aug 29, 2017
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.

2 participants