Thanks Eli - please see inline. <br><br><div class="gmail_quote">On Mon, Jun 16, 2008 at 10:40 PM, Eli Barzilay &lt;<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br></div>You have the rough idea, but several problems:<br>
<br>
* you have a redundant `lambda&#39; which means that you never really get<br>
 &nbsp;to read anything (on toy examples, this will probably be a change<br>
 &nbsp;that will make things work, but see below)<br>
</blockquote><div><br>Yup - it worked after removing the lambda. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* `write&#39; is probably not a good idea -- it will print something with<br>
 &nbsp;the double quotes.<br></blockquote><div><br>Makes sense.&nbsp; <br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* after you write, you&#39;d want to flush `pin&#39;, or if you expect the<br>
 &nbsp;program to get just that, then you&#39;d want to close it (so your<br>
 &nbsp;program will not sit there waiting for more stuff)<br>
</blockquote><div><br>Ah ha!&nbsp; I first tried to write eof to the stream and it didn&#39;t work... thanks for the pointer! <br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
* finally, the biggest problem is a conceptual one: you read stuff<br>
 &nbsp;from the output only after the process has finished -- but what if<br>
 &nbsp;it spits out a lot of data? &nbsp;In that case, it will not finish, and<br>
 &nbsp;instead just sit there waiting for you to read that data, and you&#39;ll<br>
 &nbsp;be getting into a very common race condision with subprocesses.<br>
<br>
 &nbsp;What you really need is to do the reading in a thread, so the<br>
 &nbsp;process can continue running. &nbsp;It might seem strange at first, but<br>
 &nbsp;when there&#39;s a lot of data then *someone* needs to hold it, and the<br>
 &nbsp;OS will hold only a very small amount (and for good reasons). &nbsp;Your<br>
 &nbsp;thread will need to do just that accumulation (or it can just to the<br>
 &nbsp;processing, whatever it is).<br>
</blockquote><div><br>After re-reading your example, I think I started to grok what you were doing on <a href="http://www.cs.brown.edu/pipermail/plt-scheme/2006-February/011953.html">http://www.cs.brown.edu/pipermail/plt-scheme/2006-February/011953.html</a>: <br>
<pre style="font-family: courier new,monospace; margin-left: 40px;">...<br>(define-values (in out) (make-pipe)) ... <br>...<br>(thread (lambda ()<br>          (copy-port pout out)<br>          (close-output-port out)<br>          (subprocess-wait p)))</pre>
You first created a pipe for holding the accumulation, and then you started a thread to read the data from pout into pipe&#39;s out, and when out is closed the data gets piped to in (perhaps this is happening in the background without you have to close it too?), and finally the process exits...&nbsp; correct?&nbsp; But shouldn&#39;t the ports be closed after subprocess-wait? <br>
&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
(You can also see &quot;collects/mzlib/process.ss&quot; for a very extensive<br>
solution.)<font color="#888888"><br></font></blockquote><div><br>Thanks for the pointer - time to learn the concurrency primitives in the module... ;) <br><br>Thanks,<br>yc<br><br></div></div>