October 2008 - Glasgow-haskell-users

Backspace in ghci-6.10.1-candidate
by Serge D. Mechveliani 10 Oct '08

10 Oct '08

This is about testing 6.10.0.20081007. 1. DoCon works with it. 2. The question is how to `install' Backspace and UpArrow in ghci. I make it from source by 6.10-candidate and also by itself -- on Debian Linux. And ghci does not process Backspace and UpArrow. ./configure reported configure:2303: checking whether ghc has editline package configure:2314: result: no And the Debian system area shows the files /usr/lib/libedit.so.2 /usr/lib/iceape/components/libeditor.so /usr/lib/libedit.so.2.9 Please, what is wrong here? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

cabal-1.6.0.0
by Duncan Coutts 10 Oct '08

10 Oct '08

I've tagged Cabal-1.6.0.0 and the tarball is on the cabal website. http://haskell.org/cabal/download.html Tomorrow I'll update the version of Cabal that hackage is using and upload Cabal-1.6.0.0 to hackage. We're also planning to bump and upload the extralib packages tomorrow. I also hope to release cabal-install-0.6.0 in the next couple days. In the mean time please use the darcs version and report any issues. Duncan

1 0

libedit
by Christian Maeder 10 Oct '08

10 Oct '08

Hi Judah, after installing rpm packages libedit0-2.10.snap20070831-5 libedit-devel-2.10.snap20070831-5 I get the error below for "cabal install editline" Cheers Christian checking editline/readline.h usability... yes checking editline/readline.h presence... yes checking for editline/readline.h... yes checking for sign of read_history result on error... positive configure: creating ./config.status config.status: creating editline.buildinfo config.status: creating include/HsEditlineConfig.h Preprocessing library editline-0.2... In file included from Editline.hsc:52:0: include/HsEditline.h:11:0: error: conflicting types for 'el_get' /usr/include/histedit.h:112:0: error: previous declaration of 'el_get' was here compiling dist/build/System/Console/Editline_hsc_make.c failed command was: /home/linux-bkb/ghc/ghc-6.8.3/bin/ghc -c -package base-3.0.2.0 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o cabal: Error: some packages failed to install: editline-0.2 failed during the building phase. The exception was: exit: ExitFailure 1

2 2

Re: planning for ghc-6.10.1 and hackage
by Duncan Coutts 09 Oct '08

09 Oct '08

On Thu, 2008-10-09 at 12:47 -0500, Paulo Tanimoto wrote: > Hi Duncan, > > On Thu, Oct 9, 2008 at 10:28 AM, Duncan Coutts > <duncan.coutts(a)worc.ox.ac.uk> wrote: > > On Thu, 2008-10-09 at 10:20 +0200, Jean-Philippe Bernardy wrote: > >> On Mon, Oct 6, 2008 at 9:16 AM, Duncan Coutts > >> <duncan.coutts(a)worc.ox.ac.uk> wrote: > > > Right, you need the darcs version of cabal-install. > > > Just to be clear, what about the other dependencies? > > 1. zlib: the package from hackage seems to work flawlessly. > > 2. http: the one in hackage doesn't build [1], I'm using: > > $ darcs get --partial http://code.haskell.org/http/ > > Is that what I should be doing? I get those warnings about base [2]. This will be fixed by both a new point release of HTTP, but more generally this will be fixed by using the soft preferences which we'll include in the hackage index and which will be used by the upcomming cabal-install release. > 3. Cabal: should I use the one that comes with GHC or upgrade to the > darcs version? They're currently more or less the same. Duncan

2 1

planning for ghc-6.10.1 and hackage
by Duncan Coutts 09 Oct '08

09 Oct '08

Hi, We're getting pretty close to a final ghc-6.10.1 release. We would like of course for the transition this time to be less painful than last time. We all got a lot of flack last time for having no plan in place and making everyone change all their .cabal files etc. This time we can do a lot better. We have already decided to ship two versions of base, version 3 and version 4. Version 4 is the even more stripped down one, and with changes to exception handling etc. The version 3.1 of base depends on base 4 and re-exports most of it with a few differences so that it provides essentially the same api as base 3.0 did (which was included in ghc-6.8.x). However we are not all the way there yet. If we released ghc-6.10.1 today everything would still break. By everything I mean everyone's private projects and all the packages on hackage. The only packages that would build would be trivial ones, or the ones that come with ghc. There are two primary causes of this breakage: * cabal-installs dependency resolver does not work with base 3 & 4 * Cabal will still build packages using base-4 rather than 3 because most packages say "build-depends: base >= 2" rather than "build-depends: base ==3.*" The current cabal-install dependency resolver is based around the idea of picking at most one version of each package. This is because typically using two versions of any package is a mistake. For base we now have the situation that version 3 depends on version 4. So the current resolver will find a conflict as soon as anything needs base 3. The other problem is that packages currently typically specify an optimistic upwardly open range rather than a pessimistic closed range. Cabal uses the heuristic of picking the highest version of each package that satisfies the version constraints. I propose two solutions: * Fix the dependency resolver * Add support in Cabal and Hackage for suggested version constraints The second is considerably easier than the first. The second involves adjusting the dependency resolver to accept a per-package version constraint, like "base < 4", "QuickCheck < 2" or "parsec < 3". It would be a soft constraint that is used only when there is still a free choice between multiple package versions. This should help the situation with upward open version ranges like "build-depends: base". I have done this first part but not tested it yet. Then we would add this list of suggestions as an extra file in the 00-index.tar.gz file on hackage and make cabal-install use it. Hopefully doing this would allow us to not have to change every .cabal file on hackage, at least not immediately. In tandem we should encourage (using automatic warnings) people to use closed version ranges. The first problem is quite hard. I could really do with some help on it. The current dep resolver is a very simple constraint solving algorithm. It's only as clever as was needed to make things work in most cases. It is not a full general solver. It it based on being able to collect version constraints per-package and end up with exactly one version of a package. The obvious adaptation is to say that we can have multiple slots for a single package, one for base 3 and one for base 4. However it is not clear when we would decide to use two slots. Even if we just hack it and hard code there being two for base, we do not know which slot to put constraints into, probably both. My concern here obviously is that if we release a ghc-6.10.1 and tell everyone to start using it immediately for everything then we'll have chaos and take yet more flack for breaking everything. It would also be a great shame since Simon and Ian have already put a not-insignificant amount of effort into the underlying mechanisms to allow us to provide a compatibility base-3 package. Remember we do have the ability to set up an extra hackage server with everything and test how much builds or breaks with ghc-6.10. I'd like the time to do a test run with that before the release so that we can tell people what the expected level of breakage is and how to fix it. I'm not doing that immediately because I already know nothing will work atm without the two above issues being fixed. So I'll aim to work on both issues this week and report back on how things are going. Duncan

9 20

space in making 6.10.1-candidate
by Serge D. Mechveliani 09 Oct '08

09 Oct '08

Another point in testing ghc-6.10.0.20081007: I make it from source on Debian Linux. On 1 Gb - 2 GHz machine, it builds in 1400 sec. On 512 Mb machine, it seems to overfill RAM, it becomes slow, and this `make' creates difficulties for other processes (like emacs editor): they start to hang, a bit, and the `top' command shows 85% RAM used by this `make', now and then (and probably it takes more, sometimes). This effect is in making ghc-6.10.0.20081007 from source by ghc-6.10.0.20080921 on Debian Linux, on 512 Mb RAM i386-like machine. This was not so in earlier GHC versions. Can this be improved? Because 512 Mb is much enough. The last messages (after which I interruptred it) is ------------------------ make -C compiler doc stage=2 make[2]: Entering directory `/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/compiler' /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/libraries/cabal-bin /home/mechvel/ghc/6.10cand/inst0/bin/ghc /home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ libraries/bootstrapping.conf haddock --distpref dist-stage2 --haddock-option=--optghc=-DSTAGE=2 --with-haddock=/home/mechvel/ghc/6.10.1cand/ghc-6.10.0.20081007/ utils/haddock/install-inplace/bin/haddock Preprocessing library ghc-6.10.0.20081007... Running Haddock for ghc-6.10.0.20081007... Warning: The documentation for the following packages are not installed. No links will be generated to these packages: rts-1.0 Preprocessing library ghc-6.10.0.20081007... make[2]: *** [doc.stage.2] .. make[1]: *** [stage2] Interruption make: *** [bootstrap2] Interruption ---------------------------------------------- Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

More DPH
by Austin Seipp 07 Oct '08

07 Oct '08

Hi, I've been playing with DPH more; this time I've taken the Parallel Strategies binary-trees benchmark and converted it to use DPH. The results are here: http://haskell.org/haskellwiki/Shootout/Parallel/BinaryTreesDPH I haven't yet got anybody to test it on a 4/8 core machine, but on my core2duo it performs reasonably well, although as you can see from the test results, parallel strategies win every time (although some not by very much.) Is there any way to improve this code? I've noted at the bottom something that might be a potential bottleneck, or does U.toList fuse to make it as fast as possible? Austin P.S. I'm thinking of perhaps spending a few days and parallelising some of the other benchmarks; I'll keep people updated if they want to hear about it.

1 0

Re: Control.Exception
by Johannes Waldmann 07 Oct '08

07 Oct '08

> catch \(e :: SomeException) -> ... So, this changes the API (from 6.8 to 6.10)? I see there is Control.OldException (providing the "old catch") but that still does not help me if I want my code compile with both 6.8 and 6.10. Is there some version of catch that works both ways? best regards, J.W.

3 2

ghc-6.10.0.20081005 binary refers to (non existent?) libedit.so.0
by Johannes Waldmann 07 Oct '08

07 Oct '08

Dear all, I tried to install the binary snapshot on Debian (etch) x86_64 and got: /usr/local/lib/ghc-6.10.0.20081005/ghc: error while loading shared libraries: libedit.so.0: cannot open shared object file: No such file or directory I do have libedit (I think): lrwxrwxrwx 1 root root 14 2007-11-30 16:01 /usr/lib/libedit.so.2 -> libedit.so.2.9 -rw-r--r-- 1 root root 140640 2006-03-19 15:26 /usr/lib/libedit.so.2.9 This is the right package? dpkg -l "libedit*" ... ii libedit2 2.9.cvs.20050518 BSD editline and history libraries Best regards, J.W.

2 1

Re: System.Process.runInteractiveCommand, exit_group ()
by Johannes Waldmann 07 Oct '08

07 Oct '08

Solved - exit_group() wasn't the problem. My wrapper program silently died from SIGPIPE. Best regards, J.W.

2 1