Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
sdeibel wrote: Sorry to hear that, maybe you could recommend zdb to people in the meantime ;-) That won't help people debugging wxPython, of course... ;-) Silly people, they should be developing for a browser instead <0.5 wink> I should have said "in CMF" -- with the addition of FSObject it looked like things were heading towards a cleaner state of affairs. This is just a general impression based on looking at successive versions of this code a few times a year, so I could be misunderstanding the motivation for the changes. Hmmm, yeah, but FS-based objects aren't the only things people need to debug... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
On Sat, 25 Mar 2006, Chris Withers wrote: sdeibel wrote: I don't think the linecache hack is going to work for Wing because the file is read by the IDE and not within the same process space as Zope is running. While we might eventually make it possible to transfer code over the debug connection for cases like this, it would slow our debugger to a crawl in many debug scenarios so it's not designed that way now. Sorry to hear that, maybe you could recommend zdb to people in the meantime ;-) That won't help people debugging wxPython, of course... ;-) I see there seems to be some evolution in Zope that fits with perhaps some day compiling the right file name into code objects, Not at all clear what you mean, perhaps you could clarify? I should have said "in CMF" -- with the addition of FSObject it looked like things were heading towards a cleaner state of affairs. This is just a general impression based on looking at successive versions of this code a few times a year, so I could be misunderstanding the motivation for the changes. Incidentally my earlier email to zope@zope.org was rejected but I just joined so this one might make it... - Stephan ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
sdeibel wrote: I don't think the linecache hack is going to work for Wing because the file is read by the IDE and not within the same process space as Zope is running. While we might eventually make it possible to transfer code over the debug connection for cases like this, it would slow our debugger to a crawl in many debug scenarios so it's not designed that way now. Sorry to hear that, maybe you could recommend zdb to people in the meantime ;-) The particular approach to patching _compiler may be useful, tho, in a general sense to make our patch at least a bit simpler. Simpler is good... I see there seems to be some evolution in Zope that fits with perhaps some day compiling the right file name into code objects, Not at all clear what you mean, perhaps you could clarify? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
Stephan Deibel wrote: You can turn on and off debugging from the WingDBG control panel which installs/removes the tracer hook and also the monkey patches. When off, it's the same as if no debugger were running (except that WingDBG lets you turn it on again dynamically). Is the WingDBG control panel in Zope or in WingIDE? Where's the code which does this "turning off and turning on"? Also, someone mentioned changing the monkey patch to call inherited. Not sure what you mean by that... I meant trying to call the inherited/replaced method to do the work or more of the work rather than completely replacing it. This *might* make things less brittle (but I doubt it, actually ;-). Well, it's more than you may want to call the method you're replacing when you're monkey patched method is done doing what it's doing. zdb does this with prettymuch all its monkeypatches... The old/existing impl adds a ##'ed comment block to scripts and ends up stripping the block before compiling the script so that line numbers in the code object don't match up with the copy of the script that has the ##'s (which is what anyone reading from the file system will see). The patch changes this to compile the script w/ the ##'ed comment in place. Yes, but this stuff isn't necessary ;-) (and has nothing to do with the code that patches co_filename, right?) Re: patching Zope + CMF: It should be possible to patch CMF so that it can run w/ either patched or unpatched Zope. The author of CMFFormController accepted our patch when it was originally submitted and did that. Odd. You earlier suggested you wanted to get "Zope" changed to co_filename was meaningful. That change also needs to be made in FSPythonScript. That one small change is the only thing I'm talking about ;-) Hmm, so perhaps reworking the patch for CMF to work like that might help get it accepted... then the question is whether the Zope patch can be made to work w/ unpatched CMF (if that is an issue; or is it OK for Zope to change under CMF?). The two should have nothing to do with each other... As far as a standard for co_filename it should be the full path file name for FS scripts (O/W most debuggers won't work out of the box), Well, you see, that doesn't work for me ;-) (Since I tried both FSPythonScripts and PythonScripts in the same way, and that uses their full ZODB path) We'll try to do actual work on this (rather than sending emailed drivel ;-) after Wing 2.0.4 is out. Unfortunately, we've got various things going on that has left us w/ very little extra time for the next month or so. You might start by actually getting to know how zdb works, there's very little code in it and it tackles the problem in a different way which avoids all the trouble you're getting into above... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
Wingware Support wrote: Just a couple notes on this: We monkey patch only while the debugger is active Does this mean "When WingDbg is installed" or is there more to it than that? Also, someone mentioned changing the monkey patch to call inherited. Not sure what you mean by that... However, what would make the most sense (to me) is to get the co_filename setting part of the patch into Zope as a real change to the code (this adds no overhead, and it's entirely reasonable to set file name or url of some type here when available) and leave any other stuff like line cache stuffing to zdb or other debugger. I guess I agree, but we need to come up with a standard for it then ;-) Anybody understand what the sticking point with that is? Is it the change from removing/adding ##'ed header so it's not stripped before making the code object (so line numbers match source)? Don't see what any commented block stuff has to do with it, what would that have to do with co_filename? I don't see any real sticking point other than that both CMF and Zope need the changes... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
Wingware Support wrote: Because Wing currently doesn't read files from anywhere but the file system. I have looked briefly at zdb, but have not had time to set it up yet. Man, you are short of time ;-) Wing's debugger does not use pdb or even the linecache module, so zdb's technique of pre-filling the line cache isn't applicable. That's a shame, you should be able to use something similar though... Since you also have a need for the co_filename attribute to be set, I suggest we try to come up with a monkey patch that we can both use and not conflict with each other. Yep :-) I don't have Wing, so I can't try WingDbg, but if you could stick zdb and WingDbg in the same Zope instance and see what zdb is stomping on that's stopping WingDbg working, then I'll see what I can do.. I still think even better would be to get a change into Zope so monkey patches aren't required. Well, zdb adds overhead, so I'd never want its stuff to be intergated... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: AW: [Zope] Zope Debugger lets WingDbg fail to connect toclient
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 ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
Hi John, Wingware Support wrote: Right now, Wing only supports file system based code. Really? Why? For code in the database, I'd think you would want to set co_filename to some sort of url. You could always look at the product I mailed you about, it's not exactly big ;-) Somehow the debugger needs to find the source text that produced a code object, and using co_filename is the standard way of doing this. Yep, that's what zdb does.. By unpluggable do you mean it assumes code is on the file system? Yeah, and it certainly was a fair assumption, but what with now having code coming form .zip's in plain python and zodb in Zope, it reallt could do with a good kicking... Yes, you don't want the debugger on a production system. Simply setting the co_filename attribute won't slow the system down, though. Yup, but zdb pre-stuff the linecache so the normal pdb mechanisms can find the code, and that _is_ expensive ;-) Not to mention oh so many monkey patches calls which both zbd and WingDbg suffer from ;-) cheers, Chris - who would be interested to know if you actually downloaded zdb and had a look at its source... -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
Hi John, Wingware Support wrote: sorry, here it is. It is the the WingDbg Product, but you probably will be unable to install/use it as it depends on the WingIDE (at least part of it) to be installed on the server, too. And as WingIDE is not open source, I am not allowed to hand it on. The patching is a bit worse than I expected, it doesn't look like WinDbg makes any attempt to call back to the original version of the method it's patching, which is a bit sad :-( The patching WingDBG does is required so that the co_filename attribute of code objects is set correctly. That's no good if they're not FS-based ;-) We would be interested in hearing if there is a better way to do this. http://www.simplistix.co.uk/software/zope/zdb We'd be even more interested in having Zope changed so that any debugger would work without monkey patching ;). Well, with code stored in an ODB and pdb's fundamentally FS-based and suprisingly unpluggable attitude, I don't think that's likely... Also, bear in mind the oeverhead for getting the debugger stuff working, I really wouldn't want to use it in production! cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Zope Debugger lets WingDbg fail to connect toclient
Hi Peter, Frey, Peter wrote: sorry, here it is. It is the the WingDbg Product, but you probably will be unable to install/use it as it depends on the WingIDE (at least part of it) to be installed on the server, too. And as WingIDE is not open source, I am not allowed to hand it on. Yeah, I don't need it to run, just wanted to take a look. The patching is a bit worse than I expected, it doesn't look like WinDbg makes any attempt to call back to the original version of the method it's patching, which is a bit sad :-( That said, I'd expect zdb not to work when WinDbg is installed, and not the other way round... I'm CC'ing in a support address I found for Wing-IDE in the hope that one of those guys will contact me. I believe zdb replaces a lot of the code they currently have in WingDbg, hopefully I can persuade them to use zdb instead, then everyone can be happy ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
