[32903] in Perl-Users-Digest
Perl-Users Digest, Issue: 4181 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 28 18:09:31 2014
Date: Fri, 28 Mar 2014 15:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 28 Mar 2014 Volume: 11 Number: 4181
Today's topics:
c call <gravitalsun@hotmail.foo>
Re: c call <rweikusat@mobileactivedefense.com>
Re: c call <peter@makholm.net>
Re: c call <news@todbe.com>
Re: c call <rweikusat@mobileactivedefense.com>
CGI::Carp and File::Temp <gravitalsun@hotmail.foo>
Re: CGI::Carp and File::Temp <rweikusat@mobileactivedefense.com>
Re: CGI::Carp and File::Temp <gravitalsun@hotmail.foo>
Re: CGI::Carp and File::Temp <rweikusat@mobileactivedefense.com>
Re: CGI::Carp and File::Temp <gravitalsun@hotmail.foo>
Re: CGI::Carp and File::Temp <rweikusat@mobileactivedefense.com>
Re: CGI::Carp and File::Temp <gravitalsun@hotmail.foo>
Re: CGI::Carp and File::Temp <rweikusat@mobileactivedefense.com>
Cost of qr// vs m// <adrien.barreau@live.fr>
Re: Cost of qr// vs m// <hSoPrAsMt@raSdPnAeMrs.de>
Re: Cost of qr// vs m// <rweikusat@mobileactivedefense.com>
Re: Cost of qr// vs m// <rweikusat@mobileactivedefense.com>
Re: Cost of qr// vs m// <hSoPrAsMt@raSdPnAeMrs.de>
Re: Cost of qr// vs m// <rvtol+usenet@xs4all.nl>
Re: Unbuffered I/O problem <gamo@telecable.es>
Re: Unbuffered I/O problem <rweikusat@mobileactivedefense.com>
Re: Unbuffered I/O problem <xhoster@gmail.com>
unbuffered i/o to a pipe <No_Spam@deezee.org>
Re: unbuffered i/o to a pipe <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 26 Mar 2014 14:35:43 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: c call
Message-Id: <lguhhp$2f5m$1@news.ntua.gr>
At windows I can call a C function as end user, using the Win32::API
Can I do something similar at Linux ?
Do not mention the inline because we assume that there is so access to C
source.
------------------------------
Date: Wed, 26 Mar 2014 13:33:25 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: c call
Message-Id: <87wqfh84pm.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> At windows I can call a C function as end user, using the Win32::API
> Can I do something similar at Linux ?
AFAIK, no, as this would require generating different kinds of 'glue
code' at run time, depending on whatever the calling conventions of the
current platform happen to be.
------------------------------
Date: Wed, 26 Mar 2014 15:13:50 +0100
From: Peter Makholm <peter@makholm.net>
Subject: Re: c call
Message-Id: <87bnwtjbdt.fsf@vps1.hacking.dk>
George Mpouras <gravitalsun@hotmail.foo> writes:
> At windows I can call a C function as end user, using the Win32::API
> Can I do something similar at Linux ?
> Do not mention the inline because we assume that there is so access to
> C source.
Never tried it myself, but try look at FFI::Library or FFI::Raw.
//Makholm
------------------------------
Date: Thu, 27 Mar 2014 12:17:40 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: c call
Message-Id: <lh1th2$8jn$2@dont-email.me>
On 3/26/2014 06:33, Rainer Weikusat wrote:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> At windows I can call a C function as end user, using the Win32::API
>> Can I do something similar at Linux ?
>
> AFAIK, no, as this would require generating different kinds of 'glue
> code' at run time, depending on whatever the calling conventions of the
> current platform happen to be.
Easy enough to do, I would think, if you compile in a constant that tells
you which calling convention the compiler is using.
------------------------------
Date: Fri, 28 Mar 2014 13:55:34 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: c call
Message-Id: <871txmpgvd.fsf@sable.mobileactivedefense.com>
"$Bill" <news@todbe.com> writes:
> On 3/26/2014 06:33, Rainer Weikusat wrote:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> At windows I can call a C function as end user, using the Win32::API
>>> Can I do something similar at Linux ?
>>
>> AFAIK, no, as this would require generating different kinds of 'glue
>> code' at run time, depending on whatever the calling conventions of the
>> current platform happen to be.
>
> Easy enough to do, I would think, if you compile in a constant that tells
> you which calling convention the compiler is using.
I don't know how the FFI module works internally (and can't easily
determine that at the moment), but a naive approach would need explicitly written,
platform-specific machine code.
------------------------------
Date: Wed, 26 Mar 2014 15:13:49 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: CGI::Carp and File::Temp
Message-Id: <lgujp7$2kg2$1@news.ntua.gr>
When I use CGI::Carp and File::Temp my code is crashing without obvious
reason (Centos 6.5 , Perl 5.10) For a proof of bug you can run
perl -e "use CGI::Carp; use File::Temp"
The only workaround is to "zero" the die using the
local *CORE::GLOBAL::die = sub {};
at several places at /usr/share/perl5/File/Temp.pm
Any better idea ?
------------------------------
Date: Wed, 26 Mar 2014 13:37:31 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: CGI::Carp and File::Temp
Message-Id: <87ppl984is.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> When I use CGI::Carp and File::Temp my code is crashing without
> obvious reason (Centos 6.5 , Perl 5.10) For a proof of bug you can run
>
> perl -e "use CGI::Carp; use File::Temp"
Works for me (the example above) on both 5.10.0 and 5.10.1 (rather
ancient Ubuntu and moderately ancient Debian).
------------------------------
Date: Wed, 26 Mar 2014 16:14:54 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: CGI::Carp and File::Temp
Message-Id: <lgunbp$2sng$1@news.ntua.gr>
Στις 26/3/2014 15:37, ο/η Rainer Weikusat έγραψε:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>> When I use CGI::Carp and File::Temp my code is crashing without
>> obvious reason (Centos 6.5 , Perl 5.10) For a proof of bug you can run
>>
>> perl -e "use CGI::Carp; use File::Temp"
>
> Works for me (the example above) on both 5.10.0 and 5.10.1 (rather
> ancient Ubuntu and moderately ancient Debian).
>
I cpanm the latest modules and now the command works also for me, BUT
still not working at real script.
I have drill down the problem to the following piece of code that
reproduce the bad behavior
#!/usr/bin/perl
use strict;
use CGI::Carp;
BEGIN { CGI::Carp::set_die_handler( sub {print $_[0]} ) };
use File::Temp;
I get
our vendor has not defined Fcntl macro O_NOINHERIT, used at
/usr/share/perl5/File/Temp.pm line 114.
Your vendor has not defined Fcntl macro O_EXLOCK, used at
/usr/share/perl5/File/Temp.pm line 122.
Your vendor has not defined Fcntl macro O_TEMPORARY, used at
/usr/share/perl5/File/Temp.pm line 144.
------------------------------
Date: Wed, 26 Mar 2014 20:56:21 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: CGI::Carp and File::Temp
Message-Id: <87lhvw7k7e.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> Στις 26/3/2014 15:37, ο/η Rainer Weikusat έγραψε:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>> When I use CGI::Carp and File::Temp my code is crashing without
>>> obvious reason (Centos 6.5 , Perl 5.10) For a proof of bug you can run
>>>
>>> perl -e "use CGI::Carp; use File::Temp"
>>
>> Works for me (the example above) on both 5.10.0 and 5.10.1 (rather
>> ancient Ubuntu and moderately ancient Debian).
>>
> I cpanm the latest modules and now the command works also for me, BUT
> still not working at real script.
> I have drill down the problem to the following piece of code that
> reproduce the bad behavior
>
>
> #!/usr/bin/perl
> use strict;
> use CGI::Carp;
> BEGIN { CGI::Carp::set_die_handler( sub {print $_[0]} ) };
> use File::Temp;
>
>
>
> I get
>
> our vendor has not defined Fcntl macro O_NOINHERIT, used at
> /usr/share/perl5/File/Temp.pm line 114.
> Your vendor has not defined Fcntl macro O_EXLOCK, used at
> /usr/share/perl5/File/Temp.pm line 122.
> Your vendor has not defined Fcntl macro O_TEMPORARY, used at
> /usr/share/perl5/File/Temp.pm line 144.
I've spent some time looking into this: The File::Temp code tries to
determine if the macros exist on the current platform by accessing them
from within eval-blocks with $SIG{__DIE__} locally bound to sub {} to
"Make sure that redefined die handlers do not cause problems
e.g. CGI::Carp"
The problem appears to be that CGI::Carp overrides CORE::GLOBAL::die
with a subroutine which calls the registered die handler via
$CGI::Carp::DIE_HANDLER if that is set instead of invoking 'the real
die' which would use $SIG{__DIE__} instead.
----------
BEGIN {
local $CGI::Carp::DIE_HANDLER;
require File::Temp;
}
----------
could be used to work around that. IMHO, that's a bug in CGI::Carp.
------------------------------
Date: Thu, 27 Mar 2014 00:00:42 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: CGI::Carp and File::Temp
Message-Id: <lgvimb$1qv3$1@news.ntua.gr>
>
> The problem appears to be that CGI::Carp overrides CORE::GLOBAL::die
> with a subroutine which calls the registered die handler via
> $CGI::Carp::DIE_HANDLER if that is set instead of invoking 'the real
> die' which would use $SIG{__DIE__} instead.
>
> ----------
> BEGIN {
> local $CGI::Carp::DIE_HANDLER;
> require File::Temp;
> }
> ----------
>
> could be used to work around that. IMHO, that's a bug in CGI::Carp.
>
if the BEGIN is the last line e.g..
...
use File::Temp;
BEGIN { CGI::Carp::set_die_handler( sub {print $_[0]} ) };
it works without error,even if the BEGIN is executed before anything
else. So may it have to with principle of indeterminacy also
------------------------------
Date: Thu, 27 Mar 2014 13:38:23 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: CGI::Carp and File::Temp
Message-Id: <8738i3pxrk.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
>> The problem appears to be that CGI::Carp overrides CORE::GLOBAL::die
>> with a subroutine which calls the registered die handler via
>> $CGI::Carp::DIE_HANDLER if that is set instead of invoking 'the real
>> die' which would use $SIG{__DIE__} instead.
>>
>> ----------
>> BEGIN {
>> local $CGI::Carp::DIE_HANDLER;
>> require File::Temp;
>> }
>> ----------
>>
>> could be used to work around that. IMHO, that's a bug in CGI::Carp.
>>
>
>
> if the BEGIN is the last line e.g..
> ...
> use File::Temp;
> BEGIN { CGI::Carp::set_die_handler( sub {print $_[0]} ) };
>
> it works without error,even if the BEGIN is executed before anything
> else.
As can be determined by creating a file named b.pm with the following
content:
----
print "1\n";
----
and then executing
perl -e 'use b; BEGIN { print "2\n"; }'
perl executes the file b.pm prior to the BEGIN-block encountered after
the use statement. For File::Temp, this would mean it executes the
init-code testing the flags before $CGI::Carp::DIE_HANDLER gets set in
you example and hence, everything works as desired.
------------------------------
Date: Thu, 27 Mar 2014 16:24:53 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: CGI::Carp and File::Temp
Message-Id: <lh1caf$1bqd$1@news.ntua.gr>
b; BEGIN { print "2\n"; }'
>
> perl executes the file b.pm prior to the BEGIN-block encountered after
> the use statement. For File::Temp, this would mean it executes the
> init-code testing the flags before $CGI::Carp::DIE_HANDLER gets set in
> you example and hence, everything works as desired.
>
true, but weird
print "start\n";
BEGIN { print "begin\n" };
------------------------------
Date: Thu, 27 Mar 2014 14:43:00 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: CGI::Carp and File::Temp
Message-Id: <87ob0raeiz.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
> b; BEGIN { print "2\n"; }'
>>
>> perl executes the file b.pm prior to the BEGIN-block encountered after
>> the use statement. For File::Temp, this would mean it executes the
>> init-code testing the flags before $CGI::Carp::DIE_HANDLER gets set in
>> you example and hence, everything works as desired.
>>
>
> true, but weird
>
> print "start\n";
> BEGIN { print "begin\n" };
It's actually documented behaviour: 'do EXPR' can be used to execute a
file, require ... uses do .... to read a library file which implies that
it is getting executed and use ... is by defintion identical to
BEGIN { require ...; ...->import(...); } which implies that the file
gets executed from within a BEGIN-block in this case. This BEGIN-block
will be executed as soon as it is encountered which means prior to all
BEGIN-blocks encountered after it (and after all BEGIN-blocks
encountered earlier).
------------------------------
Date: Fri, 28 Mar 2014 13:32:07 +0100
From: Adrien BARREAU <adrien.barreau@live.fr>
Subject: Cost of qr// vs m//
Message-Id: <lh3q47$ubp$1@dont-email.me>
Hello.
Here is a piece of code:
---
#!/usr/bin/perl
use strict;
use warnings;
use Time::HiRes;
use Benchmark;
my @strings = map { sprintf "%08X\n", rand(0xffffffff); } 1 .. 100;
my $r = qr/some/;
sub compiled
{
/$r/ for (@strings)
}
sub live
{
/some/ for (@strings)
}
my $results = Benchmark::timethese(100000, {
'compiled' => \&compiled,
'live' => \&live,
});
Benchmark::cmpthese($results);
---
Running it gives me:
Benchmark: timing 100000 iterations of compiled, live...
compiled: 2 wallclock secs ( 2.67 usr + 0.00 sys = 2.67 CPU) @
37453.18/s (n=100000)
live: 1 wallclock secs ( 0.90 usr + 0.00 sys = 0.90 CPU) @
111111.11/s (n=100000)
Rate compiled live
compiled 37453/s -- -66%
live 111111/s 197% --
On: This is perl 5, version 14, subversion 2 (v5.14.2) built for
x86_64-linux-gnu-thread-multi
I don't really understand these results: qr// seems to cost more, but I
don't find anything in the perldoc about that.
Do I miss an error in this benchmark?
Does somebody have any information about that overhead I see?
If I had to guess, I would suspect dereferencing cost of a Regexp ref.
Could it be right?
Adrien.
------------------------------
Date: Fri, 28 Mar 2014 14:44:23 +0100
From: "Horst-W. Radners" <hSoPrAsMt@raSdPnAeMrs.de>
Subject: Re: Cost of qr// vs m//
Message-Id: <lh3ubn$5mo$1@online.de>
Adrien BARREAU schrieb am 28.03.2014 13:32:
> [...]
> my $r = qr/some/;
>
> sub compiled
> {
> /$r/ for (@strings)
> [...]
That's done twice ...
Try
$r for (@strings)
and you will see a speed advantage for the compiled version.
Regards, Horst
--
<remove S P A M 2x from my email address to get the real one>
------------------------------
Date: Fri, 28 Mar 2014 13:51:54 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Cost of qr// vs m//
Message-Id: <8761myph1h.fsf@sable.mobileactivedefense.com>
Adrien BARREAU <adrien.barreau@live.fr> writes:
> Here is a piece of code:
>
> ---
> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use Time::HiRes;
> use Benchmark;
>
> my @strings = map { sprintf "%08X\n", rand(0xffffffff); } 1 .. 100;
>
> my $r = qr/some/;
>
> sub compiled
> {
> /$r/ for (@strings)
> }
>
> sub live
> {
> /some/ for (@strings)
> }
>
>
> my $results = Benchmark::timethese(100000, {
> 'compiled' => \&compiled,
> 'live' => \&live,
> });
>
> Benchmark::cmpthese($results);
> ---
>
> Running it gives me:
>
> Benchmark: timing 100000 iterations of compiled, live...
> compiled: 2 wallclock secs ( 2.67 usr + 0.00 sys = 2.67 CPU) @
> 37453.18/s (n=100000)
> live: 1 wallclock secs ( 0.90 usr + 0.00 sys = 0.90 CPU) @
> 111111.11/s (n=100000)
> Rate compiled live
> compiled 37453/s -- -66%
> live 111111/s 197% --
[...]
> I don't really understand these results: qr// seems to cost more, but
> I don't find anything in the perldoc about that.
This mystery is easily explained when looking the the decompiled/
disassembled internal represention (I've omitted everything except the
actual loop). 'live' becomes
[rw@sable]/tmp#perl -MO=Concise,live b.pl
main::live:
- <1> null K/1 ->b
a <|> and(other->7) K/1 ->b
9 <0> iter s ->a
- <@> lineseq sK ->-
7 </> match(/"some.*3"/) v/RTIME ->8
8 <0> unstack s ->9
In contrast to that, 'compiled' is
- <1> null K/1 ->i
h <|> and(other->b) K/1 ->i
g <0> iter s ->h
- <@> lineseq sK ->-
e </> match() vK/RTIME ->f
d <|> regcomp(other->e) sK/1 ->e
b <1> regcreset sK/1 ->c
c <0> padsv[$r:601,602] s ->d
f <0> unstack s ->g
For the qr'ed case, it actually calls into the top-level regexp compiler
routine (pp_regcomp) on each iteration which gets the already compiled
regexp out of the passed argument in case contained a (reference) to an
already compiled regexp instead of calling the 'real' regexp compiler.
Judging from the (5.10.1) C-code, the compiled regexp is also copied to
'a temporary object' for each match.
A more interesting result: Adding a
my $other = 'some';
sub interpolated
{
/$other/ for @strings;
}
shows that this is faster (at least for me) as well. Presumably, this
happens because the 'last regex compiled for this op' is cached 'in the
op' and it will be re-used without recompilation if the 'source pattern'
didn't really change. In this case, no 'temporary copy' is made.
------------------------------
Date: Fri, 28 Mar 2014 13:57:57 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Cost of qr// vs m//
Message-Id: <87ha6ie87u.fsf@sable.mobileactivedefense.com>
"Horst-W. Radners" <hSoPrAsMt@raSdPnAeMrs.de> writes:
> Adrien BARREAU schrieb am 28.03.2014 13:32:
>> [...]
>> my $r = qr/some/;
>>
>> sub compiled
>> {
>> /$r/ for (@strings)
>> [...]
>
> That's done twice ...
> Try
> $r for (@strings)
> and you will see a speed advantage for the compiled version.
That's hardly suprising, given that this code doesn't do a regexp-match
at all :-).
------------------------------
Date: Fri, 28 Mar 2014 15:16:25 +0100
From: "Horst-W. Radners" <hSoPrAsMt@raSdPnAeMrs.de>
Subject: Re: Cost of qr// vs m//
Message-Id: <lh407p$9gh$1@online.de>
Rainer Weikusat schrieb am 28.03.2014 14:57:
> "Horst-W. Radners" <hSoPrAsMt@raSdPnAeMrs.de> writes:
>> Adrien BARREAU schrieb am 28.03.2014 13:32:
>>> [...]
>>> my $r = qr/some/;
>>>
>>> sub compiled
>>> {
>>> /$r/ for (@strings)
>>> [...]
>>
>> That's done twice ...
>> Try
>> $r for (@strings)
>> and you will see a speed advantage for the compiled version.
>
> That's hardly suprising, given that this code doesn't do a regexp-match
> at all :-).
>
Ah, sorry, I misunderstood the 'used standalone' in the qr section of
perldoc perlop.
Regards, Horst
--
<remove S P A M 2x from my email address to get the real one>
------------------------------
Date: Fri, 28 Mar 2014 21:39:39 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
To: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Cost of qr// vs m//
Message-Id: <5335DE0B.8000509@xs4all.nl>
On 2014-03-28 14:51, Rainer Weikusat wrote:
> A more interesting result: Adding a
>
> my $other = 'some';
>
> sub interpolated
> {
> /$other/ for @strings;
> }
>
> shows that this is faster (at least for me) as well. Presumably, this
> happens because the 'last regex compiled for this op' is cached 'in the
> op' and it will be re-used without recompilation if the 'source pattern'
> didn't really change. In this case, no 'temporary copy' is made.
With a recent Perl:
perl -Mstrict -wE'
use Benchmark ":hireswallclock";
say "\nPerl $]\n";
my @strings = map { sprintf "%08X\n", rand(0xffffffff); } 1 .. 100;
my $qr = qr/some/;
my $some = "some";
my $results = Benchmark::timethese( -3, {
compiled => sub { /$qr/ for @strings },
literal => sub { /some/ for @strings },
interpol => sub { /$some/ for @strings },
});
say "";
Benchmark::cmpthese($results);
'
Perl 5.019006
Benchmark: running compiled, interpol, literal for at least 3 CPU seconds...
compiled: 3.14617 wallclock secs ( 3.13 usr + 0.00 sys = 3.13 CPU)
@ 19945.69/s (n=62430)
interpol: 3.03571 wallclock secs ( 3.01 usr + 0.00 sys = 3.01 CPU)
@ 59009.30/s (n=177618)
literal: 3.09564 wallclock secs ( 3.09 usr + 0.00 sys = 3.09 CPU)
@ 106284.79/s (n=328420)
Rate compiled interpol literal
compiled 19946/s -- -66% -81%
interpol 59009/s 196% -- -44%
literal 106285/s 433% 80% --
--
Ruud
------------------------------
Date: Wed, 26 Mar 2014 11:05:55 +0100
From: gamo <gamo@telecable.es>
Subject: Re: Unbuffered I/O problem
Message-Id: <lgu8q6$e57$1@speranza.aioe.org>
El 23/03/14 16:42, Dave Saville escribi:
> open my $PACAT, '|pacat ...................
> my $old_fh = select $PACAT; $| = 1; select $old_fh;
>
That could be wrong because, according to the documentation, $|=1
affects to the currently selected I/O, and you do a select after that.
$| If set to nonzero, forces a flush right away and after
every write or print on the currently selected output channel.
Check that, moving the $|=1 to after the relevant last select.
Good luck.
> while (1)
> {
> # generate $stuff
> print $PACAT $stuff;
> }
>
> And it just sits there doing nothing - I assume something has blocked.
>
--
http://www.telecable.es/personales/gamo/
------------------------------
Date: Wed, 26 Mar 2014 13:27:11 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Unbuffered I/O problem
Message-Id: <871txp9jkg.fsf@sable.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 23/03/14 16:42, Dave Saville escribi:
>> open my $PACAT, '|pacat ...................
>> my $old_fh = select $PACAT; $| = 1; select $old_fh;
>>
>
> That could be wrong because, according to the documentation, $|=1
> affects to the currently selected I/O, and you do a select after that.
>
> $| If set to nonzero, forces a flush right away and after
> every write or print on the currently selected output channel.
perldoc -f select contains this exact example:
FILEHANDLE may be an expression whose value gives the name of
the actual filehandle. Thus:
$oldfh = select(STDERR); $| = 1; select($oldfh);
See also select((select(s),$|=1)[0]),
http://stackoverflow.com/questions/196754/what-does-selectselects-10-do-in-perl
------------------------------
Date: Wed, 26 Mar 2014 17:54:01 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Unbuffered I/O problem
Message-Id: <lgvsrp$5k3$1@dont-email.me>
On 03/23/14 08:42, Dave Saville wrote:
> I am playing with sending audio to stereo speakers as part of a bigger
> project. At the moment I am just generating a sine wave that moves
> from left to right.
>
> I pipe the data to pacat a sample at a time.
>
> open my $PACAT, '|pacat ...................
>
> while(1)
> {
> # generate $stuff - This is the angle sample value
> print $PACAT $stuff; #
> }
>
> This works but is a little jerky. Wondering if it were a buffering
> problem I tried to make it unbuffered.
>
> open my $PACAT, '|pacat ...................
> my $old_fh = select $PACAT; $| = 1; select $old_fh;
>
> while (1)
> {
> # generate $stuff
> print $PACAT $stuff;
> }
>
> And it just sits there doing nothing - I assume something has blocked.
>
Please post code that compiles and does something.
I'm willing you help you with perl, less willing to do extensive
speculation about what the "...." and "# generate $stuff" might be
concealing.
In any case, it works for me if I remove the ..., balance the quotes,
and just set my $stuff=random();
Xho
------------------------------
Date: Wed, 26 Mar 2014 15:23:11 +0000 (UTC)
From: "Dave Saville" <No_Spam@deezee.org>
Subject: unbuffered i/o to a pipe
Message-Id: <fV45K0OBJxbE-pn2-wiNhRqfDRs5L@paddington.bear.den>
I am playing with a raspberry pi with some generated stereo piped to
pacat. This is for a larger project but for this I just have a sine
wave that moves across the speakers for a few seconds. It stutters so
I wondered if there is any buffering going on when you open like so:
my $pacat = sprintf "| pacat --................
open my $PACAT, $pacat or die "Can't open $pacat $!";
If there is buffering how does one turn it off?
my $old_fh = select $PACAT; $| = 1; select $old_fh;
Does not make any difference. Of course it may be something completely
different causing the stutter - but things like mplayer work fine with
no stutter.
TIA
--
Regards
Dave Saville
------------------------------
Date: Wed, 26 Mar 2014 15:57:29 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: unbuffered i/o to a pipe
Message-Id: <87r45p7y1i.fsf@sable.mobileactivedefense.com>
"Dave Saville" <No_Spam@deezee.org> writes:
> I am playing with a raspberry pi with some generated stereo piped to
> pacat. This is for a larger project but for this I just have a sine
> wave that moves across the speakers for a few seconds. It stutters so
> I wondered if there is any buffering going on when you open like so:
>
> my $pacat = sprintf "| pacat --................
> open my $PACAT, $pacat or die "Can't open $pacat $!";
>
> If there is buffering how does one turn it off?
>
> my $old_fh = select $PACAT; $| = 1; select $old_fh;
>
> Does not make any difference.
It does, cf
----------
use POSIX;
my ($fh, $rc);
my ($rd, $wr, $fh);
pipe($rd, $wr);
if (fork() == 0) {
close($wr);
while ($rc = <$rd>) {
print STDERR ("pong\n");
}
_exit(0);
}
close($rd);
$fh = select($wr);
$| = 1;
select($fh);
for (0 .. 9) {
print STDERR ("ping\n");
print $wr ("ping\n");
sleep(1);
}
----------
Depending on whether autoflush is set or not, this will either print
ping - pong alternatingly or print 10 pings followed by 10 pongs. But
you should really bypass the buffering altogether for 'realtime
communication', aka 'use syswrite'.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4181
***************************************
