Wow, just now I realized that I still haven't posted about it... which is a real shame! ;-)
Well, Pydev Extensions (http://www.fabioz.com/pydev/) is a commercial plugin dedicated to extending Pydev (and adding those 'power-features' that can make your life so much easier). It has many new features, and has a lot of development going on.
The most 'noteworthy' (and already very mature) features are:
* Code completion with auto-import: I don't know how I ever managed to write code without it!!
* A 'real time', embedded code-analysis. This one is pretty nice, as it also allows getting errors while you're writing.
* Quick fixes for the errors found... From these, I guess that the most noteworthy 'quick-fix' (activated with Ctrl+1) is the one that allows you to automatically make an import on some undefined token.
* A go to definition that is a replacement to the one provided by BRM (again, I don't know how I managed without it before...)
* A debug server (allows debugging programs not ran directly from pydev) and a debug console (so that you can inspect things easier when you hit a breakpoint).
Well, there are more features... you can find the complete set at: http://www.fabioz.com/pydev/manual_adv_features.html
Also, it has *almost* a full month of existance -- which is still being celebrated -- And has lots of users already!
You can grab it and use it for 30 days without a license, so, ENJOY!
Cheers,
Fabio
p.s. This week we have 'carnival' here in Brazil, and I'll probably only be back on Tuesday... so, your e-mails and posts might take a little longer than usual to be answered.
Saturday, February 25, 2006
Wednesday, February 15, 2006
Test Driven Development in Pydev
I'm currently doing the pretty-printer for pydev, and was thinking about the way I do things...
In the end, my 'usual modus-operandis' can vary somewhat depending on what I'm developing. Usually, I like to do things with tests up-front, as was the case for the most intricate parts of pyde, like code completion, code analysis...
On the other way, for things I consider simpler, and that usually have a good 'visual' feedback, such as populating the outline, I must say there's little testing I do... basically, I just 'wish' very hard that it will keep working. I guess I must be a 'good' boy, as usually these kind of wishes come true to me ;-)
Anyway, being 'test-infected', sometimes I wonder if I should test more these interactions... I basically think that it wouldn't do much difference for those simple cases, as the time I would need to spend writing those tests are probably higher than the time I spending fixing these bugs (pydev has a 'low' number of bugs for these things... and I'm not even sure if adding those tests would lower those numbers).
On the other way, I think that it would be 'almost' impossible to deal with the critical parts without it... Let's take code completion as an example. If someone takes a look at its implementation, you can see that there is a lot of dependencies among modules, and a lot of recursivity going in the way that tokens are resolved, and much more than once, when I was up to fix something I ended breaking something else that had a dependency on that, but thankfully -- I would say luckilly, but then I thought better... luck has nothing to do with it ;-) -- the tests kept that 'error-cycle' very short.
So far so good right? Anyway, I guess that the only 'bad' part about the 'test-infected' way of doing things is sometimes not taking the time to try to refine my initial design to make some things easier from the beggining... I mean, probably in the end, with the tests and refactoring, the result could be very close, but there's a 'middle-ground' somewhere between those, which I feel would be the optimal point.
On the other side, I must say that in pydev, many 'complicated' things, didn't even have that initial design, some because I didn't 'feel' like doing it and some because I had no idea where to start, so I just wrote a test and made it pass... and then other... and other ;-)
In the end, my 'usual modus-operandis' can vary somewhat depending on what I'm developing. Usually, I like to do things with tests up-front, as was the case for the most intricate parts of pyde, like code completion, code analysis...
On the other way, for things I consider simpler, and that usually have a good 'visual' feedback, such as populating the outline, I must say there's little testing I do... basically, I just 'wish' very hard that it will keep working. I guess I must be a 'good' boy, as usually these kind of wishes come true to me ;-)
Anyway, being 'test-infected', sometimes I wonder if I should test more these interactions... I basically think that it wouldn't do much difference for those simple cases, as the time I would need to spend writing those tests are probably higher than the time I spending fixing these bugs (pydev has a 'low' number of bugs for these things... and I'm not even sure if adding those tests would lower those numbers).
On the other way, I think that it would be 'almost' impossible to deal with the critical parts without it... Let's take code completion as an example. If someone takes a look at its implementation, you can see that there is a lot of dependencies among modules, and a lot of recursivity going in the way that tokens are resolved, and much more than once, when I was up to fix something I ended breaking something else that had a dependency on that, but thankfully -- I would say luckilly, but then I thought better... luck has nothing to do with it ;-) -- the tests kept that 'error-cycle' very short.
So far so good right? Anyway, I guess that the only 'bad' part about the 'test-infected' way of doing things is sometimes not taking the time to try to refine my initial design to make some things easier from the beggining... I mean, probably in the end, with the tests and refactoring, the result could be very close, but there's a 'middle-ground' somewhere between those, which I feel would be the optimal point.
On the other side, I must say that in pydev, many 'complicated' things, didn't even have that initial design, some because I didn't 'feel' like doing it and some because I had no idea where to start, so I just wrote a test and made it pass... and then other... and other ;-)
Tuesday, February 07, 2006
Checking how to do code-formatting
I was giving a quick look on how could the code-formatter be better, and having researched a little on how would it do the 'pretty-print' I found some references:
Dealing with comments:
Approach 1 (using special token):
- https://javacc.dev.java.net
/servlets/ReadMsg?list=users&msgNo=227
Approach 2 (not using special token and actually putting comments in the parsing.
- http://cvs.sourceforge.net/viewcvs.py/jrefactory
/JRefactory/javacc/java1_5.jjt?rev=1.18&view=markup
Currently, I generate an asdl structure that would also need to be extended to be supported later, but I guess I'll have to work on this myself, as I could not find any reference about comments in asdl... anyone has any suggestions?
And a little 'offtopic' but also for javaCC:
Error recovery: http://www.cise.ufl.edu/help/software/JavaCC/errorrecovery.html
Getting special tokens: https://javacc.dev.java.net/doc/tokenmanager.html
Cheers,
Fabio
Dealing with comments:
Approach 1 (using special token):
- https://javacc.dev.java.net
/servlets/ReadMsg?list=users&msgNo=227
Approach 2 (not using special token and actually putting comments in the parsing.
- http://cvs.sourceforge.net/viewcvs.py/jrefactory
/JRefactory/javacc/java1_5.jjt?rev=1.18&view=markup
Currently, I generate an asdl structure that would also need to be extended to be supported later, but I guess I'll have to work on this myself, as I could not find any reference about comments in asdl... anyone has any suggestions?
And a little 'offtopic' but also for javaCC:
Error recovery: http://www.cise.ufl.edu/help/software/JavaCC/errorrecovery.html
Getting special tokens: https://javacc.dev.java.net/doc/tokenmanager.html
Cheers,
Fabio
Monday, February 06, 2006
Pydev 1.0.1
Yeap, just some hours after releasing version 1.0 I had to release 1.0.1... This is because of one of the stupidest bugs I ever did...
I accidentally commented a line... and it probably occured between passing the unit-tests and making the build.
Yeah,yeah, I know, I should pass the tests only when it is already built... but I still have to work out on how to do that in the pydev structure.
Well, 1.0.1 is already out, so, enjoy it.
Cheers,
Fabio
I accidentally commented a line... and it probably occured between passing the unit-tests and making the build.
Yeah,yeah, I know, I should pass the tests only when it is already built... but I still have to work out on how to do that in the pydev structure.
Well, 1.0.1 is already out, so, enjoy it.
Cheers,
Fabio
Friday, February 03, 2006
Pydev 1.0
Well, that's it, the next version will be 1.0. Pydev has surely already reached its maturity. I will try to release it next week.
There were tons of improvements over the last version, in the debugger, in the PyLint integration, wizards, perspective, shorcut to run the editor file, etc.
Also, next week I'll start giving commercial support to Pydev and release a new plugin named 'Pydev Extensions' -- which has already quite some time of development (and in that, I hope to be able to give better support for the Open Source version too).
I'll announce what it can do next week, together with the 1.0 release of Pydev... But just as a little 'preview', think about faster code analysis (not PyLint), auto-import, remote debugging... ;-)
Actually, I've been thinking about that for quite some time now, and I think this is going to be a win-win situation in many ways... Hope you all enjoy it too...
Cheers,
Fabio
There were tons of improvements over the last version, in the debugger, in the PyLint integration, wizards, perspective, shorcut to run the editor file, etc.
Also, next week I'll start giving commercial support to Pydev and release a new plugin named 'Pydev Extensions' -- which has already quite some time of development (and in that, I hope to be able to give better support for the Open Source version too).
I'll announce what it can do next week, together with the 1.0 release of Pydev... But just as a little 'preview', think about faster code analysis (not PyLint), auto-import, remote debugging... ;-)
Actually, I've been thinking about that for quite some time now, and I think this is going to be a win-win situation in many ways... Hope you all enjoy it too...
Cheers,
Fabio
Subscribe to:
Posts (Atom)