# Infiltrator based debugger

**URL:** <https://discourse.julialang.org/t/infiltrator-based-debugger/103817>\
**Category:** VS Code\
**Tags:** debug\
**Created:** [September 13, 2023, 3:09pm UTC](https://discourse.julialang.org/t/infiltrator-based-debugger/103817 "2023-09-13T15:09:22Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![mariusd](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mariusd/32/23231_2.png) [@mariusd](https://discourse.julialang.org/u/mariusd)\
**Post date:** [September 13, 2023, 3:09pm UTC](https://discourse.julialang.org/t/infiltrator-based-debugger/103817/1 "2023-09-13T15:09:22Z")

</div>

See the following code, I have added `@infiltrate` after every statement in the function such that I can debug everything. But then I was thinking this might be an excellent UI debugger alternative: having @infiltrate happening automatically and inspecting the variables in the UI as we usually do.  
What would be the advantages and downsides of this approach compared to the current interpreter based debugger?

 ![image](https://global.discourse-cdn.com/julialang/original/3X/b/6/b63d99b0a9197e6a2a48020a3aece4df24856aa9.png)

---

<div class="post-metadata">

**Author:** ![mrufsvold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mrufsvold/32/31600_2.png) [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)\
**Post date:** [September 13, 2023, 11:04pm UTC](https://discourse.julialang.org/t/infiltrator-based-debugger/103817/2 "2023-09-13T23:04:46Z")

</div>

I opened a PR with a similar idea on the Infiltrator repo

> <https://github.com/JuliaDebug/Infiltrator.jl/issues/99>
>
> I was thinking recently that it would be nice if, every time I hit an error, I c…ould drop into the REPL and figure out what was going on. I think this could be done using Cassette.jl and Infiltrator.jl. 
> 
> My design idea is:
> 
> 1) Create a \`InfiltratorCtx\` Cassette context. 
> 2) Mark \`Base\` and all modules from dependencies of the active environment as not overdubbable (kinda like marking most modules with "Compiled Mode" in the regular debugger).
> 3) For each function call in the user's code, wrap the whole function body in 
> \`\`\`julia
> try
> # body ...
> catch e
> @infiltrate
> end
> \`\`\`
> 
> All of this functionality could be wrapped in a package extension so that it doesn't change the light-weightness of Infiltrator.jl unless the user imports Cassette (or maybe some kind of wrapper package so that regular users don't need to directly install Cassette). 
> 
> One obvious tradeoff is that, when this mode is turned on and off, all of the user's functions would need to be recompiled. That's not aaaawesome, but it's the same tradeoff as adding \`@infiltrate\` manually, so I don't see it as a major problem as long as the user is made aware of the cost.
> 
> Would this be something you'd be open to a PR for? Or do you think functionality like this is best left to a completely separate package?
> 
> P.S. I want to keep the discussion focused on this narrower goal, but if we are already working with Cassette, we could also add an option to capture deep copies of the arguments of each function as we descend the stack and allow the user to "rewind" to frames further up the stack. This wouldn't allow \`@continue\` in these other frames, but it would add more "debugger" type features to the toolkit.

My idea was to wrap every line in a `try... catch e @infiltrate end`

I think this could be done with a special `include(insert_infiltrate, file)` method that does it automatically for the included file.

---

<div class="post-metadata">

**Author:** ![mariusd](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mariusd/32/23231_2.png) [@mariusd](https://discourse.julialang.org/u/mariusd)\
**Post date:** [September 15, 2023, 9:21am UTC](https://discourse.julialang.org/t/infiltrator-based-debugger/103817/3 "2023-09-15T09:21:12Z")

</div>

I noticed @pfitzseb actually considered this long time ago: [Hooks for Juno/VSCode integration · Issue #2 · JuliaDebug/Infiltrator.jl · GitHub](https://github.com/JuliaDebug/Infiltrator.jl/issues/2).  
I also noticed there is a functional form here: [https://github.com/JuliaDebug/Infiltrator.jl/blob/master/src/Infiltrator.jl#L86](https://github.com/JuliaDebug/Infiltrator.jl/blob/master/src/Infiltrator.jl#L86).  
`function infiltrate(mod, locals, file, line)` I guess I can generate `infiltrators` all over the place without touching my code - I’m going to try this 🙂.

@pfitzseb I’m wondering if there are issues with this style of debugging? Or is actually pretty good and it’s more about not having enough time left to add it in the UI?