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 :-)).


Please let me know if I've misunderstood anything.

Thanks,
Alistair


>> Cheers,
>> Alistair
>>
>>
>>
>>
>>
>>> I think the details are in the nextChunkNoTag method in the
>>> CogTools-Listener package.  I was trying to do the simplest thing that could
>>> possibly work here, not produce a usable listener.  The ! requirement is
>>> absurd for general use but acceptable for someone simply wanting to exercise
>>> (potentially non-blocking) reading from stdin.
>>>
>>>
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>>>
>>>
>>
>