PyDev 2.2.0 released

It's out already.

This release is the first to add support for Eclipse 3.7 (which has just been released too).

The major feature added was the exception breakpoints handling (so, it's now possible to stop the debugger on caught or uncaught exceptions -- the UI for it may be accessed at the menu Run > Manage Python Exception Breakpoints).

The debugger should also be a bit faster (and some bugs related to multithreaded debugging were fixed).

For those using Django, some utilities were added so that it's possible to easily do a (remote) debug session with auto-reload enabled (see details at: http://pydev.org/manual_adv_remote_debugger.html#django-remote-debugging-with-auto-reload)

And as usual, a bunch of minor bugs were also fixed.

Override/implements templates on PyDev

One thing I miss when working on Python is a way to let people know when some method is overridden (and having it raise an error if it's not)... I'm thinking about adding a decoration for that in PyDev (and probably a way to navigate to the super with that implementation), so, that'll work when using PyDev, but still, many times I look to the source code outside of PyDev (i.e.: review board, github, etc), and to sort that out, what I'm currently using is the following:

1. Create overrides (for when a method is overridden from a subclass) and implements (to indicate that some method conforms to an interface, even if not actually overriding a method) decorators as follows:



2. Create templates (in PyDev) as follows:

Name: overrides
Description: @overrides
Pattern: @overrides(${superclass}.${next_class_or_method})

Name: implements
Description: @implements
@implements(${interface_class}.${next_class_or_method})


3. Use it in your code:



To use it, just start typing 'overrides' before a 'def method' and apply the completion (and it should complete the class/method properly on overrides -- for the implements, the name of the implementing class will still be needed later on).

PyDev 2.1.0 released

PyDev 2.1.0 has just been released, with a few noteworthy changes:

The first change that's noteworthy is that only files opened in an editor will be code-analyzed... Until now, any file changed in the workspace would be analyzed for coding errors, which is a process that is usually fast, but there are 2 problems there:

1. if lots of files changed at once, it could still be costly to make that analysis (and on really big files, that could be a problem too)

2. there's no dependency analysis to know if a file should be re-analyzed when a given file changes, so, the actual state of warnings/errors could be misleading

Still, as sometimes it's useful to do the analysis of many files at once, it's now possible to right-click a folder in the PyDev package explorer and ask for a full code-analysis to be done (note that the re-indexing of internal information still must be done for any file changed, but this process is pretty fast).

Another nice feature added is a code-completion to override methods, so, after typing "def ", a code-completion may be requested to override a given method.

And for TDD lovers, there's now an option to relaunch the last launch in the PyUnit view whenever a file changes :)

The full details on the release may be seen at: http://pydev.org/

PyDev: Paying down technical debt...

Yeap, pay time :)

The next release is taking a bit more than usual because I'm taking time to pay some of the technical debt that PyDev accumulated over the years...

Not that this will also reflect in a bunch of things that will be noticed externally (e.g.: faster build times) and there are some features added too, such as an override methods code-completion...

The current nightly is already stable (although there are some more changes that are still planned), so, anyone curious is welcome to grab the latest nightly and take it for a spin...

Profiling slow downs on Eclipse

Java has this very nice utility that ships with the JDK called Java VisualVM which can provide many insights about what may be happening inside a java vm.

The steps for verifying are:

1. Have the actual java JDK installed (not only the jre) -- preferably the latest java 6.

2. Start Eclipse with -Dcom.sun.management.jmxremote vmarg (edit the eclipse.ini file and add a line -Dcom.sun.management.jmxremote after the line -vmargs -- at least for Eclipse 3.6.x -- and restart it)

3. Go on with your life until you get to something that's slow.

4. When you get up to that point, start up the Java VisualVM: it's an executable usually located at: JAVA_HOME\bin\jvisualvm.exe

5. Double click the java process running Eclipse (may appear as <Unknown Application>)

6. Go to the 'monitor' tab and check if the Heap/PermGen is too close to the max size (if it is, probably the -Xmx argument must be raised in eclipse.ini -- if you feel it shouldn't be taking up so much memory -- i.e.: there's a memory leak, click the 'heap dump', which may be a big file, zip it, upload it somewhere and point to it in a bug report).

7. If the memory seems fine, the next step is seeing up the threads running and creating a thread dump and right after it, go to the sampler, click on cpu to get sample data and add that data to a bug report (and attach both the thread dump and the sampler info to a bug report).

And hopefully, that's enough information to know what may be wrong :)