On Wed, Nov 3, 2010 at 9:41 AM, blake <dsblakewatson at gmail.com> wrote:

> Could any of this result in, say, an implementation of Curses or a
> curses-like text output?


What do you want to build that would use a curses style interface?


>
>
> On Tue, Nov 2, 2010 at 1:40 PM, Casey Ransberger <casey.obrien.r at gmail.com
> > wrote:
>
>> +1 for LF on unix, not sure what makes sense on Windows either.
>>
>> On Nov 2, 2010, at 1:19 PM, Bert Freudenberg <bert at freudenbergs.de>
>> wrote:
>>
>> >
>> > On 02.11.2010, at 19:19, Levente Uzonyi wrote:
>> >
>> >> On Tue, 2 Nov 2010, Bert Freudenberg wrote:
>> >>
>> >>>
>> >>> On 02.11.2010, at 17:41, Levente Uzonyi wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> yesterday I added Eliot's stdio change set to the Trunk. There are
>> some questions left to be answered:
>> >>>>
>> >>>> 1) Do we want to use CrLfFileStream?
>> >>>> Currently it has only two users in the image, but the class is
>> "patched" so #new will return an instance of MultiByteFileStream in those
>> cases. The change set overrides this "patch" for the stdio streams.
>> >>>
>> >>> Should use MultiByteFileStream.
>> >>>
>> >>>> 2) Read buffering: currently it's enabled for the stdio streams. For
>> stdout and stderr it doesn't make a difference. For stdin it'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'll get nothing (nil). If we want these streams to be shared
>> like this (accessible via both
>> >>>> MultiByteFileStream and StandardFileStream), then this is a problem.
>> >>>
>> >>> Only stdout should be buffered.
>> >>
>> >> This is about image level buffering, where we only have read buffering.
>> I'm pretty sure these streams use the OS's default buffering scheme at the
>> VM level. For example stdout is line buffered on windows.
>> >
>> > Right.
>> >
>> >>>> 3) Should we set the line end convention of MultiByteFileStream for
>> these streams? It's currently not set.
>> >>>
>> >>> IMHO, yes, set it to LF.
>> >>
>> >> Why LF?
>> >
>> > Unix standard. Nobody wants CR, not even on the Mac anymore, which runs
>> Unix nowadays.
>> >
>> > Scripts that use stdin and stdout certainly expect LFs.
>> >
>> > Maybe Windows should use CRLF (no idea how shell scripts work there) but
>> everything else should use LF.
>> >
>> > - Bert -
>> >
>> >
>>
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101103/aeb437d9/attachment.htm