Async display of contents (also AsyncSeq)

[dsyme]

Question for @cgravill, @tpetricek @sylvanc - is it technically feasible to have Async values display asynchronously in the Jupyter display? I presume Javascript would have to be injected which polls the server, and that this might be a modification of the Jupyter protocol beyond the scope of iFSharp directly?

If we could do this, I would then ask whether it's possible to have AsyncSeq values display as animated sequences, where each element updates the DOM element with replacement Javascript

[cgravill]

@tpetricek mentioned the bonus feature in #96 that you can do on-demand fetching so parts of this may now be present.

[cgravill]

@dgrechka the Jupyter Comms may be useful for this: http://jupyter-notebook.readthedocs.io/en/stable/comms.html

[dgrechka]

@cgravill Thank you! Indeed, Comms may better fit here rather than establishing separate communication channel. I'll try them.
Supporting Comms by the kernel side is also a step towards #126

[dgrechka]

I found that Jupyter protocol v5.1 supports updating of display outputs from kernel side.

Although it requires update the protocol from 4.0 to at least 5.1

Maybe that will be enough to achieve deferred results display. I'm trying it right now.

[dgrechka]

@dsyme FYI, I managed to get some working results for Async values display.

The demo link:
.

When the Async is displayed it is started as a task on a separate thread. Upon result readiness the corresponding output is updated.
The approach uses protocol's v5.1 update_display_data messages. Neither JS injection nor protocol extension is required.

Don't know whether the active async computation should mark the kernel as busy... Right now it does not.

I need some further testing and code cleanup, and then I'll create a PR.

[cgravill]

That looks like a great start. Is the plan to get Async of a single value first then see if AsyncSeq is possible afterwards?

[dgrechka]

Yes. The plan is to make several small incremental changes, delivering some value.
They are easier to review. Async of single value is the fist step.

[dsyme]

Wow, this is fantastic

[dgrechka]

Thank you!
I'm implementing AsyncSeq display right now...

[dgrechka]

The asyncSeq display prototype is ready!

The demo link:
.

Now I'm cleaning up the code and will do PR to close the issue.

[cgravill]

That's very nice!

Will this be compatible with Angara Charting as well and so we can have e.g. simulator creating results and progressively display results?

[dgrechka]

Right now it appends the output upon fetching next element from asyncSeq. What I can propose for now (in the situation of limited time) is to provide a switch which toggles the AsyncSeq display modes. The modes: 1) Replacing the recent produced element upon next element readiness 1) Appending the next produced element to the output (accumulating elements) For the use case of updating the charts, we can activate display mode (1) and produce AsyncSeq<Chart> It has disadvantage of possible chart blinking and visible region reset as the chart is entirely replaced, but this approach is more feasible to get the usable results in time. The approach also have advantages: This can be useful not only for the charts, but for outputting of some recent text statuses, e.g. recent text summary of some long running parameter inference process. It is also type agnostic in a sense that it will update any type of output (different charting libraries, custom printers supported) If such chart updates turn out to be inconvenient in practice, we can implement chart library specific data updates, maybe as separate github issue. What do you think?

…

On 7 Aug 2018, at 12:06, Colin Gravill ***@***.***> wrote: That's very nice! Will this be compatible with Angara Charting as well and so we can have e.g. simulator creating results and progressively display results? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.