These stack traces are still out of control

General Usage
1

5 years ago, @Samuel_Ainsworth posted These stack traces are out of control - General Usage - Julia Programming Language, and it’s still very much the case in the SciML ecosystem.

{12BDC791-9F1B-4F06-84C4-EE8127828C3A}
{12BDC791-9F1B-4F06-84C4-EE8127828C3A}1077×476 30.1 KB

I find it hard to believe that all the SciML users just put up with that as a cost of doing business. Is there a secret trick to hide the type parameters in the REPL, or some such trick?

4 Likes
2

Which version of Julia are you using? I thought since 1.10 or so, stacktraces in the REPL are usually compacted by leaving out type parameters and one has to explicitly show them if wanted. At least it feels like it’s been a while since I’ve encountered such beasts.

3

1.11. The type parameters being grayed out does hint that maybe they could be filtered out, but I don’t know how.

2 Likes
4

Did you try GitHub - BioTurboNick/AbbreviatedStackTraces.jl ?

Please vote:

Do you want shorter stack traces in interactive mode?

  • YES
  • NO
0 voters

If we get enough votes, perhaps we can encourage the Julia developers to merge RFC: Abbreviated stack traces in REPL by BioTurboNick · Pull Request #40537 · JuliaLang/julia · GitHub .

5 Likes
5

That’s true! I get that too sometimes ::SciMLBase.LinearProblem{…}, but othertimes, for some reason, the REPL does not show such restraint.

1 Like
6

Because then it might just be a problem with the heuristic that determines when to shorten the stacktraces? :thinking:

I just tried to reproduce something like the above stacktrace, but got a reasonably shortened trace (still a lot of keywords, but that’s just the definition of the function…):

Stacktrace:
  [1] __init(prob::SciMLBase.ODEProblem{…}, alg::OrdinaryDiffEqSDIRK.TRBDF2{…}, timeseries_init::Nothing, ts_init::Nothing, ks_init::Tuple{}; saveat::Vector{…}, tstops::Tuple{}, d_discontinuities::Tuple{}, save_idxs::Nothing, save_everystep::Bool, save_on::Bool, save_start::Bool, save_end::Nothing, callback::Nothing, dense::Bool, calck::Bool, dt::Float64, dtmin::Float64, dtmax::Float64, force_dtmin::Bool, adaptive::Bool, gamma::Rational{…}, abstol::Float64, reltol::Float64, qmin::Rational{…}, qmax::Int64, qsteady_min::Int64, qsteady_max::Rational{…}, beta1::Nothing, beta2::Nothing, qoldinit::Rational{…}, controller::Nothing, fullnormalize::Bool, failfactor::Int64, maxiters::Int64, internalnorm::typeof(DiffEqBase.ODE_DEFAULT_NORM), internalopnorm::typeof(LinearAlgebra.opnorm), isoutofdomain::typeof(DiffEqBase.ODE_DEFAULT_ISOUTOFDOMAIN), unstable_check::typeof(DiffEqBase.ODE_DEFAULT_UNSTABLE_CHECK), verbose::Bool, timeseries_errors::Bool, dense_errors::Bool, advance_to_tstop::Bool, stop_at_next_tstop::Bool, initialize_save::Bool, progress::Bool, progress_steps::Int64, progress_name::String, progress_message::typeof(DiffEqBase.ODE_DEFAULT_PROG_MESSAGE), progress_id::Symbol, userdata::Nothing, allow_extrapolation::Bool, initialize_integrator::Bool, alias::SciMLBase.ODEAliasSpecifier, initializealg::OrdinaryDiffEqCore.DefaultInit, kwargs::@Kwargs{})
    @ OrdinaryDiffEqCore ~/.julia/packages/OrdinaryDiffEqCore/oFTse/src/solve.jl:333
  [2] __solve(::SciMLBase.ODEProblem{…}, ::OrdinaryDiffEqSDIRK.TRBDF2{…}, ::Nothing, ::Vararg{…}; kwargs::@Kwargs{…})
    @ OrdinaryDiffEqCore ~/.julia/packages/OrdinaryDiffEqCore/oFTse/src/solve.jl:6
...

Some type information was truncated. Use `show(err)` to see complete types.

After show(err) it looks a lot more like your initial example. Type parameters and keyword names are grayed out in my terminal both in the short and long version.

PS: I ran this on 1.10 though.