promises

[parmentelat]

hi

I'm writing a course on JS using ijavascript as the jupyter kernel and I experience something odd in the section I am currently writing on promises;

what I see is this

if I run in a notebook a cell with this code

promise_ok = new Promise(
    (resolve, reject) => {
        setTimeout(
            // using resolve, we decide what the 
            // eventual result will be
            () => resolve(1000), 10000
        )
    }
)

I observe the kernel hanging for the 10s that the code is running (if I try to evaluate the next cell for example, I have to wait for 10s for the [*] sign, that says the kernel is busy, to go away)

this is not what I see in a node interpreter running in a terminal, where I immediately get back to the REPL prompt, with a promise object that I can inspect - and see it's pending - and I can compute stuff in the meanwhile before the 10s have passed (and same in the browser console)

this is a serious impediment since it's the whole point of that course on async programming, to show that the interpreter remains available for other computations

am I missing something here ? is there any known workaround ?

thanks in advance

[n-riesco]

This is actually a feature! :smiley: It helps with the creation of asynchronous cells. Unfortunately modern versions of the jupyter notebook queue execution requests at the client-side; rendering this feature useless in those clients.

I will hide this feature behind a flag and make Node.js' behaviour the default:

> p = new Promise((resolve, reject) => setTimeout(() => resolve(100), 1000))
Promise {
  <pending>,
  [Symbol(async_id_symbol)]: 322,
  [Symbol(trigger_async_id_symbol)]: 5,
  [Symbol(destroyed)]: { destroyed: false }
}
> p
Promise {
  100,
  [Symbol(async_id_symbol)]: 322,
  [Symbol(trigger_async_id_symbol)]: 5,
  [Symbol(destroyed)]: { destroyed: false }
}

[parmentelat]

thanks for the prompt answer

I can't say that I am fully getting the point of the feature that you are pointing to, since the node repl's behaviour looks just about right imho one should be able could be cut-n-pasted a cell's content as-is into node - or the browser console for that matter - and behave the same, without the need for extra boilerplate like $$.async() but I'm probably missing the point here:)

[n-riesco]

As I said, the fact that modern versions of the jupyter notebook queue execution requests on the client side has crippled this feature. In the past, it was possible to do things like #156 without display messages.

More info #164.

[parmentelat]

oh I see, I misunderstood your first answer please keep us posted then :) thanks !

[n-riesco]

@parmentelat How quickly do you need this done?

I have implemented a solution here that hides the functionality to resolve Promises behind a setting (global.$$config$$.awaitResult).

I'm not pleased with this solution (as I had deprecated all of IJavascript's global variables except $$).

I'd like to think a bit more before releasing this solution.

[n-riesco]

Note to myself (alternative solutions):

• $$.awaitResult(true|false)
• $$.config.awaitExecutionResult with $$.config backed by a variable shared by all execution contexts

[parmentelat]

@n-riesco thanks for the feedback; in terms if timing unfortunately my last course on this topic this year will take place tomorrow; it's quite alright, I'll just run the code in the browser natively, which is the main target anyway;) of course this move still makes utmost sense imho! but please do not hurry for my sake:)

[n-riesco]

@parmentelat I've just released [email protected]. If you reinstall IJavascript, it should pick up the changes. Please, let me know if it doesn't work as expected.

Next, I'm planning to add the command flag --await-execution to enable the old behaviour.

[parmentelat]

I did test this new version, and it does fix my concern 👍 Thanks much !