From: Bart W on
>>>>> "Raymond" == Raymond Toy <toy.raymond(a)gmail.com> writes:

Raymond> Bart Wage wrote:
>>
> Any other suggestions? Surely it must be possible to pass a stream of
>> bytes to a program somehow?

Raymond> Sorry for the delay. I see now that if you specify a
Raymond> stream, cmucl will basically write out the data more or
Raymond> less directly from the string, which contains 16-bit
Raymond> characters. This isn't what we want.

Raymond> run-program needs to be updated somehow.

Raymond> But until then, perhaps some variant of the following will
Raymond> work. I tested it very briefly.

Thanks, that worked! My problems are solved, but here are some more
points:

1. A similar problem exists with binary output and :output :stream.

2. The documentation (at
http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc45)
does not mention that the :output argument may be specified as a stream,
but it may and the comments in the source code (run-program.lisp) say so
too.

3. But passing a stream as :output to run-program, that stream is closed
when the process finishes. I think that's a bug.

Bart

From: Raymond Toy on
Bart W wrote:
>>>>>> "Raymond" == Raymond Toy <toy.raymond(a)gmail.com> writes:
>
> Raymond> Bart Wage wrote:
> >>
>> Any other suggestions? Surely it must be possible to pass a stream of
> >> bytes to a program somehow?
>
> Raymond> Sorry for the delay. I see now that if you specify a
> Raymond> stream, cmucl will basically write out the data more or
> Raymond> less directly from the string, which contains 16-bit
> Raymond> characters. This isn't what we want.
>
> Raymond> run-program needs to be updated somehow.
>
> Raymond> But until then, perhaps some variant of the following will
> Raymond> work. I tested it very briefly.
>
> Thanks, that worked! My problems are solved, but here are some more

Great! Here's another variant that is better and probably much faster:

(defun in-out2 (byte-array output-file program &optional arguments)
(let ((proc (ext:run-program program arguments
:input :stream
:output output-file :wait nil
:if-output-exists :supersede)))
(write-vector byte-array (process-input proc))
(close (process-input proc))
(process-close proc)))

The byte array has to be some kind of specialized array.

> points:
>
> 1. A similar problem exists with binary output and :output :stream.

I suspected that, but I haven't yet tried it. I think a similar
technique can be used as shown above.

>
> 2. The documentation (at
> http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc45)
> does not mention that the :output argument may be specified as a stream,
> but it may and the comments in the source code (run-program.lisp) say so
> too.

I'll update that soon.

>
> 3. But passing a stream as :output to run-program, that stream is closed
> when the process finishes. I think that's a bug.
>

I'll have to think about that. Thanks for the information.

Ray
From: Rob Warnock on
Raymond Toy <toy.raymond(a)gmail.com> wrote:
+---------------
| Bart W wrote:
| > 3. But passing a stream as :output to run-program, that stream is closed
| > when the process finishes. I think that's a bug.
|
| I'll have to think about that.
+---------------

Please do think about it very carefully before changing anything.

While unconditionally closing the stream is not always the correct
behavior, neither is leaving the stream open!! One can easily construct
use cases for RUN-PROGRAM that prefer one behavior over the other.
[Hint: Think "pipe"...]

Perhaps the behavior should be controllable by a new keyword option,
but the default should *definitely* remain the same as it is now!


-Rob

-----
Rob Warnock <rpw3(a)rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

From: Raymond Toy on
On 12/30/09 3:17 AM, Rob Warnock wrote:
> Raymond Toy <toy.raymond(a)gmail.com> wrote:
> +---------------
> | Bart W wrote:
> | > 3. But passing a stream as :output to run-program, that stream is closed
> | > when the process finishes. I think that's a bug.
> |
> | I'll have to think about that.
> +---------------
>
> Please do think about it very carefully before changing anything.
>
> While unconditionally closing the stream is not always the correct
> behavior, neither is leaving the stream open!! One can easily construct
> use cases for RUN-PROGRAM that prefer one behavior over the other.
> [Hint: Think "pipe"...]

[sorry for the delay]

For the pipe use-case, wouldn't you just use the capabilities of
run-program to create the necessary streams for you if you're expecting
them to be closed by run-program anyway?

I assume that if someone wants to pass in a stream, he probably wants to
control it too. The typical (?) use would be using with-open-file and
that complains if run-program closes the stream.

>
> Perhaps the behavior should be controllable by a new keyword option,
> but the default should *definitely* remain the same as it is now!

Yes, I wouldn't want to gratuitously break existing programs, unless
absolutely necessary.

Ray
P.S. Perhaps this is better discussed on the cmucl list instead?