Positioning issues with Colorbars in Matplotlib

I ran into a problem with some Matplotlib code the other day: clearing a figure that previously held a Colorbar would still keep empty space in the location of the now-removed Colorbar.

In other words, after removing the Colorbar from a figure, the figure would not shift back to its full width. And adding a colorbar afterwards would decrease the width of the figure even further, so the problem would compound.

Thankfully, I happened across a Stack Overflow answer that addresses this problem with the following code:

self.figure.delaxes(self.figure.axes[1])
self.figure.subplots_adjust(right=0.90)  #default right padding

This solution is inherently hacky, but does its job well. If you execute that code after clearing a figure (self.figure.clf()), the figure will shift to the right, returning to its original width before the creation of the Colorbar.

Also, if you are plotting multiple graphs in the same figure, I recommend keeping global handles to the figure, to the current axes, to the current Colorbar (if it exists), and to other graph elements. With that design, updating the figure requires only modification of those handles and a call to draw(), and you can fix the Colorbar positioning problem by checking to see if its handle is defined before you plot a new graph and correspondingly executing the removal code.

Extending and resizing partitions in VirtualBox VDIs

Resizing partitions in VirtualBox virtual disk images can be painful - in some cases, they don’t work as expected. For instance, I had a working Ubuntu VM where the partition on which the OS was installed reached its size limit. Here’s what I did:

1. If there is not enough unallocated space in the VDI, download the CloneVDI tool and make a cloned version of your VDI with as much more space as is needed.

2. Download the GParted live CD and boot into GParted from your VM.

3. Try to do an in-place resize of the partition you want to extend into the area of unallocated space - if that works, you’re done!

4. If that doesn’t work, delete your linux-swap partition, and move your extended partition to the left of the available space.

5. Move your main partition to the left, too, and grow it to the desired size to the right.

6. Create new linux-swap logical partition to replace the one you deleted earlier.

The key to this procedure is moving the partitions left. Without doing that, you won’t be able to resize the main partition.

An alternative, but more risky procedure is to expand your VDI with CloneVDI so that you can create an entire new parition with the desired size. Then, copy the contents from your original partition to the new old in GParted and set the “boot” mark to the new one. When I tried that, however, I lost my master boot record in the process and had to reinstall my Grub bootloader and configure it to mount Linux, which is an ugly process (I might write up the details in another post).

Local Git sharing with a virtual machine

My recent projects have involved work between two OSes. I run Windows as my host OS and virtualize Ubuntu, and in order to share work efficiently between the two, I’ve been using a local bare Git repository in a shared folder.

It’s quite simple to set up:

First, make sure that you have a shared folder that is available to both your host and your guest OS. I personally use VirtualBox’s Guest Additions and its built-in Shared Folders functionality, so I mount my share using the following command, where “share” is the name of the shared folder I have defined in VirtualBox, and “~/host” is the path to which I am mounting:

sudo mount -t vboxsf share ~/host

Now, initialize a bare Git repository in the shared folder:

cd "~/host"
mkdir myrepo
cd myrepo
git init --bare

Almost done. Return to your original repository and add to its remotes:

git remote add local "~/host/myrepo"
git push local master

Finally, clone that repository from your other OS:

git clone "C:\vmshared\myrepo"

Now, you can git push and git pull between your repository on the host OS and your repository on the guest OS to synchronize changes.

Recovering from SugarSync merge failures over source control repositories

Intro to SugarSync (SS)

Ever since I started using SugarSync, I’ve loved the app. Until now, it’s proven to be easy to use and abnormally straightforward.

However, this weekend, SugarSync Manager decided to start crashing upon each load, making it completely unusable. I ordinarilly would have attempted to find and fix the cause of these crashes, but since the app was due for an update anyway, as I had neglected to run SugarSync (and sync latest changes) for a while, I decided to reinstall the Manager completely.

Problem

That turned out to be a bad decision. For some reason, I wasn’t able to explain to SugarSync that the original device that had synced to my account is the same as the current device, so it treats them as different entities with the same device name. Instead, I decided to try SugarSync’s merge functionality - as the people at SS explain it, it looks for differences between the older (in this case) version synced and the newer (in this case) version available on the current device.

I did not expect this to be a problem, but SugarSync decided to start merging within the .hg and .git directories of my hg and git repositories. Thus, old dirstates and other key files were transformed to the version they had been at an earlier time.

Solution

My folder structure looked someting like this for “infected” files:

• _Handwriting (from Maxim-laptop).i // this is the newest one
• _Handwriting.i // this is the older one, but takes the place of the latest one.

After countless bouts with HG in order to fix this via the HG tools, I decided to instead write a simple program that renames files in order to enable this to work.

File changes:

1. _Handwriting.i –> _Handwriting.i.old
2. _Handwriting (from Maximlaptop).i –> _Handwriting.i

If you run into this problem and just want a binary, here is the Windows, .NET 4 binary.

Facebook's New Niche

Note: This is a repost of a post from my old blog. It was originally published on September 24, 2011.

In the midst of Facebook’s widly-discussed UI changes this week, one new feature fell through the cracks: the Timeline (currently only in developer beta, but you can be involved by following these steps).

This new Timeline feature solves a major UI problem that Facebook has been plagued by – the disorganization of each user’s content. The previously-separate Wall, Info, Photos, and so on have all been combined into a single, centralized profile page. But the timeline goes beyond that. In displaying your entire Facebook activity over time, it also allows you to add “life events”, from achievements to medical events to anything, really.

By now, you’ve probably realized that these features don’t just show your entire Facebook activity – they’re meant to show your entire life.

(Note: Sure, this situation is interesting in terms of privacy, but let’s just assume that people will be willing to share the events of their lives. So far, they have been pretty willing.)

The main thing going for Facebook here is how much information they have. Besides sharing information, users give Facebook a ton of personal data. They’ve finally started using this data for more than just targeted advertising; for example, the timeline has a map page that tracks your activity, intersecting place information with status updates and more.

Life-tracking might be Facebook’s niche. Google+’s focus is sharing, not identity creation. In terms of user identity, G+ certainly aims to consolidate your web activity under one profile. But Facebook doesn’t have the web – instead, they combine activity on their site (status updates, photos, places, and now app activity via Open Graph) with the life events you input. In a way, Google+ and Facebook aren’t currently competing in that realm, although Google might certainly try to follow Facebook. If anyone could do something like that best, it would be Google, specifically because of how much we rely on their services in our lives and how much information we have about ourselves on the web.

Hopefully, this timeline feature won’t be treated as just another annoying Facebook redesign. It has the potential to change the way we approach the Internet and collect our online identities. Facebook has been making dumb moves lately – but this might be their killer app.