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.

Execution Discipline

I have often been asked to help start-up founders look for technical talent because of my deep involvement in various open source software community work and because of various pro-bono community service I have done over the years.

As a software consultant building apps for customers and ex-freezer product lead for a local scientific instruments company over a career spanning 8+, 9 years, I have also acquired a deep understanding of product development cycles and the human dynamics between business and technology teams.  In a front row seat (as an employee and as a software consultant), I have observed first hand how successful product and business owners build their company and how unsuccessful ones behave.  Skills and luck (“market timing” for example) are factors that contribute to the success stories; and conversely, are also factors that can lead to a company’s downfall.

But above all else, the successful business/product owners I know are always those that have execution discipline.

What do I mean by Execution Discipline?

Execution discipline is about following clear methodologies when making product hypothesis, business or technology decisions and allocating resources. It is also about systematically evolving the methodology in a clear and deliberate manner as new facts and information becomes available.  In other words, one can start out with a completely wrong methodology, or a product hypothesis that has no demand for a given situation, but has the self-awareness and the temperament to evolve towards a more appropriate methodology or hypothesis.

Or to put it in Jack Sparrow’s words…

The problem is not the problem.  The problem is your attitude about the problem.


One of my most successful clients started out his online business ventures by working with a range of software developers.  When he first got into the online software business, he was completely unaware of all the intricacies involving online marketing, software development and the differences between all the freelance developers out in the market.  For more than a year, he hired various developers to build out various online apps he has in mind.  Every single one failed – because of a bad hire or simply because the idea he had has no legs – no one needed what he built.

With each failure, he learnt something new and evolved his approach.  Through this process of systematic trial and error, a product he built became immensely popular and profitable.

In the scientific instruments company I worked for before I started my own gig, my bosses exhibited the same kind of discipline.  They are relentless and systematic in their pursuit for perfection – whether it’s sales and marketing implementation or manufacturing (existing products) or new product development.  That is a discipline that sees a – at that time in 2006 – year-by-year company revenue of USD$11 million.  Yes, it’s not a Google-scale success.  But it certainly is a successful, profitable and self-sustaining business that is continuing to evolve and grow.

On the other hand, some of the worst kind of customers I had when I was consulting and writing software as a service, are business owners that change their mind in completely random whims.  Make no mistake, many of these customers are very brilliant people and are extremely well connected too.  They possess individual skills (marketing, sales or otherwise) that would easily match any of the successful examples I mentioned above.  It is almost as-if their brilliance is their curse – always distracted, always quick to change their minds before a hypothesis is tested and always having “the next new idea”.

So if you are to ask me what’s the one single attribute that I respect in a business owner or a product owner, I will say “Execution Discipline” – with no hesitation.

So why is this important?

Besides the obvious fact that execution discipline gives a start-up a better chance of finding product-market fit and thus achieve the elusive “start-up success”, technical talent likes working with business owners and leaders that behave in a predictable fashion.  Even when dealing with the inevitable uncertainties of a start-up company, a disciplined leader that is able to steer the ship and change directions in a calm, deliberate manner commands the respect of his/her team.

First time entrepreneurs often revel in the fact that they are completely free to move fast and change directions rapidly – and yes, indeed, the ability to change direction rapidly is one of the reasons why a start-up can do what a large, monolithic, established company cannot.  However, the mistake these first time entrepreneurs often make is to change directions randomly.  Don’t make the mistake of thinking that making changes rapidly is progress.  Change because data and facts emerge to signal a need for a change; and not because the entrepreneur has a “eureka” moment.

So start-up founders looking to hire technical talent: my advice is simple – be clear and systematic about the problem you want to solve and the customers you want to serve.  Everything else follows and evolves from there.

Does a start-up founder need to code? That is a story and a controversial debate for another time and not the focus of this post.

The observation I am sharing with you here in this post is simple: luck, market timing and skills aside, the most important attribute that technical people value in their leader is the leader’s ability to steer the ship in a calm, systematic manner – storm, kraken, or whirlpool.

Just like Jack Sparrow.