Ok, 1.3.4 is out. The major changes were on the debugger (fixing bugs that were introduced in 1.3.3, given some major refactorings in its structure -- mostly to achieve a better performance -- so, all should be working again).
Also, I've downloaded and installed Eclipse 3.3 to start trying pydev with it. Mostly the experience has been nice...
The new diff is what I liked best. It now gives you not only the lines that changed on a first glance, but also shows you what actually changed, without having to go to 'next change' all the time -- pretty nice.
There were also some new things to learn: the startup.jar is now gone, so, if you do headless builds like me, you have to use eclipsec.exe instead of java -jar startup.jar -- which is something nice, but knowing which jar it uses is still something that may be handy (if you're doing profilings and need that jar, you can probably go to the configuration details and see how it was actually launched to use the same command-line -- haven't tested it, but it should work).
And the weirdest thing I found was that Ctrl+F11 doesn't always rerun the last run, it tries to find a configuration or something like that (probably for the project?) -- as I do tons of unit-tests and usually just do F9 in pydev to run the current editor and then just do Ctrl+F11 to re-run it again, I think that the modus operandi was nicer before for me -- fortunately, that is something that can be set in the preferences, so, I got to the old style and it works again as it used to.
Also, it seems that the java process is still alive when I finish eclipse. That may actually be a pydev bug (I've already had a report about it), so, I'll start to check if I can fix it (or if that's unrelated to pydev).
All in all, pydev seems to be behaving nicely with Eclipse 3.3 (aside from that bug), I've been able to build it without any code-changes, so, it seems pretty backward-compatible (but that's something that only time will tell).
Thursday, May 31, 2007
Saturday, May 26, 2007
Latest Development News (and pydev release 1.3.3)
Ok, I didn't blog about 1.3.3, and now it's almost time for 1.3.4 ;-)
Anyway, I've already fixed a number of things from that release... I'm always amazed how those tiny little details can get you bugs you wouldn't think of...
This time a test-case for the debugger was needed to fix a bug. Making a test usually pays of, not only in the long run -- which is pretty clear to many -- but also in the short run, because having to start your application and manually having to reproduce some strange behaviour is too painful (and yes, the fix was a one-line fix, but usually, the time to fix things after finding the error is short -- the difficult thing is finding it, and preventing from repeating it later on).
Testing the debugger needed a bit of work... Basically the test was created through recording what was going on the socket from eclipse and then reproduced in a test as if it was a regular run... The debugger is one of those things people think it's very hard to test (actually, until you're used to testing, everything seems hard), but the result was pretty neat in the end (although it needs some refactoring before extending it for other tests).
There were some other fixes regarding the debugger too, so, if you use it, I really recommend upgrading to 1.3.4 ...(as soon as it's out)...
Also, the debugger it's now officially ultra-fast -- really, it's about a gazzilion times faster than the initial versions and almost the double from a month ago... until 1.3.2 it traced all the context in a file that had breakpoints, and 1.3.3 takes this a step further and only traces function contexts that have breakpoints -- aside from some other improvements.
Anyway, I've already fixed a number of things from that release... I'm always amazed how those tiny little details can get you bugs you wouldn't think of...
This time a test-case for the debugger was needed to fix a bug. Making a test usually pays of, not only in the long run -- which is pretty clear to many -- but also in the short run, because having to start your application and manually having to reproduce some strange behaviour is too painful (and yes, the fix was a one-line fix, but usually, the time to fix things after finding the error is short -- the difficult thing is finding it, and preventing from repeating it later on).
Testing the debugger needed a bit of work... Basically the test was created through recording what was going on the socket from eclipse and then reproduced in a test as if it was a regular run... The debugger is one of those things people think it's very hard to test (actually, until you're used to testing, everything seems hard), but the result was pretty neat in the end (although it needs some refactoring before extending it for other tests).
There were some other fixes regarding the debugger too, so, if you use it, I really recommend upgrading to 1.3.4 ...(as soon as it's out)...
Also, the debugger it's now officially ultra-fast -- really, it's about a gazzilion times faster than the initial versions and almost the double from a month ago... until 1.3.2 it traced all the context in a file that had breakpoints, and 1.3.3 takes this a step further and only traces function contexts that have breakpoints -- aside from some other improvements.
Thursday, May 03, 2007
Debugging Zope in Pydev Extensions
I had already posted a message about the __init__.py files that you need to add to the zope Products folder (see previous post), and I've just gotten feedback from Mario Orlandi with some additional things that need to be configured for debugging zope:
1) Add to\__init__.py the following statements:
# allows pydevd.set_trace() inside Script (Python) objects
from AccessControl import ModuleSecurityInfo
ModuleSecurityInfo('pydevd').declarePublic('settrace')
2) Install this Zope product:
http://www.zope.org/Members/regebro/ScriptDebugging
3) Take a look at the following post:
http://freeplone2.openia.com/frpiano/how-to/how-to-setup-remote-debug-on-zope-with-pydev/, which may also work as a good reference (and don't forget to start the zope and the pydev daemon from eclipse).
1) Add to
# allows pydevd.set_trace() inside Script (Python) objects
from AccessControl import ModuleSecurityInfo
ModuleSecurityInfo('pydevd').declarePublic('settrace')
2) Install this Zope product:
http://www.zope.org/Members/regebro/ScriptDebugging
3) Take a look at the following post:
http://freeplone2.openia.com/frpiano/how-to/how-to-setup-remote-debug-on-zope-with-pydev/, which may also work as a good reference (and don't forget to start the zope and the pydev daemon from eclipse).
Subscribe to:
Posts (Atom)