replace definition of error with errorWithStackTrace

[Johan Tibell]

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 at 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 at 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 at bitemyapp.com>
> wrote:
>
>  +1 - I would be very happy if this happened.
>
>
>
> On Sun, Nov 30, 2014 at 10:09 PM, Mark Wotton <mwotton at 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 <
> carter.schonwald at gmail.com> wrote:
>
>
> http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:errorWithStackTrace
>
>
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141202/9c72d7bf/attachment.html>