I've been trying to walk through some Python scripts with the debugger, but I'm having no luck. From what I can tell, Python can't access the poser module unless you're working from within Poser itself, and I can't see how to find and run a script when I invoke the Python shell inside Poser.

So what's the best practice for running the Python debugger with Poser?

Wished this worked for matmatic - it would make a huge difference. The Python error messages in the output window are generally fairly useless.

Quote - I've been trying to walk through some Python scripts with the debugger, but I'm having no luck. From what I can tell, Python can't access the poser module unless you're working from within Poser itself, and I can't see how to find and run a script when I invoke the Python shell inside Poser.

So what's the best practice for running the Python debugger with Poser?

Within the scripts-menu there is a python console. You can use it to run an interactive python shell. For running the debugger, you would use (as usual):

 >>> import pdb

 You can use the execfile function to debug a script, i.e.:

 >>> pdb.run ("execfile ('myscript.py')")

 assuming the script is in the current directory (otherwise use os.chdir())

I don't know what a python debugger is, but if you are having trouble accessing scripts, you can add more to the actual phython window in Poser.  I think the default is 10, but you can make sub menus that can hold a whole lot more.

I currently have 2 sub menus, with a 3rd about to start. Each sub menu has either a script, or the scriptor's name. In the case of a scriptor's name, that button is actually a sub button which holds scripts created by the scriptor.  For example, Ockham holds 3 buttons and each button has a number of scripts under it.

Dimension3D taught me how to do sub menus.  Here is the link if you are interested in that:

http://www.renderosity.com/mod/forumpro/showthread.php?message_id=2525895&ebot_calc_page#message_2525895

Quote - Within the scripts-menu there is a python console. You can use it to run an interactive python shell. For running the debugger, you would use (as usual):

 >>> import pdb

 You can use the execfile function to debug a script, i.e.:

 >>> pdb.run ("execfile ('myscript.py')")

 assuming the script is in the current directory (otherwise use os.chdir())

Great, I think that's going to do it, but I haven't had a chance to test it out much.

I also put this question to Ralf Sesseler at Diminsion 3D, and he said he just uses the "print" command for his debugger. Wow! That's the way I was debugging my COBOL code in the 1980s. Ralf does some of the best Python scripting for Poser that I know of, so I guess it works for him.

Acadia - Most programming environments these days have some sort of debugger built into them. A debugger lets the developer stop the code execution at a given point, shows the code, and lets the developer look at what some of the variables are set to, and all sorts of neat stuff. Then the programmer can step through the code line by line to see if it's behaving the way it is expected to.

Attached Link: http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=2829441

Son-of-a-gun! I didn't even know that forum existed. thanks.

So, nothing for us matmatic mavens, heh? Oh well... :blink:

millighost -

OK. I'm able to load the debugger and run a script from within Poser, but I can't get any breakpoints to be recognized. How is that done?

Robynsveil - Trust me, if I ever get this thing to work I'll put together some kind of tutorial.

data center

I do a print which sometimes works unless there is a problem with some other aspect not involving value changes. Being able to step through code like you would in the VBA IDE would be amazing. Thanks so much for that !!

Quote - millighost -

OK. I'm able to load the debugger and run a script from within Poser, but I can't get any breakpoints to be recognized. How is that done?

 

Robynsveil - Trust me, if I ever get this thing to work I'll put together some kind of tutorial.

data center

Quote - millighost -

OK. I'm able to load the debugger and run a script from within Poser, but I can't get any breakpoints to be recognized. How is that done?

 

Usually can set a breakpoint by giving it the line-number and file name like this:

 >>> pdb.run ("myscript.py")

 (pdb) break myscript:123

 (pdb) continue

 You have to know that this line gets executed, of course. This only works for files in your path (sys.path variable). Another method is to manually insert a breakpoint into the code by executing pdb.set_trace () from within your code. This all requires that your python program is within a file; debugging functions, you constructed with the python console does not work. There is also the old documentation on python on python.org, if you do not have it already (relevant for poser is python 2.4, which is not the newest version, and requires some clicks to get to).

I think (I think) I'm beginning to understand this Python-Poser thing and why something that should be so simple is so darn hard. Keep in mind that everything that follows is just my understanding up to this point. I'm hoping tha Millinghost and others will point out any errors.

First a little about Python. Python is open-source which means that anybody can potentially add to it. The native functionality of Python is quite limited which is why almost all Python scripts begin with a series of "import" statements. These imports load modules that contain code to handle, for example, operating system commands (import OS), variable typing (import types), string manipulation (import str), etc. In most cases there is no "official" module for anything, rather there are "de facto" standards. IDLE, for example, is often referred to as the de facto IDE (Interactive Development Environment) for Python, and IDLE is what is typically used to access the debugger for Python.

TkInter is the de facto standard module for visual UI elements such as drop-down lists, command buttons, pop-up windows, etc.; however, Poser chose to use a set of WX modules for this. This means that anything that relys on TkInter for its visual components is not going to work from within Poser. IDLE is based on TkInter.

So... You need to understand that when you are running Python scripts from within Poser, you are working a very different environment than when you are running Python as a standalone.

Finally, the Poser modules (apparently) are wrapped up inside the Poser.exe, so you can't just have an "import Poser" statement to bring those classes, methods, etc. into an ordinary Python script.

Given all that, it seems like we're going to be stuck with debugging via print statements just like I was doing back in the 80s.

Quote - TkInter is the de facto standard module ...

Actually it's an optional built-in.  

Quote - This means that anything that relys on TkInter for its visual components is not going to work from within Poser. IDLE is based on TkInter.

Not true.
TkInter has always worked fine for Windows version of Poser, but only with P7 did it work for MacOS versions.
The real problem with IDLE is related to threading and also the mechanics of the GUI main loop.  

Quote - Finally, the Poser modules (apparently) are wrapped up inside the Poser.exe, so you can't just have an "import Poser" statement to bring those classes, methods, etc. into an ordinary Python script.

As the interpreter is embedded, and the poser module is a native one, this means that it's going to be tricky to debug as it won't be possible to trace into methods.
Poser also has it's own event loop (which is now reasonably integrated with wxWidgets/wxPython in way that it never was with TkInter) that can present difficulties for debugging, especially where callbacks are triggered by GUI events.

Thanks for your input, nruddock, but I have to confess I hardly understood a word of it.

Quote - Actually it's an optional built-in.

Well, OK. I just don't know what that means. The python.org site appears to be down at the moment, but here is what the cached version says about TkInter:

Quote - "Tkinter is Python's de-facto standard GUI (Graphical User Interface) package. It is a thin object-oriented layer on top of Tcl/Tk.

Tkinter is not the only GuiProgramming toolkit for Python. It is however the most commonly used one"

I don't know if that contradicts what you said or not.

Quote - Not true.
TkInter has always worked fine for Windows version of Poser, but only with P7 did it work for MacOS versions.
The real problem with IDLE is related to threading and also the mechanics of the GUI main loop.

Again, I wish I knew what this meant - the last sentence anyway. Perhaps you can say what the significance of that is vis-a-vis Poser.

Quote - As the interpreter is embedded, and the poser module is a native one, this means that it's going to be tricky to debug as it won't be possible to trace into methods.
Poser also has it's own event loop (which is now reasonably integrated with wxWidgets/wxPython in way that it never was with TkInter) that can present difficulties for debugging, especially where callbacks are triggered by GUI events.

Well, at least I understood the part about "it's going to be tricky to debug."

Quote - Son-of-a-gun! I didn't even know that forum existed. thanks.

Yeah and it's been there for quite some time. You'll find a lot of your python questions can be answered there.

Quote - ... Given all that, it seems like we're going to be stuck with debugging via print statements just like I was doing back in the 80s.

Thank you for investigating all that for us, ElZagna. That truly is too bad... sprinkling print statements into your code doesn't hardly help at all: the output window fails to indicate whether a statement executed or not, or if not, why not. When I ran into snags in VBA, I'd step through stuff with watches on given valiables and generally be able to see where I introduced a bug or whatever.

With this environment, you pretty much have to be a PhilC or a Bagginsbill and write clean, error-free coded from the get-go. Forget about trying to sort out any mess you might have made: can't tell you how many times I've ended up with truncated mc6s because matmatic choked on some particularly bad segment of my code and output gave me a page of tracebacks which told me absolutely nothing about the problem.

At least with straight procedures (functions only), i could sort-of get to the bottom of things, but recently I've been trying to work with classes, and debugging is hopeless. :blink:

Quote - Yeah and it's been there for quite some time. You'll find a lot of your python questions can be answered there.

Hmmm.... I only see six threads, and all but one are fairly recent.

Quote - Hmmm.... I only see six threads, and all but one are fairly recent.

You'll need to look in the archives for anything older than 45 days (there's over 10 years worth of posts).

On Tkinter vs wxWidgets/wxPython:

Tkinter comes out of Tcl/Tk and was adapted to run with Python - it isn't more or less "native" to Python than any other GUI toolkit. Tkinter is great for quick development of GUIs for standalone Python scripts, but it has number of issues when it gets integrated in an embedded Python interpreter as the one in Poser.

Tkinter requires that you run its event loop, which will block the host application's event loop until the Tkinter event loop quit, therefore making Tkinter scripts modal. There are hacks that use ProcessSomeEvents() to produce what appears like a non-modal Tkinter dialog, but those are dangerous and can have all kinds of side effects (because what happens inside ProcessSomeEvent() can be anything - including closing the current scene or deleting objects that the script is in the middle of processing). 

Tkinter also acts as if it were alone, which means that it installs its own keyboard shortcuts, menu bar, etc and doesn't attempt to restore then after exit. On Mac OS X, the port to Cocoa took a while and the version that Apple distributes does not have a good reputation.

wxPython is prepared for embedding, and since Poser itself uses wxWidgets it allows for a very smooth integration. Dialogs can run modal or non-modal, scripts have full access to menu bars, windows, etc can create their own docked palettes and respond to events without having to create their own event loop. GUI elements created by wxPython are essentially equal to GUI elements created by Poser itself, which gives script developers more power (and with it, responsibility) than Tkinter ever could.

Can on infer that a Python debugger could be developed in wxPython?

Quote - Can on infer that a Python debugger could be developed in wxPython?

A wxPython GUI would certainly be possible, but for running it in Poser, there are still potential problems due to the native module and the embedded interpreter. What might work better is using boa-constructor (-> http://sourceforge.net/projects/boa-constructor) in remote debug mode (assuming that you don't run into the same problems).