Andrew Haines wrote:
Michalis Kamburelis wrote:
Andrew Haines wrote:
[...]
I am not extremely familiar with how streams work, but using
LoadFromStream(Output) may not "Read" the data so it can be replaced
with new data. Also as I said I think S.LoadFromStream is blocking
until the end of the stream is reached, which can't happen until the
program has ended possibly resulting in lost data. Someone please
correct me if I am wrong ;)
That's a good point, S.LoadFromStream *should* be blocking but
*currently it isn't*. I reproduced Bobby's problem with
TStringList.LoadFromStream (on Linux, so it's not specific to Win32).
Looking at implementation in rtl/objpas/classes/stringl.inc, there's
a test
Until BytesRead<>BufDelta
that should probably be changed to
Until BytesRead = 0
Then it should be possible to call S.LoadFromStream just once, and
read the whole output of a process. There should be no need to do the
partial reads, because TStringList.LoadFromStream should already
handle this. Generally, example "Reading large output" on
[http://wiki.lazarus.freepascal.org/index.php/Executing_External_Programs]
will not need to use memory stream anymore. One should just construct
process without poWaitOnExit (to prevent deadlock), and then be able
to read it's whole output using single call
AStringList.LoadFromStream(AProcess.Output);
So right now I think that what Bobby is observing is a result of a
bug in FPC's implementation of TStringList.LoadFromStream. I'll try
to fix it and submit to FPC devels.
Anyway, for now: the method of example "Reading large output" in the
wiki still works OK. In other words: Bobby, for now you should use
memory streams to read the pipe, like presented on the wiki (and like
Andrew suggests). Then, after grabbing everything to TMemoryStream,
you can safely convert it to e.g. TStringList by
AStringList.LoadFromStream(AMemoryStream);
This Should Work :)
I think that TProcess.Output cannot be larger than a certain size on
some platforms, so this is why it is read in increments rather than
waiting until it is done. Because the program will stop until some
output is read to make room for new output.
Andrew
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
The testproc.pp from Lazarus package reproduced the same problem - just
106kb of data, and console app goes into deadlock.
The testproc.pp code, modified to start my child process:
program project1;
uses classes,process;
Const BufSize = 1024;
TheProgram = 'disasm.exe test.exe';
Var S : TProcess;
Buf : Array[1..BUFSIZE] of char;
I,Count : longint;
begin
S:=TProcess.Create(Nil);
S.Commandline:=theprogram;
S.Options:=[poUsePipes,poNoConsole];
S.execute;
Repeat
Count:=s.output.read(buf,BufSize);
For I:=1 to Count do
write(buf[i]);
until Count=0;
writeln;
S.Free;
end.
My conclusion goes to pipes again. If so, I guess that pipe to
filestream would reproduce the same problem.
Can someone test the code above on Linux, redirecting some large output
directly from terminal console, and the from the test above, and to see
if the problem is reproduced?
regards
Boban Spasic aka Bobby
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
