[racket] Better discoverability for errortrace

Hmm, I agree that there are cases when the message is extraneous, but I
think adding it only to something like xrepl doesn't solve the core
discoverability issue for those who use plain vanilla Racket on the command
line. What about a parameter that determines if the message should be
printed or not, and DrRacket could enable or disable it as needed? It could
be enabled by default, so that places like the REPL would still show the
message.

On Mon, Sep 29, 2014 at 2:12 PM, Robby Findler <robby at eecs.northwestern.edu>
wrote:

> I don't think that that particular message makes sense as part of the
> default error messages. Specifically, if you disable errortrace in
> drracket, then you wouldn't want to see those messages (or, perhaps
> more accurately, you'd want to see different error messages). Maybe
> the repl that racket starts up can do that, tho?
>
> But perhaps this is something to add to xrepl?
>
> Robby
>
> On Mon, Sep 29, 2014 at 1:06 PM, Jonathan Schuster <schuster at ccs.neu.edu>
> wrote:
> > We were having a discussion today in the Northeastern lab about how the
> > Racket stack traces sometimes don't give enough information, and the
> > solution to the problem (errrortrace) is not very discoverable if you're
> not
> > using DrRacket.
> >
> > Here's an example of the kind of case I mean:
> >
> > $ racket -t jpg.rkt
> > Assertion failed on #f
> >   context...:
> >    do-it
> >    /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop
> >    decode-jpeg
> >    /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]
> >
> > $ racket -l errortrace -t jpg.rkt
> > Assertion failed on #f
> >   errortrace...:
> >    /Users/acobb/programs/jpg-parse/jpg.rkt:126:16: (assert #f)
> >    /Users/acobb/programs/jpg-parse/jpg.rkt:363:36: (huff-dc-decode
> dc-tree
> > bits)
> >    /Users/acobb/programs/jpg-parse/jpg.rkt:407:37: (reader bits)
> >    <eliding for length>
> >   context...:
> >    huff-dc-decode
> >    do-it
> >    /Users/acobb/programs/jpg-parse/jpg.rkt:406:5: for-loop
> >    /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop
> >    decode-jpeg
> >    /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]
> >
> >
> > To solve the discoverability issue, what would people think of putting a
> > message like "If this information is not sufficient, try errrortrace with
> > racket -l errortrace -t <prog>" after the default trace? Also, can anyone
> > think of a way to programmatically detect when a trace is not informative
> > enough and only display the message in those cases? I haven't looked into
> > the feasibility of this myself; it's just an idea that came up during our
> > discussion.
> >
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20140929/2cb0df69/attachment-0001.html>