- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Eliot Miranda

Hi Sven, On Wed, Apr 11, 2018 at 1:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 11 Apr 2018, at 21:44, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > I did not know about the NeoConsole. Nice because I wanted to build a > > little REPL for my minilanguage implementation. > > You are of course welcome to look at it. > But it is Pharo specific. > I use it to be able to hook/look into running headless server images. > For this it is super handy. > Cool usage! Could you tell me whether you type Smalltalk expressions into this to examine your running server? The answer will be used in a related discussion on a mailing list not too distant from this one ;-) > > > Stef > > > > On Wed, Apr 11, 2018 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Alistair, > >> > >>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>> I will send you some code later on. > >> > >> Today I arranged for my NeoConsole code (that normally works over a > network connection) to work over stdio. Although I am not yet happy with > every aspect of the implementation, it does work (using unaltered Zn > streams and code). The foll > >> > >> $ cat /etc/issue > >> Ubuntu 16.04.4 LTS > >> $ mkdir pharo7 > >> $ cd pharo7/ > >> $ curl get.pharo.org/70+vm | bash > >> % Total % Received % Xferd Average Speed Time Time Time > Current > >> Dload Upload Total Spent Left > Speed > >> 100 3036 100 3036 0 0 36799 0 --:--:-- --:--:-- > --:--:-- 37024 > >> Downloading the latest 70 Image: > >> http://files.pharo.org/get-files/70/pharo.zip > >> Pharo.image > >> Downloading the latest pharoVM: > >> http://files.pharo.org/get-files/70/pharo-linux-stable.zip > >> pharo-vm/pharo > >> Creating starter scripts pharo and pharo-ui > >> On a 64-bit system? You must enable and install the 32-bit libraries > >> Please see http://pharo.org/gnu-linux-installation for detailed > instructions > >> $ ./pharo Pharo.image config http://mc.stfx.eu/Neo > ConfigurationOfNeoConsole --install=bleedingEdge > >> 'Installing ConfigurationOfNeoConsole bleedingEdge' > >> > >> Loading 1-baseline of ConfigurationOfNeoConsole... > >> Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- > http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo > >> Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- > http://mc.stfx.eu/Neo --- cache > >> ...finished 1-baseline > >> $ ./pharo Pharo.image eval NeoConsoleStdio run > >> Neo Console Pharo-7.0+alpha.build.760.sha. > d2734dcabda799803c307365bcd120f92211d34a (32 Bit) > >> pharo> 1+2 > >> > >> 3 > >> pharo> 42 factorial > >> > >> 1405006117752879898543142606244511569936384000000000 > >> pharo> Stdio stdin > >> > >> StdioStream: #stdin > >> pharo> == > >> self: StdioStream: #stdin > >> class: StdioStream > >> file: a File > >> handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1] > >> forWrite: false > >> peekBuffer: nil > >> pharo> show StdioStream>>#atEnd > >> StdioStream>>#atEnd > >> atEnd > >> > >> ^ file atEnd > >> pharo> get process.list > >> Morphic UI Process > >> Delay Scheduling Process > >> Low Space Watcher > >> Input Event Fetcher Process > >> Idle Process > >> WeakArray Finalization Process > >> CommandLine handler process > >> pharo> quit > >> Bye! > >> a NeoConsoleStdio > >> > >> I know there are many approaches to a REPL, I don't claim mine is best, > it is just the one that I have been using for years. > >> > >> In the above, I do not depend on EOF - just to be clear. The point > being that there is no immediate fundamental problem. > >> > >> But there is something wrong with what is returned by Stdio stdin > >> > >> Sven > >> > >> > >> > > > > > -- _,,,^..^,,,_ best, Eliot

April 12, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Sven Van Caekenberghe

> On 11 Apr 2018, at 21:44, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I did not know about the NeoConsole. Nice because I wanted to build a > little REPL for my minilanguage implementation. You are of course welcome to look at it. But it is Pharo specific. I use it to be able to hook/look into running headless server images. For this it is super handy. > Stef > > On Wed, Apr 11, 2018 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Alistair, >> >>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> I will send you some code later on. >> >> Today I arranged for my NeoConsole code (that normally works over a network connection) to work over stdio. Although I am not yet happy with every aspect of the implementation, it does work (using unaltered Zn streams and code). The foll >> >> $ cat /etc/issue >> Ubuntu 16.04.4 LTS >> $ mkdir pharo7 >> $ cd pharo7/ >> $ curl get.pharo.org/70+vm | bash >> % Total % Received % Xferd Average Speed Time Time Time Current >> Dload Upload Total Spent Left Speed >> 100 3036 100 3036 0 0 36799 0 --:--:-- --:--:-- --:--:-- 37024 >> Downloading the latest 70 Image: >> http://files.pharo.org/get-files/70/pharo.zip >> Pharo.image >> Downloading the latest pharoVM: >> http://files.pharo.org/get-files/70/pharo-linux-stable.zip >> pharo-vm/pharo >> Creating starter scripts pharo and pharo-ui >> On a 64-bit system? You must enable and install the 32-bit libraries >> Please see http://pharo.org/gnu-linux-installation for detailed instructions >> $ ./pharo Pharo.image config http://mc.stfx.eu/Neo ConfigurationOfNeoConsole --install=bleedingEdge >> 'Installing ConfigurationOfNeoConsole bleedingEdge' >> >> Loading 1-baseline of ConfigurationOfNeoConsole... >> Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo >> Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- cache >> ...finished 1-baseline >> $ ./pharo Pharo.image eval NeoConsoleStdio run >> Neo Console Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a (32 Bit) >> pharo> 1+2 >> >> 3 >> pharo> 42 factorial >> >> 1405006117752879898543142606244511569936384000000000 >> pharo> Stdio stdin >> >> StdioStream: #stdin >> pharo> == >> self: StdioStream: #stdin >> class: StdioStream >> file: a File >> handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1] >> forWrite: false >> peekBuffer: nil >> pharo> show StdioStream>>#atEnd >> StdioStream>>#atEnd >> atEnd >> >> ^ file atEnd >> pharo> get process.list >> Morphic UI Process >> Delay Scheduling Process >> Low Space Watcher >> Input Event Fetcher Process >> Idle Process >> WeakArray Finalization Process >> CommandLine handler process >> pharo> quit >> Bye! >> a NeoConsoleStdio >> >> I know there are many approaches to a REPL, I don't claim mine is best, it is just the one that I have been using for years. >> >> In the above, I do not depend on EOF - just to be clear. The point being that there is no immediate fundamental problem. >> >> But there is something wrong with what is returned by Stdio stdin >> >> Sven >> >> >> >

April 11, 2018

Re: [Pharo-dev] Why String do not implement #displayString?

by Stephane Ducasse

The point is a list of strings should be displayed as a b c and not 'a' 'b' 'c' It shows that often people confuse asString and printString BTW. On Wed, Apr 11, 2018 at 10:05 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > ? > > > On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> Hi, >> >> I am sorry for interrupting this conversation... but >> >> | s | >> s := 'Hello, ''Funny'' World'. >> s displayString = s "false" and not true! >> >> Cheers, >> Alex >> >> On 11 April 2018 at 21:53, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Yes I think that >>> >>> | s | >>> s := 'Hello, ''Funny'' World'. >>> s displayString = s. "true" >>> s printString = s. "false" >>> >>> is ok and widgets should use displayString. >>> >>> Stef >>> >>> >>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo >>> <emaringolo(a)gmail.com> wrote: >>> > Isn't #displayString implemented in terms of #displayOn: the same way >>> > #printString is implemented in terms of "printOn:"? >>> > >>> > And in the case of String #displayString should return the receiver (it >>> > is, self), so the following should be true. >>> > >>> > | s | >>> > s := 'Hello, ''Funny'' World'. >>> > s displayString = s. "true" >>> > s printString = s. "false" >>> > >>> > Regards, >>> > >>> > >>> > On 10/04/2018 12:21, Denis Kudriashov wrote: >>> >> Hi. >>> >> >>> >> According to the comment of #displayString it should be used as default >>> >> textual representation of objects in the UI: >>> >> >>> >> "While printString is about to give a detailled information about >>> >> an >>> >> object, displayString is a message that should return a short >>> >> string-based representation to be used by list and related UI >>> >> frameworks. By default, simply return printString." >>> >> "asString should not be implemented in Object, and kept for >>> >> conversion between strings, symbols, text and characters." >>> >> >>> >> But String itself does not respect this message: >>> >> >>> >> 'some string' displayString " ==> '''someString''' " >>> >> >>> >> >>> >> Is it bug? Or is there any reason for this? >>> >> >>> >> Best regards, >>> >> Denis >>> > >>> > -- >>> > Esteban A. Maringolo >>> > >>> >>

April 11, 2018

Re: [Pharo-dev] Why String do not implement #displayString?

by Aliaksei Syrel

I had to read more carefully :) Yes, it should be true, but now it is false, which is a problem. Cheers, Alex On 11 April 2018 at 22:02, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > I am sorry for interrupting this conversation... but > > | s | > s := 'Hello, ''Funny'' World'. > s displayString = s *"false"* and not true! > > Cheers, > Alex > > On 11 April 2018 at 21:53, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> Yes I think that >> >> | s | >> s := 'Hello, ''Funny'' World'. >> s displayString = s. "true" >> s printString = s. "false" >> >> is ok and widgets should use displayString. >> >> Stef >> >> >> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo >> <emaringolo(a)gmail.com> wrote: >> > Isn't #displayString implemented in terms of #displayOn: the same way >> > #printString is implemented in terms of "printOn:"? >> > >> > And in the case of String #displayString should return the receiver (it >> > is, self), so the following should be true. >> > >> > | s | >> > s := 'Hello, ''Funny'' World'. >> > s displayString = s. "true" >> > s printString = s. "false" >> > >> > Regards, >> > >> > >> > On 10/04/2018 12:21, Denis Kudriashov wrote: >> >> Hi. >> >> >> >> According to the comment of #displayString it should be used as default >> >> textual representation of objects in the UI: >> >> >> >> "While printString is about to give a detailled information about >> an >> >> object, displayString is a message that should return a short >> >> string-based representation to be used by list and related UI >> >> frameworks. By default, simply return printString." >> >> "asString should not be implemented in Object, and kept for >> >> conversion between strings, symbols, text and characters." >> >> >> >> But String itself does not respect this message: >> >> >> >> 'some string' displayString " ==> '''someString''' " >> >> >> >> >> >> Is it bug? Or is there any reason for this? >> >> >> >> Best regards, >> >> Denis >> > >> > -- >> > Esteban A. Maringolo >> > >> >> >

April 11, 2018

Re: [Pharo-dev] Why String do not implement #displayString?

by Stephane Ducasse

? On Wed, Apr 11, 2018 at 10:02 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi, > > I am sorry for interrupting this conversation... but > > | s | > s := 'Hello, ''Funny'' World'. > s displayString = s "false" and not true! > > Cheers, > Alex > > On 11 April 2018 at 21:53, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Yes I think that >> >> | s | >> s := 'Hello, ''Funny'' World'. >> s displayString = s. "true" >> s printString = s. "false" >> >> is ok and widgets should use displayString. >> >> Stef >> >> >> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo >> <emaringolo(a)gmail.com> wrote: >> > Isn't #displayString implemented in terms of #displayOn: the same way >> > #printString is implemented in terms of "printOn:"? >> > >> > And in the case of String #displayString should return the receiver (it >> > is, self), so the following should be true. >> > >> > | s | >> > s := 'Hello, ''Funny'' World'. >> > s displayString = s. "true" >> > s printString = s. "false" >> > >> > Regards, >> > >> > >> > On 10/04/2018 12:21, Denis Kudriashov wrote: >> >> Hi. >> >> >> >> According to the comment of #displayString it should be used as default >> >> textual representation of objects in the UI: >> >> >> >> "While printString is about to give a detailled information about >> >> an >> >> object, displayString is a message that should return a short >> >> string-based representation to be used by list and related UI >> >> frameworks. By default, simply return printString." >> >> "asString should not be implemented in Object, and kept for >> >> conversion between strings, symbols, text and characters." >> >> >> >> But String itself does not respect this message: >> >> >> >> 'some string' displayString " ==> '''someString''' " >> >> >> >> >> >> Is it bug? Or is there any reason for this? >> >> >> >> Best regards, >> >> Denis >> > >> > -- >> > Esteban A. Maringolo >> > >> >

April 11, 2018

Re: [Pharo-dev] Why String do not implement #displayString?

by Aliaksei Syrel

Hi, I am sorry for interrupting this conversation... but | s | s := 'Hello, ''Funny'' World'. s displayString = s *"false"* and not true! Cheers, Alex On 11 April 2018 at 21:53, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Yes I think that > > | s | > s := 'Hello, ''Funny'' World'. > s displayString = s. "true" > s printString = s. "false" > > is ok and widgets should use displayString. > > Stef > > > On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: > > Isn't #displayString implemented in terms of #displayOn: the same way > > #printString is implemented in terms of "printOn:"? > > > > And in the case of String #displayString should return the receiver (it > > is, self), so the following should be true. > > > > | s | > > s := 'Hello, ''Funny'' World'. > > s displayString = s. "true" > > s printString = s. "false" > > > > Regards, > > > > > > On 10/04/2018 12:21, Denis Kudriashov wrote: > >> Hi. > >> > >> According to the comment of #displayString it should be used as default > >> textual representation of objects in the UI: > >> > >> "While printString is about to give a detailled information about an > >> object, displayString is a message that should return a short > >> string-based representation to be used by list and related UI > >> frameworks. By default, simply return printString." > >> "asString should not be implemented in Object, and kept for > >> conversion between strings, symbols, text and characters." > >> > >> But String itself does not respect this message: > >> > >> 'some string' displayString " ==> '''someString''' " > >> > >> > >> Is it bug? Or is there any reason for this? > >> > >> Best regards, > >> Denis > > > > -- > > Esteban A. Maringolo > > > >

April 11, 2018

Re: [Pharo-dev] Why String do not implement #displayString?

by Stephane Ducasse

Yes I think that | s | s := 'Hello, ''Funny'' World'. s displayString = s. "true" s printString = s. "false" is ok and widgets should use displayString. Stef On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Isn't #displayString implemented in terms of #displayOn: the same way > #printString is implemented in terms of "printOn:"? > > And in the case of String #displayString should return the receiver (it > is, self), so the following should be true. > > | s | > s := 'Hello, ''Funny'' World'. > s displayString = s. "true" > s printString = s. "false" > > Regards, > > > On 10/04/2018 12:21, Denis Kudriashov wrote: >> Hi. >> >> According to the comment of #displayString it should be used as default >> textual representation of objects in the UI: >> >> "While printString is about to give a detailled information about an >> object, displayString is a message that should return a short >> string-based representation to be used by list and related UI >> frameworks. By default, simply return printString." >> "asString should not be implemented in Object, and kept for >> conversion between strings, symbols, text and characters." >> >> But String itself does not respect this message: >> >> 'some string' displayString " ==> '''someString''' " >> >> >> Is it bug? Or is there any reason for this? >> >> Best regards, >> Denis > > -- > Esteban A. Maringolo >

April 11, 2018

Re: [Pharo-dev] Contribute a Fix and Reviewing changes

by Esteban Lorenzano

tomorrow I will present it to the world ;) and in theory it will be released, but today the CI was dead :( Esteban > On 11 Apr 2018, at 21:29, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi nicolai > > Keep pushing :) I succeeded to make it work and now I'm eager to use the new UI > and refactored version. > > Stef > > On Tue, Apr 10, 2018 at 11:16 PM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > Hi, > > I tried to create a pull request with IceBerg. > I followed the CONTRIBUTING HowTo and Markus' create TechTalk-Video. > > But I must have done something wrong. > This is my pull request: > https://github.com/pharo-project/pharo/pull/1189 <https://github.com/pharo-project/pharo/pull/1189> > But although I just changes one line in one method. > The gitub pull request side shows > Commit 1 Files changed 40! > But I did not change 40 files > > > And I still have problems viewing pull requests from within pharo: > > > > <grafik.png> > > > I thought this would work meanwhil. > > > Thanks in advance > > nicolai > >

April 11, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Stephane Ducasse

I did not know about the NeoConsole. Nice because I wanted to build a little REPL for my minilanguage implementation. Stef On Wed, Apr 11, 2018 at 8:47 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Alistair, > >> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I will send you some code later on. > > Today I arranged for my NeoConsole code (that normally works over a network connection) to work over stdio. Although I am not yet happy with every aspect of the implementation, it does work (using unaltered Zn streams and code). The foll > > $ cat /etc/issue > Ubuntu 16.04.4 LTS > $ mkdir pharo7 > $ cd pharo7/ > $ curl get.pharo.org/70+vm | bash > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 3036 100 3036 0 0 36799 0 --:--:-- --:--:-- --:--:-- 37024 > Downloading the latest 70 Image: > http://files.pharo.org/get-files/70/pharo.zip > Pharo.image > Downloading the latest pharoVM: > http://files.pharo.org/get-files/70/pharo-linux-stable.zip > pharo-vm/pharo > Creating starter scripts pharo and pharo-ui > On a 64-bit system? You must enable and install the 32-bit libraries > Please see http://pharo.org/gnu-linux-installation for detailed instructions > $ ./pharo Pharo.image config http://mc.stfx.eu/Neo ConfigurationOfNeoConsole --install=bleedingEdge > 'Installing ConfigurationOfNeoConsole bleedingEdge' > > Loading 1-baseline of ConfigurationOfNeoConsole... > Fetched -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- http://mc.stfx.eu/Neo > Loaded -> Neo-Console-Core-SvenVanCaekenberghe.24 --- http://mc.stfx.eu/Neo --- cache > ...finished 1-baseline > $ ./pharo Pharo.image eval NeoConsoleStdio run > Neo Console Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a (32 Bit) > pharo> 1+2 > > 3 > pharo> 42 factorial > > 1405006117752879898543142606244511569936384000000000 > pharo> Stdio stdin > > StdioStream: #stdin > pharo> == > self: StdioStream: #stdin > class: StdioStream > file: a File > handle: #[148 213 25 107 160 197 105 247 0 0 0 0 0 0 0 0 0 1 255 1] > forWrite: false > peekBuffer: nil > pharo> show StdioStream>>#atEnd > StdioStream>>#atEnd > atEnd > > ^ file atEnd > pharo> get process.list > Morphic UI Process > Delay Scheduling Process > Low Space Watcher > Input Event Fetcher Process > Idle Process > WeakArray Finalization Process > CommandLine handler process > pharo> quit > Bye! > a NeoConsoleStdio > > I know there are many approaches to a REPL, I don't claim mine is best, it is just the one that I have been using for years. > > In the above, I do not depend on EOF - just to be clear. The point being that there is no immediate fundamental problem. > > But there is something wrong with what is returned by Stdio stdin > > Sven > > >

April 11, 2018

Re: [Pharo-dev] Changed #atEnd primitive - #atEnd vs #next returning nil

by Stephane Ducasse

On Wed, Apr 11, 2018 at 5:33 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I think we have to reset this whole discussion. > > FileStream stdin > > and > > Stdio stdin > > are completely different ! Could you explain the difference because I'm dead tired and got confused :) > > We'll have to check that first, before talking about the issues raised in this thread. > > And BTW these terminal streams are a real pain to test ;-) > >> On 11 Apr 2018, at 17:20, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 11 Apr 2018, at 17:16, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> >>> 2018-04-11 17:02 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> >>>> On 11 Apr 2018, at 16:36, Sven Van Caekenberghe <sven(a)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 <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> On 11 April 2018 at 15:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>> >>>>>> >>>>>>> On 11 Apr 2018, at 11:12, Sven Van Caekenberghe <sven(a)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 > >

April 11, 2018