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.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180408/f2254f29/attachment-0001.html>