Snippets: gRPC, iPython, LLVM, Pi Trees and Juice,

snippets03gRPC: Google, doing it’s whomp-here’s-a-“standard” thing, has just announced an open sourced remote procedure call framework called gRPC. With libraries for seven languages (C, C++, Java, Node.js, Python and Ruby are done – ObjC, PHP and C# coming), gRPC gets you to use Protocol Buffers to define the end points and serialisation and the libraries then use HTTP/2 to communicate exploiting the bidirectional streaming and multiplexing. There’s an new alpha of a version 3.0 of Protocol Buffers to go with it too. They may be going evil but they do produce some great engineering so this is one to watch.

iPython 3.0: Interactive shells and books are wonderful things – beyond REPLs, they let people work different with languages and data, moving from a scripted . So it’s good to see the iPython project release a iPython 3.0 and lay down the foundation for language-agnostic notebooks. This is the last monolithic release of iPython, which pulls in a host of different language kernels into the project, including Bash, Haskell, Go and even Redis. But the next stage will be to split the project into a pure Python related stuff called iPython which will also produce a kernel to plug into Jupyter, an interactive notebook environment for multiple languages. Thats a journey that starts with iPython 3.0. If you like the idea of a shell/notebook environment, start following this project as it evolves.

LLVM 3.6 Lands: The new compiler juggernaut that is LLVM rolls through another release as version 3.6 is released. According to the release notes there’s lots of tidying up and updating and quiet adoptions like the Go bindings from gollvm being introduced.

Pi Device Trees: The Raspberry Pi’s Raspbian release that arrived the the Pi 2 also came with the added bonus of switching to Device Trees which is a way of modelling and talking to the bazillion different hardware combos out there in a unified way. The Beaglebone Black’s Debian has had it for ages and now it’s the Pi’s turn. There’s a whole load of things to get your head around but this posting on the Pi forums will get you through enabling I2C, I2S, SPI and more using DT.

PiJuice: Talking Pi, there’s a nifty Hat-sized Kickstarter for a device called a PiJuice currently running which lashes a standard phone battery, real time clock and UPS and other handy things into a £24 hat so you can take out Pi walkies. It’s also pinned so you can pop another Hat on top. Looks very clean as a design.

LLVM 3.4, Arch 2014-01-05, Mirantis OpenStack 4.0 and Paper encryption – Snippets


  • LLVM hits 3.4: The LLVM project’s compilers and more toolchain has reached version 3.4 and the announcement counts down the new features; Clang now has all of the working draft for C++1y standard working, a better static analyser, a “clang-format” for beautiful code in your preferred style and an experimental driver which should let Clang be used with Visual Studio. There’s also lots of performance enhancements in the code generator. Read more in the release notes and if you’re the kind of person who builds their own LLVM kit, head to the releases page to download.

  • Arch’s first 2014 update: The first of what will be many, the Arch Linux project has released an update (2014-01-05) to the distro. If you already use Arch, you know that as long as you are up to date you don’t need this. For folks wanting to check out Arch, this update is where you’d start. Well, there and the installation guide or beginner’s guide.

  • Mirantis OpenStack update: Mirantis have released Mirantis OpenStack 4.0 which you can download. It includes a number of “hardened” packages and the Fuel management tool which can deploy out to CentOS or Ubuntu.

  • Paper powered encryption: The folks at LightBlueTouchPaper have come up with an interesting little paper based, one-time pad driven encryption scheme with a Python script for generating encryption tables. Read more and generate a table or two at the blog posting.

FreeBSD 10.0 so close, Ruboto goes 1.0, ODroid U3 coming – Snippets


  • FreeBSD 10.0 RC3 – so close: It’s so close, FreeBSD 10.0 that it, with the third release candidate for 10.0 being made available from the various FreeBSD mirrors. And while you are looking, remember that the FreeBSD Foundation is in the final part of 2013’s fund raising drive looking to get a million dollars (currently at $648,622 with 1499 donors) to power the group through 2014.

  • Ruboto – JRuby on Android 1.0.0: The developers of Ruboto have, with the release of 1.0, declared their port of JRuby on Android “ready for general consumption” with all the “important parts” of the Android API available and stabalised and performing reasonably and enough documentation to work with.

  • ODroid U3 powers up: notes the upcoming availablity of Hardkernel’s Odroid U3, a quad core Exynos 4412 ARM based board which looks to pack a lot of power into a $59 board. It’s already been added to Codepope’s shopping list, especially with the option to use 8-64GB of faster eMMC memory to host either Linux (Xubuntu) or Android. Stay tuned for when it arrives here for a close look… in the meantime, we have an Xmos StartKIT which is pining for attention.

  • Readables: About Obfuscator-LLVM, Dual-Use tools and Acdemic Ethics – one of the elements of the fall out of the evasi0n iOS7 jailbreak clown-car-crash…

The Rubinus/Ruby Ruckus

rubinius_logo_black_on_whiteIt seems to be all going on with the developers of Rubinus, the LLVM JIT-powered Ruby implementation which recently hit version 2.0.0. First came the news that Engine Yard had ended their sponsorship for the project saying that “we no longer feel like the project needs any help from us to accelerate” – the ending of sponsorship will, they say, let them invest more in other emerging projects.

With that announcement made, Rubinus lead Brian Shirai said “I have been working to simplify and focus the project”; funding changes do tend to allow projects to step back and look at their goals. In this case, the results of that work turned up in an announcement of Rubinus X.

Rubinus X is billed as an experiment in modernising Ruby, which the project’s home page declares as no longer relevant to modern computing. The plan appears to be a major reworking of Ruby – concurrency with Promises and non-blocking I/O, persistent data structures, object composition, code loading as an API, consistency through composing operations from system primitives, immutable strings and a more explicit OO model. There is also a clean up of the language planned with a single encoding used within running programs, the removal of position-significant arguments in API calls, a defined numeric tower and the purging of Perl-inspired features and global variables.

Shirai declared “Ruby is a dying language” which triggered much discussion over on sites like Hacker News about whether Ruby was dying or not and whether Node.js was the new Ruby/Rails but very little conversation on the merits of the Rubinus X plan. More details on how the Rubinus X project will develop will be disclosed in the coming days via the mailing list (which has already got 570 signups). Rubinus X does seem to have some ambitious goals and with the development taking place outside the mainstream of Ruby, it shouldn’t have an impact on Ruby development at least until it has proven itself. What affect it will have on Rubinus development is unclear though; with no one paid to develop it, resources will be tight. Definitely one to keep an eye on.

Rubinus 2.0 has eyes on Ruby 2.1

rubinius_logo_black_on_whiteAlthough Ruby 2.1 hasn’t been released yet, the just release Rubinus Ruby runtime’s version 2.0 is aiming towards being Ruby 2.1 compatible. Rubinus, for those who don’t know of it, is an implementation of Ruby which uses an LLVM JIT compiler, generational garbage collector and native threads to give a Ruby runtime that can run efficiently on all CPU cores of a modern platform. The developers are also maintainers of RubySpec, a 20,000 plus strong library of specifications which map MRI (Matz’s Ruby Implementation), created to assist maintain compatibility with the ‘reference’ Ruby implementation; RubySpec is now used by many other Ruby implementations to ensure compatibility.

As the developers explain while the Ruby 2.1 MRI runtime hasn’t been released yet, they are aiming to improve compatibility with the leading edge of Ruby. This comes with a sacrifice though; historically the Rubinus developers have tried to support multiple Ruby versions and all the oddness that happens in any system where the specification is the implementation. The developers hope that this change, along with a focus on creating concurrent distributed applications, will make “Ruby competitive with Go, Erlang, Clojure, Scala and Node” in that domain. This means, they say, performance and stability of that kind of application will be prioritised over supporting some legacy Ruby code or “quirky Ruby feature”. In preparation for a more componentised Ruby, Rubinus 2.0 has isolated the standard library into a Ruby gem. There’s also a new release system for the Rubunius platform with a new versioning scheme being introduced in the transition between 2.0 and 3.0.

The developers also outline their own future thoughts and plans for Rubinus, including better (and less) concurrency coordination, less finely grained locks replacing the Ruby GIL, a more concurrent and parallel garbage collector and a more Ruby semantics informed JIT. The plans set out are focussed on making sure Ruby isn’t left behind in the new slew of languages and as the Rubinus team say “developers who are happy writing Ruby shouldn’t be forced to leave it because of technical limitations” – limitations they are setting out to remove.