Vincent Liu

Nobody blogs anymore, and Heroku limitations

2017-12-27T01:43:00.001+00:00

Looking at the previous date stamp, you'd have noticed that it has been ages since I've written anything on this blog. But in this day and age, who does 'blogging' anymore? I'd be surprised if any of my old-timer friends are checking if there's any updates to this page, and/or be still subscribed to any feeds related to it (if the feed readers are still surviving themselves!)

I've moved the blog to Heroku+git a while ago, and while it has also has been stagnant, in the last month, it seems like someone/something has been pinging the site pretty hard that caused all my dyno hours to be used up, bringing it down for the remainder of December. Whoever the ddos'er is, well *you win* [not like it matters anyhow]

Makes me wonder if my move to Heroku was really warranted, thinking that it is easier to post code-related snippets (and it still is), but at least with blogger, there's no risk of the site being shut down just because someone exceeded the 550 hours of use.

At least there's a choice :)

Getting YouCompleteMe to work in RHEL 6 (or Fedora)

2013-02-10T23:06:00.000+00:00

No matter what IDE I use, so far I still give up and go back to vim. However, Eclipse is quite missed for it’s autocomplete facility. The recent announcement on Hacker News gave me a glimpse of hope with YouCompleteMe, as with clang complete a while ago, but even sleeker.

But YouCompleteMe uses a number of really new dependencies, which RHEL6, being an old snapshot of Linux, is a bad target candidate since these dependencies are not easily satisfied. Perhaps stopping short of paid support, it’s unlikely that these packages will be made up-to-date. Not being a cheap-ass here, but since I really don’t like waiting, I’ll just have to roll-my-own :-)

Amazingly these dependencies are so new that even vim needs to be rebuilt due to the recently introduced python extensions, so there’s no avoiding some serious source compiling here!

Before we start, let me impart some words of advice. Firstly, even if you are gutsy enough to build your own binaries, never try to reinvent the wheel and build from pristine sources!

Secondly, installing software through package managers (eg. RPMs, .debs) are always superior to “sudo make install”. It ensures you’ll never have lingering dependencies, or wrong versions of libraries that got wrongly linked because the installed script overwrote the default.

For Redhat based OSes, since the guys at Fedora has already done the hard work of building up-to-date packages, applying patches and cleanups for you, it’ll be the best bet to avoid pain from compilation errors, or hours spent in debugging other people’s code.

Pull a copy of the vim.spec file from Fedora Rawhide and re-adapt it to your liking before building an RPM. Obviously, F19 (as this time of writing) has diverged since RHEL6 got snapshotted, so a little patch and backporting is unavoidable.

Then, there’s the issue of Clang, which is recommended to be version 3.2. Even Fedora Rawhide at the moment only supports 3.1, so I was rather surprised about such a new dependency that YouCompleteMe requires. Still it’s not a problem, just a little more hacking on llvm.spec.

Note: my Clang 3.2 build fails a single regression test during building, so I’ve disabled regression testing to allow the RPM to be built. While it may be ok for some other software, but regression test failures on your compiler is a BAD thing, especially if you’re going to build the entire OS from scratch. But since we’re only using it as an annotation tool, I’m going to let it slide.

If building those 2 things hasn’t deterred you yet, you’ll still need to deal with the last headache of building a newer version of CMake, as a dependency that YouCompleteMe require in order to compile the final ycm_core.so library. [ But why? :-( ]

Anyway, for people who want to skip the pain of building it yourself, you can get my pre-built ycm_core.so and all my vim/llvm RPM dependencies from my RPM repo (if you trust my work ;-) and save yourself some compiling hassles. They probably will work on Fedora as well, since dependencies are usually forward-compatible, but YMMV. Have fun!

Have you ever reused code?

2012-09-14T06:00:00.000+01:00

The term 'Code Reuse' feels like a software developer's cliche that had since fallen into the list with other unfashionable tech lexicons. Nevertheless the terminology still lingers on like a bad smell, never fully ready to die off. These days, code reuse feels more like the definition of a myth - a story everybody has heard of, but nobody has witnessed.

If you are ever geeky enough to have raised code reuse as a conversation piece, you'll probably notice that almost everybody have something good to say about it, from a vague feel-good feeling about how good a thing it is, to how it may have profoundly changed a person's life (ok, I exaggerated about this one). If you had to ask anybody for 5 good examples, I'm sure you'll be hard pressed to find anybody with a sensible answer. How about we start with yourself: when was the last time you've reused your own code in a meaningful, substantive way?

These days, the only visible code reuse I know of, is only when I rely on code from a software library - often an external library written by somebody else. Be it a data structure, a fancy graphical widget, or complex mathematical computations, there is probably a library out there which will cater to your need. Writing from scratch is something you never seem to do anymore.

But relying on software libraries is just not my romanticised version of code reuse, the one where the object-oriented programming paradigm had so promised so long ago. Remember the textbook claims on writing your own well-abstracted objects, and how you'll be rewarded in reusing them for all perpetuity? Personally, that lofty promise has certainly fallen short of my expectations from when I was a starry-eyed kid coding in OOP for the first time, to the more experienced software developer today.

So what went wrong? Nothing actually.

Code that has well-defined purposes, inputs and outputs, which are so often used, are easily defined and hence usually gets 'factorised' into code libraries. These libraries get battle-tested by many other developers over time, ironing out any residual kinks, as well as any lingering bugs. Over time, a well-used library makes more compelling sense to use than to roll your own, since it minimises the risk and uncertainty from newly introduced code.

So whatever's that's left for you to work on, are likely new and unique issues you are solving, making it naturally unfactorisable. And if certain portions of code do become apparent enough for you to find a commonality, that's perhaps when you'll refactor your own code to reuse these commonalities, although I suspect the possibility of such situations are getting less likely. Maybe like me, you're feeling a little cheated as well.

Code reuse today is just an euphemism of relying on other people's code - well, it is still reuse, just not your own code, not unless you happen to be a software library writer. But chances are, you are usually not.

I might as well go one step further and declare that we never reuse our own code anymore - as a corollary to the famous Bikeshed Problem. Not all of us will gain sufficient experience in building our own nuclear reactor (or more efficient data structures and algorithms), so what's left remaining is only to focus on the colour of the bikeshed (or button placements within a HTML form) because that's the only thing that's left to do when other people have done all the heavy lifting for you. And that's how it should be, after all, didn't they tell us not to reinvent the wheel?

It's why any boy and his dog today can write an application with some knowledge of HTML, CSS and Javascript - nobody needs to know how to code a rasteriser for transforming vectors into pixels, write their own graphics routines so that they can display a button, input, or to write their own binary search tree in order to use a hashmap, since they don't have to - the first principles of software systems are all conveniently abstracted into libraries, frameworks, and easy APIs that they can use.

It is not a bad thing, but it is also to no wonder why any arts major can simply write a web application and proclaim themselves to be a software developer these days. While I wouldn't mind them doing a webpage for me, I won't go as far to trust a lay-coder on anything that's of any algorithmic complexity.

On the flip side, it's never been better to be a software developer; we are more productive from the assortment of libraries that are at our disposal, from the myriad software frameworks to numerous tools that we utilise today - all of which has allowed us to write software systems that would be difficult in the past, a relative breeze today.

As software development goes these days, we are indeed standing on the shoulders of giants.

Vim: When Copy and Paste doesn't work ...

2012-09-07T06:00:00.000+01:00

I used to remember that copying and pasting to the clipboard used to work a long while ago, but I just couldn't remember what exactly did I do in order to get it to work. That were the days where I was still bothered enough to tweak things to get it running - these days I just want to get things to work, which many will arguably retort that what I'm asking for is impossible.

While Linux may be perceived as still a much less-accessible OS compared to the ones that you have to pay for, it actually works pretty well once you've gone past the learning curve. But from time-to-time, you can still be surprised with what you don't know. It can feel like a hassle sometimes, but on the flip-side, learning new things is what makes using it fun. (Sure many may disagree on that too - and if you are one of them, I'll save you the torture; shut your brain down and go back to surf your Facepage instead ;p)

I remembered about having to recompile vim from dog years ago, and started to look at what's missing in the standard vim-enhanced package; lo-and-behold, the version flag shows the following:



$ /usr/bin/vim --version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Nov 16 2010 17:05:25)
Included patches: 1-56
Modified by 
Compiled by 
Huge version without GUI.  Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent 
-clientserver -clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs 
-dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path 
+find_in_path +float +folding -footer +fork() +gettext -hangul_input +iconv 
+insert_expand +jumplist +keymap +langmap +libcall +linebreak +lispindent 
+listcmds +localmap -lua +menu +mksession +modify_fname +mouse -mouseshape 
+mouse_dec +mouse_gpm -mouse_jsbterm +mouse_netterm -mouse_sysmouse 
+mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype 
+path_extra +perl +persistent_undo +postscript +printer +profile +python 
-python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent 
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl +terminfo +termresponse +textobjects +title
 -toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
 -xterm_clipboard -xterm_save 
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
      user exrc file: "$HOME/.exrc"
  fall-back for $VIM: "/etc"
 f-b for $VIMRUNTIME: "/usr/share/vim/vim73"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -g -pipe -Wall  -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64  -D_FORTIFY_SOURCE=1     
Linking: gcc   -L.  -rdynamic -Wl,-export-dynamic  -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE   -L/usr/local/lib -Wl,--as-needed -o vim       -lm -lnsl  -lselinux  -lncurses -lacl -lattr -lgpm -ldl    -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE  -fstack-protector  -L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic   -lruby -lpthread -lrt -ldl -lcrypt -lm

The compiler flag xterm_clipboard isn't compiled with standard text mode vim, that was the main reason that I had to recompile vim in the past!

But these days, I'm lazy. I much rather not have to recompile and maintain my own packages if I have to, and it turns out that I'm in luck - a bit of digging showed that the vim-X11 package contains vimx, a version of vim that has the xterm_clipboard flag enabled. Happy days!

So just do:



$ sudo yum install vim-X11
$ alias vim=$(which vimx)

The alias command just makes it easier given I'm so used to typing vim than vimx, so that I don't have to undo my habit :)

So how do you make use of the clipboard? Let say you have mouse mode on (set mouse=a), and selected some text using your mouse; in order to send it to the clipboard, do

"+y

Note that the quote isn't a typo. To paste from the clipboard into vim, do:

"+p

Bonus trick. You can make your selection in normal mode automatically be sent to the x11 clipboard by making this configuration:



set go+=a

Have fun! :D

Adding extra jar files to Ant path in Fedora/RHEL

2012-08-31T06:00:00.001+01:00

The default RPM packaged version of 'Ant' that comes with Fedora/JPackage doesn't doesn't respect the $ANT_HOME environment variable the same way as if you have downloaded and installed it directly from Apache itself.

These days, having a little more to do with J2EE work as they are good sample applications for testing our JVM, I'm having to pick up various build tools that I don't normally use, like Apache Ivy and Maven. Ivy works as an additional jar to supercharge Ant's capabilities, and hence a post as a self reminder. There are essentially 2 ways of accomplishing the task:

1) Put "ivy.jar" into our custom development distro by default into /usr/share/ant/lib. This is a nice option for all developers, since we won't need to do anything extra for it to work. But it isn't tracked by package management (ie not an RPM), and neither should developers put in the file into /usr/share/ant/lib just because we have local superuser rights, since management of these issues should be done by the sysadmin, automatically if possible.

2) Workaround this situation by having a local override of the Ant configuration. Create the following directory structure in your $HOME/.ant directory, eg.



[vincentliu@workstation08 ~]$ tree $HOME/.ant
/home/vincentliu/.ant
|-- ant.conf
`-- lib
     `-- ivy.jar

In the ant.conf file, have the following lines:



[vincentliu@workstation08 ~]$ cat $HOME/.ant/ant.conf
# Need to override the existing $ANT_HOME path that JPackage customized
# to add in the ivy package as part of Ant's classlib
CLASSPATH=$HOME/.ant/lib/ivy.jar

Copy the ivy.jar file into $HOME/.ant/lib directory. And these changes will allow you to compile use Apache Ivy natively without littering multiple copies of it per project.

Google Drive does not work if your network is slow

2012-08-24T06:00:00.000+01:00

I solely use Google Docs, erm Drive, for working with documents these days. While it's named "Drive" now, I'll refer it as the old incarnation "Docs" as it's the document editor that I'm about to rant here.

Google Docs as an editor, is simple to use, and is very accessible - there is no need to install any specific software for it, all you need to do is to open it up through the web browser. But the best thing I like about it, is that I can edit the document without a care and not have to worry about saving the document somewhere so that I can resume editing elsewhere later. Everything is available as long as I have access to the Internet.

Now, that's all fine and dandy, except if you have a "slow" connection. And when I say "slow", I don't mean the archaic 56kbps speeds back in the heyday where people still dial-up a modem connected to a copper phone line. Slow in Google's context, apparently meant anything at mobile broadband speeds (@1mbps).

Google Docs had been working fine, prior to the fairly recently change they've introduced the "we'll save as you type" feature. The old Google Docs wasn't that bandwidth hungry since saving the document was in coarser time blocks instead of the consistent synching that they are doing now.

With the recent changes, Google Docs appear to either suck up more bandwidth, or have lower latency requirements that my humble mobile broadband dongle does not appear to satisfy anymore. For whatever I type in, after 2 minutes working into the document, Google Docs will just hang at "Saving..." and then produce this screen:

This error is consistently reproducible, and it's not even a complex document we're talking about here - it's essentially a text file editable by vim that I copy and paste into sometimes. I don't get how Google gets this so wrong - we're talking about a document editor for a simple file, for god's sake, what kind of network requirements do you need in order to make it work?!

Happy St. Patricks!

2012-03-17T22:04:00.000+00:00

It's been busy, but I haven't forgotten. Shout out to all my friends: Work has been busy, but life is chugging along. Will need to catch up with everyone soon. Till then, remember your friend in the Emerald Isle :D

The x86_64 Calling Convention

2011-07-11T00:26:00.011+01:00

I suppose I can consider myself an 'old-school' developer now; even though I have been reading the AMD64 ABI documentation, I still haven't fully absorbed it into my head yet, which is evidenced by the recent two situations I had today where RTFM-ing would have had saved me hours of GDB debugging pain.

I have been coding some assembly instructions to make C-calls at runtime to a debugging routine, but the call seems to always ends up mysteriously trampling the JIT-ed routines, making the VM take unexpected execution paths and causing some unlikely assertions to be fired.

The situation is confounded by a number of issues:

the code generated is dynamic, and therefore there are no debugging symbols associated with them compared to code typically generated by the assembler/compiler;
there are different types of call-frames for a given method; 1 for a pre-compiled stub, 1 for a frame that's crossed-over from JIT-ed code to native code, and 1 for the JIT-ed code itself;
when the eventual assertion does manifest, the code is already far away in the rabbit-hole from where the original problem manifested. And because some of the JIT-ed code actually makes a "JMP", unlike a "CALL", you can't actually figure out where the code originated from, since %rip is never saved on the call stack.

While situations 1 and 2 make debugging difficult by having the need to keep a lot of contextual information in order to figure out what's going on, situation 3 is just impossible to debug if the bug is non-deterministic in nature. For example, each compiled method in the VM generates a small assembly stub that replaces the actual code to be executed; when the stub gets executed for the first time, it triggers of the JIT compiler at runtime to compile the real method from its intermediate representation. The compiled method then replaces the stub, hence subsequent invocations will simply call the already JIT-generated method, thereby executing at native-speed, like just as you would get on compiled code.

To optimise on space, the stubs are made as small as possible (~20 bytes), and the common execution body shared by all stubs is factored into a common block. All stubs will eventually perform a global "JMP" instruction to this common block. In order to faciliate communication, all shared data between the stub and the common code block is passed on the thread stack, where the common offset to the method handle is agreed upon.

While the design is elegant, it is also impossible to debug when it breaks; the non-deterministic-ness of the bug seems to surface from time-to-time, where it seems to suggest that the thread stack got corrupted or that it's not passing the method handle correctly. Even when GDB is left running, by the time the assertion triggers, it's already past the fact, and therefore it is unable to trace back to the originating path.

I thought it might be a good idea to inject some debugging calls to trace the execution and stack pointer at runtime, so that I can figure out which stub was last called and the stack height when the call was made; the two information combined should give me sufficient hints on where the problem might lie. However, my injected code has introduced two other issues that I had overlooked, which brings me back into the discussion of the x86_64 ABI again; if you ever wanted to template any assembly instructions into your code that relies on an external library call, do keep these 2 points from the ABI specification in mind:

Save ALL caller-saves registers, not just only the ones that you are using.
(§3.2.2) The end of the input argument area shall be aligned on a 16 (32, if __m256 is passed on stack) byte boundary. In other words, the value (%rsp + 8) is always a multiple of 16 (32) when control is transferred to the function entry point. The stack pointer, %rsp, always points to the end of the latest allocated stack frame.

I have to say that I've dismissed (1) since I've gotten use to the style of only documenting and saving the registers that was used; the convention was something that I had picked up from Peter Norton's 1992 book, "Assembly Language for the PC". For those who don't know, he's the "Norton" that Symantec's Norton Antivirus is named after. I still have the out-of-print book on my desk as a keepsake; it reminds me of the the memories of reading it and scribbling code on a piece of paper at my local library. Remarkably, that was how I learnt assembly, since I didn't have a computer back then. Thumbing through the book today, I still have an incredible respect for Peter's coding prowess. He had a way of organising his procedures so elegantly such that each of them all fitted perfectly together from chapter to chapter.

Sorry, got sidetracked. So yes, point (1) - to save ALL registers; this is necessary because all caller-saved registers can actually be occupied by the JIT routines as input arguments to the callee; while this typically means the 6 defined registers (%rdi, %rsi, %rdx, %rcx, %r8, %r9) for general input (see §3.2.3), other registers can also be trashed upon a call return, so as a rule-of-thumb save everything, except the callee-saved registers (%rbx, %rbp, %r12 to %r15), which are guaranteed to be preserved.

Point (2) - I haven't observed a reproducible side effect from this; however the failure points between adhering to it and not actually causes a visible difference in the JIT-ed code's path; therefore there is a need to be on the side of caution. I seem to have observed that some memory faults from not following this directive, but I can't ascertain this for a fact yet.

Finally, a self-inflicted bug that I'd like to remind myself of; remember make sure to deduct from %rsp if any memory has been written onto the thread stack; otherwise any function calls may unknowingly overwrite it!

For all the trouble with debugging that I've gotten myself into, there is at least a silver-lining to it; I had made the problem deterministic, or if it isn't the same problem, it was a similar class of problem that I can consistently reproduce to analyse its behaviour and learn from the mistakes I have been making. Because of the determinism, I was able to use GDB's reversible debugging feature to record the execution from the stub to the common code to gain a better understanding of how the generated code actually works. It's a really nifty feature, and I'm glad to have it as my first useful case of applied reversible debugging in practice.

Page Faults

2011-06-04T18:30:00.008+01:00

While going through some code emitted by a Just-In-Time compiler (JIT), I’ve encountered a curious piece of code which suggested that if access to the process' utilisable stack space isn’t done incrementally, it will cause an “access violation”.

Normally, I wouldn’t have bothered with the problem. But in this case, the JIT-ed code makes uninitialised reads to the process stack, causing valgrind to generate a huge amount of spurious warnings in its log. This makes it difficult to sieve through relevant details, and makes it impossible to generate a static suppression for because the JIT-ed code's call frames are dynamically generated and arbitrary in nature.

I didn’t see what’s wrong with touching memory that's already accessible by the application, so I didn’t really grok what the “access violation” exactly implies. A little sleuthing is required, so I wrote a little code to test out the “access violation”:


#.equ INCREMENT, 0x1000
.equ INCREMENT, 0x1800

.section .text

FORMAT_STR:
 .string "%d\n"

.globl _start
_start:
 push %rbp
 movq %rsp, %rbp

 # loop and keep touching stack space
 movq $640, %rcx
 movq $-0x1000, %rbx
again:
 movq (%rbp, %rbx), %rax
 subq $INCREMENT, %rbx

 movq %rbx, %r12   # use callee-save to prevent push to stack   
 movq %rbx, %rsi
 movq $FORMAT_STR, %rdi
 movq $0, %rax
 call printf       # but call pushes to stack too :(
 movq %r12, %rbx
 loop again

 movq $1, %rbx
 movq $1, %rax
 int $0x80

Note the commented code at the first line; this represents the original page size boundary in which the JIT emitted that’s causing the offending uninitialised memory access; if the size isn’t extended, the code will segmentation fault at around the 8MB mark. The corresponds to what ‘ulimit -s’ reports on the OS.

However, if the size gets incremented to 0x1800 bytes for example, the code will segmentation fault way much earlier, at around the 140k mark, which puzzled me. Looking at ‘dmesg’ shows something interesting:


[806331.042666] incremental[28910]: segfault at 7fff983ad8a8 ip 0000000000400256 sp 00007fff983cf8a8 error 4 in incremental[400000+1000]

I’m surprised that the kernel actually reports this error, so I started searching for the error string on Google code search. The likely matches came from cygwin which does mention “access violation” and xen-source where it indicates a page fault.

Reading through the definition suggests that I’m causing a hard page fault, but I wanted to make sure that the error code 4 is exactly meaning this. Some cursory research led me to a pretty helpful CS page explaining page faults, with excerpts from Linux 1.0’s sources; scanning through it which showed that "error 4" means that the error comes from user space (as opposed to kernel space).

The code also indicates that if an allocation exceeds the OS page size, the kernel is free to abort the program, which explains the error. Further research also led me to the getpagesize() system call, which verified that the page size for Linux is set at 4KB.

So mystery solved. I suppose the next thing I can do, is to make a nasty hack in the JIT to make spurious writes instead of reads instead; that should get rid of all the valgrind false positives, but I can’t say it’s the most elegant way of resolving the issue.

The Future of Linux UI Scares Me

2011-04-17T00:29:00.006+01:00

I don’t think I have mentioned that I moved from Ubuntu to Fedora. Two years ago.

Why has this to do with the state of the Linux desktop? I’d say at least somewhat to do with it. When I last switched from Gentoo to Ubuntu, it was due to the eventual frustration with the incessant amount of tinkering I had to do in order to get things work.

Most people would have jumped the bandwagon and moved to the newer, and trendy MacOSX. But you know what? What most Linux windows manager have is the “focus follows mouse” feature, which is the most Zen-like simplicity that no other non-unix OSes have. That was why I swapped to Ubuntu, which was the new poster-boy for the “Linux that Just Works”.

The charm however, did not last. “apt-get” was the loveliest feature that I embraced, and it was great that Ubuntu finally fast-tracked Debian to bring forth the most bleeding edge of software packages, albeit with a higher defect rate than the rock solid Debian. Even so, the defect rate in Ubuntu wasn’t something that I perceptively noticed. Not until it came to development tools.

Fedora is the undisputed leader for being the distro by the developers, for the developers. Ubuntu is great, but only when you don’t have to tinker under the hood. If you are, then be prepared for pain. Badly configured packages like GDB, with debugger instability and crashes, and badly placed debugging symbols for packages made it hard to treat Ubuntu as a serious development environment.

It so happened that my company was relocating, and as part of the transition, it was just a good time to think about the software infrastructure that we were using, and to set things up correctly. It was also fortuitous that at the same time, we had hired a very capable sysadmin who is an expert on Redhat based distros, so the decision was to maintain one and one (free) distribution only - Fedora.

I have to say it has been a good choice; personally, I think the QA behind Fedora is very solid generally, and especially in developer tools. But what I thought had been a good choice was that Fedora stuck to the original Gnome desktop where everything was simple, like Windows 98 simple. No, it isn’t a pun; older desktop environments did get it correct, like how OS/2, Windows XP and the KDE 3.x did. They just worked.

There is nothing wrong with the existing paradigm of having an app-menu selector, a taskbar, and a widget area for notifications, plus a few bells and whistles here and there. But Ubuntu decided that it wasn’t good enough; “No, we’ve got to look like Apple”, Mark Shuttleworth says. Then he starts tinkering with the menu icons, switching it from the right hand side to the left.

I’m glad that I’ve left Ubuntu before then; I'm sure he must have realised that getting about 80% of the desktop users to make a context switch of a long-established habit won't be pleasant. It’s like telling a heroine addict that going cold-turkey is a piece of cake. Bad analogy? But you get the point.

Then Mark decides that a singular change isn’t enough, “I have an idea, let’s revamp the whole desktop altogether!” And this is how the Unity interface came about. Still, that’s ok. Ubuntu is Mark’s baby, he’s entitled to drive the design of his distro any way he likes.

I don’t really have much to say about Unity, since I’ve never used it. I don’t think I will anyway; it looks too different to what I have come to be very comfortable with as a desktop environment. But it is not just that I ain't adventurous; field reports from users who had tried it just didn’t look encouraging.

However, the bad news is, Gnome 3 will start shipping the new Gnome-shell interface, which appears to have taken a leaf from Unity's design. It means that Gnome will be the last major window manager to jump the shark. Well so long Gnome, it’s fun while it lasted.

Fedora 15 will be shipping with Gnome 3. The thought of upgrading makes me shudder. Will I be productive with it, or will I be "enjoying" my time in discovering what new features the new UI will bring? Unfortunately, I don’t understand what all that fuss about, competing to reinvent the desktop. I’ll just get a Mac instead*.

*Oh wait, that’s a joke. Don’t get too upset, my Mac fanboy friends. I’ll show you my new shiny Xfce-compiz desktop, or my zen-like fluxbox windows manager. Trust me, you’ll love it.

No Technical Support Provided

2011-04-02T21:37:00.005+01:00

Readers,

If you're came here through the links from my other blog posts, please take time to read what I have to say.

The solutions to the problems I solve, are large done to "scratch my own itch". I like to share these solutions through my blog with the hope that it'll be useful to others facing the same issues. However, I have a pretty intense full-time job in my own company, which leaves me very little time to be providing any specific guidance in any related problems that you may face.

You may want to comment on the blog post, and hopefully, some good Samaritans may give out more wisdom or advice. Or you may be the one who's giving help to others, and good on you if that's the case. That is what community spirit is all about.

Unfortunately, I cannot be here to provide technical support for you and if I don't have further insight or time to the problems you have, you are largely on your own.

Thank you for understanding.

Finding the inclination to write

2011-03-31T21:31:00.003+01:00

I'm still here; yes, I have been very quiet.

Mostly because I'm busy with things. Work mainly. Some aspects I do not enjoy, but it is still fun when it comes to the technical bits. Enjoying those!

Off work, life consists of quite a bit of physical training, something I have come to enjoy too. That is complementary to another habit of mine: sleep. I'm sleeping sufficiently early to wake up for exercise these days. That is a luxury for most people. Ask yourself, when is the last time you have had a good sleep? People are usually so sleep deprived these days, which is sad, literally.

It does mean I sacrifice other material enjoyments in life; TV watching, net surfing or out having a few late night drinks with friends. I don't miss them much, perhaps just a little bit on the socialising. But there's no point in hanging out late in this country; people tend to go overboard with their drinks - there'll hardly be any sensibilities left for meaningful interactions after late ... but I think a lot of people here will digress!

Life is coasting along. It does feel a little aimless sometimes. But then again, what is there to be aiming for? Does it matter whether if you have not done the gazillon things that you wanted to do? In the long run, we are all dead anyway. Maybe that's not enough, for we need that epitaph to survive us?

Well right now, it is enough.

For myself, keep writing. For my friends, keep in touch.

Why a volatile is different in C/C++ and Java

2010-06-05T23:29:00.003+01:00

The volatile keyword is highly subjective to the language and the platform it is implemented on. While Java provides a consistent behaviour of volatile across all architectures, this is not the case for languages that are directly compiled into the native machine platform, such as in the case of C/C++. Let's try to understand why this is the case.

Let be member of a set of program actions , and be function that applies the volatility requirement to an action, where the subscript denotes the -th iteration in which a volatile action is applied, and be the precedes operator, which is explained previously. For all program actions, the following rules holds:

Rule 1 says that all volatile functions enforce a total order, where the function always precedes , where rule 2 says that if an action precedes a volatile function on an action on the -th iteration, then the action must necessarily precede all subsequent volatile functions applied to .

This is a very strong memory requirement in Java, in fact it is much stronger than compared to C/C++. The C/C++ language specification has no such restriction on memory ordering, and leaves it to the compiler implementation to decide how non-volatile actions are ordered around volatile actions.

Let's consider how the these rules affect program execution with a simple code sample:


int a = 0;
int b = 0;
volatile int count = 0;

a  = 1;
count = 1;
b = 2;
count = 2;

In C/C++, the volatile keyword only guarantees that the count variable cannot be reordered against each other, ie. if count == 2, then count = 1 must necessarily precede it. However, there is neither a guarantee that a == 1, nor that b == 2.

In Java, given the stronger guarantee defined above, then if count == 1, then the assertion a == 1 must be true. Similarly, if count == 2 then assertion that a == 1 && b == 2 must be true. This is what is means by the strict memory guarantee that Java offers that C/C++ does not.

However this does not mean that C/C++ will not behave the same way Java does. Whether if it does so depends on (1) whether if the compiler performs any code reordering that may be in a surprising order, but legit order, and (2) whether if the underlying machine architecture upholds the same strict memory order, provided that the compiler does not perform any surprising code reordering.

For instance, compiling code on gcc with -O0 set on all x86 platforms will conform to (and is stricter than) Java's memory model, but other architectures such as the PowerPC, Alpha, Itanium all uphold a weaker memory model which can exhibit surprising program behaviours that a programmer may not expect. Caveat Lector!

Anyhow, if you are interested in more memory model consistency rules, you might want to watch Intel's explanation of the x86 memory model where the nuances of memory ordering is explained in good detail. Enjoy!

Java Hatred Is A Disease

2010-06-05T22:17:00.002+01:00

When it comes to critising programming languages, Java seems to take the top spot for being the baddest. This is widely seen on the InterTubes, like here, and here.

But does a 'bad' language mean that it'll die a relatively quick death?

To find out, let's take a look at the etymology of an older computer language, C. C has been a systems programming language that has been around the last 40 years. The last revision to the C standard was 10 years ago, and even without moving with the times, the language is still going strong - last I heard, it is still the language of choice for 40% of Open Source developers.

Does that mean that people have stopped complaining about pointers, easy-to-write buffer overflow errors, memory leaks, having to declare all variables up front before code, etc, etc, and other quirks about the language?

I suspect not. So why still C?

Simple - it works. And I suspect the same can be said with Java.

Furthermore, it's silly to argue about Java's merits and drawbacks, because that's really missing the forest for the trees. While the most visible part about Java is the undoubtedly the language, but the true technology of Java is not in the language, but the virtual machine itself. The JVM as it stands today, is a fast, abstract machine that you can plug any languages into, and is able to operate at speeds comparable to natively compiled binaries.

Like most programmers, we do enjoy bitching about peculiarities of a language once in a while, but for people who hate Java with a passion, maybe you need to get your head checked. A language is merely a medium of expression; and a computer language is one specifically used to express program behaviour. Normally, the choices are either to learn it well and avoid the pitfalls, or find a better medium of expression.

So seriously, if you don't like Java, there is a cure. Stop. Using. It.

I'll let you in on a secret to programming languages; there are only two types of languages in this world - languages that people complain about, and languages that nobody uses (Stroustrup said so). So in an obtuse manner, the vast majority of people who criticises about Java are only reaffirming its popularity.

Which is precisely why I can't see Java going the way of dinosaurs. Raving incessantly against it, ironically only helps boost its reputation, albeit in a weird, backhanded-kind of way.

Word Tearing

2010-05-29T23:16:00.001+01:00

... Or why you are not guaranteed a coherent value when you are reading longs and doubles in Java.

How is that possible?

This mainly due to a language compromise to deal with 'legacy' 32-bit CPU systems, where a 64-bit value memory action is divided into two 32-bit memory actions, which is mainly done for historical efficiency reasons (Refer to 17.4 of the Java Language Specification for an explicit answer to why). But note that this is not a problem if you are using native 64-bit architectures.

So how does this translate to a possible problem?

Lets try to simplify this problem by illustrating the same scenario as having a 2-bit value memory action being split into two 1-bit memory action. So assuming that we have a memory location m which looks something like this:

From the diagram m is logically separated into to two 1-bit locations m[0] and m[1]. Let's assume that m starts off with 00_b as its initial value. Then m looks like this:

Now suppose that we have 2 CPUs concurrently executing the following code:

CPU1	CPU2
R(m)	W(m=11_b)

R(m) is a function that reads the value of m, while W(m) is a function that sets the value to m. In the case of our example, CPU1 is reading the value of m while CPU2 is writing the binary value 11_b in to m.

Logically if atomicity is enforced, then the only possible value that can be observed at any given time is either 00_b or 11_b. But in the case of longs and doubles, the specification explicitly mentions that no guarantees of atomicity is enforced.

Hence it is possible to timeslice memory updates in the following order:

As CPU2's execution is timesliced between the execution of CPU1, this results in R(m) return the value of 01_b, which is a transient value, but it is not a proper value to be observed.

It can be said that that CPU1 happens to be reading at the right place but at a wrong time. The volatile keyword in Java will resolve this problem, by virtue of the fact that it does not allow reordering of read and write actions, and hence by implictly disallowing read in-between write actions and vice-versa.

This has the effect of making read and write actions appear atomic, not that the read and write actions are implicitly atomic themselves. For a better understanding of what I mean by atomic, see my explanation on the difference between Atomic and Volatile.

Google Docs's Equation Editor does not Create Permalink Images

2010-05-22T23:29:00.000+01:00

I initially thought I could get away with it by linking Latex images for my equations directly from Google Docs to Blogger, but it seems that the image URLs are not permalinks, causing the images in my blog posts to be missing after a while.

Wordpress has a plugin to support this directly, but there's a nary of solution for Blogger.

Still trying to look for possible workarounds to this problem. Hopefully it's not one that involves manually copying and linking the images directly. :(

Difference between Atomic and Volatile?

2010-05-15T07:59:00.001+01:00

There seems to be a tendency for people to confuse an atomic action with a volatile memory access. This is quite natural, since they exhibit similar properties and makes it hard for people to distinguish between the two.

So what is the common property between an atomic action and a volatile memory? They both exhibit the property of total ordering. Let's assume for where is the set of possible actions a program can execute, and denotes that an action precedes action , then the property of total order means:

Literally, the set of rules mean (1) that for any action that precedes and any action that precedes , then the action must necessarily be the same action as . (2) If precedes , and precedes , then must precede . (3) must precede or must precede . These are just some mathematical (or convoluted) formalisms of saying any action is guaranteed to be in sequential order.

But that's where the similarity ends.

An atomic action is literally what it means: an action that is indivisible. Volatile memory only provides a guarantee of sequential order, but offers no guarantee that an interleaving of actions cannot occur. For an illustration, lets take a look at the following code:

a = 0;
a++;

Assume that 'a' is a volatile variable. From the code, we naturally think that the increment operator (++) will atomically increment the value of 'a' to 1, but this assumption is slightly faulty:

[a] = 0;
r0 = [a];
r0 = r0 + 1;
[a] = r0;

The square brackets between [a] denotes a value gotten from memory, while r0 represents a register in which the addition operation actually occurs. An increment operation is actually a composite action, composed of a read, then a write action. (By the way, it is implied that register actions are atomic, despite being a composite action. This is because an operation within a register cannot be directly observed).

So increment is a composite action, compared to being an atomic action, what's the harm? Lets go through the same example, but with 2 concurrent processors executing simultaneously:

CPU1	CPU2
a++;	a++;

Lets assume that a is initially 0 to start. Given that iff the actions from CPU1 and CPU2 are both volatile and atomic, then the only possible transition value that can be seen after execution can only be 2.

However, if the actions from CPU1 and CPU2 are only volatile, then the actions can translate to this:

CPU1	CPU2
r0 = a;	r1 = a;
r0 = r0 + 1;	r1= r1 + 1
a = r0;	a = r1

For all the possible decompositions of into uniprocessor- interleavings, one can see that it is possible that both registers r0 and r1 both read a as 0 simultaneously which causes the resultant possible values to be either 1 or 2. Clearly seeing 1 is wrong, since if the operation is atomic, then 1 cannot be a legal value at the end of the execution.

Conversely, a volatile variable can be deemed atomic. Consider the example below:

CPU1	CPU2
a=1;	a=2;

In this case, the only possible set of terminal values are 1 or 2, which is exactly the same as you would get for an atomic action. Therefore, a volatile memory access is atomic iff you perform only a read or write action, which are atomic in nature. But a volatile variable is no guarantee of atomicity if a composite action is executed.

Hence the label atomic actions is a slight misnomer, because it doesn't imply that the action is atomic, but rather it means that it guarantees a composite action is executed as a single atomic action. A well known example of such a composite action is the Compare-and-Swap instruction.

For simplicity, just remember that atomicity is not a property of memory, but a property its actions, to which a volatile memory access may or may not uphold.

Concurrency vs. Multi-Threading

2010-05-08T00:42:00.000+01:00

A lot of people tend to treat concurrency and multi-threading as the same thing. In many ways, they are correct given the similarities between the two. But when trying to reason program behaviour, teasing out the distinction is somewhat important. Concurrency, , is by definition multi-threading; but multi-threading, , is not necessarily concurrent.

To make it clear why concurrency is not strictly multi-threading, we start off by defining what concurrency is. Let be the set of all program actions and that and . Also, denotes that the action precedes action .

The explanation is actually straightforward when expressed in plain English.

The set of rules says (1) if all the actions in set precedes all the actions in set , and all the actions in set precedes all the actions in set , then the set of actions are equivalent; (2) for any action that precedes action , and any action that precedes action , then action precedes action . This is known as a transitive relation, but note that while this transitive relation describes an action, broadly this relationship holds within a set of actions as well. (3) All the set of actions in precedes all the set of actions in , i.e. this loosely means that if an action has happened before, then it cannot happen again, which is used to describe how program flows.

To put it simply, concurrency means that for a given quantum of time, there can be one or more program actions happening simultaneously. A set of actions on a given thread T1 will be causally ordered by only on the thread itself, however this set of actions may or may not have an ordering relationship with the set of actions on another thread T2.

Understanding what concurrency is, how is multi-threading different?

Consider multi-threading on a single CPU machine. In a uni-core CPU, all actions are totally ordered, ie no two actions can happen at a single quantum of time, but this is not the case for a multi-core (concurrent) CPU. Obviously, we can easily make a multi-core CPU function like a single core CPU, but certainly not the other way around, which is why .

Even though most times type programs are what we are interested in, we do usually assign an arbitary program order to these programs to make it functionally behave like a single-core program, which is much easier to reason with. You see these to totally ordered conversions from time to time, such as in my discussion of the Implementation of Volatile in the JVM.

To put it simply, threading is a way of describing program actions for concurrent programs, and sequential programs can also be reasoned in the context of threads, but not the other way round. For a simple illustration, consider the following program:


public class MyLock {
  private volatile int thread_id;
  public void lock ( )
  {
     int my_id = Thread.getID ( );
     thread_id = my_id;
     while ( thread_id == my_id ) { } // wait loop
  }
}

The code is multi-threaded; assume that there are 2 threads executing at the moment, and with thread T1, T2 returning IDs of 1, 2 correspondingly.

There is an interesting property with this piece of code - if the threads are concurrent, then eventually the thread_id value will change, and the code can never halt (and the threads will be fairly-scheduled as an interesting side effect). But if the threads are sequential, then one thread will enter the lock ( ) code, and halts the processor in a wait loop.

For those who may be interested, the code in this example is a part of an implementation of Peterson's algorithm, and a simple and poignant example to show how concurrent programs can be different from multi-threading ones.

The Implementation of Volatile in the JVM

2010-05-03T18:49:00.011+01:00

Scanning through the code between the JVM bytecode interpreter and the JIT compiler, I was perplexed to why an interpreter does not care to differentiate between a volatile memory field access to a non-volatile one, while a JIT actually emits special code to deal with it.

But after thinking though a while, I realise why this actually makes sense. Before we find out why an interpreter does not need to care about volatile semantics, we need to first understand the idea of causality, and then understand what the volatile keyword is for.

Lets start off with a very simple snippet of code:


a = 1
v1 = a

We expect v1 to have 1 because we put 1 into a, and then a into v1. The assignment of a = 1 necessarily orders before the operation of v1 = a. This necessity is termed as 'causal order'. Subsequently we use the notation a = 1 v1 = a to imply this causal ordering.

For illustration, we can show that not all program executions need to follow causal order:


a = 1
b = 2
v1 = a
v2 =  b

Assuming that v1 and v2 needs to be assigned the value of a and b eventually, then there is a causal order such that the execution of the statement a = 1 v1 = a, and a causal order of b = 2 v2 = b. However there is no such requirement needed between the statement of a = 1 and b = 2. In fact, if we swapped the order around, the program will continue to execute fine:


b = 2
a = 1
v1 = a
v2 = b

As long as we don't break causal ordering, executions that has no causal order requirements have an interesting property of parallelism. We are able to break the such programs into separate parts and execute them in parallel and still be able to satisfy program requisites:

CPU1	CPU2
a = 1	b = 2
v1 = a	v2 = b

But with multi-processors, we can violate program determinism quite easily if we are not careful. Consider the following example:

CPU1	CPU2
a = 1	a = 2
v1 = a

In the absence of any ordering restrictions, we term the execution as concurrent; it is legal for the value of v1 to be either 1 or 2. In practice this value most likely be 1 because of cache locality, but this is not a guarantee. Even though executions between CPU1 and CPU2 can happen at exactly the same quantum, we treat such concurrent executions as if they are a special case of interleaving; either CPU1's executions always happen slightly before CPU2's executions, or CPU2's executions always happen slightly before CPU1's executions. Corollary: CPU1's and CPU2's executions never happen simultaneously, hence can be considered to be functionally equivalent to a multi-threaded application. This resulting execution is known to have a partial-ordering, ie, the execution between CPU1 and CPU2 can be interleaved in any possible permutations.

For compiled languages like C/C++, there is no implicit notion of concurrency; this is also true for a just-in-time compiler within Java. No notion of concurrency is fine and dandy on a 1-CPU machine architecture, but not so on a multi-processor system or in a language that has a notion of threads. Let's understand why by first examining a simple single-threaded code:


a = 1
a  = 2
v1 = a
v2 = a
if ( v1 == v2 ) {
 v3 = true
}
return v3

If causal order is upheld, then naturally a = 1 a = 2 v1 == v2 == a == 2. On a single-threaded execution that is causally ordered, the resulting execution is also totally ordered. Hence, an optimizing compiler may say, "hey, why don't I skip all the steps and assign v3 = true directly, since v1 == v2 always holds?". In the end, the compiler generates the code that looks like this:


v3 = true;
return v3; // or  simply "return true;"

Now consider a similar, but multi-threaded code:

T1	T2
a = 1	a = 0
v1 = a	a = 2
v2 = a
if ( v1 == v2 )
{
v3 = true
}
return v3

Notice that both threads T1 and T2 still follows causal order. For T1, a = 1 v1 = a v2 = a, hence implies that v1 == v2 == 1. On T2, a = 0 a = 2 is shown as a trivial case of causal order. However, there is no total ordering enforced among the execution between the two threads.

For a given compiler, it is very difficult to be able to reason the ordering of execution across a number of threads, given each thread's execution sequence is normally examined in isolation. The reason for this limitation is simple: in order for a compiler to be able to optimise for causality safety, it needs to examine all executions across all threads; however it is theoretically possible for the number of threads to be (1) dynamically generated; (2) the number of threads generated to be unbounded and therefore infeasible to make such an analysis.

Usually the compiler will optimise on the assumption that causality safety is assumed, where the onus is on the programmer to indicate otherwise through the volatile keyword.

In the absence of the volatile keyword, the compiler is free to assume the following optimisation:

T1	T2
v3 = true	// does nothing, since a is unused
return v3; // or simply "return true";

Therefore, the volatile keyword means for all accesses of a, always emit the code for the accesses. By doing so, it retains the code's original execution and hence execution coherency.

This is also why the volatile semantics within an interpreter is always upheld.

As an interpreter always execute instructions line-by-line, therefore no inferences and optimisations actually occurs compared to compiled code. Thus the interpreter needs not enforce the volatile mechanic, so as long as the underlying machine architecture adheres to program causality.

And this behaviour should be safe on machine architectures like the x86, but on esoteric machine architectures that performs instruction reordering, eg. Alpha and Itanium, the interpreter may require some additional memory fencing instructions to ensure that volatile semantics are upheld.

Code Reviews

2010-04-24T18:30:00.002+01:00

Ever since I've read the book "Best Kept Secrets of Peer Code Review" a couple of years ago, I was cottoned onto the idea that code reviews are good things to have. The book cites many successful examples, like Cisco and other successful corporations, and surely they must be doing something right that is worth emulating?

When I first mentioned about my plan for a code review, one of the first things I wanted to know from the team was to find out their own experiences with the process. Among the various discussions we've had, one recurring topic that keeps getting cited as an issue for a code review is the lack of domain knowledge, or the 'Bikeshed Problem', as one of my colleagues puts it.

And he tells it like this: if you have a large development team, it's likely that the person assigned to review your code may not have sufficient domain knowledge to critique on the changes you've made. However, when you're told that your job is to 'find fault' with others, chances are, you will find them.

The lack of domain knowledge can hinder the process, not help it. It is plausible to believe that the only problems that you'll be able to spot are only the easiest ones - things like formatting, code convention and spelling. At the end of the process, you're most likely made not much improvement to the code, irritated your fellow colleague with trivialities, and wasted your own time.

He has a valid point.

Code reviews are meant as a process for locating defects, not a process of bickering over changes and causing friction among fellow developers. And even with the best of intentions, it is sometimes inevitable that frictions can occur within a code review process, given a code review is a task that relies on one's communication skill, and not solely a technical one.

But if a code review process can turn terribly wrong, does that mean it is be better than having no code review at all?

I don't believe so. Since we know that there bad ways of conducting a code review, we will assiduously avoid them. If we find something that works for us, we keep them. And we'll continually refine this process until it becomes a natural, unawkward and effective routine.

So far, even after months, this process remains as a 'work-in-progress', although there are a few emergent behaviours that are becoming clearer:

1) A code review process should not be all about spelling, formatting and comments about non-adherence to convention. if one is irked by spelling and formatting, then the reviewer should take the liberty of fixing it himself; they are not proper critique for a code review;

2) Code reviews are assigned to people in a random fashion, irrespective of how familiar the reviewer is with the domain of the code. This is to mitigate what we call a 'hit by a bus' problem, where if a developer is the sole person who understands the code gets hit by the bus, then it becomes difficult for someone else to take over the code. (Not to mention that we'll be very sad about losing a colleague too.) Besides the purpose of risk mitigation, the reviewer gets an opportunity to ask questions and further his own understanding of a different subsystem of the software;

3) The 'eject' button. Sometimes, the code can be too far off for a reviewer to understand without going deep into understand the design, architecture and nuances of the problem. If it is time consuming or difficult to review the code effectively, the code will be reassigned to somebody else who has better a domain knowledge understanding. And it works in our situation because our team works loosely in pairs, and at times even perform pair programming when dealing with larger and more intractable problems.

But I have no doubt about the merits of a code review process, although we should remember that part of the impact of a code review is a psychological one: people learn to code better through this process because of the behaviourial impetuses that drives them to work better. Because we're talking about people's pride, fear and ego here, there is absolutely a need to temper the process to factor any sensitivities involved.

The most important lesson I've learnt about a code review is that whenever it is a process that involves individuals, you'll always have to find your own right balance in conducting the whole process. Find out what works for you by basing your decisions on the nature of the software project and the team that you have - so don't be foolhardy to believe that all code reviews are the same, and there can be a 'one size fits all' solution.

A Little Less Efficiency and a Little More Humanity

2010-04-19T22:25:00.000+01:00

Singapore is a country that prides itself on its efficiency.

The country is efficient. Not as efficient as the Japanese, but not as polite either.

When things are not running smoothly, people whinge, threaten and complain.

Nevertheless, efficiency is expected of when I was growing up in Singapore.

And I never knew how refreshing the lack of efficiency can be. Until today.

It was the usual train I catch to work each day, and I was running late.

Chasing after the train as it was leaving the station.

I was not alone. There were a few other people, all running behind me, all hoping to catch it too.

We paused as the train slowly inched away from us.

And then it stopped.

The train driver had waited. Just for a few of us.

Nevermind it was off-schedule.

It was a beautiful illustration of humanity above efficiency.

As I made my way to the seat on the aisle, it left me to wonder, "Singapore, isn't it possible to just have a little less efficiency and a little more humanity?"

Calorie Counting Dinner

2010-01-31T16:22:00.000+00:00

Calorie counting is a futile exercise. Can you imagine yourself to be meticulously noting down every single thing you put into your mouth throughout the day? Even if you are able to count Calories with the accuracy of an accounting auditor, you will still never get exact numbers. Our food just do not come in standard calibrated units that happily lend itself to exact, precise calculations. Therefore is there any merit in such an exercise at all?

The science behind the Glycemic Index tells us that food is not digested at a uniform rate, and by similar reasoning, it is not unlikely that not all food is absorbed uniformly too. So even if 'a Calorie is a Calorie' seducively sounds like a single reducible truth, we are doing ourselves a disservice if we believe that food can be cut down to a single number alone. While I won't argue against having a rough ballpark number to work with, there should be some sensibility on not relying on it too specifically.

To the avid hard-core Calorie counters out there, let me satisfy you a little with my own Calorie counting exercise. Here is a snapped picture of what I normally have for dinner:

All the food is cooked in a steamer, seasoned with some salt, plus pepper on the trout that I was having. There are no cooking oil or any other added ingredients to what you are seeing, so what you see is what you get. I'll go through the breakdown of what was in my dinner:

Onion, whole
Beetroot, whole
Carrot, 1 stick
Sweet potato, 1/2
Asparagus, 8 tips
Coriander, 2 sprigs
Leek, 5 slices (not visible, under trout)
Rainbow Trout, 250gm

Let's try to calculate the total Calorie intake. It will not be accurate, but I'll give higher numbers on all my estimates just for argument:

Onion (94gm) - 41 Calories
Beetroot (87gm) - 37 Calories
Carrot (61gm) - 25 Calories
Sweet Potato (84gm) - 72 Calories
Aspragus (120gm) - 26 Calories
Leek (26gm) - 15 Calories
Rainbow Trout (250gm) - 387 Calories

Total Calorie Intake: 603 Calories

That's typical dinner, and sometimes with an additional fruit or cheese as dessert after. That is usually all for dinner, and I do not consume any more after I cleaned up my kitchen. If I make a simplistic projection of these numbers to a full day (x3 for breakfast, lunch and dinner), then I'm consuming less Calories than the standard daily requirement! So if the standard is to be believed, then by definition I must be starving!

Our environment is a complex one, and our bodies are miraculous complex organisms that have to deal with this complexity. We have many bodily functions that regulate themselves autonomously without conscious thought or control, and our body constantly adjusts itself based on the feedback it receives; we feel sleepy when we are tired, our bodies ache and stop us from hurting ourselves when we over-tax it, we get thirsty when we are dehydrated. Shouldn't that mean it is naturally correct that we eat only when we are hungry?

There is no reason not to trust our bodies to do the right thing. If I am not feeling hungry from my food intake, then my body is telling me that I am not in energy deficit. And I trust that my body is right. Who do you believe, your body or the standard conventional wisdom out there?

Food and the meaning in life

2010-01-23T15:47:00.001+00:00

I have not been writing for a while, you may have noted. What have I been doing with my free time?

These days I have been researching on a number of quite arbitrary and seemingly unfocused things, but even with all that arbitrariness, it still has much to do with my philosophising on life. If there is one notable aspect that has consumed my more of time these days, it will have to do with researching about nutrition. So how is that to do with philosophy? If you think about how much food actually affects your quality of life, then the answer is 'a lot'.

Food has always been an on-and-off topic between colleagues and friends, and it is still surprisingly a subject area that I can't seem to be able to form an objective opinion upon. There is a bewildering number of conflicting literature on the science of food, and nobody, not even medical specialists, seem to be able to come to an agreement of what actually is good for you. What we have out there today is mainly unquestioned conventional wisdom, versus various splinter food cultures with their advocates and strong opinions to boot.

One aspect of food nutrition that I am interested in has been the topic of weight loss. For those who know me, you will be challenging on why this would even be my subject of interest, given that I have no personal stake in dealing with any weight issues. True, but I have always been curious to why I'm a perpetual a non-gainer no matter what I eat, while others seem to put on weight on even the most minuscule of calorie intake.

Sometimes people blame it on genetics. It makes sense from an evolutionary aspect since some people are more efficient at storing extra energy than others, given that food supply was inconsistent in the past. It would have been beneficial for humans to store surplus energy, but I have my doubts that this is the key reason, given that the obesity problem has only surfaced within the last century - I'm willing to bet my money that it's more likely that the problem comes from the composition of our food itself.

Recently, one of my colleagues had completed his weight-loss regime. He had been going on a low carbohydrate diet, coupled with a sachet of weight loss formula, which he had good results in losing around 10lbs (4.5kg) within 3 months. The talk about a 'low carb' diet became a talking point as it reminded me of the Atkins diet that had been associated with a reputation of varying between effective and crazily faddish.

Given my current interest in food nutrition, I decided to offer some interesting, counter-intuitive opinions on his diet. Basically, I told him that his 'low carb' diet was essentially a 'high fat' one! Obviously he didn't seem happy with my explanation, since it flies in the face of conventional wisdom - you gain weight consuming fat, not lose it. My explanation was relatively simple, if not immediately obvious.

There are only 3 categories of energy sources we derive from food, carbohydrates, proteins and fats. It is not possible for someone to sustain himself purely from a protein only diet, as he would have suffered from a condition called 'rabbit starvation'. Proteins at high amounts is essentially toxic, aside one symptom that protein poisoning will have caused is ravenous, insatiable hunger. If that were the case, it would have been impossible for him to diet, since it is not an issue that can be subdued by willpower alone. Dieting in such condition is as futile as trying to stop yourself from breathing. Unless he's starving himself literally, his only viable energy replacement would have to be coming from fats.

I have no idea what he was eating during the diet period (hardly anything from my observation), but it was obviously likely that in the absence of any energy input through food consumption, his body would naturally utilise its fat reserves, causing him to lose weight. But I believe that weight loss through dieting is orthogonal to the real problem of keeping it off permanently. You do get quick and good results during short dieting binges, but it is equally likely that you'll regain it back as quickly as you have taken it away.

This is because the urge to over consume on your food has not decreased. It has been shown that willpower is a limited resource, and when you go on a diet, you are essentially pushing your willpower to overcome your urges given by your brain to consume (more) food. A diet is hardly anything natural or sustainable if you can only maintain it for a limited of time. Eventually your willpower will break down, and you'll go back to your normal eating habits again, so whatever loss you are seeing will be temporary.

The impetus to tackle weight gain is really to be addressing the real issue behind the problem over-consumption. The current science of blaming fats as a bogeyman to tackling the real problem, like any dismayal science, really isn't helping. It willfully ignores that fact that any food you eat will cause you to become fat when consumed in excess - it is just restating the laws of thermodynamics. Not besides the fact that I've seen plenty chubby friends despite being on a low fat diet for perpetuity.

I've recently watched this video titled, "Sugar: a bitter truth", by Professor Robert H. Lustig which has strengthened this belief. He labels sugar as the key cause of obesity, and presents a clear cut explanation of how sugar intake increases appetite:

Generally when a doctor puts his neck out against conventional wisdom, he is either convinced he is right or a crackpot out for fame and notoriety. I can only suggest to do your own research and make your own conclusions. There are good literature out there to suggest that obesity isn't the result of a high fat diet, but a high sugar one. Some might nitpick that it's very specifically high fructose, I don't disagree, but do remember that sucrose (table sugar) is one part glucose and one part fructose.

Sugar isn't categorically the culprit for obesity, but if it is a cause for driving your up brain signals to consume, then it stands to reason that an increased sugar intake will lead to over-consumption. And if willpower is expendable, the only sustainable way to ensure a permanent weight loss is to cut down on sugar intake.

I suggested to my colleague that the easiest solution to weight loss is to simply stop consuming all forms of added sugar. He was aghast.

"If I can't have my lollipops and cookies, what would be the meaning in life? I much rather be fat and lose a few years of my life than to stop eating sugar at all."

Which means to say that sometimes the most obvious solutions aren't always the easiest.

Isn't it remarkable that seemingly trivial things like food choices can be difficult when you have to make conscious, rational choices? Now isn't that worth philosophising about? Food for thought anyone? :)

Compiling Ruby 1.9 for Mac OSX 10.4

2009-11-28T17:19:00.002+00:00

This article contains specifics for installing Ruby on PowerPC MacOSX 10.4. Newer Intel Macs with > 10.4 OS has more updated dependencies and probably do not require the instructions described here; you shouldn't need to compile from source in that case as well - there are one-click installers for binaries for Ruby 1.9 on the Internet, look for it.

On 10.4 PPC, the default version of Ruby is 1.8.2. This version is now old for some of the ruby plugins to be installed, specifically rubygems 1.3.5 in my case. I won't go into the reasons here on not going for older versions of rubygems (Read here if you are really interested why), but since an upgrade of Ruby is warranted, instead of upgrading to the latest 1.8.x series, it might be worthwhile to try out the new features from the 1.9.x series instead.

In order to recompile ruby, you'll need Xcode from Apple. That will install the SDK for developing on Apple's MacOS, but more importantly, it contains the gcc part of the GNU toolchain required for compilation.

However the GNU toolchain is incomplete at this stage; we'll require at the minimum GNU m4, autoconf and automake to complete the chain of dependencies Ruby needs.

Not Using Darwin Port/Fink

I'm going to compile these things from source directly without any package management system, and for a good reason; 3rd party MacOS package management systems are usually more trouble than it's worth, either having longer compilation time from spurious dependencies, compilation breakages due to improperly configured parameters or missing specific compiler flags that you'll end up having to fix by hand anyway.

That said, don't be put off by the exercise of compiling from scratch. It is not difficult, and you'll get to learn a thing or two about the internals of your OS.

Open up your terminal, and sudo into root:


Tigershark:~ vince$ sudo -i
Password:
Tigershark:~ root#

In order to separate your newly compiled stuffs from your existing binaries, I recommend you create a separate directory under the '/' directory so that they will be cleanly partitioned. I'm using the directory '/lfs' in my example here, as a tribute to the Linux from Scratch project, where I got my derivative knowledge from. Feel free to choose your own directory names though.


Tigershark:~ root# export LFS=/lfs
Tigershark:~ root# echo "export PATH=$LFS/bin:$PATH" >> /Users/YOURUSERNAME/.profile
Tigershark:~ root# export PATH=$LFS/bin:$PATH
Tigershark:~ root# mkdir -p $LFS/src
Tigershark:~ root# cd $LFS/src

The code above creates the /lfs directory, and the '/lfs/src' directory as well. It also sets up the PATH environment to firstly look in '/lfs/bin' before it searches all other paths. This is necessary so that you'll be using your new binaries instead of the old system binaries. The same change is added into your user's .profile file so that Terminal will know to look for the new binaries in the future when it starts up.

Installing m4


Tigershark:/ root# cd $LFS/src
Tigershark:/lfs/src root# curl http://ftp.gnu.org/gnu/m4/m4-1.4.9.tar.gz > m4-1.4.9.tar.gz
Tigershark:/lfs/src root# tar -zxvf m4-1.4.9.tar.gz
Tigershark:/lfs/src root# cd m4-1.4.9
Tigershark:/lfs/src/m4-1.4.9 root# ./configure --prefix=$LFS
Tigershark:/lfs/src/m4-1.4.9 root# make && make check

Make sure that the test results come up without any errors. When the test results are satisfied, install it.


Tigershark:/lfs/src/m4-1.4.9 root# make install

Installing autoconf


Tigershark:/ root# cd $LFS/src
Tigershark:/lfs/src root# curl http://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz > autoconf-2.65.tar.gz
Tigershark:/lfs/src root# tar -zxvf autoconf-2.65.tar.gz
Tigershark:/lfs/src root# cd autoconf-2.65
Tigershark:/lfs/src/autoconf-2.65 root# ./configure --prefix=$LFS
Tigershark:/lfs/src/autoconf-2.65 root# make && make check

Make sure that the test results come up without any errors. When the test results are satisfied, install it.


Tigershark:/lfs/src/autoconf-2.65 root# make install

Installing automake


Tigershark:/ root# cd $LFS/src
Tigershark:/lfs/src root# curl http://ftp.gnu.org/gnu/automake/automake-1.9.6 > automake-1.9.6.tar.gz
Tigershark:/lfs/src root# tar -zxvf automake-1.9.6.tar.gz
Tigershark:/lfs/src root# cd automake-1.9.6
Tigershark:/lfs/src/automake-1.9.6 root# ./configure --prefix=$LFS
Tigershark:/lfs/src/automake-1.9.6 root# make && make check

Make sure that the test results come up without any errors. When the test results are satisfied, install it.


Tigershark:/lfs/src/automake-1.9.6 root# make install

Additional Step: Upgrading libreadline

Apple's implementation of the readline library has missing symbols in which Ruby (or more accurately, irb) requires in order to retrieve command line history. If you do not use irb (which I doubt, unless you never require testing some code you're uncertain of), you may skip compiling this. But I recommend you do :)


Tigershark:/ root# cd $LFS/src
Tigershark:/lfs/src root# curl http://ftp.gnu.org/gnu/readline/readline-6.0.tar.gz > readline-6.0.tar.gz
Tigershark:/lfs/src root# tar -zxvf readline-6.0.tar.gz
Tigershark:/lfs/src root# cd readline-6.0

Tigershark:/lfs/src/readline-6.0 root# curl http://ftp.gnu.org/gnu/readline/readline-6.0-patches/readline60-001 > readline60-001
Tigershark:/lfs/src/readline-6.0 root# curl http://ftp.gnu.org/gnu/readline/readline-6.0-patches/readline60-002 > readline60-002
Tigershark:/lfs/src/readline-6.0 root# curl http://ftp.gnu.org/gnu/readline/readline-6.0-patches/readline60-003 > readline60-003
Tigershark:/lfs/src/readline-6.0 root# curl http://ftp.gnu.org/gnu/readline/readline-6.0-patches/readline60-004 > readline60-004
Tigershark:/lfs/src/readline-6.0 root# patch -p0 < readline60-001
Tigershark:/lfs/src/readline-6.0 root# patch -p0 < readline60-002
Tigershark:/lfs/src/readline-6.0 root# patch -p0 < readline60-003
Tigershark:/lfs/src/readline-6.0 root# patch -p0 < readline60-004

Tigershark:/lfs/src/readline-6.0 root# ./configure --libdir=/usr/local/lib
Tigershark:/lfs/src/readline-6.0 root# make && make check

The instructions also contains the additional patches that was released since libreadline 6.0. Make sure you follow those additional instructions to apply the patches correspondingly.

Also, note that the ./configure parameter has changed. In this case, we are installing a library, so the path to install to is different. We are installing it to '/usr/local/lib', which will make sure that we won't conflict with the original libreadline in '/usr/lib'.

Finally, make Ruby!


Tigershark:/ root# cd $LFS/src
Tigershark:/lfs/src root# curl ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p243.tar.gz > ruby-1.9.1-p243.tar.gz
Tigershark:/lfs/src root# tar -zxvf ruby-1.9.1-p243.tar.gz
Tigershark:/lfs/src root# cd ruby-1.9.1-p243
Tigershark:/lfs/src/ruby-1.9.1-p243 root# ./configure --prefix=$LFS LDFLAGS=-L/usr/local/lib
Tigershark:/lfs/src/ruby-1.9.1-p243 root# make && make install

Note the additional parameter 'LDFLAGS=-L/usr/local/lib' that we pass to './configure'. This is required so that when ruby gets compiled, it'll first search '/usr/local/lib' for it's library dependencies before looking at its system default paths. Because we have our new 'libreadline' installed, this makes sure that Ruby is compiled with our newer library instead of the system one.

Congratulations! Once you've reached here, you have your new shiny Ruby 1.9 interpreter to play with! To check:


Tigershark:/ root# which ruby
/lfs/bin/ruby
Tigershark:/ root# ruby --version
ruby 1.9.1p243 (2009-07-16 revision 24175) [powerpc-darwin8.11.0]

Why you should Blame your Tools, sometimes.

2009-10-01T23:57:00.000+01:00

As software developers, we would all wish to have 3rd party libraries that works magically immediately after installation. While this is to be expected and holds true for popular and widely used libraries, people do tend to forget that it is still more of a rule of thumb than an iron-cast fact.

Like the urban myth goes, "a good workman never blames his tools", this mindset is so ingrained in the software development culture, that it is always bad form to assume that bug may reside in a library rather than in your code. After all, it is more likely that you are the offending culprit, given it is less likely a widely used code base will make a mistake when compared to code just seen by you alone. But with everything statistical, there is always a chance that an outlier event can happen.

And it did for me.

Internally, we rely on log4cxx as our logging library, which a peculiar bug seems to only be triggered upon the termination of our application. After spending more than 2 days of debugging, the error seemed to have consistently been at the line where the logger object is being accessed. And like all true developers, I bit my lip and kept soldiering on, reading through my own code, checking the same lines over and over again, trying to see if I had missed defining a variable, or if I had forgotten to allocate memory for it. Naturally, after while of doing so, I began to start questioning my personal sanity rather than the lines of code I've written, amid this 'impossibility' that the error could actually be from the library.

And then I popped.

I turned over to my colleague and mentioned to him that the code kept failing on the logging line. The team had known that I've been stuck on this problem for the last day. Even as I started, I could see the mild derision on his face, "it can't be the library. Maybe gdb is not showing what actually is going on."

So on and on the circle I went. Then someone else suggested using valgrind.

Since I was running out of options, I didn't see any harm trying. At most I'll waste an hour more to the day I've already wasted, anyway.

Valgrind didn't really show anything more different to what gdb was showing. Basically saying the same thing - that log4cxx is accessing an invalid memory location. Given I wasn't an expert on valgrind, I got someone else to come over and discussed what we were seeing on the stack trace.

No luck still.

It's gone past the point of frustration, into the point of desperation that I decided to just fucking comment out the offending statement and see if the problem goes away.

After recompling and re-running the application 30+ times without the bug re-surfacing, I was very certain to point at the logger library being the culprit. But of course if I did, I couldn't definitively prove it, and worse, I had no workaround; the entire code base is reliant on it for logging, and to take it away would mean a major re-engineering exercise.

Sometimes talking to others help. Sometimes they offer a difference in perspective, and other times, they may have caught something you hadn't.

Given that we had multiple threads that were still operating when a shutdown signal is received, I thought maybe it'll be worth trying to stop those threads safely before the termination signal is processed - since it's likely that some portions or memory may be freed while the threads are still utilising them. But I was just shooting wildly - it was a very long shot, given how the threading interactions were designed, it was difficult to believe that it could have been the problem. But trying something is better than doing nothing.

So I sat down with another colleague of mine, and talked him through what I wanted to do, and invariably the discussion lead to another where we talked about the valgrind backtrace that I had generated, which showed memory destruction caused by exit(). After a bit of theorising back and forth about the behaviour, and on how I'd would write a quick hack to test my hypothesis, my colleague decided to do a ubiquity search on 'log4cxx exit crash^H^H^H^H', which then our eyes popped when we saw the preview result before it changed into something else that he was meaning to type.

"Go back again", I said excitedly. He was already as excited as I was, so there wasn't really the need for any prompting.

It turns out that there is a known problem in log4cxx found months ago, and someone had even posted a patch on it already. But here's the thing about software: unless you are willing to roll your own fixes, be prepared to wait for a long time before someone eventually fixes it. And even if someone did fix it, the upstream maintainer will still take a while before committing it into the main trunk. Or even worse, he may just choose to ignore it. And yes it does happen - ask Ulrich Drepper. :P

On how to fix it, and package it up nicely for use, I'll write about that in a later post, for now I want to share an invaluable lesson when it comes to software development, which also equally applies in life: while established conventions are more often right than wrong, it never hurts to question them just in case they aren't. It may not be okay to blame your tools all the time, but it sometimes worth to know when to call a shoddy spade when you see one.