Author Topic: Python debugger  (Read 8363 times)

Newbie_B

  • Junior Community Member
  • Posts: 3
  • Hero Points: 0
Python debugger
« on: April 10, 2009, 12:35:01 pm »
Hi Guys,
Thanks for very nice product.
It was very good new for me to see, that SlickEdit now supports Python debugger. But when I have downloaded trial build SlickEdit 14.0.0.7 I tried to debug some of my Python scripts to see how it works.When I created python project and added directory with my script I successfully execute some of them. It seems to be OK. But secondly I tried to debug same scripts using step execution and saw one very inconvenient thing  - debug session starts in DOS window and doesn't captured into build window of SlickEdit. Also I'm not sure about <Show value of symbol under mouse> working  in Python debugger window. Could you please explain me this features are not available in trial version or I made incorrect configuration my IDE ? Is there any more information about Python debugging in SlickEdit?
I use Python 2.4.2 for Windows, default installation in C:\Python24.
p.s. Sorry for my wrong English :-\

Rodney

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 710
  • Hero Points: 45
Re: Python debugger
« Reply #1 on: April 10, 2009, 04:56:44 pm »
Quote
...debug session starts in DOS window and doesn't captured into build window of SlickEdit.

Python output is not always flushed to stdout as the script runs. Therefore you might not see your output in the Build window as you stepped. That is the reason for the override to force a debugged script into an external shell. If you -- or anybody else that wants to comment -- would like to see this change, then please let me know your reasons.

Quote
...<Show value of symbol under mouse> working  in Python debugger window.

Yes, you are correct that this does not work in the latest release. It is a bug and will be fixed in the next patch (to be announced).

Thanks for the feedback.

--rodney

Newbie_B

  • Junior Community Member
  • Posts: 3
  • Hero Points: 0
Re: Python debugger
« Reply #2 on: April 10, 2009, 06:24:34 pm »
Quote
That is the reason for the override to force a debugged script into an external shell.

Sorry, but I dont'n understand what do you mean. How can I do it?
Another important feature I would lite to see in Slickedit debugger for Python language it is debug probe.Nowadays  Wing IDE have a lot of useful features for Python development, and it will be nice see those features in SlickEdit.


Thanks for your reply.

Rodney

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 710
  • Hero Points: 45
Re: Python debugger
« Reply #3 on: April 10, 2009, 09:09:48 pm »
Sorry I was not clear. There is no setting to cause a debugged script's output to go to the Build window right now. Even though a debug session uses the Execute tool's (Build>Execute) command line and passes that to the python debugger (pydbgp.py), the "Output to build window" option (Project>Project Properties, Tools tab) is overridden when starting a debug session.

If you want to hack in the change, then comment out the following line around line 613 of macros/pythonopts.e:

Code: [Select]
override_flags |= OVERRIDE_CAPTUREOUTPUTWITH_PROCESSBUFFER;
and reload the module (Macros>Load Module).

I would like to hear from you and other Python debugger users that feel strongly that output should go to the Build window (i.e. honor the setting for the Execute tool), while keeping in mind the limitation of the Build window that I pointed out -- non-flushed output will not print/display until the script finishes. I already know one reason: If your Python app is not a console app (e.g. PyQT graphical app, etc.), then bringing up a console might not be useful but remains harmless.

I will definitely have a look at the Wing IDE feature set. Thanks.

--rodney
« Last Edit: April 10, 2009, 09:17:34 pm by Rodney »

SteveW

  • Community Member
  • Posts: 11
  • Hero Points: 0
Re: Python debugger
« Reply #4 on: April 10, 2009, 11:25:27 pm »
I've been struggling with this a bit.  Your post cleared up what I was seeing, but I'm not real happy with the implementation.  I using Python 2.6.1 x64 on Vista64.  Just using a simple console app to figure things out.

So I start with the default Project tool settings.  Execute puts the output in the build window, and I can review what happened.  Cool.  Step into the script, and a cmd.exe box opens, Slicjedit goes into debugger mode, and as I step I can see the output in the cmd.exe window.  Not great, needs more real estate than I would like to have to dedicate to it, but bearable.  Okay, I hit go, the debugger exits, and the cmd.exe window goes away!  How do i see the script output after I hit go??  Very bad.

Then I figure from your post I can modify that by changing the Tools -> Execute settings, having already learend that the Debug tool output options were greyed out and could not be modified.  So now Execute puts the output in a text window in the editor.  Okay, I can live with that.  So I try to step into the script.  A cmd.exe window pops up and Slickedit stalls.  Nothing happens.  I close the cmd.exe window, and Slickedit then goes into debugger mode, pops up some message boxes about the command failing, and the debugger exits and I'm back in edit mode.  Oh, well.

If I uncheck Capture Output for Tools->Execute, the debugger works again, but I still can't review the script output after the debugger exits, and, of course, the execute output isn't captured.

So how do I configure this so that the script output is still available after the debugger exits??

Rodney

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 710
  • Hero Points: 45
Re: Python debugger
« Reply #5 on: April 11, 2009, 12:37:07 am »
When you have: Capture Output: ON; Output to Build window: OFF
it is equivalent to running your script and redirecting output to a file:
Code: [Select]
> foo.py > output.txt
In the rare case that a compiler/lint tool is not compatible with our Build window, it is a last resort to allow capturing error output. It is not a very useful set of options for Execute since it was intended to capture error output, and it is worse than useless for the Python debugger since it prevents the debugger from starting while it waits for output (without getting into details, it is a kind of i/o race condition, sort of). So the short answer is: don't do that  ;) The longer answer is that I will look into disabling the user's ability to choose that set of options in future.

Also, please re-read my previous post where I gave the user the option of hacking the pythonopts.e macro so Debug would not force an external console. The decision to force an external console was not arbitrary. As I said in my previous post, Python console script stdout output is generally not flushed. If you run a console script in the Build window, you might not see your output until the script finishes; that is why we forced the external console window. You might not like the implementation, but there is a good reason for it. It should be noted that even non-console apps (e.g. PyQT GUI apps) might still output to stdout/stderr, so seeing output as it comes is still important in that case.

I welcome your feedback.

--rodney

Newbie_B

  • Junior Community Member
  • Posts: 3
  • Hero Points: 0
Re: Python debugger
« Reply #6 on: April 11, 2009, 08:01:41 am »
Rodney, thanks again for your feedback.
Code: [Select]
override_flags |= OVERRIDE_CAPTUREOUTPUTWITH_PROCESSBUFFER;This hack partially solve problem with debugging scripts. And yes you are right it is useful only for console scripts. I'm not expert in development GUI application on Python (pyQT or wxWidgets) so I'm not familiar with debug such type of programs. I use python only for console scripts and often those scripts import other modules written by other people. So it will be very nice to have in SlickEdit feature like:

Code: [Select]
import Other_Module as Module
#some code

if __name__=='__main__':
    instance_of_Module = Module.Constructor(<parameters>)
    buffer = instance_of_Module.GetBuffer(length = 1024, isBytes = True, fillPattern = 0x00)
    buffer[0:8] = [1,2,3,4,5,6,7,8]
    # something else

I start debugging script and set breakpoit inside if __name__
then for example I would like to see all members of Module I imported. In wingIDE there is tool Debug Probe, I switch into this window and type something like:
Code: [Select]
dir(Module) or help(Module)and can see all members of Module in case dir() or some information about Module in case help() if it presets.
Then for example I stopped execution on line after creating buffer and filling it by values and now I would like to see buffer content and I again switch into Debug probe and type: print buffer and see it. Or I would like to change some bytes without modify my code, so I do:
Code: [Select]
buffer[0] = 0x99
buffer[3] = 0x66
and test how script will execute this.
Another feature it is for example I want to create buffer
Code: [Select]
buffer = instance_of_Module.GetBuffer(length = 1024, isBytes = True, fillPattern = 0x00)I start write GetBuffer member and in preview window I see highlighting by color name of parameter that I type (it is also present in Wing IDE).
I don't know if it easy or difficult to implement, but I would like to see this features in SlickEdit and it may cause a lot of python developpers migrate to SlickEdit.

p.s. I tried to do so clear explanation as I can, sorry for my English.

SteveW

  • Community Member
  • Posts: 11
  • Hero Points: 0
Re: Python debugger
« Reply #7 on: April 11, 2009, 11:01:53 am »
When you have: Capture Output: ON; Output to Build window: OFF
it is equivalent to running your script and redirecting output to a file:
Code: [Select]
> foo.py > output.txt
In the rare case that a compiler/lint tool is not compatible with our Build window, it is a last resort to allow capturing error output. It is not a very useful set of options for Execute since it was intended to capture error output, and it is worse than useless for the Python debugger since it prevents the debugger from starting while it waits for output (without getting into details, it is a kind of i/o race condition, sort of). So the short answer is: don't do that  ;) The longer answer is that I will look into disabling the user's ability to choose that set of options in future.

That's fine.  I was just working through the combinations to try to find a way to see the script output after the debugger exited.

Also, please re-read my previous post where I gave the user the option of hacking the pythonopts.e macro so Debug would not force an external console. The decision to force an external console was not arbitrary. As I said in my previous post, Python console script stdout output is generally not flushed. If you run a console script in the Build window, you might not see your output until the script finishes; that is why we forced the external console window. You might not like the implementation, but there is a good reason for it. It should be noted that even non-console apps (e.g. PyQT GUI apps) might still output to stdout/stderr, so seeing output as it comes is still important in that case.

I welcome your feedback.

--rodney

Yes it's important to see the output as it comes, and if an external console is the only way, so be it.  As long as you leave the console around after the debugger exits so that the script output can be reviewed.  Or tee the output to the console and a file, and open the file in the editor.  But some way to review the script output after it runs is critical.

Rodney

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 710
  • Hero Points: 45
Re: Python debugger
« Reply #8 on: April 11, 2009, 12:02:05 pm »
I did a little experimenting. Try this:

1. Apply the override flags hack as outlined previously.
2. Set your Execute tool to defaults (Project>Project Properties): Capture output: ON; Output to Build window: ON.
3. Set your python interpreter args (Build>Python Options, Run tab): -u
This gets you unbuffered output which, in my tests, works well to print output as it comes in the Build window. It even works for partial lines (i.e. we do not have to wait for whole lines before printing the output).

This seemed to work well for me. I am concerned about potential side-effects of '-u' which makes me wonder if it should be the default. If you or anybody else has any additional input about the '-u' option, then please post it here.

@Newbie_B:
The probe feature -- done properly -- will require a separate (tool) window in order for the user to interact with the debugger. I think this is doable, but will take some time to implement.

The ability to modify variable values in the debugger is definitely on my short list.

--rodney

SteveW

  • Community Member
  • Posts: 11
  • Hero Points: 0
Re: Python debugger
« Reply #9 on: April 11, 2009, 01:40:56 pm »
Works great!  Thanks!

If I do run in to anything weird with the -u, I'll post it.