Alessandro Vermeulen

Alessandro Vermeulen's blog about languages, programming, Computer Science, photography and the Web.

Why You Should Switch to Declarative Programming

| Comments

We are reaching limits of what is feasible with imperative languages and we should move to declarative languages.

When applications written in imperative languages grow, the code becomes convoluted. Why? Imperatively programmed applications contain statements such as if X do Y else do Z. As Y and Z contain invisible side-effects the correctness of the program relies on some implicit invariant. This invariant has to be maintained by the programmer or else the code will break. Thus each time a new feature is added to an application or a bug is fixed the code for the application gets more complex as keeping the invariant intact becomes harder. After a while the code becomes spaghetti-code and bugs are introduced as the programmer fails to maintain the invariant. This is going to happen despite the best intentions of the programmer to keep things clean. Why is this?

Software and Building Architecture Compared

| Comments

People tend to only understand what they can see. For most people it is difficult to grasp more abstract matters without somehow visualizing them. Software is an example of such an abstract matter. Let us visit the process of developing software through a comparison with developing a building.

JCU App Installation Script

| Comments

With this script it should be possible to install and build the JCU app in a local directory. It does not build the UHC for you. If that is wanted the option could be build in of course!

Getting Rid of Programming JavaScript With Haskell

| Comments

For my Experimentation Project at Utrecht University I ported the “JCU” application to Haskell. The JCU application is used to give Dutch High school students the opportunity to taste Prolog.

The project uses the Utrecht Haskell Compiler and its JavaScript backend. The UHC translates Haskell to Core and then translates this Core language to JavaScript. For more information on this see the blog of the creator of the UHC JavaScript backend.

Please read my report on this project. The project is hosted on GitHub in the following repositories:

Incomplete proof in the HS JCU App Complete proof in the HS JCU App

update 28-01-2012: The keyword jscript in the UHC has been changed to js in order to avoid association with Microsoft’s JScript. Also new Object syntax is now available in the foreign import directives.

1
2
foreign import js "new Object()"
  newObject :: IO (JSPtr a)

A Transition to Static Site Generation

| Comments

Today I’ve launched my new blog. It is based on Octopress and works by statically generating the pages and then syncing them with the server.

If you are for example on OS X Lion and installed XCode 4.2 and you run into weird errors like a missing gcc-4.2, and Homebrew throws errors like this:

Error: The linking step did not complete successfully The formula built, but is not symlinked into /usr/local

Please install the gcc package from this nice fellow: osx-gcc-installer

And if you are getting nagged by rb-fsevent. Change

Gemfile
1
  gem 'rb-fsevent'

to

Gemfile
1
  gem 'rb-fsevent', "0.9.0.pre4"

Update The comments have been exported with the Wordpress plugin to Disqus. I’m currently looking at how to highlight code within Disqus comments.

Caching Hackage

| Comments

On several occasions I noticed that when performing a cabal update that the index was being downloaded at the rate of plus min 300 KB/s. Finally I got around to do something about this. I’ve set up a caching server located in Utrecht, The Netherlands. It is a caching proxy for the hackage repository. If you want to use it, add the following to your ~/.cabal/config file. (Or equivalent on Windows.)

1
remote-repo: cache:http://spockz.nl:12080/packages/archive

Be sure to comment out the already existing remote-repo. Otherwise, cabal will download both indexes and merge them, and we don’t want this.

The funny bit

Apparently this only helps if your machine is fast enough to process the index (untarring and all extra administration cabal performs).

Plainly getting the file from the cache:

1
2
3
4
> wget http://spockz.nl:12080/packages/archive/00-index.tar.gz
Saving to: 00-index.tar.gz
100%[======================================>] 3.394.821   10,9M/s   in 0,3s
2011-11-13 00:12:35 (10,9 MB/s) - 00-index.tar.gz saved [3394821/3394821]

And running cabal update with my cache as source:

1
cabal update -v3  7,50s user 0,21s system 99% cpu 7,736 total

And then finally, with the original repository:

1
cabal update -v3  7,57s user 0,25s system 28% cpu 27,372 total

So here we see that the user time is roughly the same but you spent almost three times more seconds waiting for your coffee to get cold. Any further speed improvements for cabal update will probably require optimalisation of the code.

The caching server

I’m using Varnish to cache the request to hackage. And here is my config file. Please shoot if you see any improvements.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
# This is a basic VCL configuration file for varnish.  See the vcl(7)
# man page for details on VCL syntax and semantics.

backend backend_0 {
	.host = "hackage.haskell.org";
	.port = "80";
	.connect_timeout = 0.4s;
	.first_byte_timeout = 300s;
	.between_bytes_timeout = 60s;
}


acl purge {
  "localhost";
	"hackage.haskell.org";
}

sub vcl_recv {
    set req.grace = 120s;
    set req.backend = backend_0;

		set req.http.host = "hackage.haskell.org";

    if (req.request == "PURGE") {
        if (!client.ip ~ purge) {
            error 405 "Not allowed.";
        }
        return(lookup);
    }

    if (req.request != "GET" &&
        req.request != "HEAD" &&
        req.request != "PUT" &&
        req.request != "POST" &&
        req.request != "TRACE" &&
        req.request != "OPTIONS" &&
        req.request != "DELETE") {
        /* Non-RFC2616 or CONNECT which is weird. */
        return(pipe);
    }

    if (req.request != "GET" && req.request != "HEAD") {
        /* We only deal with GET and HEAD by default */
        return(pass);
    }

    if (req.http.If-None-Match) {
        return(pass);
    }

    if (req.url ~ "createObject") {
        return(pass);
    }

    remove req.http.Accept-Encoding;

    return(lookup);
}

sub vcl_pipe {
    # This is not necessary if you do not do any request rewriting.
    set req.http.connection = "close";

}

sub vcl_hit {

    if (req.request == "PURGE") {
        purge_url(req.url);
        error 200 "Purged";
    }

    if (!obj.cacheable) {
        return(pass);
    }
}

sub vcl_miss {

    if (req.request == "PURGE") {
        error 404 "Not in cache";
    }

}

sub vcl_fetch {
    set beresp.grace = 120s;

    if (!beresp.cacheable) {
        return(pass);
    }
    if (beresp.http.Set-Cookie) {
        return(pass);
    }
    if (beresp.http.Cache-Control ~ "(private|no-cache|no-store)") {
        return(pass);
    }
    if (beresp.http.Authorization && !beresp.http.Cache-Control ~ "public") {
        return(pass);
    }

}

sub vcl_deliver {

}

lhs2TeX-hl Version 1.4.5 Has Been Released!

| Comments

I’ve just released a new version of lhs2TeX-hl: 1.4.5 and it includes some new features:

  1. Added support for recursively traversing includes of .lhs files
  2. The program now doesn’t fail completely when haskell-src-exts fails to parse a file. An error is reported and the program continues. :) A fmt file is still generated.
  3. functions that aren’t functions but constants are now given the tag `constant’
  4. Removed a faulty command from the list.
  5. Cleaned up some code. (Probably introduced other ugly code)
  6. Binary operators are now typeset better. (I hope :))

Please let me know what you think.

Installing Vacuum-cairo With the Help of HomeBrew

| Comments

I tried installing vacuum-cairo on OS X 10.6 but it failed. With the help of HomeBrew I installed the dependencies by doing the following:

Be sure to run brew update first.

Then install the dependencies:

1
2
3
4
5
6
brew install pkg-config
brew install glib
brew install librsvg
chmod u+w /usr/local/Cellar/gdk-pixbuf/2.23.5/lib/gdk-pixbuf-2.0/2.10.0/loaders.cache
brew install librsvg
brew install pango

Note the installing of librsvg twice, this is in accordance with https://github.com/mxcl/homebrew/issues/4970. If you don’t get an error after running the first install of librsvg you might have a new update brew of librsvg.

And finally install vacuum-cairo:

1
cabal install vacuum-cairo

Applescript Script to Emulate the Behaviour of the `start’ Command in the Windows CMD Prompt

| Comments

People have asked me how to launch a program through the terminal in the background but with it’s own terminal screen similar to the way the “start” command in the Windows CMD prompt works. Well here it is. Add the following two files (start.applescript) and start to your path, and make them executable (chmod +x {start.applescript,start}).

One point of notice is to always encapsulate strings with spaces that should be one parameter in quotes.

Copyright © 2013 - Alessandro Vermeulen - Powered by Octopress