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 <ro...@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 <schus...@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 >
____________________ Racket Users list: http://lists.racket-lang.org/users
