On 2/16/06, Bill Baxter <[EMAIL PROTECTED]> wrote:
Hi Bill,
Should not be so hard...
The problem is that I have to pass the complete thing to the debugger because it will do an exec in your code, so, if you want to define something as:
def method1():
print 'foo'
You could not do, because the exec would pass right on the 'def method1():', and you need it only after you defined the whole method... That's so that you can do things like the below in the debugger:
class D:
def m1(self):
print 'here'
d = D()
print d
<__main__.D instance at 0x0A6D0E90>
I could still make an option to respond after a single-line, but then you'd not be able to do multi-line statements...
Anyway, I could do some more research to see if there's someway that can make multi-line statements and keep the simplicity of single line statements... Something as a buffer, that determines when it should evaluate the whole thing... maybe as the real console, that detects when it is a multiline and only then passes to the 'eval on new line' approach.
Probably doable
I'll need to check if I can override the default Eclipse console used for run... Probably hard though (I had to hack my way into Eclipse just to be able to grab the input)...
Same as the one before
Well, I'll soon have a replacement for pycrust, to help you do 'quick-scripts' in a scrap-page... something as the java scrap-page, but I'll have to see how to connect it to the debugger shell.
Well, I hope I'll get to there ;-)
Agreed... but I'd probably do the stand-alone test-cases anyway ;-)
Hi there,
Hi Bill,
On 2/17/06, Fabio Zadrozny <[EMAIL PROTECTED]> wrote:This is a pretty great addition. How hard would it be to make it act more like a full-featured shell? I.e.,
- New feature in the debugger: the console is available for probing when
in 'suspendend mode'
- have a promt so you can tell tell that it's waiting for your input,
Should not be so hard...
- respond after just one 'enter' instead of two,
The problem is that I have to pass the complete thing to the debugger because it will do an exec in your code, so, if you want to define something as:
def method1():
print 'foo'
You could not do, because the exec would pass right on the 'def method1():', and you need it only after you defined the whole method... That's so that you can do things like the below in the debugger:
class D:
def m1(self):
print 'here'
d = D()
print d
<__main__.D instance at 0x0A6D0E90>
I could still make an option to respond after a single-line, but then you'd not be able to do multi-line statements...
Anyway, I could do some more research to see if there's someway that can make multi-line statements and keep the simplicity of single line statements... Something as a buffer, that determines when it should evaluate the whole thing... maybe as the real console, that detects when it is a multiline and only then passes to the 'eval on new line' approach.
- print out the value of variables by just typing the variable name (instead of having to type "print variable_name")
Probably doable
- cycle through your command history with keys like up/down-arrow or ctrl-up/down-arrow
I'll need to check if I can override the default Eclipse console used for run... Probably hard though (I had to hack my way into Eclipse just to be able to grab the input)...
- auto-completion of symbols
Same as the one before
Ideally it would be nice to just have something like pycrust right there in a tab instead of "Console". Stani's Python Editor has pycrust built-in like that, but unfortunately it's not connected in any way to your executing program, so it's not so useful.
Well, I'll soon have a replacement for pycrust, to help you do 'quick-scripts' in a scrap-page... something as the java scrap-page, but I'll have to see how to connect it to the debugger shell.
The ultimate debugger, based on debuggers I'm familiar with, would be a hybrid of that in VisualStudio crossed with Matlab. VisualStudio does variable and watches nicely. It's got a list (several lists actually) like Eclipse's 'Expressions', but you can double click to add a new _expression_ or edit an _expression_. Eclipse is pretty close there, just needs a more efficient way to edit the expressions. The Matlab debugger, on the other hand, completely lacks an _expression_ list, but its best feature is that when you hit a breakpoint, you just have your normal interactive shell prompt there with all it's features, plus all your program's state loaded in memory.
Well, I hope I'll get to there ;-)
This is an excellent debugging model for a dynamic programming language in my opinion. If there's some error on the current line, you can quickly try out a bunch of variations to figure out what the proper _expression_ is to get the result you want, using the actual data from your program, without having to cook up a stand-alone test case that creates data similar to what's in your program.
Agreed... but I'd probably do the stand-alone test-cases anyway ;-)
Regards,
Bill Baxter
Regards,
Fabio Zadrozny
