- Glasgow-haskell-users

Build and runtime errors
by Tom Cody 05 Jun '08

05 Jun '08

I've attached a log of the 'make install' on advice from Igloo. I get the following when trying to building from source with the documentation install enabled: #Hacks: /usr/bin/install -c -m 644 base/dist/doc/html/*/*.css /usr/local/share/doc/ghc/libraries /usr/bin/install: cannot stat `base/dist/doc/html/*/*.css': No such file or directory make[1]: *** [install] Error 1 make[1]: Leaving directory `/home/cody/Desktop/ghc-6.9.20080603/libraries' make: *** [install] Error 2 However, if I comment out lines 386 -394 in the libraries makefile, it all installs perfectly. But then I get this runtime error every time I use any GHC file: ghc-6.9.20080603: panic! (the 'impossible' happened) (GHC version 6.9.20080603 for i386-unknown-linux): interactiveUI:setBuffering2 _________________________________________________________________ http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/

1 0

Having trouble with parallel Haskell
by Bryan O'Sullivan 05 Jun '08

05 Jun '08

I intended to write a half chapter or so about parallel programming in Haskell for the book I'm working on, but I've been coming to the conclusion that the time is not yet ripe for this. I hope it will be helpful if I share my experiences here. Specifically, I was planning to write about parallel programming in pure code: use of "par" and programming with strategies. The most substantial problem is that the threaded RTS in GHC 6.8.2 is very crashy in the face of "par": about 90% of my runs fail with a segfault or an assertion failure. Simon Marlow mentioned that this bug is fixed, but I've been unsuccessful in building a GHC 6.8.3 release candidate snapshot so far, so I can't verify this. When a run does go through, I have found it surprisingly difficult to actually get both cores of a dual-core system to show activity. As there are no tools I can use to see what is happening, I am stumped. It is of course quite likely that I am doing something wrong that results in unexpected dependencies, but I cannot find a means to gaining insight into the problem. As an example, I have a simple parallel quicksort that is very conservative in its sparking, and I get no joy out of it on a dual-core machine: it mostly sticks to a single core. This wouldn't be a problem if I had some way to spot the presumed data dependency that is serialising the code, but no joy. <b

7 12

-fvia-C for libHSbase, etc.?
by Donn Cave 05 Jun '08

05 Jun '08

I'm building GHC on NetBSD-amd64, and among other things need to deal with the problem described in #2305 - native code misses the __RENAME (__asm) directive in NetBSD include files, and ends up linking to the wrong externals. The author of #2305 reports that -fvia-C avoids this problem, so I built the ghc 5/31 distribution I've been working on, with GhcLibHcOpts=-O -Rghc-timing -fgenerics -fvia-C (i.e., add -fvia-C compile option for library build.) Does that seem like a reasonable solution? It does seem to work, but I'm wondering if there are issues we can expect with performance etc.? thanks, -- Donn Cave <donn(a)avvanta.com>

2 1

Re: Having trouble with parallel Haskell
by Donnie Jones 05 Jun '08

05 Jun '08

Hello Bryan, 2008/6/4 Bryan O'Sullivan <bos(a)serpentine.com>: > I intended to write a half chapter or so about parallel programming in > Haskell for the book I'm working on, but I've been coming to the > conclusion that the time is not yet ripe for this. I hope it will be > helpful if I share my experiences here. > > Specifically, I was planning to write about parallel programming in pure > code: use of "par" and programming with strategies. > > The most substantial problem is that the threaded RTS in GHC 6.8.2 is > very crashy in the face of "par": about 90% of my runs fail with a > segfault or an assertion failure. Simon Marlow mentioned that this bug > is fixed, but I've been unsuccessful in building a GHC 6.8.3 release > candidate snapshot so far, so I can't verify this. > > When a run does go through, I have found it surprisingly difficult to > actually get both cores of a dual-core system to show activity. As > there are no tools I can use to see what is happening, I am stumped. It > is of course quite likely that I am doing something wrong that results > in unexpected dependencies, but I cannot find a means to gaining insight > into the problem. Although my Google Summer of Code project was not selected, I decided to go ahead and work on the Parallel Profiling Tools for GHC this Summer, with the help of Simon Marlow of course, for my Master's thesis. The work is nowhere near complete, as I just began working on it a couple of weeks ago. I was able to run the ParSort.hs program in your original post with my modified version of GHC HEAD that now supports parallel profiling. Hopefully, by the end of the Summer, Haskell's support for parallel profiling will be vastly improved. This is the example test I performed: ghc -parprof -threaded -o ParSort --make ParSort.hs time ./ParSort 1000000 +RTS -pN -N6 -RTS We have 1000000 elements to sort. Sorted all 1000000 elements. 28.04362s elapsed. real 0m36.060s user 0m44.107s sys 0m0.708s I have attached an Postscript file containing a graph that visualizes the parallel profiling data from the above test. A lot of work still needs to be done, but I just wanted to let you know that improvements are expected soon. Btw, ParSort.hs was taking advantage of both cores on my machine. Thank you. __ Donnie Jones

1 0

GHC 6.8.2 and large source files
by Christian Höner zu Siederdissen 05 Jun '08

05 Jun '08

Dear Haskell users, we have an automated system that generates executable haskell source files. These files have a line count from 1,000 lines up to 28,000 lines. There is only 1 type definition and 5 functions in total in the file. We now can compile into executable code some of these programs but the compiler requires an incredible amount of memory: the 15,000 line programs easily require 2 GByte of RAM and then the compiler dies. Are there hints on how to compile large source files? Would it help, for example to compile each function on its own? On the following webpage you can find a handcrafted program, albeit with very few lines, that shows how one of our source files would look like: http://bibiserv.techfak.uni-bielefeld.de/cgi-bin/adp_MatrixMult We automatically generate type, algebras and the grammar for our application. Thanks, Christian Höner zu Siederdissen

2 2

Re: [Haskell-cafe] Default definitions for associated type synonyms
by Isaac Dupree 02 Jun '08

02 Jun '08

Dreixel wrote: > Hello, > > Does anyone know if it is possible to specify a default definition for an > associated type synonym? When I tried: > > class A a where >> type B a = a >> > > GHC (version 6.9.20080309) told me: "Type declaration in a class must be a > kind signature or synonym default". However, when I look at the parser I see > no way to specify such synonym default. Is this possible? I'm curious... so, cc'ing glasgow-haskell-users mailinglist because the question is more likely to be noticed by relevant people there. > Thanks, > Zé Pedro

2 1

impredicative polymorphism: seen on HCAR
by Isaac Dupree 02 Jun '08

02 Jun '08

The May 2008 Haskell Communities and Activities Report, GHC <http://www.haskell.org/communities/05-2008/html/report.html#ghc>: > Impredicative polymorphism. We are not happy with GHC’s current > implementation of impredicative polymorphism, which is rather > complicated and ad hoc. Dimitrios (with Simon and Stephanie) > wrote a paper about a new and better approach: > http://research.microsoft.com/~simonpj/papers/boxy > . At the same time, Daan Leijen has been working on his > closely-related design: > http://research.microsoft.com/users/daan/pubs.html > . Daan’s design has a much simpler implementation, in exchange > for an (arguably) less-predictable specification. Which of these > two should we implement? Let us know! I read the papers... Dimitrios's *paper* is easier for me to understand than Daan's. In fact they seem quite similar. I have no idea of any examples where they would behave differently. I don't use impredicative polymorphism much (but maybe because of my perception that the existing implementations are poorly designed, and that it can usually be avoided by an amount of abstraction that's useful anyway). So I'd say, implement the easier solution. Is there a paper or documentation somewhere, presenting a practical argument for why impredicative polymorphism is important in real programs (beyond runST $) -- for example, a real program that uses it and has clearer code because of it? I don't really mind writing let/function type-signatures that have weird types (unless they're long and repeat information that doesn't need to be, which is a different problem). I wonder how often these proposals require type-signatures on lambdas passed to higher-order functions, though... A side-effect is for those of us who want to have any concern for future compatibility with non-GHC type systems (or the long future of GHC's, even), whether one of the proposals would be likely to be easier for someone else to implement in a different compiler. -Isaac

1 1

Re: ANNOUNCE: GHC 6.8.3 Release Candidate
by Serge D. Mechveliani 02 Jun '08

02 Jun '08

On Sun, Jun 01, 2008 at 01:13:06AM +0100, Ian Lynagh wrote: > > Hi Serge, > > On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote: > > This is a bug report for the ghc candidate of May 27, 2008 > > for ghc-6.8.3. > > A short program example for this bug candidate is on > > > > http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip > > Thanks, I've finally tracked this down. The problem is that when you > evaluate something like > f ^ 10 > in 6.8.2 the result was > res > while in 6.8.3 it is > 1 * res > > I think this is actually a bug in your class instances, but I will try > to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 > which should, as a side-effect, make it work again. ?? Probably, 6.8.3 is wrong. Because when res :: Num a => a, 1*res means ((fromInteger 1) :: a) * res in Haskell-98. Right? And (fromInteger n) :: a can be defined arbitrarily by the programmer. For example, DoCon has the instance instance CommutativeRing a => Num (Pol a) where ... fromInteger _ = error "No (fromInteger n) :: Pol _ !\ \Apply instead fromi <samplePolynomial> n." -- something of this kind. This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a. Am I missing something? ----------------- Serge Mechveliani mechvel(a)botik.ru

5 6

test for 6.8.3-may27
by Serge D. Mechveliani 01 Jun '08

01 Jun '08

About the 6.8.3 candidate of May 27, there remains the question: why it builds DoCon-2.11 considerably slower than ghc-6.8.2 (3 times, as I recall) and needs larger -M memory to build this DoCon ? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: [Haskell-cafe] hint / ghc api and reloading modules
by Daniel Gorín 01 Jun '08

01 Jun '08

(Since this can be of interest to those using the ghc-api I'm cc-ing the ghc users' list.) Hi, Evan The odd behavior you spotted happens only with hint under ghc-6.8. It turns out the problem was in the session initialization. Since ghc-6.8 the newSession function no longer receives a GhcMode. The thing is that, apparently, if one was passing the Interactive mode to newSession under ghc-6.6, now you ought to set the ghcLink dynflag to LinkInMemory instead. I couldn't find this documented anywhere (except for this patch http://www.haskell.org/pipermail/cvs-ghc/2007-April/034974.html) but it is what ghci is doing and after patching hint to do this the reloading of modules works fine. I'll be uploading a fixed version of hint to hackage in the next days. Thanks, Daniel On May 31, 2008, at 2:46 PM, Evan Laforge wrote: > I'm using "hint", but since it's basically a thin wrapper around the > GHC API, this is probably a GHC api question too. Maybe this should > go to cvs-ghc? Let me know and I'll go subscribe over there. > > It's my impression from the documentation that I should be able to > load a module interpreted, make changes to it, and then reload it. > This is, after all what ghci does. It's also my impression that the > other imported modules should be loaded as object files, if the .hi > and .o exist, since this is also what ghci does. > > However, if I load a module and run code like so (using hint): > > GHC.loadModules ["Cmd.LanguageEnviron"] > GHC.setTopLevelModules ["Cmd.LanguageEnviron"] > GHC.setImports ["Prelude"] > cmd_func <- GHC.interpret (mangle_code text) (GHC.as :: LangType) > > It works fine until I change LanguageEnviron. If I make a change to a > function, I don't see my changes in the output, as if the session is > only getting partially reset. If I insert a syntax error, then I do > see it, so it is recompiling the file in some way. However, if I > *rename* the function and call it with the new name, I get a > GhcException: > > During interactive linking, GHCi couldn't find the following symbol: > ... etc. > > So I examined the code in hint for loadModules and the code in > ghci/InteractiveUI.hs:/loadModule, and they do look like they're doing > basically the same things, except a call to rts_revertCAFs, which I > called too just for good measure but it didn't help (I can't find its > source anywhere, but the ghci docs imply it's optional, so I suspect > it's a red herring). > > Here's a condensed summary of what hint is doing: > -- reset > GHC.setContext session [] [] > GHC.setTargets session [] > GHC.load session GHC.LoadAllTargets > -- rts_revertCAFs > > -- load > targets <- mapM (\f -> GHC.guessTarget f Nothing) fs > GHC.setTargets session targets > GHC.load session GHC.LoadAllTargets > > -- interpret > let expr_typesig = "($expr) :: xyz" > expr_val <- GHC.compileExpr session expr_typesig > return (GHC.Exts.unsafeCorce# expr_val :: a) > > -- GHC.compileExpr > maybe_stuff <- hscStmt hsc_env ("let __cmCompileExpr = "++expr) > ([n],[hv]) <- (unsafeCoerce# hval) :: IO [HValue] > return (Just hv) > > > and then ghci does: > -- load > GHC.setTargets session [] > GHC.load session LoadAllTargets > > targets <- io (mapM (uncurry GHC.guessTarget) files') > GHC.setTargets session targets > GHC.load session LoadAllTargets > > rts_revertCAFs > putStrLn "Ok, modules loaded: $modules" > > -- interpret > GHC.runStmt session stmt step > > -- GHC.runStmt > Just (ids, hval) <- hscStmt hsc_env' expr > coerce hval to (IO [HValue]) and run it carefully > > > So it *looks* like I'm doing basically the same thing as ghci... > except obviously I'm not because ghci reloads modules without any > trouble. Before I go start trying to make hint even more identical to > ghci, is there anything obviously wrong here that I'm doing? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0