Valgrind on Mac OS X (10.9) Mavericks

On Mac OS X, the common way to write C code is to simply use the Xcode IDE.  Xcode comes with solid autocomplete functionality and has a built-in instruments app – a performance, analysis, and testing tool for dynamically tracing and profiling your program – which is absolutely critical for preserving your sanity and for revealing any mistakes you might have made that is causing memory leaks and various syntax errors in your non-trivial C applications.

The other alternative tool is, of course, the venerable valgrind.

I was curious to see if I could get valgrind working on my Mac laptop running Mavericks (10.9) as it is not yet officially supported.  Attempts to get valgrind installed via both the Macports and Homebrew package managers fail.

Fortunately, I discovered a patched branch by Frederic Germain here – and and this patched branch seems to work great for Mavericks.

And this works beautifully.

# Make sure I have autoconf and automake both installed.
sudo port -v install automake
sudo port -v install autoconf
# Grab Frederic's patched valgrind on his "homebrew" branch
cd ~/work  # My usual project directory
git clone -b homebrew
cd valgrind
# Because he placed VEX as a git submodule, we have to make sure we clone it too
git submodule init
git submodule update
# With VEX submodule now available, we can compile valgrind
./configure --prefix=/usr/local   # set the stage for sudo make install to place our compiled valgrind binary as /usr/local/bin/valgrind
sudo make install

And checking that I indeed have valgrind installed.

calvin % which valgrind

And now, to see valgrind in action, checking a simple C program just to verify that valgrind works as advertised.

cd ~/work/simplecprogram
make program1  # compiles my program1.c source file to program1 binary
valgrind ./program1

We should see the stdout read:-

==49132== Memcheck, a memory error detector
==49132== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==49132== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==49132== Command: ./program1
==49132== WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
==49132== WARNING: Expect incorrect results, assertions and crashes.
==49132== WARNING: In particular, Memcheck on 32-bit programs will fail to
==49132== WARNING: detect any errors associated with heap-allocated data.
Hello World.
==49132== HEAP SUMMARY:
==49132== in use at exit: 29,917 bytes in 378 blocks
==49132== total heap usage: 456 allocs, 78 frees, 35,965 bytes allocated
==49132== LEAK SUMMARY:
==49132== definitely lost: 0 bytes in 0 blocks
==49132== indirectly lost: 0 bytes in 0 blocks
==49132== possibly lost: 0 bytes in 0 blocks
==49132== still reachable: 4,096 bytes in 1 blocks
==49132== suppressed: 25,821 bytes in 377 blocks
==49132== Rerun with --leak-check=full to see details of leaked memory
==49132== For counts of detected and suppressed errors, rerun with: -v
==49132== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 117 from 20)

And that’s it. Notice the warnings of course!  As I mentioned, valgrind is not offically supported beyond Mac OS X 10.7 yet.

WARNING: Support on MacOS 10.8/10.9 is experimental and mostly broken.
WARNING: Expect incorrect results, assertions and crashes.
WARNING: In particular, Memcheck on 32-bit programs will fail to
WARNING: detect any errors associated with heap-allocated data.

In any case, it is completely possible to invoke instruments from the command line as well – if you insist on writing C programs without the help of Xcode. And is a much safer bet when you are working on your production C programs.  But… that shall be a topic for another day. :-)

python virtualenv with node environment via nodeenv

Virtualenvwrapper is one of the most useful tools a python user should be familiar with.  Built on top of virtualenv, it helps us avoid a lot of redundant “code administrative” work and simplifies our 3rd party python package isolation.

NodeJS has a similar isolation mechanism and a number of such isolation tools available.

I prefer to use the nodeenv tool because it saves me the trouble of typing out long “source” commands (much like virtualenvwrapper helps me avoid typing in long “source” commands provided by the virtualenv tool).  Also, the integration with virtualenvwrapper implies that I don’t have to waste time remembering new commands to manage my isolated nodejs environment.

So here’s how it’s done. Really efficiently! (assuming of course you have installed your python virtualenvwrapper and virtualenv tools properly):

$ mkvirtualenv myproject1
$ pip install nodeenv  # This installs the nodeenv package into our new python virtualenv so named "myproject1" above
$ nodeenv -p  # This commands installs nodejs and adds new shell functions to our virtualenvwrapper shell functions
* Install node.js (0.10.12) ..
* Appending nodeenv settings to /Users/calvin/.virtualenvs/myproject1/bin/activate
$ deactivate; workon project1   # Deactivate and re-activate to ensure we load in the updated shell functions and environment

Once this is done, we are all set with project1 being our nodejs AND python isolated environment.  When we use the npm install -g command, we install our npm packages into our node virtual env.

$ npm install -g yo grunt-cli bower

$ yo angular
[?] Would you like to include Twitter Bootstrap?: No
[?] Would you like to include angular-resource.js?: Yes
[?] Would you like to include angular-cookies.js?: Yes
[?] Would you like to include angular-sanitize.js?: Yes

This installs the yo, grunt-cli and bower tools directly into our node virtual environment and using yo angular we easily scaffold out a new angularjs project.

A quick peek at our ~/.virtualenvs/myproject1 directory shows us the directory structure that includes python packages and npm packages.

$ cd ~/.virtualenvs/myproject1

$ tree -L 2
├── bin
│   ├── activate
│   ├── activate.csh
│   ├──
│   ├──
│   ├── bower -> ../lib/node_modules/bower/bin/bower
│   ├── easy_install
│   ├── easy_install-2.7
│   ├── get_env_details
│   ├── grunt -> ../lib/node_modules/grunt-cli/bin/grunt
│   ├── istanbul -> ../lib/node_modules/istanbul/lib/cli.js
│   ├── karma -> ../lib/node_modules/karma/bin/karma
│   ├── node
│   ├── nodeenv
│   ├── npm -> ../lib/node_modules/npm/bin/npm-cli.js
│   ├── pip
│   ├── pip-2.7
│   ├── postactivate
│   ├── postdeactivate
│   ├── preactivate
│   ├── predeactivate
│   ├── python
│   ├── python2 -> python
│   ├── python2.7 -> python
│   └── yo -> ../lib/node_modules/yo/bin/yo
├── include
│   └── python2.7 -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
├── install.cfg
├── lib
│   ├── dtrace
│   ├── node_modules
│   └── python2.7
├── share
│   └── man
├── src
│   └── node-v0.10.12
└── tags

That’s it.

compass/zurb-foundation via gem with yeoman/Gruntfile.js

Starting a frontend project (e.g. an AngularJS project) with yeoman helps us generate a bunch of default directory layout and a pre-set Gruntfile.js configuration file. This configuration file contains most of the necessary settings that controls our project requirements and behaviour.

In this post, I will explain how I get compass and zurb-foundation running seamlessly as scss imports in my yeoman-generated project.

 yeoman: yeomanConfig,
 watch: {
 coffee: {
 files: ['<%= %>/scripts/{,*/}*.coffee'],
 tasks: ['coffee:dist']
 coffeeTest: {
 files: ['test/spec/{,*/}*.coffee'],
 tasks: ['coffee:test']
 compass: {
 files: ['<%= %>/styles/{,*/}*.{scss,sass}'],
 tasks: ['compass']
 livereload: {
 files: [
 '<%= %>/{,*/}*.html',
 '{.tmp,<%= %>}/styles/{,*/}*.css',
 '{.tmp,<%= %>}/scripts/{,*/}*.js',
 '<%= %>/images/{,*/}*.{png,jpg,jpeg,gif,webp,svg}'
 tasks: ['livereload']

Update our configuration for compass

compass: {
 options: {
 config: '.compass.rb',
 force: true
 dist: {},
 server: {
 options: {
 debugInfo: true

.compass.rb is references in a new file we create with the following:

require 'zurb-foundation'

http_path = "/"
sass_dir = 'app/styles'
css_dir = '.tmp/styles'
images_dir = 'app/images'
javascript_dir = 'app/scripts'
fonts_dir = 'app/styles/fonts'
import_path = 'app/components'

Since this is a ruby file, it loads up zurb-foundation in its first line.

We install zurb-foundation with gem as follows (if you do not have rvm or gem correctly configured, check out my previous post guiding you to set up rvm step-by-step).

$ rvm use 1.9.3   # if we have not done this yet
$ gem install zurb-foundation

Once we have zurb-foundation installed, it is trivial to import the zurb-foundation framework into our scss file.

@import "foundation"

Quite a bit of hassle to get to this point but now we can mess with zurb-foundation framework in our project!

Zurb foundation includes a whole range of scss and we are interested in its location so that we can specify the appropriate @import statement to use the appropriate components to style our application.  Here’s how we find the location of our recently installed zurb-foundation library.

$ irb
1.9.3-p448 :001 > spec = Gem::Specification.find_by_name("zurb-foundation")
=> #<Gem::Specification:0x3fe2b185bb40 zurb-foundation-4.2.3>
1.9.3-p448 :002 > gem_root = spec.gem_dir
=> "/Users/calvin/.rvm/gems/ruby-1.9.3-p448/gems/zurb-foundation-4.2.3"
1.9.3-p448 :003 >

So, if we change into this directory,

$ cd /Users/calvin/.rvm/gems/ruby-1.9.3-p448/gems/zurb-foundation-4.2.3
$ tree scss

├── foundation
│ ├── _variables.scss
│ └── components
│      ├── _alert-boxes.scss
│      ├── _block-grid.scss
│      ├── _breadcrumbs.scss
│      ├── _button-groups.scss
│      ├── _buttons.scss
│      ├── _clearing.scss
│      ├── _custom-forms.scss
│      ├── _dropdown-buttons.scss
│      ├── _dropdown.scss
│      ├── _flex-video.scss
│      ├── _forms.scss
│      ├── _global.scss
│      ├── _grid.scss
│      ├── _inline-lists.scss
│      ├── _joyride.scss
│      ├── _keystrokes.scss
│      ├── _labels.scss
│      ├── _magellan.scss
│      ├── _orbit.scss
│      ├── _pagination.scss
│      ├── _panels.scss
│      ├── _pricing-tables.scss
│      ├── _progress-bars.scss
│      ├── _reveal.scss
│      ├── _section.scss
│      ├── _side-nav.scss
│      ├── _split-buttons.scss
│      ├── _sub-nav.scss
│      ├── _switch.scss
│      ├── _tables.scss
│      ├── _thumbs.scss
│      ├── _tooltips.scss
│      ├── _top-bar.scss
│      ├── _type.scss
│      └── _visibility.scss
├── foundation.scss
└── normalize.scss

which gives us the list of zurb foundation scss components we can import into our “main.scss” file!