- Glasgow-haskell-users

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

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

09 Nov '05

On 08 November 2005 14:44, Malcolm Wallace wrote: > Whilst we are wishing for language features, I wonder if anyone > else would be interested in being able to export/import such cpp > macros using the normal Haskell module mechanism? At the moment, > it is ugly that you need to either #include or #define your macros > separately in every module where you use them. But if the cpp phase > were integrated more tightly into the compiler, it could be possible > to treat macros almost like ordinary function definitions. *shudder* I disagree most strongly. CPP is a well-defined preprocessing stage, it is easily understood by virtue of being separate from Haskell. I don't even want to start thinking about what happens if you merge the CPP and Haskell namespaces... ugh! I guess we have a different idea of what's "ugly" :) 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 23:53, John Meacham wrote: > On Tue, Nov 08, 2005 at 11:12:09AM -0000, Simon Marlow 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*, >> 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. > > personally, I rarely find the stack dump very useful at all (though I > always have high hopes). perhaps I have just had bad experiences with > it, but it can often be uninformative or even misleading. It wouldn't be a dump of the evaluation stack, rather a dump of the lexical call stack - the stack that you see when you do +RTS -xc, or time profiling in GHC. It's much more useful than the evaluation stack, which is usually not terribly informative I agree (though I've heard others say they'd still like to be able to get hold of that too). Cheers, Simon

1 0

cant bootstap ghc-6.4.1 with no ghc
by Vihang Dudhalkar 09 Nov '05

09 Nov '05

I have been attempting to bootstrap ghc-6.4.1 on a Fedora system with no previous version of ghc installed. I'm currently stuck at System/CPUTime_hsc.c. The build fails at the following point: $ distrib/hc-build --enable-hc-boot-unregistered [ many successful lines skipped ] touch GHC/PrimopWrappers.hs gmake[2]: *** No rule to make target `System/CPUTime_hsc.c', needed by `depend'. Stop. what can be the problem?? -- ___________________________________________ -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/S C++++ P+ L+++(++++) E++(+++) W++ N+++ w--- G++++ e+++ a-- y d- s:++ r-- b+ Y+ G+++ ------END GEEK CODE BLOCK------ decode with www.ebb.org/ungeek Linus Torvalds wrote: > Ehh.. Telling people "don't do that" simply doesn't work. Not if they can > do it easily anyway. Things really don't get fixed unless people have a > certain pain-level to induce it to get fixed. Umm... How about the following: you hit delete on patches that introduce new ioctls, I help to provide required level of pain. Deal? - Al Viro on linux-kernel

1 0

RE: Array operations and pinning
by Simon Marlow 09 Nov '05

09 Nov '05

On 02 November 2005 11:15, Rene de Visser wrote: > Where is the documentation on how pinning works in the GHC garbage > collector (from a GHC users point of view). > > I have copied the following code from array/IO.hs and am thinking > that it is assuming that the array is pinned? What triggers the > pinning? Actually this code does not assume that any memory is pinned. It is ok to pass the underlying ByteArr# directly to C, as long as the C call is annotated "unsafe", which means that GC cannot happen while the call is running. If you want to pass ByteArr# to a "safe" C call, then you have to allocate the ByteArr# using newPinnedByteArray#. This is the only way to get a pinned object in GHC, and the only kind of pinned object that is supported is a MutByteArr# or ByteArr# (this is to simplify the GC; it doesn't need to traverse pinned objects because they don't contain any pointers, all it needs to do is remember that the memory block they occupy is still alive). Note that all this is GHC-specific; the right high-level interface to allocating pinned memory is mallocForeignPtr. > On a second note. > Why is the type signiture so constricted. The code below works on any > IOUArray (which is very usefull, not just on Int Word8). Naturally > this assumes the particular in memory array layout that GHC uses on a > particular platform, so would not be compatible (probably) with other > Haskell compilers. I think the type is right - it makes it clear that the representation being written to the file is an array of bytes. You can use castIOUArray, although that isn't ideal (it doesn't change the bounds). We should do something better here. Cheers, Simon

8 7

Proposal: Improved error message of "Error in array index"
by Rene de Visser 08 Nov '05

08 Nov '05

>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. What I think would be good is the ability to compile the executable with a top level exeception handler which goes into a low level debugger where you can examine the thunk and its surroundings. I presume that some type information is retained for the garbage collector? Enough to tell integers from pointers? Also error "Error in array index" ++ internal_show_b b ++ internal_show_i i could be done, which wouldn't have the problem of exporting unwanted show instances. Rene.

1 0