Recently I decided to learn the basics of OCaml and I spent yesterday installing the compiler and some basic tools. On my machine at work I have a Debian 7 installation, while on my home laptop I have openSUSE 11.4. Both systems are quite dated and ship with OCaml 3.x compiler, which is five years old. Obviously, I wanted to have the latest version of the language. I could have compiled OCaml from sources – and in fact I have done that in the past to compile the latest version of Coq – but luckily there is a tool called OPAM (OCaml Package manager). OPAM can be used to easily download and install desired version of OCaml compiler. As the name implies, OPAM can be also used for managing packages installed for a particular compiler version.
The installation process went very smooth on my Debian machine, but on openSUSE I have run into problems. After getting the latest compiler I wanted to install
ocamlfind, a tool required by a project I wanted to play with. To my disappointment installation ended with an error:
[ERROR] The compilation of conf-ncurses failed at "pkg-config ncurses".
This package relies on external (system) dependencies that may be missing.
`opam depext conf-ncurses.1' may help you find the correct installation for your
I verified that I indeed have installed development files for the
ncurses library as well as the
pkg-config tool. Running the suggested
opam command also didn’t find any missing dependencies, and the log files from the installation turned out to be completely empty, so I was left clueless. Googling revealed that I am not the first to encounter this problem, but offered no solution. I did some more reading on
pkg-config and learned that: a) it is a tool that provides meta-information about installed libraries, and b) in order to recognize that a library is installed it requires extra configuration files (aka
*.pc files) provided by the library. Running
pkg-config --list-all revealed that
ncurses is not recognized as installed on my system, which suggested that the relevant
*.pc files are missing. Some more googling revealed that
ncurses library can be configured and then compiled with
--enable-pc-files switch, which should build the files needed by
pkg-config. I got the sources for the
ncurses version installed on my system (5.7) only to learn that this build option is unsupported. This explains why the files are missing on my system. I got the sources for the latest version of
ncurses (6.0), configured them with
--enable-pc-files and compiled, only to learn that the
*.pc files were not built. After several minutes of debugging I realized that for some unexplained reasons the
configure-generated script which should build the
*.pc files (located at
misc/gen-pkgconfig) did not receive
+x (executable) permission. After adding this permission manually I ran the script and got five
*.pc files for the
ncurses 6.0 library. Then I had to edit the files to match the version of
ncurses of my system – relevant information can be obtained by running
ncurses5-config --version. The only remaining thing was to place the five
*.pc files in a place where
pkg-config can find them. On openSUSE this was
/usr/local/pkgconfig, but this can differ between various Linux flavours.
After all these magical incantations the installation of
ocamlfind went through fine and I can enjoy a working OCaml installation on both of my machines. Now I’m waiting for the “Real-world OCaml” book ordered from Amazon (orders shipped from UK Amazon to Poland tend to take around two weeks to arrive).
Time for another upgrade of my GHC installation. OK, I know I already posted about this twice but yet again the process was different from the previous ones.
My first attempts of installing GHC and the Haskell Platform a year ago relied on using packages from my distribution’s repository. This quickly turned out to be problematic so I decided for a direct installation of the Haskell Platform. This worked perfectly fine except for the fact that Haskell packages were installed in different subdirectories of
/usr/local, which lead to a bit of a mess and problems with controlling what is installed where (this is useful if you want to remove a package). So the second time I was installing Haskell Platform I was smarter and refined the whole process. This time I confined the installation to a single directory so that both GHC and all the packages are located in a single, easy to find place.
Yesterday I figured out it would be great to get a new version of GHC. GHC 7.6.1 was released on 6th September 2012 and the updated 7.6.2 version is only two weeks old. While GHC 7.6.1 has been out for over 5 months it is still not part of the Haskell Platform and it won’t be for the next three months. That’s too long a wait for me so I decided to send the Platform to
/dev/null and just install GHC and its environment from scratch.
My plan to install GHC from precompiled binaries went up the spout:
This build requires
Watwatwat? Now what is that supposed to mean? Previously released binaries didn’t depend on one particular version of
libgmp library. Of course my system has
libgmp.so.10 and any attempt to install an older version results in breaking package dependencies. I downloaded binaries anyway and tried to run them:
[killy@xerxes : ~/ghc-7.6.2/ghc/stage2/build/tmp] ./ghc-stage2 --interactive
./ghc-stage2: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory
OK, so that requirement is true – you need the exact version of
libgmp. So what now? I know! Compilation from sources! I’ve been hacking on GHC recently so I already have sources on my drive. Unfortunately it turned out that after switching GHC repo and all its subrepos to
ghc-7.6 branch I get some compilation errors. I wasn’t in the mood for debugging this so I switched everything back to master and downloaded the source snapshot. From now on things are easy, assuming that you already have an older version of GHC on your system. After extracting the sources I copied
$(TOP) refers to directory containing GHC sources) and uncommented the line
perf-llvm. This gives me fully optimized build using LLVM. Now the compilation:
This will build GHC and prepare it for installation in
/usr/local/ghc-7.6.2. Fully optimized build takes much over an hour on all 4 cores. After the build is done all one needs to do is run
make install as root. At this stage old GHC can be removed. You of course need to add
PATH environmental variable. As I already have mentioned I have the habit of installing all the packages system-wide in a single directory. For that I need to edit
/root/.cabal/config file by adding the following entry:
All that is left now is installing cabal-install. Grab the sources from hackage, extract them and run (as root)
sh bootstrap.sh --global in the source directory. This installs cabal-install with its dependencies. Now you can start installing other packages that you need (a.k.a. compile the World).
This completes Yet Another Installation of GHC.
When I started using Emacs a few months ago I went through some effort to configure it to my liking. There were a couple of issues I wasn’t able to resolve back then. I decided that it’s time to get them fixed. That’s how I wasted two days doing something that should take no longer than an hour.
About 90% of my time went to configuring Emacs running under Tmux. While Emacs runs fine under terminal emulator (I’m using Konsole for that) it turned out that running it under Tmux causes numerous problems: some key combinations don’t work and even worse the colours get screwed up. I am using Tmux always when working in console and at first I wanted to blame Tmux for all the problems. Soon I realized that all other applications work correct and only Emacs is causing problems. Problems with key combinations were solved using xterm-extras add-on. I am not exactly sure what is causing issues with colours but this is related to
TERM environment variable. Within Tmux this is set to
screen, while my terminal emulator sets it to
xterm. If I understand correctly Tmux takes care of translating between these two different modes, but it looks that Emacs is still affected by this difference. Of course I tried changing values of
TERM in all possible ways, but things only got worse. I tried improving Emacs’ colours by using color-theme but under my terminal emulator this breaks completely. I enabled 256 colours (by default there’s only 8!), but still I mostly got garbage when applying different themes. Oh well, I can live with 8 colours just fine. This was day one.
On the next day, when things were more or less working fine, I decided to upgrade Emacs to version 24.2. I was tempted by Emacs’ built in package management system and a promise of better compatibility with terminal emulators. This was a mistake. I spent another day trying to figure out why configuration that worked fine under 23.2 breaks under 24.2.
I acknowledge the fact that if I had arcane knowledge of Elisp all my issues would be much easier to solve. Without that knowledge I have to resort to googling and voodoo programming. Well, I am just an ordinary user who just wants to use a text editor. I need a text-based editor so I can do almost all of my work using console. Emacs meets that requirement, which makes me more productive but I seriously doubt that this increase in productivity justifies time needed to configure editor to my needs. I guess I would be proud of myself had I managed to solve all the problems. I didn’t and there are still unresolved issues:
- How can I manage keyboard shortcuts in a sane way? I install some expansion only to realize it is not working because keyboard shortcuts collide with the ones from different expansion. I can remap the keys, but then again I run into risk of colliding with other shortcuts.
- Can I have a block mode in Emacs similar to one offered by Kate (under KDE)? I found that rect-mark allows me to mark a rectangle area and cut it, but pasting doesn’t work the way it should.
- Emacs’ undo is clumsy. I managed to improve it by using undo-tree, but still it has rough edges: every delete is seen as a single operation. If I hold backspace and delete 30 characters Emacs sees that as 30 separate operations! Undoing that is a real pain.
Solving these issues would make Emacs a very decent editor to work with Haskell (though not as good as Eclipse is for Java). Perhaps one day I’ll find patience and energy to resolve the remaining problems. Until then I steel myself for using Emacs the way it is.