November 2005 - Glasgow-haskell-users

GHC 6.4.1 on Solaris x86
by Ben Horsfall 14 Nov '05

14 Nov '05

Is there a binary package for GHC 6.4.1 on Solaris x86 (Sun OS 5.9)? Building from source fails thus: ../../ghc/compiler/ghc-inplace -optc-O -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wbad-function-cast -optc-I../includes -optc-I. -optc-Iparallel -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -H16m -O -O2 -static -I. -#include Prelude.h -#include Rts.h -#include RtsFlags.h -#include RtsUtils.h -#include StgRun.h -#include Schedule.h -#include Printer.h -#include Sanity.h -#include STM.h -#include Storage.h -#include SchedAPI.h -#include Timer.h -#include Itimer.h -#include ProfHeap.h -#include LdvProfile.h -#include Profiling.h -#include Apply.h -fvia-C -dcmm-lint -c StgCRun.c -o StgCRun.o Assembler: StgCRun.c "/tmp/ghc14327.s", line 18 : Illegal mnemonic "/tmp/ghc14327.s", line 18 : Syntax error "/tmp/ghc14327.s", line 18 : Illegal mnemonic make[2]: *** [StgCRun.o] Error 1 Ben

1 0

RE: class aliases
by Simon Peyton-Jones 11 Nov '05

11 Nov '05

John | If I were to implement my class alias proposal for ghc in an acceptably | clean way, would it be accepted? There appeared to be enough interest to | support at least experimentation with it and I would have no issues with | it being dropped in the future if it turned out to not be useful. Yes, definitely; that would be great. I would like to interact with you as you did it, rather than be presented with a completed result, because I'm sure I'll have lots of ideas about what a clean implementation would look like. I'd also like to take another look at the design (which you may have refined a bit since your initial message). So let me know when you feel like taking up the cudgels and we can discuss it in a bit more detail. Simon

1 0

RE: HSQL installation woes
by Simon Marlow 11 Nov '05

11 Nov '05

On 06 November 2005 20:31, Ed Osinski wrote: > I'm trying to install GHC and related software under Solaris 9 and am > stuck at HSQL. I initially used the binary package of ghc 6.4.1. It > installed w/o any problems, and I was able to build alex, happy, > haddock and cpphs. However, when trying to install HSQL-1.6, it > complained about "ld" not recognizing "-x". I guess this is due to > the binary package for Solaris being built on a machine that used the > GNU linker, which recognizes "-x"? Anyway, this led me to build ghc > 6.4.1 from source, with gcc 4.0.2, which was successful. :-) However, > when I try to install HSQL-1.6, it dies during the build step. :-( > > Here is the output: > > /sware/build/HSQL-1.6/HSQL |> runghc Setup.lhs configure > Warning: No license-file field. > Configuring hsql-1.6... > configure: searching for ghc in path. > configure: found ghc at /usr/local/bin/ghc > configure: looking for package tool: ghc-pkg near compiler in > /usr/local/bin/ghc configure: found package tool in > /usr/local/bin/ghc-pkg configure: Using install prefix: /usr/local > configure: Using compiler: /usr/local/bin/ghc > configure: Compiler flavor: GHC > configure: Compiler version: 6.4.1 > configure: Using package tool: /usr/local/bin/ghc-pkg > configure: Using haddock: /usr/local/bin/haddock > configure: Using happy: /usr/local/bin/happy > configure: Using alex: /usr/local/bin/alex > configure: Using hsc2hs: /usr/local/bin/hsc2hs > configure: Using cpphs: /usr/local/bin/cpphs > configure: Reading installed packages... > configure: Dependency base-any: using base-1.0 > /sware/build/HSQL-1.6/HSQL |> runghc Setup.lhs build > Preprocessing library hsql-1.6... > Building hsql-1.6... > Chasing modules from: Database.HSQL,Database.HSQL.Types > Compiling Database.HSQL.Types ( ./Database/HSQL/Types.hs, > dist/build/./Database/HSQL/Types.o ) Compiling Database.HSQL ( > ./Database/HSQL.hs, dist/build/./Database/HSQL.o ) *** Exception: > waitForProcess: interrupted (Interrupted system call) > > This error happens consistently, but sometimes one line earlier. > Googling reveals that at least one person encountered this exception > on Solaris in the recent past: I think this means that GHC crashed. waitForProcess throws the "interrupted" exception whenever the sub-process it is waiting for receives a signal, such as a SIGSEGV. This is the wrong behaviour, I'll look into fixing it. The next step is to find out why GHC is crashing - you could try running GHC on its own, independently of Cabal (use "runghc Setup.lhs -v" to get the command line). Cheers, Simon

2 1

Re: C minus minus? No, C monad monad.
by John Meacham 11 Nov '05

11 Nov '05

On Thu, Nov 03, 2005 at 12:57:54PM +0100, Christof Douma wrote: > It is nice to see GRIN is used by other people as well. My work has been > to extend the GRIN model to be usefull for exceptions and implement a > grin compiler. I am currently in the process of writing the results down. I am glad to see other people using it too :) I have read some of your stuff and am looking forward to seeing the results. > Continuations in this example are not needed. The example calls some > function by using continuations. The idea of GRIN is to have nodes which > represent thunks. A partial application to some function foo can be > represented by a node which describes which function to be called when > fully saturated and the already applied arguments. The above example can > be rewritten to standard GRIN as follows: > > foo x = return (x + 4) > > myfunc = \(a,b) -> do > cont <- return (P1foo) //store a partial application node > case (a - b) of > 3 -> return -1 > 5 -> apply cont 2 > z -> apply cont z > > apply f a = case f of > P1foo -> foo a The problem is that this is the exact opposite transformation that I am trying to carry out :) The above is what is generated by my front-middle-end (hmm. need new terminology) and my goal is to transform it into explicit loops with updatable variables. These things cannot be expressed directly in traditional Grin which is why I introduced continuations and a series of transformations to turn the above into efficient looping updating c-- code. > >yay! Grin has gained a whole lot of power from stealing this idea from c--. > yay! Grin already has a whole lot of power. ;-) Indeed, but the goal of jhc is to produce code that is faster than C code. any compromises in expressing algorithms that can be expressed in C are not ones I am willing to make :) so powerful here doesn't mean being able to do more. it means being able to express the optimizations I need to in order to produce code that runs as efficiently as I want without sacrificing Grin's nice theoretical properties. > Secondly. Modelling exceptions in GRIN does not benefit from the use of > these continuation constructs. GRIN does not have some global variable > in which you can store the exception handler. Of course this can also be > added (as a primitive in the monad). But what is the difference to a > global variable with a node in it? Although jhc does not have global variables, it does have global names, this is how CAFs are implemented. theoretically, you can think of them as parameters that are implicitly passed to every function and they have the same semantics, but practically, I don't implement them that way of course. They are not special in any way and are just like any other grin name so none of the machinery needs to change to take them into account. in any case, one of these global names can easily hold the value of some heap location or register to store the exception stack. This is exactly what needs to be done to implement updatable CAFs properly so I am not adding any new concepts to support exceptions. > The extension I created allows exceptions in GRIN with the use of try > catch and throw statements. These two are monad primitives. The try > catch statments defines a continuation and pushes it on the exception > handler stack. The throw statment cuts to that handler. Leaving the > scope of the try statement or entering the handler will restore the > previous handler. Indeed, I was looking at using this model too, but I decided against it for a couple reasons, the main one is that continuations give me a whole lot of other advantages I can make good use of. but other than that, it means that the IO monad will have to be special since it has these primitives that are part of the monad. in jhc, the IO monad is exactly data World__ data IOResult a = FailIO World__ IOError | JustIO World__ a newtype IO a = IO (World__ -> IOResult a) with continuations as a primitive, I could get rid of FailIO and have the continuation actually be the World__ value that is passed around, this also incidentally obviates the need for a global variable as mentioned above. It also opens up the use of the continuation primitive to other uses, like a more efficient Control.Monad.Cont. though, imprecise exceptions most likely would need a global exception stack though I am still undecided as to whether those are a good idea. > Doing register allocation and instruction selection in GRIN sure looks > nice. It is an intresting thought. Yeah, I think boquist would have benefited from a lot of these ideas since he went directly from grin -> assembly. going through c or c-- affords us a lot more freedom. but using this algorithm to decide what goes in C local variables is quite useful too. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

Re: C minus minus? No, C monad monad.
by Simon Peyton-Jones 11 Nov '05

11 Nov '05

John Interesting message. http://repetae.net/john/repos/jhc/docs/c-minus-monad.txt But I'm not completely convinced. Firstly, C-- *continuations* are quasi-first class values: you can pass them as arguments to functions, and store them in data structures. In contrast, your continuations are more akin to C-- *labels*. These are definitely not first class. They just give a textual way of describing a control flow graph. That's much closer to what you mean to do (with join points etc). Of course, labels allow you to build a cyclic graph. Your hack for building cycles feels to me like using the monadic story for something it wasn't really meant for. Somehow, a set of labelled blocks seems more more direct. I'm also not convinced that you are getting anything much from your monadic presentation that you would not also get, sometimes more directly, from a C-- representation. What, do you think you gain? There is a long and distinguished history to regarding lambda code as an intermediate language that can go all the way to machine code (e.g. the lambda-the-ultimate papers; the T compiler; Appel's book etc). Using a monadic, rather than CPS, framework may be better -- though it's a tricky case to make. But in fact, few compilers do take this idea right through. It's hard to say why, except that it can be a bit clumsy to make one hammer that is truly comfortable on many different nails. At the moment, I'd still incline to translating Grin into C-- (or something like it), and optimising there. But maybe you have good reasons not to do that. Simon

2 1

RE: Proposal: Improved error message of "Error in array index"
by Simon Marlow 09 Nov '05

09 Nov '05

On 09 November 2005 11:52, Olaf Chitil wrote: > Simon Marlow wrote: > >> I can explain why it happens, >> though. The compiler has lifted out the error case into a top-level >> binding: >> >> x = error "Error in array index" >> >> > So cost-centre stacks are not produced for the original program > written by the user, but for the intermediate program after > optimisation. I understand that you want to profile the optimised > version, but the fact that your profile does not quite match your > program can be confusing. For debugging, however, I think that it is > clear that you want your debugging information (cost centre stacks) > to match your program, even if it costs you some performance. I completely agree! Indeed, the simplifier does try to maintain the shape of the call graph when it transforms the program (perhaps not entirely successfully). The issue here I think is that we should treat exceptions in a similar way to functions: when a function is called, the cost-centre stack of the function is appended to the cost-centre stack of the call site, this is how the call graph is built up. A thunk which evaluates to an exception should probably behave in the same way, which would fix the problem above (I'm not sure how easy this is to do, though). Cheers, Simon

1 0

RE: Proposal: Improved error message of "Error in array index"
by Simon Marlow 09 Nov '05

09 Nov '05

On 08 November 2005 09:19, John Meacham wrote: > jhc has a SRCLOC_ANNOTATE pragma to solve just this problem > > here is the relevant part of the docs: > > * SRCLOC_ANNOTATE pragma. This is a generalization of GHCs assert > magic. A function which is given an SRCLOC_ANNOTATE pragma will be > replaced with an alternate version that takes the functions use > site as an argument. This allows error messages to be in terms of > where said function was used. The alternate function is named > [function]_srcloc_ann__ and must be in the same module as the > original function. Jhc does no checking to ensure both functions > have the same effect, it is up to the user to ensure that. An > example is Nice - though it would be even better to provide the required functionality automatically. One idea that occurred to us recently is this: GHCi could provide a simplified version of the cost-centre-stack machinery *all the time*, giving you a proper backtrace for any exception, at least for the parts of the call stack that are interpreted. We don't care about the cost too much - interpreted code is a lot slower than compiled already, and it would only be a small constant factor. I think this would be a huge win for debuggability. And a nice project for anyone who wants to hack on the GHC internals - though not a small task by any means. Cheers, Simon

3 2

RE: Proposal: Improved error message of "Error in array index"
by Simon Marlow 09 Nov '05

09 Nov '05

On 08 November 2005 12:09, Rene de Visser wrote: >> One idea that occurred to us recently is this: GHCi could provide a >> simplified version of the cost-centre-stack machinery *all the time*, > >> Simon > > This still doesn't explain to me why > > C:\Haskell\dev>main +RTS -xc > > gave > > <GHC.Arr.CAF>main: Error in array index > > (This is with full profiling turned on) > > This sort of stack is not going to help anyone. Hmm yes, this is indeed rather unhelpful. I can explain why it happens, though. The compiler has lifted out the error case into a top-level binding: x = error "Error in array index" and the profiling system takes the view that any costs involved in evaluating a CAF to head normal form should not be attributed to any particular call site in particular, because the call site that gets to evaluate the CAF first can change as a result of strictness analysis or other optimisations, and it isn't useful to expose this kind of non-determinism to the programmer. So the cost center stack when evaluating a CAF is always rooted at the CAF itself, and ignores the call site. CAFs are the free variables of the program, if you like. This is the argument, however I'm not sure I buy it any more. It clearly isn't very useful for backtracing, for one thing. It wouldn't really do any harm to have the costs for a CAF grafted onto the call stack at the site of its first evaluation. Figuring out how to make cost-centre-stacks do the right thing with CAFs is something of an open problem, in fact; there are currently cases where GHC produces strange results. Things get hairy when CAFs get evaluated to data structures that contain functions (eg. dictionaries). Cheers, Simon

3 2

RE: Proposal: Improved error message of "Error in array index"
by Simon Marlow 09 Nov '05

09 Nov '05

On 09 November 2005 11:40, Simon Marlow wrote: > On 09 November 2005 10:18, Ketil Malde wrote: > >> Simon Marlow wrote: >> >>> Hmm yes, this is indeed rather unhelpful. I can explain why it >>> happens, though. The compiler has lifted out the error case into a >>> top-level binding: >>> >>> x = error "Error in array index" >>> >>> >> Would the compiler be less agressive with this if I turn off >> optimization? I usually use optimization with profiling as well, >> but could of course turn it off if it would result in more useful >> stack backtraces. > > Possible... but not guaranteed. I think the simplifier does limited > forms of let-floating even without -O. Oh, and that code is in a library, so turning off -O won't help there. Cheers, Simon

1 0

RE: Proposal: Improved error message of "Error in array index"
by Simon Marlow 09 Nov '05

09 Nov '05

On 09 November 2005 10:18, Ketil Malde wrote: > Simon Marlow wrote: > >> Hmm yes, this is indeed rather unhelpful. I can explain why it >> happens, though. The compiler has lifted out the error case into a >> top-level binding: >> >> x = error "Error in array index" >> >> > Would the compiler be less agressive with this if I turn off > optimization? I usually use optimization with profiling as well, but > could of course turn it off if it would result in more useful stack > backtraces. Possible... but not guaranteed. I think the simplifier does limited forms of let-floating even without -O. Cheers, Simon

1 0