Hi,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
&gt; Thinking of wilder ideas, it might even be possible to share a common<br>
&gt; interpreter (with which I mean the code running in the second process). Such<br>
&gt; that only the way of controlling it is different. Whether one uses IPython<br>
&gt; or IEP, under the hood it&#39;s the same thing. There are of course some<br>
&gt; fundamental differences between IEP and IPython (for example IEP needs to be<br>
&gt; able to run a selection of code), but who knows?<br>
<br>
</div>Not wild at all, in fact all the recent work from the Google SoC<br>
students, as well as the stuff Brian, Evan and I are currently working<br>
on, goes precisely in that direction. We&#39;re basically specifying an<br>
&#39;IPython protocol&#39; as described here:<br>
<br>
<a href="http://ipython.scipy.org/doc/nightly/html/development/messaging.html" target="_blank">http://ipython.scipy.org/doc/nightly/html/development/messaging.html</a><br>
<br>
That messaging spec fully defines how to interact with an ipython<br>
kernel that has all the goodies we see today in the terminal, and any<br>
number of frontends can talk to one. The &#39;newkernel&#39; branch in the<br>
ipython repo has a Qt implementation of a client that uses this spec,<br>
and it&#39;s getting to be pretty functional already. We&#39;re doing a ton<br>
of work on this over the next few weeks.<br></blockquote></div><br>I&#39;ve read some of the documentation for the new stuff you&#39;re working on. It all sounds really well thought through, and am looking forwards for the results. I&#39;ve got a couple of questions though.<br>
<br>- I see the possibilities of distributed computing by connecting multiple kernels to a single client. However, I don&#39;t get why you would want to connect multiple clients to a single kernel at the same time?<br><br>
- I saw an example in which you&#39;re kind of going towards a Mathematica/Sage type of UI. Is this what you&#39;re really aiming at, or is this one possible front end? I&#39;m asking because IEP has more of a Matlab kind of UI, with an editor from which the user can run code (selected lines or cells: code between two lines starting with two ##&#39;s). Would that be compatible with the kernel you&#39;re designing?<br>
<br>- About the heartbeat thing to detect whether kernels are still alive. I use a similar concept in the channels module. I actually never realized that this would fail if Python is running extension code. However, I do run Cython code that takes about a minute to run without problems. Is that because it&#39;s Cython and the Python interpreter is still involved? I&#39;ll do some test running Cython and C code next week.<br>
<br><br>Since I think its interesting to see that we&#39;ve taking rather different approaches to do (more or less) the same thing, I&#39;ll share some background on what I do in IEP:<br><br>I use one Channels instance from the channels.py module, which means all communication goes over one socket. However, I can use as many as 128 different channels each way. Instead of a messaging format, I use a channel for each task. By the way, I&#39;m not saying my method is better; yours is probably more &quot;scalable&quot;, mine requires no/little message processing. So from the kernel&#39;s perspective, I have one receiving channel for stdin, two sending for stdout and stderr, one receiving for control (mostly debugging at the moment) and one sending for status messages (whether busy/ready, and debug info). Lastly there&#39;s one receiving and one sending channel for introspection requests and responses.<br>
<br>To receive code, sys.stdin is replaced with a receivingChannel from channels.py,
which is non-blocking. The readline() method (which is what raw_input()
uses) *is* blocking, so that raw_input() behaves appropriately.<br><br>The remote process runs an interpreter loop. Each iteration the interpreter checks (non-blocking) the stdin for a command to be run. If there is, it does so using almost the same code in code.py. Next (if required) process GUI events. Next produce prompt if necessary, and send status. In another thread, there is a loop that listens for introspection requests (auto-completion, calltips, docs). <br>
<br>This code is all in iepRemote1.py and iepRemote2.py if you&#39;re interested in the details.<br><br>Cheers,<br> Almar<br>