UnhandledPromiseRejectionWarning about klyng HOT 7 CLOSED

Thank you for reporting this.

It was a dependency issue: when I created klyng, the module I used for IPCs (node-ipc) had some bugs in it. I fixed them back then and created the pull requests but it took the maintainer so long to merge them. So to release klyng, I installed the dependency directly from my fork which contains the fixes and forgot to change back to the original repo after my fixes were merged. So when one of node-ipc dependencies changed, and the code in my fork remained still without accounting for such changes, everything broke!

Now that node-ipc is installed directly from its original repo, the issue you reported should be fixed.

Feel free to reopen the issue if the problem persists.

from klyng.

Brilliant, dude. It now works great. I think I had to do something interesting to install it...

$ mkdir ~/.npm-modules
$ echo export PATH=\~/.npm-modules/bin:\$PATH >> ~/.profile
$ source ~/.profile
$ NPM_CONFIG_PREFIX=/home/pi/.npm-modules sudo npm install -g klyng

Didn't seem to work out. So I then proceeded with...

$ sudo npm uninstall -g klyng
$ sudo bash
#   Note that we're now logged in as root and the
#   prompt has changed to root@gru:/home/pi# so
#   just copy/run everything after the prompt.
root@gru:/home/pi# NPM_CONFIG_PREFIX=/home/pi/.npm-modules npm install -g klyng
root@gru:/home/pi# exit

And that seems to work as expected. The supercomputer is now working with the Hello, Minions! JavaScript using your module. Here is that subset of the instructions.

from klyng.

What's interesting is that each remote node needs to run sudo klyng... and the master seems to get away with just running klyng.... Not sure if this is my setup or what but you might mention this to your own users in your documentation.

from klyng.

Oh... and I seem to recall that the remote nodes failed with a message that they couldn't create the .unpacks folder. I think I then manually created it for them and they were then able to proceed. Or... I chmod'd the parent folder perhaps to the user's name and group.

You might just create an empty .unpacks folder within your image and avoid the whole issue.

from klyng.

I'm glad that its working with you!

When you installed it on remote nodes, did you use the same process of creating a different global dir intead of the one in root or just used sudo npm install -g klyng? if you used the latter and didn't fire up the beacon with sudo then this problem is expected! because .unpacks then would reside under a root path!

Anyway I'm glad that the framework is being used, I've wanted to add more directives for collective communication (like gather, scatter and reduce) and wasn't really motivated to do that, perhaps I can get around and do that soon!

from klyng.

Pretty sure the install was identical throughout.

I'm giving a talk this Tuesday on "Supercomputing in JavaScript" at SanDiego.js in front of maybe a hundred people so you may get some recognition and/or traffic to your repository (possibly).

What's funny is that if I attempt to move the master's website* to run as root then I have to explicitly give the path to the klyng executable for it to be found... and then it ultimately doesn't work when submitting jobs after that. I'll have to play around with all that later--I think I'd like all the nodes to be at the same level (user versus root) simply for consistency. I'll figure it out, though.

• Note that the website does server-side to run the klyng --beacon-up, for example.

from klyng.

Was able to introduce your library to a group of 155 at the SanDiego.js meeting last night to much applause. Thanks, again.

from klyng.