+1 - I would be very happy if this happened. On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton wrote:

having just spent a day tracking down a really uninformative error in Cabal, I'm all for this.

On Mon Dec 01 2014 at 11:08:35 Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorW...

has been in GHC for for >=1 major version, and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message!

I think this change would benefit many!

My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands.

discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed!

cheers -Carter

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design. I think we have something of a consensus forming around https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations, see #9049. It’s simple, non-invasive, and predicatable. It does need someone to implement it though. Simon Hengel is thinking about implementing it. (He is the one who also suggested “rewrite with location”). So I think we are stalled not so much on design but on implementation. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Michael Snoyman Sent: 01 December 2014 05:33 To: Christopher Allen; Mark Wotton Cc: Haskell Libraries Subject: Re: replace definition of error with errorWithStackTrace +1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design. [1] https://github.com/sol/rewrite-with-location [2] https://github.com/sol/rewrite-with-location#explicit-call-stacks On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen mailto:cma@bitemyapp.com> wrote: +1 - I would be very happy if this happened. On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton mailto:mwotton@gmail.com> wrote: having just spent a day tracking down a really uninformative error in Cabal, I'm all for this. On Mon Dec 01 2014 at 11:08:35 Carter Schonwald mailto:carter.schonwald@gmail.com> wrote: http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorW... has been in GHC for for >=1 major version, and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message! I think this change would benefit many! My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands. discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed! cheers -Carter _______________________________________________ Libraries mailing list Libraries@haskell.orgmailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.orgmailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries@haskell.orgmailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Why don't we use the DWARF information instead? It has no runtime overhead so it can actually be turned on always. It also integrates with all the standard open source tooling. On Tue, Dec 2, 2014 at 10:04 AM, Simon Peyton Jones wrote:

+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.

I think we have something of a consensus forming around https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations, see #9049. It’s simple, non-invasive, and predicatable. It does need someone to implement it though. Simon Hengel is thinking about implementing it. (He is the one who also suggested “rewrite with location”).

So I think we are stalled not so much on design but on implementation.

Simon

*From:* Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of *Michael Snoyman *Sent:* 01 December 2014 05:33 *To:* Christopher Allen; Mark Wotton *Cc:* Haskell Libraries *Subject:* Re: replace definition of error with errorWithStackTrace

+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.

[1] https://github.com/sol/rewrite-with-location

[2] https://github.com/sol/rewrite-with-location#explicit-call-stacks

On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen wrote:

+1 - I would be very happy if this happened.

On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton wrote:

having just spent a day tracking down a really uninformative error in Cabal, I'm all for this.

On Mon Dec 01 2014 at 11:08:35 Carter Schonwald < carter.schonwald@gmail.com> wrote:

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorW...

has been in GHC for for >=1 major version,

and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message!

I think this change would benefit many!

My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands.

discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed!

cheers

-Carter

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

I don't think the dwarf information replaces the utility of this proposal, this proposal, critically, will help the new users who won't know how to use debugging information. It'll also give people useful first-pass information for reproducing the error for later, more detailed debugging. I'd very much like to see this happen if there aren't technical arguments against it. --- Chris Allen On Tue, Dec 16, 2014 at 10:38 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

if the dwarf information work is landing in 7.10 (as it seems to be), perhaps my proposal is moot. But either way, making error "foo" and friend more informative by default would be a great thing to make sure happens.

I think we had a clear majority supporting this proposal, but i think *some* basic dwarf support got merged in today?

-Carter

On Tue, Dec 2, 2014 at 5:02 AM, Johan Tibell wrote:

...

Why don't we use the DWARF information instead? It has no runtime overhead so it can actually be turned on always. It also integrates with all the standard open source tooling.

On Tue, Dec 2, 2014 at 10:04 AM, Simon Peyton Jones < simonpj@microsoft.com> wrote:

...

+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.

I think we have something of a consensus forming around https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations, see #9049. It’s simple, non-invasive, and predicatable. It does need someone to implement it though. Simon Hengel is thinking about implementing it. (He is the one who also suggested “rewrite with location”).

So I think we are stalled not so much on design but on implementation.

Simon

*From:* Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of *Michael Snoyman *Sent:* 01 December 2014 05:33 *To:* Christopher Allen; Mark Wotton *Cc:* Haskell Libraries *Subject:* Re: replace definition of error with errorWithStackTrace

+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.

[1] https://github.com/sol/rewrite-with-location

[2] https://github.com/sol/rewrite-with-location#explicit-call-stacks

On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen wrote:

+1 - I would be very happy if this happened.

On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton wrote:

having just spent a day tracking down a really uninformative error in Cabal, I'm all for this.

On Mon Dec 01 2014 at 11:08:35 Carter Schonwald < carter.schonwald@gmail.com> wrote:

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorW...

has been in GHC for for >=1 major version,

and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message!

I think this change would benefit many!

My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands.

discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed!

cheers

-Carter

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

sure, will GHC provide that out of the box for 7.10 though? It sounds like it'll require exceptions to "core dump" right? and then use lldb or gdb or something related? On Wed, Dec 17, 2014 at 2:10 AM, Johan Tibell wrote:

The idea with using dwarf info is that error (and all exception messages) would always include a stack trace automatically, just like in other languages. On Dec 17, 2014 5:49 AM, "Christopher Allen" wrote:

...

I don't think the dwarf information replaces the utility of this proposal, this proposal, critically, will help the new users who won't know how to use debugging information. It'll also give people useful first-pass information for reproducing the error for later, more detailed debugging.

I'd very much like to see this happen if there aren't technical arguments against it.

--- Chris Allen

On Tue, Dec 16, 2014 at 10:38 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

if the dwarf information work is landing in 7.10 (as it seems to be), perhaps my proposal is moot. But either way, making error "foo" and friend more informative by default would be a great thing to make sure happens.

I think we had a clear majority supporting this proposal, but i think *some* basic dwarf support got merged in today?

-Carter

On Tue, Dec 2, 2014 at 5:02 AM, Johan Tibell wrote:

...

Why don't we use the DWARF information instead? It has no runtime overhead so it can actually be turned on always. It also integrates with all the standard open source tooling.

On Tue, Dec 2, 2014 at 10:04 AM, Simon Peyton Jones < simonpj@microsoft.com> wrote:

...

+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.

I think we have something of a consensus forming around https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations, see #9049. It’s simple, non-invasive, and predicatable. It does need someone to implement it though. Simon Hengel is thinking about implementing it. (He is the one who also suggested “rewrite with location”).

So I think we are stalled not so much on design but on implementation.

Simon

*From:* Libraries [mailto:libraries-bounces@haskell.org] *On Behalf Of *Michael Snoyman *Sent:* 01 December 2014 05:33 *To:* Christopher Allen; Mark Wotton *Cc:* Haskell Libraries *Subject:* Re: replace definition of error with errorWithStackTrace

+1, as I don't see a downside. However, I don't think this change is a sufficient change as long as stack traces are only available for profiled builds. I still wish something like rewrite-with-location[1], which even addresses explicit stack traces directly[2]. IIRC, last time that feature was brought up for discussion, it stalled due to disagreements on the right design.

[1] https://github.com/sol/rewrite-with-location

[2] https://github.com/sol/rewrite-with-location#explicit-call-stacks

On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen wrote:

+1 - I would be very happy if this happened.

On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton wrote:

having just spent a day tracking down a really uninformative error in Cabal, I'm all for this.

On Mon Dec 01 2014 at 11:08:35 Carter Schonwald < carter.schonwald@gmail.com> wrote:

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorW...

has been in GHC for for >=1 major version,

and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message!

I think this change would benefit many!

My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands.

discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed!

cheers

-Carter

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Wed, Dec 17, 2014 at 11:31 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

and ... currently exceptions / error dont trigger a core dump right? So how on earth will i get that dwarf stack trace? (seriously, i'm really ignorant :) )

In the general case, if you use a library that can understand binary formats and extract debug information (e.g. GNU libbfd), you can implement your own. There are also ways to do it without a library, although portability can be a concern in that case. That said, my understanding of the GHC DWARF stuff is that it's statically integrated with code generation, such that the runtime can use it to print a meaningful stack trace without the runtime overhead of profiling. Note that it's not necessary or even useful to do a full stack trace in this case --- for example, given how Haskell evaluation works, the whole notion of printing parameters is hazy at best, especially when the parameter is a function. So emulating --- or indeed using --- a debugger to get the stack trace is both overkill and pointless.

On Wed, Dec 17, 2014 at 11:23 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

sure, will GHC provide that out of the box for 7.10 though? It sounds like it'll require exceptions to "core dump" right? and then use lldb or gdb or something related?

On Wed, Dec 17, 2014 at 2:10 AM, Johan Tibell wrote:

...

The idea with using dwarf info is that error (and all exception messages) would always include a stack trace automatically, just like in other languages. On Dec 17, 2014 5:49 AM, "Christopher Allen" wrote:

...

I don't think the dwarf information replaces the utility of this proposal, this proposal, critically, will help the new users who won't know how to use debugging information. It'll also give people useful first-pass information for reproducing the error for later, more detailed debugging.

I'd very much like to see this happen if there aren't technical arguments against it.

--- Chris Allen

On Tue, Dec 16, 2014 at 10:38 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

if the dwarf information work is landing in 7.10 (as it seems to be), perhaps my proposal is moot. But either way, making error "foo" and friend more informative by default would be a great thing to make sure happens.

I think we had a clear majority supporting this proposal, but i think *some* basic dwarf support got merged in today?

-Carter

On Tue, Dec 2, 2014 at 5:02 AM, Johan Tibell wrote:

...

Why don't we use the DWARF information instead? It has no runtime overhead so it can actually be turned on always. It also integrates with all the standard open source tooling.

On Tue, Dec 2, 2014 at 10:04 AM, Simon Peyton Jones < simonpj@microsoft.com> wrote:

> +1, as I don't see a downside. However, I don't think this change > is a sufficient change as long as stack traces are only available for > profiled builds. I still wish something like rewrite-with-location[1], > which even addresses explicit stack traces directly[2]. IIRC, last time > that feature was brought up for discussion, it stalled due to disagreements > on the right design. > > I think we have something of a consensus forming around > https://ghc.haskell.org/trac/ghc/wiki/ExplicitCallStack/ImplicitLocations, > see #9049. It’s simple, non-invasive, and predicatable. It does need > someone to implement it though. Simon Hengel is thinking about > implementing it. (He is the one who also suggested “rewrite with > location”). > > > > So I think we are stalled not so much on design but on > implementation. > > > > Simon > > > > *From:* Libraries [mailto:libraries-bounces@haskell.org] *On Behalf > Of *Michael Snoyman > *Sent:* 01 December 2014 05:33 > *To:* Christopher Allen; Mark Wotton > *Cc:* Haskell Libraries > *Subject:* Re: replace definition of error with errorWithStackTrace > > > > +1, as I don't see a downside. However, I don't think this change is > a sufficient change as long as stack traces are only available for profiled > builds. I still wish something like rewrite-with-location[1], which even > addresses explicit stack traces directly[2]. IIRC, last time that feature > was brought up for discussion, it stalled due to disagreements on the right > design. > > > > [1] https://github.com/sol/rewrite-with-location > > [2] > https://github.com/sol/rewrite-with-location#explicit-call-stacks > > > > On Mon Dec 01 2014 at 6:39:25 AM Christopher Allen < > cma@bitemyapp.com> wrote: > > +1 - I would be very happy if this happened. > > > > On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton > wrote: > > having just spent a day tracking down a really uninformative error > in Cabal, I'm all for this. > > On Mon Dec 01 2014 at 11:08:35 Carter Schonwald < > carter.schonwald@gmail.com> wrote: > > > http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorW... > > > has been in GHC for for >=1 major version, > > and for normal builds, acts just like error, BUT, when an error is > thrown in a profiled build, it appends a stack trace with some basic source > location data to the end of the error message! > > > > I think this change would benefit many! > > > > My current understanding is that the DWARF based approach to stack > traces wont make it into GHC 7.10 , and while this variant would only > provide extra info in profiling builds (and strictly less than the dwarf > work), its something that can definitely be done in a single small patch > that could easily be swapped out for that improved approach once it lands. > > > > > > discussion period: 2 weeks unless theres a clear unanimous agreement > to make the change ASAP, OR if the stack trace error stuff is landing in > 7.10 and I'm misinformed! > > > > cheers > > -Carter > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

| As far as I understand, DWARF information will give us the dynamic | chain, while the ImplicitLocations idea will give us fragments of the | static chain. So I believe these two features are complementary, and | most useful if combined. I think that's a very accurate summary, thanks. Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of | Bertram Felgenhauer | Sent: 25 December 2014 20:10 | To: libraries@haskell.org | Subject: Re: replace definition of error with errorWithStackTrace | | Johan Tibell wrote: | > Why don't we use the DWARF information instead? It has no runtime | overhead | > so it can actually be turned on always. It also integrates with all the | > standard open source tooling. | | I think there are two backtrace-like chains of interest for every | Haskell value: There is one "static" chain that tracks how values are | created, and one "dynamic" chain that tracks the actual evaluation. | For example, for | | makePair :: (Int, Int) | makePair = (error "The first component is actually undefined", 42) | | sumPair :: (Int, Int) -> Int | sumPair (a, b) = a + b | | main = print $ sumPair makePair | | the static chain up to the error call would be | | main -> makePair -> error | | while the dynamic chain that actually produces the error is something | like | | main -> print -> show -> sumPair -> (+) -> error | | As far as I understand, DWARF information will give us the dynamic | chain, while the ImplicitLocations idea will give us fragments of the | static chain. So I believe these two features are complementary, and | most useful if combined. | | Cheers, | | Bertram | _______________________________________________ | Libraries mailing list | Libraries@haskell.org | http://www.haskell.org/mailman/listinfo/libraries

Carter Schonwald wrote:

how do profiling stack traces fit into that "Static" vs "Dynamic" continuum?

Except for the way they deal with recursion (if an SCC is already on the SCC stack, then it is not pushed again), they're static traces, going by the description at https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/profiling.htm... Actually recursion poses an interesting problem for static traces; it'd be awkward to see long traces like foo -> foo.go -> ... -> foo.go -> bar just because foo does some kind of iteration. BTW, I'm not completely happy with the terminology. The idea is that * 'static' traces match the function calls visible in the program's source code. * 'dynamic' traces very much depend on the evaluation order, which in practice means that they're subject to optimization choices of the compiler and non-determinism introduced by sparks and threads. Perhaps 'call trace' and 'stack trace' are better names. A possible downside with those terms is that they are familiar and used interchangably for strict programming languages, so the fact that there's a difference between them in Haskell is easily lost. Cheers, Bertram

Note that you can already get this by running with `+RTS -xc -RTS'. Francesco On 1 December 2014 at 16:20, John Lato wrote:

+1 seems clearly better.

On 20:09, Sun, Nov 30, 2014 Mark Wotton wrote:

...

having just spent a day tracking down a really uninformative error in Cabal, I'm all for this.

On Mon Dec 01 2014 at 11:08:35 Carter Schonwald wrote:

...

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorW... has been in GHC for for >=1 major version, and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message!

I think this change would benefit many!

My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands.

discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed!

cheers -Carter

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries