Valgrind on Mac OS X (10.10) Yosemite

The trunk version of valgrind seems to be compiling properly on Mac OS X (10.10.2), Xcode 6.2.

Here’s my self-explanatory build script:

#! /usr/bin/env bash

mkdir -p buildvalgrind
cd buildvalgrind
svn co svn:// valgrind
cd valgrind
./configure --prefix=/usr/local
make && sudo make install

# check that we have our valgrind installed
/usr/local/bin/valgrind --version

UPDATE: r15088 works for Xcode 6.3 commandline tools. r14960 as shown in the build script above only works for Xcode 6.2 commandline tools. Julian Seward (the valgrind creator himself) gave me the heads-up.

svn diff -c15088
--- (revision 15087)
+++ (revision 15088)
@@ -154,7 +154,7 @@
# Note: m4 arguments are quoted with [ and ] so square brackets in shell
# statements have to be quoted.
case "${is_clang}-${gcc_version}" in
- applellvm-5.1|applellvm-6.0*)
+ applellvm-5.1|applellvm-6.*)
AC_MSG_RESULT([ok (Apple LLVM version ${gcc_version})])

P.S.: This is an update to the original post here

Managing Cabal sandbox environment

Cabal is the defacto build tool for building packages in the haskell universe. Unfortunately, it was not designed to be a package manager for haskell and has some limitations. The most recent improvement to cabal was the introduction of cabal sandboxes, which goes a long way to help haskell developers avoid the infamous cabal hell.

Still, the utilities for cabal sandbox are generally rough on the edges, so here’s a few shell functions and wrapper functions I have written to make it easier to automate the management of cabal sandbox environment –

It works much like python’s virtualenv/virtualenvwrapper, you can easily switch to a particular cabal environment with a single command and set your cabal sandbox’s bin directory into your `$PATH`.

A few convenient wrapper functions like `ghcis`, `ghc` and `runhaskells` (notice the “s”) also help us avoid specifying the `-package-db` flag everytime we want `ghci` or `ghc` or `runhaskell` to use the cabal sandbox package database. `cabal exec — runhaskell` does the same thing of course, but I am just too lazy to type such lengthy command.

So there you go, a simple shell script (`zsh` at the moment) to simplify the management of my cabal sandbox environment for my haskell projects and experiments.

Interactive web clients: frontend routing or backend routing?

As frontend web frameworks like AngularJS, BackboneJS and EmberJS (and ReactJS, though ReactJS doesn’t give you MVC, only V) gain prominence, a question that’s often asked and explored is — where do we specify our routing?

Frontend MVC-style JS frameworks usually come with libraries that help you define url routes.  And frontend MVC-style JS frameworks are often coupled with NodeJS, where NodeJS can act as the backend server to provide you a way to specify your url routes like Django’s does or Rails’ routes.rb or martini-go’s m.[http method GET, PUT, POST, DELETE, PATCH] do.  Typically, if we implement backend routing in NodeJS, it will be represented as such:

// ... more code above, truncate code here

var app = connect()
     .use( function(req, res) {
var pathname=url.parse(req.url).pathname;
var localpath = path.resolve(__dirname);
    case '/register':
        getfile(__dirname+"/html/register.html", res, "text/html");
    case '/homepage':
        getfile(__dirname+"/html/homepage.html", res, "text/html");
    case '/upload':
        getfile(__dirname+"/html/upload.html", res, "text/html");
        getfile(__dirname+"/html/index.html", res, "text/html");

http.createServer(app).listen(8000, serverUrl);

which as you can see, is fundamentally analogous to the framework interfaces provided by python/django or python/flask or ruby/rails or golang/martini-go.

In short, if we so choose to use nodejs for backend routing when implementing our web client, we are essentially asking our server backend for url route definitions.

This dilutes the benefits associated with implementing a frontend-only web client because we will in fact be polling our server for a URL whenever we render a new “page” (screen).  Put it another way – would you implement an iOS or Android app that needs to ask the server which screen to transit to whenever a user needs to load a new screen?

Viewed in this context, the answer is clear — we should be using frontend routing to leverage on the full benefits provided by feature-complete MVC JS framework like AngularJS or BackboneJS or EmberJS.  This means that the end user of our web app only loads our html/js/css files once.  Dynamic data on each “screen/page” is retrieved from a REST API and has nothing to do with the “screens/pages” already implemented in the frontend, which is why all routes are *already decided* by our frontend routing the first (and-only) time your user’s web browser loads up the site.  This is also why we often refer to these type of web apps as “single page app”.

Because of frontend routing via these JS frameworks, we will see a strange hashbang symbol in our url, like this .  Such urls are not cool in my books and I want my pretty urls!  So sad… fortunately for us, HTML5’s pushstate feature is readily available and already implemented in all these modern MVC JS framework. With a little configuration, we can have our pretty urls without the hashbang-ed urls.

Like this:-

AngularJS –

BackboneJS –

What about my SEO?

The astute reader and seasoned web developer/owner will ask a question at this point — if it’s a “single page app” that is fundamentally rendered by hashbang urls, wouldn’t our SEO be screwed?

Great question, but developers of these frameworks are seasoned web veterans…

Handling SEO is nothing but providing a way for search engine crawlers (“bots”) to navigate your website and associate content/keywords on each “url” on your website so that search engine users can find your content. Here’s a great article detailing how to “serve” content to the bots while providing the seamless experience provided by a single-page app to the human user –

Long story short, we will *still* deploy a nodejs app via phantomjs with generated “backend routing” solely to serve our bots.  As far as our human friends are concerned, they will never need to access these content or poll the server to figure out url routes.  Best of both worlds.