I want to run hoogle on a project of mine. I successfully generated the hoogle database (a file with .hoo extension) from my project.
But when I run the server locally, hoogle cannot find any of the functions or types that are defined in my project.
It can find some of the prelude functions such as map, but none of the functions that are defined in my project.
hoogle dump my-project.hoo dumps the content with no error.
I also moved my-project.hoo to ~/.cabal/share/x86_64-osx-ghc-7.8.4/hoogle-4.2.38/databases where all the .hoo files reside. No success again.
-verbose switch also does not output any useful information.
Any suggestion is appreciated.
Edit:
Thanks to mhuesch's suggestion, I was able to get the search results. Although, the returned results are not linked to the local hackage documents. Something that I couldn't find anywhere on the web is that the hoogle server looks for a file called default.hoo in the current directory.
Edit 2:
If you, like me, have 5000+ databases (i.e., .hoo files) you may get a "too many open files" error when combining them. The trick is simple: run hoogle combine x*.hoo -o=parts/x.hoo for all x='a' ... 'z' and then run hoogle combine *.hoo -o=default.hoo in the parts folder.
Edit 3:
If you want to link your hoogle search results with local hackage documentation,
use hoogle convert --doc='absolute-path-to-your-doc' your-package-hoogle-doc.txt default.hoo.
I couldn't get relative path working.
Hoogle searches the current directory (where the command hoogle is run) for a database called 'default.hoo', so if you rename your database to that it should find it.
To add it to the database in your cabal directory, I believe this should work (taken from http://newartisans.com/2012/09/running-a-fully-local-hoogle/):
cd {...path to hoogle databases dir...}
mv default.hoo default.hoo-prev
hoogle combine *.hoo
Edit: (in response on Oxy's edits)
My knowledge of default.hoo comes from here. It seems to doesn't seem to be very well know.
hoobuddy (the above linked project), while cool, doesn't seem to address what you want. I think the key to that is in the help of hoogle data
$ hoogle data --help
...
-l --local[=FILEPATH] Use local documentation if available
...
I haven't done it myself so I am not sure. The author of this writeup achieved local documentation linking by compiling hoogle from source and adding his local docs directory. I think that you can avoid that by using hoogle data.
Related
I would like to look at the code of functions defined in modules, such as Data.List or Data.Map.
I can import Data.List module with
import Data.List
and then I can use the functions nub or sort.
I would like to know where I can find these functions to look at their code.
In which directory are the modules installed by default?
PS: Windows 8.1, I installed Haskell Platform.
That directory contains compiled modules, so you wouldn't be able to read the source there.
What you can do is to find your function in online documentation and then click "Source" on the right.
As #arrowd notes in his answer,
That directory contains compiled modules, so you wouldn't be able to
read the source there.
The GHC repo (and its Github mirror) can be directly browsed, but there is an easier way:
Use Hoogle or Stackage to find the package where the module/function resides
Note that Hoogle and Stackage are case-sensitive. (It's best to look up modules with their capitalized names.)
A query for sort in Hoogle yields a list similar to the one below. Stackage has a slightly different style, but the basics are the same (mostly because it uses Hoogle for lookup). The lines in green under the result headings show the name(s) of the containing
(1) package(s) (in small caps) and
(2) module(s) (capitalized).
There can be multiple functions with the same name, but the module and package name helps to choose the right one.
Click on the function/module name
Click on "#Source"
I work with the Yocto Project quite a bit and a common challenge is determining why (or from what recipe) a file has been included on the rootfs. This is something that can hopefully be derived from the build system's environment, log & meta data. Ideally, a set of commands would allow linking a file back to a source (ie. recipe).
My usual strategy is to perform searches on the meta data (e.g. grep -R filename ../layers/*) and searches on the internet of said filenames to find clues of possible responsible recipes. However, this is not always very effective. In many cases, filenames are not explicitly stated within a recipe. Additionally, there are many cases where a filename is provided by multiple recipes which leads to additional work to find which recipe ultimately supplied it. There are of course many other clues available to find the answer. Regardless, this investigation is often quite laborious when it seems the build system should have enough information to make resolving the answer simple.
This is exact use case for oe-pkgdata-util script and its subcommand find-path. That script is part of openembedded-core.
See this example (executed in OE build environment, i.e. bitbake works):
tom#pc:~/oe/build> oe-pkgdata-util find-path /lib/ld-2.24.so
glibc: /lib/ld-2.24.so
You can clearly see that this library belongs to glibc recipe.
oe-pkgdata-util has more useful subcommands to see information about packages and recipes, it worth to check the --help.
If you prefer a graphical presentation, the Toaster web UI will also show you this, plus dependency information.
The candidate files deployed for each recipe are placed in each $WORKDIR/image
So you can cd to
$ cd ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}
and perform a
$ find . -path '*/image/*/fileYouAreLookingFor'
from the result you should be able to infer the ${PN} of the recipe which deploys such file.
For example:
$ find . -path '*/image/*/mc'
./bash-completion/2.4-r0/image/usr/share/bash-completion/completions/mc
./mc/4.8.18-r0/image/usr/share/mc
./mc/4.8.18-r0/image/usr/bin/mc
./mc/4.8.18-r0/image/usr/libexec/mc
./mc/4.8.18-r0/image/etc/mc
How do I find the source of the code I am importing. Like if I do
λ <Prelude>: import Graphics.EasyPlot
λ <Prelude Graphics.EasyPlot>:
How do I find that code. I do not mean an online copy of the code (Google is very good at indexing Hackage by that) but where it is on my system that I can edit. The reason is that it is a bit buggy, and I want to try and fix it. (I might submit a patch, but I just want to fix it for my own use first.)
As #ThomasDuBuisson mentioned, you many not necessarily find that on your system. One thing which I generally do is fetch it using cabal:
cabal fetch package-name
It downloads the tarballs of the package. Once you have fetched it, the entire source will be under the path where cabal puts it. In my case, it is (/home/sibi/.cabal/packages/hackage.haskell.org/package-name ). You can then untar and then build it from the cabal file which is already present there.
That being said you should probably using the version control system which the project is using as #bheklilr pointed out.
What are the possibilities, if any, for getting offline docs for Haskell core libraries (and maybe more)?
Sometimes I take my laptop to the coffee-shop where there is no wifi, and it would be nice having something like Hoogle but for offline use.
Hoogle is available offline, installable from Cabal: http://hackage.haskell.org/package/hoogle
Usage instructions are at http://www.haskell.org/haskellwiki/Hoogle#Command_Line_Search_Flags.
Usage:
$ hoogle --help
Hoogle v4.2.8, (C) Neil Mitchell 2004-2011
http://haskell.org/hoogle
hoogle [COMMAND] ... [OPTIONS]
Commands:
[search] Perform a search
data Generate Hoogle databases
server Start a Hoogle server
combine Combine multiple databases into one
convert Convert an input file to a database
test Run tests
dump Dump sections of a database to stdout
rank Generate ranking information
log Analyse log files
Common flags:
-? --help Display help message
-V --version Print version information
-v --verbose Loud verbosity
-q --quiet Quiet verbosity
Create a default database with hoogle data (more info at http://neilmitchell.blogspot.com/2008/08/hoogle-database-generation.html).
EDIT: A session of usage after installing Hoogle locally:
$ hoogle
No query entered
Try --help for command line options
$ hoogle data
(downloads databases...takes a few minutes)
I ran into an error here...apparently it is related to the version of Cabal, so I updated that (http://hackage.haskell.org/trac/hackage/ticket/811). That didn't help, so I ran hoogle data all, which I canceled since it was taking so long (it seems to go through every package on Hackage). It still wouldn't allow a query like hoogle map but did allow hoogle map +base (i.e. restrict the search to the base package) Hopefully it works for you!
EDIT2: This seems to fix the problem (for me):
$cd .cabal/share/hoogle-4.2.8/databases
$hoogle combine base.hoo
$hoogle foldl\'
Data.List foldl' :: (a -> b -> a) -> a -> [b] -> a
Data.Foldable foldl' :: Foldable t => (a -> b -> a) -> a -> t b -> a
The HTML documentation can be downloaded as .tar.bz2 from the Haskell website:
https://downloads.haskell.org/~ghc/latest/docs/
I just downloaded https://www.haskell.org/ghc/docs/7.6.3/libraries.html.tar.bz2 and it's exactly what I've been hoping for.
There are also other options, such as Dash and Zeal, and see also that reddit thread.
If you install the Haskell Platform it includes the GHC docs and the GHC library docs (which cover the core libraries). On Windows they are on the Start Menu under "All Programs|Haskell Platform".
Edit your ~/.cabal/config file. Look for the line (probably commented out) that says documentation: False. Change that line to documentation: True and uncomment it. Now when you build projects with cabal install documentation will also be built and saved locally.
Look around a little more in that same config file and you'll find things options like doc-index-file, docdir, datadir, prefix, etc that allow you to configure where the documentation is stored.
It may not be "canonical" per se, but i believe that the most useful option is a docset software like dash(OS X)/zeal + generated docsets. This way you'll get the search for free and also will have an option to build your custom docsets. It's no problem to get the 'base' package haddock documentation with either of the projects out of the box. You can build custom docsets with haddocset or dash-haskell. Also it integrates nicely with emacs/vim/other editors, allows you to have project-based docsets(you'll have the relevant versions on a per-project basis this way, forget all this hassle with local hoogle!) and don't restrict you to any build flow you can have.
If you build your project with cabal-install you can set documentation: True in your ~/.cabal/config, then reinstall dependencies to get generated haddocks locally.
If you're using stack, you can utilize stack haddock command to build your dependencies and project with generated haddocks.
I use devdocs.io, it has docs for a lot of languages and libraries (including Haskell) and has an offline mode.
Velocity is a free and beautiful universal tool to do just that. It supports a wide range of languages, technologies and libraries, and one click updating.
You will probably be able to find more of what you are already using in its documentation list.
For Windows, install cygwin's wget and curl packages. That will enable hoogle data.
If you happen to be using a Debian derived distribution and their packages, then you will find the combined documentation of all installed Haskell packages (if you also install the libghc-foo-doc packages) at
file:///usr/share/doc/ghc-doc/html/libraries/index.html
Furthermore, the libghc-foo-doc packages contain the necessary files for hoogle, so if you apt-get install hoogle, then you should immediately be able to use hoogle to search through all libraries installed this way.
In this instance I'm using c with autoconf, but the question applies elsewhere.
I have a glade xml file that is needed at runtime, and I have to tell the application where it is. I'm using autoconf to define a variable in my code that points to the "specified prefix directory"/app-name/glade. But that only begins to work once the application is installed. What if I want to run the program before that point? Is there a standard way to determine what paths should be checked for application data?
Thanks
Thanks for the responses. To clarify, I don't need to know where the app data is installed (eg by searching in /usr,usr/local,etc etc), the configure script does that. The problem was more determining whether the app has been installed yet. I guess I'll just check in install location first, and if not then in "./src/foo.glade".
I dont think there's any standard way on how to locate such data.
I'd personally do it in a way that i'd have a list of paths and i'd locate if i can find the file from anyone of those and the list should containt the DATADIR+APPNAME defined from autoconf and CURRENTDIRECTORY+POSSIBLE_PREFIX where prefix might be some folder from your build root.
But in any case, dont forget to use those defines from autoconf for your data files, those make your software easier to package (like deb/rpm)
There is no prescription how this should be done in general, but Debian packagers usually installs the application data somewhere in /usr/share, /usr/lib, et cetera. They may also patch the software to make it read from appropriate locations. You can see the Debian policy for more information.
I can however say a few words how I do it. First, I don't expect to find the file in a single directory; I first create a list of directories that I iterate through in my wrapper around fopen(). This is the order in which I believe the file reading should be done:
current directory (obviously)
~/.program-name
$(datadir)/program-name
$(datadir) is a variable you can use in Makefile.am. Example:
AM_CPPFLAGS = $(ASSERT_FLAGS) $(DEBUG_FLAGS) $(SDLGFX_FLAGS) $(OPENGL_FLAGS) -DDESTDIRS=\"$(prefix):$(datadir)/:$(datadir)/program-name/\"
This of course depends on your output from configure and how your configure.ac looks like.
So, just make a wrapper that will iterate through the locations and get the data from those dirs. Something like a PATH variable, except you implement the iteration.
After writing this post, I noticed I need to clean up our implementation in this project, but it can serve as a nice start. Take a look at our Makefile.am for using $(datadir) and our util.cpp and util.h for a simple wrapper (yatc_fopen()). We also have yatc_find_file() in case some third-party library is doing the fopen()ing, such as SDL_image or libxml2.
If the program is installed globally:
/usr/share/app-name/glade.xml
If you want the program to work without being installed (i.e. just extract a tarball), put it in the program's directory.
I don't think there is a standard way of placing files. I build it into the program, and I don't limit it to one location.
It depends on how much customising of the config file is going to be required.
I start by constructing a list of default directories and work through them until I find an instance of glade.xml and stop looking, or not find it and exit with an error. Good candidates for the default list are /etc, /usr/share/app-name, /usr/local/etc.
If the file is designed to be customizable, before I look through the default directories, I have a list of user files and paths and work through them. If it doesn't find one of the user versions, then I look in the list of default directories. Good candidates for the user config files are ~/.glade.xml or ~/.app-name/glade.xml or ~/.app-name/.glade.xml.