Could any of this result in, say, an implementation of Curses or a curses-like text output?<br><br><div class="gmail_quote">On Tue, Nov 2, 2010 at 1:40 PM, Casey Ransberger <span dir="ltr">&lt;<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">+1 for LF on unix, not sure what makes sense on Windows either.<br>
<div><div></div><div class="h5"><br>
On Nov 2, 2010, at 1:19 PM, Bert Freudenberg &lt;<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt; On 02.11.2010, at 19:19, Levente Uzonyi wrote:<br>
&gt;<br>
&gt;&gt; On Tue, 2 Nov 2010, Bert Freudenberg wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 02.11.2010, at 17:41, Levente Uzonyi wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; yesterday I added Eliot&#39;s stdio change set to the Trunk. There are some questions left to be answered:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 1) Do we want to use CrLfFileStream?<br>
&gt;&gt;&gt;&gt; Currently it has only two users in the image, but the class is &quot;patched&quot; so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this &quot;patch&quot; for the stdio streams.<br>

&gt;&gt;&gt;<br>
&gt;&gt;&gt; Should use MultiByteFileStream.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 2) Read buffering: currently it&#39;s enabled for the stdio streams. For stdout and stderr it doesn&#39;t make a difference. For stdin it&#39;s a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you&#39;ll get nothing (nil). If we want these streams to be shared like this (accessible via both<br>

&gt;&gt;&gt;&gt; MultiByteFileStream and StandardFileStream), then this is a problem.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Only stdout should be buffered.<br>
&gt;&gt;<br>
&gt;&gt; This is about image level buffering, where we only have read buffering. I&#39;m pretty sure these streams use the OS&#39;s default buffering scheme at the VM level. For example stdout is line buffered on windows.<br>

&gt;<br>
&gt; Right.<br>
&gt;<br>
&gt;&gt;&gt;&gt; 3) Should we set the line end convention of MultiByteFileStream for these streams? It&#39;s currently not set.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; IMHO, yes, set it to LF.<br>
&gt;&gt;<br>
&gt;&gt; Why LF?<br>
&gt;<br>
&gt; Unix standard. Nobody wants CR, not even on the Mac anymore, which runs Unix nowadays.<br>
&gt;<br>
&gt; Scripts that use stdin and stdout certainly expect LFs.<br>
&gt;<br>
&gt; Maybe Windows should use CRLF (no idea how shell scripts work there) but everything else should use LF.<br>
&gt;<br>
&gt; - Bert -<br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br>