[IPython-dev] Camera widget
Doug Blank
doug.blank at gmail.com
Thu Feb 27 10:09:49 EST 2014
On Thu, Feb 27, 2014 at 9:34 AM, Jason Grout <jason-sage at creativetrax.com>wrote:
> On 2/27/14 6:53 AM, Doug Blank wrote:
> > On Thu, Feb 27, 2014 at 12:39 AM, Jason Grout
> > <jason-sage at creativetrax.com <mailto:jason-sage at creativetrax.com>>
> wrote:
> >
> > On 2/26/14 11:00 PM, Doug Blank wrote:
> > > Here is a puzzle: can you make a kernel-side script that will
> take a
> > > picture, *and* return it? It seems like you can't because the
> kernel
> > > can't handle receiving the image while at the same time run your
> code
> > > waiting for the message to come it. I guess you could do it with a
> > > non-blocking kernel? Yep, just tried it by putting our kernel in
> > > non-blocking mode.
> >
> > Can you elaborate on putting your kernel in non-blocking mode?
> >
> >
> > So in our kernel (ICalico), currently the only difference between
> > blocking and unblocking is whether the server waits for the thread
> > running the computation to finish (blocking) or not (non-blocking)
> > before sending an kernel idle message. In fact, I just exposed this
> > setting, so the user can control this. As a new user of IPython, I'm not
> > sure how this maps onto the IPython Python kernel's usage of
> > blocking/non-blocking.
> >
>
>
> Do you run each computation in a separate thread? Who manages the
> communication channels---do you send separately from each thread, or do
> you have a main thread coordinating all communication?
>
Yes, each bit of computation runs in a (currently singleton) thread. That
way, if we receive an interrupt (control+c) we just kill that thread.
Usually, we .Join() on that thread to make it blocking. If you don't issue
a .Join() then the kernel can receive another command.
What we do not have yet is a way of *managing* multiple threads of
computation running simultaneously. So, you'd want to keep the outputs
going to the right place (maybe not possible in our kernel), and be able to
interrupt all running threads (possible). Maybe that is all that is needed?
(I just realized that we could have some magics that handle these cases...
run cell in a thread, return the thread id, cancel a thread, etc. You would
effectively say: run this cell in the background. I could think of some use
cases for that (we program a lot of robots). I guess you could do this in
the IPython Python kernel too by just manually creating threads).
>
> I think it would be interesting to explore non-blocking computation
> threads. I've explored this in the past with Sage in interacting with
> widgets (trying to get it so that I could move a slider to update a
> value in an ongoing computation in real time), and my experiments gave
> reason to hope it might work out.
>
Oh, right. I was thinking about doing that demo today (we have a tone
generator that sends the wave data to the sound system). But you are right
that that wouldn't work (without running it in a thread).
>
> In the current IPython model, I think you have to write non-blocking
> stuff in a callback-oriented manner: You do a short computation and then
> set up callbacks to respond to events. I essentially do this in my
> sagecell camera widget demo (http://sagecell.sagemath.org/?q=htlcsf)
>
Yep. We stole your code :) and made a built-in CameraWidget in Calico.
http://nbviewer.ipython.org/urls/bitbucket.org/ipre/calico/raw/master/notebooks/Camera%20with%20Calico.ipynb
Our system is still wildly under development and code is rough; here is the
relevant thread code:
https://bitbucket.org/ipre/calico/src/master/Source/Calico/ZMQServer.cs?at=master#cl-878
It would be cool someday to have Calico as a viable kernel in Sage. (Of
course, there are a lot of good kernels under development. We just got F#
working as one of our languages, and some people might be interested in
that reason alone.)
-Doug
>
>
>
>
>
>
>
> >
> > I suppose what you bring up a is more general problem---I probably
> can't
> > adjust a slider while some user code is executing and see the result
> in
> > the code, for example.
> >
> >
> > That is what it looks like to me.
> >
> >
> > On the other hand, if the comm infrastructure supported a blocking
> mode,
> > where a message could be sent and then we block and wait for a
> reply, we
> > could do your picture-taking example. Just ask the camera to take
> the
> > picture, and then wait for the reply, just like asking for raw input
> and
> > waiting for a reply.
> >
> >
> > That sounds generally useful! In that manner, we can *programmatically*
> > press the "Take Pic" button, wait for an variable update (or some
> > message), handle the message, and then return the results. I'm not sure
> > exactly how to implement it, but it sounds useful :)
>
> Again, I essentially do this in my sagecell link, but it has to be
> callback-driven. It would be nice if it could be written in coroutine
> style using yield, for example:
>
> c=CameraWidget()
> pic = yield c.take_pic()
> display(pic)
>
> Jason
>
> _______________________________________________
> 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/20140227/3d2c243e/attachment.html>
More information about the IPython-dev
mailing list