io.js v3 preparation

[rvagg]

So! We have V8 4.4 in io.js/next now and the next-nightlies are also coming out with both header-only tarballs and a node-gyp that is hacked to understand when it's running on a nightly, next-nightly, rc or release build and will then grab the headers tarball from the right location. i.e. npm install <compiled addon> should work properly on next-nightly builds and RC builds that I'm about to start pushing out for io.js v3. We need to get NAN rolled out to cope with this now that we have a target to work against.

From this build: https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c6/

$ npm i buffertools
npm http request GET https://registry.npmjs.org/buffertools
npm http 304 https://registry.npmjs.org/buffertools
npm WARN engine buffertools@2.1.2: wanted: {"node":">=0.3.0"} (current: {"node":"2.3.1-next-nightly201506308f6f4280c6","npm":"2.11.3"})

> buffertools@2.1.2 install /tmp/node_modules/buffertools
> node-gyp rebuild

gyp http GET https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c6/iojs-v2.3.1-next-nightly201506308f6f4280c6-headers.tar.gz
gyp http 200 https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c6/iojs-v2.3.1-next-nightly201506308f6f4280c6-headers.tar.gz
gyp http GET https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c6/SHASUMS256.txt
gyp http 200 https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c6/SHASUMS256.txt
make: Entering directory '/tmp/node_modules/buffertools/build'
  CXX(target) Release/obj.target/buffertools/buffertools.o
../buffertools.cc: In function ‘v8::Local<v8::Value> {anonymous}::decodeHex(const uint8_t*, size_t, const v8::FunctionCallbackInfo<v8::Value>&, uint32_t)’:
../buffertools.cc:367:71: error: conversion from ‘v8::MaybeLocal<v8::Object>’ to non-scalar type ‘v8::Local<v8::Object>’ requested
   Local<Object> buffer = UNI_BUFFER_NEW(size / 2);
                                                                       ^
../buffertools.cc: In function ‘void {anonymous}::Concat(const v8::FunctionCallbackInfo<v8::Value>&)’:
../buffertools.cc:459:67: error: conversion from ‘v8::MaybeLocal<v8::Object>’ to non-scalar type ‘v8::Local<v8::Object>’ requested
   Local<Object> buffer = UNI_BUFFER_NEW(size);
                                                                   ^
buffertools.target.mk:88: recipe for target 'Release/obj.target/buffertools/buffertools.o' failed
make: *** [Release/obj.target/buffertools/buffertools.o] Error 1
make: Leaving directory '/tmp/node_modules/buffertools/build'

@kkoopa can you let us know if there's anything blocking a release to cope with this so we can make it happen asap?

[kkoopa]

I'll check, but I don't think there's more than cosmetic fixes (naming and
such) to fix.

On Tuesday 30 June 2015 00:20:34 Rod Vagg wrote:

So! We have V8 4.4 in io.js/next now and the next-nightlies are also coming
out with both header-only tarballs and a node-gyp that is hacked to
understand when it's running on a nightly, next-nightly, rc or release
build and will then grab the headers tarball from the right location. i.e.
npm install <compiled addon> should work properly on next-nightly builds
and RC builds that I'm about to start pushing out for io.js v3. We need to
get NAN rolled out to cope with this now that we have a target to work
against.

From this build:
https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c
6/

$ npm i buffertools
npm http request GET https://registry.npmjs.org/buffertools
npm http 304 https://registry.npmjs.org/buffertools
npm WARN engine buffertools@2.1.2: wanted: {"node":">=0.3.0"} (current:
{"node":"2.3.1-next-nightly201506308f6f4280c6","npm":"2.11.3"})
> buffertools@2.1.2 install /tmp/node_modules/buffertools
> node-gyp rebuild

gyp http GET
https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c
6/iojs-v2.3.1-next-nightly201506308f6f4280c6-headers.tar.gz gyp http 200
https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c
6/iojs-v2.3.1-next-nightly201506308f6f4280c6-headers.tar.gz gyp http GET
https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c
6/SHASUMS256.txt gyp http 200
https://iojs.org/download/next-nightly/v2.3.1-next-nightly201506308f6f4280c
6/SHASUMS256.txt make: Entering directory
'/tmp/node_modules/buffertools/build'
  CXX(target) Release/obj.target/buffertools/buffertools.o
../buffertools.cc: In function ‘v8::Local<v8::Value>
{anonymous}::decodeHex(const uint8_t*, size_t, const
v8::FunctionCallbackInfo<v8::Value>&, uint32_t)’: ../buffertools.cc:367:71:
error: conversion from ‘v8::MaybeLocal<v8::Object>’ to non-scalar type
‘v8::Local<v8::Object>’ requested Local<Object> buffer =
UNI_BUFFER_NEW(size / 2);
                                                                       ^
../buffertools.cc: In function ‘void {anonymous}::Concat(const
v8::FunctionCallbackInfo<v8::Value>&)’: ../buffertools.cc:459:67: error:
conversion from ‘v8::MaybeLocal<v8::Object>’ to non-scalar type
‘v8::Local<v8::Object>’ requested Local<Object> buffer =
UNI_BUFFER_NEW(size);
                                                                   ^
buffertools.target.mk:88: recipe for target
'Release/obj.target/buffertools/buffertools.o' failed make: ***
[Release/obj.target/buffertools/buffertools.o] Error 1
make: Leaving directory '/tmp/node_modules/buffertools/build'

@kkoopa can you let us know if there's anything blocking a release to cope
with this so we can make it happen asap?

---

Reply to this email directly or view it on GitHub:
#376

[bnoordhuis]

buffertools doesn't use nan at the moment (it uses a hand-rolled compat shim) but I can migrate it to nan if you think it's a useful guinea pig.

[rvagg]

not necessary @bnoordhuis, I just use it as a quick test for the runtime, not nan necessarily, cause it's small and a quick compile. bignum is probably just as good for testing nan.

[rvagg]

https://iojs.org/download/rc/v3.0.0-rc1/

There's an RC1, we'll hold off on publicising it and putting it on iojs.org until we have a NAN release out.

[rvagg]

Some issues in attempting a migration of leveldown to nan@next, which I'm obviously far from achieving but here are some things I've encountered so far:

• The RC1 build still has the same NODE_MODULE_VERSION as io.js v2, I should have bumped it to 45 and I'll have to do an RC2 to accommodate this. Grr.
• Internal references in NAN don't use the namespace so unless you are using namespace Nan you get errors, so far just on the NAN_METHOD, NAN_GETTER etc. definitions, should be using Nan::NAN_METHOD_RETURN_TYPE etc.
• We need to take into account the lack of a native node::smalloc in v3:

../node_modules/nan/nan.h:667:13: error: ‘node::smalloc’ has not been declared
     , node::smalloc::FreeCallback callback

• My compiler is warning of redefinition of EnsureHandleOrPersistent and EnsureLocal, I can comment out the v8::Local<T> ones to make these warnings go away.

And finally: I have clearly lost track of the rewriting going on in NAN because this is super-painful and I feel like I don't have enough context. The change to implementing Nan versions of FunctionInfoCallback and Persistent have caught me a little off guard. I tried to use the 1to2.js tool initially but with not much success so I backed up and started picking off the changes using sed and now I'm stuck at trying to grok the new funky Maybe stuff.

So, my take-away is that there's a huge need for documentation to get NAN@2 out, both formal API documentation but also a primer for people upgrading, otherwise we're just going to have a lot of wailing and gnashing of teeth (actually that might be hard to avoid anyway!). I can write docs but I don't have enough information to start with and will likely do a bad job at it. Perhaps @kkoopa et. al. could provide some dot-points of the major changes that I can use as a starting point to begin investigation?

[trevnorris]

Ooh yeah. The removal of smalloc was a last minute change when V8 was updated to v4.4 after latest nan had been released. Couldn't have been accounted for.

[mathiask88]

@rvagg kkoopa wrote a migration tool based on libclang (https://github.com/kkoopa/node-libclang/tree/experiment?files=1) but I don't know the status of that. The plan was to wrap this tool into a prebuild electron app making the conversion as easy as possible (select binding.gyp->press convert->show some help how to deal with Maybes->done)

[rvagg]

that sounds like a lot of work when we need this released yesterday

[kkoopa]

It's not necessary for release. Can come at some later point.

[rvagg]

RC2 https://iojs.org/download/rc/v3.0.0-rc2/ minor V8 update, NODE_MODULE_VERSION bumped

[rvagg]

babel is fine with this version in smoke testing except for:

  1) util regexify:
     AssertionError: /\x66oo|\x62ar/i deepEqual /foo|bar/i

😕

[rvagg]

aaand I can't smoke test npm@master now either:

Packaging or installing npm@3.0.0 with npm@2.11.3 is impossible.
Please install npm@^3.0.0-0 from the registry and use that or run your command with
this version of npm with:
    /usr/local/bin/iojs /smoke/npm install --cache-min=Infinity

[domenic]

@Fishrock123 was looking in to npm@3, summoning him... that is a strange error. Maybe try that thing it asks you to do with cache-min?

[rvagg]

actually, ignore those 2 msgs, I thought I was in the v2.3.2 release thread! this is not relevant to v3.0.0, I confused