io.js 1.4 released – featuring debuggable ES6 promises

https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md

by inglor • 11 years ago

64 21 11 years ago

pfraze2• 11 years ago

Details about the rejectionUnhandled events dont seem to be in the docs yet, but this gist [1] explains it in detail. Looks like a decent solution to quiet suppression of unhandled rejections.

1 https://gist.github.com/benjamingr/0237932cee84712951a2

inglor6• 11 years ago

You can find them here: https://github.com/iojs/io.js/blob/v1.x/doc/api/process.mark... it'll take a bit longer until the website syncs.

We're interested in feedback on how the event descriptions are phrased since there is some controversy regarding how these events "should be used" - if anyone has any feedback on phrasing or how to explain the usage of these events better I'd love to know how to improve them more.

pfraze2• 11 years ago

Docs look good to me.

colinramsay2• 11 years ago

Hang on - 1.3 was only about three days ago! Rapid progress is obviously fantastic, but is there a reason why these two releases weren't bundled together?

Edit: five days ago, but my point stands.

Whitespace• 11 years ago

Probably due to V8 upgrade which contains an embargoed fix. These are usually critical bugs that remain undisclosed until major users (read as: large companies) have patched their systems.

inglor6• 11 years ago

Great question. It started off as 1.3.x but ended up being 1.4 for semver issues. There was discussion[1] about this. In short - it was named 1.4 because of how NPM updated and because of the big features landing.

[1] https://github.com/iojs/io.js/issues/932

colinramsay2• 11 years ago

So issues beyond the control of io.js then? Makes more sense, just unfortunate I suppose.

apaprocki2• 11 years ago

So it appears that Node is vulnerable to the bug because Google won't backport the fix:

https://github.com/joyent/node/blob/master/deps/v8/src/heap/...

assuming this is the issue:

https://github.com/iojs/io.js/pull/952/files#diff-1440e8305d...

It is kind of annoying that the bug is embargoed...

inglor6• 11 years ago

In Google's defence - they have stated they won't support versions of v8 that reached end of life and have announced they're supporting io.js in favor of node. I totally get why Google won't backport fixes like this.

Google is actively helping io.js and development is coordinated.

apaprocki2• 11 years ago

To be clear, I find it annoying Google is not yet making the bug public even though the fix and test driver are available. Since they aren't going to patch the v8 in Node, I'd think Node users would really like to know if they are vulnerable to this and should manually patch it. stares at Joyent

bsimpson• 11 years ago

I'm only seeing 1.3 in the changelog. =(

inglor6• 11 years ago

Yes there was a short regression with libuv on macs, here https://github.com/iojs/io.js/issues/932#issuecomment-760226...

statenjason• 11 years ago

I'm not seeing a 1.4 entry in the changelog. What's the deal?

Edit: They force pushed to master to remove the release due to issues on OSX

https://github.com/iojs/io.js/issues/932#issuecomment-760480...

inglor6• 11 years ago

There is a short regression for https://github.com/iojs/io.js/issues/932#issuecomment-760226...

doublerebel• 11 years ago

Is this two releases in a row now that have had a major issue due to speed of release and lack of testing?

Seriously I think it is great to push the platform forward but this is exactly what Joyent was cautious about. Solves some bugs but creates other less predictable problems.

Current node-debugger still does not work with io.js so I am curious how the feature is debuggable.

bhouston• 11 years ago

Sweet.

Any speed improvements to the ArrayBuffers? http://geekregator.com/2015-01-19-node_js_and_io_js_very_dif... For us with Clara.io, TypedBuffers are pretty important.

ndesaulniers• 11 years ago

Trevor Norris informed me that C++11 must be supported for the version of v8 that iojs ships with, which means node native module authors can use C++11. The native stream stuff looks neat, too. As an author of a node native add on, I look forward to this iojs/node fork stuff being resolved, so that I can start using new features. Until then, I refuse to make drop support for node.js.

_greim_• 11 years ago

So is the default use case this?

    process.on('unhandledRejection', function(ex){
      throw ex;
    });

...the idea being that it's analogous to an uncaught exception bubbling up to the top and causing the process to crash, which is generally what you want to happen?

inglor6• 11 years ago

Yes, it's possible this indeed will be the default behavior at some later point.

Some people don't like this since `unhandledRejection`s can be handled later on at some point (for example, after a week of not adding a catch handler).

There is a discussion here: https://github.com/iojs/io.js/issues/830

gnrlbzik• 11 years ago

Is it a typo in title? From the page:

``` io.js ChangeLog 2015-02-20, Version 1.3.0, @rvagg ```

io.js 1.4 released – featuring debuggable ES6 promises

Related Stories