Support Jupyter (IPython 3) kernel spec #224
Comments
|
Yep, that's in progress in #210 we'll need a few more hooks in IPython for IJulia custom javascript. Assigning to me. Wont have time I guess to do it for your keynote, but see you at EuroScipy anyway. |
|
Technically speaking the hook missing in IPython/Jupyter are
|
|
Ah, I forgot about #210. Support for switching the logo should really happen on the Jupyter side; @ellisonbg said this was planned. I don't think it's necessary to switch the favicon as long as the favicon is for Jupyter and not Python. What is missing for handling the language in the metadata? Isn't this already in Jupyter? |
|
Most of current kernels to add a We also do need a way to "un-monkeypatch" the javascript. Eg, I haskell patch for tooltip to show on I propose that the kernelspec If there is a custom.css file, it is not yet either injected in the notebook. |
|
The custom Javascript patches that we currently use, if I remember correctly, were mainly:
I feel like whether the tooltip is triggered by space or shift-tab or whatever should be a global keybinding preference, not a per-language thing. I don't see why this is language-specific. |
|
@Carreau, regarding adding and using the |
Yes it is
Not sure the tooltip code has been updated to use that yet. But you are right
Haskell don't use parents. in python or julia
No, but it's on the list of things we know we should do.
Yes agreed |
My bad, yes there is ipython/ipython#6217 |
|
Since the plan, as I understand it, is to serve multiple different types of notebooks from a single Jupyter server, each according its kind, and favicon's are per-server, I don't think that changing favicons even really makes sense. |
|
@StefanKarpinski, actually it is a bit more ambitious than that. @ellisonbg showed me a demo today in which there was a menu item on the notebook allowing you to switch languages inside a single notebook. (Unfortunately, switching languages kills the old kernel. So, if you switch from Julia to Python and then back to Julia, you lose all of your Julia variables. Also, "run all" no longer works because Jupyter doesn't know which cells were in which languages. So, I'm skeptical that this feature is particularly useful, as opposed to having a fixed per-notebook kernel/language.) |
|
Hmm. That seems kind of pointless. @Carreau, @ellisonbg, what's the motivation? |
|
I don't think the kernel is likely to be a function of time for a given notebook, but we need UI somewhere to select the kernel for a given notebook. It's currently on the notebook page itself. It's not likely to be changed much more often than at notebook creation time, even though the UI as it is technically allows people to fiddle with it in ways that don't make much sense. |
|
@minrk, wouldn't it make more sense for the UI to be on the dashboard? e.g. add a drop-down menu by "new notebook" to set the current kernel preference. The problem with allowing people to change it while editing the notebook is that you then need to support that functionality, even if it doesn't make much sense. For example, see @Carreau's comments above about having to support both patching and unpatching of the Javascript, which seems like unnecessary pain. And I'm guessing that this is only one of many implementation annoyances. |
|
I agree we need to rethink the UI - I have been demoing this all week and On Fri, Aug 22, 2014 at 9:12 PM, Steven G. Johnson <notifications@github.com
Brian E. Granger |
|
@stevengj sure, that's a possibility. It would need to be triggered somehow in the notebook UI anyway, as part of the 'New Notebook' action in the File menu, or as a pop-up when you open a notebook with no associated kernel. Plus, it still makes sense to be able to switch the kernel at some point, because one could reasonably have several Python kernels or several Julia kernels available. So switching kernels is definitely required. |
|
Agreed with min, we had the discussion of changing only at creation time, or using a "copy this notebook and make it XXX". let's say you got an assignment it requires you to copy the notebook. Update from Julia 0.2 to Julia 0.3 (cause you are a dev), make a copy. In terminal it makes sens to be able to do The reasoning is we want first an "indicator" of the language, while we are relatively advance user that can in less than 100ms distinguish Julia for perl, from C, from Python 2 or 3 code, most user cannot. So there is an indicator. And if you ever want to switch the most natural place is this indicator. After we can make the fact that it restart the kernel more obvious by having the switch also clear all output and scroll to top. |
Yes once we have a Jupyter favicon, people actually using IJulia now would be confuse to have an IPython icon, but agree low priority (and might not even works on all browsers) |
|
@Carreau, allowing people to change kernels in a live notebook, with all of the complexities that entails (e.g. unpatching) is a high price to pay just to have an indicator. Why not just have a static indicator? (In addition to logo changes.) @minrk, the reason I suggested a drop-down menu next to the "New Notebook" button was that most users will probably be using the same language most of the time, so it is more efficient for them to just set the preference once and then be able to click "new notebook". Having a pop-up (or your current scheme), in contrast, imposes a cost every single time you create a new notebook. (And yes, I know there is a config file where you can change this, but forcing users to edit a config file is also a high cost.) |
There will be a way to set the default. Then "New notebook" will always behave without having the user to switch. The problem with switching from dashboard is that it adds a strong coupling between dashboard and notebook page, which shouldn't be much easier that unpatching. If unpatching becomes too hard, we can still have the change of kernel reload the page after saving the notebook, but unpatching shouldn't be much harder than saving a copy of the function at patch time and replace with the old one after. Also reload would require saving the notebook, and I woudl prefer people to be able to test different languages without saving files. |
|
@Carreau, @ellisonbg already told me there will be a way to set a default by changing some config file somewhere, but that's not good enough. Not only is this painful from a usability perspective—most users will not want to edit a config file manually, and in fact will not even be aware of config files (they are not discoverable)—but it is also doesn't address the case where I'm working with Python on Thursday and Julia on Friday, and I want to change the default easily without restarting Jupyter. And it might not even be possible to edit the config file if I'm running Jupyter on a remote server (authenticated via webcerts) and viewing it locally in my browser. Switching from the dashboard does not add a strong coupling between the dashboard and notebook. My proposed switch in the dashboard only affects new notebooks that are opened subsequently. That's why it's next to the "new notebook" button. The whole point (well, part of the point) of this is to avoid changing the kernel in a running notebook. I know that unpatching is technically possible, but you are adding a whole level of complexity for no useful purpose. (Not to mention that I think unpatching will be only the beginning of our troubles when we start to use this in practice for complicated notebooks that have lots of embedded JS in output cells.) |
|
Oh, but we will have "new notebook" with drop down in the dashboard at some point. We just have a limiting manpower willing to work on JS side. Envoyé de mon iPhone
|
|
Header logo and favicon for now is at least Jupyter rather than IPython: ipython/ipython#7004, ipython/ipython#7031 |
|
Okay, no problem. |
|
However, the kernel logo is going to be part of the kernel spec. The layout is still TBD. ipython/ipython#6537 |
|
@Carreau, since ipython/ipython#6537 was merged, is there anything else holding this up? |
Me getting time to finis #210 among other. I should be definitively in berkeley in something like 48h. |
|
Cool, thanks! So we are not waiting on any changes on the IPython side anymore. |
|
Except for last minute raptor, no. |
|
It looks like both 0.3.6+ and 0.4-dev work quite nicely with 3.0.0rc1:
Really liking the improved scrolling behavior! |
|
It looks like the only thing left to do is to fix this deprecation warning: Otherwise it looks like all systems go. |
|
Just don't use |
|
I don't need |
|
We do out best so that you do not have to:
Still a bit of work, but all languages should be equal citizen soon. |
|
I would really like to have both Julia 0.3 and 0.4 accessible from Jupyter. Is that possible now or is that still WIP? |
I guess changing this line to install in |
|
I'll give it a try. Sadly, 3.0 breaks one of my favorite packages, @shashi's
but I suppose this was inevitable. |
|
:-( Sorry about that, That's also why we split in Jupyter, we hope to have non-python contributor, at least in the governance of the project, to minimally know what the breakage in differents kernels might be and get early feedback. Side question as you are around: are you aware that we have https://try.jupyter.org ? |
|
Indeed, making essentially that change and rebuilding
Not until you mentioned it! |
Well, it's still in progress it spawns Docker container without network access |
|
You're welcome to use all the notebooks I have posted publicly at https://github.com/jiahao/ijulia-notebooks and |
This change allows multiple Julia versions to be registered as IPython/Jupyter 3.0 kernels. You will get entries like - Julia 0.3.6 - Julia 0.4.0-dev - Julia 0.4.0-dev debug depending on which Julia binary is used to build IJulia.jl. To get multiple Julia versions available as IPython kernels, you will need to rebuild IJulia from within each Julia binary. Ref: #224
This should be a very simple matter of writing out a couple of extra files to the
.ipythondirectory.cc: @ellisonbg, @Carreau
The text was updated successfully, but these errors were encountered: