You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was thinking recently that it would be nice if, every time I hit an error, I could 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:
Create a InfiltratorCtx Cassette context.
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).
For each function call in the user's code, wrap the whole function body in
try# body ...catch e
@infiltrateend
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.
The text was updated successfully, but these errors were encountered:
My thinking evolved on this while I was working on a PoC. I think every individual statement should be wrapped in try ... catch e @infiltrate end so that you can "pause on exception" exactly at the line that failed with all the variables defined.
I also realized that this could be achieved with theinclude method that takes a function for manipulating the AST.
That would be less flexible than Cassette, but far less finicky since we could intervene before IR.
I'd be happy to see an external package do this (the AST transform injecting a bunch of @infiltrates).
Something we could add to Infiltrator itself is the ability to recompile a method a recently thrown stacktrace with an @infiltrate before the error happens. Imho that seems like the right balance between ease-of-use and cost, so I'll play around with that a bit.
I was thinking recently that it would be nice if, every time I hit an error, I could 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:
InfiltratorCtx
Cassette context.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).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.The text was updated successfully, but these errors were encountered: