more info in errors

[tor]

Sometimes debugging is more convenient when error messages has more information. In particular I would like subscript errors to report exactly what is going on, such as:

Index out of range: 0 not in [1..256]

or

Index out of range: 2147483648 not in [1..1000]

This tends to immediately make clear what's wrong.

[Tim Holy]

This would not be an issue if we had a debugger. I'm not clear on how the
whole backtrace thing works, however, and therefore I don't know how difficult
it would be to (optionally) leave the user in the deepest portion of the call
stack where the error occurred (i.e., like Matlab's "dbstop if error").

--Tim

[Patrick O'Leary]

+1 for DBSTOP IF ERROR equivalent, but probably contingent on having a debugger to stop execution into :D

The request for printing more detailed subscripting error information sounds familiar. It would definitely be helpful.

[Tim Holy]

On Monday, July 09, 2012 06:43:17 AM Patrick O'Leary wrote:
> +1 for DBSTOP IF ERROR equivalent, but probably contingent on having a
> debugger to stop execution into :D

I know next to zero about compilers/debuggers/etc. It looks like we already
use libunwind to generate the stack trace in our current error-reporting code.
According to their website, it seems that's already much of the way to a
debugger, and in any event it's oh-so-easy to write one as long as you just
use libunwind :-). Anyone who knows something about these topics care to
comment? Or maybe even write one? :-)

I thought a profiler was esoteric, and while it ended up being quite a few
lines of code, it was much more straightforward for a mere mortal to code up
than I expected. All thanks to the metaprogramming awesomeness of Julia, of
course!

--Tim

[Stefan Karpinski]

We don't actually use libunwind on OS X because we could never get it to work. Jameson (if I recall correctly) came along and just got some non-libunwind stack walking goodness to work and that's what's done still afaik.

As to the debugger, I don't know, but what Jeff and I had once discussed was having a debug mode where code is just emitted such that a debug callback is invoked after the evaluation of each expression. That really might not be much harder than writing a profiler, just by writing @debug begin ... end and munging the AST that @debug gets. Most of the time you want to just debug a particular block of code anyway, so that would be a good starting point.

[Tim Holy]

On Tuesday, July 10, 2012 12:41:07 PM Stefan Karpinski wrote:
> As to the debugger, I don't know, but what Jeff and I had once discussed
> was having a debug mode where code is just emitted such that a debug
> callback is invoked after the evaluation of each expression. That really
> might not be much harder than writing a profiler, just by writing @debug
> begin ... end and munging the AST that @debug gets. Most of the time you
> want to just debug a particular block of code anyway, so that would be a
> good starting point.

Something along these lines was tickling at the back of my brain, too, but it
hadn't crystallized this way yet. Thanks!

But what is a "debug callback"? In particular, for "dbstop if error" I guess
the core would be something like this:

macro dbstop_one_line(ex)
quote
try
$ex
catch
keyboard # gives me a "julia-debug> " interactive prompt
end
end
end

I don't know how to write "keyboard." Hmm, I see there's a file in base/ called
"client.jl," is the answer in there?

--Tim

[Stefan Karpinski]

On Tue, Jul 10, 2012 at 1:37 PM, Tim Holy <tim....@gmail.com> wrote:

Something along these lines was tickling at the back of my brain, too, but it
hadn't crystallized this way yet. Thanks!

But what is a "debug callback"? In particular, for "dbstop if error" I guess
the core would be something like this:

macro dbstop_one_line(ex)
    quote
         try
            $ex
        catch
            keyboard   # gives me a "julia-debug> " interactive prompt
        end
    end
end

I don't know how to write "keyboard." Hmm, I see there's a file in base/ called
"client.jl," is the answer in there?

Yes, that's basically it. You emit code that does what the repl loop in client.jl does. Might want to start with something easier and less fancy than using readline though — just reading from stdin. If we had julia bindings to readline, the repl stuff could be moved entirely into julia code, but I'm hesitant to do that because the readline stuff is so tricky.

[Jameson Nash]

I tried it in the libuv branch and it was surprisingly easy to almost get this to work (3-5 lines of code to run the repl prompt -- essentially run_repl() -- inside of a function inside the repl). What prevented it from being particularly useful was that repl code is processed with eval() so it was running entirely in the global scope and was thus no better than getting dumped back into the repl. To make this useful, dbstop_one_line would somehow need to acquire access to the local variables. Possibly the macro could add a few lines after catch to push all (detected) local variables into the global scope? Or if the debugger was running it's own command processor, maybe it could somehow preprocess the symbols?

-jameson

[Stefan Karpinski]

Ah crap. That's right. This may be harder than I realized.

[Tim Holy]

On Tuesday, July 10, 2012 02:22:40 PM Stefan Karpinski wrote:
> Ah crap. That's right. This may be harder than I realized.

Is there a reasonable way forward? We seem close, and I'd say having a
debugger (even rudimentary, i.e., just dbstop if error) would be a major step
forward. So I hope this discussion doesn't end here.

Is there a way to do "eval_in"? Or is Jameson's suggestion of exporting the
variables to the global workspace the right answer? If so, should we pack them
into a container of some kind, just to prevent overwriting?

--Tim

[Stefan Karpinski]

I'm not sure what the way forward is. Jeff should be able to shed more light on the matter once he comes around. (We were up late last night for a paper deadline so neither of us is really "on it" today.) I completely agree that having a debugger is essential. The main question is just whether you can do it by this kind of code manipulation or not...