<div dir="ltr">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. </div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Sep 29, 2014 at 2:12 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <div><div class="h5"> On Mon, Sep 29, 2014 at 1:06 PM, Jonathan Schuster <<a href="mailto:schuster@ccs.neu.edu">schuster@ccs.neu.edu</a>> 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. > </div></div>> ____________________ > Racket Users list: > <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a> > </blockquote></div> </div>