Resize VirtualBox hard disk drive

Numerous post cover how easily this can be done.

$ sudo vboxmanage modifyhd filename --resize size-in-MB

There is a catch, and I'm not sure why, but your VM may not recognize the new unallocated space if there are snapshots, so make a clone first and work with that.

Extending your partition in Windows XP is a little more work. If you are not extending the system partition, Windows XP can handle it using diskpart. Otherwise there are numerous partition managers (listed in no particular order) such as EaseUS Partition Master, Aomei Partition Assistant, Mini Tool Partition Wizard (which also has a live CD for download), and GParted Live. Here's a recent review with a few others.

All of these except the last (two, if you include Mini Tool) must be installed first. I chose GParted Live because I did not want to install any more software on my VM than necessary, and I didn't want to uninstall it either. Also it's easy enough for me to reboot my VM using any ISO image on my host. GParted Live is an ISO image of a mini Debian X11 system with Gparted, the partitioning tool. It has everything you need to manage your partitions on any platform. All of the files in the dependencies for each platform are in the ISO image.

As always there are caveats. Before you edit your partitions obviously back up any data. But you already did that by making a clone of your VM. Now defragment then run CHKDSK /f on your old volume. This is to make sure the disk sectors are properly accounted. Otherwise GParted won't know where they are and will fail. Don't worry, if this happens your disks will not be altered, and GParted tells you to do what I just said above. The rest is pretty obvious.

VS C# Cheat

To change the target platform, manually edit the platform tag in the *.csproj project file. The platform tag can be titanium, anycpu (default), x86 & x64.

[UPDATE 2014-04-27] This is unnecessary for VS2010, since you can use in the Configuration Manager to add the x64 or whatever target you want. See How to: Configure Visual C++ Projects to Target 64-Bit Platforms on MSDN.

hg-git and TortoiseHg

[UPDATE 2013-05-28] Make sure your hg-git is up to date and pointing at the most recent tag. I have had issues when I have updated hg but not pulled the latest hg-git changes from durin42.

If for some reason you were using Mercurial, aka Hg, and you needed to interact with Git, then you probably have heard about hg-git. There are other tools, but I think this one is the oldest, and even though not necessarily the best, it works fine. Now if you are on Windows, then you are most likely using TortoiseHg, aka thg, and if so integrating hg-git is a snap. The only confusion is that there are multiple website with seemingly different information. If you already have TortoiseHg installed, all you have to do is follow the directions in the TortoiseHg v2.1.1 Documentation: Section 9.3: Use with other VCS systems: hg-git (git). There are some key differences between this documentation and what you will find on various other websites which are geared toward non-TortoiseHg users. In particular, hg-git requires Dulwich, a python-git implementation, but note what it says in the thg docs:

Current versions of TortoiseHg include dulwich version 0.7.0. We recommend to use hg-git version 0.2.6 with this version of dulwich and Mercurial 1.8.

So you don't need to install Dulwich if you are using hg-git with TortoiseHg! This is intended for non-thg users.

Now on to use:

1. Make sure that you have enabled the plugin by adding the [extension] line hggit = C:\hg-git\hggit to your mercurial.ini file, which can be found in your user-profile folder (the one with your Windows user name). This is described in all of the websites, but most of them use the Linux/Unix home folder ~/.hgrc which you will NOT find on a windows machine unless you are using Cygwin or minGW/MSYS. For thg installations of Mercurial, the %USERPROFILE%\mercurial.ini file is the equivalent of the Linux ~/.hgrc file.
2. Branches should to bookmarked before you can push them to a git repo. Basically this is how hg-git deals with branches. A Git branch is the equivalent of an hg bookmark. This is because branches in Mercurial and Git are different. You can do this manually by issuing the command hg bookmark -r default master. That basically maps the hg branch called default to the git branch called master, by creating an hg bookmark also called master. The -r allows you to specify the revision (could be an hg branch, bookmark or tag), instead of pointing to the current working copy. For example if you have an hg branch named x64 if you want to push it to a Git repo, make a bookmark, hg bookmark -r x64 x64_git; note that in Mercurial branches and bookmarks cannot have the same name. There is an hg-git extension you can add that will remove the suffix, but a better practice might be to use bookmarks instead of named branches in Mercurial.
3. Finally to push to your git repo use hg push git+ssh://git@github/user/repo. Note that protocol "git+ssh://" and the switch from colon to slash between github and user! That tells hg-git to push to a git repo using ssh. Also you will need to enable Pageant, you can find it in the thg folder in program files. You will need an ssh key. If you don't already have one, you can download puttygen and follow the directions on Bitbucket: Using the SSH protocol.

That's it. You don't need to enable the bookmarks extension, because it became part of Mercurial core 1.8. There is an issue with author, you want to make sure that you are commiting with the same username. You can set that in either mercurial.ini globally or in .hg/hgrc per repo. Alternately select thg settings and commit. But not setting this is NOT a show stopper.

Package Predicament Part 3: Python, the final installment

[WARNING: Outdated Material] This post is over a year old, and consequently the ideas, opinions and facts may no longer be relevant or accurate (assuming there were actually facts in this post). Please proceed with caution. You have been warned.

So it turns out that there is a long history between Python and Linux (*). Debian has an official Python Package Policy. This is because Python is an integral part of Linux; Linux libraries depend on Python and Python packages. If you go moving them around, you will break your Linux installation.

One of the main differences you will see are the /lib/site-packages folder is renamed /lib/dist-packages on Linux (* just Ubuntu, see CORRECTION), and the existence of /usr/share/pyshared and /usr/lib/pymodules on Linux as well. I'm not going to pretend I understand everything that's going on, but in a nutshell these are Python modules that Linux is using, for something.

Lucky for you, distribute, setuptools, distutils and pip are tailored for Ubuntu so that they will install packages in the correct locations, and also know where to find them. So in general this supports the argument that you should look for your Python packages from the distro repo, especially pip, distribute, setuptools, distutil, and virtualenv. If you install these from your distro repo, you should be OK (**). And above all, "for the love of Guido," use pip, never easy_install!

[CORRECTION: 2012-04-11] (*) After several adventures with VMs (Fedora16, OpenSUSE 12 and even FreeBSD), I have done some experimentation, and some of these Python-peculiarities are only on Ubuntu/Debian distros. For example, there is no dist-packages folder on either OpenSUSE or Fedora. They both use the traditional Python file structure and name conventions such as site-packages. On Fedora it looks like your packages will go in /usr/lib/Python2.7/site-packages, whether you install them with $ sudo yum install python-package or $ sudo pip-python package. Note: on Fedora pip is pip-python, unless you are using it from a virtualenv, then it's just pip. There's nothing in the /usr/local/lib folder on Fedora remotely related to Python, nor /usr/local/share. I didn't get a chance to look for pyshared or pymodules, which are both in /usr/lib on Ubuntu 11.10, but I did notice that there is a lib-dynload in /python2.7.

So what does this all mean? Well, I tried to install numpy with pip in a virtualenv on Fedora, and it still failed miserably (***), see Package Predicament, Part 2. I've research it a little, there are some old bug reports, and several SO questions, but no good answer. I did not try to install it in the base system, but I'm believe it would fail there, just like it did on my Oneiric Ocelot. I think it's a problem with pip, not virtualenv, and I guess the Numpy setup.py or egg. BTW: it also fails on Windows, no surprise; where's my libgcc? Sorry I don't have the complete MinGW installation, only MsysGit. But of course I can install it using the *.exe all-in-one isntaller from Numpy/Scipy website just fine.

[UPDATE: 2013-01-16] (***) Duh, I needed the dev packages, _obviously_. Do yum/apt-get/zypper install libatlas-dev, ... and make sure you have gfortran. Numpy, SciPy and Matplotlib all build fine with pip in a virtualenv, once you have the proper dev files. Now Windows is an entirely different story, but it can also be done.

[UPDATE: 2012-04-17] (**) You can seriously f*** up your sh** if you start messing around with your distro's version of distribute, distutils or setuptools. For example, Unity's Software Center depends on these to install packages. If you screw up your version of setuptools, Software Center won't even open. My advice is to (1) use virtualenv for any package that you need that differs from your repo's version. For example python-requests is version 0.5 in Oneiric Ocelot, but newest version of Requests is (as of now) 11.1, so you should create a virtualenv and install it there. (2) Only pip Python packages that are pure Python, that are not in your repo, and do not let them install dependencies that are already installed by your repo. For example, Requests now requires chardet >=1.0.0, which because Ubuntu's version of chardet is named oddly 2.0.1-2 causes pip to replace it with the exact same code. Probably fine, but not smooth. (3) If your desired package has dependencies that already exist in the repo, then use virtualenv and install them there. (4) Put a simlink to packages that require compiled code, such as Numpy in your virtualenv site-packages folder.

Package predicament or distribution dilemma, part 2

[UPDATE 2013-05-01]

Another post so hopelessly outdated, that it's almost better off just deleting. On the flip side it's instructive to relive, however painful  my learning process. So I addressed the issue of building Numpy from source using Pip in both the system (local) environment and in a virtualenv (always recommended) in an update to the next and final installment of this 3-part post: Package Predicament Part 3: Python, the final installment, and in there I also link to the solution: Building numpy, scipy, matplotlib and PIL in virtualev on both windows and linux. In a nutshell my intuition in (a) below was correct. In particular Numpy requires both C and Fortran compilers, and the source for its dependencies, or at least their headers, specifically BLAS and LAPACK. However the issue of building Numpy was peripheral to the real question in this series of where and when to deviate from the Ubuntu package repository. My answers, now, would be as follows:

• If the package is not in the repository, consider a ppa (personal package archive) such as this one for Sublime Text 2 by W8, or if possible drop a prebuilt binary installed ~/opt and add a symlink to it from ~/bin as I described here in this post: Install Add On Software and Create GTK+ Desktop File.
• If the package is in the repository, but you want a different version then if the package is a python or ruby package consider using a virtualenv or rvm. This protects your system environment from differently named or different versions and possibly conflicting dependencies. For example chardet is a Requests dependency, but in ubuntu it's named something different than it is on Pypi, causing it to be installed twice and confuse everyone. Placing your off-repo version of requests in a virtualenv protects your system and avoids the conflict. Ubuntu does have a place to put your system python files, but I would almost never use it. For packages that are add-ons, I would do the same thing I did for eclipse which I described in this post: Eclipse in ubuntu.

Stick this these rules and you will always be happy! I promise!

So here's the flip. Just for kicks I tried to update numpy, stupid because (a) it includes a lot of binaries that need to be compiled, not just py code and (b) it's so mature what could possibly be in 1.6.1 that's not in 1.5.9?

So pip scream loudly on and on about this not being where it looked and this not compiling and finally, installation failed. Luckily for me it underwent all this trauma in a temp file called ~/build so my system was never altered.

Made me think though... maybe I should try some of these "experiments" on a vm so my real system won't get trashed.

distribution dilemma or package predicament

I recently installed Requests, a Python package for HTTP requests, from the Ubuntu Software Center since that's become my habit, mostly because I foolishly believe that it will handle dependencies (if there actually are any) for me properly, and because I'm too scarred or lazy to handle the sometimes recursive  requirements an installation involves on my own. The downside of this is of course that packages in the Ubuntu repository (some are on Launchad) are maintained by volunteers, not always updated and, by their very nature of being Ubuntu, will always be at least 6 months old. In the case of Requests, the version on Ubuntu and Launchpad is version 0.5.0, there's an archived page on Github, and compared to the current version 0.10.7, you can see it has come a very long way! Lamely, the next release of Ubuntu, the Precise Pangolin will have Requests 0.8.2, also archived on Github.

This is the distribution dilemma, go with the distro, old but reliable (is it really?), or go it alone. The Python hacks will say the obvious, use pip, also available on Ubuntu, not nearly as outdated, which is Python's answer to apt-get/yum, i.e.: it will take care of installing dependencies for lazy, insecure me.

What do you think? When should you break from the fold? When do you stay in the warm embrace of your distro? Obviously the answer will be different for each user and circumstance. This time, I think I'm going have to buck up and jump out of the nest.

(*) Yay! I found a happy medium. I must say pip kicks ass!
marko@myBox:~$ pip freeze
Shows me all of my installed Python packages, and there's requests and it sorry outdated state.
Now ...
marko@myBox:~$ pip install --upgrade requests
Oh that didn't work, it couldn't uninstall the old requests because permission was denied.
So try ...
marko@myBox:~$ sudo pip install --upgrade requests
Ahh, success! I love linux! And I love the smartypants who wrote Pip! Thank you!

Update (2012-04-17): (*) Well I probably won't do that again. Please see Part 3. This approach works sometimes but can cause problems, and probably isn't optimal. My initial instincts, scared and lazy, were probably best. In the future, I'll only use pip in virtualenv, with the added plus, that I don't have to remember to precede it with sudo!

Ruby Rhinestone

I'm always the last to know. Saw this on Slate:
Code School - TryRuby
How cool is that!