- Glasgow-haskell-users

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 08 Oct '08

08 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

System.Process.runInteractiveCommand, exit_group ()
by Johannes Waldmann 06 Oct '08

06 Oct '08

Dear all, I have a Haskell program (compiled with -threaded) that calls an external executable via System.Process.runInteractiveCommand (and then I do waitForProcess). The external program finishes with exit_group () (I don't have source, but I see it from strace). Then, my Haskell program dies immediately. Is exit_group () the reason? How can I prevent this? Thanks - J.W.

1 0

Is -fvia-C still needed?
by leledumbo 06 Oct '08

06 Oct '08

I notice that speed from code generated by -fasm and -fvia-C isn't significant, furthermore -fvia-C takes longer time. So, why ghc still needs gcc (at least on Windows)? -- View this message in context: http://www.nabble.com/Is--fvia-C-still-needed--tp19663119p19663119.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

4 8

One stage2 compiler hanging around after head build (Solaris/x86 buildbot)
by Karel Gardas 05 Oct '08

05 Oct '08

Hello, month or so ago I've noticed that one compiler instance is hanging around and spending 100% of CPU for nothing after a build of head (I'm not sure if it also happens on stable) on my Solaris/x86 buildbot. I've thought that it's my old ghc-6.8.2 from 2008/05/04 and so I've updated the compiler now to 6.8.3, but the hangup happens again and now I've noted that in fact it's the stage2 compiler: -bash-3.2$ ps -fU buildbot|grep 4380 buildbot 24480 27081 0 14:50:27 pts/6 0:00 grep 4380 buildbot 4380 641 25 12:38:14 ? 130:33 /buildbot/ghc/kgardas/build/ghc/stage2-inplace/libexec/ghc -B/buildbot/ghc/kgar -bash-3.2$ my question is: is it just me who is affected by this or is it a well known issue in GHC build framework? Thanks, Karel

2 6

isTypeId, isValueId
by Serge D. Mechveliani 05 Oct '08

05 Oct '08

People, I need to implement the functions isTypeId, isValueId :: String -> Bool which check whether the argument fits respectively the syntax of a type identifier and of a value identifier -- in the Haskell-98 syntax for a program. The argument is produced by lexLots. For example, my program applies lexLots "ab-(f_21 <Ab:c" --> -- I expect: ["ab", "-", "(", "f_21", "<", "Ab", ":", "c"] -- 1 2 3 4 Then, I think, only (1), (2), (3) and (4) are type or value identifiers ... What is the most regular expression for isTypeId, isValueId ? I presume to consider first the Standard library, and if fail, then the GHC library. Thank you in advance for your advice. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0