4 ms·
So go ahead and set up that working situation and try this: Define a function foo() in one module that calls a function bar() in another one, but don't define
by mikelevins 6y ago
So go ahead and set up that working situation and try this:
Define a function foo() in one module that calls a function bar() in another one, but don't define bar().
Now call foo().
Now, in the debugger that you break into, give a definition for bar(), and resume the execution of foo(). Don't quit the program and restart it; that's cheating!
If that works fine, please tell me what tools you're using, because they'll materially improve my tools for some work I need to do.
Also, try this:
Define some classes and make a bunch of instances of them. Write a few methods on the classes. Start your program running with code that uses those classes and methods.
Now change one or more of the class definitions. Don't stop and reload the program! Again, that's cheating.
When you land in the debugger (you do land in an interactive debugger, right?) use it to inspect the stack and find out which classes and methods are on the stack and what's responsible for the breakage. Ask the Python runtime to show you all the functions, types, and values that are on the stack, and when you find the likely culprit, ask it to take you to the source for the version that's currently on the stack.
Now, while you're still suspended in the call stack, redefine the offending classes and methods and tell Python to use the new ones. Now resume the broken computation. If you hit another problem, use the same tools to find and fix that one, too.
After you've done all that, please let me know what your Python toolchain is so that I can use it, too.
Also, if that's all perfectly doable in Matlab and R, that's good to know. Let me know about those tools, too. I haven't had much occasion to use them, but that might have to change if they work that way, too.
- tylermw 6y agoI don’t know about MATLAB, but everything you describe is trivial to do in R. Being dropped into the debugger is standard on most R installs (it’s an option you can turn off) and everything you mentioned can be done in the REPL.
- mikelevins 6y agoThat's good to know; thanks!
- mikelevins 6y agoSo I tried this with R: 1. Define an S4 class. 2. Create an instance of the S4 class (let's call it A). 3. Redefine the S4 class. 4. Examine A. R complains that there's an error in slot(object, what), because A is missing a slot from the (re)definition of the S4 class. This is promising, in that R realizes that A is supposed to be an instance of the redefined class. So far, so good. What I would expect to see next is that either R automatically reinitializes A with the new slot (it has exactly as much information about the new slot as it had about the old ones when I created A), or, if it wants intervention from me, it presents an interactive session I can use to tell it how to initialize the new slots. It didn't do that, but maybe I just don't have the options configured properly to make it happen. Smalltalk and Common Lisp meet my expectations: they notice that A is an instance of a redefined class and they either reinitialize the instance automatically, or they present an interactive session that I can use to tell them how to do it. It's entirely possible that R has this feature and I'm just missing it because I'm a noob.