It seems that this may be because blinkstick does not work with Node v0.12?
Also I noticed the usb module used by blinkstick is an older version, not sure if that’s a problem though.
I’ve got it working on Node v0.10 using a stand-alone blinkstick (not the npm install one).
Thanks for this. I managed to reproduce it, but my development system was behind and on Node 0.10.26. I’ll update to the latest and apply the required fixes to support Node 0.12.
Sorry about the inconvenience, will let you know when it’s done.
This should now be sorted. I’ve pushed a new BlinkStick Node.js module release to address this issue. Thanks for reporting!
Alas: I can now install it, but not run it.
H:\dev\node\test>node -v
v0.12.0
H:\dev\node\test>npm -v
2.5.1
H:\dev\node\test>npm install blinkstick
npm WARN optional dep failed, continuing usb-shyp-darwin-x64@1.0.4
> usb@1.0.4 install H:\dev\node\test\node_modules\blinkstick\node_modules\usb
> node shyp-blacklist.js win32-x64 win32-ia32 darwin-x64 || node-gyp rebuild
blinkstick@1.1.1 node_modules\blinkstick
+-- usb@1.0.4 (bindings-shyp@0.2.3, nan@1.6.2, usb-shyp-win32-ia32@1.0.4, usb-shyp-win32-x64@1.0.4)
H:\dev\node\test>type test.js
require('blinkstick')
H:\dev\node\test>node test.js
module.js:355
Module._extensions[extension](this, filename);
^
Error: The specified procedure could not be found.
H:\dev\node\test\node_modules\blinkstick\platform\windows\HID.node
at Error (native)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> (H:\dev\node\test\node_modules\blinkstick\blinkstick.js:11:11)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
H:\dev\node\test>Also, that was using the x86 version of nodejs. Using the x64 version, the HID.node will not load at all, as it is compiled for x86.
H:\dev\node\test>node test.js
module.js:355
Module._extensions[extension](this, filename);
^
Error: %1 is not a valid Win32 application.
H:\dev\node\test\node_modules\blinkstick\platform\windows\HID.node
at Error (native)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
at Module.require (module.js:365:17)
at require (module.js:384:17)
at Object.<anonymous> (H:\dev\node\test\node_modules\blinkstick\blinkstick.js:11:11)
at Module._compile (module.js:460:26)
at Object.Module._extensions..js (module.js:478:10)
at Module.load (module.js:355:32)
at Function.Module._load (module.js:310:12)
H:\dev\node\test>Not sure if I’ll be able to support 64 bit version of Node.js. Booting a VM with Windows 8 to check if I can reproduce your issue.
I can confirm that there is an issue with the precompiled HID module on Windows 8. Looking for a way to fix this.
Is HID.node a build of node-hid? If so, did you make any changes to it to get it to work with blinkstick?
I’d like to know so I can have a go at compiling HID.node myself. I think I make it work on both x86 and x64 by compiling two versions of HID.node and having the script decide which one to load, or having it attempt to load both and use whichever works - I’m doning a similar thing for an addon I’m working on.
Seems that I may not be able to support 64 bit version of Node.js, but I think I have a fix for 32 bit version. I haven’t released to npm yet and it’s only available in the repository. Would you be able to test this for me if it works on your system please? Here are the steps:
Please let me know if it works for you and BlinkStick starts blinking.
Yes, it works on v0.12 x86 now, thank you!
Great! Thanks for testing this. I’ll release a new version of package tomorrow after I complete the tests with earlier versions of Node.js. For now please use the version from Github and I’ll notify about the new release.
Thanks, will do.
I just compiled my own addon for x86 and x64 on v0.10 and v0.12. I’ve thus created four version of the .node file and put them in a tree such that I have ia32/0.10/name.node, ia32/0.12/name.node, x64/0.10/name.node, and x64/0.12/name.node. Then I use an index.js to load the correct binary like so:
var sArchitecture = process.arch;
var sVersion = process.versions.node.match(/^(\d+\.\d+)\.\d+$/)[1];
module.exports = require("./bin/" + sArchitecture + "/" + sVersion + "/" + sModuleName);
I’m assuming HID.node is a build of node-hid? I ask because I can build that for v0.10 x64 myself. However, I can’t build it for v0.12 at all - they don’t seem to use Nan. You appear to have “patched” yours, care to share how you got it working?
This is actually an ideal solution to load all required version of HID module. I want to provide precompiled HID modules for BlinkStick package, because it’s such a pain to set up a build environment on Windows in order to use gyp based installation for node-hid. It’s not the case on Linux or OSX.
It is in fact node-hid which I have forked. My patches have been applied from another repository which claims to be incomplete, but seem to be working on my platform. However I didn’t manage to build them for the 64bit version of Node.js on Windows with the patches applied. Might be something missing and I would need to investigate this further. The forked repository and applied patches are on develop branch available here:
The breaking changes in Node.js API occurred in 0.11.13. You can see this check in my code to cover the case. However I would be very interested to cover all platforms and versions of Node.js like you did. Currently my solution only covers x86.
I’ve successfully implemented the “multi-.node loader” that I used with my own addon in both your node-hid and blinkstick code. I’ve sent pull requests for both for your consideration.
NB. This is my first time working with github, so I am not sure I did everything correctly.
PS. I had no problem building your original node-hid for x64, so I’d be interested to hear what errors you were seeing. Might it be related to your build environment, rather than the code?
Thanks for the pull request, I’ll review and come back to you. One thing that concerns me straight away is that this only works with 0.10-0.13 version of Node.js. When 0.14 is release we would be forced to recreate the files otherwise the package wouldn’t work which may not be necessary. Also I need to look if I have to support node versions 0.8 and 0.9.
You are right. I will create a fall-back mechanism where a previous version is automatically selected if the desired version is not available. I will do another pull when it’s ready.
It seems I do not have to create a new pull request, but my previous one is automatically updated to include the changes I suggested.
I’ve updated the code to attempt to load all available versions of the “.node” file for the user’s processor architecture. The first one to successfully load will be used. This has the added benefit of allowing me to remove the 0.12 version of the code as the 0.11 version works just fine in 0.12. It also means that unless there are new changes to the addon format, you do not need to build any new “.node” files for future version of node.js.
You can test if the 0.10 version works in 0.8 and 0.9, if it does not, you can simply add 0.8 to the list in build-targets.txt and run install.cmd to create additional “.node” files. Then test if they work in 0.9 and if not, add that to the list too, etc.
EDIT: I’ve tested it and the 0.10 version will not work in 0.8 or 0.9, so I added 0.8.9 and 0.9.9 to the build-targets.txt file. I was unable to build the 0.9.9 version because of an error:
HID.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) class v8::Handle<class v8::Value> __cdecl node::MakeCallback(class v8::Handle<class v8::Object>,class v8::Handle<class v8::Function>,int,class v8::Handle<class v8::Value> * const)" (__imp_?MakeCallback@node@@YA?AV?$Handle@VValue@v8@@@v8@@V?$Handle@VObject@v8@@@3@V?$Handle@VFunction@v8@@@3@HQAV23@@Z) [H:\dev\node\node-hid\build\HID.vcxproj]
H:\dev\node\node-hid\build\Release\HID.node : fatal error LNK1120: 1 unresolved externals [H:\dev\node\node-hid\build\HID.vcxproj]
Update: I was able to build for 0.9.7, but it appears that module will not load in 0.9.8 or 0.9.9.
It starting to look like supporting all versions of node with pre-compiled binaries may be a stretch goal, but using multiple versions should definitely be an improvement from the original.
PS. To make testing different version of node.js easier, I have done a similar thing with “node.exe” files: I’ve downloaded standalone node.exe executables and saved them in a folder structure. I’ve also created a #node.cmd file which will run any script in a given version of node
+ #node.cmd
+ node/
+ ia32/
+ 0.10.36/
+ node.exe
+ 0.11.16/
+ node.exe
+ 0.12.0/
+ node.exe
+ x64/
+ 0.10.36/
+ node.exe
+ 0.11.16/
+ node.exe
+ 0.12.0/
+ node.exe
Usage:
#node.cmd [arch] [version] [script] [arguments]
Example:
#node.cmd ia32 0.10 node-hid.js
Source:
@ECHO OFF
FOR /F "usebackq" %%I IN (`dir /B "%~dp0node\%~1\%~2.*" 2^>nul ^| sort /R`) DO (
CALL :FOUND "%~dp0node\%~1\%%~I\node.exe" %*
EXIT /B 0
)
ECHO The requested version of node was not found.
EXIT /B 1
:FOUND
SET COMMAND=%1
SHIFT
SHIFT
:ADD_ARGUMENTS
SHIFT
if "%~1" == "" (
%COMMAND%
EXIT /B %ERRORLEVEL%
)
SET COMMAND=%COMMAND% %1
GOTO ADD_ARGUMENTS
I hope this helps.
I’ve done more work on my own addon and ported some of the improvements to my branches of hid-node and blinkstick-node. Please check them out.
You may be interested in pWinRunInVersion, a Node.js package I developed to replace the “#node.cmd” hack I wrote about earlier.
pWinRunInVersion allows you to run a Node.js script in any version of Node.js. It’s proven helpful during development of my own addon. I’ve used it to create a list of working targets for my own addon, I assume the same list will work for BlinkStick.
For instance, I’ve found that Nan does not support Node.js v0.11.0-v0.11.12, and that builds for previous or later versions will not load in these versions. This means that I cannot currently build for these version and would probably need to add a lot of version specific hacks to the code in order to do so, which I am not willing to do.