Extended printing at a MethodError.

[dhoegh]

I have extended #7714 with the following:

• Take into account that args... is a match and removed the requirement of equal lengths of arguements of the input and method.
• The match also takes into account that parametric methods args needs to have the same type for one T variable. Plus added some printing for parametric methods.
• Lastly I have added so the file and line number for the function also are printed

The following will demo the difference, suppose you have the following methods deffined:

g(x::Int, args...) = pass
g(x::Int, y::Float64 ,args...) = pass
g(x::Int, y::Float64) = pass
g{T<:Real}(x::T, y::T, z::T) = pass

Before you would get:

Where it shows that the parametric type matches all arguments and the second is two arguments from matching but in reality if you change the first argument to an Int then it matches. With this pull-request it displays:

@jhasse could you approve/comment on my changes since you are the original author of this, nice work and idea by the way. Also pinging some of the reviewers in #7714 to hear their opinion, @ivarne, @simonster, @mbauman.

[jhasse]

Just tested this and it works great :) Good work!

I'm against including the file and line number, it makes the output to verbose. Also the user can get the information using methods(g).

[dhoegh]

@jhasse I do agree with you it was very verbose so have removed the printing of file and line number again and removed the misplaced space you found. If nobody have any further concerns then it is ready to merge.

[dhoegh]

I have refactored the pull-request to use typeintersect function which should both improve the speed and make the code less error-prone.

[dhoegh]

@tkelman could you help me figure out the Travis failure? I have seen the failure on mac and windows but not on linux. I cannot reproduce it locally. The error is:

exception on 2: ERROR: LoadError: invalid method definition: not a generic function
 in runtests at /private/tmp/julia/share/julia/test/testdefs.jl:5
 in anonymous at multi.jl:852
 in run_work_thunk at multi.jl:603
 in anonymous at task.jl:852
while loading replutil.jl, in expression starting on line 9
ERROR: LoadError: LoadError: invalid method definition: not a generic function
 in anonymous at task.jl:1616
while loading replutil.jl, in expression starting on line 9
while loading /private/tmp/julia/share/julia/test/runtests.jl, in expression starting on line 42

The error goes away if i wrap the function difinitions in a module like:

module ReplutilTest
    fe(x::Float64, s::AbstractString...) = true
    ge(x::Int32, args...) = true
    ge(x::Int32, y::Float64 ,args...) = true
    ge(x::Int32, y::Float64) = true
    ge{T<:Real}(x::T, y::T, z::T) = true
end

And of cause reference to the function in the module by ReplutilTest.fe.

[dhoegh]

What I do not understand is why the line with fe(x::Float64, s::AbstractString...) = true should raise an error.

[ivarne]

Seems like it might be a variable named fe that has been used earlier (maybe in another test file, if we don't clear the session).

[dhoegh]

Thank you @ivarne. There where a const fe in random.jl, I think I'm going to file an issue on that error message, I could not understand what it tried to tell me:)

[dhoegh]

I have squashed the commits, added test cases and made Travis happy. From my point of view this is ready to merge unless people have some further feedback.

[timholy]

weird indentation here

[timholy]

This looks awesome---I've really been enjoying #7714, and this looks to make it even better.

One thing to consider is the use of the new emphasize function in show; if you don't have color, it prints things in uppercase. There are some ways in which that could be misleading (what if someone defined two types that differ only in their case?), of course.

[jhasse]

One thing to consider is the use of the new emphasize function in show;
if you don't have color, it prints things in uppercase. There are some ways
in which that could be misleading (what if someone defined two types that
differ only in their case?), of course.

I'm against that. IMHO color should always be available and if it isn't (e.
g. an editor running Julia) it should be fixed instead of the workaround
using caps.

[timholy]

Can you clarify what you mean by "it should be fixed"? Some terminals simply don't support color.

I should be explicit about my underlying motivation for suggesting this: I'm not certain, but I suspect our travis tests run with have_color=false. A really nice aspect of all this work is the highlighting of arguments that don't match; but when there is no color, there's nothing to indicate which arguments match and which ones don't. That means that the highlighting aspect of this functionality is not actually getting tested.

[dhoegh]

I have made the small correction according to you @timholy. I agree with @jhasse that it could be misleading with all upper cases. Could we do something like putting ! or ≠ in front of the type. Like:

julia>g(x::Int, y::Int) = pass
julia>g(1.,1)
Closest candidates are:
method_c1(!::Int64, ::Int64)

Or

method_c1(Float64!<:Int64, ::Int64)

[timholy]

I especially like the Float64!<:Int64 idea.

[jhasse]

Can you clarify what you mean by "it should be fixed"? Some terminals
simply don't support color.

I mean that these terminals should be fixed to support colors. "Color
support" should be treated the same way as "newline support". It's an
esential feature for me.

I should be explicit about my underlying motivation for suggesting this:
I'm not certain, but I suspect our travis tests run with have_color=false.
A really nice aspect of all this work is the highlighting of arguments that
don't match; but when there is no color, there's nothing to indicate which
arguments match and which ones don't. That means that the highlighting
aspect of this functionality is not actually getting tested.

I see. What is the reason behind deactivating colors for tests?

[timholy]

julia is asking the OS whether color is available, and if the answer is "no" then it doesn't try to use it. For example, when you redirect STDOUT to a file, odds are you don't want all those dratted special characters appearing in the output. When you run your tests as make testall, you're not running in the REPL, so the (internal) display doesn't support color.

[dhoegh]

@timholy then I'm going to implement that suggestion tomorrow when color is not supported by the terminal.

[jhasse]

julia is asking the OS whether color is available, and if the answer is
"no" then it doesn't try to use it. For example, when you redirect STDOUT
to a file, odds are you don't want all those dratted special characters
appearing in the output. When you run your tests as make testall, you're
not running in the REPL, so the (internal) display doesn't support color.

What do you mean by internal display?

[dhoegh]

@timholy I have updated the pull-request to print this when have_color=false

julia>method_c1(x::Float64, s::AbstractString...) = true
julia>method_c1(1, "", 1)
ERROR: `method_c1` has no method matching method_c1(::Int64, ::ASCIIString, ::Int64)
Closest candidates are:
  method_c1(!Matched::Float64, !Matched::AbstractString...)

I did not do as we discussed yesterday due to AbstractString... matches multiple arguments and hence it can not be written as discussed then it would write ASCIIString!<:AbstractString.... It is also a problem when the number of arguments given is shorter than the method in question like:

julia>method_c1(1)
ERROR: `method_c1` has no method matching method_c1(::Int64, ::ASCIIString, ::Int64)
Closest candidates are:
  method_c1(Int64!<:Float64, ::AbstractString...)

And hence I do not know what should be in front of AbstractString.... Do any one have a better solution than printing !Matched in front of not matched types when the terminal do not have colors.

[timholy]

!Matched seems fine to me; nice job thinking through the likely problems.

[timholy]

Thanks for doing this!