It's been only some days since the release and lot's of things already changed...
One part changed because of some (minor) bugs that were affecting the outline because of new changes I did to the parser and some old bugs regarding reusing the editor for showing some other file.
Also, I restructured many things in the way I deal with imports, to make it easier for getting information on relative imports... This was bugging me for some time already (and took me almost a full day to get all unit-tests running again).
Well, I guess this means a new release will be in its way not long from now...
Cheers,
Fabio
Friday, September 30, 2005
Sunday, September 25, 2005
So, what's next?
Long time since the last release... Well, next week (probably on monday or tuesday) a new release should come out. This will be mostly some nice 'minor' features (which make some lives so much easier) and some bug-fixes.
I'm still thinking about what should be the next implementation cycle for pydev... (especially since the time I'm putting on it is starting to shorten -- last month with OctetString support it advanced a lot -- even more to jython users).
There are still some things that they might want to have, so, who knows... I might be able to spend one more month with pydev in 'high-priority' mode :-)
Anyway, for those that use pydev, isn't there something you'd like to have enough for paying for its development? Or otherwise, isn't the current state of pydev enough for some donation? Well, just wanted to remind you that altough pydev is open-source, nothing is actually 'free'... so, if you do like and use it, a donation would be surely welcome (and if you use it professionally, how about trying to persuade your superior to make a little investment in your tools and help funding pydev? -- depending on the 'size' of the donation, you could also get some space in the homepage)
Cheers,
Fabio
I'm still thinking about what should be the next implementation cycle for pydev... (especially since the time I'm putting on it is starting to shorten -- last month with OctetString support it advanced a lot -- even more to jython users).
There are still some things that they might want to have, so, who knows... I might be able to spend one more month with pydev in 'high-priority' mode :-)
Anyway, for those that use pydev, isn't there something you'd like to have enough for paying for its development? Or otherwise, isn't the current state of pydev enough for some donation? Well, just wanted to remind you that altough pydev is open-source, nothing is actually 'free'... so, if you do like and use it, a donation would be surely welcome (and if you use it professionally, how about trying to persuade your superior to make a little investment in your tools and help funding pydev? -- depending on the 'size' of the donation, you could also get some space in the homepage)
Cheers,
Fabio
Monday, September 12, 2005
Pydev growth
Yeap, Pydev is becoming a big-boy...
I've looked at its statistics in sourceforge, and I must say that I'm pretty impressed that pydev has been in the top 50 projects in the last months...
Also, it's pretty rewarding (in many ways) to see pydev being so well accepted in the community. Another thing I would like to share is that lately, I've been getting a lot more support from the community to keep pydev growing, so, I'd like to leave special thanks for those that actively support pydev, through donations or through patches... without that support, pydev would surely not be where it is today.
Cheers,
Fabio
I've looked at its statistics in sourceforge, and I must say that I'm pretty impressed that pydev has been in the top 50 projects in the last months...
Also, it's pretty rewarding (in many ways) to see pydev being so well accepted in the community. Another thing I would like to share is that lately, I've been getting a lot more support from the community to keep pydev growing, so, I'd like to leave special thanks for those that actively support pydev, through donations or through patches... without that support, pydev would surely not be where it is today.
Cheers,
Fabio
Monday, September 05, 2005
Release 0.9.8.1
The release is out, but only partially...
I'm still trying to add it as a zip in sourceforge, but for some reason sf is way tooooooooooo slow today... so, I'm not sure if I'll be able to do it... anyway, those that were expecting java 1.4 support can already use the new release by getting it from the update manager.
Cheers,
Fabio
I'm still trying to add it as a zip in sourceforge, but for some reason sf is way tooooooooooo slow today... so, I'm not sure if I'll be able to do it... anyway, those that were expecting java 1.4 support can already use the new release by getting it from the update manager.
Cheers,
Fabio
Saturday, September 03, 2005
Back to the future... java 1.4 re-integrated
I'm currently in the process of re-supporting java 1.4. So, retroweaver was my first choice, and it appears it works quite well (I've already been able to use pydev in 1.4, but some testing is still needed), so, next week (maybe monday), I'll probably release it.
Well integration from the retroweaver perspective is quite easy, but from the eclipse perspective it is quite horrible (not difficult, but horrible). This is mostly because of the runtime environment that eclipse has now, that for me, basically sucks...
What they did is create a classloader that gets only things that are in the plugin or in dependent plugins in the 'allowed' packages... the problem is that by doing that, they just cut off all the good 'reflection' things java provides (that are actually not quite so good, if compared to other languages, such as python).
This means many things:
1 - I just can't serialize anything that has some structure from another plugin if I'm not dependent on it' which basically does not allow for any serialization utilities... in my case I had a core package that had it, and I basically had to copy it to all the places that needed it... just the opposite of reuse hum???
2 - In the retroweaver case, initally, I just did a plugin, added it to my core plugin and re-exported its dependencies... pretty simple and elegant, right? Well, that's what I thought, untill I saw that it needs to be able to do a Class.forName after the bytecode enhancement, but for that to happen, the retroweaver plugin must be dependent on all the plugins that are dependent on it, because of the *&(^%$ eclipse runtime environment... so, I had to copy the retroweaver jar to each plugin and add it to each build, etc, etc... which basically is really, really ugly to me... as I said, just the opposite of reuse...
There are way to many use-cases for me to list, so, I'll stop rambling here... it's probably kind of late to complain about it... I do understand the problem the eclipse guys had, which is: people were using their not 'public' classes, but instead of just saying: don't use it, they just did a horrible implementation of a runtime environment (don't get me wrong here... eclipse has many great things, but on this, it just sucks)... That's what I love about python... everybody is grown up, so, if I say something is private, you can still see it, and even depend on it, but you're warned, it may not be there next time, or it might not have what you expect, so, just don't depend on it (we're all grown-ups, right?). By doing what they did, they don't really enforce anything, as bad programming can happen everywhere (just copy and paste from the private code), what they did was preventing really good programming from happening.
I think that if they really wanted to try to enforce something, they should have marked their things they didn't want anyone to use as private (and let it as public for default)... eclipse 2 was so much better at this...
Wow, big post...
Cheers,
Fabio
Well integration from the retroweaver perspective is quite easy, but from the eclipse perspective it is quite horrible (not difficult, but horrible). This is mostly because of the runtime environment that eclipse has now, that for me, basically sucks...
What they did is create a classloader that gets only things that are in the plugin or in dependent plugins in the 'allowed' packages... the problem is that by doing that, they just cut off all the good 'reflection' things java provides (that are actually not quite so good, if compared to other languages, such as python).
This means many things:
1 - I just can't serialize anything that has some structure from another plugin if I'm not dependent on it' which basically does not allow for any serialization utilities... in my case I had a core package that had it, and I basically had to copy it to all the places that needed it... just the opposite of reuse hum???
2 - In the retroweaver case, initally, I just did a plugin, added it to my core plugin and re-exported its dependencies... pretty simple and elegant, right? Well, that's what I thought, untill I saw that it needs to be able to do a Class.forName after the bytecode enhancement, but for that to happen, the retroweaver plugin must be dependent on all the plugins that are dependent on it, because of the *&(^%$ eclipse runtime environment... so, I had to copy the retroweaver jar to each plugin and add it to each build, etc, etc... which basically is really, really ugly to me... as I said, just the opposite of reuse...
There are way to many use-cases for me to list, so, I'll stop rambling here... it's probably kind of late to complain about it... I do understand the problem the eclipse guys had, which is: people were using their not 'public' classes, but instead of just saying: don't use it, they just did a horrible implementation of a runtime environment (don't get me wrong here... eclipse has many great things, but on this, it just sucks)... That's what I love about python... everybody is grown up, so, if I say something is private, you can still see it, and even depend on it, but you're warned, it may not be there next time, or it might not have what you expect, so, just don't depend on it (we're all grown-ups, right?). By doing what they did, they don't really enforce anything, as bad programming can happen everywhere (just copy and paste from the private code), what they did was preventing really good programming from happening.
I think that if they really wanted to try to enforce something, they should have marked their things they didn't want anyone to use as private (and let it as public for default)... eclipse 2 was so much better at this...
Wow, big post...
Cheers,
Fabio
Friday, September 02, 2005
Release 0.9.8
Yeap, came out already!
This release had many, many fixes and new features, both in the python and jython part.
The major highlight in jython was that there is now a debugger supported for jython (the only available in an IDE that I know of so far...).
And for python users, I finally got some time to mess around with the grammar I'm using, so, you can now have decorators, the new import syntax and list comprehension in tuples and method calls (I believe this has some other name in this context, but I don't know which, so, I hope you understood...heheheh).
There were many, many changes in this release aside from those mentioned, so, bug-reports are expected (many were fixed already), so, a release 0.9.8.1 will be done shortly with bug-fixes for it.
Cheers,
Fabio
This release had many, many fixes and new features, both in the python and jython part.
The major highlight in jython was that there is now a debugger supported for jython (the only available in an IDE that I know of so far...).
And for python users, I finally got some time to mess around with the grammar I'm using, so, you can now have decorators, the new import syntax and list comprehension in tuples and method calls (I believe this has some other name in this context, but I don't know which, so, I hope you understood...heheheh).
There were many, many changes in this release aside from those mentioned, so, bug-reports are expected (many were fixed already), so, a release 0.9.8.1 will be done shortly with bug-fixes for it.
Cheers,
Fabio
Subscribe to:
Posts (Atom)