DiffEqOperators.jl VS Infiltrator.jl

>I hope those benchmarks are coming in hot

M1 is extremely good for PDEs because of its large cache lines.

https://github.com/SciML/DiffEqOperators.jl/issues/407#issue...

The JuliaSIMD tools which are internally used for BLAS instead of OpenBLAS and MKL (because they tend to outperform standard BLAS's for the operations we use https://github.com/YingboMa/RecursiveFactorization.jl/pull/2...) also generate good code for M1, so that was giving us some powerful use cases right off the bat even before the heroics allowed C/Fortran compilers to fully work on M1.

(b) DiffEqOperators.jl is being worked on https://github.com/SciML/DiffEqOperators.jl/pull/467 .

I like that they are colored now, but really what needs to be added is type parameter collapasing. In most cases, you want to see `::Dual{...}`, i.e. "it's a dual number", not `::Dual{typeof(ODESolution{sfjeoisjfsfsjslikj},sfsef,sefs}` (these can literally get to 3000 characters long). As an example of this, see the stacktraces in something like https://github.com/SciML/DiffEqOperators.jl/issues/419 . The thing is that it gives back more type information than the strictest dispatch: no function is dispatching off of that first 3000 character type parameter, so you know that printing that chunk of information is actually not informative to any method decisions. Automated type abbreviations could take that heuristic and chop out a lot of the cruft.

Also Infiltrator is very fast and useful but don't try to use it from the Vscode integrated terminal.

The package Infiltrator.jl might be what you seek. It's not as good as inserting breakpoints like in Matlab but it's still better than printing everywhere haha

Yes, it uses Debugger.jl, which relies on JuliaInterpreter.jl under the hood, so while you can tell the debugger to compile functions in certain modules, it will mostly interpret your code.

You might be interested in https://github.com/JuliaDebug/Infiltrator.jl, which uses an approach more similar to what you describe.

Another small thing is in the REPL when you trigger an error in Common lisp it drops you into the debugger where you can redefine code and retry directly from the stack without unwinding the entire stack. Does Julia have functionality similar to this? Currently when I trigger an error Julia just throw the error and goes right back to the top level prompt. To resolve this issue I've tried sprinkling my code with a combination of GitHub - JuliaDebug/Infiltrator.jl + Stack Traces · The Julia Language wrapped in try catch blocks so that if an error is singled it drops into a debugger of sorts. This is ok and it works but it isn't really as good. Is there a current package that can emulate what I am trying to do? I think that the REPL workflow is good in julia but the workflow stalls out when you run into errors that don't drop into debuggers and such.

Have you ever tried Infiltrator.jl and Chain.jl?