[IPython-dev] Camera widget

Jason Grout jason-sage at creativetrax.com
Thu Feb 27 09:34:47 EST 2014

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?

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.

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)

>     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:

pic = yield c.take_pic()


More information about the IPython-dev mailing list