> On 11 Apr 2018, at 17:16, Denis Kudriashov <dionisi...@gmail.com> wrote:
> 
> 
> 2018-04-11 17:02 GMT+02:00 Sven Van Caekenberghe <s...@stfx.eu>:
> 
> 
> > On 11 Apr 2018, at 16:36, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> >
> > I can make your example, using the Zn variants, work with the following 
> > change:
> >
> > StdioStream>>#atEnd
> >  ^ peekBuffer isNil or: [ (peekBuffer := self next) isNil ]
> 
> Argh, make that
> 
> atEnd
>   ^ peekBuffer isNil and: [ (peekBuffer := self next) isNil ]
> 
> But discussion exactly about "self next isNil": how to avoid it.

I know, but like this it could/might become an implementation detail.

The more things that I try, the more that I feel that stdin is so special that 
it does not fit in the rest of the stream zoo.

> but I am still testing, this is probably not the final answer/solution.
> 
> > Which is a literal implementation of your statement that you can only know 
> > that you are atEnd by reading (and thus waiting/blocking) and checking for 
> > nil, which seems logical to me, given the fact that you *are* waiting for 
> > user input.
> >
> > BTW, at least on macOS you have to enter ctrl-D (^D) on a separate line, I 
> > am not sure how relevant that is, but that is probably another argument 
> > that stdin is special (being line-buffered by the OS, EOF needing to be on 
> > a separate line).
> >
> > And FWIW, I have been writing networking code in Pharo for years, and I 
> > have never had issues with unclear semantics of these primitives (#atEnd, 
> > #next, #peek) on network streams, either the classic SocketStream or the 
> > Zdc* streams (TLS or not). That is why I think we have to be careful.
> >
> > That being said, it is important to continue this discussion, I find it 
> > very interesting. I am trying to write some test code using stdin myself, 
> > to better understand the topic.
> >
> >> On 11 Apr 2018, at 16:06, Alistair Grant <akgrant0...@gmail.com> wrote:
> >>
> >> On 11 April 2018 at 15:11, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> >>>
> >>>
> >>>> On 11 Apr 2018, at 11:12, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> >>>>
> >>>> How does one modify #atEnd to block ? I suppose you are talking about 
> >>>> StdioStream>>#atEnd ?
> >>>>
> >>>> ^ self peek isNil
> >>>>
> >>>> ?
> >>>
> >>> Still the same question, how do you implement a blocking #atEnd for stdin 
> >>> ?
> >>>
> >>> I have seen your stdio.cs which is indeed needed as the current 
> >>> StdioStream>>#atEnd is bogus for sure.
> >>>
> >>> But that is still a non-blocking one, right ?
> >>>
> >>> Since there is a peekBuffer in StdioStream, why can't that be used ?
> >>
> >> I think you've created a chicken-and-egg problem with this question,
> >> but ignoring that for now:
> >>
> >>
> >> StdioStream>>peek
> >> "Answer what would be returned if the message next were sent to the
> >> receiver. If the receiver is at the end, answer nil.  "
> >>
> >>   self atEnd ifTrue: [^ nil ].
> >>
> >>   peekBuffer ifNotNil: [ ^ peekBuffer ].
> >>
> >>   ^ peekBuffer := self next.
> >>
> >>
> >>
> >> So when we first start the program, i.e. the user hasn't entered any
> >> input yet, and #peek is called:
> >>
> >> 1. #atEnd returns false because Ctrl-D (or similar) hasn't been
> >> entered (assuming it is non-blocking).
> >> 2. peekBuffer is nil because we haven't previously called #peek.
> >> 3. The system now blocks on "self next".
> >>
> >>
> >> Just a reminder: for terminal input the end-of-file isn't reached
> >> until the user explicitly enters the end of file key (Ctrl-D).
> >>
> >> So, if there is no buffered input (either none has been entered yet,
> >> or all input has been consumed)
> >>
> >> #atEnd (after the patch) calls #primAtEnd:.
> >>
> >> At the moment, #primAtEnd: ends up calling the libc function feof(),
> >> which is non-blocking and answers the end-of-file flag for the FILE*.
> >> Since the user hasn't entered Ctrl-D, that's false.
> >>
> >> If we want to control iteration over the stream and ensure that we
> >> don't need to do a "stream next == nil" check, then #primAtEnd: is
> >> going to have to peek for the next character, and that means waiting
> >> for the user to enter that character.
> >>
> >> In c that is typically done using:
> >>
> >> atEnd = ungetc(fgetc(fp), fp);
> >>
> >> and fgetc() will block until the user enters something.
> >>
> >>> I have run your example testAtEnd.st now, and it works/fails as 
> >>> advertised.
> >>
> >> :-)
> >>
> >>
> >> Cheers,
> >> Alistair
> >


Reply via email to