The old Node.js versions don't treat v8::Handle and v8::Local as
the same types, and the latest versions (v12 and newer) have
removed v8::Handle at all.
This patch introduces the following macros that use v8::Handle or
v8::Local depending on the selected Node.js version:
- SWIGV8_ARRAY
- SWIGV8_FUNCTION_TEMPLATE
- SWIGV8_OBJECT
- SWIGV8_OBJECT_TEMPLATE
- SWIGV8_VALUE
Tests for std::vector of pointers added which check
std::vector<T*>::const_reference and std::vector<T*>::reference
usage which gave compilation errors in Python and Perl which had
specialized these vectors incorrectly.
Overloading support for Javascript is generally incomplete as there are
no typecheck typemaps, so the overloading and NULL support added here
doesn't work and won't work until the typecheck typemaps are
implemented.
* js-v8-52-tests:
fixed nvm
node tests: use provided version if present
travis tests for different node versions
fix travis tests
Test NodeJS 4, 6, 8, and 10
Remove warnings on Node 6.x aka V8 5.0 and 5.1
Add Node 7.x aka V8 5.2+ support
Fixes missing type information for std::complex in scripting languages.
Closes#732.
Update Javascript and Octave complextest, although they don't actually
get run as they don't work
The proposed changes targetted at 5.2 (or 5.4 to be more precise, since there is no Node release with V8 5.2 or 5.3) work for lower versions as well and bust the deprecation warnings there.
* Use WeakCallbackInfo instead of WeakCallbackData
* Use GetPrivate instead of GetHiddenValue
* Adopted new signature for SetWeak to support destructor calling
* SetAccessor deprecation fixed
* Proper version checks where applicable
Adds preprocessor checks to avoid defining functions that use long long if it isn't available
Effects the following languages: javascript, octave, perl, python, r, ruby, tcl
JSObjectMakeError automatically populates the "message" field, and possibly other fields I don't know about. This seems to be the most robust way to create an exception object.
Thanks to Brian Barnes again for the tip on JSObjectMakeError.
It is unclear what the correct handling is for JavaScriptCore. (Nobody bothers to document this in JSCore.) Unlike our other problem where we incorrectly assume JSObjectRef when the functions want JSValueRef, this time Apple is demanding the JSObjectRef. Like our other problem, I assume it is unsafe to try to convert Undefined into a JSObjectRef.
So reverting to NULL seems like the safer bet for this specific case. Perhaps the other alternative is to return an exception object or an error object. But I would like to see JSCore document this before trying.
