Replacing Macbook Pro's 13" Battery


My old Macbook Pro that I have been using since Jan 2011 has never had a good battery life since a few years ago. It might be because I have been abusing it with dual boot or I never care to unplug it from the power.

I wish there is a free app for OS X that could automatically stop the power in some scheduled time so that the battery is always exercised to charge and discharge. I know there is an application that does exactly this sort of thing on Lenovo Thinkpad called ThinkPad Power Management.

Changing a Macbook Pro's battery is very simple, what you need are only a replacement battery, a plus screwdriver, and a tri-wing screwdriver. First, shut down the MacBook and then unscrew all the screws off the back lid using a plus screwdriver. Lift the lid and don't be surprised with the amount of dust that has accumulated there.

Next, just unscrew the 2 screws on the battery with a three-wing screwdriver. Then, unplug the socket to disconnect the battery from the laptop, which should be easy if it's picked from the correct angle. Lift the battery and then install a new replacement battery there.

It takes less than 10 minutes and would save you 2 trips to Apple Care, not to mention the days where the laptop has to stay with them.



This thesis program is the result of my work from Dec 2014 until around Mar 2015. It is a parallelisation of swarm - an existing single-linkage clustering algorithm for metagenomics data. This program arranges the complete hierarchical clustering workflow into of a set of finely-grained computations (referred as row calculations) that can be run in parallel. The concept of "subseed" was re-used from swarm to skip most of the redundant comparisons (referred as economic search).

The code for global pairwise alignment and k-mer filtering scheme were also re-used from Swarm since they were proven to be very efficient with the SIMD utilisation.

Based on the tests that were run on medium sequence length dataset (averagely 381 nucleotides), the speedup that can be achieved through the parallelisation is averagely 11 times when using 16 threads. This result indicates a successful parallelisation technic which according to Amdahl's law it means 97% of the code were able to be parallelised.

4 level economic search

sequence distance triangle inequality

And the full document:

Is write to disk faster than write to memory? Don't think so


Not long after being featured in IT Worldthis paper went viral in Slashdot.

Code was written in different language: Java and Python and this paper claimed to prove that "in-memory DOES NOT always work faster than disk operation". I couldn't help but to read the code because it cannot be true.

First of all, the code is not proving that memory operation is slower than disk operation.

First part of the code repeatedly concatenate the String object "1" as a single byte using `concatString += addString` which is a proven inefficient way to do it (mentioned in every Java programming book). This is irrelevant with memory operation being slow.

Second of all, what "Single Write to Disk Time" does is actually not an in-memory operation. This is just the time used to write an object of a very big String (length of 1,000,000) into a file. What will happen is that CPU will fetch buffers of data from RAM and then pass it to the file.

The part "Write to Disk Time" that is claimed to be faster is the part where "1" is repeatedly written to BufferedWriter for 1,000,000 times. Of course it will be faster because "1" will be stored in CPU cache since it's used for 1 million times and fetching from CPU cache is very fast because the data is already there in the CPU.

It is not a surprise that reading "1" from CPU cache for 1,000,000 times is faster than reading a String containing 1,000,000 of "1"s from the RAM.

So, no, disk operation cannot be faster than memory operation.

OTOH this could also remind us how important it is to validate any research paper before citing or referring from it.

Setting up Valgrind on Mac OS Yosemite


Valgrind is a popular tool for debugging memory leak in C++. By using this tool you will be able to see objects that were forgotten to be freed/deleted, and potential bug from code that Valgrind doesn't like.

Installing Valgrind on older Mac OS is very simple and can be done from brew. However the most recent Mac OS 10.10 (Yosemite), has not been officially supported by Valgrind. Hence to be able to use this, installation must be done manually from their latest svn trunk which is also very simple.

svn checkout svn://

Followed by going into the directory trunk and:

make install

While running one might get an error saying that aclocal was not found.
./ line 6: aclocal: command not found
error: while running 'aclocal'

In this case the automake needs to be installed prior to running this script. The easiest way to do it is to install from brew, such as:

brew install automake

To start using valgrind:

valgrind --leak-check=full --show-reachable=yes --log-info=leak.log "[your program and args]"

For less detailed information and log to stdout:

valgrind --leak-check=yes "[your program and args]"

How to Setup GDB in Mac OS


The last time I wrote something in C++ was 10 years ago during the lab session in the university, and recently I just decided to write my thesis project in C++ because of many reasons. First time writing after 10 years wasn't so easy and I got this error message on the screen when running the code:

Segmentation fault: 11

Not so helpful, is it? Meaning some errors relating to pointer happened somewhere in the program.

In Java (and probably many other modern programming languages too) usually a complete stack trace will be printed at least on the stdout, even if it's the programmer's fault for not catching the exception. Apparently in C to debug something like this there is a tool called GDB that can be easily installed in linux. On Mac it can be installed from brew, followed by a simple step of adding keychain access for gdb.

So to install:

  1. brew tap homebrow/dupes
  2. brew install gdb
  3. Open /Applications/Utilities/Keychain Access and create a certificate in "System". Things to highlight here are (chronologically):
    • Identity type: Self signed root
    • Certificate type: code signing
    • Let me override defaults
    • Store in "System"
  4. Get info of the just created certificate and set everything to "Always trust"
  5. codesign -s [name of certificate] $(which gdb)
Start using GDB:
  1. gdb [name of executable]
  2. run
    • up to this point the program will run and print out line number where the error happened and if need more information use backtrace.
  3. backtrace 
  4. help catch exception followed by catch throw and re-run debug to help catch exceptions that were not caught in code.
  5. quit