[racket] Better discoverability for errortrace
Another possibility we discussed was to give errortrace it's own flag that
shows up when you do racket -h. It certainly wouldn't really scale for all
of the libraries, but errortrace seems like it's something common enough
that it might deserve it's own flag. Maybe something like:
racket --errortrace <prog>
~Leif Andersen
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
> >
> ____________________
> 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/3ce2c361/attachment.html>