[IPython-dev] Implementing inline images in a kernel

Doug Blank doug.blank at gmail.com
Wed Jan 29 15:44:06 EST 2014


On Wed, Jan 29, 2014 at 1:24 PM, Brian Granger <ellisonbg at gmail.com> wrote:

> > Calico interpreting whatever language shows the output intermittently
> > over the course of the 10 seconds, just like IPython running the
> > Python kernel. Calico doesn't "talk" to a Python backend... Calico
> > *is* Python, in a sense. And it is also Basic, Logo, etc. There isn't
> > one primary language talking to the others---there is just the thin
> > socket kernel talking to a specific language's eval function. But the
> > eval occurs in the "same space". Lower level calls to functions like
> > print() in the interpreted language's eval() inject messages to the
> > iopub stream. Even our Java works this way.
>
> Great, this is also how the %julia magic works. By having shared
> objects that can all access the same messaging layer, you co go a lot
> further. Asynchronous output (including rich) shouldn't be too bad.
> The important thing is that there be a common messaging API that all
> of the sub-kernels can access to send messages asynchronously. Tab
> completion might be a bit of a pain, but can probably be done with
> this approach as well.
>
> I think the widgets are going to be a bit more difficult. I think you
> will be able to get them working, but with some serious reinvention.
> What do I mean by that. We already have a relatively full set of
> Python widgets shipping with IPython 2.0. Other people will start to
> write 3rd party widgets for Python as well. But these use the IPython
> kernel implementation of the widget/comm infrastructure:
>
> https://github.com/ipython/ipython/wiki/IPEP-21%3A-Widget-Messages
>
> you will need to implement this layer in your main/sub kernels. The
> problem is that widgets in your kernels will need to use your layer
> for this. This means you will also have to re-implement the actual
> Python widgets to use your layer instead of the normal IPython one.
> You might be able to monkey patch things to get this stuff working,
> but it could be a serious amount of work. Over time, as the number and
> complexity of widgets grows, this will require a substantial effort to
> do.
>

Thanks for the link to that. This may not be an issue for us, because
Python is one of the languages we support. We should be able to re-use this
code. (There may still be issues, for example, we aren't using pyzmq (nor
any library based on C) but if it is just talking to a duck, we may be able
to be that duck). Other kernels may have a lot of work.


> > This is why I find some of the assumptions stated
> > confusing---insisting that "one language/one kernel" is the future
> > apparently misses some possibilities in design :) It may be that we
> > made unique design decisions. In any event, it appears that Calico
> > running scripts is very different in a fundamental way that IPython's
> > Python running the integrated Julia.
>
> There are two issues:
>
> * Can the meta kernel thing be done: depending on how it is designed,
> to some degree yes.
> * Does it make sense to create meta kernels: my own feeling is that it
> does not in general. Obviously, IPython, through cell magics does
> offer some of this in limited form. But we definitely don't have plans
> on trying to add things like tab completion+widgets to these cell
> magics. My main problem with meta kernels though is not technical, but
> conceptual. Most users, even very advanced ones, have plenty enough
> cognitive load when working with 1 programming language. To ask them
> to manage multiple languages in the same namespace is a huge ask that
> is probably DOA for all but the most advanced users.
>

We don't expect that most users will be using more than one programming
language. We just want to provide a choice to which one they do use. This
can be set at start time, so a user never even knows that their shell could
be changed to a different language, or that they could call a different
language during their processing.

I'm not sure what a "meta kernel" is. In Calico, there is no meta... it is
a flatspace. Perhaps it is better to just think of it as dynamically
changing the parser. In any event,  I have inline rich media working. I
fully expect that tab-completion and the widget interfaces will be two
things that we absolutely want to add. Tab-completion shouldn't be too bad
as all languages share a common object system. The widget interface may be
able to reuse the Python.... we'll see :)

On the topic of meta, it would be nice if the same magics could be used for
all kernels. What I mean is that it appears that shelling out to R, Bash,
and other kernels is done by the IPython kernel. We don't need to
reimplement shelling out to bash, but could rely on this layer to handle
those requests. But that is a topic for a different thread.

-Doug


>
> Cheers,
>
> Brian
>
> > I wonder what the best technical way to describe this difference is? I
> > guess that you had assumed some type of blocking behavior. Perhaps I
> > need a better way of describing how Calico operates. My question to
> > you is why does %julia block?
> >
> > -Doug
> >
> >> On Wed, Jan 29, 2014 at 12:14 AM, Doug Blank <doug.blank at gmail.com>
> wrote:
> >>> On Wed, Jan 29, 2014 at 3:10 AM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >>>>
> >>>> > That's interesting... IJulia using the Python VM... Then, this is
> very
> >>>> > similar to Calico. Because all of the languages share memory, I was
> able
> >>>> > to
> >>>> > put a global object in there. I have now written display(), HTML(),
> >>>> > Image(),
> >>>> > and Audio(), and all is working very well. HTML, Image, and Audio
> all
> >>>> > have a
> >>>> > specially named method (similar to Python's __rep__) that when
> called,
> >>>> > returns the dictionary of mime-types and strings, and display()
> sends
> >>>> > the
> >>>> > proper message. Demo to follow...
> >>>>
> >>>> That is absolutely similar to the Calico idea. But keep in mind,
> >>>> running Julia through the %julia magic will *never* allow things like
> >>>> the widgets or tab completion to work. Only the true native Julia
> >>>> kernel will allow that.
> >>>>
> >>>
> >>> Why can't the Julia-using-the-PythonVM magic use the widgets or tab
> >>> completion? What is the limitation?
> >>>
> >>> -Doug
> >>>
> >>>>
> >>>>
> >>>> > -Doug
> >>>> >
> >>>> >>
> >>>> >> Cheers,
> >>>> >>
> >>>> >> f
> >>>> >>
> >>>> >>
> >>>> >> --
> >>>> >> Fernando Perez (@fperez_org; http://fperez.org)
> >>>> >> fperez.net-at-gmail: mailing lists only (I ignore this when
> swamped!)
> >>>> >> fernando.perez-at-berkeley: contact me here for any direct mail
> >>>> >>
> >>>> >> _______________________________________________
> >>>> >> IPython-dev mailing list
> >>>> >> IPython-dev at scipy.org
> >>>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
> >>>> >>
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > 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
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140129/b63f30e2/attachment.html>


More information about the IPython-dev mailing list