# Units, errors and type display
**URL:** https://discourse.julialang.org/t/units-errors-and-type-display/11220
**Category:** General Usage
**Tags:** question
**Created:** [May 29, 2018, 7:10am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220 "2018-05-29T07:10:02Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 7:10am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/1 "2018-05-29T07:10:02Z")
So it finally happened, I ran out of terminal screen to scroll up through all the Unitful types and find what my error was.
Before I look into changing the memory buffer on my terminal, or log everything to file, can we actually fix this somehow?
How do we use units (or any other super complicated types) and have sensible error output without pages of frustrating scrolling?
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [May 29, 2018, 7:29am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/2 "2018-05-29T07:29:08Z")
> [@Raf](#):
>
> can we actually fix this somehow?
What do you propose? Limiting the output would miss some, which would affect the users looking precisely for those.
Look at [tmux](https://github.com/tmux/tmux/wiki), or run the REPL in an interface which supports more output (eg Emacs, Juno, …).
---
### Author:  [@stillyslalom](https://discourse.julialang.org/u/stillyslalom)
#### Post date: [May 29, 2018, 7:54am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/3 "2018-05-29T07:54:50Z")
Better type-printing tools are on the way in 0.7 via `showarg`: [julep: `Base.summary` and ShowItLikeYouBuildIt · Issue #18909 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/18909)
It doesn’t look like it’s been added to the online docs just yet, but it’s in the REPL help:
> `showarg(io::IO, x, toplevel)`
>
> Show `x` as if it were an argument to a function. This function is used by
> summary to display type information in terms of sequences of function calls
> on objects. toplevel is true if this is the direct call from summary and
> false for nested (recursive) calls.
>
> The fallback definition is to print `x` as `":::(typeof(x))"`, representing
> argument `x` in terms of its type. (The double-colon is omitted if
> `toplevel=true`.) However, you can specialize this function for specific types
> to customize printing.
>
> Example
> ≡≡≡≡≡≡≡≡≡
>
> A SubArray created as `view(a, :, 3, 2:5)`, where a is a 3-dimensional Float64
> array, has type
>
> `SubArray{Float64,2,Array{Float64,3},Tuple{Colon,Int64,UnitRange{Int64}},false}`
>
> The default show printing would display this full type. However, the summary
> for SubArrays actually prints as
>
> `2×4 view(::Array{Float64,3}, :, 3, 2:5) with eltype Float64`
>
> because of a definition similar to
>
> ```julia
> function Base.showarg(io::IO, v::SubArray, toplevel)
> print(io, "view(")
> showarg(io, parent(v), false)
> print(io, ", ", join(v.indices, ", "))
> print(io, ')')
> toplevel && print(io, " with eltype ", eltype(v))
> end
>
> ```
>
> Note that we’re calling showarg recursively for the parent array type,
> indicating that any recursed calls are not at the top level. Printing the
> parent as `::Array{Float64,3}` is the fallback (non-toplevel) behavior,
> because no specialized method for `Array` has been defined.
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 8:18am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/4 "2018-05-29T08:18:11Z")
I was semi serious, but really trying to make the point that if I have to look at using a different terminal it might not be the terminal that’s the problem. The scrolling will be painful wherever it happens.
I think being able to change the nesting depth of type output could help, if thats possible. I really only need to see the top two levels most of the time.
@stillyslalom showarg looks good - but is it actually called for error output? That’s the main pain point with Unitful.
---
### Author:  [@mauro3](https://discourse.julialang.org/u/mauro3)
#### Post date: [May 29, 2018, 8:27am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/5 "2018-05-29T08:27:29Z")
I have definitely seen error-messages (in fact using DifferentialEquartions + DynamicHMC) which were well beyond what I can parse, containing 100s of lines of parametrized types. So, whilst there should probably be an option to be able to see all of this, I’d think for normal day to day use, truncating show of parametrized types to say one level would be more helpful.
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [May 29, 2018, 8:29am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/6 "2018-05-29T08:29:38Z")
Perhaps show short form in interactive mode and save the error message so one could do something like `REPL.reshow_error()` which would print the last error verbosely?
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 8:38am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/7 "2018-05-29T08:38:50Z")
That seems perfect.
Short-form errors by default would save all the scrolling. What I mostly need to see is what the error was, and a traceback of the lines of code that lead to it. Currently these can be separated by pages of type signature.
For the 2% of the time all the types are needed `reshow_error()` is there. How easy it that to implement?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [May 29, 2018, 8:42am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/8 "2018-05-29T08:42:16Z")
Pretty easy. The previous backtrace is already stored for the Ctrl+Q keyboard shortcut to jump with the editor to stack frames. Would just need to store the exception as well. Also, would need some option to how types are shown.
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 8:49am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/9 "2018-05-29T08:49:43Z")
Should I open an issue somewhere for this?
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 9:02am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/10 "2018-05-29T09:02:25Z")
For the record my error clocks in at 1042 lines, 515505 Chars!! About 5000 lines in the terminal.
We could make some kind of competition out of this…
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [May 29, 2018, 9:07am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/11 "2018-05-29T09:07:23Z")
```julia
julia> f() = g(); g() = f(); f()
```
80 000 lines. Do I win?
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 9:10am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/12 "2018-05-29T09:10:54Z")
> [@kristoffer.carlsson](#):
>
> f() = g(); g() = f(); f()
Hmm. We might have to factor in information content into the ranking, maybe maxium Kolmogorov complexity per error message?
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 9:11am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/13 "2018-05-29T09:11:41Z")
Or length after gzip?
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [May 29, 2018, 12:12pm UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/14 "2018-05-29T12:12:49Z")
> [@mauro3](#):
>
> error-messages (in fact using DifferentialEquartions + DynamicHMC) which were well beyond what I can parse, containing 100s of lines of parametrized types
Good point. Type parameters can get very complex even with few levels of nesting.
---
### Author:  [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)
#### Post date: [May 29, 2018, 3:07pm UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/15 "2018-05-29T15:07:38Z")
Could you provide a bit more information about what the bad case is? Is there really a single type that’s 5000 lines long?
Truncating backtraces, and/or better detection of cycles would certainly be good.
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 29, 2018, 5:02pm UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/16 "2018-05-29T17:02:31Z")
There are probably a few lines of backtrace, but yes its hundreds of lines for one type. There’s a struct with maybe 200 params/vars. It’s a pretty complicated biophysical model with units on everything, maybe no-one has pushed units this far yet…
Heres a gist with the gory details, discourse can’t handle it all…
[https://gist.github.com/rafaqz/5e295aaaee7f2564b9121482e1b044ba](https://gist.github.com/rafaqz/5e295aaaee7f2564b9121482e1b044ba)
---
### Author:  [@jeff.bezanson](https://discourse.julialang.org/u/jeff.bezanson)
#### Post date: [May 29, 2018, 5:11pm UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/17 "2018-05-29T17:11:12Z")
Ok, I’m impressed. 🤩
---
### Author:  [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [May 29, 2018, 6:43pm UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/18 "2018-05-29T18:43:37Z")
> [@Raf](#):
>
> Heres a gist with the gory details, discourse can’t handle it all…
🍿.
> [@Raf](#):
>
> maybe no-one has pushed units this far yet…
I have seen some stuff with users where dimensions end up with big types, but I think you take the cake here. And it solves just fine and just doesn’t plot? The type system never ceases to amaze me…
But yes, there must be some easier way to parse this. I really like the Juno tree displays and would like to see them as part of the Base display system, but of course they wouldn’t be usable from the REPL (I think?)
---
### Author:  [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [May 29, 2018, 7:01pm UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/19 "2018-05-29T19:01:49Z")
I’ve handled this manually (because the `Strs` types can also get fairly gnarly), by adding `show` methods for them, so at least the specific concrete types that people are meant to use (`ASCIIStr`, `UTF8Str`, `UniStr`, etc.) don’t end up being more than one line.
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [May 30, 2018, 12:33am UTC](https://discourse.julialang.org/t/units-errors-and-type-display/11220/20 "2018-05-30T00:33:11Z")
Yeah solves just fine. It plots if I separate sol out manually, I just need to deal with the timestep handling in that DiffEq/UnitfulPlots recipe somehow.
We are talking about eventually porting some huge Fortran models to Julia in a similar way, so there are better/worse things to come. Unitful is essentially a free API for modularity, it’s going to be one of Julias biggest selling points in environmental modelling fields, along with numerical tools like DiffEq, and an actually nice language…
[Next page](https://discourse.julialang.org/t/units-errors-and-type-display/11220.md?page=2)