Whenever xmonad starts, restarts, or is recompiled, I get an xmessage:
xmonad.hs:1:8:
Could not find module `XMonad'
Perhaps you meant
Monad (needs flag -package haskell98-2.0.0.2)
CgMonad (needs flag -package ghc-7.6.3)
DsMonad (needs flag -package ghc-7.6.3)
Use -v to see a list of the files searched for
This doesn't stop it from starting, but I only see updates to xmonad or xmobar settings on system reboot. My current xmonad.hs is just
import XMonad
main = xmonad defaultConfig
and it still produces the error. Any attempts to import other modules give similar results. I have both xmonad and xmonad-contrib installed from the Arch repositories, so the modules should be properly in the ghc search path, right? I've tried reinstalling the packages from Cabal like some other sources have suggested, but it turned into a complete snafu, so I went back to the Arch repos, which ought to work. Kind of at a loss for where to go from here; any help would be greatly appreciated.
EDIT: ghc-pkg list xmonad returns
/usr/lib/ghc-7.6.3/packag.conf.d
xmonad-0.11
/home/decalis/.ghc/x86_64-linux-7.6.3/package.conf.d
and ghc-pkg check output is here: http://pastebin.com/BsCPMn8M. The issue is a little clearer after seeing that, but I still don't get why it's looking in ~/.cabal when all of the packages and their dependencies were resolved from the Arch repos by pacman.
For me the solution was to run ghc-pkg recache since the ghc cache was just out of sync for some reason. It's worth trying before wiping the whole ghc database.
In cases like this one of the first things to try is to "start from scratch", i.e. forget about all the local packages that you might have installed in the past.
To do this, wipe (or rename/move) ghc's package database, which is under ~/.ghc/$arch-$os-$ghcver (such as ~/.ghc/i386-linux-7.6.3). Or just remove ~/.ghc altogether.
Related
I'm trying to load my .hs file but when I import Data.Numbers.CReal, it gives me the error Failed to load interface for 'Data.Numbers.CReal'. I have runned cabal install numbers and if I cabal list --installed the number pkg appears, but if I ghc-pkg list it doesn't (also if I ghc-pkg checkit gives LOTS of haddock warnings). Is it related to my non-loading file? How can I solve this?
Ps. I know how to import packages, but I'm not sure if I am importing this one properly.
Thanks and sorry if I didn't explained myself correctly.
Two hypotheses spring to mind:
cabal is choosing a different version of ghc and its attending toolsuite than your shell is. You can check for this discrepancy by running these two commands:
cabal exec -- ghc --version
ghc --version
Do they say the same thing? If so, reject this hypothesis. Otherwise you should decide whether you like the shell's choice or cabal's choice better (I recommend preferring your shell's choice).
If you like cabal's choice better, you can use a specific version of GHC (and other GHC tools) by appending -<version> to the command; e.g. try ghc-pkg-7.10.3 list to see what is in the package database for version 7.10.3, or ghci-7.10.3 to run a specific version of the REPL. You can make these changes permanent by adding symlinks or similar to your PATH.
If you like your shell's choice better, you can ask cabal to use that version with cabal configure -w ghc; or if you are worried that cabal and your shell will resolve ghc differently, you could ask for a specific version with cabal configure -w ghc-7.10.3 or similar.
Your shell agrees with cabal about what version of GHC to use, but you are in a cabal sandbox. cabal list --installed is telling you what's installed in the sandbox, but ghc-pkg list is telling you what's installed in your user package database. You can check for discrepancies between these two commands:
cabal exec -- ghc-pkg list numbers
ghc-pkg list numbers
(If you have a newish cabal -- not sure which version this appeared in -- you could also try cabal hc-pkg list instead of cabal exec -- ghc-pkg list. This is likely to be the more forward-compatible way, so a good habit to develop.)
If these print the same things, reject this hypothesis. Otherwise you should decide whether you want to continue using a sandbox or not (I recommend continuing to use a sandbox).
If you want to stop using a sandbox, you can pass --ignore-sandbox to cabal. To make this permanent, look in the cabal.sandbox.config file, which will contain a pointer to the actual sandbox (usually .cabal.sandbox). Delete both the config and the sandbox. You can also globally ignore sandboxes by adding ignore-sandbox: True to your ~/.cabal/config, but I strongly recommend against this.
If you want to keep the sandbox, you will need to use cabal exec for all of your GHC toolsuite needs to make sure the correct package database is selected. For example, try cabal exec ghci to run the REPL with access to the sandbox package database.
These hypotheses are not mutually exclusive: both may happen. In that case I strongly recommend choosing the final solution ("use cabal exec for all GHC toolsuite executions"), as it handles both problems transparently: the standard GHC toolsuite commands will be rewritten to refer to explicitly versioned ones (e.g. cabal exec ghc will actually execute ghc-7.10.3) and the environment will be set up to point at the correct package database.
The answer to this
You can check for this discrepancy by running these two commands:
cabal exec -- ghc --version
ghc --version
Do they say the same thing?
was yes. I don't remember the second option, but I've managed to solve it myself. What I specifically did was:
run the command "rm -rf .cabal" (without commmas) to delete the cabal configuration.
run "rm -rf .cabal-sandbox"
run "rm -rf .ghc"
cabal new-build cabal (not sure if this helped or not)
In admin mode (sudo) I edited the cabal config file and changed Ignore Sandbox to True --> would this give me problems in the future? should I change it back to false? please answer
Had to delete a cabal.sandbox.config that was giving some troubles
cabal install cabal-install
cabal update
Now the ghc-pkg list command and the cabal list --installed show both my installed packages, and they work without problems.
Ps. I gave detailed information from the process in case anyone needs it in the future. Still not sure what caused that cabal and ghc didn't show the same pkgs.
There are several things I'm confused about here, so I'll try to explain each of them as clearly as I can.
I've been trying to install the diagrams package for haskell, using cabal. I've seen it suggested to install packages using sandboxes, so that's what I did. Something that's not clear to me is exactly what a sandbox is - I understand that I can initialise one with cabal sandbox init and install packages inside of it with cabal install, but I don't see how to use those packages once they're installed.
I then tried to compile a test-script using ghc, which resulted in the following error:
diagramstutorial.lhs:3:10:
Could not find module 'Diagrams.Prelude'
Use -v to see a list of the files searched for.
With a similar error for another module that the script was supposed to load. These modules are definitely both included in the diagrams package, and cabal seems happy that the package is installed correctly. I expect there's something simple I just don't understand, but I don't know what it is.
I typed ghc --make diagramstutorial.lhs to compile it
That will make GHC use the regular user package database (that is, not the sandbox one). Use cabal exec -- ghc --make diagramstutorial.lhs instead, so that GHC runs in the context of your sandbox.
You can also use GHCi within the sandbox with cabal repl. And naturally, if/when you start preparing a cabal package, all cabal commands (cabal build, etc.) will use the sandbox if you are within its directory.
Something that's not clear to me is exactly what a sandbox is
A set of packages with an accompanying database local to the directory. Beyond the cabal.sandbox.config configuration file there is also a hidden directory .cabal-sandbox, in which diagrams and the other packages you installed lie.
Find the sandbox directory, and locate the packages.conf.d file.
For example, /home/user/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d
Rerun your GHC commands with the package-db flag:
ghci -package-db /home/user/.cabal-sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d --make diagramstutorial.lhs
Everything should now work
I'm experimenting a problem with the interaction between the ghc-mod plugin in emacs, and NixOS 14.04. Basically, once packages are installed via nix-env -i, they are visible from ghc and ghci, recognised by haskell-mode, but not found by ghc-mod.
To avoid information duplication, you can find all details, and the exact replication of the problem in a VM, in the bug ticket https://github.com/kazu-yamamoto/ghc-mod/issues/269
The current, default, package management set up for Haskell on NixOS does work will with packages that use the ghc-api, or similar (ghc-mod, hint, plugins, hell, ...) run time resources. It takes a little more work to create a Nix expression that integrates them well into the rest of the environment. It is called making a wrapper expression for the package, for an example look at how GHC is installed an operates on NixOS.
It is reasonable that this is difficult since you are trying to make a install procedure that is atomic, but interacts with an unknown number of other system packages with their own atomic installs and updates. It is doable, but there is a quicker work around.
Look at this example on the install page on the wiki. Instead of trying to create a ghc-mod package that works atomically you weld it on to ghc so ghc+ghc-mod is an atomic update.
I installed ghc+ghc-mod with the below install script added to my ~/.nixpkgs/nixpkgs.nix file.
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
# add more packages here
]);
Install package with something like:
nix-env -i hsEnv
or better most of the time:
nix-env -iA nixpkgs.haskellPackages.hsEnv
I have an alias for the above so I do not have to type it out every time. It is just:
nixh hsEnv
The down side of this method is that other Haskell packages installed with nix-env -i[A] will not work with the above installation. If I wanted to get everything working with the lens package then I would have to alter the install script to include lens like:
hsEnv = haskellPackages.ghcWithPackages (self : [
self.ghc
self.ghcMod
self.lens
# add more packages here
]);
and re-install. Nix does not seem to use a different installation for lens or ghc-mod in hsEnv and with the ghc from nix-env -i ghc so apparently only a little more needs to happen behind the scenes most of the time to combine existing packages in the above fashion.
ghc-mod installed fine with the above script but I have not tested out its integration with Emacs as of yet.
Additional notes added to the github thread
DanielG:
I'm having a bit of trouble working with this environment, I can't even get cabal install to behave properly :/ I'm just getting lots of errors like:
With Nix and NixOS you pretty much never use Cabal to install at the global level
Make sure to use sandboxes, if you are going to use cabal-install. You probably do not need it but its there and it works.
Use ghcWithPackages when installing packages like ghc-mod, hint, or anything needs heavy runtime awareness of existing package (They are hard to make atomic and ghcWithPackages gets around this for GHC).
If you are developing install the standard suite of posix tools with nix-env -i stdenv. NixOS does not force you to have your command line and PATH cultured with tools you do not necessarily need.
cabal assumes the existence a few standard tools such as ar, patch(I think), and a few others as well if memory services me right.
If you use the standard install method and/or ghcWithPackages when needed then NixOS will dedup, on a package level (If you plot a dependency tree they will point to the same package in /nix/store, nix-store --optimise can always dedup the store at a file level.), many packages automatically unlike cabal sandboxes.
Response to comment
[carlo#nixos:~]$ nix-env -iA nixos.pkgs.hsEnv
installing `haskell-env-ghc-7.6.3'
these derivations will be built:
/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv
building path(s) `/nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3'
building /nix/store/minf4s4libap8i02yhci83b54fvi1l2r-haskell-env-ghc-7.6.3
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
builder for `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed with exit code 2
error: build of `/nix/store/39dn9h2gnp1pyv2zwwcq3bvck2ydyg28-haskell-env-ghc-7.6.3.drv' failed
It is the line that starts with collision that tells you what is going wrong:
collision between `/nix/store/1jp3vsjcl8ydiy92lzyjclwr943vh5lx-ghc-7.6.3/bin/haddock' and `/nix/store/2dfv2pd0i5kcbbc3hb0ywdbik925c8p9-haskell-haddock-ghc7.6.3-2.13.2/bin/haddock' at /nix/store/9z6d76pz8rr7gci2n3igh5dqi7ac5xqj-builder.pl line 72.
It is a conflict between two different haddocks. Switch to a new profile and try again. Since this is a welding together ghc+packages it should not be installed in a profile with other Haskell packages. That does not stop you from running binaries and interrupters from both packages at once, they just need to be in their own name space so when you call haddock, cabal, ghc, there is only one choice per profile.
If you are not familiar with profiles yet you can use:
nix-env -S /nix/var/nix/profiles/per-user/<user>/<New profile name>
The default profile is either default or channels do not which one it will be for your set up. But check for it so you can switch back to it later. There are some tricks so that you do not have to use the /nix/var/nix/profiles/ directory to store you profiles to cut down on typing but that is the default location.
I have installed Leksah 0.12.0.3 on Windows 8 in C:\Leksah and the latest Haskell Platform in C:\HaskellPlatform.
I created a new workspace and package and added a module of my own (distinct from the Main one that Leksah creates). I can import and use this new module in the Main module, however Leksah does not show it in the right Browser pane no matter what I do - it only lists the Main module there. If I switch to System, that list is empty.
I have tried:
reinstalling Leksah and the Haskell Platform;
running ghc-pkg recache in a cmd ran as admin;
putting my workspace and package in paths without spaces.
Still, no luck. Also, in the console that opens along with Leksah, I see this when my workspace / package open:
Using default Yi configuration
Warning: D:\Haskell\TestPackage\TestPackage.cabal: A package using section
syntax must specify at least
'cabal-version: >= 1.2'.
Now updating system metadata ...
***server start
Bind 127.0.0.1:26411
Metadata collector has nothing to do
Metadata collection has finished
Now loading metadata ...
Now updating workspace metadata ...
Can't extract module C:\Users\Vlad\.leksah-0.12\metadata\TestPackage-1\Test.lksh
e <command line>: cannot satisfy -package -db
(use -v for more information)
Finished
>>>Info Changed!!! True
Also, under Configuration -> Edit Prefs -> Metadata, "Paths under which haskell sources for packages may be be found" is empty. Should I put something there, and if yes, what?
I don't know what to try anymore. How can I get Leksah working right?
I had someone suggest that your leksah needs to be compiled with the same version of GHC as the one you have on your system. I haven't tried it, but even if it's true, I think that is really silly and shows that leksah may not be mature enough yet, at least not for my comfort. Not to mention that this could easily be detected and the user notified.
So, I ended up using Eclipse FP, which works great.
I'm currently trying out web development frameworks for haskell and I recently came across yesod. It seemed pretty interesting so I installed it using cabal, however I'm not able to run the development server. Following their getting started instructions here's the result:
$ yesod init
$ cd mysite
$ yesod devel
Configuring mysite-0.0.0...
Testing files...
Rebuilding app
yesod: bind: resource busy (Address already in use)
Preprocessing library mysite-0.0.0...
Preprocessing executables for mysite-0.0.0...
Building mysite-0.0.0...
Controller.hs:16:7:
Could not find module `Data.Dynamic':
It is a member of the hidden package `base'.
Perhaps you need to add `base' to the build-depends in your .cabal file.
It is a member of the hidden package `base-3.0.3.2'.
Perhaps you need to add `base' to the build-depends in your .cabal file.
Use -v to see a list of the files searched for.
Testing files...
Testing files...
^^ above line just keeps repeating...
I'm assuming it has something to do with the Data.Dynamic module but I don't know how to go about fixing it.
Additional Info
Running Ubuntu 10.10 Maverick
ghc version:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
I haven't run into this specific issue, but the error message looks like it's a simple question of GHC being unable to find version 3.0.3.2 the package "base." This version has been buildable since GHC 6.9, so you should have it. Try running the following command:
ghc-pkg check
This will tell you if there is something wrong with your packages. Cabal can be a bit of a nightmare for dependencies -- partly, it seems, because a lot of Haskell developers underestimate the extent to which their underlying libraries will shift in the future. So they will define a dependency as ">= [version of package x]" without limiting the max version to the one presently available. Or they just leave out version-limiting altogether.
Yesod, I'm happy to say, doesn't fall into this trap. But several of the libraries it depends on do. When you start developing in Haskell, learn this lesson: never assume that future versions of a library won't break your code. They will. A lot.
If ghc-pkg comes up with broken packages, you may need to clean up/uninstall/reinstall these packages until they are either cleaned up or hidden. (Just do ghc-pkg hide [package name] to tell ghc to ignore that package.
Your next problem is that hidden base package. Try the following:
ghc-pkg list | grep base
If you see brackets around the library, that means it's hidden. The package base-3.0.3.2 might show up as hidden (although that's a bit unlikely, as that's where the backward-compatible Prelude lives). If it is hidden, try to unhide it with the following command:
ghc-pkg expose base-3.0.3.2
Now try re-running yesod devel and see how it goes. Best case scenario is that it works. If not, let us know.
According to the Yesod in Five Minutes guide, you appear to be missing the a call to the command "cabal install" between your "cd mysite" and "yesod devel". It may need to install further packages based on what your responses were during "yesod init", such as which database you want to use.
Also, you may want to check that the port is not currently being used, as you have the "Address already in use" shown in your transcript.
First, it would be a good idea to resolve any broken packages reported by ghc-pkg check, by removing/reinstalling/upgrading them.
Next, can you manually cabal build the mysite app without trouble ? If your mysite.cabal actually does not specify base in the build-depends list, you should follow the suggestion to add that.
The repeating Testing Files message is normal for current yesod devel, it is polling your source files.