These are chat archives for ipython/ipython

30th
Sep 2014
Nicholas Bollweg
@bollwyvl
Sep 30 2014 13:32
@jasongrout right, and you can keep going with css and fonts, etc
Jason Grout
@jasongrout
Sep 30 2014 14:09
I think you can do css with the text plugin too; you just give the .css or .html extensions, if I understand correctly
Jason Grout
@jasongrout
Sep 30 2014 14:16
ah, I see the difference. Those plugins do more than just load a string. I agree that it would be nice to have an html plugin that actually renders a dom node, which you can then clone when you require it.
Jason Grout
@jasongrout
Sep 30 2014 14:41
just found this: https://github.com/jrburke/requirejs/wiki/Plugins (which lists an html plugin)
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:12
hello
Thomas Kluyver
@takluyver
Sep 30 2014 23:14
hi sylvain
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:14
thanks for helping on saturday !
I am glad I could have Carlos in NY.
I was about to add a couple of more thoughts in the thread of the link widget, but thought you guys might still be around
Thomas Kluyver
@takluyver
Sep 30 2014 23:22
it's only 4.20 over here ;-)
we're not that lazy!
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:23
lol, this is not what I meant - 720 here and empty openspace
Thomas Kluyver
@takluyver
Sep 30 2014 23:24
:)
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:24
ok, then lets argue on the document model :)
Jonathan Frederic
@jdfreder
Sep 30 2014 23:25
ooo sounds fun
:D
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:25
Widget views, which are linked to a cell have a touch method which essentially makes a call to save_changes and passes the callback to route stderr and stdout to the right cells. However, if the call to save_changes is made in the model, and does not originate from a view or cell in particular (or very remotely), there is no outlet for stderr and stdout.
Thomas Kluyver
@takluyver
Sep 30 2014 23:26
heck, I'm going to need some 4.20, IYKWIM
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:26
:+1:
Jonathan Frederic
@jdfreder
Sep 30 2014 23:26
lol
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:27
this speaks for a notebook-level stderr outlet
We currently tend to have rather thick models and thin views in our visualization widgets and models respond to events of other models, which are not attached to a specific view.
we could probably try to pass optional callbacks from function to function to have stderr errors printed in the right cell, but it can be rather remote.
Jonathan Frederic
@jdfreder
Sep 30 2014 23:29
And there's also a possibility that the change made to the model is not triggered by a cell at all. i.e. It may be triggered by a timeout or a document event.
(not necessarily in Sylvain's case)
Thomas Kluyver
@takluyver
Sep 30 2014 23:29
which side is touch on? I'm confused because views are frontend, and stderr happens in the kernel
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:30
(not in my case as of now)
on the js side
only in views
views are linked to cells
touch calls this.model.save_changes(routing_callbacks)
Thomas Kluyver
@takluyver
Sep 30 2014 23:31
so when it gets some stderr/stdout, how does it know that it's associated with a particular widget?
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:31
what do you mean?
Jonathan Frederic
@jdfreder
Sep 30 2014 23:31
Via the callbacks associated with the message id
the callbacks are generated by the view since the view knows of the cell
Thomas Kluyver
@takluyver
Sep 30 2014 23:32
the reason for this cell is to route std* caused by widget callbacks to the cell where the view is, not the last cell that ran, right?
this *call
Jonathan Frederic
@jdfreder
Sep 30 2014 23:32
yes
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:33
but if save_changes is called by the model, no cell
Thomas Kluyver
@takluyver
Sep 30 2014 23:33
oh, so the parent is the comm message that triggered that, I guess
and the notebook keeps track of comm messages and the cells to which output from those should be directed?
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:37
Example: two figures use the same scales. A change of the data of an item displayed in a first figure triggers a change of the domain of the scale, which then impacts the other figure. We have a series of model front-side events. Propagating the cell from which the chain originated can be rather difficult.
Jonathan Frederic
@jdfreder
Sep 30 2014 23:37
Or impossible - The problem here is that the changes are events not driven by the backend (not my any comm messages nor user interaction).
(in some cases)
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:38
like a live feed of data.
It happens very easily, even in a notebook with a few plots that use the same scales.
Thomas Kluyver
@takluyver
Sep 30 2014 23:43
would you two rather talk between yourselves, without me getting in the way? I think I'm having trouble understanding how we achieve the current state, let alone the problems with that.
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:45
I think that it is very difficult to convey what I am trying to say without being very specific about what we are doing and giving a very simple concrete example.
Thomas Kluyver
@takluyver
Sep 30 2014 23:48
ok
I'm happy to look at an example, but if you and Jon can work this out quicker, go ahead
Jonathan Frederic
@jdfreder
Sep 30 2014 23:51
We weren't trying to work anything out, we just brought this up because it speaks for notebook level std* and persistence.
Thomas Kluyver
@takluyver
Sep 30 2014 23:52
notebook level std*?
I'm not even sure what that would look like
Sylvain Corlay
@SylvainCorlay
Sep 30 2014 23:55
yeah, I don' t know if we should make it visible for anything else than debugging purpose.
or directed to console.log
Currently, print statements in callbacks registered to traits changes coming from a model just disappear.
Jonathan Frederic
@jdfreder
Sep 30 2014 23:57
:poop:
disappearing stdout sucks