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.

Cheers,
Alistair