4 ms·

io.js 1.4 released – featuring debuggable ES6 promises

64 points by inglor 12y ago

pfraze 12y 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 https://gist.github.com/benjamingr/0237932cee84712951a2
- inglor 12y ago
  You can find them here: https://github.com/iojs/io.js/blob/v1.x/doc/api/process.markdown#event-unhandledrejection 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.
  - pfraze 12y ago
    Docs look good to me.
colinramsay 12y 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 12y 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.
- inglor 12y 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 https://github.com/iojs/io.js/issues/932
  - colinramsay 12y ago
    So issues beyond the control of io.js then? Makes more sense, just unfortunate I suppose.
    - shouldbeworking 12y ago
      Not really unfortunate. Unlike with money, inflation of version numbers doesn't cause that much trouble. It just takes some getting used to. I've gotten used to the high version numbers in Chrome and Firefox, and I'm sure I'll get used to them in projects that use semver the right way as well.
apaprocki 12y 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/mark-compact.cc#L3185 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-1440e8305d54e104797269f3835ac0bfR3055 https://github.com/iojs/io.js/pull/952/files#diff-1440e8305d... It is kind of annoying that the bug is embargoed...
- inglor 12y 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.
  - apaprocki 12y 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 12y ago
I'm only seeing 1.3 in the changelog. =(
- inglor 12y ago
  Yes there was a short regression with libuv on macs, here https://github.com/iojs/io.js/issues/932#issuecomment-76022607 https://github.com/iojs/io.js/issues/932#issuecomment-760226...
statenjason 12y 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-76048069 https://github.com/iojs/io.js/issues/932#issuecomment-760480...
- inglor 12y ago
  There is a short regression for https://github.com/iojs/io.js/issues/932#issuecomment-76022607 https://github.com/iojs/io.js/issues/932#issuecomment-760226...
- doublerebel 12y 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 12y ago
Sweet. Any speed improvements to the ArrayBuffers? http://geekregator.com/2015-01-19-node_js_and_io_js_very_different_in_performance.html http://geekregator.com/2015-01-19-node_js_and_io_js_very_dif... For us with Clara.io, TypedBuffers are pretty important.
ndesaulniers 12y 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_ 12y 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?
- inglor 12y 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 https://github.com/iojs/io.js/issues/830
gnrlbzik 12y ago
Is it a typo in title? From the page: ``` io.js ChangeLog 2015-02-20, Version 1.3.0, @rvagg ```
deleted 12y ago
[deleted]

64 points by inglor 12y 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 https://gist.github.com/benjamingr/0237932cee84712951a2

inglor 12y ago
You can find them here: https://github.com/iojs/io.js/blob/v1.x/doc/api/process.markdown#event-unhandledrejection 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.
- pfraze 12y ago
  Docs look good to me.

colinramsay 12y 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 12y 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.
inglor 12y 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 https://github.com/iojs/io.js/issues/932
- colinramsay 12y ago
  So issues beyond the control of io.js then? Makes more sense, just unfortunate I suppose.
  - shouldbeworking 12y ago
    Not really unfortunate. Unlike with money, inflation of version numbers doesn't cause that much trouble. It just takes some getting used to. I've gotten used to the high version numbers in Chrome and Firefox, and I'm sure I'll get used to them in projects that use semver the right way as well.

apaprocki 12y 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/mark-compact.cc#L3185 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-1440e8305d54e104797269f3835ac0bfR3055 https://github.com/iojs/io.js/pull/952/files#diff-1440e8305d... It is kind of annoying that the bug is embargoed...

inglor 12y 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.
- apaprocki 12y 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 12y ago

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

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

statenjason 12y 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-76048069 https://github.com/iojs/io.js/issues/932#issuecomment-760480...

inglor 12y ago
There is a short regression for https://github.com/iojs/io.js/issues/932#issuecomment-76022607 https://github.com/iojs/io.js/issues/932#issuecomment-760226...
doublerebel 12y 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 12y ago

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

ndesaulniers 12y 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_ 12y 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?

inglor 12y 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 https://github.com/iojs/io.js/issues/830

gnrlbzik 12y ago

Is it a typo in title? From the page: ``` io.js ChangeLog 2015-02-20, Version 1.3.0, @rvagg ```

deleted 12y ago

[deleted]