I am thrilled to announce the arrival of a new stable version of Node.js.
Compared with the v0.6 releases of Node, this release brings
significant improvements in many key performance metrics, as well as
cleanup in several core APIs, and the addition of new debugging
features.
$ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req
# v0.6.19
^C # lost patience after a few hours
# v0.8.0
Requests per second: 252.69 [#/sec] (mean)
```
The more bytes you're pushing, and the more work you're doing, the
more win you'll see with node 0.8 over 0.6.
The vast majority of the performance boost is due to improvements in
V8. They've been very responsive to the needs of the Node.js project.
A lot of Node's success is due to being built on such a stellar VM.
## Build System
Since its inception Node has used the WAF build system which is a
Python based system similar to SCons. The Chrome project recently
changed to the GYP meta-build system from SCons. GYP generates
Makefiles, Visual Studio project files, or XCode files depending on
the target. V8, being part of the Chrome project, now defines its
build in GYP. By using GYP, Node is able to:
- integrate with the optimal build system on all platforms,
- easily able to integrate V8's build process into its own, and
- define its compilation declaratively for better manageability
GYP was used already in Node v0.6 to build on Windows, but now it
defines the build on all platforms. Node is still in the process of
migrating external addon modules to GYP, and node-gyp is included with
npm. In future releases, node-waf will be officially deprecated. If
you are currently using a wscript in your addon, please migrate to gyp
as soon as possible.
## Stabler
The transition from libev and libeio to libuv in 0.6 was somewhat
destabilizing for many node internals. The gambit paid off: libuv is
the obvious choice in cross-platform asynchronous IO libraries, and
Node.js is impressively performant on both Windows and Unix. But it
made the transition from 0.4 to 0.6 was very rocky for a lot of users.
Libuv wasn't as mature as node, and it showed in those early releases.
At this point, with very few exceptions, if your v0.6 program doesn't
run on v0.8, it should be easy and obvious to make whatever changes
are necessary. Libuv has come a very long way, and Node 0.8 is a
simpler and more efficient machine as a result.
In Node 0.4, there was a `listenFD` method that servers could use to
listen on a specific file descriptor that was already bound to a
socket or port. In 0.6, that functionality went away, largely because
it was very Unix-specific, and couldn't be easily made to work with
the new cross-platform libuv base.
Since the most common use case for listenFD was as a method for having
servers in multiple node processes share the same underlying handle,
the `cluster` module was added in its place. However, this still left
a lot of use cases unaddressed, and was a reason why some people could
not use node 0.6 for their programs.
In 0.8, we've replaced this functionality, as `server.listen({ fd: number })`.
The other feature in node 0.4 that got dropped in 0.6 was the ability
to pass arbitrary file descriptors as a child process's stdio, using
the `customFds` array. In Node 0.6, `customFds` could be used to
inherit the parent's stdio handles, but not to pass arbitrary handles
or file descriptors to the child's stdio. Also, there was never a way
to pass more than the standard `in, out, err` trio, so programs that
expected FD 4 to be opened in some specific way were out of luck.
In 0.8, we've added the `stdio` array on the `child_process.spawn`
options. Pass as many file descriptors, handles, etc. as you like, and
the child process will see them as already-opened FDs.
Barring these very minor API changes, if you were using cluster in
0.6, then your program will still work, but it'll be faster and more
well-behaved now. And if you aren't taking advantage of the new
features in 0.8's cluster, you're really missing out.
The original idea for Domains was a way to join multiple different IO
actions, so that you can have some context when an error occurs.
Since Ryan discussed the feature with node users at NodeConf Summer
Camp last year, the domains feature has gone through many revisions.
The problem is fairly well understood, but most attempts to solve it
resulted in serious performance regressions, or uncovered difficult
edge cases.
What we ended up with in 0.8 is a very stripped-down version of this
idea. It's entirely opt-in, with minimal performance impact when it's
used (and none when it isn't). There are a lot of examples in [the API
documentation](http://nodejs.org/api/domain.html), so check them out,
and start handling your crashes smarter.
The domain module is still experimental. We are looking forward to
your feedback, so please use it and let us know what you think.
## Repl, Readline, TTY
The Repl, Readline, and TTY modules have all had a major facelift. The
interfaces between these three modules are cleaned up and refactored,
removing a lot of common pain points and making it easier to use for
debugging your programs.
It may seem minor at times, but a good repl dramatically increases the
quality of the overall experience. My personal favorites are:
1. Typing `fs` or `net` or `path` will automatically load the module.
2. Typing `npm install ...` will give you a helpful message.
3. It doesn't do that stupid thing where long lines wrap and then the
backspace makes it get all confused and crazy. Instead of that, it
does the right thing.
## Looking Forward
Like other even-numbered version families before it, v0.8 will
maintain API and ABI stability throughout its lifetime.
On Mon, Jun 25, 2012 at 8:01 AM, Isaac Schlueter <i...@izs.me> wrote:
> I am thrilled to announce the arrival of a new stable version of Node.js.
> Compared with the v0.6 releases of Node, this release brings
> significant improvements in many key performance metrics, as well as
> cleanup in several core APIs, and the addition of new debugging
> features.
> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req
> # v0.6.19
> ^C # lost patience after a few hours
> # v0.8.0
> Requests per second: 252.69 [#/sec] (mean)
> ```
> The more bytes you're pushing, and the more work you're doing, the
> more win you'll see with node 0.8 over 0.6.
> The vast majority of the performance boost is due to improvements in
> V8. They've been very responsive to the needs of the Node.js project.
> A lot of Node's success is due to being built on such a stellar VM.
> ## Build System
> Since its inception Node has used the WAF build system which is a
> Python based system similar to SCons. The Chrome project recently
> changed to the GYP meta-build system from SCons. GYP generates
> Makefiles, Visual Studio project files, or XCode files depending on
> the target. V8, being part of the Chrome project, now defines its
> build in GYP. By using GYP, Node is able to:
> - integrate with the optimal build system on all platforms,
> - easily able to integrate V8's build process into its own, and
> - define its compilation declaratively for better manageability
> GYP was used already in Node v0.6 to build on Windows, but now it
> defines the build on all platforms. Node is still in the process of
> migrating external addon modules to GYP, and node-gyp is included with
> npm. In future releases, node-waf will be officially deprecated. If
> you are currently using a wscript in your addon, please migrate to gyp
> as soon as possible.
> ## Stabler
> The transition from libev and libeio to libuv in 0.6 was somewhat
> destabilizing for many node internals. The gambit paid off: libuv is
> the obvious choice in cross-platform asynchronous IO libraries, and
> Node.js is impressively performant on both Windows and Unix. But it
> made the transition from 0.4 to 0.6 was very rocky for a lot of users.
> Libuv wasn't as mature as node, and it showed in those early releases.
> At this point, with very few exceptions, if your v0.6 program doesn't
> run on v0.8, it should be easy and obvious to make whatever changes
> are necessary. Libuv has come a very long way, and Node 0.8 is a
> simpler and more efficient machine as a result.
> In Node 0.4, there was a `listenFD` method that servers could use to
> listen on a specific file descriptor that was already bound to a
> socket or port. In 0.6, that functionality went away, largely because
> it was very Unix-specific, and couldn't be easily made to work with
> the new cross-platform libuv base.
> Since the most common use case for listenFD was as a method for having
> servers in multiple node processes share the same underlying handle,
> the `cluster` module was added in its place. However, this still left
> a lot of use cases unaddressed, and was a reason why some people could
> not use node 0.6 for their programs.
> In 0.8, we've replaced this functionality, as `server.listen({ fd: number })`.
> The other feature in node 0.4 that got dropped in 0.6 was the ability
> to pass arbitrary file descriptors as a child process's stdio, using
> the `customFds` array. In Node 0.6, `customFds` could be used to
> inherit the parent's stdio handles, but not to pass arbitrary handles
> or file descriptors to the child's stdio. Also, there was never a way
> to pass more than the standard `in, out, err` trio, so programs that
> expected FD 4 to be opened in some specific way were out of luck.
> In 0.8, we've added the `stdio` array on the `child_process.spawn`
> options. Pass as many file descriptors, handles, etc. as you like, and
> the child process will see them as already-opened FDs.
> Barring these very minor API changes, if you were using cluster in
> 0.6, then your program will still work, but it'll be faster and more
> well-behaved now. And if you aren't taking advantage of the new
> features in 0.8's cluster, you're really missing out.
> The original idea for Domains was a way to join multiple different IO
> actions, so that you can have some context when an error occurs.
> Since Ryan discussed the feature with node users at NodeConf Summer
> Camp last year, the domains feature has gone through many revisions.
> The problem is fairly well understood, but most attempts to solve it
> resulted in serious
Great Release. Big thanks to all developers for their hard work making this release possible. Now, after realeasing - go home and get yourself a big fresh bottle of beer!!
Kind regards
Am Montag, 25. Juni 2012 17:01:13 UTC+2 schrieb Isaac Schlueter:
> I am thrilled to announce the arrival of a new stable version of Node.js.
> Compared with the v0.6 releases of Node, this release brings > significant improvements in many key performance metrics, as well as > cleanup in several core APIs, and the addition of new debugging > features.
> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req > # v0.6.19 > ^C # lost patience after a few hours > # v0.8.0 > Requests per second: 252.69 [#/sec] (mean) > ```
> The more bytes you're pushing, and the more work you're doing, the > more win you'll see with node 0.8 over 0.6.
> The vast majority of the performance boost is due to improvements in > V8. They've been very responsive to the needs of the Node.js project. > A lot of Node's success is due to being built on such a stellar VM.
> ## Build System
> Since its inception Node has used the WAF build system which is a > Python based system similar to SCons. The Chrome project recently > changed to the GYP meta-build system from SCons. GYP generates > Makefiles, Visual Studio project files, or XCode files depending on > the target. V8, being part of the Chrome project, now defines its > build in GYP. By using GYP, Node is able to:
> - integrate with the optimal build system on all platforms, > - easily able to integrate V8's build process into its own, and > - define its compilation declaratively for better manageability
> GYP was used already in Node v0.6 to build on Windows, but now it > defines the build on all platforms. Node is still in the process of > migrating external addon modules to GYP, and node-gyp is included with > npm. In future releases, node-waf will be officially deprecated. If > you are currently using a wscript in your addon, please migrate to gyp > as soon as possible.
> ## Stabler
> The transition from libev and libeio to libuv in 0.6 was somewhat > destabilizing for many node internals. The gambit paid off: libuv is > the obvious choice in cross-platform asynchronous IO libraries, and > Node.js is impressively performant on both Windows and Unix. But it > made the transition from 0.4 to 0.6 was very rocky for a lot of users. > Libuv wasn't as mature as node, and it showed in those early releases.
> At this point, with very few exceptions, if your v0.6 program doesn't > run on v0.8, it should be easy and obvious to make whatever changes > are necessary. Libuv has come a very long way, and Node 0.8 is a > simpler and more efficient machine as a result.
> In Node 0.4, there was a `listenFD` method that servers could use to > listen on a specific file descriptor that was already bound to a > socket or port. In 0.6, that functionality went away, largely because > it was very Unix-specific, and couldn't be easily made to work with > the new cross-platform libuv base.
> Since the most common use case for listenFD was as a method for having > servers in multiple node processes share the same underlying handle, > the `cluster` module was added in its place. However, this still left > a lot of use cases unaddressed, and was a reason why some people could > not use node 0.6 for their programs.
> In 0.8, we've replaced this functionality, as `server.listen({ fd: number > })`.
> The other feature in node 0.4 that got dropped in 0.6 was the ability > to pass arbitrary file descriptors as a child process's stdio, using > the `customFds` array. In Node 0.6, `customFds` could be used to > inherit the parent's stdio handles, but not to pass arbitrary handles > or file descriptors to the child's stdio. Also, there was never a way > to pass more than the standard `in, out, err` trio, so programs that > expected FD 4 to be opened in some specific way were out of luck.
> In 0.8, we've added the `stdio` array on the `child_process.spawn` > options. Pass as many file descriptors, handles, etc. as you like, and > the child process will see them as already-opened FDs.
> Barring these very minor API changes, if you were using cluster in > 0.6, then your program will still work, but it'll be faster and more > well-behaved now. And if you aren't taking advantage of the new > features in 0.8's cluster, you're really missing out.
> The original idea for Domains was a way to join multiple different IO > actions, so that you can have some context when an error occurs.
> Since Ryan discussed the feature with node users at NodeConf Summer > Camp last year, the domains feature has gone through many revisions. > The problem is fairly well understood, but most attempts to solve it > resulted in serious performance regressions, or uncovered difficult > edge cases.
> What we ended up with in 0.8 is a very stripped-down version of this > idea. It's entirely opt-in, with minimal performance impact when it's > used (and none when it isn't). There are a lot of examples in [the API > documentation](http://nodejs.org/api/domain.html), so check them out, > and start handling your crashes smarter.
> The domain module is still experimental. We are looking forward to > your feedback, so please use it and let us know what you think.
> ## Repl, Readline, TTY
> The Repl, Readline, and TTY modules have all had a major facelift. The > interfaces between these three modules are cleaned up and refactored, > removing a lot of common pain points and making it
Good stuff. I'm particularly excited to see where the Buffer/TypedArray transition leads, as I'm doing a lot of code sharing between browser JS and node and have ended up with a lot of nasty Buffer/TypedArray conversions.
On Monday, June 25, 2012 8:23:30 AM UTC-7, Thomas Fritz wrote:
> Great Release. > Big thanks to all developers for their hard work making this release > possible. > Now, after realeasing - go home and get yourself a big fresh bottle of > beer!!
> Kind regards
> Am Montag, 25. Juni 2012 17:01:13 UTC+2 schrieb Isaac Schlueter:
>> I am thrilled to announce the arrival of a new stable version of Node.js.
>> Compared with the v0.6 releases of Node, this release brings >> significant improvements in many key performance metrics, as well as >> cleanup in several core APIs, and the addition of new debugging >> features.
>> The difference is not small. If you are writing network programs with >> node, and pushing a lot of traffic, you will notice this improvement.
>> The speed of reading files got quite a bit faster as well:
>> ``` >> # v0.6.19 >> read the file 110948 times (higher is better) >> 90141.32 ns per read (lower is better) >> 11093.69 reads per sec (higher is better)
>> # v0.8.0 >> read the file 158193 times (higher is better) >> 63217.16 ns per read (lower is better) >> 15818.48 reads per sec (higher is better) >> ```
>> And of course, the ubiquitous 'hello, world' http server benchmark got >> significantly faster, especially for large message sizes:
>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req >> # v0.6.19 >> ^C # lost patience after a few hours >> # v0.8.0 >> Requests per second: 252.69 [#/sec] (mean) >> ```
>> The more bytes you're pushing, and the more work you're doing, the >> more win you'll see with node 0.8 over 0.6.
>> The vast majority of the performance boost is due to improvements in >> V8. They've been very responsive to the needs of the Node.js project. >> A lot of Node's success is due to being built on such a stellar VM.
>> ## Build System
>> Since its inception Node has used the WAF build system which is a >> Python based system similar to SCons. The Chrome project recently >> changed to the GYP meta-build system from SCons. GYP generates >> Makefiles, Visual Studio project files, or XCode files depending on >> the target. V8, being part of the Chrome project, now defines its >> build in GYP. By using GYP, Node is able to:
>> - integrate with the optimal build system on all platforms, >> - easily able to integrate V8's build process into its own, and >> - define its compilation declaratively for better manageability
>> GYP was used already in Node v0.6 to build on Windows, but now it >> defines the build on all platforms. Node is still in the process of >> migrating external addon modules to GYP, and node-gyp is included with >> npm. In future releases, node-waf will be officially deprecated. If >> you are currently using a wscript in your addon, please migrate to gyp >> as soon as possible.
>> ## Stabler
>> The transition from libev and libeio to libuv in 0.6 was somewhat >> destabilizing for many node internals. The gambit paid off: libuv is >> the obvious choice in cross-platform asynchronous IO libraries, and >> Node.js is impressively performant on both Windows and Unix. But it >> made the transition from 0.4 to 0.6 was very rocky for a lot of users. >> Libuv wasn't as mature as node, and it showed in those early releases.
>> At this point, with very few exceptions, if your v0.6 program doesn't >> run on v0.8, it should be easy and obvious to make whatever changes >> are necessary. Libuv has come a very long way, and Node 0.8 is a >> simpler and more efficient machine as a result.
>> In Node 0.4, there was a `listenFD` method that servers could use to >> listen on a specific file descriptor that was already bound to a >> socket or port. In 0.6, that functionality went away, largely because >> it was very Unix-specific, and couldn't be easily made to work with >> the new cross-platform libuv base.
>> Since the most common use case for listenFD was as a method for having >> servers in multiple node processes share the same underlying handle, >> the `cluster` module was added in its place. However, this still left >> a lot of use cases unaddressed, and was a reason why some people could >> not use node 0.6 for their programs.
>> In 0.8, we've replaced this functionality, as `server.listen({ fd: number >> })`.
>> The other feature in node 0.4 that got dropped in 0.6 was the ability >> to pass arbitrary file descriptors as a child process's stdio, using >> the `customFds` array. In Node 0.6, `customFds` could be used to >> inherit the parent's stdio handles, but not to pass arbitrary handles >> or file descriptors to the child's stdio. Also, there was never a way >> to pass more than the standard `in, out, err` trio, so programs that >> expected FD 4 to be opened in some specific way were out of luck.
>> In 0.8, we've added the `stdio` array on the `child_process.spawn` >> options. Pass as many file descriptors, handles, etc. as you like, and >> the child process will see them as already-opened FDs.
>> ## More Powerful Cluster
>> The cluster module in 0.8 is so much improved over 0.6, it's basically >> a complete rewrite. The API is mostly backwards compatible, but not >> entirely. (See the [migration >> wiki]( >> https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8) >> for details.)
>> Barring these very minor API changes, if you were using cluster in >> 0.6, then your program will still work, but it'll be faster and more >> well-behaved now. And if you aren't taking advantage of the new >> features in 0.8's cluster, you're really missing out.
>> The original idea for Domains was a way to join multiple different IO >> actions, so that you can have some context when an error occurs.
>> Since Ryan discussed the feature with node users at NodeConf Summer >> Camp last year, the domains feature has gone through many revisions. >> The problem is fairly well understood, but most attempts to solve it >> resulted in serious performance regressions, or uncovered difficult >> edge cases.
>> What we ended up with in 0.8 is a very stripped-down version of this >> idea. It's entirely opt-in, with minimal performance impact when it's >> used (and
On Mon, Jun 25, 2012 at 8:23 AM, Thomas Fritz <fritz...@gmail.com> wrote:
> Great Release.
> Big thanks to all developers for their hard work making this release
> possible.
> Now, after realeasing - go home and get yourself a big fresh bottle of
> beer!!
> Kind regards
> Am Montag, 25. Juni 2012 17:01:13 UTC+2 schrieb Isaac Schlueter:
>> I am thrilled to announce the arrival of a new stable version of Node.js.
>> Compared with the v0.6 releases of Node, this release brings
>> significant improvements in many key performance metrics, as well as
>> cleanup in several core APIs, and the addition of new debugging
>> features.
>> The difference is not small. If you are writing network programs with
>> node, and pushing a lot of traffic, you will notice this improvement.
>> The speed of reading files got quite a bit faster as well:
>> ```
>> # v0.6.19
>> read the file 110948 times (higher is better)
>> 90141.32 ns per read (lower is better)
>> 11093.69 reads per sec (higher is better)
>> # v0.8.0
>> read the file 158193 times (higher is better)
>> 63217.16 ns per read (lower is better)
>> 15818.48 reads per sec (higher is better)
>> ```
>> And of course, the ubiquitous 'hello, world' http server benchmark got
>> significantly faster, especially for large message sizes:
>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req
>> # v0.6.19
>> ^C # lost patience after a few hours
>> # v0.8.0
>> Requests per second: 252.69 [#/sec] (mean)
>> ```
>> The more bytes you're pushing, and the more work you're doing, the
>> more win you'll see with node 0.8 over 0.6.
>> The vast majority of the performance boost is due to improvements in
>> V8. They've been very responsive to the needs of the Node.js project.
>> A lot of Node's success is due to being built on such a stellar VM.
>> ## Build System
>> Since its inception Node has used the WAF build system which is a
>> Python based system similar to SCons. The Chrome project recently
>> changed to the GYP meta-build system from SCons. GYP generates
>> Makefiles, Visual Studio project files, or XCode files depending on
>> the target. V8, being part of the Chrome project, now defines its
>> build in GYP. By using GYP, Node is able to:
>> - integrate with the optimal build system on all platforms,
>> - easily able to integrate V8's build process into its own, and
>> - define its compilation declaratively for better manageability
>> GYP was used already in Node v0.6 to build on Windows, but now it
>> defines the build on all platforms. Node is still in the process of
>> migrating external addon modules to GYP, and node-gyp is included with
>> npm. In future releases, node-waf will be officially deprecated. If
>> you are currently using a wscript in your addon, please migrate to gyp
>> as soon as possible.
>> ## Stabler
>> The transition from libev and libeio to libuv in 0.6 was somewhat
>> destabilizing for many node internals. The gambit paid off: libuv is
>> the obvious choice in cross-platform asynchronous IO libraries, and
>> Node.js is impressively performant on both Windows and Unix. But it
>> made the transition from 0.4 to 0.6 was very rocky for a lot of users.
>> Libuv wasn't as mature as node, and it showed in those early releases.
>> At this point, with very few exceptions, if your v0.6 program doesn't
>> run on v0.8, it should be easy and obvious to make whatever changes
>> are necessary. Libuv has come a very long way, and Node 0.8 is a
>> simpler and more efficient machine as a result.
>> In Node 0.4, there was a `listenFD` method that servers could use to
>> listen on a specific file descriptor that was already bound to a
>> socket or port. In 0.6, that functionality went away, largely because
>> it was very Unix-specific, and couldn't be easily made to work with
>> the new cross-platform libuv base.
>> Since the most common use case for listenFD was as a method for having
>> servers in multiple node processes share the same underlying handle,
>> the `cluster` module was added in its place. However, this still left
>> a lot of use cases unaddressed, and was a reason why some people could
>> not use node 0.6 for their programs.
>> In 0.8, we've replaced this functionality, as `server.listen({ fd: number
>> })`.
>> The other feature in node 0.4 that got dropped in 0.6 was the ability
>> to pass arbitrary file descriptors as a child process's stdio, using
>> the `customFds` array. In Node 0.6, `customFds` could be used to
>> inherit the parent's stdio handles, but not to pass arbitrary handles
>> or file descriptors to the child's stdio. Also, there was never a way
>> to pass more than the standard `in, out, err` trio, so programs that
>> expected FD 4 to be opened in some specific way were out of luck.
>> In 0.8, we've added the `stdio` array on the `child_process.spawn`
>> options. Pass as many file descriptors, handles, etc. as you like, and
>> the child process will see them as already-opened FDs.
>> Barring these very minor API changes, if you were using cluster in
>> 0.6, then your program will still work, but it'll be faster and more
>> well-behaved now. And if you aren't taking advantage of the new
>> features in 0.8's cluster, you're really missing out.
>> The original idea for Domains was a way to join multiple different IO
>> actions, so that you can have some context when an error occurs.
>> Since Ryan discussed the feature with node users at NodeConf Summer
>> Camp last year, the domains feature has gone through many revisions.
>> The problem is fairly well understood, but most attempts
On Monday, June 25, 2012 8:01:13 AM UTC-7, Isaac Schlueter wrote:
> I am thrilled to announce the arrival of a new stable version of Node.js.
> Compared with the v0.6 releases of Node, this release brings > significant improvements in many key performance metrics, as well as > cleanup in several core APIs, and the addition of new debugging > features.
> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req > # v0.6.19 > ^C # lost patience after a few hours > # v0.8.0 > Requests per second: 252.69 [#/sec] (mean) > ```
> The more bytes you're pushing, and the more work you're doing, the > more win you'll see with node 0.8 over 0.6.
> The vast majority of the performance boost is due to improvements in > V8. They've been very responsive to the needs of the Node.js project. > A lot of Node's success is due to being built on such a stellar VM.
> ## Build System
> Since its inception Node has used the WAF build system which is a > Python based system similar to SCons. The Chrome project recently > changed to the GYP meta-build system from SCons. GYP generates > Makefiles, Visual Studio project files, or XCode files depending on > the target. V8, being part of the Chrome project, now defines its > build in GYP. By using GYP, Node is able to:
> - integrate with the optimal build system on all platforms, > - easily able to integrate V8's build process into its own, and > - define its compilation declaratively for better manageability
> GYP was used already in Node v0.6 to build on Windows, but now it > defines the build on all platforms. Node is still in the process of > migrating external addon modules to GYP, and node-gyp is included with > npm. In future releases, node-waf will be officially deprecated. If > you are currently using a wscript in your addon, please migrate to gyp > as soon as possible.
> ## Stabler
> The transition from libev and libeio to libuv in 0.6 was somewhat > destabilizing for many node internals. The gambit paid off: libuv is > the obvious choice in cross-platform asynchronous IO libraries, and > Node.js is impressively performant on both Windows and Unix. But it > made the transition from 0.4 to 0.6 was very rocky for a lot of users. > Libuv wasn't as mature as node, and it showed in those early releases.
> At this point, with very few exceptions, if your v0.6 program doesn't > run on v0.8, it should be easy and obvious to make whatever changes > are necessary. Libuv has come a very long way, and Node 0.8 is a > simpler and more efficient machine as a result.
> In Node 0.4, there was a `listenFD` method that servers could use to > listen on a specific file descriptor that was already bound to a > socket or port. In 0.6, that functionality went away, largely because > it was very Unix-specific, and couldn't be easily made to work with > the new cross-platform libuv base.
> Since the most common use case for listenFD was as a method for having > servers in multiple node processes share the same underlying handle, > the `cluster` module was added in its place. However, this still left > a lot of use cases unaddressed, and was a reason why some people could > not use node 0.6 for their programs.
> In 0.8, we've replaced this functionality, as `server.listen({ fd: number > })`.
> The other feature in node 0.4 that got dropped in 0.6 was the ability > to pass arbitrary file descriptors as a child process's stdio, using > the `customFds` array. In Node 0.6, `customFds` could be used to > inherit the parent's stdio handles, but not to pass arbitrary handles > or file descriptors to the child's stdio. Also, there was never a way > to pass more than the standard `in, out, err` trio, so programs that > expected FD 4 to be opened in some specific way were out of luck.
> In 0.8, we've added the `stdio` array on the `child_process.spawn` > options. Pass as many file descriptors, handles, etc. as you like, and > the child process will see them as already-opened FDs.
> Barring these very minor API changes, if you were using cluster in > 0.6, then your program will still work, but it'll be faster and more > well-behaved now. And if you aren't taking advantage of the new > features in 0.8's cluster, you're really missing out.
> The original idea for Domains was a way to join multiple different IO > actions, so that you can have some context when an error occurs.
> Since Ryan discussed the feature with node users at NodeConf Summer > Camp last year, the domains feature has gone through many revisions. > The problem is fairly well understood, but most attempts to solve it > resulted in serious performance regressions, or uncovered difficult > edge cases.
> What we ended up with in 0.8 is a very stripped-down version of this > idea. It's entirely opt-in, with minimal performance impact when it's > used (and none when it isn't). There are a lot of examples in [the API > documentation](http://nodejs.org/api/domain.html), so check them out, > and start handling your crashes smarter.
> The domain module is still experimental. We are looking forward to > your feedback, so please use it and let us know what you think.
> ## Repl, Readline, TTY
> The Repl, Readline, and TTY modules have all had a major facelift. The > interfaces between these three modules are cleaned up and refactored, > removing a lot of common pain points and making it easier to use for > debugging your programs.
> It may seem minor at times, but a good repl dramatically increases the > quality
On Monday, June 25, 2012 9:34:32 PM UTC+4, Mark Hahn wrote:
> What is the best way to install 0.8 on ubuntu linux?
> On Mon, Jun 25, 2012 at 8:23 AM, Thomas Fritz <fritz...@gmail.com> wrote:
>> Great Release. >> Big thanks to all developers for their hard work making this release >> possible. >> Now, after realeasing - go home and get yourself a big fresh bottle of >> beer!!
>> Kind regards
>> Am Montag, 25. Juni 2012 17:01:13 UTC+2 schrieb Isaac Schlueter:
>>> I am thrilled to announce the arrival of a new stable version of >>> Node.js.
>>> Compared with the v0.6 releases of Node, this release brings >>> significant improvements in many key performance metrics, as well as >>> cleanup in several core APIs, and the addition of new debugging >>> features.
>>> The difference is not small. If you are writing network programs with >>> node, and pushing a lot of traffic, you will notice this improvement.
>>> The speed of reading files got quite a bit faster as well:
>>> ``` >>> # v0.6.19 >>> read the file 110948 times (higher is better) >>> 90141.32 ns per read (lower is better) >>> 11093.69 reads per sec (higher is better)
>>> # v0.8.0 >>> read the file 158193 times (higher is better) >>> 63217.16 ns per read (lower is better) >>> 15818.48 reads per sec (higher is better) >>> ```
>>> And of course, the ubiquitous 'hello, world' http server benchmark got >>> significantly faster, especially for large message sizes:
>>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req >>> # v0.6.19 >>> ^C # lost patience after a few hours >>> # v0.8.0 >>> Requests per second: 252.69 [#/sec] (mean) >>> ```
>>> The more bytes you're pushing, and the more work you're doing, the >>> more win you'll see with node 0.8 over 0.6.
>>> The vast majority of the performance boost is due to improvements in >>> V8. They've been very responsive to the needs of the Node.js project. >>> A lot of Node's success is due to being built on such a stellar VM.
>>> ## Build System
>>> Since its inception Node has used the WAF build system which is a >>> Python based system similar to SCons. The Chrome project recently >>> changed to the GYP meta-build system from SCons. GYP generates >>> Makefiles, Visual Studio project files, or XCode files depending on >>> the target. V8, being part of the Chrome project, now defines its >>> build in GYP. By using GYP, Node is able to:
>>> - integrate with the optimal build system on all platforms, >>> - easily able to integrate V8's build process into its own, and >>> - define its compilation declaratively for better manageability
>>> GYP was used already in Node v0.6 to build on Windows, but now it >>> defines the build on all platforms. Node is still in the process of >>> migrating external addon modules to GYP, and node-gyp is included with >>> npm. In future releases, node-waf will be officially deprecated. If >>> you are currently using a wscript in your addon, please migrate to gyp >>> as soon as possible.
>>> ## Stabler
>>> The transition from libev and libeio to libuv in 0.6 was somewhat >>> destabilizing for many node internals. The gambit paid off: libuv is >>> the obvious choice in cross-platform asynchronous IO libraries, and >>> Node.js is impressively performant on both Windows and Unix. But it >>> made the transition from 0.4 to 0.6 was very rocky for a lot of users. >>> Libuv wasn't as mature as node, and it showed in those early releases.
>>> At this point, with very few exceptions, if your v0.6 program doesn't >>> run on v0.8, it should be easy and obvious to make whatever changes >>> are necessary. Libuv has come a very long way, and Node 0.8 is a >>> simpler and more efficient machine as a result.
>>> for details on the specific APIs that changed.
>>> ## The Return of File Descriptors
>>> In Node 0.4, there was a `listenFD` method that servers could use to >>> listen on a specific file descriptor that was already bound to a >>> socket or port. In 0.6, that functionality went away, largely because >>> it was very Unix-specific, and couldn't be easily made to work with >>> the new cross-platform libuv base.
>>> Since the most common use case for listenFD was as a method for having >>> servers in multiple node processes share the same underlying handle, >>> the `cluster` module was added in its place. However, this still left >>> a lot of use cases unaddressed, and was a reason why some people could >>> not use node 0.6 for their programs.
>>> In 0.8, we've replaced this functionality, as `server.listen({ fd: >>> number })`.
>>> The other feature in node 0.4 that got dropped in 0.6 was the ability >>> to pass arbitrary file descriptors as a child process's stdio, using >>> the `customFds` array. In Node 0.6, `customFds` could be used to >>> inherit the parent's stdio handles, but not to pass arbitrary handles >>> or file descriptors to the child's stdio. Also, there was never a way >>> to pass more than the standard `in, out, err` trio, so programs that >>> expected FD 4 to be opened in some specific way were out of luck.
>>> In 0.8, we've added the `stdio` array on the `child_process.spawn` >>> options. Pass as many file descriptors, handles, etc. as you like, and >>> the child process will see them as already-opened FDs.
>>> Barring these very minor API changes, if you were using cluster in >>> 0.6, then your program will still work, but it'll be faster and more >>> well-behaved now. And if you aren't taking advantage of the new >>> features in 0.8's cluster, you're really missing out.
On Monday, June 25, 2012 9:36:54 PM UTC+4, Mark Hahn wrote:
> What is the best way to install 0.8 on ubuntu linux?
> On Monday, June 25, 2012 8:01:13 AM UTC-7, Isaac Schlueter wrote:
>> I am thrilled to announce the arrival of a new stable version of Node.js.
>> Compared with the v0.6 releases of Node, this release brings >> significant improvements in many key performance metrics, as well as >> cleanup in several core APIs, and the addition of new debugging >> features.
>> The difference is not small. If you are writing network programs with >> node, and pushing a lot of traffic, you will notice this improvement.
>> The speed of reading files got quite a bit faster as well:
>> ``` >> # v0.6.19 >> read the file 110948 times (higher is better) >> 90141.32 ns per read (lower is better) >> 11093.69 reads per sec (higher is better)
>> # v0.8.0 >> read the file 158193 times (higher is better) >> 63217.16 ns per read (lower is better) >> 15818.48 reads per sec (higher is better) >> ```
>> And of course, the ubiquitous 'hello, world' http server benchmark got >> significantly faster, especially for large message sizes:
>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req >> # v0.6.19 >> ^C # lost patience after a few hours >> # v0.8.0 >> Requests per second: 252.69 [#/sec] (mean) >> ```
>> The more bytes you're pushing, and the more work you're doing, the >> more win you'll see with node 0.8 over 0.6.
>> The vast majority of the performance boost is due to improvements in >> V8. They've been very responsive to the needs of the Node.js project. >> A lot of Node's success is due to being built on such a stellar VM.
>> ## Build System
>> Since its inception Node has used the WAF build system which is a >> Python based system similar to SCons. The Chrome project recently >> changed to the GYP meta-build system from SCons. GYP generates >> Makefiles, Visual Studio project files, or XCode files depending on >> the target. V8, being part of the Chrome project, now defines its >> build in GYP. By using GYP, Node is able to:
>> - integrate with the optimal build system on all platforms, >> - easily able to integrate V8's build process into its own, and >> - define its compilation declaratively for better manageability
>> GYP was used already in Node v0.6 to build on Windows, but now it >> defines the build on all platforms. Node is still in the process of >> migrating external addon modules to GYP, and node-gyp is included with >> npm. In future releases, node-waf will be officially deprecated. If >> you are currently using a wscript in your addon, please migrate to gyp >> as soon as possible.
>> ## Stabler
>> The transition from libev and libeio to libuv in 0.6 was somewhat >> destabilizing for many node internals. The gambit paid off: libuv is >> the obvious choice in cross-platform asynchronous IO libraries, and >> Node.js is impressively performant on both Windows and Unix. But it >> made the transition from 0.4 to 0.6 was very rocky for a lot of users. >> Libuv wasn't as mature as node, and it showed in those early releases.
>> At this point, with very few exceptions, if your v0.6 program doesn't >> run on v0.8, it should be easy and obvious to make whatever changes >> are necessary. Libuv has come a very long way, and Node 0.8 is a >> simpler and more efficient machine as a result.
>> In Node 0.4, there was a `listenFD` method that servers could use to >> listen on a specific file descriptor that was already bound to a >> socket or port. In 0.6, that functionality went away, largely because >> it was very Unix-specific, and couldn't be easily made to work with >> the new cross-platform libuv base.
>> Since the most common use case for listenFD was as a method for having >> servers in multiple node processes share the same underlying handle, >> the `cluster` module was added in its place. However, this still left >> a lot of use cases unaddressed, and was a reason why some people could >> not use node 0.6 for their programs.
>> In 0.8, we've replaced this functionality, as `server.listen({ fd: number >> })`.
>> The other feature in node 0.4 that got dropped in 0.6 was the ability >> to pass arbitrary file descriptors as a child process's stdio, using >> the `customFds` array. In Node 0.6, `customFds` could be used to >> inherit the parent's stdio handles, but not to pass arbitrary handles >> or file descriptors to the child's stdio. Also, there was never a way >> to pass more than the standard `in, out, err` trio, so programs that >> expected FD 4 to be opened in some specific way were out of luck.
>> In 0.8, we've added the `stdio` array on the `child_process.spawn` >> options. Pass as many file descriptors, handles, etc. as you like, and >> the child process will see them as already-opened FDs.
>> ## More Powerful Cluster
>> The cluster module in 0.8 is so much improved over 0.6, it's basically >> a complete rewrite. The API is mostly backwards compatible, but not >> entirely. (See the [migration >> wiki](
>> https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8) >> for details.)
>> Barring these very minor API changes, if you were using cluster in >> 0.6, then your program will still work, but it'll be faster and more >> well-behaved now. And if you aren't taking advantage of the new >> features in 0.8's cluster, you're really missing out.
>> The original idea for Domains was a way to join multiple different IO >> actions, so that you can have some context when an error occurs.
>> Since Ryan discussed the feature with node users at NodeConf Summer >> Camp last year, the domains feature has gone through many revisions. >> The problem is fairly well understood, but most attempts to solve it >> resulted in serious performance regressions, or uncovered difficult >> edge cases.
>> What we ended up with in 0.8 is a very stripped-down version of this >> idea. It's entirely opt-in, with minimal performance impact when it's >> used (and none when it isn't). There are a lot of examples in [the API
> On Monday, June 25, 2012 9:36:54 PM UTC+4, Mark Hahn wrote:
>> What is the best way to install 0.8 on ubuntu linux?
>> On Monday, June 25, 2012 8:01:13 AM UTC-7, Isaac Schlueter wrote:
>>> I am thrilled to announce the arrival of a new stable version of
>>> Node.js.
>>> Compared with the v0.6 releases of Node, this release brings
>>> significant improvements in many key performance metrics, as well as
>>> cleanup in several core APIs, and the addition of new debugging
>>> features.
>>> The difference is not small. If you are writing network programs with
>>> node, and pushing a lot of traffic, you will notice this improvement.
>>> The speed of reading files got quite a bit faster as well:
>>> ```
>>> # v0.6.19
>>> read the file 110948 times (higher is better)
>>> 90141.32 ns per read (lower is better)
>>> 11093.69 reads per sec (higher is better)
>>> # v0.8.0
>>> read the file 158193 times (higher is better)
>>> 63217.16 ns per read (lower is better)
>>> 15818.48 reads per sec (higher is better)
>>> ```
>>> And of course, the ubiquitous 'hello, world' http server benchmark got
>>> significantly faster, especially for large message sizes:
>>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req
>>> # v0.6.19
>>> ^C # lost patience after a few hours
>>> # v0.8.0
>>> Requests per second: 252.69 [#/sec] (mean)
>>> ```
>>> The more bytes you're pushing, and the more work you're doing, the
>>> more win you'll see with node 0.8 over 0.6.
>>> The vast majority of the performance boost is due to improvements in
>>> V8. They've been very responsive to the needs of the Node.js project.
>>> A lot of Node's success is due to being built on such a stellar VM.
>>> ## Build System
>>> Since its inception Node has used the WAF build system which is a
>>> Python based system similar to SCons. The Chrome project recently
>>> changed to the GYP meta-build system from SCons. GYP generates
>>> Makefiles, Visual Studio project files, or XCode files depending on
>>> the target. V8, being part of the Chrome project, now defines its
>>> build in GYP. By using GYP, Node is able to:
>>> - integrate with the optimal build system on all platforms,
>>> - easily able to integrate V8's build process into its own, and
>>> - define its compilation declaratively for better manageability
>>> GYP was used already in Node v0.6 to build on Windows, but now it
>>> defines the build on all platforms. Node is still in the process of
>>> migrating external addon modules to GYP, and node-gyp is included with
>>> npm. In future releases, node-waf will be officially deprecated. If
>>> you are currently using a wscript in your addon, please migrate to gyp
>>> as soon as possible.
>>> ## Stabler
>>> The transition from libev and libeio to libuv in 0.6 was somewhat
>>> destabilizing for many node internals. The gambit paid off: libuv is
>>> the obvious choice in cross-platform asynchronous IO libraries, and
>>> Node.js is impressively performant on both Windows and Unix. But it
>>> made the transition from 0.4 to 0.6 was very rocky for a lot of users.
>>> Libuv wasn't as mature as node, and it showed in those early releases.
>>> At this point, with very few exceptions, if your v0.6 program doesn't
>>> run on v0.8, it should be easy and obvious to make whatever changes
>>> are necessary. Libuv has come a very long way, and Node 0.8 is a
>>> simpler and more efficient machine as a result.
>>> for details on the specific APIs that changed.
>>> ## The Return of File Descriptors
>>> In Node 0.4, there was a `listenFD` method that servers could use to
>>> listen on a specific file descriptor that was already bound to a
>>> socket or port. In 0.6, that functionality went away, largely because
>>> it was very Unix-specific, and couldn't be easily made to work with
>>> the new cross-platform libuv base.
>>> Since the most common use case for listenFD was as a method for having
>>> servers in multiple node processes share the same underlying handle,
>>> the `cluster` module was added in its place. However, this still left
>>> a lot of use cases unaddressed, and was a reason why some people could
>>> not use node 0.6 for their programs.
>>> In 0.8, we've replaced this functionality, as `server.listen({ fd:
>>> number })`.
>>> The other feature in node 0.4 that got dropped in 0.6 was the ability
>>> to pass arbitrary file descriptors as a child process's stdio, using
>>> the `customFds` array. In Node 0.6, `customFds` could be used to
>>> inherit the parent's stdio handles, but not to pass arbitrary handles
>>> or file descriptors to the child's stdio. Also, there was never a way
>>> to pass more than the standard `in, out, err` trio, so programs that
>>> expected FD 4 to be opened in some specific way were out of luck.
>>> In 0.8, we've added the `stdio` array on the `child_process.spawn`
>>> options. Pass as many file descriptors, handles, etc. as you like, and
>>> the child process will see them as already-opened FDs.
>>> Barring these very minor API changes, if you were using cluster in
>>> 0.6, then your program will still work, but it'll be faster and more
>>> well-behaved now. And if you aren't taking advantage of the new
>>> features in 0.8's cluster, you're really missing out.
>> On Monday, June 25, 2012 9:36:54 PM UTC+4, Mark Hahn wrote:
>>> What is the best way to install 0.8 on ubuntu linux?
>>> On Monday, June 25, 2012 8:01:13 AM UTC-7, Isaac Schlueter wrote:
>>>> I am thrilled to announce the arrival of a new stable version of
>>>> Node.js.
>>>> Compared with the v0.6 releases of Node, this release brings
>>>> significant improvements in many key performance metrics, as well as
>>>> cleanup in several core APIs, and the addition of new debugging
>>>> features.
>>>> The difference is not small. If you are writing network programs with
>>>> node, and pushing a lot of traffic, you will notice this improvement.
>>>> The speed of reading files got quite a bit faster as well:
>>>> ```
>>>> # v0.6.19
>>>> read the file 110948 times (higher is better)
>>>> 90141.32 ns per read (lower is better)
>>>> 11093.69 reads per sec (higher is better)
>>>> # v0.8.0
>>>> read the file 158193 times (higher is better)
>>>> 63217.16 ns per read (lower is better)
>>>> 15818.48 reads per sec (higher is better)
>>>> ```
>>>> And of course, the ubiquitous 'hello, world' http server benchmark got
>>>> significantly faster, especially for large message sizes:
>>>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req
>>>> # v0.6.19
>>>> ^C # lost patience after a few hours
>>>> # v0.8.0
>>>> Requests per second: 252.69 [#/sec] (mean)
>>>> ```
>>>> The more bytes you're pushing, and the more work you're doing, the
>>>> more win you'll see with node 0.8 over 0.6.
>>>> The vast majority of the performance boost is due to improvements in
>>>> V8. They've been very responsive to the needs of the Node.js project.
>>>> A lot of Node's success is due to being built on such a stellar VM.
>>>> ## Build System
>>>> Since its inception Node has used the WAF build system which is a
>>>> Python based system similar to SCons. The Chrome project recently
>>>> changed to the GYP meta-build system from SCons. GYP generates
>>>> Makefiles, Visual Studio project files, or XCode files depending on
>>>> the target. V8, being part of the Chrome project, now defines its
>>>> build in GYP. By using GYP, Node is able to:
>>>> - integrate with the optimal build system on all platforms,
>>>> - easily able to integrate V8's build process into its own, and
>>>> - define its compilation declaratively for better manageability
>>>> GYP was used already in Node v0.6 to build on Windows, but now it
>>>> defines the build on all platforms. Node is still in the process of
>>>> migrating external addon modules to GYP, and node-gyp is included with
>>>> npm. In future releases, node-waf will be officially deprecated. If
>>>> you are currently using a wscript in your addon, please migrate to gyp
>>>> as soon as possible.
>>>> ## Stabler
>>>> The transition from libev and libeio to libuv in 0.6 was somewhat
>>>> destabilizing for many node internals. The gambit paid off: libuv is
>>>> the obvious choice in cross-platform asynchronous IO libraries, and
>>>> Node.js is impressively performant on both Windows and Unix. But it
>>>> made the transition from 0.4 to 0.6 was very rocky for a lot of users.
>>>> Libuv wasn't as mature as node, and it showed in those early releases.
>>>> At this point, with very few exceptions, if your v0.6 program doesn't
>>>> run on v0.8, it should be easy and obvious to make whatever changes
>>>> are necessary. Libuv has come a very long way, and Node 0.8 is a
>>>> simpler and more efficient machine as a result.
>>>> for details on the specific APIs that changed.
>>>> ## The Return of File Descriptors
>>>> In Node 0.4, there was a `listenFD` method that servers could use to
>>>> listen on a specific file descriptor that was already bound to a
>>>> socket or port. In 0.6, that functionality went away, largely because
>>>> it was very Unix-specific, and couldn't be easily made to work with
>>>> the new cross-platform libuv base.
>>>> Since the most common use case for listenFD was as a method for having
>>>> servers in multiple node processes share the same underlying handle,
>>>> the `cluster` module was added in its place. However, this still left
>>>> a lot of use cases unaddressed, and was a reason why some people could
>>>> not use node 0.6 for their programs.
>>>> In 0.8, we've replaced this functionality, as `server.listen({ fd:
>>>> number })`.
>>>> The other feature in node 0.4 that got dropped in 0.6 was the ability
>>>> to pass arbitrary file descriptors as a child process's stdio, using
>>>> the `customFds` array. In Node 0.6, `customFds` could be used to
>>>> inherit the parent's stdio handles, but not to pass arbitrary handles
>>>> or file descriptors to the child's stdio. Also, there was never a way
>>>> to pass more than the standard `in, out, err` trio, so programs that
>>>> expected FD 4 to be opened in some specific way were out of luck.
>>>> In 0.8, we've added the `stdio` array on the `child_process.spawn`
>>>> options. Pass as many file descriptors, handles, etc. as you like, and
>>>> the child process will see them as already-opened FDs.
>>>> Barring these very minor API changes, if you were using cluster in
>>>> 0.6, then your program will still work, but it'll be faster and more
>>>> well-behaved now. And if you aren't taking advantage of the new
>>>> features
I'll switch to n github issues now but my latest problem is that I canceled
the 0.6.18 install and now I can't get rid of it. `n rm 0.6.18` silently
fails.
>>> On Monday, June 25, 2012 9:36:54 PM UTC+4, Mark Hahn wrote:
>>>> What is the best way to install 0.8 on ubuntu linux?
>>>> On Monday, June 25, 2012 8:01:13 AM UTC-7, Isaac Schlueter wrote:
>>>>> I am thrilled to announce the arrival of a new stable version of
>>>>> Node.js.
>>>>> Compared with the v0.6 releases of Node, this release brings
>>>>> significant improvements in many key performance metrics, as well as
>>>>> cleanup in several core APIs, and the addition of new debugging
>>>>> features.
>>>>> The difference is not small. If you are writing network programs with
>>>>> node, and pushing a lot of traffic, you will notice this improvement.
>>>>> The speed of reading files got quite a bit faster as well:
>>>>> ```
>>>>> # v0.6.19
>>>>> read the file 110948 times (higher is better)
>>>>> 90141.32 ns per read (lower is better)
>>>>> 11093.69 reads per sec (higher is better)
>>>>> # v0.8.0
>>>>> read the file 158193 times (higher is better)
>>>>> 63217.16 ns per read (lower is better)
>>>>> 15818.48 reads per sec (higher is better)
>>>>> ```
>>>>> And of course, the ubiquitous 'hello, world' http server benchmark got
>>>>> significantly faster, especially for large message sizes:
>>>>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req
>>>>> # v0.6.19
>>>>> ^C # lost patience after a few hours
>>>>> # v0.8.0
>>>>> Requests per second: 252.69 [#/sec] (mean)
>>>>> ```
>>>>> The more bytes you're pushing, and the more work you're doing, the
>>>>> more win you'll see with node 0.8 over 0.6.
>>>>> The vast majority of the performance boost is due to improvements in
>>>>> V8. They've been very responsive to the needs of the Node.js project.
>>>>> A lot of Node's success is due to being built on such a stellar VM.
>>>>> ## Build System
>>>>> Since its inception Node has used the WAF build system which is a
>>>>> Python based system similar to SCons. The Chrome project recently
>>>>> changed to the GYP meta-build system from SCons. GYP generates
>>>>> Makefiles, Visual Studio project files, or XCode files depending on
>>>>> the target. V8, being part of the Chrome project, now defines its
>>>>> build in GYP. By using GYP, Node is able to:
>>>>> - integrate with the optimal build system on all platforms,
>>>>> - easily able to integrate V8's build process into its own, and
>>>>> - define its compilation declaratively for better manageability
>>>>> GYP was used already in Node v0.6 to build on Windows, but now it
>>>>> defines the build on all platforms. Node is still in the process of
>>>>> migrating external addon modules to GYP, and node-gyp is included with
>>>>> npm. In future releases, node-waf will be officially deprecated. If
>>>>> you are currently using a wscript in your addon, please migrate to gyp
>>>>> as soon as possible.
>>>>> ## Stabler
>>>>> The transition from libev and libeio to libuv in 0.6 was somewhat
>>>>> destabilizing for many node internals. The gambit paid off: libuv is
>>>>> the obvious choice in cross-platform asynchronous IO libraries, and
>>>>> Node.js is impressively performant on both Windows and Unix. But it
>>>>> made the transition from 0.4 to 0.6 was very rocky for a lot of users.
>>>>> Libuv wasn't as mature as node, and it showed in those early releases.
>>>>> At this point, with very few exceptions, if your v0.6 program doesn't
>>>>> run on v0.8, it should be easy and obvious to make whatever changes
>>>>> are necessary. Libuv has come a very long way, and Node 0.8 is a
>>>>> simpler and more efficient machine as a result.
>>>>> for details on the specific APIs that changed.
>>>>> ## The Return of File Descriptors
>>>>> In Node 0.4, there was a `listenFD` method that servers could use to
>>>>> listen on a specific file descriptor that was already bound to a
>>>>> socket or port. In 0.6, that functionality went away, largely because
>>>>> it was very Unix-specific, and couldn't be easily made to work with
>>>>> the new cross-platform libuv base.
>>>>> Since the most common use case for listenFD was as a method for having
>>>>> servers in multiple node processes share the same underlying handle,
>>>>> the `cluster` module was added in its place. However, this still left
>>>>> a lot of use cases unaddressed, and was a reason why some people could
>>>>> not use node 0.6 for their programs.
>>>>> In 0.8, we've replaced this functionality, as `server.listen({ fd:
>>>>> number })`.
>>>>> The other feature in node 0.4 that got dropped in 0.6 was the ability
>>>>> to pass arbitrary file descriptors as a child process's stdio, using
>>>>> the `customFds` array. In Node 0.6, `customFds` could be used to
>>>>> inherit the parent's stdio handles, but not to pass arbitrary handles
>>>>> or file descriptors to the child's stdio. Also, there was never a way
>>>>> to pass more than the standard `in, out, err` trio, so programs that
>>>>> expected FD 4 to be opened in some specific way were out of luck.
>>>>> In 0.8, we've added the `stdio` array on the `child_process.spawn`
>>>>> options. Pass as many file descriptors, handles, etc. as you like, and
>>>>> the child process will see them as already-opened FDs.
>>>>> ## More Powerful Cluster
>>>>> The cluster module in 0.8 is so much improved over 0.6, it's basically
>>>>> a complete rewrite. The API is mostly backwards compatible,
On Mon, Jun 25, 2012 at 12:53 PM, Mark Hahn <m...@hahnca.com> wrote:
> I'll switch to n github issues now but my latest problem is that I
> canceled the 0.6.18 install and now I can't get rid of it. `n rm 0.6.18`
> silently fails.
> On Mon, Jun 25, 2012 at 10:48 AM, Mark Hahn <m...@hahnca.com> wrote:
>> FYI, I did `n stable` and got 0.6.18.
>> On Mon, Jun 25, 2012 at 10:46 AM, Mark Hahn <m...@hahnca.com> wrote:
>>> Does n work the same way as nvm?
>>> On Mon, Jun 25, 2012 at 10:43 AM, Eldar <eldar...@gmail.com> wrote:
>>>> On Monday, June 25, 2012 9:36:54 PM UTC+4, Mark Hahn wrote:
>>>>> What is the best way to install 0.8 on ubuntu linux?
>>>>> On Monday, June 25, 2012 8:01:13 AM UTC-7, Isaac Schlueter wrote:
>>>>>> I am thrilled to announce the arrival of a new stable version of
>>>>>> Node.js.
>>>>>> Compared with the v0.6 releases of Node, this release brings
>>>>>> significant improvements in many key performance metrics, as well as
>>>>>> cleanup in several core APIs, and the addition of new debugging
>>>>>> features.
>>>>>> The difference is not small. If you are writing network programs with
>>>>>> node, and pushing a lot of traffic, you will notice this improvement.
>>>>>> The speed of reading files got quite a bit faster as well:
>>>>>> ```
>>>>>> # v0.6.19
>>>>>> read the file 110948 times (higher is better)
>>>>>> 90141.32 ns per read (lower is better)
>>>>>> 11093.69 reads per sec (higher is better)
>>>>>> # v0.8.0
>>>>>> read the file 158193 times (higher is better)
>>>>>> 63217.16 ns per read (lower is better)
>>>>>> 15818.48 reads per sec (higher is better)
>>>>>> ```
>>>>>> And of course, the ubiquitous 'hello, world' http server benchmark
>>>>>> got
>>>>>> significantly faster, especially for large message sizes:
>>>>>> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req
>>>>>> # v0.6.19
>>>>>> ^C # lost patience after a few hours
>>>>>> # v0.8.0
>>>>>> Requests per second: 252.69 [#/sec] (mean)
>>>>>> ```
>>>>>> The more bytes you're pushing, and the more work you're doing, the
>>>>>> more win you'll see with node 0.8 over 0.6.
>>>>>> The vast majority of the performance boost is due to improvements in
>>>>>> V8. They've been very responsive to the needs of the Node.js project.
>>>>>> A lot of Node's success is due to being built on such a stellar VM.
>>>>>> ## Build System
>>>>>> Since its inception Node has used the WAF build system which is a
>>>>>> Python based system similar to SCons. The Chrome project recently
>>>>>> changed to the GYP meta-build system from SCons. GYP generates
>>>>>> Makefiles, Visual Studio project files, or XCode files depending on
>>>>>> the target. V8, being part of the Chrome project, now defines its
>>>>>> build in GYP. By using GYP, Node is able to:
>>>>>> - integrate with the optimal build system on all platforms,
>>>>>> - easily able to integrate V8's build process into its own, and
>>>>>> - define its compilation declaratively for better manageability
>>>>>> GYP was used already in Node v0.6 to build on Windows, but now it
>>>>>> defines the build on all platforms. Node is still in the process of
>>>>>> migrating external addon modules to GYP, and node-gyp is included
>>>>>> with
>>>>>> npm. In future releases, node-waf will be officially deprecated. If
>>>>>> you are currently using a wscript in your addon, please migrate to
>>>>>> gyp
>>>>>> as soon as possible.
>>>>>> ## Stabler
>>>>>> The transition from libev and libeio to libuv in 0.6 was somewhat
>>>>>> destabilizing for many node internals. The gambit paid off: libuv is
>>>>>> the obvious choice in cross-platform asynchronous IO libraries, and
>>>>>> Node.js is impressively performant on both Windows and Unix. But it
>>>>>> made the transition from 0.4 to 0.6 was very rocky for a lot of
>>>>>> users.
>>>>>> Libuv wasn't as mature as node, and it showed in those early
>>>>>> releases.
>>>>>> At this point, with very few exceptions, if your v0.6 program doesn't
>>>>>> run on v0.8, it should be easy and obvious to make whatever changes
>>>>>> are necessary. Libuv has come a very long way, and Node 0.8 is a
>>>>>> simpler and more efficient machine as a result.
>>>>>> for details on the specific APIs that changed.
>>>>>> ## The Return of File Descriptors
>>>>>> In Node 0.4, there was a `listenFD` method that servers could use to
>>>>>> listen on a specific file descriptor that was already bound to a
>>>>>> socket or port. In 0.6, that functionality went away, largely because
>>>>>> it was very Unix-specific, and couldn't be easily made to work with
>>>>>> the new cross-platform libuv base.
>>>>>> Since the most common use case for listenFD was as a method for
>>>>>> having
>>>>>> servers in multiple node processes share the same underlying handle,
>>>>>> the `cluster` module was added in its place. However, this still left
>>>>>> a lot of use cases unaddressed, and was a reason why some people
>>>>>> could
>>>>>> not use node 0.6 for their programs.
>>>>>> In 0.8, we've replaced this functionality, as `server.listen({ fd:
>>>>>> number })`.
>>>>>> The other feature in node 0.4 that got dropped in 0.6 was the ability
>>>>>> to pass arbitrary file descriptors as a child process's stdio, using
>>>>>> the `customFds` array. In Node 0.6, `customFds` could be used to
>>>>>> inherit the parent's stdio handles, but not to pass arbitrary handles
>>>>>> or file descriptors to the child's stdio. Also, there was never a way
>>>>>> to pass more than the standard `in, out, err`
> I am thrilled to announce the arrival of a new stable version of Node.js.
> Compared with the v0.6 releases of Node, this release brings > significant improvements in many key performance metrics, as well as > cleanup in several core APIs, and the addition of new debugging > features.
> $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep Req > # v0.6.19 > ^C # lost patience after a few hours > # v0.8.0 > Requests per second: 252.69 [#/sec] (mean) > ```
> The more bytes you're pushing, and the more work you're doing, the > more win you'll see with node 0.8 over 0.6.
> The vast majority of the performance boost is due to improvements in > V8. They've been very responsive to the needs of the Node.js project. > A lot of Node's success is due to being built on such a stellar VM.
> ## Build System
> Since its inception Node has used the WAF build system which is a > Python based system similar to SCons. The Chrome project recently > changed to the GYP meta-build system from SCons. GYP generates > Makefiles, Visual Studio project files, or XCode files depending on > the target. V8, being part of the Chrome project, now defines its > build in GYP. By using GYP, Node is able to:
> - integrate with the optimal build system on all platforms, > - easily able to integrate V8's build process into its own, and > - define its compilation declaratively for better manageability
> GYP was used already in Node v0.6 to build on Windows, but now it > defines the build on all platforms. Node is still in the process of > migrating external addon modules to GYP, and node-gyp is included with > npm. In future releases, node-waf will be officially deprecated. If > you are currently using a wscript in your addon, please migrate to gyp > as soon as possible.
> ## Stabler
> The transition from libev and libeio to libuv in 0.6 was somewhat > destabilizing for many node internals. The gambit paid off: libuv is > the obvious choice in cross-platform asynchronous IO libraries, and > Node.js is impressively performant on both Windows and Unix. But it > made the transition from 0.4 to 0.6 was very rocky for a lot of users. > Libuv wasn't as mature as node, and it showed in those early releases.
> At this point, with very few exceptions, if your v0.6 program doesn't > run on v0.8, it should be easy and obvious to make whatever changes > are necessary. Libuv has come a very long way, and Node 0.8 is a > simpler and more efficient machine as a result.
> In Node 0.4, there was a `listenFD` method that servers could use to > listen on a specific file descriptor that was already bound to a > socket or port. In 0.6, that functionality went away, largely because > it was very Unix-specific, and couldn't be easily made to work with > the new cross-platform libuv base.
> Since the most common use case for listenFD was as a method for having > servers in multiple node processes share the same underlying handle, > the `cluster` module was added in its place. However, this still left > a lot of use cases unaddressed, and was a reason why some people could > not use node 0.6 for their programs.
> In 0.8, we've replaced this functionality, as `server.listen({ fd: number > })`.
> The other feature in node 0.4 that got dropped in 0.6 was the ability > to pass arbitrary file descriptors as a child process's stdio, using > the `customFds` array. In Node 0.6, `customFds` could be used to > inherit the parent's stdio handles, but not to pass arbitrary handles > or file descriptors to the child's stdio. Also, there was never a way > to pass more than the standard `in, out, err` trio, so programs that > expected FD 4 to be opened in some specific way were out of luck.
> In 0.8, we've added the `stdio` array on the `child_process.spawn` > options. Pass as many file descriptors, handles, etc. as you like, and > the child process will see them as already-opened FDs.
> Barring these very minor API changes, if you were using cluster in > 0.6, then your program will still work, but it'll be faster and more > well-behaved now. And if you aren't taking advantage of the new > features in 0.8's cluster, you're really missing out.
> The original idea for Domains was a way to join multiple different IO > actions, so that you can have some context when an error occurs.
> Since Ryan discussed the feature with node users at NodeConf Summer > Camp last year, the domains feature has gone through many revisions. > The problem is fairly well understood, but most attempts to solve it > resulted in serious performance regressions, or uncovered difficult > edge cases.
> What we ended up with in 0.8 is a very stripped-down version of this > idea. It's entirely opt-in, with minimal performance impact when it's > used (and none when it isn't). There are a lot of examples in [the API > documentation](http://nodejs.org/api/domain.html), so check them out, > and start handling your crashes smarter.
> The domain module is still experimental. We are looking forward to > your feedback, so please use it and let us know what you
