Promise.all() does not seem to work

[espruino-discuss]

Posted at 2016-12-07 by Drarok

The following code demonstrates that Promise.all() never resolves:

var p1 = Promise.resolve(1).then(function () {
  console.log('p1');
});
var p2 = Promise.resolve(2).then(function () {
  console.log('p2');
});

var all = Promise.all([p1, p2]).then(function () {
  console.log('done');
}).catch(function () {
  console.log('FAIL');
});

console.log('Promise test');

The output is:

p1
p2
> Promise test
=undefined

[espruino-discuss]

Posted at 2016-12-08 by @MaBecker

@Drarok - which Espruino version are you running ?

your code works fine on puck.js with 1v89.

   _____                  _
|   __|___ ___ ___ _ _|_|___ ___
|   __|_ -| . |  _| | | |   | . |
|_____|___|  _|_| |___|_|_|_|___|
              |_| http://espruino.com
 1v89 Copyright 2016 G.Williams
>Promise test
p1
p2
done
> 

[gfwilliams]

Posted at 2016-12-08 by @gfwilliams

There was another post on this - I think even 1v89 has some issues, but they are fixed on the absolute latest builds from GitHub, and will be in 1v90.

[espruino-discuss]

Posted at 2016-12-08 by Drarok

Huh, weird. I updated both my Pucks to the latest available (1v89 – I just checked my downloads folder).

@MaBecker: interesting that your log messages are in a different order, too!

[espruino-discuss]

Posted at 2016-12-08 by @MaBecker

javascript is asynchrone ;-)

used "Send to Espruino" in the WebIDE to test your code .....

[gfwilliams]

Posted at 2016-12-08 by @gfwilliams

You get the latest numbered build, like 1v89, but then you get builds from GitHub - which have the fixes in as I make them. Currently there aren't automatic Puck.js builds though.

I think the problem is that when you enter code in the root scope, it's executed statement by statement.

Promise 1 is executed and resolves, as does Promise 2, then you call Promise.all.

In 1v89, Promise.all sits there waiting for the 2 promises to complete (when they have already completed) - in later versions I check to see if they have previously executed, and if so execute the .all immediately.

In 1v89, just wrapping it in a function would probably make it work:

function go() {
var p1 = Promise.resolve(1).then(function () {
  console.log('p1');
});
var p2 = Promise.resolve(2).then(function () {
  console.log('p2');
});
var all = Promise.all([p1, p2]).then(function () {
  console.log('done');
}).catch(function () {
  console.log('FAIL');
});
console.log('Promise test');
}
go();

[espruino-discuss]

Posted at 2016-12-08 by Drarok

Interesting! You're right that wrapping into a function works, thanks!

This works:

function go() {
  var p1 = new Promise(function (res, rej) {
    setTimeout(() => res(1), 250);
  });

  var p2 = new Promise(function (res, rej) {
    setTimeout(() => res(2), 300);
  });

  Promise.all([p1, p2]).then(function () {
    console.log('done', arguments);
  }).catch(function () {
    console.log('FAIL');
  });

  console.log('Promise test');
}

go();

Output:

Promise test
=undefined
done [
  [ 1, 2 ]
 ]

But attempting to use ES6 arrow functions as the Promise executor causes the Puck to completely stop responding and require a powercycle before I can interact with it?

function go() {
var p1 = new Promise((res, rej) => {
    setTimeout(() => res(1), 250);
  });

  var p2 = new Promise((res, rej) => {
    setTimeout(() => res(2), 300);
  });

  Promise.all([p1, p2]).then(function () {
    console.log('done', arguments);
  }).catch(function () {
    console.log('FAIL');
  });

  console.log('Promise test');
}

go();

There's no output after the Espruino logo and version text, the console on the left stops working (can't type any text), and attempting to upload code seems to work, but doesn't execute.
I can disconnect and attempt to reconnect via BLE, which hangs at "Connecting..." – super weird!

[espruino-discuss]

Posted at 2016-12-08 by Drarok

Oh, and another weird one with arrow functions: they don't seem to be passed values if defined with parentheses:

function go() {
  var p1 = new Promise(function (res, rej) {
    setTimeout(() => res(1), 250);
  });

  p1.then(x => {
    console.log('Bare arrow:', x);
  });

  p1.then((x) => {
    console.log('Parentheses arrow:', x);
  });

  p1.then(function (x) {
    console.log('Regular:', x);
  });
}

Output:

Bare arrow: 1
Parentheses arrow: undefined
Regular: 1

[espruino-discuss]

Posted at 2016-12-08 by Drarok

This one causes the Puck to immediately crash and disconnect from BLE!

function go() {
  var users = [
    { name: "Bob" },
    { name: "Alice" },
    { name: "Eva" }
  ];

  console.log(users.map((u, i) => u.name));
}

It seems as follows:

u => u.name works perfectly
(u) => u.name isn't correctly passed its arguments (?)
(u, i) => u.name crashes the device

[gfwilliams]

Posted at 2016-12-08 by @gfwilliams

Thanks - that's another one that should also be fixed in the latest builds (not 1v89, but 1v90 when it comes out or the ones from GitHub).

Arrow functions, promises and template literals are still pretty new additions to the Espruino interpreter, so there's been a bit of tweaking needed to get them working reliably.

[espruino-discuss]

Posted at 2016-12-12 by Drarok

Amazing, thanks again!

I had a quick look but there don't appear to be docs specifically for building for the Puck, are there any special steps required? If I get it wrong, am I likely to brick my puck(s)?

If it's risky, I'm happy to wait for the next release – is there a release schedule, or just as and when there's enough fixes and features to warrant a new one?

[gfwilliams]

Posted at 2016-12-13 by @gfwilliams

You'd need to follow the nRF52 instructions for building: https://github.com/espruino/Espruino/blob/master/README_Building.md#for-nordic-semiconductors-nrf51nrf52-series-devices

But while not dangerous it's a bit of a faff to get it creating an image that you can then upload via the nordic app. It's probably easiest if I extend the auto-build system to include the Puck, and then you should be able to get up to date builds much more easily.

There isn't a fixed schedule, no... as you say it's just when there's enough stuff to warrant it. Generally if something is crashing or has regressed it gets priority.