Hi Eliot,

On 8 April 2018 at 23:56, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Alistair,
>
> On Sun, Apr 8, 2018 at 2:19 PM, Alistair Grant <akgrant0710 at gmail.com>
> wrote:
>>
>> Hi Eliot,
>>
>> On 8 April 2018 at 19:06, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> > Hi Alistair,
>> >
>> >
>> >> On Apr 8, 2018, at 8:43 AM, Alistair Grant <akgrant0710 at gmail.com>
>> >> wrote:
>> >>
>> >> Hi Eliot,
>> >>
>> >>> On 8 April 2018 at 17:25, Eliot Miranda <eliot.miranda at gmail.com>
>> >>> wrote:
>> >>> Hi Alistair,
>> >>>
>> >>>
>> >>>> On Apr 8, 2018, at 5:23 AM, Alistair Grant <akgrant0710 at gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>> Hi Eliot,
>> >>>>
>> >>>>> On 8 April 2018 at 03:02, Eliot Miranda <eliot.miranda at gmail.com>
>> >>>>> wrote:
>> >>>>> Hi Alistair,
>> >>>>>
>> >>>>> On Sat, Apr 7, 2018 at 12:32 PM, Alistair Grant
>> >>>>> <akgrant0710 at gmail.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>>> On 7 April 2018 at 20:29, K K Subbu <kksubbu.ml at gmail.com> wrote:
>> >>>>>>>> On Saturday 07 April 2018 08:14 PM, Eliot Miranda wrote:
>> >>>>>>>>
>> >>>>>>>> $ cd image
>> >>>>>>>> $ ./buildspurtrunkreaderimage.sh
>> >>>>>>>> $ myvm spurreader.image
>> >>>>>>>> squeak> 3 + 4!
>> >>>>>>>> 7
>> >>>>>>>> squeak> Smalltalk quit!
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Nice. This can become a good smoke test at the end of the
>> >>>>>>> build*.sh:
>> >>>>>>>
>> >>>>>>> /bin/echo -e '14*3!\nSmalltalk quit!' | $VM spurreader.image
>> >>>>>>>
>> >>>>>>> Now there's the answer to life, the universe and everything ;-)
>> >>>>>>>
>> >>>>>>> Regards .. Subbu
>> >>>>>>
>> >>>>>>
>> >>>>>> Interesting idea...  But even the old VM doesn't provide the
>> >>>>>> answer.
>> >>>>>
>> >>>>>
>> >>>>> It will do, but that \n must be a ^M.  So if one types '3+4!
>> >>>>> followed by
>> >>>>> ctrl-v carriage return, followed by Smalltalk quit!' then echo will
>> >>>>> echo a
>> >>>>> carriage return.  But since the REPL is actually reading chunk
>> >>>>> format (hence
>> >>>>> the !'s) one doesn't need the carriage return at all and one should
>> >>>>> be able
>> >>>>> to say
>> >>>>>
>> >>>>> echo '3+4!Smalltalk quit!' | $VM spurreader.image
>> >>>>>
>> >>>>> and see "squeak> 7
>> >>>>> squeak> " printed to stdout
>> >>>>>
>> >>>>>> Piped input is working in general with my new test VM.  I'll have
>> >>>>>> to
>> >>>>>> figure out why the reader image doesn't handle it.
>> >>>>
>> >>>> In this case:
>> >>>>
>> >>>> - PositionableStream>>nextChunkNoTag calls #peek
>> >>>> - #peek tries to save the state, which tries to read the stream
>> >>>> position.
>> >>>> - And getting the stream position doesn't seem to be supported for
>> >>>> piped input.
>> >>>> - So an Error is raised.
>> >>>> - But because the input processing is done outside the exception
>> >>>> handler, there's nothing to catch the error.
>> >>>> - And the system becomes unresponsive (when run headless).
>> >>>>
>> >>>> I want to get #primitiveFileAtEnd working first - I've written the
>> >>>> code, I just need to run it through the usual test suites.
>> >>>
>> >>> Agreed.  And having peek work on stdin, as if used to, is essential.
>> >>> Consider the reader part of the tests.
>> >>>
>> >>>>
>> >>>> Adding a primitivePeek would be trivial and should also work with
>> >>>> piped input.  I might have a look at this after I'm sure
>> >>>> #primitiveFileAtEnd works properly.
>> >>>
>> >>> This would have bay be acceptable on a major release.  You /cannot/
>> >>> break problems motives and expect image code to change except at a major
>> >>> release.  The VM /must/ continue to run exist my images unchanged. If it
>> >>> does not then there has been a regression and it must be fixed.  So if your
>> >>> changes to primitiveFileAtEnd are at fault they must be fixed.
>> >>>
>> >>
>> >>
>> >> I think two issues are being mixed together here:
>> >>
>> >> 1. primitiveFileAtEnd
>> >>
>> >> My change broke some behaviour - no question.  Cyril, Subbu and your
>> >> reports allowed me to identify what was wrong there.  I've modified
>> >> the code and have a PR being built at the moment to make sure it
>> >> builds on all platforms.  Both the Pharo and Squeak test suites (32
>> >> bit) had their usual group of errors, which aren't related to file
>> >> i.o, so that is looking good.
>> >>
>> >> However that has nothing to do with the issue we're talking about at
>> >> the moment.
>> >>
>> >>
>> >> Second issue:
>> >>
>> >> 2. #peek not working with piped input
>> >>
>> >>> Adding primitivePeek seems to me a mistake.  It is adding unnecessary
>> >>> code at a low level.  I had managed to get perk working for stdin.  Why is
>> >>> it broken?
>> >>
>> >> The problem here is that the current implementation of #peek, which
>> >> relies on getting and setting the position of the stream, works with
>> >> terminal input and a redirected input file, but not with piped input.
>> >>
>> >> The additional primitive I'm proposing I think will allow it to also
>> >> work with piped input (although I haven't tested it).  Obviously
>> >> existing images won't be affected - they won't be calling the new
>> >> primitive.
>> >>
>> >> None of the changes I'm proposing (primitiveFileAtEnd or adding a
>> >> primitivePeek) would break backward compatibility (bugs aside :-)).
>> >
>> > Good to hear!
>> >
>> >>
>> >>
>> >> Please let me know if I've misunderstood anything.
>> >
>> > I don't think so.  I think the misunderstandings are in my side.  My
>> > current concern is that if stdin is at end of input (input consumed or user
>> > has typed EOF) that stdin reflect that, otherwise the listener is severely
>> > hampered and requires Smalltalk quit to exit cleanly, getting blocked
>> > otherwise.
>>
>>
>> The behaviour of #atEnd for stdin from a terminal is the same
>> with my patch as before.
>>
>> That is, once the code has read past the end of the stream #atEnd will
>> answer true.
>>
>> This doesn't meet the original definition of #atEnd, which is that it
>> should answer true once the last element has been read.
>>
>> But that isn't possible for stdin from a terminal since we need to wait
>> for the user to explicitly flag the end of input (using Ctrl-D) and
>> #atEnd shouldn't block waiting for input from the user.
>>
>> In practice, this generally isn't an issue in Squeak as any code that is
>> reading from stdin isn't relying on #atEnd, but checking for #next
>> returning nil.
>>
>>
>> For all other files:
>>
>> #atEnd used to return the correct answer if the size of the
>> file was reported accurately by the file system.
>>
>> This was generally true for "normal" files, i.e. those where I can
>> find the contents on the disk.
>>
>> But was often wrong for virtual files, e.g. /proc/cpuinfo, and
>> character devices, e.g. /dev/urandom, which return a file size of 0.
>>
>> Hopefully now it returns the correct answer in all cases.
>
>
> Well, I don't know why but when I try the reader image it works, but no
> prompt is printed until after one supplies input.  So something has changed.
> I want your fixes but we also need backward compatibility.  So some more
> investigation is necessary.

I'd made the fixes and put them in a PR, but hadn't yet merged them.

Try CommitHash 6bee4d2 or later (9 April 2018).

Cheers,
Alistair