Frey, Peter wrote:

this statement is true, in theory, but sometimes one hits problems that cannot be solved without help of a debugger. There may be two circumstances where on NEEDs a debugger in the production environment

Hmmm, not convinced ;-)

a) when the problem is that urgent that there is no time to spend to set up and reproduce the problem in a test environment

You should ALWAYS have some kind of development or testing environment up, except in the tinyest of projects...

b) when the problem is not reproducable in test environemnt (as we had this month with a debug_mode problem on one of our production servers)

Okay, so long as you don't mind kissing performance goodbye. Maybe you enable profiler support and install PTProfiler on production too? ;-)

but still keep the option open to use the debugger directly on the production system (where it is installed then, when one of the two cases mentionned above come true) to get a fast solution of a problem

Okay, but don't just leave it installed ;-)

that is why our interest in the Zope Debugger product, as pdb is available on all systems but debugging script based code with it not that easy. and WingDbg/WingIDE is normally to heavy for a production server.

Well, try it, zdb is pretty lightweight code-wise, and it'd be interesting to see if you notice any memory or performance problems as a result, I'm just glad I'm not the one who's testing that ;-)

one more thought: we need to get experience with Zope Debugger BEFORE an emergency happens, so I tried it on a development system where WingDbg is installed (and used) and found that installing the Zope Debugger lets WingDbg fail, and had to remove it again. this was the start of this email chain

Yep, I know, still curious as to why that is... try putting some print statements in all the patched methods, and company with zdb installed and without... see what's no longer getting called and let me know ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk