These are chat archives for ipython/ipython

4th
Dec 2015
epifanio
@epifanio
Dec 04 2015 00:54
class NumberSelector is defined in the previous cell, as:
class NumberSelector(DOMWidget):
    _view_name = Unicode('NumberSelector', sync=True)
    description = Unicode(help="Description of the value this widget represents", sync=True)
    value = Int(0, sync=True)
then the js code, give this log in the js console:
Uncaught TypeError: Cannot read property 'extend' of undefined(anonymous function) @ VM1861:5context.execCb @ require.js:1678Module.check @ require.js:878Module.enable @ require.js:1165Module.init @ require.js:783(anonymous function) @ require.js:1441
in code cell 3
i guess because of: var NumberSelector = IPython.DOMWidgetView.extend
which perhapse changed in newer version ?
epifanio
@epifanio
Dec 04 2015 01:01
found answer here https://ipython.org/ipython-doc/3/whatsnew/version3_widget_migration.html . i’ll try to apply the needed changes
but i don’t know how to fix: Uncaught ReferenceError: widget is not defined
from the js code:
%%javascript
// We import the WidgetManager.
require(["widgets/js/widget"], function(WidgetManager){ 

    // We define the NumberSelector view here.
    var NumberSelector = widget.DOMWidgetView.extend({

        // Function for rendering the view.
        render: function(){

            // Little trick to pass the current context into closures.
            var that = this;
...
epifanio
@epifanio
Dec 04 2015 01:06
that’s the last bit to finish the porting to 4.x
epifanio
@epifanio
Dec 04 2015 01:52

so .. i changed the js code to:

%%javascript
// We import the WidgetManager.
require(["widget"], function(WidgetManager){ 

    // We define the NumberSelector view here.
    var NumberSelector = widget.DOMWidgetView.extend({

        // Function for rendering the view.
        render: function(){

using require(["widget”] … instead of require(["widgets/js/widget … and widget.DOMWidgetView.extend instead of IPython.DOMWidgetView.extend
but when testing the widget i still have (from the js console):

Couldn't create a view for model id '8727d6f51f804c7aa582b3d95b3c630d'  --  Error: Class NumberSelector not found in registry (…)
from code cell 4:
widget = NumberSelector()
widget

so i guess the last line in the js code:

WidgetManager.register_widget_view('NumberSelector', NumberSelector);

didn’t worked

epifanio
@epifanio
Dec 04 2015 03:37
I opened an issue rossant/euroscipy2014#2 :( shame on the custom example i can’t figure it out
Alexander Korsunsky
@akors
Dec 04 2015 11:30
Hey guys, not a dev here. I saw in an older tutorial that there was a help chatroom, but the link has disappeared from the ipython.org page. Has it been removed? Is there a replacement, or is it OK to ask user questions here?
Thomas Kluyver
@takluyver
Dec 04 2015 12:19
@akors it's still there, but we decided to de-emphasise it, and encourage asking questions on Stack Overflow or mailing lists, where the answers create a searchable record that people in the future can use.
Alexander Korsunsky
@akors
Dec 04 2015 12:20
@takluyver I understand. Thanks for the reply
Thomas Kluyver
@takluyver
Dec 04 2015 12:20
If we need more rapid conversation with someone to help debug an issue, we can point them to the chat room.
no problem :)
Min RK
@minrk
Dec 04 2015 15:26
There isn't a way to distinguish between a notebook and terminal frontend, in part because there can be both at the same time.
Matthew Rocklin
@mrocklin
Dec 04 2015 15:27
Darn
Min RK
@minrk
Dec 04 2015 15:27
You can identify whether you are in a Kernel vs regular IPython shell
Matthew Rocklin
@mrocklin
Dec 04 2015 15:27
Is the best option something like a kwarg?
Are there contexts in which kernels are often used but widgets aren't appropriate?
excluding ipython parallel
Min RK
@minrk
Dec 04 2015 15:28
qtconsole, terminal
Matthew Rocklin
@mrocklin
Dec 04 2015 15:28
you mentioned the term "vs regular IPython shell" is this not the same as "terminal"
Min RK
@minrk
Dec 04 2015 15:29
ipython as opposed to jupyter console --kernel python3
the latter is indistinguishable from a kernel hooked up to the notebook
What would you do differently?
Matthew Rocklin
@mrocklin
Dec 04 2015 15:30
In the notebook I would use from IPython.html.widgets import FloatProgress. and return immediately, updating the progressbar from a separate thread. In the console I would probably have to block and dump to sys.stdout
In principle these are different behaviors and should come from different functions. In practice it's a bit of a pain to have a split API for users.
but not terrible
Min RK
@minrk
Dec 04 2015 15:31
Hm.
Matthew Rocklin
@mrocklin
Dec 04 2015 15:31
it'd be nice if I could at least raise a warning if I suspected they were doing the wrong thing
Min RK
@minrk
Dec 04 2015 15:31
It certainly is annoying. We've considered doing things like setting __file__ when it's a notebook.
Matthew Rocklin
@mrocklin
Dec 04 2015 15:32
Bokeh has this problem as well. They have an explicit use_notebook() function that you're supposed to call if you're in a notebook.
Min RK
@minrk
Dec 04 2015 15:32
But in the meantime, it seems to be the norm to have a process-global enable_notebook().
right
Matthew Rocklin
@mrocklin
Dec 04 2015 15:32
which always felt a bit unfortunate
Min RK
@minrk
Dec 04 2015 15:32
Not awesome, but it works for now. We've had a few 'frontend-capability-detection' discussions, but nothing conclusive.
Part of the reason it's complex is that you can have multiple frontends connected at once, with different capabilities.
Matthew Rocklin
@mrocklin
Dec 04 2015 15:34
In principle I agree, in practice I find that people are often in exactly one frontend, and that frontend is either ipython shell or the notebook (at least with the people I commonly work with)
__jupyter_frontends__ = {'notebook', 'console'} ?
anyway, you all have probably thought about all of these things
Min RK
@minrk
Dec 04 2015 15:34
So the question becomes: How/when do frontends communicate their capabilities, and then what's the API for libraries to look that up.
Matthew Rocklin
@mrocklin
Dec 04 2015 15:34
my apologies for giving inexpert opinions to experts :)
Min RK
@minrk
Dec 04 2015 15:35
In reality, it's a pretty good approximation to guess that Kernels are used in notebooks.
Sylvain Corlay
@SylvainCorlay
Dec 04 2015 15:35
Well, in a not so far future, people will have multiple web front-ends connected to the backend, the same notebook in multiple tabs, but potentially a js console etc.
Min RK
@minrk
Dec 04 2015 15:35
So as long as there's an escape hatch for the non-notebook frontends, it is probably okay to assume widgets work if it's a kernel
Matthew Rocklin
@mrocklin
Dec 04 2015 15:36
OK, can I ask for a SO answer that says how to identify the presence of a kernel and a warning that this isn't an perfect signal?
Min RK
@minrk
Dec 04 2015 15:36
@SylvainCorlay right, that's why it has to be a capability-detection and not frontend-identification, because there are going to be a growing number of frontends that support widgets that are not the notebook. We don't want to start another User-Agent mess.
Sure.
Sylvain Corlay
@SylvainCorlay
Dec 04 2015 15:37
@minrk maybe there should be a check to see if one is a zmqshell or not
when trying to use ipywidgets. At the moment, the error when trying to use widgets in a bare IPython session is not helpful for someone who does not know that there is not really a separate "kernel" in this case.
Min RK
@minrk
Dec 04 2015 15:37
It's easier than that: `hasattr(get_ipython(), 'kernel')
Matthew Rocklin
@mrocklin
Dec 04 2015 15:38
oh, looks like someone replied with a redirect to another question
Min RK
@minrk
Dec 04 2015 15:39
The second answer there doesn't work.
epifanio
@epifanio
Dec 04 2015 15:43
I posted my issue on stack overflow http://stackoverflow.com/questions/34092007/porting-ipython-widget-to-newer-ipywidget-api maybe can be helpful for others
Min RK
@minrk
Dec 04 2015 15:46
@mrocklin answered. Now off to my office christmas party.
Matthew Rocklin
@mrocklin
Dec 04 2015 15:46
Thanks @minrk !
Hope you're enjoying your new home
I'm running into this myself
Matthew Rocklin
@mrocklin
Dec 04 2015 17:37
One thought here is that one shouldn't affect widgets with threads, but should instead integrate into the IPython event loop. If this is an appropriate answer then are there documents or an example somewhere on how to do this?
A quick google search hasn't yielded a great answer to this.
Jason Grout
@jasongrout
Dec 04 2015 17:40
looking at this
  1. are messages getting sent to the browser?
Jason Grout
@jasongrout
Dec 04 2015 17:46
It's possible that the main thread being busy means that other threads are blocked from sending messages (messages should go through the main thread, IIRC)
@minrk would know the details better
can you start your work in a separate thread, leaving the main thread available for messages?
Or one thing you can do is periodically stop in the work and give the event loop a chance to run once
Sylvain Corlay
@SylvainCorlay
Dec 04 2015 17:48
@mrocklin indeed, messages will be sent to the frontend only if the kernel is idle.
You can access the tornado event loop using get_ipython
when the other threads wants to make updates to the float progress, it can call call_*.
Matthew Rocklin
@mrocklin
Dec 04 2015 17:49
OK, I'll try a couple of things out and report back
Thanks for the help @jasongrout , @SylvainCorlay
Sylvain Corlay
@SylvainCorlay
Dec 04 2015 17:51
Correction:
import zmq
zmq.eventloop.ioloop.IOLoop.instance()