[IPython-dev] Implementing inline images in a kernel

Gabriel Becker gmbecker at ucdavis.edu
Wed Jan 29 04:50:48 EST 2014


Brian,

Apologies if anything I say below is no logner true. I'm in the process of
porting the modified version I use to the latest release, but I haven't
finished yet so I'm lagging a bit behind.

On Wed, Jan 29, 2014 at 12:08 AM, Brian Granger <ellisonbg at gmail.com> wrote:

> On Tue, Jan 28, 2014 at 8:30 PM, Gabriel Becker <gmbecker at ucdavis.edu>
> wrote:
> > Is there any reason a kernel (or metakernel if you want to call it
> something
> > else) cannot know how to send code to more than one evaluator? It seems
> to
> > me that the magics themselves are proof that this could easily be
> achieved
> > in (I)Python. It seems like it should be pretty straightforward to push
> that
> > dispatch up from the "now evaluate our python code" step into a new
> > intermediary "check the language and evaluate accordingly" step.
>
> With a little bit of thinking...
>
> To do a sucky job it wouldn't be hard. Do just as you say, make
> everything work through an in process blocking API passing simple data
> structures from the evaluators to the "routing kernel"
>

I'm not surprised it is more complicated to do something right than just
take the naive approach :)


>
> To do a good job and have everything (tab completion, tooltips, async
> output, widgets, etc.) work is extremely difficult and would require
> very careful asynchronous routing logic using all of our zeromq
> sockets from the backend "evaluators" to the main "routing kernel".
>

At least some, if not all, of things already don't work with the full cell
magics (at least not the %%R magic on my machine). I know that for some of
the issues (tab completion, tooltips) that is because technically it is
python code, but in some sense that is the whole issue.


> Not to mention that if all of these evaluators are running in process,
> they will actively block one another. What happens if your user tab
> completely in a logo cell while a VisualBasic one is running?


As above, the magics (or at least the R one) already blocks tab completion
from other cells while running.


> How do
> you route that? What happens if your user drags a slider in a Java
> backed IPython Widget? How do you route that? What if the entire
> backend is blocked by code running in another evaluator? What if some
> of these objects are shared in different evaluators? Which one gets to
> handle output at any given moment in time?
>

I admit that I don't know too much about the workings widget stuff. It
seems very cool, but we've chatted previously about why its conceptual
model doesn't meet my needs so I haven't delved into it too deeply (also
i'm extremely busy and have been for a while).



>
> People tend of think of the messaging in IPython as being simple
> request/reply. Browser sends code to the kernel, kernel replies with
> output. Nothing can be further from that. Message can be sent
> bidirectionally at any moment in time by either party. The
> widgets/comm stuff use that all over the place.
>
> Summary: if you are going to want a kernel with all the features that
> IPython offers (not just blocking code execution) don't try to build
> this type of "routing kernel" - build kernels that run code in one
> language.
>

I guess the issue is probably that because I use (a modified version of)
IPython Notebook for R analyses, I've been using it without all this
"extra" stuff the whole time. Maybe when I find a handful of hours
somewhere (Ha!) I'll put together an R kernel and see what the fuss is
about.

Anyway, thanks for the detailed response to my naive musings.

~G


>
> > Signalling the language of a particular code cell to the user could be
> done
> > with a small icon or other indicator in the page.
>
> Yes, that is perhaps the only trivial part...
>
> Cheers,
>
> Brian
>
> > I had toyed with the idea of building such a metakernel myself (why
> build an
> > R kernel when I could build a kernel for truly multilanguage notebooks)
> but
> > I never found the time.
> >
> > ~G
> >
> >
> > On Tue, Jan 28, 2014 at 6:17 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>
> >> Jason, to illustrate:
> >>
> >> Idée intéressante
> >>
> >> Но я думаю, что есть некоторые проблемы
> >>
> >> Ben kullanıcılar için çok kafa karıştırıcı olacağını düşünüyorum
> >>
> >> ほとんどの人は、一度に1つの言語を追跡することができます
> >>
> >> מספר שפות היו שמות עומס קוגניטיבי משמעותי על משתמשים עם יתרון ברור קטן
> >>
> >> French, Russian, Turkish, Japanese, Hebrew. Have fun translating :)
> >>
> >> On Tue, Jan 28, 2014 at 6:10 PM, Brian Granger <ellisonbg at gmail.com>
> >> wrote:
> >> >> What if we supported different kernels on a per-cell basis?  Then it
> >> >> would be similar to the %% magics.  There could be a number of
> kernels
> >> >> associated with a notebook, and the metadata on a cell would tell
> where
> >> >> to send the code and get output from?
> >> >
> >> > User's heads will already explode with the ability to change kernels
> >> > on the fly for an entire notebook. Allowing that for individual cells
> >> > would lead to a further explosion of UI complexity and cognitive load.
> >> > Obviously, anyone is free to build such a beast, but I can't imagine
> >> > that ever being within scope for IPython itself.
> >> >
> >> > Cheers,
> >> >
> >> > Brian
> >> >
> >> >> Thanks,
> >> >>
> >> >> Jason
> >> >>
> >> >> _______________________________________________
> >> >> IPython-dev mailing list
> >> >> IPython-dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >> >
> >> >
> >> >
> >> > --
> >> > Brian E. Granger
> >> > Cal Poly State University, San Luis Obispo
> >> > bgranger at calpoly.edu and ellisonbg at gmail.com
> >>
> >>
> >>
> >> --
> >> Brian E. Granger
> >> Cal Poly State University, San Luis Obispo
> >> bgranger at calpoly.edu and ellisonbg at gmail.com
> >> _______________________________________________
> >> IPython-dev mailing list
> >> IPython-dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
> >
> >
> > --
> > Gabriel Becker
> > Graduate Student
> > Statistics Department
> > University of California, Davis
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu and ellisonbg at gmail.com
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140129/d3bc0c49/attachment.html>


More information about the IPython-dev mailing list