[Zope-Perl] Re: Weird output in pyperl

[Jeff Bachtel]

On Mon, Jul 11, 2005 at 08:16:54PM +0100, Felix Schwarz wrote:
> Hi Jeff,
> 
> Jeff Bachtel wrote:
> > On Mon, Jul 11, 2005 at 07:24:29PM +0100, Felix Schwarz wrote:
> >>
> >> Where would you start looking given my bug description?
> 
> > I'd check for some error being returned by popen. I'd have callee
> > touch a file (inside Perl) to make sure evaluation was happening
> > properly. Given all of that, I'd start looking to see what file
> > descriptors were being given to child processes and piped, to see if
> > that was getting mangled.
> 
> Thanks for your comments. After some tests I found out, that...
> * perl.eval is being executed. "system('touch pyperl.felix.log');"
>   creates a new file as expected.
> * My problem has something to do with buffering. After eval'ing this
>   code
>     print 'Perl\n';
>     system('touch pyperl.felix.log');
>   the "Perl" string appeared in caller.py. I figured out that "$| = 1;"
>   before the Perl print has the same effect.
> 
> Therefore I think that pyperl should force the Perl interpreter to
> flush all buffers before returning to Python. And there is another
> bug: The order of the items is reversed.

Have you tried running pclose? My pipe-fu isn't great, but the unix
manpage indicates this can be used to close the stream, which might
(or might not) force the flushing of the associated buffered output.

The unix manpage for the popen libc call might give you further ideas
on things to try. I didn't deeply investigate how Perl was invoked by
pyperl, and whether the idea of forcing Perl into an unbuffered mode
is feasible.

> 
> I expected
>   Python
>   Perl
>   eval exit code: ...
> The first and the last one are printed by Python code the last one by
> Perl code. But the output is:
>   Perl
>   Python
>   eval exit code: ...
> 
> That means that all Python buffers should be flushed before entering
> the Perl eval, right?
> 
> Does anybody have any experience with Un*x popen and buffering? If I
> run callee.py separately the order of the items is okay. Only
> executing it with popen reveals the bug.

I don't believe this is a bug so much as an artifact of the way popen
and its buffering work. The difference between, in this case, being
that the behaviour is deterministic but painful to the user.

jeff

>     
> -- 
> Felix