Live Variable Watches about hydrogen HOT 17 CLOSED

This would be awesome. My dream development environment actually looks a lot like the Chrome Dev Tools mid-debugging, with watch expressions, lists of the values of all variables in scope, and value-on-hover for variables in your code.

Watch expressions are a great first step towards that. I'd like to implement them in a language-agnostic way.

What about a panel on the side of the editor that, after every chunk of code you send to the kernel, reruns all its watch expressions and shows the results? So the flow would be:

1. Write a watch expression to rerun after every call (e.g. display(n))
2. Send some code to the kernel (e.g. n = n**2)
3. Kernel executes the code from 2. and sends back the result
4. Watch panel sends its snippets to be run
5. Kernel executes the watch expression and sends back the result
6. Watch panel displays the new value of your expression

It's not quite as good as having all the old values there too, but it could be implemented with no knowledge of the particular language and no parsing of the code, and with little overhead.

Then the interface would look something like this (potato quality) drawing.

Or maybe a smaller panel that doesn't take up a whole vertical column. Or something. We can figure that part out.

from hydrogen.

This sounds eerily like it could use the comms channel that the ipython widgets use.

from hydrogen.

Huh, I hadn't looked at that channel at all. Can we use it with updates to Hydrogen alone, or does it need kernels to play along?

from hydrogen.

This could also be used to debug functions/methods directly by placing a call with parameters on the panel where the result of every assignment is displayed below (maybe even the same line, just like Bret Victor has envisioned it).

I don't know if the panel is the best way to display plots or anything that is bigger than some small values. Any ideas?

from hydrogen.

Definitely useful for functions, plots, etc also. I would love having live plots of my data onscreen while I manipulate it.

I expect a few hundred pixels wide is enough to use the plots to keep tabs on what's going on. You probably wouldn't want a larger plot always on-screen. When it's the thing you're actively looking at, you can run it in the main editor (or maybe resize the pane bigger).

This is now a priority, and probably the next significant feature that I work on.

from hydrogen.

Sounds great, maybe this will cause some further ideas for interactive programming. I'd love to see that!

from hydrogen.

Here's a preview:

It still needs some testing, but I expect to release this within the next couple of days.

from hydrogen.

This is now available for testing on the v0.4.0 branch: #60

You can install this branch by running apm dev hydrogen, cding into the folder Atom clones it to, and running git checkout v0.4.0.

Anybody who tries this out, let me know what you think in a comment on the pull request!

from hydrogen.

you might want to have a look at user_expression, they are side execution request that can be inserted by the client that are excuted befor (or after?) user code, do not appear in history and are ment to convey side information to the frontend.

You can for example, ask for a list of variable to be sent back after each execution, as a json objet.
Typically that's how the qtconsole display the list of availlable magics in a menu. it requets a ls_magic --json as a user_expression, and use the result to populate the menu.

from hydrogen.

@Carreau that's a really good thought.

For the moment I'm going to stick with this implementation despite it being a little dodgier and semantically incorrect. One of my biggest priorities is maintaining compatibility with as many kernels as possible, and lots of them implement only the "critical path" of executing code and skip the bells and whistles that are in the spec but not required to make the Jupyter notebook work. Definitely a change to make down the line though.

from hydrogen.

I completely understand, and that's typically the kind of things that are underdocumented.

This is one of the reason we asked for some funding to ba able get the principal kernel and frontends authors in the same room for a couple of day and figure out theses things.

from hydrogen.

That would be great.

I also cannot recommend strongly enough having some certification or automatic suite of tests for kernels. 75% of the kernels I've seen (from e.g. https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages) are broken, incomplete, or not to spec in one respect or another, and many of them don't even work with the notebook frontend.

Having a certification or testing process which displays a warning to the user when they're on a dodgy kernel would encourage kernel devs to implement the spec more closely (and tell them where they're not). Right now it seems like "works with the notebook" is the de facto test suite, and all kinds of awful things get shipped as a result.

from hydrogen.

I also cannot recommend strongly enough having some certification or automatic suite of tests for kernels. 75% of the kernels I've seen (from e.g. https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages) are broken, incomplete, or not to spec in one respect or another, and many of them don't even work with the notebook frontend.

We are working on that :

https://github.com/jupyter/jupyter_kernel_test

Still a question fo documentation on how to run it.
Sometime it is also difficult to express all the test.
like adding 1 and one can be 1+1, (+ 1 1) or +(1,1) which make some test tricky.
But we should at least be able to test the protocol in some area.

from hydrogen.

Frankly I think it will just take a lot of per-language effort to get this off the ground, but it's extremely worth it.

I expect many kernel developers will need an extra push to run these tests and implement parts of the spec they aren't personally using. Something like a build status badge on the kernel's logo in the notebook (that all their users can see) might do the trick.

from hydrogen.

There is work on that too, a main page that list the kernels and their features. Having auto-testing kernels features to put badges was considered.

jupyter/jupyter.github.io#7

from hydrogen.

Design issues aside, this would be a strong step. Especially if there was a really clear separation between "known good" kernels and "experimental" ones.

from hydrogen.

Shipped!

from hydrogen.