This summers I was in Germany for my internship. On the weekends I backpacked across different places around Europe, visiting:

  • Freiburg (Germany): It is small town extreme south of Germany. It was where I stayed during the three months. It is a nice and warm student town and you get really awesome beer at the Feierling Beer Garden.InstagramCapture_4fa7c98b-dc0a-42e3-9173-979ad2e9bc95_jpg

Continue reading

The Benevolent Dictator

They were new. They were the change. But they heard another change was coming. A new dictator – a symbol of hope supposedly.

He came, but he didn’t like change. He was stone, indifferent to the outside world. He was a conventional slave, who was scared from trying out the new.

It was massacre, one by one he played his moves. These people opposed to the injustice, the oppression in the most gentle way possible. He was ruthless, unwilling to listen to anything. He did not respect women, nor did he follow the standard protocols of running an empire. He left every other minister with no choice but either to follow him or die.

Alas! These new people, their philosophy, all were at the verge of extinction, but he didn’t care. What had they done? They tried to make him understand their value with logical arguments. But given a dictator that he was, he didn’t allow them to speak and hardly met them.

The decision was taken to banish them, to ensure that no further new people is ever born in the state. These people being constitutional beings, looked forward for redress. They had only hope on their side, a hope for a brighter future, a hope for a better world for everyone.

A Brainf*ck JIT

I recently came across an article by Josh Haberman on the web which demonstrates how to make simple fun JITs, with the help of LuaJIT. I am still a beginner in the field of compilers and JITs. So I tried to implement a Brainf*ck JIT with the help of GNU LibJIT library. It proved to be a really entertaining exercise. The results are up here on Github.

The fun is in the part where we directly emit the machine instructions while reading source. The JIT doesn’t make any optimizations to the code, it just directly converts to the machine instructions.

Wikipedia tells us what each of the BF instructions correspond to in C. This makes it easy to write the corresponding instructions for the JIT. The entire BF program is defined as single function that when once compiled will run. I’ll take up sections of the code from bf-jit.c and lookup what they do:

case '>':
    tmp = jit_insn_add(function, ptr, uptr);
    jit_insn_store(function, ptr, tmp);

The > instruction increments the current pointer by an unit address value. The uptr value is defined to have a pointer of unit byte length. Once we do the add, we store the new value back to the ptr (since, ++ptr is equivalent to ptr = ptr + 1).

case '+':
    tmp = jit_insn_load_relative(function, ptr, 0, jit_type_ubyte);
    tmp = jit_insn_add(function, tmp, ubyte);
    tmp = jit_insn_convert(function, tmp, jit_type_ubyte, 0);
    jit_insn_store_relative(function, ptr, 0, tmp);

Similarly the + instruction loads the values from the address stored in ptr. We add one to the byte value and type cast it to ensure that it is still a byte value. We then store the result into the address contained in ptr.

case '.':
    tmp = jit_insn_load_relative(function, ptr, 0, jit_type_ubyte);
    jit_insn_call_native(function, "putchar", putchar, putchar_sig, &tmp, 1, JIT_CALL_NOTHROW);

Here the . instruction prints the character pointed to by the ptr. Then we call a native C function, putchar that prints the character on the screen.

Making the loop constructs are the most interesting part. We defined a struct that has the labels to the start and end of the loop in the program. It also has a pointer to the parent loop, so that we can return to the parent loop.

case '[':
    loop_start(function, &loop);
    tmp = jit_insn_load_relative(function, ptr, 0, jit_type_ubyte);
    jit_insn_branch_if_not(function, tmp, &loop->stop);

The condition the loop is the value pointed to by the ptr. We load that value and then use to decide whether we should branch on the loop, depending on whether it is 0 or not.

We then compile the JIT function and then call the function. The results of the benchmark by running the Mandelbrot code were really interesting:

Implementation                      Time
Mandelbrot (C Unoptimized)       22.343s
Mandelbrot (C Optimized)          1.241s
Mandelbrot (BF Interpreter)       8.304s
Mandelbrot (BF JIT)               3.918s

The unoptimized JIT is 2x faster that the optimizing interpreter. Though we are nowhere close to the optimized C code, but the gap can be narrowed by making some optimizations to the generated code.

Future work can be done in constructing an IR of the source and making an optimization pass, for example ++++ can be converted to +4 directly then, instead of +1 instruction 4 times.

Certain references that really helped are:


I made a few optimizations to fuse the multiple increment/decrement and pointer movement operations into a single one. The benchmarks from my JIT is now much closer to that of the optimized C version. The latest benchmark results are:

Implementation                      Time
Mandelbrot (C Unoptimized)       22.343s
Mandelbrot (C Optimized)          1.241s
Mandelbrot (BF Interpreter)       8.304s
Mandelbrot (BF JIT)               1.609s

Maybe I should look at implementing these optimizations next.

Knocked out of Node Knockout

I had spent this Saturday participating in Node Knockout. I had planned for a little Travelogue web app called Mapvel, with which one can share his experience about the current location, hence other users can get what people think about a place. I was planning to make use of a person’s real location by using the HTML 5 Geolocation API.

My team name was Struggler, that shouldn’t be a surprise considering that I am making this post.

But then things went downhill from there. I got this idea around 10 hours into the competition. Then I realized that to store Geolocation and perform spatial queries, I would need to use MongoDB. But this was the first time I had even planned to use it. Then I thought, lets make people sign in with Twitter, oh well, this was the first time I was implementing OAuth stuff in Node.js. Hence most of my time was spent in reading the docs and playing around with these. The build part comes later.

Apart from that there were some awesome happenings in college (I am being sarcastic!) and I also have 4 project submission to do this week. Excuses aside, I sat Saturday evening and night and got a basic version of the app running. Twitter login worked, MongoDB worked, I started hating Jade even more. Today morning I woke up and decided to give up.

It was good experience, I was coding fast, and learning fast as well, I just implemented login with Twitter and was querying MongoDB in few hours. Maybe I’ll get back to completing this Mapvel some other time.

Fun with morse code

Few days back I sat down and cooked up something, an esoteric language made only of Morse code characters: . and _. I won’t call it a full programming language per se, but then it can be used to make some fun stuff (without the codes making no sense by themselves).

Mind you, don’t try to develop anything useful with it, (it just has basic stack manipulations and arithmetic operators on integers). If you can make something with it, I would send you a cookie. :)

The docs are up on the website and source code is on GitHub.

In the meantime here is a morse “Hello” program.

_.. __.____
_.. __.__..
_.. __.__..
_.. __.._._
_.. _.._...

Recollections from the Mozilla Summit

Couple of weeks back I was at Mozilla Summit at Santa Clara, USA – a grand get together of people who contribute to people. This was the first time i was meeting the first global Mozilla community, the first time I went outside India. It was a massive effort to bring the paid employees as well as the voluntary contributors at the same place. I got to meet and talk to people with whom I had only been talking on IRC.

Mitchell Baker’s keynote on the Nature of Mozilla, really set the mood for the Summit and it best defines why Mozilla exists and why we all gathered over the weekend to discuss the future goals and plans for Mozilla.

The event lineup was well thought of, to keep you interested and give you options to choose from the tracks going on at parallel. I met so many people I probably don’t remember the names of quite a few but some were Brendan Eich, Asa Dotzler, Brian Bondy, Brandon Benvie, Alon Zakai, David Herman and so many others. It was great to talk to Luke Wagner over the internals of SpiderMonkey, Mozilla’s JavaScript Engine and JITs. I also had a chat with Patrick Walton over Rust and Servo and both the projects really look promising.  Randomly bumping into new people while playing Guitar Hero and getting to talk to them is another great thing about these events.

It was very informative to see the demos and talks about the upcoming projects and products we are working on, advances with respect to performance of FirefoxOS, brainstorming on the different products and discussion about how we can improve the Mozilla ‘platform’ code, sessions about Servo, how to appreciate contributors and so many others. At Innovation Fair booths I could interact with all these people who are working on these projects, and it gave much better insight.

It was a great event, I felt a part of the common cause, of a shared vision — of an open web.

PS: Thank you Mozilla for the free passes to Great America, the amusement park was one experience I will never forget.

GSoC: The final wrap up

This is the final round up of the work I did for my Google Summer of Code project – “Autosuggestion of Search Engines” for Mozilla Firefox. It was a great experience.

The module initiates with the launch of the browser and raises notification when it finds that you have been submitting some search forms. The GUI part of it has not been implemented yet, as it was one of the non-goals of the project. The algorithm that I had proposed has been completely implemented. The code has test coverage for operation of the algorithm and to check for the proper functioning of the disk I/O.

The raised notification can now be used by any of the modules in the Firefox code to do something. I have kept the documentation of the module in the Mozilla Wiki.

It was a great experience, and I plan to work on all the follow up bugs that come up for the module. My patch is up for review at Bug 335448 and will merged to the source tree after that.

I would like to thank my mentor Matthew Noorenberghe of Mozilla, for giving me all the advice and support for the project, tips on improving performance and code quality.

GSoC: Towards the first deadline

Today is the soft pencils down date for GSoC 2013. My work is almost done. From the last update, I made some changes to the following things:

  1. Removed a lot of unnecessary methods and clubbed many of the functions into a single one. So now the code is more manageable.
  2. Add a few browser preferences to toggle Autosuggest Search Engine feature on and off.
  3. Saved a lot on the I/O front. Now the module will save to disk after every 5 minutes to prevent a lot of disk I/O. It will also save the data just before the browser is closed.
  4. Better tests – now has tests to check if the disk I/O functions are behaving properly and also if the most likely search field element is being predicted correctly.
  5. Also got my patch reviewed by Gregory Szorc [:gps], to get feedback on the build front. A lot of boilerplate in the Makefile has thus been reduced.

GSoC Project Update

It has been a long time since the last update! The project has shown a lot of progress since then.

  • The algorithm for detecting the form submissions and detecting heuristically whether it is a search form now works perfectly (according to what I had proposed initially).
  • I struggled for sometime on integrating the frecency metric for a website from the Places API. But now this is done, and it checks against the frecency score of a website before marking it as a positive result. Simply put, we now measure how frequently you have visited the website and that will also be used to say whether the form is relevant enough to be a search form.
  • I had written some basic automated mochi-tests for the mid-term evaluation. Now the tests are better, the pains of testing the algorithm is over. Yay!

Progress is found in Bug 335448.

At the moment, when a positive result is detected, a notification is raised in the browser. Any consumer can listen to the notification to get information about the site that has been detected with a search engine. An ideal use case would be to implement a GUI to allow the user to add the website as a search to the browser. This was a non-focus goal for the project, so will be tracked by a follow-up Bug 879155.

ARM Development Environment on Linux

This post is intended to the Systems Science students taking the Embedded Systems course at IIT Jodhpur.

The Keil IDE is inefficient to do normal programming for the ARM platform, and setting up a virtual machine on an ARM processor is too hectic. But it turns out QEMU can run the binaries using the host OS itself, so its dead simple to set up an ARM system on your Linux.

I will be using the Ubuntu distro for the same.

Install the following packages from the Terminal.

$ sudo apt-get install gcc-4.6-arm-linux-gnueabi libc6-dev-armel-cross qemu-user-static

Write some assembly in your text editor. There are some differences from the syntax taught in class.

There is no AREA and ENTRY directive. Instead to define an entry point for your program use a label _start. Then on top add

.globl _start

to signify that it is the global start for your program. Also any label needs to be followed by a :.

Here is a sample program that calculates the factorial of 10.

To assemble this execute:

$ arm-linux-gnueabi-as -o factorial.o factorial.s

To create an executable file:

$ arm-linux-gnueabi-ld -o factorial factorial.o

Just to verify that the files you created are for the ARM platform, you can do:

$ file factorial
factorial: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped

Finally to execute:

$ ./factorial

Hence, we have a fully functional ARM build from our host Linux system itself.

GSoC Project Report Update

I know, this update is coming after a long time. Here is a quick list of what works and what needs to be worked on:

  • The basic form handling and score calculation works. It still not the exact algorithm that I had proposed, but we will get there.
  • Right now I have been doing some manual testing. Will be writing automated test cases once the detection stabilizes.
  • I haven’t started working on the UI front. I guess that would be once the above two is done.

You can track the progress of the work on Bug 335448.

Shoes, Socks & Presentations

After listening to Steve Klabnik‘s talk in RubyConf India, I really wanted to try Ruby and Shoes as well. After messing with it for few hours, I came up with Socks.

Socks is a Shoes app that takes in data in JSON format and renders them on screen. Its designed to be used as slides for presentations, so supports only text and images.

The best part is that you define your GUI in a declarative language in the JSON format. This is very much simpler to the CSS styles, so its real easy to get started. Moreover your slides are just your data, so you can write software on any platform to read them. (Data freedom? Yeah!)

This produces a window like this:


Or you could write:


You can put all this together and Socks will create a nice presentation for you.

It renders just text and images now. Go give it a try, its on GitHub. Any help for Socks is appreciated, so just fork and send me a pull request!

Why should you be at RubyConf India

Warning: This post is a non-Rubyist’s take on RubyConf India. Forgive me for my inaccuracies.

I’ll accept it right at the beginning, I don’t do Ruby (forget Rails), having dabbled with it previously I knew just bits of it. And when I got the opportunity scholarship, there was no reason not to go.

Reason #1: Ruby is nice, and so is the the Ruby community. Trust me, the Ruby community is one of the best that I’ve ever seen in my life. People are so friendly, progressive, open to discussions and ideas. Really amazing!

Reason #2: The star cast at RubyConf India is pretty good. Let me list it out – we had Steve Klabnik, Jim Weirich, Aaron Patterson, Andy Lindeman, Nick Stutter, etc. Nothing is better that hearing the best from the pros.

Reason #3: So many stories at one place. Yes, you get to hear the stories of so many people – each being an inspiration in itself. The times when Aaron Patterson says he is a college dropout thrice, denied the opportunity to study at University of Washington but then goes and teaches there for years, you feel no matter how bad the situation is, you can always get better.

Reason #4: Ruby is for everyone – BRails. This really drew my attention – how much do we think about the physically challenged when developing products? Siddhant’s though visually impaired served as an eye-opener for everyone. He had be developing with Ruby and Rails for quite a few years – and developing teaching materials for the others.

Reason #5: You can do cool stuff with Ruby and rediscover old school concepts again. Places where representation of the data matter more than just numbers. Parallelism can be both your friend and enemy (just like MRI and JRuby can be), how you can dive into Unix system calls from Ruby itself. Last but not the least a bit of Rock and Roll with Ruby doesn’t hurt either. For those who are wondering, what I am blabbering you should take a look at the list of talks.

Bonus Reason: The beer parties after conferences are always awesome.

Personal Takeaway: Do more Ruby and use it for more of my personal projects. There is a lot that can be done with it.

The value of Re. 1

This weekend was at Ooty, also known as the blue mountains or Nilgiris. When I came to Bangalore little did I know that I would be going to Ooty 7000-8000 feet above the sea level. Well, I did not have any warm clothes, no sweaters/jackets. What followed was two days of shivering cold, but full of enjoyment.

We traveled a lot, the lush green valleys and mountains were a welcome break from the hectic life in Bangalore. I had different kinds of tea – Masala, Chocolate, Plain (an achievement in itself). The tea gardens of Ooty  had some magic of its own.

But, still the ultimate take away from the trip was the moment when we stood at the highest peak of the place without any shirts on, and everybody else was wrapped in sweaters. I still remember the look on the faces of the rest of people (awestruck by our heroic feat – seriously?)

To end the story, our last night at Ooty was too good. We ran out of cash (barring the 100 bucks I had saved up for emergency) and entire Ooty also ran out of cash. You got it right, all the ATMs in that place were out of cash too. Turned out we didn’t even have enough to have dinner. After searching our bags we collected Rs. 7, in all one rupee short of Rs. 108 – the bare minimum required for 3 people’s dinner. Whoever designed that Airtel ad, you did a very bad job. That 1 rupee was gold for us at that time. Nevertheless, the guy turned out be nice, served us food!

We returned that night from Ooty. It had left a soothing impression on all of us. I now miss nature in that form.

I have uploaded selected few photographs at Flickr. Check them out if you want to.

Note to Self

This is a note to myself and to anybody else reading this blog. These things have been helpful in college and also go a long way in helping others too. So I just thought of jotting them down.

  1. Document what you do: You always experiment, try out cool things everyday (they may not seem cool to you, but it maybe for others), just take some time out and make a note of that, write a blog post. Not because that would be show-off but because it will go a long way in inspiring and helping your juniors or any other person from outside your college as well. I can vouch for it because there have been many blogs from whom I have taken inspiration.
  2. Be passionate for engineering: Make things, create! Its the best way to have fun, when code that you had been hacking on runs, or the Arduino LED glows, the ecstasy is incomparable. At the end you will end up tinkering with a lot of things and a whole bunch of messy ideas in your head.
  3. Give back: You will always find yourself looking up answers on Google, Stack Overflow and the like. Take a moment after you solve your problem, share it with the world, answer a few questions on Stack Overflow, or on our group. Improve the community as a member, because if others hadn’t contributed you wouldn’t have found the answers.
  4. Open your eyes and ears: Look outside your world, there are a lot of great people to meet and find out. Keep yourself updated with the latest from the tech world. Read other blogs, HN, etc.
  5. Re-invent the wheel:You can go ahead and try to make a square wheel (doesn’t matter if you fail), the experience that you gain along the way will be what will be valuable to you. Don’t be afraid to re-implement something because it already exists – who knows, yours could be different or better?
  6. Find your specialty: That one thing that you are good at, do it often, iterate until you are good. You find yourself drawn to cool user-interfaces then just do HTML/CSS just don’t for Python because your friend is doing it. As it is stated in the Unix Philosophy – “Do one thing, do it well!”

Following points have been added by Rishi Ayyer, and I feel they will be an useful addition to this post.

  1. Travel: Because you need to get out of that comfortable armchair, with the comfortable food and sleep that you know will be there. Don’t worry, it’ll be there when you get back. But go and have an adventure. You’ll learn a lot more in just a few days roaming out in the world, from practical problems, to meeting people who “do” in the real world.
  2. Be versatile: Yes, it’s good to have a specialty. It’s great if you’re a master at it too. But be open to other aspects, other interests. Always approach situations with an open mind, and an eager heart. Learn to be interested in various aspects of a particular thing. One-dimensional views can be misleading, and won’t help you build a “system” or “product”. At the end of the day, that’s the aim.
  3. Learn to code: It’s my greatest regret. And I know that’s it’s indispensable today. (Though I myself agree somewhat with this, but still I prefer my own #6)
  4. Take charge of your life: Don’t let life happen to you. Make life happen. To quote Marley, “Live the life you love. Love the life you live.”

PS: These viewpoints are purely personal and in case you have something to say, please leave a comment.