Moving Virtual Box VM to another host

I have Windows XP running in a Virtual Box VM. The iMac it was running on is getting intermittent screen artifacts, so time to switch machines.

I found this, which led me to believe that moving hosts is possible. The VM is named "Win XP" and has one snapshot. I mucked up the transfer the first time. These are the steps I followed the second time, which worked.

1. Moved ~/Library/VirtualBox/HardDisks/Win XP.vdi to the same location on the new host.


2. Copied ~/Library/VirtualBox/Machines/Win XP to the same location on the new host.


3. In the old VirtualBox.xml there was a HardDisk tag with the attribute location="HardDisks/Win XP.vdi" that contained a child HardDisk tag (I had one snapshot). Copied these into the new VirtualBox.xml.


4. Copied the appropriate MachineEntry tag from the old VirtualBox.xml to the new one.

The VM started up on the new host with no problems.

Also stumbled across a site with downloadable Virtual Box images.

This is how Scoodi is intended to work

I get an RSS feed of all items listed on Scoodi within 10km's of my house.

Someone posted a wanted listing for CD cases a few days ago. I had some that had been sitting in the cupboard for a long time, so I replied this morning. Since he lives in the same suburb, he walked around and has just picked them up. Nice and quick and easy.

Not only was he very appreciative, but he was also happy that he has been able to get rid of the stuff he has been cleaning out of his garage on Scoodi.

Haiku

BeOS was yet another innovative technical product that was built too far before its time and has subsequently passed away. I bought a copy in the late 90's and still have the CD lying around at home.

The BeOS legacy lives on, in the form of Mac OS X's file system metadata features and as I have just stumbled across, the open source Haiku project. It would be nice to have an open source, simple, consistent, fast but lightweight desktop operating system option.

Fun with functors

I have been slowly working through some more Haskell with help from Tony.

1. Quickly worked through the previous stuff we did to refresh my memory.


2. Consider a simplified version of the Eq type class.

   class Eq a where 
     (==) :: a -> a -> Bool

   The type variable a is polymorphic over types. Now consider the Functor type class.

   class Functor f where
     fmap :: (a -> b) -> f a -> f b

   Here we have an example of higher-order polymorphism, e.g. f a, f b. The type variables a and b are polymorphic over types as before, but f is polymorphic over type constructors. Note that f has kind * -> * as it is applied to a single type variable in both cases.


3. The Maybe type constructor has kind * -> *. We have effectively already written the Functor implementation, i.e. the mmap function in the previous work.

   class Functor' f where
     (<$>) :: (a -> b) -> f a -> f b
   
   instance Functor' Maybe where
     (<$>) = mmap



4. Observe that -> is a type constructor with kind * -> * -> *. Given two types a and b, a->b is the type of functions mapping elements of type a to elements of type b.
   
   We can't write a Functor instance for the -> type constructor as their kinds are different. However we can partially apply a polymorphic type, lets call it t which gives ((->) t) and has kind * -> *.


5. Exercise: write an instance of Functor for functions:

   instance Functor' ((->) t) where
     (<$>) = error "todo"

   Looks a little nasty when you first see it. Its a bit easier if you write out the type signature with the type constructor applied.

   <$> :: (a -> b) -> ((->) t a) -> ((->) t b)

   It is more obvious in infix form.

   <$> :: (a -> b) -> (t -> a) -> (t -> b)

   Now it is fairly easy to come up with an implementation.


6. Exercise: just for fun, write a Monad instance:

   class (Functor' m) => Monad' m where
     flatMap :: (a -> m b) -> m a -> m b
     pure    :: a -> m a
   
   instance Monad' ((->) t) where
     flatMap = error "todo"
     pure    = error "todo"

   Again writing out the type signatures helps.


7. Note the laws that all Functor instances should satisfy.

   fmap id == id
   fmap (f . g) == fmap f . fmap g

   The combination of the Functor type class and these laws define a particular concept/pattern. Intuitively function composition and the traditional map function seem like very different things, yet they are both instances of this abstraction.


8. Exercise: write an implementation for:

   (<***>) :: (Functor f, Functor g) => (a -> b) -> g (f a) -> g (f b)

   It took me a while, with help, so the answer is at the bottom of the post.

This is all well and good, but what use is it? Here are two examples of using the <***> function.

Example 1

data Connection = Connection

newtype Conn a = Conn {
  conn :: Connection -> a
}

instance Functor Conn where
  k `fmap` Conn z = Conn (k . z)

data ResultSet = ResultSet
data Person = Person

f :: ResultSet -> Person
f = undefined

executeQuery :: String -> Conn ResultSet
executeQuery = undefined

k :: String -> Conn Person
k = f <***> executeQuery

Example 2

g :: Maybe [Bool] -> Maybe [String]
g = (<***>) show

Useful references.

1. A Gentle Introduction to Haskell: 2 Values, Types, and Other Goodies


2. Functional Programming with Overloading and Higher-Order Polymorphism

Answer for 7.

(<***>) :: (Functor f, Functor g) => (a -> b) -> g (f a) -> g (f b)
f <***> g = (f `fmap`) `fmap` g

Or in point free form.

(<***>) = fmap . fmap

[shell-fu]$

shell-fu.org has lots of little command line tips and RSS feeds to keep an eye on new ones.

Tehran Times SQL Server error

Trying to view the story Israel is committing a holocaust in Gaza: Norman Finkelstein via Google News.

Why Haskell?

I was catching up with a friend recently after some years and I talked about how I now preferred programming in Haskell. He didn't know much about Haskell, so he asked my why. On the spur of the moment I didn't give him a good answer, so that got me thinking afterwards. Why do I prefer Haskell and how do I convey it concisely to a mainstream programmer (e.g. Java)?

I think it is a largely pointless exercise to try and have a useful discussion on the benefits/issues of these languages if you haven't at least had experience in functional programming. I had come from years of mainstream imperative programming, with no functional exposure and it took me significant time and effort to unlearn many things I had internalised and get a basic grip on Haskell. It is a fundamental mind shift. I have observed a number of other people, some very talented developers, go through a similar experience.

So perhaps it is best to offer some personal observations on my own programming experiences, simply to pique curiosity. Hopefully it will motivate further investigation.

• I am not some super programmer - there are other people far better than me. However it is uncanny how often my Haskell code "just works" once it compiles, compared to my experiences with Java over the years.


• Generics in Java are useful, but cumbersome and limited. Haskell takes parametric polymorphism (aka Generics) to a whole new level.


• A Haskell program is made up of functions and values, all of which have a type. These types are expressed more concisely than in Java and they provide valuable clues on recurring patterns that can be "refactored" to reduce duplication.


• Types are such a useful description for functions/values, that I find myself thinking in terms of assembling types so that they all fit together correctly. It can be a little like putting together conventional rectangular Lego blocks, where you might want a 2x4 thick block, and you know you need a 4x4 flat piece next, etc.


• When I sit down to right some code in Haskell, I find I tend to think more deeply about what it is I am really expressing. Not sure I can clarify that sufficiently, but I think it may be more concern for underlying structure, relationships and patterns.

Like many things, not all is rosy.

Be warned though. If you make the effort to learn Haskell and become familiar enough to find the abstractions, type system and brevity useful, coming back to Java is an unpleasant experience.

Finally, while writing this I happened across a related interview: Bryan O'Sullivan on the Power of Haskell.

Google Docs

Recently I have started using Google Docs. Before that, all my docs were stored in Git and I was reasonably happy with that system.

Reasons for changing:

• Technical complexity. My system using Git is not suitable for the non-technical members of my family.


• No syncing now. I move around several trusted computers, each with a clone of my Git docs repository and the master repository is encrypted on a USB memory stick. Finding the USB stick, mounting the encrypted disk image and syncing the repository was not difficult or too time consuming, but it was inconvenient.


• Version diffs. I never did it, but if I wanted to compare versions of a spreadsheet/document then that would probably be a manual process with the old system as they are stored as a binary file (OpenOffice) on the filesystem.

I had a quick look at Google's competitors - Zoho and ThinkFree. Zoho has many applications, probably with more features than Google, e.g. the Equation Editor with LaTeX support, although it doesn't have a built-in PDF viewer like Google. One day I should investigate it further. ThinkFree looked more specialised and complicated, like MS Office, so I didn't sign up and trial it.

Issues with Google Docs that I have encountered so far:

• Only upload single files. I wish I could select multiple files to upload at a time.


• PDF versioning. I can't find a way to replace a PDF with a new version and have that history.


• Sharing folders. You can't share a folder of documents, you must select the files and share those. Collaborators also only see the individual files, not the folder structure that they have been organised in.


• Invitation email address. When a sharing, invitation email is sent, it comes from your gmail.com address, irrespective of your Gmail settings (Accounts -> Send mail as). I don't know whether Google Apps solves this.

I still need to put a backup strategy in place, i.e. periodically download a copy of my documents. Not sure if the Google Gears offline support will be an easy way to achieve that.

Null in Java

Following on from the previous post, two papers about null in Java. Found both in these comments.

The Introduction of the paper Much Ado About Nothing: Putting Java’s Null in its Place provides a good, very readable description of the issues with null in Java. From the Abstract:

The ubiquity of null in object-oriented programs leads to severe engineering problems for programmers. First, the error messages issued by the run-time checks are typically not sufficiently informative to help the programmer find the source of the error. Second, the type systems in OO languages generally do not distinguish null from other values of (object) type, preventing the programmer from stating important invariants about the flow of null in the type system. Third, programmers’ standard use of null as a sentinel does not unambiguously represent failures. To resolve or avoid these ambiguities, component authors must incorporate additional complexity into their interfaces, and this complexity can lead to subtle bugs.

As a side note, there is an existing implementation of Maybe in Java, as Option in Functional Java.

I have only skimmed the paper Non-Null References by Default in Java: Alleviating the Nullity Annotation Burden. This is an empirical study of null in 5 open source Java projects. The Abstract states:

The results allow us to confirm that in Java programs, at least 2/3 of declarations of reference types are meant to be non-null, by design. Guided by these results, we propose a new non-null-by-default semantics. This new default has the advantages of better matching general practice, lightening the annotation burden of developers and being safer.

Tony Hoare - "Null References: The Billion Dollar Mistake"

Abstract: I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.

Tony is giving this presentation in the Historically bad ideas track at QCon London 2009. The other presentations look like they pale in comparison. He gets my respect (beyond his other accomplishments) for doing such a talk.

Found here.