<div dir="ltr"><div>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:<br><br></div>racket --errortrace <prog><br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><br></div>~Leif Andersen</div></div>
<br><div class="gmail_quote">On Mon, Sep 29, 2014 at 2:12 PM, Robby Findler <span dir="ltr"><<a href="mailto:robby@eecs.northwestern.edu" target="_blank">robby@eecs.northwestern.edu</a>></span> wrote:<br><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<br>
default error messages. Specifically, if you disable errortrace in<br>
drracket, then you wouldn't want to see those messages (or, perhaps<br>
more accurately, you'd want to see different error messages). Maybe<br>
the repl that racket starts up can do that, tho?<br>
<br>
But perhaps this is something to add to xrepl?<br>
<br>
Robby<br>
<div><div class="h5"><br>
On Mon, Sep 29, 2014 at 1:06 PM, Jonathan Schuster <<a href="mailto:schuster@ccs.neu.edu">schuster@ccs.neu.edu</a>> wrote:<br>
> We were having a discussion today in the Northeastern lab about how the<br>
> Racket stack traces sometimes don't give enough information, and the<br>
> solution to the problem (errrortrace) is not very discoverable if you're not<br>
> using DrRacket.<br>
><br>
> Here's an example of the kind of case I mean:<br>
><br>
> $ racket -t jpg.rkt<br>
> Assertion failed on #f<br>
>   context...:<br>
>    do-it<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop<br>
>    decode-jpeg<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]<br>
><br>
> $ racket -l errortrace -t jpg.rkt<br>
> Assertion failed on #f<br>
>   errortrace...:<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt:126:16: (assert #f)<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt:363:36: (huff-dc-decode dc-tree<br>
> bits)<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt:407:37: (reader bits)<br>
>    <eliding for length><br>
>   context...:<br>
>    huff-dc-decode<br>
>    do-it<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt:406:5: for-loop<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt:402:2: for-loop<br>
>    decode-jpeg<br>
>    /Users/acobb/programs/jpg-parse/jpg.rkt: [running body]<br>
><br>
><br>
> To solve the discoverability issue, what would people think of putting a<br>
> message like "If this information is not sufficient, try errrortrace with<br>
> racket -l errortrace -t <prog>" after the default trace? Also, can anyone<br>
> think of a way to programmatically detect when a trace is not informative<br>
> enough and only display the message in those cases? I haven't looked into<br>
> the feasibility of this myself; it's just an idea that came up during our<br>
> discussion.<br>
><br>
</div></div>> ____________________<br>
>   Racket Users list:<br>
>   <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
><br>
____________________<br>
  Racket Users list:<br>
  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</blockquote></div><br></div>