> On 12 Apr 2018, at 08:33, Alistair Grant <[email protected]> wrote: > > Hi Sven, > > On 11 April 2018 at 20:47, Sven Van Caekenberghe <[email protected]> wrote: >> Alistair, >> >>> On 11 Apr 2018, at 19:42, Sven Van Caekenberghe <[email protected]> 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. > > > Cool. I've wanted to try NeoConsole for a while (I've got a Raspberry > Pi monitoring temperatures and wanted to use it to work on the Pi) but > hadn't made the time. > > But... :-) > > > $ vm/pharo Pharo7.0-64bit-d2734dc.image eval NeoConsoleStdio run > Neo Console > Pharo-7.0+alpha.build.760.sha.d2734dcabda799803c307365bcd120f92211d34a > (64 Bit) > pharo> 4+3 > > 7 > pharo> [Ctrl-D] > MessageNotUnderstood: receiver of "<" is nil > UndefinedObject(Object)>>doesNotUnderstand: #< > ZnUTF8Encoder>>nextCodePointFromStream: > ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream: > ZnCharacterReadStream>>nextElement > ZnCharacterReadStream(ZnEncodedReadStream)>>next > [ :out | > | eol char | > eol := false. > [ eol ] > whileFalse: [ char := readStream next. > (char isNil or: [ char == lf ]) > ifTrue: [ eol := true ] > ifFalse: [ char == cr > ifTrue: [ eol := true. > readStream peekFor: lf ] > ifFalse: [ out nextPut: char ] ] ] ] in ZnFastLineReader>>nextLine in > Block: [ :out | ... > ZnFastLineReader>>streamContents: > ZnFastLineReader>>nextLine > [ lineReader nextLine trimBoth ] in NeoConsoleStdio>>readInputFrom: in > Block: [ lineReader nextLine trimBoth ] > BlockClosure>>on:do: > NeoConsoleStdio>>readInputFrom: > NeoConsoleStdio>>executeRequestResponseLoop > NeoConsoleStdio>>run > NeoConsoleStdio class>>run > UndefinedObject>>DoIt > > > In your example you've carefully exited by some other means than > signalling end-of-file (Ctrl-D). > > I don't think we can reasonably say "if you write code with Zinc > streams, ensure that none of your users ever press Ctrl-D, they must > always type 'quit' (or whatever)".
I left that open as an exercise for the reader - I knew you would try that ;-) The code was originally written for network streams and there it catches ConnectionClosed which is the network stream equivalent of EOF (more or less). I think we need something like an EndOfStream exception which should be thrown in that case, instead of returning nil. Returning nil from ZnCharacterReadStream or ZnCharacterEncoder when the stream is EOF is wrong IMHO. The stream being EOF is an exceptional situation (even though it is relatively common) and there is always #atEnd that works well in 99% of the cases. AFAIK that is also the design decision taking by Xtreams (where I believe the Incomplete exception replaces #atEnd). >> But there is something wrong with what is returned by Stdio stdin > > Right, that's the bug I was addressing stdio.cs. I've got a note to > open an issue and submit a PR. > > Cheers, > Alistair
