These are chat archives for ipython/ipython

24th
Aug 2015
Matt Craig
@mwcraig
Aug 24 2015 00:52
Are you doing this in a notebook? If so, a widget might do the trick...
Jessica B. Hamrick
@jhamrick
Aug 24 2015 06:27
The nbagg/notebook matplotlib backend doesn’t seem to work anymore, yet the magic reports it as being installed:
In [1]: %matplotlib nbagg
/Users/jhamrick/.virtualenvs/temp/lib/python3.4/site-packages/IPython/kernel/__init__.py:13: ShimWarning: The `IPython.kernel` package has been deprecated. You should import from ipykernel or jupyter_client instead.
  "You should import from ipykernel or jupyter_client instead.", ShimWarning)
UsageError: Invalid GUI request 'nbagg', valid ones are: qt, gtk, glut, gtk3, wx, qt5, pyglet, tk, osx
In [2]: %matplotlib --list
Available matplotlib backends: ['tk', 'qt', 'notebook', 'nbagg', 'wx', 'gtk', 'gtk3', 'qt4', 'osx', 'inline', 'qt5']
Jessica B. Hamrick
@jhamrick
Aug 24 2015 06:41
Ahh, nevermind, that’s beause the notebook backend doesn’t exist in terminal ipython.
cel4
@cel4
Aug 24 2015 08:36
There is no way to deactivate notebooks cells, so that they are not executed during "run all cells", is there?
ambiorix21
@ambiorix21
Aug 24 2015 09:42
@mwcraig I am doing it in a notebook. What exactly would such a widget be?
Okay, I found a solution on stackoverflow expalining these kind of widgets ;). Thanks for the hint!
Jason Grout
@jasongrout
Aug 24 2015 14:03
@minrk, @stefanv: re: the choppy graphics. A way to do (3) is to compute a low-resolution approximate image and use that while things are interactive, and then follow up with a full-resolution image after activity has died down.
Stefan van der Walt
@stefanv
Aug 24 2015 15:04
@jasongrout That's an excellent idea. Nor sure if that is possible with current widget implementation?
Jason Grout
@jasongrout
Aug 24 2015 15:12
we don't have a built-in way of doing it yet, but it's something I've wanted for quite some time. what kind if support from ipywidgets would be needed? In the case of a slider, how about we set a flag in the slider when the user starts dragging, and make sure the flag is off on the final update when the user releases the slider.
Steve Dower
@zooba
Aug 24 2015 15:29
@jasongrout A delay that keeps resetting every time something changes is pretty standard (e.g. reparse code in an editor when someone stops typing). Maybe widgets could send a final update request some time after the last change?
Jason Grout
@jasongrout
Aug 24 2015 15:55
the widget frontend (i.e., the slider) knows when it is being dragged, and when the user releases the slider.
we can convey that information to the backend immediately, and the backend can do whatever it wants. I think the reason for a delay would be to try to guess when a user is dragging a slider. We know for sure, so we might as not guess.
Steve Dower
@zooba
Aug 24 2015 15:57
Can users manipulate a slider with the keyboard?
Jason Grout
@jasongrout
Aug 24 2015 15:57
yes
this wouldn't handle that case of holding down a key, with key repeats
Steve Dower
@zooba
Aug 24 2015 15:57
I know, that's why I suggested the delay
It's only 200-300ms, maybe less since you know there'll be a network delay too
Jason Grout
@jasongrout
Aug 24 2015 15:58
ah. I think the backend can implement the delay, if it wants. I think the frontend should just convey the user interaction as clearly as possible.
Steve Dower
@zooba
Aug 24 2015 15:59
Can the backend can send an update without it being a reply to a specific message?
Jason Grout
@jasongrout
Aug 24 2015 16:00
I think it would technically be replying to some message, but we could tap into the event loop in the kernel to schedule an update
so a function on the backend should be able to delay 300ms, for example, and then send some update.
Steve Dower
@zooba
Aug 24 2015 16:01
Seems like it'd be the second reply to the same message, so it can send out the quick image first and follow up with the full fidelity one
That may also be more complicated state/logic to implement in the backend rather than the frontend, but I'm speculating.
Jason Grout
@jasongrout
Aug 24 2015 16:02
right; we can play with the ideas here.
Stefan van der Walt
@stefanv
Aug 24 2015 17:38
The trigger-on-timeout functionality probably belongs in the widget implementation, rather than leaving it to users.
Andrew Gibiansky
@gibiansky
Aug 24 2015 20:37
Has anyone used jupyter_client? I'm trying to use it to do something similar to vim-ipython, but it's creating tons of kernel json files. How do I tell it where to put them?
Min RK
@minrk
Aug 24 2015 21:01
The default location is probably the right one. You can specify the connection_file attribute, though.
It should clean them up on KM tear down, but you can do it explicitly with cleanup_connection_file (or something quite close to that)
Andrew Gibiansky
@gibiansky
Aug 24 2015 21:34
Thanks. The default location is in the working directory I think, so it litters files around the places the user is working... Should be easy to change to a temporary directory somewhere.
Min RK
@minrk
Aug 24 2015 22:18
Oh, weird. I don't think it's supposed to be. Are you using master?
Andrew Gibiansky
@gibiansky
Aug 24 2015 22:19
No, just whatever pip installs when I run pip install jupyter_client
Min RK
@minrk
Aug 24 2015 22:24
ok. Maybe it's something non-default that we are doing everywhere we are using jupyter_cleint (it's used in the QtConsole, notebook, etc.)
Andrew Gibiansky
@gibiansky
Aug 24 2015 23:51
Is there any way to emulate IPython's --debug using only jupyter_client?
I'm having a lot of problems because it won't reply on shell channel but I can't really see a stream of messages to debug the issue.
I think the issue with kernel-*.json files is IHaskell specific, BTW. IHaskell isn't writing those files, but perhaps something to do with the way the kernelspec works.