[racket] Better discoverability for errortrace

If you want to go that way, I think the right thing is to change the
initial error-display-handler that racket installs when it is started
up in "open a repl" mode.

I will note, however, that there are lots of things that aren't
discoverable in this way. Indeed, I would prefer that if someone were
unhappy with their feedback of the racket repl that they were directed
to a) use xrepl, b) use Greg's emacs mode, or c) use drracket, all
ahead of being directed to use "racket -l errortrace -t file.rkt".
That latter one I view as a convenience for wizards, not something
where discovery is important.

Robby


On Mon, Sep 29, 2014 at 1:42 PM, Jonathan Schuster <schuster at ccs.neu.edu> wrote:
> 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
>> >
>
>