what the heck is goinjg on here

[Peaker]

The hoogle package is very useful to search the standard library. Unfortunately, it does not search packages that you have installed which are not part of the stdlib.

It would be great if every package installed always had its haddock generated, and from its .txt file a .hoo file was generated (e.g: hoogle --convert), and then all .hoo files sat in some centralized directory which hoogle would then use for its searches.

This would be great documentation, and let you hoogle for anything that you can import.

[Peaker]

Using hoogle --convert on the .txt files directly will not work until this bug is fixed:  http://hackage.haskell.org/trac/ghc/ticket/2766

[guest]

#3766 has been fixed.

More importantly, I'm not sure it was a problem. I'm still on 6.10.1, but my Hoogle had no problem converting an xmonad-contrib.txt and searching the .hoo file.

[guest]

#3766 would only have been a problem for certain libraries, so it won't effect most things.

This would be great if someone could do it :-) I'll do any Hoogle changes that are necessary, but don't have time to do the Cabal side.

[guest]

I don't think many Hoogle changes are necessary, but it's unclear how it's going to be handled. Is Cabal going to dump .hoo files into Hoogle's data-directory, or should Hoogle be going and looking elsewhere for .hoo files or what?

Personally, I like the idea of Cabal dumping the generated .hoo file into Cabal's data-directory myself. Simple.

But that opens other questions. As ndm says, 'Hoogle could look in the same directory as haddock does for its documentation databases, Hoogle could dump its path to stdout, hoogle could dump the converted files to its path'.

Here again I favor the simple solution of dumping the path to stdout, but another possibility is exposing Hoogle's library and thus Paths_hoogle (I think that'd work).

Finally, there becomes the question of what .hoos Hoogle should look in by default. ndm: "There should certainly be an all database, and an all libraries on hackage database, and an all installed libraries database. Which one of those is default is a good question, I'd guess at all installed libraries - but not certain."

[dschoepe]

This patch should resolve this issue at least on cabal-install's part:  http://article.gmane.org/gmane.comp.lang.haskell.cabal.devel/6566

The question of what is a good default for hoogle still remains though.

[dschoepe]

I've been using my patch for the past few months now and it appears to work fine, so once the required haddock-patch(about generating hoogle and html output in one call[1]) is applied, this patch should be ready to be applied.

[1]  http://thread.gmane.org/gmane.comp.lang.haskell.cabal.devel/5617

[duncan]

I applied the other patch about generating hoogle and html output in one go. I've looked at this patch but I think it needs a bit more thought.

So, the general idea is to create a binary .hoo file for each package right? Generating a merged binary database would be a separate task, not covered by this patch. There are two issues:

1. The code in the doc step of cabal-install is assuming a certain layout of the build tree by reading and writing files directly in the build tree. This will not work for packages using build-type custom. It would be ok if we were copying into a temporary image dir before doing the real installation. In that case writing extra files into the temporary image dir would be fine. As it is, I think this feature of generating a per-package .hoo db would be better in the build system itself, in the Cabal lib.
2. according to the  hoogle manual, the .hoo files of dependencies need to be specified as well.

Since each .txt can be converted into a .hoo, and the final .hoo is not really useful except as something to use to merge into a db that users will actually use, perhaps it would be better to just generate the .txt files per-package and then generate a big merged one. Alternatively, why generate the .txt files if we could just generate the .hoo files?

Is there any point in generating both .txt and .hoo files for each package?

More minor comments about the patch. It should use the existing framework for running programs. This would cut down on the code and integrate it properly with the Cabal exception handling and logging stuff.

[elga]

*  virgin mobile

[edouard]

D'autre part, la pauntte d'informations detaillees relatives a l'obtention du code rio Simyo et du code rio Virgin Mobile sont egalement disponibles.  simyo