# These stack traces are still out of control
**URL:** https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447
**Category:** General Usage
**Created:** [October 27, 2025, 5:32am UTC](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447 "2025-10-27T05:32:22Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@cstjean](https://discourse.julialang.org/u/cstjean)
#### Post date: [October 27, 2025, 5:32am UTC](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447/1 "2025-10-27T05:32:22Z")
5 years ago, @Samuel_Ainsworth posted [These stack traces are out of control - General Usage - Julia Programming Language](https://discourse.julialang.org/t/these-stack-traces-are-out-of-control/47162), and it’s still very much the case in the SciML ecosystem.
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?
---
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [October 27, 2025, 9:41am UTC](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447/2 "2025-10-27T09:41:46Z")
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.
---
### Author:  [@cstjean](https://discourse.julialang.org/u/cstjean)
#### Post date: [October 28, 2025, 12:25am UTC](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447/3 "2025-10-28T00:25:46Z")
1.11. The type parameters being grayed out does hint that maybe they could be filtered out, but I don’t know how.
---
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [October 28, 2025, 12:51am UTC](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447/4 "2025-10-28T00:51:13Z")
Did you try [GitHub - BioTurboNick/AbbreviatedStackTraces.jl](https://github.com/BioTurboNick/AbbreviatedStackTraces.jl) ?
Please vote:
**Do you want shorter stack traces in interactive mode?**
_Poll ([view on site](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447/4))_
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](https://github.com/JuliaLang/julia/pull/40537) .
---
### Author:  [@cstjean](https://discourse.julialang.org/u/cstjean)
#### Post date: [October 28, 2025, 4:09am UTC](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447/5 "2025-10-28T04:09:22Z")
> [@Sevi](#):
>
> 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.
That’s true! I get that too sometimes `::SciMLBase.LinearProblem{…}`, but othertimes, for some reason, the REPL does not show such restraint.
---
### Author:  [@Sevi](https://discourse.julialang.org/u/Sevi)
#### Post date: [October 28, 2025, 7:28am UTC](https://discourse.julialang.org/t/these-stack-traces-are-still-out-of-control/133447/6 "2025-10-28T07:28:19Z")
Because then it might just be a problem with the heuristic that determines when to shorten the stacktraces? 🤔
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…):
```julia
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.