These are chat archives for ipython/ipython

24th
Sep 2014
Jason Grout
@jasongrout
Sep 24 2014 15:37
did we agree on a time for the g+ hangout about widgets/outputs? How long do you imagine it being?
just got Brian's email about it...never mind
Jonathan Frederic
@jdfreder
Sep 24 2014 17:59
@minrk @ellisonbg @takluyver any of you guys know if it's possible to register a trait change callback to always run last? I'm having trouble with widget trait validation loops, because the change handler that syncs the widget state is getting fired before the handlers that do value validation.
:cry:
It would be nice if the trait change callback that did widget state synchronizing always fired last...
Min RK
@minrk
Sep 24 2014 18:01
Can probably force it somehow
Jonathan Frederic
@jdfreder
Sep 24 2014 18:02
I'll look into it.. there's got to be something creative that I can do
@SylvainCorlay @jasongrout @ellisonbg ready for the hangout?
Min RK
@minrk
Sep 24 2014 18:05
I'm all set
@jasongrout @SylvainCorlay the link is here...
Min RK
@minrk
Sep 24 2014 18:07
Don't include the URL params (after ?) when you share hangout links
that's how we end up with 3 people all identified as IPython
Brian E. Granger
@ellisonbg
Sep 24 2014 18:09
ahhh
Usability...
Min RK
@minrk
Sep 24 2014 18:11
it's the right link if you use the share dialog
Jonathan Frederic
@jdfreder
Sep 24 2014 19:04
whoops lost you guys
should I reconnect or is the call over?
Brian E. Granger
@ellisonbg
Sep 24 2014 19:05
we are done
Thomas Kluyver
@takluyver
Sep 24 2014 19:13
Just discussing this with Min now, it seems like we have a lot of ways to synchronise state: backbone model/view to synchronise frontend views, the link widget to synchronise models on the frontend, our own widget model stuff to synchronise between kernel and frontend, and link to synchronise traitlets on the backend
given that sync is hard, should we try to eliminate some of the syncing pieces?
In particular, syncing models on the frontend seems redundant given that models already exist in order to synchronise views
Jonathan Frederic
@jdfreder
Sep 24 2014 19:16
The Javascript link hasn't been merged
so it doesn't actually exist yet
ipython/ipython#6454
but it's similar to Python
It wouldn't make sense to not have the Javascript link, when we have the Python link, because they both serve the same purpose (linking specific keys between two different models).
Thomas Kluyver
@takluyver
Sep 24 2014 19:22
But you still have two comm messages to sync the two models, right?
They're just both frontend->kernel, instead of one each way
I just worry that we've got four sync frameworks, and only one of them is an external package that we don't have to take responsibility for
Jonathan Frederic
@jdfreder
Sep 24 2014 19:28
I wouldn't call Python link() and the Javascript link widget "frameworks". In my opinion, it would make more sense if Python link() was removed and the link widget synchronized both in the front-end and back-end so no comm messages would need to be sent.
Min RK
@minrk
Sep 24 2014 19:30
While the Python link is less efficient, it's strictly more useful thank the Javascript one, because it can be used on any HasTraits, not just Widgets.
Jonathan Frederic
@jdfreder
Sep 24 2014 19:31
Good point
Min RK
@minrk
Sep 24 2014 19:33
So if one is killed, it should be js. And I'm always for killing js :)
Jonathan Frederic
@jdfreder
Sep 24 2014 19:33
Haha :smile:
Thomas Kluyver
@takluyver
Sep 24 2014 19:35
Looking at it from further back: rather than syncing bits of different models, should values that we want to keep the same be part of a single model
that is the point of the model/view separation, IIUIC
Jonathan Frederic
@jdfreder
Sep 24 2014 19:35
That's something that we looked at when we first implemented the widgets
But instead it was decided that the MVC design would only live in the front-end
Thomas Kluyver
@takluyver
Sep 24 2014 19:36
But we have models, effectively, in the backend too
Jonathan Frederic
@jdfreder
Sep 24 2014 19:36
and any additional MVC like logic in Python would be built separate to the widget framework
Min RK
@minrk
Sep 24 2014 19:37
It's really M-M-VVV-C
part of why it's difficult to reason about
Jonathan Frederic
@jdfreder
Sep 24 2014 19:37
I think of it as M-M-(V/C)(V/C)(V/C)
but yes :)
Thomas Kluyver
@takluyver
Sep 24 2014 19:37
possibly instead of syncing traitlets, we want something like a TraitletProxy, which acts like a property, but also fires events
that wasn't very clear...
example
A.b is an Int instance
C.d is a TraitletProxy referring to A.b (C instances have an A instance somewhere)
if you access c.d, it actually looks up c.a.b, like if c.d was a plain Python property
Jonathan Frederic
@jdfreder
Sep 24 2014 19:39
That sounds like an interesting idea
Thomas Kluyver
@takluyver
Sep 24 2014 19:39
but if you set a.b, the traitlet on_change things fire for both a.b and c.d
I haven't thought through the details of this, but it avoids storing the same state in two places
Jonathan Frederic
@jdfreder
Sep 24 2014 19:40
Does it break something as simple as "linking" a value of one traitful object to a value of another. i.e. Slider to textbox?
in this case you don't have access to modify the class definitions
Matthias Bussonnier
@Carreau
Sep 24 2014 19:41
I though the JS link would be used for static widgets ?
Jonathan Frederic
@jdfreder
Sep 24 2014 19:41
yes
@Carreau
Thomas Kluyver
@takluyver
Sep 24 2014 19:41
on the JS side, does Backbone have a concept of nesting models
Jonathan Frederic
@jdfreder
Sep 24 2014 19:41
The JS link is a link that would persist with the document
Thomas Kluyver
@takluyver
Sep 24 2014 19:41
i.e. can you say "these two models share a common piece"
Jonathan Frederic
@jdfreder
Sep 24 2014 19:42
I don't think so, but I could be wrong
Min RK
@minrk
Sep 24 2014 19:44
@jdfreder how rigorous are you about deleting any models that aren't used anymore?
An important bit about the notebook is that it only saves the cells you see. Saving the notebook doc shouldn't save any models that you don't currently see.
Thomas Kluyver
@takluyver
Sep 24 2014 19:46
tell me we don't have to implement our own garbage collection in JS ;-)
Min RK
@minrk
Sep 24 2014 19:46
gc on Python should mostly take care of it - deleting a Widget instance closes its comm, which should delete its js counterpart
Kyle Kelley
@rgbkrk
Sep 24 2014 19:46
Want to know if your system is vulnerable to the bash vulnerability? There's a notebook for that.
Min RK
@minrk
Sep 24 2014 19:46
nice!
Jonathan Frederic
@jdfreder
Sep 24 2014 19:47
@minrk Not enough, that was something that I'm supposed to clarify in the Widget Persistence PR, but haven't done yet. There was discussion about trying to reference count both in Python and JS (it's in the PR).
Kyle Kelley
@rgbkrk
Sep 24 2014 19:47
Screen Shot 2014-09-24 at 2.46.14 PM.png
I really wish there was a way to publish straight from tmpnb
Min RK
@minrk
Sep 24 2014 19:47
oh lord
Jonathan Frederic
@jdfreder
Sep 24 2014 19:47
but @minrk I agree, that's why I had originally designed the persistence to only persist visible things
Min RK
@minrk
Sep 24 2014 19:47
I still think that's a much better way to go
Kyle Kelley
@rgbkrk
Sep 24 2014 19:47
Yeah, I'm still scoping things
Jonathan Frederic
@jdfreder
Sep 24 2014 19:47
In fact, I think the current state of that PR, it's only persisting visible things
Min RK
@minrk
Sep 24 2014 19:48
walk cell outputs, visit views, only persist models that you hit on the way by
Jonathan Frederic
@jdfreder
Sep 24 2014 19:48
visible = display(w)
even if the view itself is null
Min RK
@minrk
Sep 24 2014 19:48
that's fine
Jonathan Frederic
@jdfreder
Sep 24 2014 19:48
but it just means the widget is associated with atleast one cell
Thomas Kluyver
@takluyver
Sep 24 2014 19:48
Is the only case we have of a viewless model the link widget?
'cause if widgets are disabled, we don't need to preserve links between them
Min RK
@minrk
Sep 24 2014 19:49
Persisting all model state in the notebook document is like persisting the kernel namespace: It makes perfect sense, is super useful, and is out of scope.
Jonathan Frederic
@jdfreder
Sep 24 2014 19:49
That we have in IPython, yes.
Thomas Kluyver
@takluyver
Sep 24 2014 19:49
do we know of other cases of viewless models?
Jonathan Frederic
@jdfreder
Sep 24 2014 19:50
I think @jasongrout uses them in his three.js
widget
Jessica B. Hamrick
@jhamrick
Sep 24 2014 19:50
Is there a way to test with casper whether a dialog has been shown or not?
Min RK
@minrk
Sep 24 2014 19:51
an alert, or an HTML dialog?
I think there's a wait_for_selector you can use
Jessica B. Hamrick
@jhamrick
Sep 24 2014 19:52
HTML dialog, from base/js/dialog
Jessica B. Hamrick
@jhamrick
Sep 24 2014 19:52
Cool, thanks that looks like what I want
Jonathan Frederic
@jdfreder
Sep 24 2014 19:53
g2g, will be back after lunch
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 20:41
persisting an output image in the scope but not the value of a slider?
Jonathan Frederic
@jdfreder
Sep 24 2014 20:53
No that is within the scope, I think @minrk 's just arguing about persisting the value of a slider you can't see (for example).
Thomas Kluyver
@takluyver
Sep 24 2014 20:56
if a slider lands in the notebook but cannot be seen, is it in fact a slider?
Jonathan Frederic
@jdfreder
Sep 24 2014 20:56
HAHA
Thomas Kluyver
@takluyver
Sep 24 2014 20:57
philosophical musings aside, I think it's only a slider if there's a visible element
otherwise it's just a number in an interval
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 20:57
ok, what about the link?
Jonathan Frederic
@jdfreder
Sep 24 2014 20:57
Or a JS link
It sounds like @minrk and @takluyver are < 0 on there even being a JS link widget
I'm +1
Thomas Kluyver
@takluyver
Sep 24 2014 20:58
aren't the widgets disabled on load anyway? So persisting a link widget is superfluous
Jonathan Frederic
@jdfreder
Sep 24 2014 20:58
Well, they aren't disabled with the changes
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 20:58
that is the whole point.
Jonathan Frederic
@jdfreder
Sep 24 2014 20:58
Instead a broken link wdiget is displayed next to them
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 20:58
I want to have things like this in the notebook.
http://bokeh.pydata.org/docs/gallery/color_scatter.html
Interaction based on JS links between widgets
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:00
yeah, the chain broken is to say that there is no backend. But the JS-wiring can persist.
Jonathan Frederic
@jdfreder
Sep 24 2014 21:00
Yup
Min RK
@minrk
Sep 24 2014 21:00
Why is that link a new model, and not two views referring to the same model?
what does the extra model do?
Thomas Kluyver
@takluyver
Sep 24 2014 21:00
doing that within the widget architecture seems wrong, anyway
you can display html+js and set up arbitrary connections between things on the JS side
widgets are specifically for when a model needs to be synchronised with the kernel
if it doesn't need to go via the kernel, why use the widgets in the first place?
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:02
To allow the user / who does not write javascript / to put it together
Thomas Kluyver
@takluyver
Sep 24 2014 21:02
is that a haiku?
:P
but the user needn't write JS to do display(foo)
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:03
:clap:
Thomas Kluyver
@takluyver
Sep 24 2014 21:03
someone needs to write JS to implement the stuff, but that's true for custom widgets too
nasty though JS is, I'd rather tell people to write it than provide a baroque framework to do everything people want to without writing it
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:05
A Link widget, having the same interface as the traitlets.link is a very common case.
Thomas Kluyver
@takluyver
Sep 24 2014 21:05
(I am very slightly exaggerating my position here, but only slightly - Min and I discussed this over lunch, and it sounds like there's a scary amount of new complexity that's trying to make its way into core IPython)
I also have concerns about how many syncing things we have
sync is hard, and we're doing it in four places: models sync frontend views, widgets sync kernel to frontend, and we have our own links to sync models on both the frontend and the kernel
this seems bad
Min RK
@minrk
Sep 24 2014 21:07
There's a major difference: the Python link has no model, it adds symmetric references in two existing models. There's nothing extra to persist.
Thomas Kluyver
@takluyver
Sep 24 2014 21:07
yes
but on both the frontend and the kernel, I wonder if we could better use the idea of models - i.e. store a value in one place, rather than duplicating it and keeping them in sync
Jonathan Frederic
@jdfreder
Sep 24 2014 21:08
How is a hastraits not a model?
The backbone "model" is just a set of keys/values
Thomas Kluyver
@takluyver
Sep 24 2014 21:09
(the Python link is not a HasTraits)
Min RK
@minrk
Sep 24 2014 21:09
link(a, b) connects the a model to the b model. The link itself has no model, there is no extra HasTraits object.
Jonathan Frederic
@jdfreder
Sep 24 2014 21:09
Ahhh I see what you're saying
Min RK
@minrk
Sep 24 2014 21:09
It registers on_change callbacks and can be discarded immediately. The only reason there's an object at all is an easy way to disable the link
Jonathan Frederic
@jdfreder
Sep 24 2014 21:09
link(a, b) -> just a, b exist. JS link a, b -> JS a, b, and c exist
Thomas Kluyver
@takluyver
Sep 24 2014 21:10
yep
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:10
fig = scatter(x,y)
zoom = ZoomWidget()
buttons = ToggleButtons(values=OrderedDict([('zoom', zoom), ('pan', pan), ('boxzoom', boxzoom), ('None', None)]))
link((buttons, 'value'), (fig, 'interaction'));
And you have the bokeh example.
Thomas Kluyver
@takluyver
Sep 24 2014 21:10
and my ideal: link(a, b) -> only a exists, b is a reference to a ;-)
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:10
in the traitlets case, link also returns an object
Min RK
@minrk
Sep 24 2014 21:11
but it has no model
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:11
indeed, no data
Min RK
@minrk
Sep 24 2014 21:11
the object it returns is just convenience for enabling unlinking
destroying the link object has no effect on the linking of the models
so destroying the link object js-side should have no effect on the linked A,B models
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:12
The example above could persist in nbconvert. I think that it is valuable.
Thomas Kluyver
@takluyver
Sep 24 2014 21:12
lots of things are valuable, but it sounds like making that persist adds a lot of extra complexity to the notebook format
also, the point of Bokeh versus something like d3 is that interaction can fetch data from the server
which can't be persisted to a static export
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:14
Sure. We would have the broken link icon in the corner. Only local interaction remains for sure.
What is the added complexity exactly. Is it memory leaks?
Min RK
@minrk
Sep 24 2014 21:15
models without views are not part of the document - they are part of the runtime state of the javascript
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:15
meaning having link widget models and what they reference hanging around forever?
Min RK
@minrk
Sep 24 2014 21:15
the notebook document is only the document state
so any models js-side that are not displayed should not survive
Thomas Kluyver
@takluyver
Sep 24 2014 21:16
if you don't need to persist models without a view, then widgets can be stored where they're displayed in the document
Min RK
@minrk
Sep 24 2014 21:16
Persisting absolutely everything in every widget model is like persisting the kernel's interactive state - it's clearly useful, but I don't think it's in scope for the document format
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:17
I guess that if this model had a trivial view, calling display would make it persistent in what you propose.
Min RK
@minrk
Sep 24 2014 21:17
it would
and the link shouldn't have a view :)
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:18
:worried:
Min RK
@minrk
Sep 24 2014 21:18
To sensibly persist the 'right' models in javascript, with any other indicator than a currently-displayed view, would require strict refcounting and garbage collection
i.e. make sure you delete or close all your Widget objects kernel-side, or they might get saved in the document!
When the current model of the notebook is very clear: What you see is what you save
Thomas Kluyver
@takluyver
Sep 24 2014 21:19
WYSIWYS ;-)
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:19
:)
Min RK
@minrk
Sep 24 2014 21:19
I think preserving that idea is worth making some things harder to implement
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:19
I see that the two widgets are linked
Jonathan Frederic
@jdfreder
Sep 24 2014 21:20
hmmm campus wifi took a dump
playing catch up..
Min RK
@minrk
Sep 24 2014 21:20
A trivial view is a little ugly if that's the only way you can do it, but it's not nearly as bad as persisting all models to the document
do models have backrefs (i.e. can you see models referring to this)?
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:22
@minrk, in general, we agree that we should pay more attention to the life cycle. I I have a lot of individual plot items that are widgets, it became critical to clean things when deleting items.
Jonathan Frederic
@jdfreder
Sep 24 2014 21:23
@minrk models have refs to their views and the views to the models
but models don't have a notion of parent
just children
Min RK
@minrk
Sep 24 2014 21:23
ok
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:23
views have references to their parent views
Jonathan Frederic
@jdfreder
Sep 24 2014 21:24
^ true
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:25
I have an idea that might make you happy. If we create a notebook-level widget area. we could display the links there by default - and fall back to the idea that non-displayed widgets are not persisted.
Thomas Kluyver
@takluyver
Sep 24 2014 21:26
hmmm
Jonathan Frederic
@jdfreder
Sep 24 2014 21:27
We could also display views with the links, the link's view would be cause a little link notifier to be rendered next to the view's of the linked models
Thomas Kluyver
@takluyver
Sep 24 2014 21:27
the notebook-level widget area seems like the global model store under another name
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:27
there is notebook-level metadata
and cell-level metadata
Thomas Kluyver
@takluyver
Sep 24 2014 21:27
there is, but it's metadata
widget models aren't meta ;-)
I guess in some sense if you link different widgets, those connections are metadata, but they're metadata about the widgets, not about the notebook
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:31
Another way to solve the memory leak issue is, when loading the notebook, if there is a connected backend and some widget models don't have a backend counterpart, violently kill them.
Thomas Kluyver
@takluyver
Sep 24 2014 21:33
any solution that involves our implementing any kind of garbage collection is probably wrong
(I hope)
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:33
Independently, I am still trying to get my head around how to clean up after backbone, to avoid zombie models and views. It seems that stopListening does not unregister handlers registered with on
and one think that is a bit crazy, is that anyone registering to a 'destroy' event in another way than with 'once' will make the corresponding model become a zombie.
Thomas Kluyver
@takluyver
Sep 24 2014 21:36
OT: zombie models is one of those phrases that sounds so much more interesting out of context
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:42
@takluyver I agree on garbage collection / ref counting.
Thomas Kluyver
@takluyver
Sep 24 2014 21:43
but FWIW, I'm not so worried about that, at least at the moment - that seems more like an implementation question
my concerns are about architecture and trying to limit the scope of what we're doing
Min RK
@minrk
Sep 24 2014 21:44
And since persisting all models seems so clearly wrong, we need a very simple rule for what models to actually persist.
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:45
In that regard, calling display with some trivial view for link is an "ok" solution to say that this guy must persist
Min RK
@minrk
Sep 24 2014 21:45
Given the scope of the notebook document, restricting it to displayed models seems logical. If there is a similarly simple rule to select which models to include in the document, that would be fine, too.
Thomas Kluyver
@takluyver
Sep 24 2014 21:49
btw @jdfreder - Min and I were discussing the relationship between comm targets and widget models some more
Jonathan Frederic
@jdfreder
Sep 24 2014 21:49
Nice
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:49

Event if you restrict to displayed stuff and don't allow for links to have a view, one can always do

x = Link((slider1, 'value'), (slider2, 'value')); x._view_name = 'LatexView'
display(x)

and x persists.

Jonathan Frederic
@jdfreder
Sep 24 2014 21:49
and revelations?
@SylvainCorlay true
because the default view would be used
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:50
hum, no the one of LaTeX
default views are not registered
Jonathan Frederic
@jdfreder
Sep 24 2014 21:50
oh whoops
didn't scroll over
Thomas Kluyver
@takluyver
Sep 24 2014 21:51
comm targets/widget models: we think it may make sense for them to be two separate fields, so all widgets have comm target 'Widget' (or suchlike name), and there's just one entry for that in the comm target registry. Then the registry of widget models is completely separate.
Jonathan Frederic
@jdfreder
Sep 24 2014 21:51
where is the PR that registers default views?
@takluyver that sounds fine
like a good sln
Thomas Kluyver
@takluyver
Sep 24 2014 21:51
rather than the current state, where every widget model is registered in both the widget model registry and the comm target registry
Jonathan Frederic
@jdfreder
Sep 24 2014 21:51
yes
Thomas Kluyver
@takluyver
Sep 24 2014 21:51
great
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:51
open, but I think that we agreed with @takluyver not to register default views
Jonathan Frederic
@jdfreder
Sep 24 2014 21:52
but in this case it would be nice
Thomas Kluyver
@takluyver
Sep 24 2014 21:52
(since that's a bigger change, I'll do that in a separate PR)
Jonathan Frederic
@jdfreder
Sep 24 2014 21:52
because it would allow for things like the JS link to be persisted
in the way you show above
minus the line that sets the view name
Thomas Kluyver
@takluyver
Sep 24 2014 21:53
@SylvainCorlay if there's a reason for a view to exist on the JS side, I'm not against it. Though I still feel a bit uncomfortable about views that aren't really views.
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:53
yes, I think we agree
Widget should have no view
Thomas Kluyver
@takluyver
Sep 24 2014 21:53
yep
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:53
and Link too
Thomas Kluyver
@takluyver
Sep 24 2014 21:53
I think we might try to discuss this some more at the dev meeting tomorrow.
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:54
but the hack above makes a link persistent.
Thomas Kluyver
@takluyver
Sep 24 2014 21:54
oh, I thought you were saying Link should have a view
:confused:
Jonathan Frederic
@jdfreder
Sep 24 2014 21:54
no that was me saying that we could do that
Thomas Kluyver
@takluyver
Sep 24 2014 21:54
oh, I see
set a view for specific links if you want them to persist
Jonathan Frederic
@jdfreder
Sep 24 2014 21:54
to make the hack, less for the user
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:54
x = Link((slider1, 'value'), (slider2, 'value'))
x._view_name = 'LatexView'   # haha, got you
display(x)  # now my link is persistent
Jonathan Frederic
@jdfreder
Sep 24 2014 21:55
@SylvainCorlay just as an FYI, HTMLView would be best :)
it's just a div
nothing more
Thomas Kluyver
@takluyver
Sep 24 2014 21:55
why not just display(Javascript("link thing 1 and thing2;"))
display(Javascript("link thing 1 and thing2;"))
Jonathan Frederic
@jdfreder
Sep 24 2014 21:55
^
the JS link could be rewritten
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:56
because the user does not want to write javascript
who does.
Jonathan Frederic
@jdfreder
Sep 24 2014 21:56
so it was just class with a JS repr
Thomas Kluyver
@takluyver
Sep 24 2014 21:56
you could generate that much JS fairly trivially
and I just mean calling some method that's already implemented in the frontend
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:57
We might not want to allow Javascript
besides the already proposed widgets
Thomas Kluyver
@takluyver
Sep 24 2014 21:57
in that case, none of the fancy widgets that benefit from Link would work either
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 21:58
well not if it is pre-installed
or I don't see what you mean
Thomas Kluyver
@takluyver
Sep 24 2014 21:59
things like your bokeh-like plots will need third party JS to run, no?
that's never going to be built into IPython
or Jupyter
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 22:00
what I mean is that in the notebook server that I run for my users, my own widgets are not considered third party. But I don't necessarily want to allow them to write javascript
Thomas Kluyver
@takluyver
Sep 24 2014 22:01
oh, I see
well, maybe linking should be done by a custom message sent over one of the widget's comm channels
it seems wrong that it requires a new Model and a new Comm (which presumably never sends more than one message) to link two existing widgets
Sylvain Corlay
@SylvainCorlay
Sep 24 2014 22:13
How would you persist that link then?
besides, things like the button don't really have a state. It is still convenient to inherit from DOMWidget for all the rest
Thomas Kluyver
@takluyver
Sep 24 2014 22:18
yeah, that's another thing that troubles me - we talk about widgets as if they're all stateful, synced models, but the most basic example of all is not.
as for the link, I guess there would be some kind of widget metadata that said 'this field is linked to that field on that model'
Thomas Kluyver
@takluyver
Sep 24 2014 22:28
@jdfreder you know there's a cell in the 'Using interact' example notebook that is not valid in any version of Python
it uses function annotations, which are Python 3 only, with the Python 2 print statemetn
will it conflict with anything if I go through and make that notebook Python 3 compatible?
Jonathan Frederic
@jdfreder
Sep 24 2014 22:31
Not anymore, thanks :)
Thomas Kluyver
@takluyver
Sep 24 2014 22:31
great
Jonathan Frederic
@jdfreder
Sep 24 2014 22:32
The widget doc changes I had floating around got merged yesterday, so if there's anything else you want to clean-up or add, feel free to
Thomas Kluyver
@takluyver
Sep 24 2014 22:32
cool, I'll keep an eye out for such things
Thomas Kluyver
@takluyver
Sep 24 2014 22:52
It looks like Comm.del will never get called, because the comm manager keeps a reference to the comm until it's closed
Comm.__del__
Thomas Kluyver
@takluyver
Sep 24 2014 23:08
@jdfreder it looks like, if a Comm object is instantiated in a kernel that doesn't support it, it will fail silently rather than raising an error
is that deliberate?
Jonathan Frederic
@jdfreder
Sep 24 2014 23:08
yes
Thomas Kluyver
@takluyver
Sep 24 2014 23:09
why? It seems like, if it can't open, it should raise
Jonathan Frederic
@jdfreder
Sep 24 2014 23:12
Looking for it, one sec
Jonathan Frederic
@jdfreder
Sep 24 2014 23:17
ipython/ipython#6151
Tests were failing when the kernel didn't exist
Is this what you're talking about : jasongrout/ipython@c1f4e57 ?
Thomas Kluyver
@takluyver
Sep 24 2014 23:19
that's at least part of it
Jonathan Frederic
@jdfreder
Sep 24 2014 23:20
is this the rest: jasongrout/ipython@4ea8a40 ?
Thomas Kluyver
@takluyver
Sep 24 2014 23:20
yep
that sounds like a problem with the tests, though. Since a Widget needs a kernel and a frontend, I think it should throw an error if you instantiate it in the terminal
then we just mock that out in the tests that check widget creation for interact
those are the only relevant ones, right?
Jonathan Frederic
@jdfreder
Sep 24 2014 23:21
You can try reverting them, the tests will fail, but I don't remember why those test were failing
Those are the only changes I made
Thomas Kluyver
@takluyver
Sep 24 2014 23:22
I am ~reverting them, in the process of changing comm_manager to belong to a kernel, not a shell
Jonathan Frederic
@jdfreder
Sep 24 2014 23:22
Sounds good
ping me when you find the root cause of the test failures
Jason Grout
@jasongrout
Sep 24 2014 23:23
Wow, I'm just seeing the discussion here. It's quite entertaining :)
Jonathan Frederic
@jdfreder
Sep 24 2014 23:23
lol
Thomas Kluyver
@takluyver
Sep 24 2014 23:23
if I mock out DummyComm.open() like we've already mocked .send() and .closed(), the tests seem to be OK
Jonathan Frederic
@jdfreder
Sep 24 2014 23:23
@jasongrout which one?
This message was deleted
@takluyver yay
Jason Grout
@jasongrout
Sep 24 2014 23:35
did I push out my MockComm object?
for doing widget testing?
Jason Grout
@jasongrout
Sep 24 2014 23:47
okay, finished reading. So display(link(...)) is a euphemism for persist_widget(link(...))
Thomas Kluyver
@takluyver
Sep 24 2014 23:48
well, that's a possibility
Jason Grout
@jasongrout
Sep 24 2014 23:48
@takluyver - the problem with display(javascript("link models.fields a.field1 to b.field2")) is: when is that js run?
If it's part of the widget infrastructure, the two models are automatically instantiated before the link is made.
if it's just random js, then somehow the widgets need to be created before the js is run.
if I do display(javascript("...")), is that javascript run, for example, with a static page?
Thomas Kluyver
@takluyver
Sep 24 2014 23:49
yuck, getting the ordering right seems like it's going to introduce a lot of extra complexity no matter how it's done
Jason Grout
@jasongrout
Sep 24 2014 23:50
A problem with proxy references to other models. That means that basically one model is the parent, the other is the child. However, links are much more egalitarian.
a change to either model will propogate to the other.
Thomas Kluyver
@takluyver
Sep 24 2014 23:52
but if the link is itself is a model (which I'm far from convinced about), it's a child of both
Jason Grout
@jasongrout
Sep 24 2014 23:53
no, it's not a child. It's sort of a parent of both.
it hooks up two even handlers, that's it.
Thomas Kluyver
@takluyver
Sep 24 2014 23:53
but it has to be created after the other two
Jason Grout
@jasongrout
Sep 24 2014 23:53
the model state is just there to say that if the models are reanimated, then they should be linked together again.
Thomas Kluyver
@takluyver
Sep 24 2014 23:54
thus it's a child. I'm a biologist, trust me ;-)
Jason Grout
@jasongrout
Sep 24 2014 23:54
it will be created after the other two. children are created before parents :)
Or rather, a model who has references to other models obviously needs to create those other models first.
uh, maybe we're saying the same thing.
Yes, I guess from biology, my children have references (well, copies) of my and my wife's DNA
Thomas Kluyver
@takluyver
Sep 24 2014 23:55
yep, DNA is pass by value :P
I'm still not convinced that link should have a separate model and comm, though
Jason Grout
@jasongrout
Sep 24 2014 23:56
But it's a parent, in that if we try to create a link, then it first creates the other two models, then links them together. Parents create children :)
Sure, but we do want the link to persist in a static page, so the info should be stored somewhere.
It's really metadata about the widgets and their relationships.
Perhaps the functionality can be folded into the widget manager somehow.
Thomas Kluyver
@takluyver
Sep 24 2014 23:59
does someone have time to look into implementing link as metadata on widgets, created by sending a custom message on one of the existing widget's comms?
Jason Grout
@jasongrout
Sep 24 2014 23:59
that sounds messier, though.