[IPython-dev] Camera widget
Thu Feb 27 08:34:47 CST 2014
On 2/27/14 6:53 AM, Doug Blank wrote:
> On Thu, Feb 27, 2014 at 12:39 AM, Jason Grout
> <email@example.com <mailto:firstname.lastname@example.org>> 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
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