Passive tracing of function objects (was: Efficient debug logging)

On Tue, Feb 14, 2017 at 3:55 PM, Barry <barry@barrys-emacs.org> wrote:
Awhile back I was playing with some code for the purpose of adding debug logs "after the fact": https://github.com/anthonyrisinger/retrospect/blob/master/README.rst I'm not trying to plug it (It's POC, broken, and Python 2) but maybe there is some value because I was trying to solve a similar problem of fast and easy debugging and logs. The idea here is we target a function for "retrospection" by replacing it's code object with a modified variant that implements call outs at different points. Such interesting points might be "on symbol table changes" (new vars) or "on identifier rebinding" (updating vars) or "on line changes" or even "every single tick" to inspect TOS. I like this approach of latching onto the function/code object directly because it does not require a wrapper, but it can have be tricky with decorators depending on what the decorator does with the function it receives (we need access to the function object to replace it's __code__). I don't much like writing logs. They are verbose in code and almost always either much more or less than I need to deal with the problem at hand, and it's not always clear what's important ahead-of-time. With all the implementation details in play, you might end up wrapping code in context managers and whatnot for the sole purpose of logging. Or you have to jump thru hoops to get the exact info you need using many log levels or flags. I think having a way to target functions for real time introspection, then perfectly disable it, could allow for interesting solution to large, cross-cutting concerns like application logging. Is there any interest in this? Say a new function method like fun.trace(vars=[a,b,c])? Is there already a solution or past discussion on this topic? Thanks, -- C Anthony

On Wed, Feb 15, 2017 at 10:45 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
I meant to note that I did in fact use this (plus a wrapper that would take an ENV var with the function to target) a few times to inspect code running deep in Django without ever editing any Django code. It also works for inspecting code you can't edit, say modules installed globally into /usr. -- C Anthony

On Wed, Feb 15, 2017 at 10:45 AM, C Anthony Risinger <anthony@xtfx.me> wrote:
I meant to note that I did in fact use this (plus a wrapper that would take an ENV var with the function to target) a few times to inspect code running deep in Django without ever editing any Django code. It also works for inspecting code you can't edit, say modules installed globally into /usr. -- C Anthony
participants (1)
-
C Anthony Risinger