It is commonly known that Twitter allows 140 character messages, and some will tell you that a single SMS message is limited to 160 characters. However, it’s not as simple as that. In the US a single SMS message can contain 140 bytes of data, which if using GSM encoding, we can squeeze up to 160 7-bit characters. Those 7-bit GSM characters don’t match up with normal ASCII characters, and even worse, not all characters take 7 bits, some take up 14 bits (for example the { character)!

When we start talking about messaging in non-latin scripts, such as Chinese, then a different encoding must be used. In the SMS world the encoding of choice is UCS-2, which uses 16 bits per character. This limits a single part message to 70 characters (down from 160).

On top of that, most SMS clients will let you send concatenated SMS messages. That is, multiple message parts that appear as one long SMS message. A two part message allow up to 304 characters, not the 320 (160×2) you might expect. This is due to the overhead required to store meta data about each part.

This all makes it very hard to count how long a SMS message will be, what characters are allowed, and how many parts it will take. To help with these isuses, I’ve created this simple tool which allows you to type out your message, and see how well it’ll fit

https:/blog.bramp.net/sms/

I’m happy to announce one of my projects, js-sequence-diagrams. This uses Javascript to draw UML sequence diagrams in SVG format. Here is an example:

You can alter the diagram in real time, and I even have a simple jQuery plugin to make this easy to use on your own sites.

<script src="sequence-diagram-min.js"></script>
<div class="diagram">A->B: Message</div>
<script>
$(".diagram").sequenceDiagram({theme: 'hand'});
</script>

I’ve started using JSHint to check my javascript. One error I encountered was:

Errors:
     85,5:'grammar' is not defined.
Warning:
     85,1: 'grammar' is an implied global variable.

This is saying that I’m using some variable that I’ve not declared in my javascript file. In most cases that would be a mistake, but in my case I was expecting it to be in the global scope included from another javascript file.

To make JSHint stop complaining about this, you can simply place the following at the top of your javascript document:

/*global grammar */

This will tell it that the variable is declared at a global scope. Check out one of my projects for example.

I’ve been modifying an existing nodejs extension, that wraps libcwiid (a C library written to interface with a Wiimote). This extension uses polling to check if the state of the Wiimote has changed (such as a button being pressed). Libcwiid however provides a callback mechanism to be alerted as soon as a state change occurs. This has the benefit of being instantaneous, instead of at the polling interval.

While adapting nodewii to use this callback mechanism I learnt a couple of things about developing multi-threaded nodejs extensions that I thought I’d share.

1) All V8 operations must run from the main thread

Nodejs uses a single thread for executing the V8 JavaScript engine, and multiple worker threads to execute longer running non-JavaScript blocking tasks. Because V8 is not thread safe, all V8 operations must be executed from this single V8 thread. That means you are not allowed to create V8 objects, integers, strings, etc, from any other thread. If you try, race conditions happen, memory get corrupted and nodejs is likely to crash. Helpfully, nodejs does provide a mechanism to simplify using these threads:

eio_custom(eio_cb execute, int pri, eio_cb cb, void *data);

This function allows you to execute a blocking task in a worker thread. Once that task is finished another callback is called on the main JavaScript thread. Multiple extensions use it, and this is the basis for how nodejs provides it’s callback mechanism. Here is a very short example (adapted from wiimote.cc) of how to use eio_custom.

Handle<Value> WiiMote::Connect(const Arguments& args) {
  WiiMote* wiimote = ObjectWrap::Unwrap<WiiMote>(args.This());
  Local<Function> callback;

  HandleScope scope;

  // Pass the arguments like you would any other method
  if(args.Length() == 0 || !args[0]->IsFunction()) {
    return ThrowException(
      Exception::Error(String::New("Callback is required and must be a Function."))
    );
  }

  callback = Local<Function>::Cast(args[0]);

  // Create a struct to pass into worker thread
  connect_request* ar = new connect_request();
  ar->wiimote = wiimote;
  ar->callback = Persistent<Function>::New(callback);

  // Add a reference to the wiimote, so it isn't garbage collected between now
  // and the callback being run
  wiimote->Ref();

  // Add reference to the EV (JavaScript) thread
  ev_ref(EV_DEFAULT_UC);

  // Schedule the Connect function to be called.
  eio_custom(Connect, EIO_PRI_DEFAULT, AfterConnect, ar);

  return Undefined();
}


int WiiMote::Connect(eio_req* req) {
  // This method is running in a worker thread, and NOT the main nodejs
  // thread. This mean you can't use any V8 methods.

  connect_request* ar = static_cast<connect_request* >(req->data);
  // Do some work with the connect_request, and put the results back into the struct
  ...

  return 0;
}

int WiiMote::AfterConnect(eio_req* req) {
  // Once the "Connect" method has finished, this method will be called on
  // the main nodejs thread. This means we can now use normal V8 methods.

  HandleScope scope;

  // Retrieve the info from the request
  connect_request* ar = static_cast<connect_request* >(req->data);
  WiiMote * wiimote = ar->wiimote;

  // We no longer need a reference to the follow things
  ev_ref(EV_DEFAULT_UC);
  wiimote->Unref();

  // Create some JavaScript objects, and call the callback
  Local<Value> argv[1] = { Integer::New(ar->err) };

  TryCatch try_catch;

  ar->callback->Call(Context::GetCurrent()->Global(), 1, argv);

  if(try_catch.HasCaught())
    FatalException(try_catch);

  // Now cleanup!
  ar->callback.Dispose();
  delete ar;

  return 0;
}

This simple pattern makes writing callback code relatively simple. However, this only works well if you are in control of creating the callback.

2) How to run something on the main thread without eio_custom

Libcwiid creates it’s own thread, which is uses to read data from the wiimote. When data is received, it invokes a callback function passing this new data. This callback function is run on the libcwiid thread. This restricts us from interacting with V8. We ideally need this callback function running in the context of the main thread. The answer to this problem is:

eio_req *eio_nop       (int pri, eio_cb cb, void *data);

It is safe to call this function from any thread. It will place the eio_cb callback task on the main event queue. This task is then eventually executed on the V8′s thread. An example of this follows:

void WiiMote::HandleMessages(cwiid_wiimote_t *wiimote, int len, union cwiid_mesg mesgs[]) {
  // This thread is running on the libcwiid's thread, and thus we can not use V8 operations
  WiiMote *self = const_cast<WiiMote*>(static_cast<const WiiMote*>(cwiid_get_data(wiimote)));

  // Create a struct to pass to the V8 thread
  struct message_request * req = (struct message_request *)malloc( sizeof(*req) + sizeof(req->mesgs) * (len - 1) );

  // Copy all the data into this struct
  req->wiimote = self;
  req->len = len;
  memcpy(req->mesgs, mesgs, len * sizeof(union cwiid_mesg));

  // Now pass this over to the main V8 thread
  eio_nop (EIO_PRI_DEFAULT, WiiMote::HandleMessagesAfter, req);
}

int WiiMote::HandleMessagesAfter(eio_req *req) {
  // We are now running in the V8 thread.
  message_request* r = static_cast<message_request* >(req->data);
  WiiMote * self = r->wiimote;

  HandleScope scope;

  // Create JavaScript objects with the message_request
  ...

  // Emit this event to a JavaScript callback.
  this->Emit(event, 1, argv);
}

Using a combination of eio_custom and eio_nop you should be able to interface with any external library of service. You just have to make sure you always know what thread you are on, and what methods you are allowed to use in that context.

Finally, writing correct thread-safe code is hard. From the various nodejs extensions I have come across I regularlly find memory management, or threading issues with them. So I suggest you rigorously use valgrind while developing, and simplify your designs so that most of the heavily lifting is done by nodejs itself.

I recently stumbled across this issue while debugging some Javascript. Take the following example code:

var array = [1,2,3,4,5,6,7,8,9,10];
var i = 0;
while(array.length > 0) {
	console.log(i++, array);
	//alert("pause");
	array.pop();
}

If you run it in your browser you would expect to see the following printed (in your Javascript console):

0 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
1 [1, 2, 3, 4, 5, 6, 7, 8, 9]
2 [1, 2, 3, 4, 5, 6, 7, 8]
3 [1, 2, 3, 4, 5, 6, 7]
4 [1, 2, 3, 4, 5, 6]
5 [1, 2, 3, 4, 5]
6 [1, 2, 3, 4]
7 [1, 2, 3]
8 [1, 2]
9 [1]

However, I instead saw:

1 []
2 []
3 []
4 []
5 []
6 []
7 []
8 []
9 []

The issue seems to be that console.log() does not log straight away. In fact it most likely logs in a background thread for performance reasons. Thus by the time it actually logs the array it has changed. I tested this in Firefox (with Firebug) and it logged everything correctly. I also tried slowing down the loop by adding a alert() call. That fixed the issue at the cost of a popup every iterations.

What really should happen is either

• console.log() should block until the logging is complete
• console.log() should copy all objects to avoid them being changed after log() returns but before they are printed.
• add a console.flush() and make me aware this race condition could occur.

I filed this as a bug report on the Chromium site, but I suspect I should have filed it over at the Webkit site.

For the moment I came up with a “fix”. I copy the array before I log it, so in this case I do the following:

console.log(i++, array.slice(0));

Update: I previously searched for this bug, but didn’t find it before writing this article. However, I have just found someone else had reported it a few days ago:

In the on going battle to make my lunch time more optimised I decided to learn some Javascript, and how to use the HTML5 Canvas element. Turns out it’s not that hard, and I have now created

The Lunch Wheel]3. It helps me find lunch close to my office in the Courthouse area of Arlington, VA.

While making this I found that information on the Canvas element seemed to be lacking. For example, not many sites talked about ways to optimise or profile the javascript. Also I was disappointed to see that not all browsers supported the Canvas completely. Here is a quick list of the problems:

1. Firefox 3.5 (linux) doubled the size of the fonts when I was setting the font in “pt”. When I switched to “em” things seemed to work consistently across browsers. 30fps

2. Android 2.2 (Droid 2) works well but slowly. It also didn’t support the Audio tag. 6fps

3. Android 3.0 (Xoom Tablet) seemed to have some issues rendering half of the wheel. It looked like a bug with the hardware acceleration. I made some minor tweaks to the rendering and things started to work. 15fps

4. iPhone 3 didn’t render any of the text, but played the sound and spun the wheel. 3fps

5. iPhone 4 rendered fine but as slowly as the Android 2.2 device. 5fps

6. Chrome (linux) worked great, and was the platform I was developing on. 30fps (max)

I was also using the clip() method to ensure the text didn’t go outside of the wheel, but this heavily impacted performance. So instead I just chopped the text manually and performance doubled.

I realise HTML5 is new, but I’m really hoping all browsers will start to support it consistently and across the board. I’d hate to start writing large blocks of code to cope with all the browser quirks.

Also, thanks to jQuery, TinySort and ExplorerCanvas (which I still haven’t made work).

Update: Soon to come, the ability to find your own lunch places, as well as integration with foursquare so you can see how popular the venues are with your friends.