The V8 team has been working hard on improving JavaScript performance recently, where performance means both peak performance (as in throughput of long running computations) as well as user visible latency (as in time wasted not doing useful work towards completing a computation or rendering a website).
The Raspberry Pi is probably the most popular Linux ARM device nowadays (not including the ARM based Android smartphones and tablets) and V8 is the most popular JavaScript engine, so chances are you may want to run (a recent version of) V8 on the Raspberry Pi. Building on the device is an option, but that takes ages. So you will probably want to cross-compile V8 on your powerful Linux workstation instead.
The Strato Linux V-Servers always reset their hostnames to hXXXXXX.stratoserver.net on boot, no matter what you put in /etc/hostname and there's no way to fix this (it's actually intended behavior). If you happen to have a Strato V-Server running Debian, here's a simple failsafe way to fix the hostname early during boot and have all daemons use your desired hostname.
I spent some time getting a decent cross compiler toolchain for arm-linux-gnueabi running on Mac OS X, including GNU binutils 2.22, gcc 4.6.2 and OCaml 3.12.1. The cross compiler toolchain targets ARM boards running Debian/armel squeeze or later.
I decided that it was about time to get used to OASIS, that new all-in-one build system generator for OCaml projects. So I started by getting it up and running using various local MacPorts. Once everything was up and running, I started to switch my implementation of Red-Black Trees for OCaml to use OASIS instead of my custom Makefile-based approach. That went amazingly well, and so here's my first release, version 0.1.0, of ocaml-rbtrees featuring an OASIS-generated build system.
This paper presents the current state of our work on an interactive toplevel for the OCaml language based on the optimizing native code compiler and runtime. Our native toplevel is up to 100 times faster than the default OCaml toplevel, which is based on the byte code compiler and interpreter. It uses Just-In-Time techniques to compile toplevel phrases to native code at runtime, and currently works with various Unix-like systems running on x86 or x86-64 processors.
After several additional hours of testing and bugfixing it was time for another test release of our new OCaml native code toplevel ocamlnat. The test release includes a fully featured OCaml 3.12.1 distribution plus our new toplevel ocamlnat, which is up to 100 times faster than the byte code toplevel. See the website for installation instructions and additional information.
Now that we have working versions of our new native OCaml toplevel ocamlnat without toolchain dependencies for both i386 and amd64, I decided to run a few benchmarks, comparing our ocamlnat to OCaml 3.12.1 (both the byte code toplevel and the ocamlnat that silently ships with 3.12.1) and to our byte-code just-in-time compiler OCamlJIT2.