These are chat archives for ipython/ipython

2nd
Mar 2015
Jason Grout
@jasongrout
Mar 02 2015 15:15
@jcoady: install_nbextension has been simplified. See the docs at https://github.com/ipython/ipython/blob/master/IPython/html/nbextensions.py#L137.
I think in your case, you'll need to call it 3 times, once for each thing to install, as `install_nbextension(path='...', ...)
Actually, I'd recommend that you bundle all of your js files into a directory, and just install the one directory, to avoid cluttering up the nbextensions/... namespace
Jason Grout
@jasongrout
Mar 02 2015 17:04
@minrk - what are the plans for merging things in 3.1 vs 4.0?
i.e., are things marked for 4.0 merged only after 3.1 is released, or are there two separate branches?
Min RK
@minrk
Mar 02 2015 17:11
We're merging 3.1 stuff for a bit, and we'll fork off the 3.x branch as soon as we merge the first 4.0 PR.
No specific plans, just waiting a little bit on some of the 4.0 stuff so we don't have more backporting to do than we have to, since it's a little tedious.
Since we have so many 3.1-targeted PRs already.
Jason Grout
@jasongrout
Mar 02 2015 17:14
sure, makes sense
Min RK
@minrk
Mar 02 2015 17:15
Probably start merging 4.0 things by the end of the week, I would guess. Maybe sooner.
Jason Grout
@jasongrout
Mar 02 2015 17:15
and the big repo split happens after a lot of the 4.0 PRs get merged, right?
Min RK
@minrk
Mar 02 2015 17:16
Yeah. We are going to try to plan out the big split during our dev meeting next week. We are going to ask most PRs to wait during that.
But the stuff that's already open now, I think we'll get through before splitting.
One of the tricky bits right now is deciding what to do with traitlets.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:17
I hope the traitlets things would be merged before the split. Things like the allow_none=False by default will be difficult to merge after
Min RK
@minrk
Mar 02 2015 17:17
Yes, definitely
Jason Grout
@jasongrout
Mar 02 2015 17:17
@minrk - do you mean deciding whether traitlets is split off or not?
Min RK
@minrk
Mar 02 2015 17:17
Our plan has always been to have a 'config' package that includes traitlets as the lowest level, most stable package. But some of the work you guys want in traitlets suggests that maybe Widgets should ship its own fork of traitlets where that stuff happens.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:18
There are more changes I would like to make in the traitlets, but I am waiting for the ones I proposed to be merged, because it would conflict everywhere
Min RK
@minrk
Mar 02 2015 17:18
Because traitlets as we use it everywhere other than widgets is very stable and slow moving.
Jason Grout
@jasongrout
Mar 02 2015 17:18
hmmm, that seems troubling to have too many forks of traits
Min RK
@minrk
Mar 02 2015 17:18
And the demands for traitlets in the config system and in the Widgets seem to be diverging.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:19
actually, besides the allow_none=False most of the things would not break backward compatibility
Min RK
@minrk
Mar 02 2015 17:19
Another option, preferable if possible, would be for customizations in the Widget stuff to be done via subclassing.
Jason Grout
@jasongrout
Mar 02 2015 17:20
so maybe traitlets should be split off into a separate repo, and then IPython ships its own (stable, never-changing) fork
Min RK
@minrk
Mar 02 2015 17:20
I would go the other way - Widgets ships its own unstable, experimental fork.
since widgets is the outlier
We should talk about the changes you want to make. This may not be necessary if you only have a few things planned, and expect to be done with significant changes to traitlets very soon.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:21
@minrk, you consider the already proposed changes to be experimentat things.
?
Min RK
@minrk
Mar 02 2015 17:22
I'll have to look, but not yet, I don't think. Maybe early validation and definitely dynamic traits.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:22
subclassing would work for dynamic traits
Min RK
@minrk
Mar 02 2015 17:23
Terrific. Maybe we should start there, and only fork if working in separate repos becomes too problematic.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:24
but I don't see how to solve the race conditions we have on widgets without early validation
like the one on the slider
Min RK
@minrk
Mar 02 2015 17:24
I'm not saying any of your changes shouldn't be merged.
Jason Grout
@jasongrout
Mar 02 2015 17:24
are there going to be dev meeting sessions we can participate in via google hangout or something?
Min RK
@minrk
Mar 02 2015 17:24
Absolutely, yes.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:25
(or something else than google hangout :))
Min RK
@minrk
Mar 02 2015 17:25
Do you know your availability next week?
I presume AM here is better for you, or no?
We're here all week, so we should be able to schedule at least one session around you guys.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:25
does not matter. Tuesday mornings are not available
Jason Grout
@jasongrout
Mar 02 2015 17:25
yes; I'll be around, except for various meetings on various days (not too many, though)
Min RK
@minrk
Mar 02 2015 17:26
We don't have anything scheduled specifically, yet, so if you guys want to pick a time, we can make it work.
Jason Grout
@jasongrout
Mar 02 2015 17:26
For me: up until around 5pm or so (or maybe 5:30pm) ET should be good for most days. Wednesday even later is okay.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:26
damn I hoped the early validation would be the easiest to merge :)
Min RK
@minrk
Mar 02 2015 17:27
It might be fine, it's been a while since I looked at it.
I don't mean to worry you. I'll look at it again.
Jason Grout
@jasongrout
Mar 02 2015 17:27
I might have some phosphor stuff to show you guys. We'll see.
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:28
it becomes really valuable once the unused default values are not validated, (other PR)
but can be merged independently
Min RK
@minrk
Mar 02 2015 17:28
makes sense
@jasongrout great!
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:28
phosphor is really cool
Jason Grout
@jasongrout
Mar 02 2015 17:29
@minrk: do you guys have any exposure to TypeScript?
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:29
TypeScript really talks to my inner C++ aficionado.
Min RK
@minrk
Mar 02 2015 17:30
Not much
Jason Grout
@jasongrout
Mar 02 2015 17:31
for the record, I'd like to be in on discussions about real-time collaboration as well
Min RK
@minrk
Mar 02 2015 17:31
ok
Min RK
@minrk
Mar 02 2015 17:37
Want to come to Berkeley next week?
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:37
That would be great :)
Min RK
@minrk
Mar 02 2015 17:38
You guys all have private jets, right?
just hop over for a meeting?
Jason Grout
@jasongrout
Mar 02 2015 17:38
This message was deleted
Sylvain Corlay
@SylvainCorlay
Mar 02 2015 17:39
Not quite private, I must share mine with Jason.
(because of the crisis)
Min RK
@minrk
Mar 02 2015 17:40
naturally
Jason Grout
@jasongrout
Mar 02 2015 17:40
This message was deleted
john
@jcoady
Mar 02 2015 17:45
@minrk I just installed the new IPython 3.0 and tried it out with a custom python module that makes use of threading. What I noticed is that if I create a thread in a cell, the thread does not run until the cell finishes executing. It worked fine in IPython 2.x but doesn't work in IPython 3.0 . What has changed between IPython 2.x and IPython 3.0 with regard to threading?
Min RK
@minrk
Mar 02 2015 17:45
the thread does not run, or the output does not appear?
john
@jcoady
Mar 02 2015 17:47
It appears as though the thread does not run. For instance, I put a time.sleep(10) command at the end of a cell and I notice that the thread does not run until the sleep timeout is completed.
Min RK
@minrk
Mar 02 2015 17:47
Can you share an example?
I think there have been changes to how output from background threads is handled, but I don't know how we could influence how threads actually start.
Jonathan Frederic
@jdfreder
Mar 02 2015 17:49
@rgbkrk I'm not sure I understand the question. Are you talking about toggling through GUI panels?
john
@jcoady
Mar 02 2015 17:49
The example I have is with my custom module. I will create a small example to demonstrate it and get back to you.
Min RK
@minrk
Mar 02 2015 17:53
@jcoady thanks
Here is the demo. It looks like the thread starts but I don't see the output from the background thread.
The cell needs to finish running before the output appears. What were the changes for handling output from background threads?
Min RK
@minrk
Mar 02 2015 18:06
The thread's running, the output is just being buffered.
background threads are not allowed to publish output directly, they can only tell the main thread that there's output to publish.
Any call to sys.stdout.flush (can be triggered by print in the main thread) will flush that buffer, but if the main thread is blocking, it may not be flushed until the end of the thread.
Jonathan Frederic
@jdfreder
Mar 02 2015 18:12
@rgbkrk if that's what you mean, the easiest would be to link a combo widget's value to the active tab index of a Tab widget.
john
@jcoady
Mar 02 2015 18:12
So in order to get background thread stuff to appear I need to call sys.stdout.flush() in the main thread? I will give it a try.
Jonathan Frederic
@jdfreder
Mar 02 2015 18:14
If it's a multiselect thing instead of an enum, link an array of checkboxes to corresponding widget.visible traits
Kyle Kelley
@rgbkrk
Mar 02 2015 18:20
@jdfreder I set it up with an enum for the trait. This is 1 bit vs. 8 bits per block (bitjet became one widget).
Jonathan Frederic
@jdfreder
Mar 02 2015 18:35
Cool
Matthias Bussonnier
@Carreau
Mar 02 2015 19:01
@jdfreder, is there an easy way from kernel side (non-python) to know the version of widgets ?
Jonathan Frederic
@jdfreder
Mar 02 2015 19:03
@Carreau no, right now the version is stored in the kernel's implementation of the widgets (Python in this case) - https://github.com/ipython/ipython/blob/master/IPython/html/widgets/widget.py#L136
But that's a good point, the same information should probably be stored in the front-end
it boils down to a lack of symmetry, again...
Matthias Bussonnier
@Carreau
Mar 02 2015 19:04
Yeah, it's more a question for Julia, interact that try to be compatible both.
JuliaLang/Interact.jl#54
Jonathan Frederic
@jdfreder
Mar 02 2015 19:04
Since the front-end widgets all use a dummy model, which mirrors the model of the back-end on first state push.
@Carreau well they could poll the front-end using a comm
like you suggest
to get the Notebook client's version
which at this point in time correlates directly with the widgets version
Matthias Bussonnier
@Carreau
Mar 02 2015 19:08
OK, I'll tell that on the PR.