replace definition of error with errorWithStackTrace

Thu Dec 18 04:31:14 UTC 2014

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
:) )

On Wed, Dec 17, 2014 at 11:23 PM, Carter Schonwald <
carter.schonwald at 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 <johan.tibell at gmail.com>
> 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" <cma at bitemyapp.com> 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 at 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 <johan.tibell at gmail.com>
>>>> 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 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20141217/5e852c6a/attachment-0001.html>