Pydev 1.3.23 and 1.3.24

Yes, that's right, 2 new releases were done.

Basically, 1.3.24 fixes a major bug in Pydev, related to the debugger (it was halting on some cases and Jython was not working because a dependency on itertools was added).

I think that the major highlight in 1.3.23 is the possibility to debug multiple processes at the same time in the remote debugger (yes, it only supported one at a time), so, if you're spawning multiple processes, that should help a bit :)

Another fix was an incompatibility with the update manager of Eclipse 3.4... It should be backward compatible, but apparently, because the Pydev update site contained some really old versions, after installing Pydev, no other plugins could be installed! -- something related to getting the dependencies wrong in the new Eclipse update manager.

Aside from that, this release had lots of minor bugs fixed, so, upgrading is highly recommended!

Pydev Subversion @ Aptana

I think it's already widely publicized that Pydev is now a part of Aptana, and the last release is starting to mark that integration: the source is now available at the subversion hosted by Aptana.

The basic info to get it is:

• repo: https://source.aptana.com/pydev_repo/
• user: anonymous
• password: aptana

There are detailed instruction on how to get/build it at: http://pydev.sourceforge.net/developers.html

Enjoy!

Pydev 1.3.22

This Pydev release was focused mostly on bug-fixes, with many minor things being done. It fixed that nasty bug related to handling __all__ incorrectly together with a bunch of others.

I think that the only feature added that's worth mentioning is a mode where you can have Pydev analyze only your current editor (this enables builds to happen faster, as less work is needed when building the project, so, it can increase your performance a bit at the cost of having the markers added only to open editors). To activate it, go to window > preferences > Pydev > Builders and check 'Only analyze open editors'.

Note that doing so will not remove existing markers, and will be available for new analysis (the markers may be removed by right-clicking a folder and choosing "Pydev > Remove error markers"). Also, this feature is still in beta, so, please report any bugs found when using it.

Pydev 1.3.19

I guess 1.3.19 is already old news by now, but I decided to comment a bit on it, especially on a new support direction that'll start to be adopted in the Pydev development (and I'm still unsure how well that'll work):

Pydev will now try to support Eclipse 3.2, 3.3 and 3.4 (all with the same binaries) -- actually, there are still some known bugs on Eclipse 3.4, but those should be solved for the next release.

Now, while trying to support all those versions with the same binary release, there are some hacks that don't really seem right for me (but I couldn't see another way out for it):

1. Catching Exceptions such as ClassNotFoundException / LinkageError and related and falling back to another version (usually deprecated) of some API

2. When adapting to some interface, instead of having adapter == IElementContentProvider.class, do things as if(adapter.toString().endsWith("org.eclipse.debug.internal.ui.viewers.model.provisional.IElementContentProvider"))
-- because that class still does not exist on a previous version.

3. Using reflection (yes, in languages as Python this would be the default, but Java's not really made for this)

BTW: This wouldn't be possible without using Mercurial locally -- right now I have 4 workspaces, all synched through mercurial -- one for each version of Eclipse and one that's the link to the outside world -- and each of those has some changes to make it compile in that version -- yes, the final code runs in all versions, but it'll only actually compile in 3.3 for now -- the others have classes not defined (which are those cases with ClassNotFoundException), so, the code must be tested later on those versions with the final release.

Configuring tvtk / forced builtins

Recently, there was a report on problems while configuring tvtk (it's a pythonic API over vtk).

Having the import:

from enthought.tvtk.api import tvtk

did not bring any completions while later using 'tvtk.' on that module.

This happens because the code in tvtk does some black-magic to load the classes in that module... there's a module called enthought.tvtk.tvtk that has a class tvtk that's actually what's imported in "from enthought.tvtk.api import tvtk", so, the solution is adding "enthought.tvtk.tvtk.tvtk" to the "forced builtins", so that pydev can understand that it should be dynamically analyzed.

More info on the "forced builtins" can be found at: http://www.fabioz.com/pydev/manual_101_interpreter.html... and yes: finding out what should be dynamically analyzed and what shouldn't can be very tricky some times...