What’s New in Node and libuv this Week – March 28, 2013

Welcome to this week’s wrap up of the week in Node and libuv covering March 21-27. The purpose of this blog is to recap a subset of the non-documentation related commits to the master branch of Node.js, plus give a little color and commentary to the ongoing development of Node.

npm’s missing callback fix

As @ronkorving pointed out, we missed mentioning the missing callback fix in npm from last week. Our apologies for the gross oversight 😉

child_process changes

There was bug in process#send() and child_process.ChildProcess#send() that got fixed this week. Messages between the processes were getting corrupted when:

  • They contained non-ASCII (v0.10 only), or
  • The message could not be read/written atomically and was split inside a UTF-8 character sequence (something of an edge case but affected both v0.8 and v0.10).

See also: https://github.com/joyent/node/pull/5016

Another bug that was tackled was one that when sending over handles (e.g. net.Socket
objects), sometimes the same handle would be emitted two or even three times. People don’t generally use that part of the API directly so it’s unlikely to have affected anyone. Ben only discovered it in the process of hunting down some other bug.

An update to crypto.getCiphers()

crypto.getCiphers() got updated to return normal ciphers instead of SSL/TLS ciphers (so it’s more inline with what crypto.getHashes() does) and Ben added tls.getCiphers() which returns the SSL/TLS ciphers. Compare:

$ node -p 'require("crypto").getCiphers().slice(1, 4)'
[ 'aes-128-cbc', 'aes-128-cbc-hmac-sha1', 'aes-128-cfb' ]

$ node -p 'require("tls").getCiphers().slice(1, 4)'
[ 'aes128-sha', 'aes128-sha256', 'aes256-gcm-sha384' ]

Security fix

Security fix CVE-2013-2632 was a back-port from upstream V8 commits. This is unlikely to affect Node users unless they’re in the habit of running untrusted, arbitrary JS code.

Timer fixes

Ben fixed a timer bug in libuv, but it might also need to get fixed in uv-win. Alexey added an additional safeguard to the fix so that Timers specified with a timeout of 1ms now won’t fire any earlier. There was a signed int32 overflow assertion bug that Fedor fixed as well.

Performance regressions

There was a performance regression in V8 3.17, that has been fixed to some extent in upstream V8, but it will take some time to trickle into Node master.  v0.10 is not affected because we stuck with V8 3.14 exactly for this reason.

Sub-second stat resolution

While libuv supports reporting subsecond stat resolution across platforms, to actually get that resolution your platform and filesystem must support it (not HFS, ext[23] and FAT) otherwise the nsecs are 0.

 libuv 0.10.2 (Stable) is out!

The first officially versioned release of libuv is out now and will begin releasing independently of the Node releases. libuv.org is pretty barebones, any web designers want to show it some love? 🙂

Update: Node v0.10.2 is out – here’s the official release blog.

This week’s commits to Node master

You can view the complete Node commit history on GitHub.

This week’s blogs, tutorials, how-tos and news:

What’s New in Node and libuv this Week – March 21, 2013

Welcome to this week’s wrap up of the week in Node and libuv. The purpose of this blog is to recap a subset of the non-documentation related commits to the latest branch of Node.js and libuv, plus give a little color and commentary to the ongoing development of Node. And in case you missed it, Node v0.10.1 (Stable) is out as of this morning!

What happened this week?

  • Node: 36 commits by 14 authors and 41 files changed.
  • libuv: 7 commits by 4 authors.

In the master branch Trevor Norris (trevnorris) and Ben Noordhuis (bnoordhuis) have been upgrading v8 to the latest version. If you recall, at the last-minute before the 0.10 release it was decided to go back to 3.15 because the latest one introduced some pretty serious performance regressions. Trevor and Ben are now trying to track down where that comes from. V8 3.17 is interesting because some APIs were changed so that it doesn’t need to access thread local storage (TLS) as often, which is relatively expensive.

For those of you who have already upgraded to 0.10, you may have encountered some pretty bad performance regressions in some crypto functions (like createHmac) which are currently being worked on by Ben.

Bert Belder (piscisaureus) is working on making the first standalone libuv release (you probably already knew that) so, look for a “stable” version of it next week. This should make life easier for other projects that also use libuv (like luvit, rust, julialang, pyuv) and for distro maintainers that like to package libraries separately.

And by the way, repl (which provides the ability to interactively run JavaScript and see the results) got some upgrades too:

  • repl now uses the domains feature to not crash when an asynchronous function fails with an error.
  • And something for the international developers, finally fixed was the issue that repl couldn’t really deal with some characters (e.g. Chinese) that take more space than a regular character.

This week’s Node commits

isaacs

bnoordhuis

piscisaureus

indutny

raymondfeng

kanongil

tjfontaine

trevnorris

This week’s libuv commits

tjfontaine

bnoordhuis

indutny

bmazza

You can view all the changes to the Node v0.10 branch and changes to libuv on GitHub.

This week’s blogs, tutorials, how-to’s and news:

Introducing slc – a Swiss Army Knife for Node

Editor’s Note: If you experience problems installing or configuring StrongLoop components, please make sure to check the documentation and the Getting Started page for the most current instructions.

It’s only been about a week since we announced the release of StrongNode, our supportable distribution of Node, and although it has been a hectic week fielding inquiries, we did manage to pull together a new feature, a command line utility called slc.

What is slc?

slc is a command line tool that ships with StrongNode for building and managing applications. It’s a Swiss-Army knife tool that provides commands for scaffolding, testing and documenting Node.js source code. In the near future, it will also provide functionality for debugging and the ability to install and manage different versions of Node (a la Tim Caswell’s excellent nvm), without the need to invoke those other tools. For now, anywhere that you run node you should be able to run slc. Download the new StrongNode with slc.

Why did we create slc?

As users of Node, we noticed that there was a lot of functionality that was being covered by multiple tools within the Node ecosystem. This is a great testament to the Node community, but it also meant installing a number of tools to do common operations. Putting all of these under one umbrella utility would mean we get all the benefits of oft-used functionality as subcommands to slc. We were inspired by other languages, specifically Go, where its go command envelopes all functions with a set of subcommands.

What can slc do for you?

The current version of slc offers five distinct subcommands:

  • create: initialize a new StrongNode project, automatically download StrongNode supported modules and create boilerplate for modules
  • run: run a specified script
  • env: print node environment information
  • test: run tests
  • version: print the version of Node

To get a more detailed look at the commands type slc -h. Let’s take a look at a few examples on how to use slc, shall we?

First, be sure to download and install the latest StrongNode distribution.

Create applications

The create command supports a few program types. The web type is used by default and when generated installs the following:

  • package.json – dependencies and other package configuration
  • app.js – app entry point and runtime configuration
  • public – for holding static assets (images, css, et al)
  • routes – route handler functions
  • views – templates for rendering html

You can create a simple web application with just a single command:

Create boilerplate for modules

The create command also makes it easy to create boilerplate code for a new module you can then publish to npm or simply require in your application. You can do this by executing:

This generates the following JavaScript file ./my-module.js :

You can now call the module like this:

Generating tests and the help command

slc also supports automatically generating tests:

$ slc create module my-module --test

And allows you to supply a stream type to implement:

$ slc create module my-module --stream transform

For more information see the help for each command:

$ slc create -h

$ slc create module -h

$ slc test -h

Finally, if you want to get additional information on how to use the StrongNode distribution and the slc utility, check out our Getting Started Guide.

What’s new in Node v0.10 ?

At StrongLoop we are totally psyched that Node v0.10 is finally here, as we are basing our first supportable Node.js distribution on it. (You can download the StrongLoop Node distro here.) It has taken about nine months (if you recall v0.8.0 released on June 25, 2012), but it was well worth the wait.

The first piece of good news is that lots of effort has gone into minimizing the amount of changes that went into existing APIs. That being said, there’s definitely lots to like in this new release, so let’s dig in, shall we?

A new Stream implementation: Streams2

As many of you know, the new Stream implementation in v0.10 is known as “Streams2.” Before we talk about what’s great about this change, let’s recap some of the known issues with the Stream implementation in v0.8, which Isaac outlined back in December:

  1. The pause() method doesn’t pause. It is advisory-only. In Node’s implementation, this makes things much simpler, but it’s confusing to users, and doesn’t do what it looks like it does.
  2. ‘data’ events come right away (whether you’re ready or not). This makes it unreasonably difficult to do common tasks like load a user’s session before deciding how to handle their request.
  3. There is no way to consume a specific number of bytes, and then leave the rest for some other part of the program to deal with.
  4. It’s unreasonably difficult to implement streams and get all the intricacies of pause, resume, write-buffering, and data events correct. The lack of shared classes mean that we all have to solve the same problems repeatedly, making similar mistakes and similar bugs.

Make sure to the read RTFM on Streams2 before you set out to do anything dangerous! Oh, and for those of you who have apps that depended on the old Streams API, no worries it’s still supported in v0.10 and probably will be forever.

It’s now easier to write your own Streams

With Node v0.10, it’s now easier to create your own stream class. Before you needed to implement a handful of methods, and emit all stream events yourself.. But now with the a new Stream base class, you’ll just need to inherit from the base class and implement two functions _read and _write. You can suffice with just telling node how to produce data that the user can read, and what to do with data that the user writes to it. The new Stream base class takes care of all the nasty details.

For example:

Faster, more consistent performance

Node v0.10 is faster than v0.8 on most HTTP, file system and TLS benchmarks. Check out the latest Node performance benchmarks. Also, the runtime characteristics of Node are now more stable, meaning latency numbers are more consistent because there are fewer long stalls in the V8 garbage collector.

Libuv updates

Libuv, the library that does all the asynchronous hard work got some major updates as well. Until Node 0.8 the unix implementation of libuv was for a large part just a wrapper around two pre-existing libraries (libev and libeio). Ben Noordhuis went out of his way to remove these dependencies, thereby removing another layer of indirection and making it more efficient.

Can’t get enough of Node v0.10?

There’s also two videos worth checking out that cover what’s new in v0.10:

 

Announcing StrongLoop Node

Today we release StrongLoop Node v1.0 in Beta. Based on Node.js v0.10 which also was released today, we expect to evolve StrongLoop Node to the most stable and performant version of Node yet. Read more about why we are releasing a Node distribution in my colleague Al’s post.

Did you know that StrongLoop staff were major contributors to this recent release and StrongLoop is now the most active corporate sponsor of Node? Read about how the Node.js project works and who contributed to the v0.10 release.

If you’ve been using Node for a while, you might want to know What’s New in Node v0.10 and if you’re new to Node, why not go to our Getting Started section to have an example blog up and running on Node and MongoDB in just a couple of minutes.