- Glasgow-haskell-users

RE: heap profiling and name truncation
by Simon Marlow 16 Nov '05

16 Nov '05

On 14 November 2005 20:35, Abraham Egnor wrote: > I'm trying to use the built-in ghc heap profiling and running into a > large roadblock: the names of producers are truncated, often into > uselessness, and there doesn't seem to be an option to control this. > Am I missing something in the docs? The limit of 25 characters before the "..." is built-in, I'm afraid. How ever, the cost centre ID is included (the number in parentheses before the cost centre stack), and you can match this to the full CCS by adding the -P option: $ ./prog +RTS -hc -P also produces a time profile in prog.prof that includes the ID of each cost centre stack. Cheers, Simon

1 0

RE: working lazy memoizer for GHC?
by Simon Marlow 16 Nov '05

16 Nov '05

The whole util package is deprecated, because it is using the old non-hierarchical module names. The memo table library should really be re-packaged with Cabal and made available somewhere. Cheers, Simon On 16 November 2005 07:29, Conal Elliott wrote: > I'd also like to know why this module is deprecated. Does anyone > know? - Conal > > -----Original Message----- > From: glasgow-haskell-users-bounces(a)haskell.org > [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of > Chung-chieh Shan > Sent: Monday, November 14, 2005 5:46 PM > To: glasgow-haskell-users(a)haskell.org > Subject: Re: working lazy memoizer for GHC? > > Conal Elliott <conal(a)conal.net> wrote in article > <011c01c5e655$97329390$0202a8c0@conalputer> in > gmane.comp.lang.haskell.glasgow.user: >> Does anyone have a working lazy memoizer (memo :: (a->b) -> (a->b)) >> for GHC? - Conal > > There's a deprecated one in the util package. Why is it deprecated > anyway?

1 0

Re: [Haskell-cafe] GHC ignores RTS options
by Tomasz Zielonka 16 Nov '05

16 Nov '05

On Wed, Nov 16, 2005 at 08:53:18AM +0100, Dusan Kolar wrote: > I wonder whether anybody could advise me how to pass > correctly RTS options to ghc? I've tried You have to pass these options to the program, not to GHC. BTW - it would be nice if it was easier to override the default RTS options when compiling the program. Perhaps a nice task for a newbie GHC developer? Best regards Tomasz

1 0

working lazy memoizer for GHC?
by Conal Elliott 16 Nov '05

16 Nov '05

Does anyone have a working lazy memoizer (memo :: (a->b) -> (a->b)) for GHC? - Conal

2 2

heap profiling and name truncation
by Abraham Egnor 14 Nov '05

14 Nov '05

I'm trying to use the built-in ghc heap profiling and running into a large roadblock: the names of producers are truncated, often into uselessness, and there doesn't seem to be an option to control this. Am I missing something in the docs? Abe

1 0

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