Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

0.9 WIP #86

Merged
merged 75 commits into from May 4, 2014

Conversation

Projects
None yet
6 participants
Owner

rvagg commented Mar 15, 2014

Targeting 0.11.13, or before if we're comfortable with the stability.

Replaces #64

@bnoordhuis bnoordhuis and 1 other commented on an outdated diff Mar 16, 2014

@@ -153,6 +156,14 @@
# define NAN_DEPRECATED(declarator) declarator
#endif
+#ifdef _MSC_VER
+#if _MSC_VER < 1600
+// TODO(kkoopa): Implement
+#else
+#define typeof(expression) decltype(expression)
@bnoordhuis

bnoordhuis Mar 16, 2014

Member

Should probably be called NAN_TYPEOF to avoid conflicts with user code.

@kkoopa

kkoopa Mar 16, 2014

Collaborator

It's not used anywhere in future revisions, so it can be safely removed (until it might have to return at some future point).

@bnoordhuis bnoordhuis commented on an outdated diff Mar 16, 2014

@@ -801,7 +967,7 @@ class NanCallback {
callback = NULL;
}
- void SavePersistent(const char *key, v8::Local<v8::Object> &obj) {
+ void SavePersistent(const char *key, const v8::Local<v8::Object> &obj) {
@bnoordhuis

bnoordhuis Mar 16, 2014

Member

It doesn't hurt to have obj be a reference here (usually - temporary rvalues might be an issue) but using copy semantics here would be okay too.

A Local (a Handle too) is essentially a pointer wrapped in a struct. You don't gain much by passing references around because copying the object is as cheap as referencing it.

A copy might even be cheaper because it removes a layer of indirection. Though I'm reasonably sure that in this case the compiler will generate the same code for a reference because this method is great inlining material.

/digression

@bnoordhuis bnoordhuis and 1 other commented on an outdated diff Mar 16, 2014

@@ -1111,7 +1278,9 @@ static NAN_INLINE(void* NanRawString(
}
NanSetPointerSafe<size_t>(
datalen
- , toStr->WriteUtf8(to, int(sz_ + term_len), NULL, flags) - term_len);
+ , toStr->WriteUtf8(to, static_cast<int>(sz_ + term_len) \
+ , NULL, flags) \
@bnoordhuis

bnoordhuis Mar 16, 2014

Member

Erroneous backslashes?

@kkoopa

kkoopa Mar 16, 2014

Collaborator

Yes, I saw them earlier today and removed them in the cleanup branch.

@bnoordhuis bnoordhuis commented on an outdated diff Mar 16, 2014

test/cpp/fromv8string.cpp
@@ -17,9 +26,16 @@
char *s = NanFromV8String(args[0], enc, &bc, NULL, 0, flags);
if (enc == Nan::UCS2) {
- NanReturnValue(v8::String::New(reinterpret_cast<uint16_t *>(s), flags & v8::String::NO_NULL_TERMINATION ? bc / 2 : - 1));
+ NanReturnValue(
+ v8::String::New(
+ reinterpret_cast<uint16_t *>(s)
+ , flags & v8::String::NO_NULL_TERMINATION ? bc / 2 : - 1
@bnoordhuis

bnoordhuis Mar 16, 2014

Member

s/- 1/-1/

As a suggestion for future improvement of the test, maybe add an CHECK(bc & 1 == 0) to check that the result is a multiple of two.

@bnoordhuis bnoordhuis commented on an outdated diff Mar 16, 2014

test/cpp/weak.cpp
+
+
+NAN_WEAK_CALLBACK(weakCallback) {
+ NanMakeWeak(data.GetParameter()->handle, data.GetParameter(), weakCallback);
+}
+
+v8::Handle<v8::String> wrap() {
+ NanScope();
+ v8::Local<v8::String> lstring = v8::String::New("result");
+
+ int *parameter = new int(3);
+ CallbackInfo<v8::String, int> *cbinfo =
+ new CallbackInfo<v8::String, int>(lstring, parameter);
+ NanMakeWeak(cbinfo->handle, cbinfo, weakCallback);
+ return lstring;
+}
@bnoordhuis

bnoordhuis Mar 16, 2014

Member

Indent errors. The code above uses four spaces, not two.

This was referenced Mar 16, 2014

Collaborator

kkoopa commented Mar 16, 2014

Removed:

  • NanInitPersistent
  • NanPersistentToLocal
  • NanFromV8String
  • NanMakeWeak
  • NanNewLocal
  • NAN_WEAK_CALLBACK_OBJECT
  • NAN_WEAK_CALLBACK_DATA

Introduced:

  • NanEscapableScope
  • NanEscapeScope
  • NanMakeWeakPersistent callback argument must be specialized to work on both old and new node
  • NanNew
  • NanGetCurrentContext
  • NanAdjustExternalMemory
  • NanAddGCEpilogueCallback
  • NanAddGCPrologueCallback
  • NanGetHeapStatistics
  • NanRemoveGCEpilogueCallback
  • NanRemoveGCPrologueCallback
  • NanSetTemplate
  • NanCompileScript
  • NanRunScript
  • NanMakeCallback
  • NanUndefined
  • NanNull
  • NanTrue
  • NanFalse

Modified:

  • NanSymbol now does NanNew<v8::String>(value) on new Node. (What's the new, experimental Symbol class in v8 for? v8::String::NewSymbol() is gone.)
  • NAN_WEAK_CALLBACK now has an argument called data with access to the callback object and data, as well as methods for renewing or disposing the weak callback
  • NanAssignPersistent may have been leaking persistent handles in old versions of Node
  • type arguments are gone from everywhere
  • NAN_INLINE no longer takes arguments
  • NAN_DEPRECATED no longer takes arguments
Collaborator

kkoopa commented Mar 17, 2014

Is there any point maintaining NanPersistentToLocal when NanNew could handle it?
What about doing a #define $ NanNew?

Owner

rvagg commented Mar 26, 2014

This is broken on 0.8.x btw, fine on 0.10.x and master but none of the 0.8's pass.

  CXX(target) Release/obj.target/asyncworker/cpp/asyncworker.o
In file included from ../cpp/asyncworker.cpp:11:0:
../../nan.h: In function 'v8::Local<v8::Object> NanNewBufferHandle(const char*, uint32_t)':
../../nan.h:1140:59: error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
In file included from ../../nan.h:135:0,
                 from ../cpp/asyncworker.cpp:11:
/usr/src/node/src/node_buffer.h:101:18: error:   initializing argument 1 of 'static node::Buffer* node::Buffer::New(char*, size_t)' [-fpermissive]
make: make: Leaving directory `/dnt/test/build'
*** [Release/obj.target/asyncworker/cpp/asyncworker.o] Error 1

considering we've had calls for 0.6 compatibility (which I believe we've largely had), this would upset people if we released like this.

Member

bnoordhuis commented Mar 26, 2014

That's because of nodejs/node-v0.x-archive@7ab4a77. It should be alright to do a const_cast<char*>(...) here; Buffer::New() in v0.8 is conceptually const, just not in its argument list. :-)

Collaborator

kkoopa commented Mar 26, 2014

So it needs patching for ancient versions. Question then is whether to keep NanNewBufferHandle or create yet another overload of NanNew. NanNewContext could also be integrated into NanNew and dropped.

Collaborator

kkoopa commented Mar 26, 2014

I have not tested, but I guess it should work on 0.8 now.

Owner

rvagg commented Mar 27, 2014

👍 thanks!

rvagg@tweedy (0.9-wip) ~/git/nan$ sudo dnt
Node@v0.10.26: PASS wrote output to /tmp/nan-dnt-v0.10.26.out
Node@v0.10.25: PASS wrote output to /tmp/nan-dnt-v0.10.25.out
Node@v0.10.24: PASS wrote output to /tmp/nan-dnt-v0.10.24.out
Node@master  : PASS wrote output to /tmp/nan-dnt-master.out
Node@v0.10.23: PASS wrote output to /tmp/nan-dnt-v0.10.23.out
Node@v0.10.22: PASS wrote output to /tmp/nan-dnt-v0.10.22.out
Node@v0.10.21: PASS wrote output to /tmp/nan-dnt-v0.10.21.out
Node@v0.10.20: PASS wrote output to /tmp/nan-dnt-v0.10.20.out
Node@v0.10.19: PASS wrote output to /tmp/nan-dnt-v0.10.19.out
Node@v0.10.18: PASS wrote output to /tmp/nan-dnt-v0.10.18.out
Node@v0.8.26 : PASS wrote output to /tmp/nan-dnt-v0.8.26.out
Node@v0.8.25 : PASS wrote output to /tmp/nan-dnt-v0.8.25.out
Node@v0.8.24 : PASS wrote output to /tmp/nan-dnt-v0.8.24.out
Node@v0.8.23 : PASS wrote output to /tmp/nan-dnt-v0.8.23.out
Node@v0.8.22 : PASS wrote output to /tmp/nan-dnt-v0.8.22.out
Took 36s to run 15 versions of Node
Owner

rvagg commented Apr 13, 2014

Still passing on Node master, is anyone aware of issues with this branch against master? We should prepare for a release soon, I'll probe the core guys about the promised 0.11.13.

In the meantime, anything new that's been added or changed, please update the parts of the docs you're responsible, also filling out some dot points in the Changelog at the top of nan.h would save me some time at release digging through the git log to come up with one myself.

Owner

rvagg commented Apr 13, 2014

Upgraded LevelDOWN to this branch, kind of epic but it's working on 0.10 and master now. The actual commit is here. I have a failing test involving a buffer but I'm leaning towards an error on my end rather than NAN or Node master.

I'm loving the new NanNew() stuff, fantastic work on that @kkoopa! Unfortunately there's going to be a lot of pain out there for people to catch up to NAN changes and also the major V8 changes.. Might need a more detailed write-up than normal.

Collaborator

kkoopa commented Apr 14, 2014

There's no support for making v8::Scripts yet. This was changed in the latest v8 upgrade. Don't know what else has changed.

Member

bnoordhuis commented Apr 14, 2014

That's the only major change between 3.24 and 3.25, everything else is either small fix-ups or new functionality but not anything that should affect nan.

Collaborator

TooTallNate commented Apr 14, 2014

Removed:
NanInitPersistent
NanPersistentToLocal
NanFromV8String
NanMakeWeak
NanNewLocal
NAN_WEAK_CALLBACK_OBJECT
NAN_WEAK_CALLBACK_DATA

So, are we actually breaking API here, or just deprecating? Breaking the API should be reserved for a v1.0.0 release IMO, otherwise, any packages out there that have i.e. "nan": "0" would break once this is released.

Collaborator

kkoopa commented Apr 14, 2014

I don't think many packages have it added that way. Those who use NAN use it to support 0.12 (and 0.11 inbetween), everybody should want to run the latest working 0.11 release, as it is an unstable target. In order to support Node 0.11.13 and on, there will have to be rewriting any way, so this means that all packages using nan will need changing. Even if we did not break NAN, there would still have to be rewriting for everything, due to the v8 changes.

Oh yeah, while many items could be retained as deprecated, the weak API can't be unbroken, so anything using that will break no matter what.

I guess we could declare it 1.0, but up until now the promise has been that builds are stable within a minor version, so doing "nan" : "0" would not have been correct for that behavior, it should always have been "nan" : "~0.8".

Owner

rvagg commented Apr 14, 2014

Yeah, we should probably start following correct semver now because of the ^ change in npm. 1.0.0 will be fine for this release, there's lots of breakage.

Member

bnoordhuis commented Apr 14, 2014

I don't have an opinion on what the version number should be, just wanted to point out that ^ works like ~ when the major version is < 0.

(I have opinions on npm trying to shove semver down everyone's throat but that's besides the point. Suffice it to say that none of my modules will ever see a 1.0.0 release.)

Collaborator

kkoopa commented Apr 16, 2014

I think this should be fairly feature-complete now, there could still be some polishing. Maybe NanNull() et al should return Locals and not Handles, I've made all others return Locals. Then there is the Buffer and Context constructors which I would like to get into NanNew, but they are a little problematic to fit. All those overloads of NanNew might also need some oversight, perhaps they could be better structured somehow, or generated via macros. NanNew still does not support everything you might think it should, like Dates. These extra overloads are however not strictly necessary, just nice additions to make things unified.

Owner

rvagg commented Apr 16, 2014

Agreed on pushing things through NanNew, makes the API easier to deal with if you don't have to look up what to use each time you want to do something new.

Contributor

Rush commented Apr 17, 2014

You guys certainly been busy. I have managed to compile the addon for 0.11.13-pre but it seems 0.10 is completely broken now:

n file included from ../include/x509.h:7:0,
                 from ../src/addon.cc:5:
../node_modules/nan/nan.h: In function ‘v8::Local<v8::Script> NanNew(v8::Local<v8::String>, const v8::ScriptOrigin&)’:
../node_modules/nan/nan.h:895:37: error: no matching function for call to ‘v8::Script::New(v8::Local<v8::String>&, const v8::ScriptOrigin&)’
     return v8::Script::New(s, origin);
                                     ^
../node_modules/nan/nan.h:895:37: note: candidates are:
In file included from /home/rush/.node-gyp/0.10.18/src/node.h:62:0,
                 from ../include/addon.h:4,
                 from ../src/addon.cc:4:
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:615:24: note: static v8::Local<v8::Script> v8::Script::New(v8::Handle<v8::String>, v8::ScriptOrigin*, v8::ScriptData*, v8::Handle<v8::String>)
   static Local<Script> New(Handle<String> source,
                        ^
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:615:24: note:   no known conversion for argument 2 from ‘const v8::ScriptOrigin’ to ‘v8::ScriptOrigin*’
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:630:24: note: static v8::Local<v8::Script> v8::Script::New(v8::Handle<v8::String>, v8::Handle<v8::Value>)
   static Local<Script> New(Handle<String> source,
                        ^
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:630:24: note:   no known conversion for argument 2 from ‘const v8::ScriptOrigin’ to ‘v8::Handle<v8::Value>’
In file included from ../include/x509.h:7:0,
                 from ../src/addon.cc:5:
../node_modules/nan/nan.h: At global scope:
../node_modules/nan/nan.h:904:40: error: redefinition of ‘template<class T> v8::Local<v8::Script> NanNew(v8::Local<v8::String>, const v8::ScriptOrigin&)’
   NAN_INLINE v8::Local<NanBoundScript> NanNew(
                                        ^
../node_modules/nan/nan.h:891:42: error: ‘template<class T> v8::Local<v8::Script> NanNew(v8::Local<v8::String>, const v8::ScriptOrigin&)’ previously declared here
   NAN_INLINE v8::Local<NanUnboundScript> NanNew(
                                          ^
../node_modules/nan/nan.h: In function ‘v8::Local<v8::Script> NanNew(v8::Local<v8::String>, const v8::ScriptOrigin&)’:
../node_modules/nan/nan.h:908:41: error: no matching function for call to ‘v8::Script::Compile(v8::Local<v8::String>&, const v8::ScriptOrigin&)’
     return v8::Script::Compile(s, origin);
                                         ^
../node_modules/nan/nan.h:908:41: note: candidates are:
In file included from /home/rush/.node-gyp/0.10.18/src/node.h:62:0,
                 from ../include/addon.h:4,
                 from ../src/addon.cc:4:
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:649:24: note: static v8::Local<v8::Script> v8::Script::Compile(v8::Handle<v8::String>, v8::ScriptOrigin*, v8::ScriptData*, v8::Handle<v8::String>)
   static Local<Script> Compile(Handle<String> source,
                        ^
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:649:24: note:   no known conversion for argument 2 from ‘const v8::ScriptOrigin’ to ‘v8::ScriptOrigin*’
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:667:24: note: static v8::Local<v8::Script> v8::Script::Compile(v8::Handle<v8::String>, v8::Handle<v8::Value>, v8::Handle<v8::String>)
   static Local<Script> Compile(Handle<String> source,
                        ^
/home/rush/.node-gyp/0.10.18/deps/v8/include/v8.h:667:24: note:   no known conversion for argument 2 from ‘const v8::ScriptOrigin’ to ‘v8::Handle<v8::Value>’
In file included from ../include/x509.h:7:0,
                 from ../src/addon.cc:5:
../node_modules/nan/nan.h: At global scope:
../node_modules/nan/nan.h:912:40: error: redefinition of ‘v8::Local<T> NanNew(P) [with T = v8::Script; P = v8::Local<v8::String>]’
   NAN_INLINE v8::Local<NanBoundScript> NanNew(v8::Local<v8::String> s) {
                                        ^
../node_modules/nan/nan.h:899:42: error: ‘v8::Local<T> NanNew(P) [with T = v8::Script; P = v8::Local<v8::String>]’ previously declared here
   NAN_INLINE v8::Local<NanUnboundScript> NanNew(v8::Local<v8::String> s) {
Owner

rvagg commented Apr 17, 2014

probably due to a change introduced yesterday on that branch of NAN, it'll be sorted out before a proper release and we won't go live with a git dependency here either

Owner

rvagg commented Apr 17, 2014

sorry, I thought this was a leveldown thread! ooops. I'm sure @kkoopa will be on to this soon and have it sorted.

Contributor

Rush commented Apr 17, 2014

Hopefully there will be an end to the changes in v8 at some point and broken official node releases. It is pretty tedious to fix stuff for such moving target. :)

Contributor

Rush commented Apr 17, 2014

Now I have problem because I have ported node-x509 to 0.11.13 through this pull request but as soon as as the control flow returns from native addon to node, the node process terminates abruptly without any error or segault. It simply exits. Now I cannot check if it works with other versions but if you have similar issues then please advise.

Owner

rvagg commented Apr 17, 2014

@rushpl have a look for references that may be garbage collected. The GC behaviour all through 0.11 has been quite different. If you don't hold on to a Persistent to something that you need later on then you can get this behaviour. A callback is the most likely candidate, it gets cleaned up and the call never gets propagated up into the JS layer even though it might be made in the C++ layer.

Contributor

Rush commented Apr 17, 2014

Thanks for the tip but I have just found the culprit. I had this piece of code (I am not original author :P)

Handle<Value> parse_date(const char *date) {
   NanScope();
   // (...)
   return (NanGetCurrentContext()->Global()->Get(NanNew<String>("Date"))->ToObject()->CallAsConstructor(1, args));
}

So basically the scope was not closed properly and this resulted in node simply quitting ... is this a bug in node? Could it be protected against? I do not see why NanScope could not be closed automatically via some scoped variable.

Collaborator

kkoopa commented Apr 17, 2014

That script thing is due to something I broke yesterday when I tried exposing both bound and unbound script API through NanNew. I think I have to rewrite NanNew without using generic templates to ensure that things do not collide. The current solution was good in the beginning, but has grown more and more complex and now it seems like restructuring it in the explicit way actually will lead to less complexity.

The scope thing is due to stricter rules in v8. Whenever a handle gets returned from a function with a scope, the scope has to be escaped. New v8 has two kinds of scopes, escapable scopes and non-escapable scopes. That code now has to be:

Handle<Value> parse_date(const char *date) {
   NanEscapableScope();
   // (...)
   return NanEscapeScope((NanGetCurrentContext()->Global()->Get(NanNew<String>("Date"))->ToObject()->CallAsConstructor(1, args)));
}

It is not a bug in v8, node or nan.

Contributor

Rush commented Apr 17, 2014

Well .. I kind of see it as a bug because nowhere in the code there was process.exit() and the code was working as though there was.

Collaborator

kkoopa commented Apr 17, 2014

I think the behavior is undefined in this case. Rod got a double free error, because a check on Buffer::HasInstance incorrectly returned true on a handle that had not been properly passed back. v8 Handles are wrapped pointers, so I guess you could see it as returning a handle without escaping the surrounding scope is similar to returning a pointer to uninitialized memory in that anything can happen.

Collaborator

kkoopa commented Apr 17, 2014

I pushed a commit that comments out the script parts so things will compile. NanNew must be restructured, then it can be re-added among with NanNew<Buffer> and NanNew<Context>, removing corresponding existing constructors.

Member

bnoordhuis commented Apr 17, 2014

Well .. I kind of see it as a bug because nowhere in the code there was process.exit() and the code was working as though there was.

If you test with a debug build of node.js (make -C out BUILDTYPE=Debug), then you'll probably get an assert.

Collaborator

kkoopa commented Apr 17, 2014

NanNew<Script> runs into problems for old versions of node as both NanBoundScript and NanUnboundScript are defined as v8::Script. Compiler can't distinguish the two constructors as they have identical signatures. Don't see any way of fixing that... It might be impossible not to have them as separate functions with both the bound and unbound api exposed.

Collaborator

kkoopa commented Apr 17, 2014

Broke out the bound script API to a separate function. Now everything should work again.
I don't think buffer construction can be cleanly integrated, seeing as how it returns a v8::Object. It would be somewhat confusing to do NanNew<node::Buffer> and get a v8::Object in return. NanNewContext is hardly ever going to be used and can be left as well.

Collaborator

kkoopa commented May 2, 2014

Node v0.11.13 has been tagged for release: https://github.com/joyent/node/tree/v0.11.13-release

It seems possible to build native addons again and all tests pass:

kkoopa@ubuntu:~/dev/nan/test$ node -v
v0.11.13
kkoopa@ubuntu:~/dev/nan/test$ npm test --nodedir=/home/kkoopa/dev/node

> nan-tests@0.0.0 test /home/kkoopa/dev/nan/test
> node-gyp rebuild && tap --gc js/*-test.js

make: Entering directory `/home/kkoopa/dev/nan/test/build'
  CXX(target) Release/obj.target/asyncworker/cpp/asyncworker.o
  SOLINK_MODULE(target) Release/obj.target/asyncworker.node
  SOLINK_MODULE(target) Release/obj.target/asyncworker.node: Finished
  COPY Release/asyncworker.node
  CXX(target) Release/obj.target/bufferworkerpersistent/cpp/bufferworkerpersistent.o
  SOLINK_MODULE(target) Release/obj.target/bufferworkerpersistent.node
  SOLINK_MODULE(target) Release/obj.target/bufferworkerpersistent.node: Finished
  COPY Release/bufferworkerpersistent.node
  CXX(target) Release/obj.target/multifile/cpp/multifile1.o
  CXX(target) Release/obj.target/multifile/cpp/multifile2.o
  SOLINK_MODULE(target) Release/obj.target/multifile.node
  SOLINK_MODULE(target) Release/obj.target/multifile.node: Finished
  COPY Release/multifile.node
  CXX(target) Release/obj.target/news/cpp/news.o
  SOLINK_MODULE(target) Release/obj.target/news.node
  SOLINK_MODULE(target) Release/obj.target/news.node: Finished
  COPY Release/news.node
  CXX(target) Release/obj.target/optionvalues/cpp/optionvalues.o
  SOLINK_MODULE(target) Release/obj.target/optionvalues.node
  SOLINK_MODULE(target) Release/obj.target/optionvalues.node: Finished
  COPY Release/optionvalues.node
  CXX(target) Release/obj.target/persistent/cpp/persistent.o
  SOLINK_MODULE(target) Release/obj.target/persistent.node
  SOLINK_MODULE(target) Release/obj.target/persistent.node: Finished
  COPY Release/persistent.node
  CXX(target) Release/obj.target/returnemptystring/cpp/returnemptystring.o
  SOLINK_MODULE(target) Release/obj.target/returnemptystring.node
  SOLINK_MODULE(target) Release/obj.target/returnemptystring.node: Finished
  COPY Release/returnemptystring.node
  CXX(target) Release/obj.target/returnnull/cpp/returnnull.o
  SOLINK_MODULE(target) Release/obj.target/returnnull.node
  SOLINK_MODULE(target) Release/obj.target/returnnull.node: Finished
  COPY Release/returnnull.node
  CXX(target) Release/obj.target/returnundefined/cpp/returnundefined.o
  SOLINK_MODULE(target) Release/obj.target/returnundefined.node
  SOLINK_MODULE(target) Release/obj.target/returnundefined.node: Finished
  COPY Release/returnundefined.node
  CXX(target) Release/obj.target/returnvalue/cpp/returnvalue.o
  SOLINK_MODULE(target) Release/obj.target/returnvalue.node
  SOLINK_MODULE(target) Release/obj.target/returnvalue.node: Finished
  COPY Release/returnvalue.node
  CXX(target) Release/obj.target/settergetter/cpp/settergetter.o
  SOLINK_MODULE(target) Release/obj.target/settergetter.node
  SOLINK_MODULE(target) Release/obj.target/settergetter.node: Finished
  COPY Release/settergetter.node
  CXX(target) Release/obj.target/strings/cpp/strings.o
  SOLINK_MODULE(target) Release/obj.target/strings.node
  SOLINK_MODULE(target) Release/obj.target/strings.node: Finished
  COPY Release/strings.node
  CXX(target) Release/obj.target/symbols/cpp/symbols.o
  SOLINK_MODULE(target) Release/obj.target/symbols.node
  SOLINK_MODULE(target) Release/obj.target/symbols.node: Finished
  COPY Release/symbols.node
  CXX(target) Release/obj.target/weak/cpp/weak.o
  SOLINK_MODULE(target) Release/obj.target/weak.node
  SOLINK_MODULE(target) Release/obj.target/weak.node: Finished
  COPY Release/weak.node
make: Leaving directory `/home/kkoopa/dev/nan/test/build'
ok js/asyncworker-test.js ............................... 3/3
ok js/multifile-test.js ................................. 3/3
ok js/news-test.js .................................... 49/49
ok js/optionvalues-test.js .............................. 3/3
ok js/persistent-test.js .............................. 10/10
ok js/returnemptystring-test.js ......................... 4/4
ok js/returnnull-test.js ................................ 4/4
ok js/returnundefined-test.js ........................... 4/4
ok js/returnvalue-test.js ............................... 4/4
ok js/settergetter-test.js .............................. 5/5
ok js/strings-test.js ................................. 24/24
ok js/symbols-test.js ................................... 3/3
ok js/weak-test.js ...................................... 4/4
total ............................................... 120/120

ok
Owner

rvagg commented May 2, 2014

Time for a release, 0.11.13 is now properly out. We just need doc cleanup, changelog and some basic notes at the top of the readme about what we've done. If anyone wants to help with any of this please do so, otherwise I'll try and get to it tomorrow (just heading to bed now, I have a bit of travel to do tomorrow too).

Excited for this release, we may as well do 1.0.0, so much excellent work in here from everyone!

Owner

rvagg commented May 4, 2014

I've just done the changelog in nan.h, please have a quick look and let me know if I've missed anything or if you want to expand on anything (actually, just change it yourself asap). I'm just going to do a quick note on the README and mention some of the major changes that will impact most people -- NanNew, NanEscapableScope, the NanAssignPersistent sig change, NanDisposePersistent, NanMakeCallback. Once I've written that up I'll bump to 1.0.0 and release. I'll follow up with a leveldown release and a node-bignum release. After that I guess we should all go around and update the various projects we contribute this stuff to.

kkoopa and others added some commits Mar 14, 2014

@rvagg rvagg merged commit 4614e7f into master May 4, 2014

Owner

rvagg commented May 4, 2014

merged and 1.0.0 released

@rvagg rvagg deleted the 0.9-wip branch May 4, 2014

Collaborator

kkoopa commented May 4, 2014

LGTM But I wonder how tests pass down to 0.11.10, were there constructors with isolates already then?

Rod Vagg notifications@github.com wrote:

I've just done the changelog in nan.h, please have a quick look and let me know if I've missed anything or if you want to expand on anything (actually, just change it yourself asap). I'm just going to do a quick note on the README and mention some of the major changes that will impact most people -- NanNew, NanEscapableScope, the NanAssignPersistent sig change, NanDisposePersistent, NanMakeCallback. Once I've written that up I'll bump to 1.0.0 and release. I'll follow up with a leveldown release and a node-bignum release. After that I guess we should all go around and update the various projects we contribute this stuff to.


Reply to this email directly or view it on GitHub.

Owner

rvagg commented May 4, 2014

my guess is that our test suite is too incomplete to pick up incompatibilities! yes, about 1/2 of the constructors had isolates, now it's pervasive

It's May 2014 :)

Owner

rvagg replied May 5, 2014

thanks for picking that up! fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment