The Gods Themselves by Isaac Asimov

The Gods Themselves by Isaac Asimov

My rating: 5 of 5 stars

I started reading this book, when I found that it was a Hugo award winner and I was looking for some intellectually entertaining science fiction. It didn't disappoint me. OTOH it turned out to be one of the best scifi novels I've ever read.


It takes real imaginative power and also thorough knowledge of science and technology to weave a story around them. Asimov has tackled three extremely imaginative topics - Parallel Universes, Procreation that takes 3 individuals of a species instead of 2, Life on Moon - and he has done full justice to each one of them.

View all my reviews

Why OpenGL ES is so hard?

Because it takes minimum 76 lines of code to produce even the least meaningful output - A straight line. (And that too, only after doing unfair hard coding of matrix values)

Gist

[Do not confuse OpenGL ES with OpenGL. It might be possible to write a shorter program to do this task in OpenGL, but in OpenGL ES you need to use shaders even for the shortest of programs]

How to print stack trace anywhere in Javascript

It's well know how to print a stack trace after catching an exception/error in Javascript. But what if you are not catching anything? You see something happening at a particular line in code, but you want to know what's the code path through which the control flow reached that line when that interesting thing happened. In other words, you want to know what's the stack trace (series of function calls, starting from beginning of the program), at that particular line of code.

It's quite easy. If you don't have an exception, create one. Then you can print the stack trace off of it. Like this (gist) ...

How to debug WebWorker threads?

WebWorkers offer your Web app a way to do multithreading. If your advanced web app does some number crunching keeping the CPU busy for a while, then it makes sense to do it in a separate thread instead of doing it in the main thread, which may lead to blocking the browser tab (Chrome) or the entire browser (Firefox and others). One of the troubles of writing programs in WebWorkers is, they are hard to debug. Two key mechanisms required for debugging a program are not available in WebWorkers - print statements (console.log is not available) and breakpoints (even if you manage to place breakpoints in the code running in WebWorker, they won't be hit).

During my work on 3DTin, I have learnt couple of techniques that help me debug my WebWorker code.

1. Use postMessage as replacement for console.log

postMessage is how you send some data from the WebWorker thread to the main thread. This is the primary way of returning the result of the computation you perform in WebWorker. But we can use it for other purposes too. Here is how you can use the postMessage mechanism for communicating both the successful response as well as debug messages.

2. Catch exceptions and send their stack trace over postMessage

When an exception occurs in the code running in WebWorker, the debugger will print the line at which exception occurred, but not the entire stack trace. In most cases the whole stack trace can help you find the root cause quickly. To achieve that, place most of your code that runs in the WebWorker inside a try-catch statement. Then in the catch clause extract the stack trace of the exception, format it nicely and send it to the main thread using postMessage, as discussed in the first technique above. Here is the exception handling code that helps you extract stack trace at least on Google Chrome and other Webkit browsers. I have cherry-picked it from the stacktrace.js library. If you need a browser agnostic solution, paste the stacktrace.js library at the beginning of your WebWorker code.

I hope this makes your life easy while debugging WebWorker code.