The Pleasure of Finding Things Out

Tuesday, January 11, 2011

Merging Two Google Calendars

I regularly use Mail for Exchange to sync my phone with my Google Calendar account. It's awfully useful but there's one catch : you can't set it up to sync with two google calendars. It'll always sync only your primary calendar.

Now, I have a personal calendar with entries for my classes etc. Apart from that, I have also subscribed to another public calendar for keeping track of the activities organized by various clubs of IISER Kolkata. But the default-calendar-only policy of Mail for Exchange meant I was unable to get the second calendar to sync with my phone.

I googled for finding some solution for the issue, but it didn't yield any useful information. I had almost given up when I came across a not so well-known service from google called Google Apps Script. As the name suggests, It lets you run scripts written in JavaScript on google's server and the script can access many of google's popular services, including calendar.

That solved my problem completely. All I needed was a script which will add all the events of the second calendar to the primary calendar, with some background checks to avoid adding duplicate entries. That was pretty easy: as per google's standards, the documentation was excellent, with ample examples too. So I had a working version of the script ready within very little time.

The code:

function sync() {

var id="i0oa77ome1sh58gf5tq0ke9teg@group.calendar.google.com"; //id of the secondary calendar
      
  var cal=CalendarApp.getCalendarById(id);
  var today=new Date();
  var enddate=new Date();
  enddate.setDate(today.getDate()+30);
  var events=cal.getEvents(today,enddate);

}
  Browser.msgBox("added all"); 
}

You can add triggers for the script as well. I added a daily trigger, so it will run once a day and sync the secondary calendar. Problem solved!

Thursday, July 8, 2010

Tab completion in the python interpreter

Since I program mostly in python, I spend a lot of time in the default python interpreter of my distro. I even use it as a replacement for bash quite often - mainly because of python's excellent string manipulation capabilities and well, I confess, also because bash's syntax always baffles me (especially the if statements). So whenever I get stuck with some bash code, I take the escape route of opening up the python interpreter.

But the default python interpreter that comes bundled with most linux distros (and also the OS X), lacks a killer feature of bash: tab completion. One can find this feature in some python interpreters like bpython, but they sometimes overdo it (popping up suggestions even when one doesn't want them, for example).

Anyway, I recently learned from this excellent blog post by Matthias Friedrich that it is REALLY easy to add tab completion in the python interpreter: all one needs to do is import rlcompleter and readline modules of python and assign a completer key (Tab is the most natural choice, of course). The blog post I linked above also describes how to set the PYTHONSTARTUP environment variable so that tab completion is enabled every time the interpreter is opened.

Since python's readline module uses the same GNU readline utility used by bash for tab-completion, it should be just as much fun, right? Well, that's not quite the case. Because tab completion imposes a severe restriction on you here: you cannot use the Tab key for indenting your code anymore. And using single space for python's code indentation is a very bad idea: trying to distinguish between different indentation levels in heavily nested code blocks is a trouble not worth taking even for sake of the benefits given by tab completion.

Anyway, I figured out a way to circumvent the problem by looking at these lines in the source code of the rlcompleter module (The file in question is /usr/lib/python2.6/rlcompleter.py for Debian and Ubuntu): class Completer: def __init__(self, namespace = None): """Create a new completer for the command line. Completer([namespace]) -> completer instance. If unspecified, the default namespace where completions are performed is __main__ (technically, __main__.__dict__). Namespaces should be given as dictionaries. Completer instances should be used as the completion mechanism of readline via the set_completer() call: readline.set_completer(Completer(my_namespace).complete) """ if namespace and not isinstance(namespace, dict): raise TypeError,'namespace must be a dictionary' # Don't bind to namespace quite yet, but flag whether the user wants a # specific namespace or to use __main__.__dict__. This will allow us # to bind to __main__.__dict__ at completion time, not now. if namespace is None: self.use_main_ns = 1 else: self.use_main_ns = 0 self.namespace = namespace def complete(self, text, state): """Return the next possible completion for 'text'. This is called successively with state == 0, 1, 2, ... until it returns None. The completion should begin with 'text'. """ if self.use_main_ns: self.namespace = __main__.__dict__ if state == 0: if "." in text: self.matches = self.attr_matches(text) else: self.matches = self.global_matches(text) try: return self.matches[state] except IndexError: return None When one presses the completion key the function complete(self, text, state) defined in line#29 is called with the word being typed as it's second argument. I simply added an extra elif after the 42nd line asking it to return '\t' if the argument consists of only whitespaces: elif text.strip()=='': self.matches = [text+'\t'] So, now I have all the goodness of tab completion without losing the ability of using tab for code indentation!

Tuesday, July 6, 2010

Weird rounding-off bug in WebKit

I ran into this weird problem while I was writing the css for my personal website. There is a navigation bar in the page with 7 links inside a <div> sitting side-by-side:

I specified the width of the first six links to be 14% and the that of the last one 16% in the css. All the paddings, margins and borders were set to zero. So, they seven links should take up the entire width of the containing <div>, right?

Well, in webkit based browsers (I checked in Google Chrome for linux and Safari in Mac OS X leopard), that sometimes just would not happen: the total width of the seven links would fall short of the total width of the containing <div> by just a few pixels and there would be an annoying narrow strip showing the background color of the <div>.

More surprisingly, on resizing the browser window, sometimes the strip would go away and sometimes it would come back again. Firefox and opera didn't have any such problem rendering the page, though.

Now, I am no specialist in web designing. But still my common sense says that as long as 6*14+16 is 100, no such strip should be there. What the hell is going on?

Luckily, I found the answer while fiddling with the excellent Developer Tools of the Chrome browser. The widths computed by Chrome were:

Element	Computed width	Intended width
Container <div>	1013	-
First 6 <a>'s	141	1013*0.14=141.82
The last <a>	162	1013*0.16=162.08

Yes, webkit is taking the integer parts of the floats while computing the widths of the elements, instead of rounding off properly to the nearest integer. Therefore it's no wonder that for certain values of the width of the containing <div>, the sum of the widths of the child elements isn't adding up to the width of the parent.

I later found out that this bug has been reported in WebKit Bugzilla almost 5 years ago and hasn't been resolved yet. The bugzilla page doesn't even indicate that anybody ever tried to fix this crucial flaw capable of ruining the appearance of many webpages single-handedly.

Anyway, I wrote a few lines of javascript to make sure that the site renders correctly in chrome and safari and it's working just fine. It's really annoying though, being forced to use javascript to compensate for a rendering engine's shortcoming in this era of standards-compliant browsers. I shudder to imagine what I would encounter when I finally test the site in IE.