Hide long types in error output for better readability

Do you mean: https://github.com/cmcaine/julia-error-message-catalogue
?

1 Like

The fact is that it isn’t that simple. Sometimes the function F has a method with two arguments, but different types than those used. And you may also have dozens of two-argument methods, all of them with different types.

2 Likes

Probably this one:

The discussion contains a lot of interesting ideas. I don’t know the progress towards implementation.

1 Like

As @giordano pointed out, generally this is not something the language can figure out from the method table, because it is a design decision only apparent to the programmer who wrote the API. Eg

f(a, b, c) = :three
f(a) = :one
f(a, 1) # too few or too many?

This is of course further complicated by parametric types.

Also, f(a, b, args...)

1 Like

Yes, that’s it, thank you. Possibly I have also seen some useful discussion on the topic somewhere else, but not sure.

The discussion at GitHub - Stacktrace gripes is probably too technical for me, and I don’t have a GitHub account, so let me put my consideration here.

Yes, full stack trace convey a ton of potentially useful information. If you (@giordano , @Tamas_Papp ) probably spend most of your (work) time programming in Julia, if you don’t make any silly errors, and if you trained your eyes to discard unimportant lines even before they reach your brain so to say – then full stack trace could be perfect for you. Even than, I don’t think the information about the “Closest candidates” is what you need in most cases.

Now that’s we, who learn and would like to (maybe, only occasionally) use Julia. That’s me, who tend to make a lot of silly and obvious errors. Well, I am now sufficiently intelligent to scroll the stack trace and pinpoint the line number in my script which triggered the error and then often instantely know what happend. It is not THAT difficult, mostly it’s just boring and tiring and time consuming, and - let me cite @tim.holy , who has

… definitely seen folks be turned off by the complexity of our stacktraces

So I think the following could be done improve the user-frendliness for us without sacrifying the usefullness for you (at least some of these ideas were mentioned in some form in the cited GitHub discussion or somewhere else):

Set the verbosity level in a Julia variable, say 1 to 3. 3 would correspond to the current stack trace, 1 shows some minimal information. For function calls that would be the wrong number of arguments, if there are no methods with exactly that args number, otherwise something like no methods exist for foo({Int64}, {Bool})

Save the full error information in a (structured) Julia object, available from the REPL. If you are interested in the “Closest candidates” - type in >errorlog.last.closest and get it. Want to see the packages involved - - type >errorlog.last.packages

Yes, if you want to see in detail what happened before, call e.g. >errorlog[end-2].fullstack

As an option, write all that into a log file (could be useful for standalone Julia).

For the verbosity level of 1, show the only the stack traces through the “user” files. These could be defined as files in the directory of the main script, or let (the advanced) user define the folders and packages which they want to see in the short version of the stack trace.

Am I very naive?

1 Like

Agreed. A choice of verbosity level (or similar) would probably help beginners and veterans alike.

It is recognized that stack traces are quite complex and need to be improved (eg the issue you linked). This is work in progress.

However, the solution may not be as simple as you seem to imagine. With parametric multiple dispatch, selecting the “useful” part of the information can be difficult. This is what those discussions are about.

Also, I think that dividing the Julia community to “us” (casual users) and “them” (users you imagine to be experts) is not constructive here. As implemented now, stack traces contain both useful and less useful information for everyone. None of us relish scrolling through a lot of text, and we would all like to improve the signal/noise ratio. It is just not an easy problem.

3 Likes

Agreed. Nim has three choices of verbosity and I seem to remember the docs saying that the highest level is “only useful to developers”.

:100:

Agreed. I don’t think that the problem is technically infeasible, it is just hard. It is a good thing that Julians are greedy.

2 Likes

We could also work on making what we have easier to read. Simply making different kinds of information color coded would go a long way - you could look for blocks of color instead of actual characters. Especially helpful when you are scrolling through long messages.

Not sure how easy it is to do in practice but seems like low hanging fruit.

1 Like

I am sure PRs would be welcome.

There are two parts of long type strings:

  • Deeply nestred parametric types (with a lot of {} braces).
  • Long type names for each individual type (like QueryOperators.GroupColumnArrayView).

For some standard types like arrays or tuples there was a proposal to change their names to a shorter syntax in declarations:

Tamas, thank you for you reply.

Do I understand you correctly that you imply I should better abstain from further suggestions on this topic until I have better understanding of the Julia internals: just let the experts do the work and wait patiently for what comes?

No. Whatever gave you this idea?

If anything, you should consider contributing to the solution. This is primarily a user interface problem, which means that you don’t need to know about language internals to make improvements.

Even exploratory PRs that fix one minor thing can be a significant improvement. Eg color highlighting of matching {}s, or breaking lines in at meaningful chunks of type parameters, could be nice.

Is there a way to get the stacktrace as an object, I assume a vector of frames or something like that? That would be handy for prototyping solutions.

The error handling code is in base julia. Look eg at https://github.com/JuliaLang/julia/blob/master/base/stacktraces.jl, https://github.com/JuliaLang/julia/blob/master/base/errorshow.jl

3 Likes

also, there is some documentation at https://docs.julialang.org/en/v1/manual/stacktraces/

2 Likes

I just want to mention that in general it looks as if fixing this kind of issues is technically very hard, and that any attempt to fix them will be met with institutional inertia. My experience is that is the opposite: it’s just that the people who routinely commit to julia are the people who are least bothered by this kind of issues because they are used to it and tend to be pretty busy anyway, and so this kind of things just doesn’t happen. I’m not familiar with julia’s codebase, nor am I an expert hacker, but still I was able to submit https://github.com/JuliaLang/julia/pull/33087, which was very simple but still made my life better and got merged pretty quickly. Also a nice option for more disruptive changes is to make an external package (maybe that pirates base, eg by overloading Base.show_backtrace) to encourage people to try it out and polish it, and then merge it to base julia.

5 Likes

FWIW, Juno has been hiding types for inline evaluation for a fairly long time now and I haven’t heard any major complaints:

5 Likes