fire upon the deep unix timestamps are NNNNN bits

Vernor Vinge talks about people still using unix timestamps in his future universe.

Unix timestamps, when stored in fixed width fields, run out of bits. 32 bits runs out in 2038: the year 2038 problem.

I wondered how many bits would be needed to be to represent timestamps in his future.

Vinge is not very clear when his novels are set. Someone on slashdot thinks 38000 years from now.

Well, the next obvious size up from 32 bits is 64 bits. And wikipedia says that will run out in the year 292,277,026,596. Which seems far in advance of Vinge's future.

I was hoping the answer would be cooler than that. But 64 bits seems to be enough.

machine ordering restaurant

I went to a sushi restaurant in Brisbane which used touch screens for ordering. That was pretty nice for ordering a few things at once without having to interact with a human being (something hackers hate to do...).

It reminded me of a place like that I went to near Red Square in Moscow, which was an internet cafe/pub. Unfortunately, that place had a bug: it de-duplicated your order so that you didn't accidentally order the same thing twice. But that meant it was difficult to order pint after pint after pint - it detected all but the first as duplicates; and worse, silently discarded the subsequent orders rather than telling you.

commandline RSS->text tool using Haskell arrows

I wanted barwen.ch to display news updates at login. I already have an RSS feed from the drupal installation on the main page; and that RSS feed is already gatewayed into the IRC channel. So that seemed an obvious place to get news updates.

I wrote a tool, rsstty, to output the headlines to stdout. Then, I wired it into the existing update-motd installation to fire everything someone logs in.

So you can say:

$ rsstty http://s0.barwen.ch/rss.xml
 * ZNC hosting(Thu, 01 Mar 2012 10:09:15 +0000)
 * finger server with cgi-like functionaity(Wed, 22 Feb 2012 18:43:08 +0000)
 * Welcome, people who are reading the login MOTD(Fri, 17 Feb 2012 23:56:44 +0000)
 * resized and rebooted(Wed, 25 Jan 2012 12:23:39 +0000)
 * One time passwords (HOTP/TOTP)(Wed, 18 Jan 2012 11:33:45 +0000)

I wrote the code in Haskell, using the arrow-xml package.

arrow-xml is a library for munging XML data. Programming using it is vaguely reminiscent of XSLT, but it is embedded inside Haskell, so you get to use Haskell syntax and Haskell libraries.

The interesting arrow bit of the code is this. Arrow syntax is kinda awkward to get used to Haskell and sufficiently different from regular syntax and monad syntax that even if you know those you have to get used to it. If you want to get even more confused, try to figure out how it ties into category theory - possibly the worst possible way to learn arrows ever.

But basically, the below definition make a Haskell arrow which turns a url (to an RSS feed) into a stream of one line text headlines with title and date (as above)

> arrow1 urlstring =
>  proc x -> do
>   url <- (arr $ const urlstring) -< x

This turns the supplied filename into a stream of just that single filename. (i.e. awkward plumbing)

>   rss <- readFromDocument [withValidate no, withCurl []] -< url

This uses that unixy favourite, curl (which already has Haskell bindings), to convert a stream of URLs into a stream of XML documents retrieved from those URLs - for each URL, there will be one corresponding XML document.

>   item <- deep (hasName "item" <<< isElem) -< rss

Now convert a stream of XML documents into a stream of <item> XML elements. Each XML document might have multiple item elements (and probably will - each RSS news item is supplied as an <item>) so there will be more things in the output stream than in the input stream.

>   title <- textOfChild "title" -< item
>   pubdate <- textOfChild "pubDate" -< item

Next, I'm going to pull out the text of the <title> and <pubdate> child elements of the items - there should be one each per item

>   returnA -< " * " ++ title ++ "(" ++ pubdate ++ ")\n"

When we get to this point, we should have a stream of items, a stream of titles corresponding to each item, and a stream of pubdates corresponding to each title. So now I can return (using the arrow-specific returnA) what I want using regular Haskell string operations: a stream of strings describing each item.

The above arrow is wrapped in code which feeds in the URL from the command line, and displays the stream of one-line news items on stdout.

The other interesting bit is a helper arrow, textOfChild which extracts the text content of a named child of each element coming through an XML stream. Each part of this helper arrow is another arrow, and they're wired together using <<<. To read it, imagine feeding in XML elements at the right hand side, with each arrow taking that stream and outputting a different stream: first each element is converted into a stream of its children; then only the element children are allowed through; then only the elements with the supplied name; then all of the children of any elements so selected; and then the text content of those. (its quite a long chain, but thats what the XML infoset looks like...)

> textOfChild name =
>  textNodeToString <<< getChildren <<< hasName name <<< isElem <<< getChildren

--

program a little bit every day

Something I've been trying for the last year or so is to make sure that I program a little bit every day.

I've seen lots of my friends drift upwards into management or other fields, where their default program becomes Word or Powerpoint rather than vi.

I've seen other people already in a management position when I met them, desperate to hack on things rather than manage things, but finding time to do it.

Having seen all that, and eventually realising what I saw, I became fearful that the same would happen to me.

So I started trying to program a little bit every day, at least on workdays.

The rules are pretty simple: I try to edit some code, compile and run it.

Often, I'm being paid by someone to write code for them. That makes things real easy. Not only to do I get my resolution done, but I get a wad of money too.

Sometimes I don't - perhaps because I've spent a day on paperwork, on design documentation, on configuring things, on phoning other people to find out why shit is broken.

In those cases, I have to make time to program. Sometimes the change I make is as small as renaming a variable I didn't like. Or rephasing an error message.

But the important thing is that it keeps me touching a programming editor (vi in my case, but whatever) and compiling stuff and running it and testing it, every day. Stopping me falling down the slope of "its been N days since I last programmed" which seems so easily to become "its been N years since I last programmed".