Conversation
R/execution.r
Outdated
There was a problem hiding this comment.
Ok, I was going to argue that this should send a execution_reply but in python this also uses the display function :-/
But this then means that the kernel depends on the display package (due to the useage in sending plots) and the display package depends on the kernel (due to the actual sending of the display_data reply). I'm not sure if that's a problem in R.
There was a problem hiding this comment.
This is already the case - IRdisplay provides the display API, that I also want to make usable from the R magic in a Python notebook, so the same code works in both. However, it doesn't know how to actually display the data - it needs to be run by something that gives it a base display function to send the data. IRkernel does this. It's not very nice, but it seems to work.
I'm still not convinced that display_alternatives is necessary, though.
|
btw. i think that this is now independent from IRkernel/IRdisplay#3, right? so we can pull this in and bikeshed over the IRdisplay APIs the following weeks ;) |
|
Yes, I think so - I tested it without that PR (using #83). I also want to think a bit about repr APIs, though - I'm a bit confused as to why repr has a class, rather than just a set of methods returning string/raw vectors. |
let’s discuss this in IRkernel/repr#1 |
i think this should be the way everyone’s happy with.
depends on
IRkernel/IRdisplay#3’s functionIRkernel/repr (in order to display multiple alternative formats of one output, and to create those formats, respectively)display_alternativesandsorry for the mess of commits, i brought the notebooks up to date too. relevant changes should start here
this fixes #73 and lays foundations for #59 (by depending on repr)