<div dir="ltr">I appear to have solved the issue on the Scheme side by flushing stdout and stderr streams when printing status messages.<div>Thank you so much for your help!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 15, 2022 at 1:07 PM David O'Toole <<a href="mailto:deeteeoh1138@gmail.com">deeteeoh1138@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I tried reading character by character using #next, and this worked okay albeit producing output slowly in the Transcript---and it still stalls at the same point in the output.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 15, 2022 at 12:48 PM David O'Toole <<a href="mailto:deeteeoh1138@gmail.com" target="_blank">deeteeoh1138@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thank you. This did not change the behavior. I did discover that output is always read in exact 1000 byte multiples, first it reads 1000 then in a later invocation of #step, it reads 4000 and then output stalls. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 15, 2022 at 12:34 PM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi David,<br>
<br>
Hmmm, I'm not sure where the missing output is going.<br>
<br>
I do have another suggestion though. I think you can simplify your<br>
initialization by using just the #prepareOutputForInternalReader method.<br>
This will set things up properly, with non-blocking applied only to<br>
the Scheme output reader pipe (the writer to Scheme should remain in<br>
blocking mode).<br>
<br>
So the code can be reduced to this:<br>
<br>
<br>
startScheme<br>
<br>
        sourcePath ifNil: [self error: 'You must set sourcePath to the directory where Mosaic''s Scheme source files are stored.'].<br>
        self schemeSourceFileExists ifFalse: [self error: 'Cannot find Scheme source in sourcePath.'].<br>
        schemeProcess ifNil: [<br>
                schemeProcess := PipeableOSProcess<br>
                        new: schemeExecutable<br>
                        arguments: nil<br>
                        environment: nil<br>
                        descriptors: nil<br>
                        workingDir: nil<br>
                        errorPipelineStream: nil].<br>
        schemeProcess prepareOutputForInternalReader.<br>
        "actually start the process now"<br>
        schemeProcess value.<br>
        self sendInitialize.<br>
        self sendSchemeExtensions.<br>
        self sendScheme: '(provide ''squeak-mosaic)'<br>
<br>
<br>
<br>
On Sat, Jan 15, 2022 at 11:40:33AM -0500, David O'Toole wrote:<br>
> Hi David, thanks for your help. I indeed have the following in my About<br>
> Squeak dialog: AioPlugin VMConstruction-Plugins-AioPlugin-eem.22 (i)<br>
> <br>
> The Delay suggestion did not work. I notice that I can start a new Scheme<br>
> job, and the standard output begins flowing again, without ever producing<br>
> the remaining output from the previous run, even though the run completed<br>
> successfully. So the output is getting lost somewhere.<br>
> <br>
> Should I be doing [schemeOutput atEnd] whileFalse: [ | output | output :=<br>
> schemeOutput upToEnd ] ? That seemed to prevent output entirely.<br>
> <br>
> Thanks for the references to those other places I could look. I will<br>
> endeavor to debug this.<br>
> <br>
> On Sat, Jan 15, 2022 at 10:53 AM David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
> <br>
> > Hi David,<br>
> ><br>
> > On Fri, Jan 14, 2022 at 10:03:46PM -0500, David O'Toole wrote:<br>
> > > I forgot to include the output method. Adding "flush" seems to have<br>
> > helped,<br>
> > > but output still stops coming well before it is complete.<br>
> > ><br>
> > > On Fri, Jan 14, 2022 at 9:49 PM David O'Toole <<a href="mailto:deeteeoh1138@gmail.com" target="_blank">deeteeoh1138@gmail.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > > I have a question relating to PipeableOSProcess. I'm trying to read the<br>
> > > > standard output from the process and (optionally) print it to the<br>
> > > > Transcript. Several large chunks consisting of dozens of lines are<br>
> > > > produced, but then output halts always after a certain number of<br>
> > characters<br>
> > > > (stopping in the middle of a line) even though I can verify that the<br>
> > Scheme<br>
> > > > process completed its entire job successfully and should have produced<br>
> > more<br>
> > > > output. Am I setting up / accessing the PipeableOSProcess incorrectly<br>
> > in my<br>
> > > > snippet here? I would greatly appreciate any tips you might be able to<br>
> > give<br>
> > > > on my investigating this further. I am running Squeak 5.3 on Linux.<br>
> > > ><br>
> ><br>
> > A likely source of the problem relates to reading available data from<br>
> > an OS pipe, particularly if a large amount of data is involved. When<br>
> > you send #upToEnd to the reader, you will get all of the data that is<br>
> > currently available in the pipe. Meanwhile, pipe itself may be waiting<br>
> > for someone to read from it before it allows the process that is writing<br>
> > to the pipe (the Scheme interpreter in this case) to complete the write.<br>
> ><br>
> > The end result is that when you read upToEnd from a pipe, you may not<br>
> > receive the entire chunk of data that is being written by Scheme, and<br>
> > you may need to wait for a few milliseconds and do another read to<br>
> > get the rest.<br>
> ><br>
> > For purposes of debugging, try putting a short delay before the #upToEnd<br>
> > (Delay forMilliseconds: 200). If that makes it work, it will confirm<br>
> > my guess above.<br>
> ><br>
> > A couple of related notes for your information:<br>
> ><br>
> > Take a look at the #upToEndOfFile method, as compared to #upToEnd.<br>
> > You will not be able to use it for your Scheme interpreter because<br>
> > it would wait for the Scheme interpreter to close its end of the<br>
> > pipe, which is not what you want for in interactive connection. But<br>
> > it may clarify the issues of reading from a pipe.<br>
> ><br>
> > Also look at class BufferedAsyncFileReadStream, which deals with<br>
> > the issue by populating its buffer based on AIO events (data available<br>
> > on the pipe) to minimize the need for polling loops to get data<br>
> > from a pipe. This is how you are reading the pipe data, and depending<br>
> > on whether you have the AIOPlugin in your VM, it may be falling back<br>
> > on its polling loop instead of being event driven. This should still<br>
> > work fine but it affects timing of the data available from the pipe.<br>
> ><br>
> > Regarding the #flush, I'm not sure I understand what you are doing<br>
> > in the #step method, but when you write to the external Scheme<br>
> > process on pipeToInput you do want to flush it. That ensures that<br>
> > your data gets pushed out to the OS pipe, and makes it available<br>
> > for Scheme to read from its end of the pipe.<br>
> ><br>
> > HTH,<br>
> > Dave<br>
> ><br>
> ><br>
> ><br>
<br>
> <br>
<br>
<br>
</blockquote></div>
</blockquote></div>
</blockquote></div>