[32902] in Perl-Users-Digest
Perl-Users Digest, Issue: 4180 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 26 05:17:34 2014
Date: Wed, 26 Mar 2014 02:17:07 -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 Wed, 26 Mar 2014 Volume: 11 Number: 4180
Today's topics:
Re: dynamically creating a hash from an array <gravitalsun@hotmail.foo>
Re: dynamically creating a hash from an array <rweikusat@mobileactivedefense.com>
Re: dynamically creating a hash from an array <derykus@gmail.com>
Re: dynamically creating a hash from an array <rweikusat@mobileactivedefense.com>
Re: dynamically creating a hash from an array <derykus@gmail.com>
Re: dynamically creating a hash from an array <kaz@kylheku.com>
Re: dynamically creating a hash from an array (Tim McDaniel)
Re: dynamically creating a hash from an array <derykus@gmail.com>
Re: dynamically creating a hash from an array <derykus@gmail.com>
Re: dynamically creating a hash from an array <rweikusat@mobileactivedefense.com>
Re: dynamically creating a hash from an array <rweikusat@mobileactivedefense.com>
Re: dynamically creating a hash from an array <rweikusat@mobileactivedefense.com>
Google spreadsheets with WWW::Mechanize <marc.girod@gmail.com>
Re: Google spreadsheets with WWW::Mechanize <marc.girod@gmail.com>
Re: Google spreadsheets with WWW::Mechanize <marc.girod@gmail.com>
Re: Google spreadsheets with WWW::Mechanize <marc.girod@gmail.com>
Re: Google spreadsheets with WWW::Mechanize <marc.girod@gmail.com>
Unbuffered I/O problem <No_Spam@deezee.org>
Re: Unbuffered I/O problem <rweikusat@mobileactivedefense.com>
Re: Unbuffered I/O problem <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 24 Mar 2014 10:06:04 +0200
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: Re: dynamically creating a hash from an array
Message-Id: <lgop06$1421$1@news.ntua.gr>
cool !
------------------------------
Date: Mon, 24 Mar 2014 12:31:54 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <874n2neq11.fsf@sable.mobileactivedefense.com>
George Mpouras <gravitalsun@hotmail.foo> writes:
[PadWalker]
> cool !
"I wouldn't recommend using PadWalker directly in production code"
http://search.cpan.org/~robin/PadWalker-1.98/PadWalker.pm
------------------------------
Date: Mon, 24 Mar 2014 13:20:49 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <lgq433$9qn$1@speranza.aioe.org>
On 3/24/2014 5:31 AM, Rainer Weikusat wrote:
> George Mpouras <gravitalsun@hotmail.foo> writes:
>
> [PadWalker]
>
>> cool !
>
> "I wouldn't recommend using PadWalker directly in production code"
>
> http://search.cpan.org/~robin/PadWalker-1.98
Also mentions "PadWalker is particularly useful for debugging. It's
even used by Perl's built-in debugger..."
So it may be worth the risk here. YMMV.
--
Charles DeRykus
------------------------------
Date: Mon, 24 Mar 2014 22:52:42 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <877g7j1a6d.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 3/24/2014 5:31 AM, Rainer Weikusat wrote:
>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>
>> [PadWalker]
>>
>>> cool !
>>
>> "I wouldn't recommend using PadWalker directly in production code"
>>
>> http://search.cpan.org/~robin/PadWalker-1.98
>
> Also mentions "PadWalker is particularly useful for debugging. It's
> even used by Perl's built-in debugger..."
>
> So it may be worth the risk here. YMMV.
Being able to replace a tiny bit of 'safe' (in the sense that it works
only with documented interfaces and doesn't fiddle around with internal
data structures of the interpreter) with a fairly large bit of (not
exactly expertly written) C code isn't worth any risks.
------------------------------
Date: Mon, 24 Mar 2014 19:03:15 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <lgqo59$q3r$1@speranza.aioe.org>
On 3/24/2014 3:52 PM, Rainer Weikusat wrote:
> Charles DeRykus <derykus@gmail.com> writes:
>> On 3/24/2014 5:31 AM, Rainer Weikusat wrote:
>>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>
>>> [PadWalker]
>>>
>>>> cool !
>>>
>>> "I wouldn't recommend using PadWalker directly in production code"
>>>
>>> http://search.cpan.org/~robin/PadWalker-1.98
>>
>> Also mentions "PadWalker is particularly useful for debugging. It's
>> even used by Perl's built-in debugger..."
>>
>> So it may be worth the risk here. YMMV.
>
> Being able to replace a tiny bit of 'safe' (in the sense that it works
> only with documented interfaces and doesn't fiddle around with internal
> data structures of the interpreter) with a fairly large bit of (not
> exactly expertly written) C code isn't worth any risks.
>
That's overreaching IMO. You're deprecating the value of a module
even used by "Perl's built-in debugger" and especially, in this
case, since the use was limited to debug. You should throw out Perl's
built-in debugger then for the same reason. Caution tips over and
becomes FUD.
--
Charles DeRykus
------------------------------
Date: Tue, 25 Mar 2014 04:37:42 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <20140324210207.335@kylheku.com>
On 2014-03-25, Charles DeRykus <derykus@gmail.com> wrote:
> On 3/24/2014 3:52 PM, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:
>>> On 3/24/2014 5:31 AM, Rainer Weikusat wrote:
>>>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>>
>>>> [PadWalker]
>>>>
>>>>> cool !
>>>>
>>>> "I wouldn't recommend using PadWalker directly in production code"
>>>>
>>>> http://search.cpan.org/~robin/PadWalker-1.98
>>>
>>> Also mentions "PadWalker is particularly useful for debugging. It's
>>> even used by Perl's built-in debugger..."
>>>
>>> So it may be worth the risk here. YMMV.
>>
>> Being able to replace a tiny bit of 'safe' (in the sense that it works
>> only with documented interfaces and doesn't fiddle around with internal
>> data structures of the interpreter) with a fairly large bit of (not
>> exactly expertly written) C code isn't worth any risks.
>>
>
> That's overreaching IMO. You're deprecating the value of a module
> even used by "Perl's built-in debugger" and especially, in this
> case, since the use was limited to debug. You should throw out Perl's
> built-in debugger then for the same reason. Caution tips over and
> becomes FUD.
A lexical environment is not something that is passed down to a child function:
doing so (as an exposed feature) makes it a de facto dynamic environment.
Programs that depend on a lexical environment being treated as a dynamic
environment (via some internal escape hatch) should be written with the
understanding that the author is wrecking the lexical scope paradigm.
This falls into the "dumb hack" category when used other than for the intended
purpose of supporting the debugger as part of the implemenation. If Perl ever
becomes a properly compiled language, this area will have to drastically
change, such that programs which depend on it will break.
------------------------------
Date: Tue, 25 Mar 2014 05:32:19 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: dynamically creating a hash from an array
Message-Id: <lgr4d3$6i4$1@reader1.panix.com>
In article <lgqo59$q3r$1@speranza.aioe.org>,
Charles DeRykus <derykus@gmail.com> wrote:
>Rainer Weikusat wrote [against using PadWalker]
>
>That's overreaching IMO. You're deprecating the value of a module
So far as I've seen, that's Rainer's usual approach to modules from
CPAN, for example, so I'm not surprised to see the same opinion here.
You write that PadWalker is used in the Perl debugger, but
perl -e 'use PadWalker'
fails for me on the systems I have available, so I don't understand
what's going on with it.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Mon, 24 Mar 2014 23:12:25 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <lgr6oe$qdq$1@speranza.aioe.org>
On 3/24/2014 9:37 PM, Kaz Kylheku wrote:
> On 2014-03-25, Charles DeRykus <derykus@gmail.com> wrote:
>> On 3/24/2014 3:52 PM, Rainer Weikusat wrote:
>>> Charles DeRykus <derykus@gmail.com> writes:
>>>> On 3/24/2014 5:31 AM, Rainer Weikusat wrote:
>>>>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>>>
>>>>> [PadWalker]
>>>>>
>>>>>> cool !
>>>>>
>>>>> "I wouldn't recommend using PadWalker directly in production code"
>>>>>
>>>>> http://search.cpan.org/~robin/PadWalker-1.98
>>>>
>>>> Also mentions "PadWalker is particularly useful for debugging. It's
>>>> even used by Perl's built-in debugger..."
>>>>
>>>> So it may be worth the risk here. YMMV.
>>>
>>> Being able to replace a tiny bit of 'safe' (in the sense that it works
>>> only with documented interfaces and doesn't fiddle around with internal
>>> data structures of the interpreter) with a fairly large bit of (not
>>> exactly expertly written) C code isn't worth any risks.
>>>
>>
>> That's overreaching IMO. You're deprecating the value of a module
>> even used by "Perl's built-in debugger" and especially, in this
>> case, since the use was limited to debug. You should throw out Perl's
>> built-in debugger then for the same reason. Caution tips over and
>> becomes FUD.
>
> A lexical environment is not something that is passed down to a child function:
> doing so (as an exposed feature) makes it a de facto dynamic environment.
>
> Programs that depend on a lexical environment being treated as a dynamic
> environment (via some internal escape hatch) should be written with the
> understanding that the author is wrecking the lexical scope paradigm.
>
> This falls into the "dumb hack" category when used other than for the intended
> purpose of supporting the debugger as part of the implemenation. If Perl ever
> becomes a properly compiled language, this area will have to drastically
> change, such that programs which depend on it will break.
>
And the documentation makes it clear that it's particularly useful for
debugging...and not recommended for production code. You need enough
rope to climb into the nooks and crannies of a language even if it's
dangerous and tomorrow you may need a better rope. The "Perl Hacks"
segment on PadWalker shows a couple of cases where breaking
encapsulation is useful and a very apt rationale:
"It's scary and wrong, but sometimes it's just what you need".
--
Charles DeRykus
------------------------------
Date: Mon, 24 Mar 2014 23:37:06 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <lgr86n$uge$1@speranza.aioe.org>
On 3/24/2014 10:32 PM, Tim McDaniel wrote:
> In article <lgqo59$q3r$1@speranza.aioe.org>,
> Charles DeRykus <derykus@gmail.com> wrote:
>> Rainer Weikusat wrote [against using PadWalker]
>>
>> That's overreaching IMO. You're deprecating the value of a module
>
> So far as I've seen, that's Rainer's usual approach to modules from
> CPAN, for example, so I'm not surprised to see the same opinion here.
>
> You write that PadWalker is used in the Perl debugger, but
> perl -e 'use PadWalker'
> fails for me on the systems I have available, so I don't understand
> what's going on with it.
>
I see in perldebug that using the "y" command requires PadWalker to be
installed.
--
Charles DeRykus
------------------------------
Date: Tue, 25 Mar 2014 14:10:45 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <87bnwubc7u.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 3/24/2014 3:52 PM, Rainer Weikusat wrote:
>> Charles DeRykus <derykus@gmail.com> writes:
>>> On 3/24/2014 5:31 AM, Rainer Weikusat wrote:
>>>> George Mpouras <gravitalsun@hotmail.foo> writes:
>>>>
>>>> [PadWalker]
>>>>
>>>>> cool !
>>>>
>>>> "I wouldn't recommend using PadWalker directly in production code"
>>>>
>>>> http://search.cpan.org/~robin/PadWalker-1.98
>>>
>>> Also mentions "PadWalker is particularly useful for debugging. It's
>>> even used by Perl's built-in debugger..."
>>>
>>> So it may be worth the risk here. YMMV.
>>
>> Being able to replace a tiny bit of 'safe' (in the sense that it works
>> only with documented interfaces and doesn't fiddle around with internal
>> data structures of the interpreter) with a fairly large bit of (not
>> exactly expertly written) C code isn't worth any risks.
>>
>
> That's overreaching IMO. You're deprecating the value of a module
> even used by "Perl's built-in debugger" and especially, in this
> case, since the use was limited to debug. You should throw out Perl's
> built-in debugger then for the same reason. Caution tips over and
> becomes FUD.
I didn't write that I thought any risk was associated with using this
module and in fact, I don't think so, except possibly that it may not or
not anymore or not at all be compatible with some Perl versions, IOW,
"it may seem like a free download now but you will have to maintain this
code". Considering that versus
eval('{'.join(',', map { "$_, \$$_" } @a).'}');
this becomes a very bad tradeoff.
------------------------------
Date: Tue, 25 Mar 2014 14:20:23 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <877g7ibbrs.fsf@sable.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <lgqo59$q3r$1@speranza.aioe.org>,
> Charles DeRykus <derykus@gmail.com> wrote:
>>Rainer Weikusat wrote [against using PadWalker]
>>
>>That's overreaching IMO. You're deprecating the value of a module
>
> So far as I've seen, that's Rainer's usual approach to modules from
> CPAN, for example, so I'm not surprised to see the same opinion here.
That's my usual approach to human gateways answering any Perl question
by (blindly) forwarding something the CPAN search engine returned: It
shifts the topic of discussion away from the original question towards
the 'free download du jour'.
> You write that PadWalker is used in the Perl debugger, but
> perl -e 'use PadWalker'
> fails for me on the systems I have available, so I don't understand
> what's going on with it.
According to the documentation, auto-completion of lexical variable
names is provided via PadWalker if it is available. It also seems to be
a core part of the/ an Eclipse Perl debugger.
------------------------------
Date: Tue, 25 Mar 2014 17:51:24 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: dynamically creating a hash from an array
Message-Id: <87zjkejher.fsf@sable.mobileactivedefense.com>
Charles DeRykus <derykus@gmail.com> writes:
> On 3/24/2014 9:37 PM, Kaz Kylheku wrote:
>> On 2014-03-25, Charles DeRykus <derykus@gmail.com> wrote:
[...]
>>>>>> [PadWalker]
[...]
>> A lexical environment is not something that is passed down to a child function:
>> doing so (as an exposed feature) makes it a de facto dynamic environment.
>>
>> Programs that depend on a lexical environment being treated as a dynamic
>> environment (via some internal escape hatch) should be written with the
>> understanding that the author is wrecking the lexical scope paradigm.
>>
>> This falls into the "dumb hack" category when used other than for the intended
>> purpose of supporting the debugger as part of the implemenation. If Perl ever
>> becomes a properly compiled language, this area will have to drastically
>> change, such that programs which depend on it will break.
>
> And the documentation makes it clear that it's particularly useful for
> debugging...and not recommended for production code. You need enough
> rope to climb into the nooks and crannies of a language even if it's
> dangerous and tomorrow you may need a better rope.
Hmm ... sorry, but I don't need any more Perl-level access to the
internal data structures of the interpreter in order to program in Perl/
for perl than I need userspace access to internal kernel data structures
for writing UNIX(*) applications.
> The "Perl Hacks" segment on PadWalker shows a couple of cases where
> breaking encapsulation is useful and a very apt rationale:
>
> "It's scary and wrong, but sometimes it's just what you need".
The actual example is "dark magic you don't have to understand in order
to use" (this cries out loud for banging some sense into the guy who
wrote this --- there's nothing magical about clumsily written C code
accessing perl data structures and trying to use something one doesn't
understand is a recipe for disaster more of than not) in order to do
something which could have been accomplished by inserting a
print-statement into the example closure or even by running the
unadorned program via perl debugger and using a watch point.
------------------------------
Date: Sun, 23 Mar 2014 06:21:11 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Google spreadsheets with WWW::Mechanize
Message-Id: <5caa25ec-5d29-4caf-b23a-100058ccc419@googlegroups.com>
Hello,
I intend to process a Google spreadsheet, using WWW::Mechanize to access it.
The authentication is manages by my own company.
I manage to authenticate to Google Drive and to Gmail, but somehow the spreadsheet are different.
Is the any guidance concerning this?
Thanks,
Marc
------------------------------
Date: Sun, 23 Mar 2014 06:58:25 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Google spreadsheets with WWW::Mechanize
Message-Id: <041f5acf-2ff5-4ac0-959b-9636f1eba654@googlegroups.com>
Sorry: I got my spreadsheet page...
Now, my concern changes: is the Google::Spreadsheets module still relevant?
But I need to delve into it first.
Marc
------------------------------
Date: Tue, 25 Mar 2014 03:30:11 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Google spreadsheets with WWW::Mechanize
Message-Id: <baac4324-f30e-4e54-9a64-c6fb91ac48a4@googlegroups.com>
Net::Google::Spreadsheets looks complex enough for me to avoid reinventing some wheels.
The fact it builds upon Moose, which I haven't used so far, seems to make it hard to debug.
Most of the code is dynamically built, hence accessible as CODE in the debugger, in which I have to navigate--no breakpoints!
I had to tweak the authentication which to my understanding, is outdated for Google spreadsheets, but would anyway not be appropriate for my company's deferred authentication.
I had to replace LWP::UserAgent with WWW::Mechanize, maybe only in order to add a 'referer' header to all requests (which I might have done explicitly with LWP::UserAgent, assuming this is the only thing... One other is however handling gzipped content...)
Anyway, not I face an error:
Can't locate object method "entries" via package "HTTP::Headers" at /usr/local/share/perl/5.14.2/HTTP/Message.pm line 644.
at /usr/local/share/perl/5.14.2/Net/Google/DataAPI.pm line 113.
SF::Spreadsheets::spreadsheets('SF::Spreadsheets=HASH(0x28beef8)', 'HASH(0x28be910)') called at /home/marc.girod/dev/sandbox/mgirod/SF/Spreadsheets.pm line 56
SF::Spreadsheet is the result of my tweak so far, and I cannot show it.
(This is not going to any customer product)
The problem I have is that the $feed object lacking an entries member, is an HTTP::Response, i.e. an HTTP::Message.
I can only find an entries member in HTTP::Config, which is used by LWP::Agent...
Do you have any advice about the relevant forum to discuss Net::Google::Spreadsheets?
Thanks
Marc
------------------------------
Date: Tue, 25 Mar 2014 03:33:19 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Google spreadsheets with WWW::Mechanize
Message-Id: <94b655ca-5ff7-4602-a485-e783cadf0a46@googlegroups.com>
> Anyway, not I face an error:
s/not/now/
> ... which is used by LWP::Agent...
s/LWP::Agent/LWP::UserAgent/
So many ytpos!
------------------------------
Date: Tue, 25 Mar 2014 05:00:40 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: Google spreadsheets with WWW::Mechanize
Message-Id: <0581b05a-0df0-4992-8453-05909f8e77ab@googlegroups.com>
OK, there is an alternative way to construct the $feed, depending on the $cond (we are in Net::Google::DataAPI), and then it would be a XML::Atom::Feed, in which entries is an alias to either of two member functions.
The entries are then objects of type: XML::Atom::Entry
------------------------------
Date: Sun, 23 Mar 2014 15:42:20 +0000 (UTC)
From: "Dave Saville" <No_Spam@deezee.org>
Subject: Unbuffered I/O problem
Message-Id: <fV45K0OBJxbE-pn2-mdoC4X5e0VdY@paddington.bear.den>
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.
--
Regards
Dave Saville
------------------------------
Date: Sun, 23 Mar 2014 16:40:21 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Unbuffered I/O problem
Message-Id: <877g7kuave.fsf@sable.mobileactivedefense.com>
"Dave Saville" <No_Spam@deezee.org> writes:
> 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;
This doesn't "make it unbuffered", it forces the buffer to be flushed
after every output operation. Considering that you're dealing with a
soft realtime problem, you shouldn't be using the implicit buffering
layer to begin with, but syswrite.
------------------------------
Date: Sun, 23 Mar 2014 18:55:31 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Unbuffered I/O problem
Message-Id: <878us0n3rw.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
> "Dave Saville" <No_Spam@deezee.org> writes:
>> 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;
>
> This doesn't "make it unbuffered", it forces the buffer to be flushed
> after every output operation. Considering that you're dealing with a
> soft realtime problem, you shouldn't be using the implicit buffering
> layer to begin with, but syswrite.
Expanding a little on that (I'm ignoring the 'STREAMS for perl' features
of PerlIO): The whole point of 'stdio-style, implicit buffering' is to
delay actual output until a 'large' amount of output data has been
accumulated in order to increase throughput/ decrease system resource
usage by decreasing the number of system calls necessary to perform the
actual output. This is already of somewhat dubious value in Perl because
Perl-code usually doesn't do 'I/O processing' in 'really small chunks'
aka 'char-by-char/ byte-by-byte' (I also suspect that the overhead of
calling a Perl subroutine is higher than that of a system call) but it
is (at best) totally useless for audio output: This implies that audio
data has to become available at a fixed bit rate/ byte rate. When the
next chunk of it is due, it must not be delayed and 'increasing
throughput' is useless because sending data faster than required only
means something else has to use an internal buffer in order to cope with
that (this is somewhat simplified).
Something similar is true for many other IPC scenarios which are not
supposed to do batch processing of data. And trying to work around that
by 'enabling autoflush' is just totally bizarre: It basically means "Oh
well, the implicit buffering is really harmful in my case, so I'll
always flush the buffer immediately after a totally redundant block
memory copy of my input data was made" --- but if the buffering isn'y
useful, why copy data from application buffer a to 'middleware buffer' b
to begin with?
------------------------------
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 4180
***************************************
