Provide better interactive method definition info

[quinnj]

Currently when methods are defined at the REPL, you don't get much information:

julia> function hey(x,y)
       return x + y*2
       end
hey (generic function with 1 method)

julia> methods(hey)
#1 method for generic function "hey":
hey(x,y) at none:2     #  <-- "none"? what is line 2 of "none"?

Whereas methods from files and even IJulia provide much better info.

In  [2]: function hey(x,y)
            return x + y*2
        end

Out [2]: hey (generic function with 1 method)

In  [3]: methods(hey)

Out [3]: # 1 method for generic function "hey":
hey(x,y) at In[2]:2   # <-- We at least see what "In [x]:" the method was defined in

With all the new fancy REPL/history machinery, could we make this better somehow? Maybe provide the timestamp from history where the method was defined?

Not only would this help in better discerning where a method definition is coming from, but this would also provide a mechanism for #2625 without having to keep the original method definition string somewhere.

[StefanKarpinski]

We can actually use lines of the history file although that complicates the internal repl flow a bit.

[stevengj]

IJulia calls include_string(string, "In[xx]") where the second argument is a "file name" to use for parsing. I don't see any reason why the REPL could not do something similar, with a bit of support from the parser.

Things are a bit different for the REPL, compared to IJulia, because the REPL has to decide dynamically when the input is finished (i.e. when an expression is complete), and hence it needs to call parse_input_line (→ C jl_parse_input_line → Scheme jl-parse-string) instead of include_string (→ C jl_load_file_string → Scheme jl-parse-string-stream).

However, it seems like it would be straightforward to make a version of parse_input_line that accepts an extra argument, the "file name" to use for labeling method definitions etcetera, simply by adding a C function to call Scheme to push/pop the current-filename on the *filename-stack* in Scheme.

I'm still unclear on what "filename" label you want, however. One option would be to change the REPL to number the input/output lines, like IPython's console interface and like IJulia notebooks. Is that something people would like?

(I don't see what this has to do with the history. What is in the history file is irrelevant; all that matters is what definitions you actually evaluated in the REPL in the current session.)

[StefanKarpinski]

The reason the history file would be relevant is that later if you want to debug code entered into the REPL, the history file happens to be a place where that code is saved. So, for example, if you do

julia> function foo()
           # do stuff
           # and things
           # or whatnot
       end
foo (generic function with 1 method)

julia> @edit foo()
ERROR: could not find function definition
 in functionlocs at reflection.jl:153
 in edit at interactiveutil.jl:55

instead of showing that error, it could actually open up the history file at that function definition.

[stevengj]

I guess I've never actually used @edit. In the REPL, I normally just use ctrl-r to find code.

I'm skeptical that you would actually want to open up the history file in an editor during a live REPL session, though.

[KristofferC]

This now shows:

julia> methods(hey)
# 1 method for generic function "hey":
hey(x, y) in Main at REPL[3]:2

which seems to be along the line of the requested. Tentatively closing, please reopen if there is more to do here.