Ok, I've been giving a whirl on supporting Eclipse 4.2 on PyDev and everything seems to work as expected, but unfortunately, I still can't recommend the Eclipse 4.x series over the 3.x series because performance-wise Eclipse 4 is still not on par with Eclipse 3 (and for me the only gain was that floating docks are now better -- as for skinning, I don't really think it's much better for final users unless someone else already got to the point of doing a skin exactly as you'd want -- so I think that for now, Aptana Studio 3 skinning (themeing) is a better solution -- and targeted at Eclipse 3.x).
I have hopes that those issues will be addressed in a newer release of Eclipse 4, but the truth is that right now Eclipse 4 feels sluggish when compared to Eclipse 3 (even changing configurations on the Eclipse appearance preferences for having some performance gains).
So, if by any chance you've just gotten into PyDev and it doesn't seem as speedy as you'd like, please make sure you check it with Eclipse 3.8 (in the downloads page: http://download.eclipse.org/eclipse/downloads/ there's a link to Eclipse 3.x downloads available: http://download.eclipse.org/eclipse/downloads/eclipse3x.html).
Also, make sure that you have the latest version of java as it may make a difference.
Or, if you've gotten the Aptana Studio 3 download directly, you're already good to go -- as it's already based on Eclipse 3.x and has PyDev preinstalled (see http://pydev.org/download.html for links).
Tuesday, August 14, 2012
Monday, July 02, 2012
Git (multiple repos)
Improving my Git workflow has been one of my current targets lately... Especially when working with multiple projects.
So, although I'm working all the time inside Eclipse, I still like to use the command line for many things (so, even with the Aptana Studio 3 Git integration and EGit having improved, I still use the command line a lot on common operations, resorting to other options mostly when investigating the history of a repository or some other thing which may be suboptimal in the command line).
To improve that situation, I ended up creating a tool... Yes, I know there are probably many other command line tools that try to accomplish that, but I did a good amount of research and didn't find anything that worked as I wanted -- and not nearly as fun (but I appreciate suggestions in this realm).
The tool I did is hosted at GitHub: https://github.com/fabioz/mu-repo, and it's freely available (GPL 3).
It's a Python program which interfaces with the git binary to execute whatever is needed. Also, for diffing operations it currently relies on WinMerge (meaning this part of the tool is Windows only for now, but if there's interest, it should be straightforward having it support other diff tools such as KDiff3).
My basic workflow is now:
cd /workspace (which has many .git subrepos)
Note: all the "mu" operations below will actually be applied to all the git subdirs (must be previously registered), so, a single command line is enough for dealing with all repositories at once -- yes, I know about git submodules, but I don't really like how it works -- and it's one of the main reasons this tool exists :)
To get changes:
mu up (fetches origin for the current branch updating the origin/current_branch reference -- I found it weird that trying to do "git fetch origin current_branch" ended up updating FETCH_HEAD instead of origin/current_branch -- also, this and most other operations work only in the current branch, leaving other branches or references untouched).
mu dd origin/current_branch (preview incoming changes: compare current branch HEAD to origin/current_branch).
mu rebase origin/current_branch (rebase incoming changes -- could also be: mu merge origin/current_branch).
To submit changes:
mu st (check status of changed files -- indexed or not)
mu dd (diff working copy with winmerge while editing changes and keeping the working dir updated even if no symlink support is available)
mu acp "message" (add all working copy changes, commit, push)
To start working on a feature:
mu co -b branch_name (create branch for all repos)
mu ac "message" (add / commit changes on that branch)
mu co main_branch (go back to main branch)
mu rebase branch_name (get the changes from the branch into the main branch)
mu branch -D branch_name (remove that local branch)
Note that for my workflow I work mostly without taking "advantage" of the git index -- usually I review things with "mu dd" and on "mu ac" I add all the changes to the index and commit in a single operation (before that I was almost always doing "git add -A" and "git commit -m "message"" anyways).
I also still configure many things as I posted previously: http://pydev.blogspot.com.br/2011/02/git-on-command-line.html, but a bunch of things are now better integrated with this tool :)
Also, the tool works for a directory that has a '.git' repository, so, operations such as the diff with WinMerge can be used even when working with a single git repository.
p.s.: The tool is still in beta, so, although I'm using it all the time, it's possible that some things are not working as they should -- but on the good side, I still haven't been able to corrupt any of my git repos :)
So, although I'm working all the time inside Eclipse, I still like to use the command line for many things (so, even with the Aptana Studio 3 Git integration and EGit having improved, I still use the command line a lot on common operations, resorting to other options mostly when investigating the history of a repository or some other thing which may be suboptimal in the command line).
To improve that situation, I ended up creating a tool... Yes, I know there are probably many other command line tools that try to accomplish that, but I did a good amount of research and didn't find anything that worked as I wanted -- and not nearly as fun (but I appreciate suggestions in this realm).
The tool I did is hosted at GitHub: https://github.com/fabioz/mu-repo, and it's freely available (GPL 3).
It's a Python program which interfaces with the git binary to execute whatever is needed. Also, for diffing operations it currently relies on WinMerge (meaning this part of the tool is Windows only for now, but if there's interest, it should be straightforward having it support other diff tools such as KDiff3).
My basic workflow is now:
cd /workspace (which has many .git subrepos)
Note: all the "mu" operations below will actually be applied to all the git subdirs (must be previously registered), so, a single command line is enough for dealing with all repositories at once -- yes, I know about git submodules, but I don't really like how it works -- and it's one of the main reasons this tool exists :)
To get changes:
mu up (fetches origin for the current branch updating the origin/current_branch reference -- I found it weird that trying to do "git fetch origin current_branch" ended up updating FETCH_HEAD instead of origin/current_branch -- also, this and most other operations work only in the current branch, leaving other branches or references untouched).
mu dd origin/current_branch (preview incoming changes: compare current branch HEAD to origin/current_branch).
mu rebase origin/current_branch (rebase incoming changes -- could also be: mu merge origin/current_branch).
To submit changes:
mu st (check status of changed files -- indexed or not)
mu dd (diff working copy with winmerge while editing changes and keeping the working dir updated even if no symlink support is available)
mu acp "message" (add all working copy changes, commit, push)
To start working on a feature:
mu co -b branch_name (create branch for all repos)
mu ac "message" (add / commit changes on that branch)
mu co main_branch (go back to main branch)
mu rebase branch_name (get the changes from the branch into the main branch)
mu branch -D branch_name (remove that local branch)
Note that for my workflow I work mostly without taking "advantage" of the git index -- usually I review things with "mu dd" and on "mu ac" I add all the changes to the index and commit in a single operation (before that I was almost always doing "git add -A" and "git commit -m "message"" anyways).
I also still configure many things as I posted previously: http://pydev.blogspot.com.br/2011/02/git-on-command-line.html, but a bunch of things are now better integrated with this tool :)
Also, the tool works for a directory that has a '.git' repository, so, operations such as the diff with WinMerge can be used even when working with a single git repository.
p.s.: The tool is still in beta, so, although I'm using it all the time, it's possible that some things are not working as they should -- but on the good side, I still haven't been able to corrupt any of my git repos :)
Thursday, June 28, 2012
PyDev 2.6.0 released
PyDev 2.6.0 is just out of the door.
Main in this release were changes in the interactive console -- and mostly by external contributors, so, it seems this feature has really picked up some traction :)
Hussain Bohra made it possible to have an interactive console bound to a debugger frame and James Blackburn did a bunch of fixes in it.
Aside from that, the default PyUnit runner has new options to include/exclude files from the test loading process and Jython has an annoying fix done (print can be used as a dotted notation) along with many other fixes (see: http://pydev.org for more details).
Also, the PyDev official issue tracker is now the same tracker used in Aptana Studio 3: https://jira.appcelerator.org/browse/APSTUD/ (there's a component related to PyDev there).
The issues currently on Sourceforge will be migrated to that tracker, but there's no way to make the current Sourceforge trackers read-only, so, I'm just redirecting people to the new tracker and asking not to post on the old one -- hope that works :)
It's interesting to note that now the official Eclipse release is focused on Eclipse 4.x (and not on 3.x)... the integration has already been tested, but not as much as the 3.x series, so, please report any issues found in the way.
Main in this release were changes in the interactive console -- and mostly by external contributors, so, it seems this feature has really picked up some traction :)
Hussain Bohra made it possible to have an interactive console bound to a debugger frame and James Blackburn did a bunch of fixes in it.
Aside from that, the default PyUnit runner has new options to include/exclude files from the test loading process and Jython has an annoying fix done (print can be used as a dotted notation) along with many other fixes (see: http://pydev.org for more details).
Also, the PyDev official issue tracker is now the same tracker used in Aptana Studio 3: https://jira.appcelerator.org/browse/APSTUD/ (there's a component related to PyDev there).
The issues currently on Sourceforge will be migrated to that tracker, but there's no way to make the current Sourceforge trackers read-only, so, I'm just redirecting people to the new tracker and asking not to post on the old one -- hope that works :)
It's interesting to note that now the official Eclipse release is focused on Eclipse 4.x (and not on 3.x)... the integration has already been tested, but not as much as the 3.x series, so, please report any issues found in the way.
Tuesday, April 10, 2012
PyDev 2.5.0 released
Major things in the PyDev 2.5.0 release include:
Aside from those, many bugs were fixed and minor improvements were done. More details can be seen at: http://pydev.org/
- Proper support for Django 1.4 (as it's layout changed, the project creation wizard wasn't working properly).
- Better patching of Django 1.4 for the debugger and auto-reload (details at the end of the page: http://pydev.org/manual_adv_django.html). Note: there is an issue when using it on Linux, which is already fixed in the nightly build, so, if you are on Linux and want to experiment with it, please update to the current nightly build.
- The interactive console can now be attached to the variables/expressions view (the preference at: window > preferences > PyDev > Interactive Console and check 'Connect console to Variables Debug View?' must be enabled). Also, there's drag and drop support for it now.
Aside from those, many bugs were fixed and minor improvements were done. More details can be seen at: http://pydev.org/
Tuesday, March 13, 2012
PyCon retrospect
Ok, so, this was the first time I've been on PyCon and I must say it was pretty nice.
Initially, it started out kind of lousy for me: United seems to have 'misplaced' my bag and I only got it back in time to check it back to Brazil, so, that sucked. On the other hand, to balance things, I won a Kindle DX in raffle from http://www.truecar.com :)
Mainly, it was awesome talking to so many great names of the Python world... Meeting people face to face does make a great difference (some things are simply not as well expressed in an e-mail).
On the PyDev side, it was pretty nice seeing many people using it while hacking away during the conference and even having some people asking 'how can I help to make PyDev better?'.
I guess I wasn't properly prepared and mostly, my answer was: read the devs guide to grab the code/compile, find an itch to scratch and mail me about it so that I can help you find yourself there... Some things can be done in Java, some in Jython, depends a lot on what you want to do.
Aside from that, documentation-wise, I guess the major issue would be having some section explaining how to configure each major library on how to work with PyDev (most work out of the box, but some need minor adjustments such as adding a token to the forced builtins and some may even require more than that), so, if someone is willing to help working on the PyDev documentation in that topic, that would be a great help (and I guess that if someone doesn't have an itch to scratch and still wants to contribute in code, there are things I can point to that need to be done and are relatively simple to get started).
On the scientific computing side, I liked Numba (https://github.com/ContinuumIO/numba), which seems to be a pretty nice idea... it's still in its early stages, but I think it could be a nice substitute for Psyco (but with knowledge about numpy types and maybe a bit more strict -- if I did understand it properly)... I'd much rather use something as Numba for speedups than Cython (as the Cython code is only 'close' to Python, but doesn't really run on a Python interpreter) and Pypy is just not an option right now...
Although Pypy seemed strong in the conference, I must say that it'll probably be a long, long time until I'll be able to use it in production... I really use lots of code in C/C++ bindings, so, this is a killer CPython feature which I'm not sure Pypy will ever be able to provide (and the 'current' workaround of porting a library to RPython as is being done in Pypy/Numpy doesn't seem to be really feasible).
One thing I thought was a bit strange was the lack of projects with Python in mobile platforms, as I was guessing it should be straightforward to compile Python to Android/iPhone (so, I'm guessing the issue is probably the lack of proper multi-platform bindings on that area). In contrast, Python seems very strong on the server-side and scientific computing fields.
And I think Python 3 does deserve a special note here: I think Guido left it pretty clear (as much of his keynote talked about the subject) that Python 2 is really deprecated, so, although it's currently the production version that's most widely deployed/used, people have to really start getting used to the idea that a port to Python 3 is the way to go -- although in the real world, I still do expect this to take quite a few years (probably more than was initially expected by the Python-core folks). The fact that Guido made this topic such a big portion of his keynote, does make me feel like many of the Python lovers were against this move and the actual response from the community on this respect has been mixed, but regardless of that, the direction that Python-core is going is 100% on Python 3 (maybe doing something here or there to help in easing the port or having a shared Python 2-3 codebase).
And, there are still have some talks I'll see later at: http://pyvideo.org (because many interesting talks took place at the same time).
Initially, it started out kind of lousy for me: United seems to have 'misplaced' my bag and I only got it back in time to check it back to Brazil, so, that sucked. On the other hand, to balance things, I won a Kindle DX in raffle from http://www.truecar.com :)
Mainly, it was awesome talking to so many great names of the Python world... Meeting people face to face does make a great difference (some things are simply not as well expressed in an e-mail).
On the PyDev side, it was pretty nice seeing many people using it while hacking away during the conference and even having some people asking 'how can I help to make PyDev better?'.
I guess I wasn't properly prepared and mostly, my answer was: read the devs guide to grab the code/compile, find an itch to scratch and mail me about it so that I can help you find yourself there... Some things can be done in Java, some in Jython, depends a lot on what you want to do.
Aside from that, documentation-wise, I guess the major issue would be having some section explaining how to configure each major library on how to work with PyDev (most work out of the box, but some need minor adjustments such as adding a token to the forced builtins and some may even require more than that), so, if someone is willing to help working on the PyDev documentation in that topic, that would be a great help (and I guess that if someone doesn't have an itch to scratch and still wants to contribute in code, there are things I can point to that need to be done and are relatively simple to get started).
On the scientific computing side, I liked Numba (https://github.com/ContinuumIO/numba), which seems to be a pretty nice idea... it's still in its early stages, but I think it could be a nice substitute for Psyco (but with knowledge about numpy types and maybe a bit more strict -- if I did understand it properly)... I'd much rather use something as Numba for speedups than Cython (as the Cython code is only 'close' to Python, but doesn't really run on a Python interpreter) and Pypy is just not an option right now...
Although Pypy seemed strong in the conference, I must say that it'll probably be a long, long time until I'll be able to use it in production... I really use lots of code in C/C++ bindings, so, this is a killer CPython feature which I'm not sure Pypy will ever be able to provide (and the 'current' workaround of porting a library to RPython as is being done in Pypy/Numpy doesn't seem to be really feasible).
One thing I thought was a bit strange was the lack of projects with Python in mobile platforms, as I was guessing it should be straightforward to compile Python to Android/iPhone (so, I'm guessing the issue is probably the lack of proper multi-platform bindings on that area). In contrast, Python seems very strong on the server-side and scientific computing fields.
And I think Python 3 does deserve a special note here: I think Guido left it pretty clear (as much of his keynote talked about the subject) that Python 2 is really deprecated, so, although it's currently the production version that's most widely deployed/used, people have to really start getting used to the idea that a port to Python 3 is the way to go -- although in the real world, I still do expect this to take quite a few years (probably more than was initially expected by the Python-core folks). The fact that Guido made this topic such a big portion of his keynote, does make me feel like many of the Python lovers were against this move and the actual response from the community on this respect has been mixed, but regardless of that, the direction that Python-core is going is 100% on Python 3 (maybe doing something here or there to help in easing the port or having a shared Python 2-3 codebase).
And, there are still have some talks I'll see later at: http://pyvideo.org (because many interesting talks took place at the same time).
Subscribe to:
Posts (Atom)