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

Added version information to haddock page title of executables #1336 #3959

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

holzensp
Copy link

@holzensp holzensp commented Oct 8, 2016

Minor request; add version numbers to the page titles of the haddock documentation of executables.

@mention-bot
Copy link

@holzensp, thanks for your PR! By analyzing the history of the files in this pull request, we identified @dcoutts, @igfoo and @23Skidoo to be potential reviewers.

}
fromLibrary :: PackageDescription
-> Library
-> Verbosity
Copy link
Member

Choose a reason for hiding this comment

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

By convention, the Verbosity argument should go first.

Copy link
Author

Choose a reason for hiding this comment

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

Opted for this to not have to eta-expand things. I'll change.

fromExecutable :: Verbosity
fromExecutable :: PackageDescription
-> Executable
-> Verbosity
Copy link
Member

Choose a reason for hiding this comment

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

Same here.

Copy link
Author

Choose a reason for hiding this comment

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

^^ ditto

type ModuleFiles = [(ModuleName.ModuleName, FilePath)]
fromTarget :: (LocalBuildInfo -> ComponentLocalBuildInfo
-> target -> IO ModuleFiles)
-> (HaddockArgs -> HaddockArgs)
Copy link
Member

Choose a reason for hiding this comment

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

This argument seems unnecessary -- you can just do amendArgs <$> fromTarget ... in fromLibrary/fromExe.

Copy link
Author

Choose a reason for hiding this comment

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

Ouch... you're right. This is incremental hacking. Good catch

fromLibrary verbosity tmp lbi lib clbi htmlTemplate haddockVersion = do
inFiles <- map snd `fmap` getLibSourceFiles lbi lib clbi
type ModuleFiles = [(ModuleName.ModuleName, FilePath)]
fromTarget :: (LocalBuildInfo -> ComponentLocalBuildInfo
Copy link
Member

Choose a reason for hiding this comment

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

Bikeshedding: I'd rename it to fromLibOrExe.

Copy link
Contributor

Choose a reason for hiding this comment

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

In principle we could Haddock tests and executables, couldn't we? Given the type signature fromTarget seems appropriate.

Copy link
Author

Choose a reason for hiding this comment

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

I'm not passionate either way, but considering @ezyang's comment, I'll stick with fromTarget

Copy link
Member

Choose a reason for hiding this comment

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

OK.

@23Skidoo
Copy link
Member

23Skidoo commented Oct 8, 2016

Looks OK. In the future, can you please split refactorings and functionality changes into different commits?

inFiles <- map snd `fmap` getLibSourceFiles lbi lib clbi
type ModuleFiles = [(ModuleName.ModuleName, FilePath)]
fromTarget :: (LocalBuildInfo -> ComponentLocalBuildInfo
-> target -> IO ModuleFiles)
Copy link
Contributor

@ezyang ezyang Oct 8, 2016

Choose a reason for hiding this comment

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

In general, if you have a higher-order argument like this, doc is especially important. In this case, the passed in function is supposed to list the sources of the module in question. But why isn't just inFiles passed in as an argument? (UPDATE: I guess the answer is, "because it saves less typing at the use site")

Copy link
Author

Choose a reason for hiding this comment

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

Yes, it was of typing at the use site... It's a subjective trade-off, but I went for compactness.

fromExecutable verbosity tmp lbi exe clbi htmlTemplate haddockVersion = do
inFiles <- map snd `fmap` getExeSourceFiles lbi exe clbi
ifaceArgs <- getInterfaces verbosity lbi clbi htmlTemplate
let vanillaOpts = (componentGhcOptions normal lbi bi clbi (buildDir lbi)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

The rest of the comments are just stylistic fluff (and can be ignored), but this has got me worried. I don't see this code anywhere in the new diff. This code seems to be solving a very specific problem (interface file overwriting) and I don't see (1) any code in the new diff to handle it, or (2) a comment in the commit saying why this is not a problem anymore. It's possible it isn't (esp if the CI passes) but that is very non-obvious!

Copy link
Author

Choose a reason for hiding this comment

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

Line 295 in the new version (fromTarget); did I miss something?

Copy link
Contributor

Choose a reason for hiding this comment

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

You are right! This is what I get for assuming that the original code hadn't copy-pasted the damn code :)

Copy link
Author

@holzensp holzensp left a comment

Choose a reason for hiding this comment

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

On splitting out into separate diffs (@23Skidoo); yes, you're right. Things had already happened when I realised. Apologies for the conflation.

inFiles <- map snd `fmap` getLibSourceFiles lbi lib clbi
type ModuleFiles = [(ModuleName.ModuleName, FilePath)]
fromTarget :: (LocalBuildInfo -> ComponentLocalBuildInfo
-> target -> IO ModuleFiles)
Copy link
Author

Choose a reason for hiding this comment

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

Yes, it was of typing at the use site... It's a subjective trade-off, but I went for compactness.

type ModuleFiles = [(ModuleName.ModuleName, FilePath)]
fromTarget :: (LocalBuildInfo -> ComponentLocalBuildInfo
-> target -> IO ModuleFiles)
-> (HaddockArgs -> HaddockArgs)
Copy link
Author

Choose a reason for hiding this comment

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

Ouch... you're right. This is incremental hacking. Good catch

}
fromLibrary :: PackageDescription
-> Library
-> Verbosity
Copy link
Author

Choose a reason for hiding this comment

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

Opted for this to not have to eta-expand things. I'll change.

fromLibrary verbosity tmp lbi lib clbi htmlTemplate haddockVersion = do
inFiles <- map snd `fmap` getLibSourceFiles lbi lib clbi
type ModuleFiles = [(ModuleName.ModuleName, FilePath)]
fromTarget :: (LocalBuildInfo -> ComponentLocalBuildInfo
Copy link
Author

Choose a reason for hiding this comment

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

I'm not passionate either way, but considering @ezyang's comment, I'll stick with fromTarget

fromExecutable :: Verbosity
fromExecutable :: PackageDescription
-> Executable
-> Verbosity
Copy link
Author

Choose a reason for hiding this comment

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

^^ ditto

fromExecutable verbosity tmp lbi exe clbi htmlTemplate haddockVersion = do
inFiles <- map snd `fmap` getExeSourceFiles lbi exe clbi
ifaceArgs <- getInterfaces verbosity lbi clbi htmlTemplate
let vanillaOpts = (componentGhcOptions normal lbi bi clbi (buildDir lbi)) {
Copy link
Author

Choose a reason for hiding this comment

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

Line 295 in the new version (fromTarget); did I miss something?

@ezyang
Copy link
Contributor

ezyang commented Oct 15, 2016

I'm OK with merging this!

@23Skidoo
Copy link
Member

IIUC, @holzensp wants to address some review comments before merging.

@Mikolaj
Copy link
Member

Mikolaj commented May 26, 2021

@holzensp: hi! would you like to rebase/revisit this PR? I'm assuming the functionality is not implemented elsewhere, but if while rebasing you find that it is, this is also good to know and perhaps the current implementation may be improved using this old PR.

@mergify mergify bot added the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Sep 1, 2022
@ulysses4ever ulysses4ever removed the merge delay passed Applied (usually by Mergify) when PR approved and received no updates for 2 days label Sep 3, 2022
@Kleidukos
Copy link
Member

Marking this PR as draft 🙂

@Kleidukos Kleidukos marked this pull request as draft May 17, 2023 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants