I’m taking part in National Novel Writing Month this year along with Saf. We shall not see each other for the next month, I imagine, as we immerse ourselves in, respectively, mythology and murder. Since the Nano—as I believe the cool kids call it—website has the facility for uploading cover art, I procrastinated a bit in my lunch break yesterday and came up with this:
Just a little post quoting NASA’s science fail in one of its news items.
Shutting down this heater is expected to save 250 watt-hours of power per Martian day.
It makes me despair. It really does…
A couple of times in the past few months I’ve noticed a new illness sweeping the Web: shot blot. Today I came across another example. This screenshot has, at the bottom, a round fuzzy black blob. I’ve noticed other screenshots lurking around the web with this affliction.
Using my awesome skills of a Doctor, I’m going to propose a likely cause: The GIMP. Suppose you’ve just opened the GIMP, hit the ‘Acquire Screenshot’ button and been presented with a window containing the contents of your screen for cropping. You move over the image and click to focus. But wait! The image window is already focused and, due to the GIMP now having the paintbrush tool as the default selected tool, you inadvertently place a small, easily missed blob on your image.
This particular quirk does seem to be triggered on a non-trivial number of occasions. Yes, dear reader, these will in most cases have passed you by but now you will notice each and every occurrence. I thought I should share the pain :).
I had a play with installing the RoundCube webmail system on my server yesterday and was pretty impressed. It does seem to do what it says on the tin and act as a AJAX-y web front end to an IMAP server.
This encouraged me to place my web developer hat[0] upon my head and have a ponder. “Surely JavaScript » Some XML-y RPC » PHP » IMAP » My Mail and the associated return path is somehow sub-optimal, requiring, as it does, two separate servers on my email hosting box”, says I to myself. “Not to mention the overhead of said box talking IMAP to itself!” I added.
Astonished that such a sentence could emerge from my mouth, abusing, as it does, a French punctuation symbol, I started Googling around for an IMAP-like protocol which was more RESTful. Perhaps I should explain at this point that RESTful is the Web 2.0 buzzword du jour for ’sensible API for accessing stuff over the web, innit’. The Big Idea I had was making the mail reader truly just a hunk of HTML + JavaScript which could access the mail directly.
I failed to find such a (public) API. Do please link in comments if my Googling was insufficient.
Then I stumbled upon a description of the Maildir on-disk mailbox format which my IMAP server was getting all the mail from and it struck me that, actually, the Maildir format itself is RESTful. It certainly ticks many REST boxes:
This set me wondering. Assuming I have some appropriately cunning Apache config which lets me access my Maildir via WebDAV under something like http://example.com/~user/mail/…, would this be sufficient to write a mail reader[2] entirely in HTML + JavaScript? I am far to busy to actually investigate this myself but the idea is almost irresistible to my mind.
[0] A funky little beret naturally!
[1] Well, locking handled by the file system anyhow. It has been pointed out that there are some conditions where Maildirs are not the panacea they appear in this regard but for the purposes of this discussion I’ll stick my fingers in my ears about it.
[2] Reading. i.e. without the actual sending mail part.
Update: So it appears that one of the protocols Exchange and Outlook speak for exchanging emails is WebDAV. Great minds…
<rant>
Sometimes I hate Python. For reasons which we need not go into here (but which are, in themselves fairly sensible), object destructors in Python are not guaranteed to be called. This matters less for a language like Python where it is the Interpreters Problem to free resources but does matter for C++ bindings to Python. Firtree has a nice little debugging feature built into it’s reference counting mechanism. Should the program terminate and there still be objects with non-zero references, it prints a list of them so you can try and diagnose/cure memory leaks.
Annoyingly this means that every so often my Python program spits out a dire ‘MEMORY LEAK’ warning. On the upside this does mean that I have to actually care about resource management. On the downside, it means that I have to actually care about resource management.
</rant>
Update: Here is a concrete example:
#!/usr/bin/env python
import gc
class Good:
def __del__(self):
print('goodbye, good [%s]' % self)
def __init__(self, object_of_interest):
self._interesting = object_of_interest
print('hello, good [%s]' % self)
class Bad:
def __del__(self):
print('goodbye, bad [%s]' % self)
def __init__(self, object_of_interest):
self._interesting = object_of_interest
if(object_of_interest != None):
object_of_interest.set_parent(self)
print('hello, bad [%s]' % self)
def set_parent(self, parent):
self._parent = parent
good_a = Good(None)
good_b = Good(good_a)
bad_a = Bad(None)
bad_b = Bad(bad_a)
## oh, how I wish it would...
gc.collect()And the output:
rjw57@vega:~/bzr/firtree-playground$ python refcheck.py
hello, good [<__main__.Good instance at 0x7f278d409098>]
hello, good [<__main__.Good instance at 0x7f278d4090e0>]
hello, bad [<__main__.Bad instance at 0x7f278d409128>]
hello, bad [<__main__.Bad instance at 0x7f278d409170>]
goodbye, good [<__main__.Good instance at 0x7f278d4090e0>]
goodbye, good [<__main__.Good instance at 0x7f278d409098>]