[32555] in Perl-Users-Digest
Perl-Users Digest, Issue: 3821 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 20 14:09:27 2012
Date: Tue, 20 Nov 2012 11:09:12 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 20 Nov 2012 Volume: 11 Number: 3821
Today's topics:
IO::Select and PerlIO <hjp-usenet2@hjp.at>
Re: IO::Select and PerlIO <ben@morrow.me.uk>
Re: IO::Select and PerlIO <rweikusat@mssgmbh.com>
Re: IO::Select and PerlIO <xhoster@gmail.com>
Re: IO::Select and PerlIO <hjp-usenet2@hjp.at>
Re: IO::Select and PerlIO <ben@morrow.me.uk>
Re: IO::Select and PerlIO <ben@morrow.me.uk>
Re: IO::Select and PerlIO <rweikusat@mssgmbh.com>
Re: Module for common perl/shell/python constants <willem@turtle.stack.nl>
Re: Module for common perl/shell/python constants <derykus@gmail.com>
OpenOffice::OODoc - discussion? <news@lawshouse.org>
Too long <mickey@perusion.net>
Re: Too long <news@lawshouse.org>
Re: Too long <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 19 Nov 2012 17:43:03 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: IO::Select and PerlIO
Message-Id: <slrnkakocn.ti7.hjp-usenet2@hrunkner.hjp.at>
Does IO::Select take into account data buffered by PerlIO?
Specifically, I would like to do something like the following:
my $s = IO::Select->new();
$s->add($socket_fh);
while (...) {
print $socket_fh "$request\n";
while ($s->can_read(0)) {
my $response = <$socket_fh>;
# do something with $response
}
}
to exploit pipelining in a protocol.
This wouldn't work with stdio and select(2) in C, but in C, the system
call select is at a lower layer than the stdio and cannot know about
stdio buffers, while in Perl, IO::Select works on filehandles so one
could hope that it is smart enough to know about them. I can't find
anything about that in the docs, though.
(perldoc -f select says you have to use sysread, but select uses fd
numbers, not filehandles)
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Mon, 19 Nov 2012 17:14:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IO::Select and PerlIO
Message-Id: <306qn9-smm1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> Does IO::Select take into account data buffered by PerlIO?
No. It can't, because the underlying syscall can't.
> Specifically, I would like to do something like the following:
>
> my $s = IO::Select->new();
> $s->add($socket_fh);
>
> while (...) {
> print $socket_fh "$request\n";
>
> while ($s->can_read(0)) {
This loop never blocks (assuming your filehandles are nonblocking). You
have to block somewhere, usually in select, or you'll just spin round
the loop doing nothing and wasting CPU.
> my $response = <$socket_fh>;
> # do something with $response
> }
> }
Your options here are:
- Use sysread/write, as recommended in the docs.
- Push a :unix layer, so that print and <> do unbuffered IO. You
will have to be aware of this, and handle the buffering yourself
as needed (you will almost certainly want to do block reads rather
than line reads, for instance).
In all cases that select loop is not sufficient: you are not checking
for writability before writing. You need to buffer writes as well, and
keep trying to write what's left in the buffer until it's all been
written.
> to exploit pipelining in a protocol.
I'm not sure what you mean here: you are writing and then reading in
lockstep, so you won't be pipelining anything. If you want to pipeline
you need to build a buffer with several requests in, then loop around a
select for both read and write, sending when you can and buffering the
next response until you've read it all.
> This wouldn't work with stdio and select(2) in C, but in C, the system
> call select is at a lower layer than the stdio and cannot know about
> stdio buffers, while in Perl, IO::Select works on filehandles so one
> could hope that it is smart enough to know about them. I can't find
> anything about that in the docs, though.
>
> (perldoc -f select says you have to use sysread, but select uses fd
> numbers, not filehandles)
IO::Select is a very thin layer around the core select(): read the
source. All it does is handle the vec()s for you and maintain a map from
fds back to filehandles.
If you want a higher-level facility, you probably want POE.
Ben
------------------------------
Date: Mon, 19 Nov 2012 17:28:40 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: IO::Select and PerlIO
Message-Id: <871ufpec3b.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
[...]
> Your options here are:
>
> - Use sysread/write, as recommended in the docs.
> - Push a :unix layer, so that print and <> do unbuffered IO. You
> will have to be aware of this, and handle the buffering yourself
> as needed (you will almost certainly want to do block reads rather
> than line reads, for instance).
>
> In all cases that select loop is not sufficient: you are not checking
> for writability before writing.
This doesn't really make sense: Except in unusual cases (eg, when the
code does something like 'sending the contents of a large file'), the
socket will always be writeable and checking for this is a waste of
time. The better idea is usually to try to write something and check
for 'did this become writeable' only if a pending write could not be
completed.
[...]
>> This wouldn't work with stdio and select(2) in C, but in C, the system
>> call select is at a lower layer than the stdio and cannot know about
>> stdio buffers, while in Perl, IO::Select works on filehandles so one
>> could hope that it is smart enough to know about them. I can't find
>> anything about that in the docs, though.
>>
>> (perldoc -f select says you have to use sysread, but select uses fd
>> numbers, not filehandles)
>
> IO::Select is a very thin layer around the core select(): read the
> source. All it does is handle the vec()s for you and maintain a map from
> fds back to filehandles.
Using 'automatic I/O buffering' together with 'sockets' (or any other
kind of IPC channel) also doesn't make sense: Usually, the protocol
dictates when data needs to be written or can be read and this implies
that any 'hidden buffers' need to be flushed whenever data has to be
sent. Since Perl supports automatic memory management, constructing a
complete message in memory before sending and then using syswrite to
actually send it (instead of copying it into and application buffer
and then flushing that so that it gets copied into a kernel buffer)
shouldn't be difficult.
------------------------------
Date: Mon, 19 Nov 2012 10:03:21 -0800
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: IO::Select and PerlIO
Message-Id: <50aa7507$0$7120$ed362ca5@nr5-q3a.newsreader.com>
On 11/19/2012 09:14 AM, Ben Morrow wrote:
>
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> Does IO::Select take into account data buffered by PerlIO?
>
> No. It can't, because the underlying syscall can't.
So then don't make that underlying syscall if/when you don't need to.
Just because they chose not to implement it that way doesn't mean that
it can't be done.
That has always bothered me about IO::Select. An object-oriented
interface shouldn't just be an alternative spelling of an underlying
syscall.
Xho
------------------------------
Date: Mon, 19 Nov 2012 20:21:40 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: IO::Select and PerlIO
Message-Id: <slrnkal1m4.f3h.hjp-usenet2@hrunkner.hjp.at>
On 2012-11-19 17:14, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>> Does IO::Select take into account data buffered by PerlIO?
>
> No. It can't, because the underlying syscall can't.
That's like saying <> can't read line by line because the underlying
syscall can't.
>> Specifically, I would like to do something like the following:
>>
>> my $s = IO::Select->new();
>> $s->add($socket_fh);
>>
>> while (...) {
>> print $socket_fh "$request\n";
>>
>> while ($s->can_read(0)) {
>
> This loop never blocks (assuming your filehandles are nonblocking). You
> have to block somewhere, usually in select, or you'll just spin round
> the loop doing nothing and wasting CPU.
No. When $s->can_read returns true, the loop does something: It reads
the next response and processes it. When there is nothing to do, the
loop is aborted. So it can't spin around doing nothing.
If the client is consistently faster than the server the outer loop will
eventually block on print.
>> my $response = <$socket_fh>;
>> # do something with $response
>> }
>> }
>
> Your options here are:
>
> - Use sysread/write, as recommended in the docs.
Yes. I knew about this one.
> - Push a :unix layer, so that print and <> do unbuffered IO.
That's an idea. Unbuffered I/O for <> probably means 1 byte reads which
doesn't sound appealing (I'm on a Gbit LAN, so the latency I'm trying to
avoid is actually less than a millisecond per request).
> You will have to be aware of this, and handle the buffering
> yourself as needed (you will almost certainly want to do block
> reads rather than line reads, for instance).
If I do that I can use sysread.
> In all cases that select loop is not sufficient: you are not checking
> for writability before writing.
This is intentional: I want the process to block when the write buffer
becomes full. With the amount of buffering in the network layer and
given that I always read all received responses after each request I'm
not worried about deadlocks.
> You need to buffer writes as well, and keep trying to write what's
> left in the buffer until it's all been written.
That's what buffered I/O is for ;-).
>> to exploit pipelining in a protocol.
>
> I'm not sure what you mean here: you are writing and then reading in
> lockstep,
No, I'm not. I'm only reading if a response has been received. I can
probably send quite a few requests before the first response trundles
in.
> so you won't be pipelining anything.
Yes, I am.
> If you want to pipeline you need to build a buffer with several
> requests in,
No. There is no reason to build that buffer beforehand.
> then loop around a select for both read and write, sending when you
> can
Testing whether it is possible to send would be necessary if there was a
possibility of deadlock (both client and server are blocked trying to
write). This is highly unlikely in this case, as requests and responses
are much smaller than the buffer.
> and buffering the next response until you've read it all.
>> This wouldn't work with stdio and select(2) in C, but in C, the system
>> call select is at a lower layer than the stdio and cannot know about
>> stdio buffers, while in Perl, IO::Select works on filehandles so one
>> could hope that it is smart enough to know about them. I can't find
>> anything about that in the docs, though.
>>
>> (perldoc -f select says you have to use sysread, but select uses fd
>> numbers, not filehandles)
>
> IO::Select is a very thin layer around the core select(): read the
> source. All it does is handle the vec()s for you and maintain a map from
> fds back to filehandles.
That's what I feared. Using sysread isn't a big hassle, but I would have
hoped that they fixed this when they replaced stdio with PerlIO.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Mon, 19 Nov 2012 22:58:55 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IO::Select and PerlIO
Message-Id: <f6qqn9-pvo1.ln1@anubis.morrow.me.uk>
Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
> On 11/19/2012 09:14 AM, Ben Morrow wrote:
> >
> > Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> >> Does IO::Select take into account data buffered by PerlIO?
> >
> > No. It can't, because the underlying syscall can't.
>
> So then don't make that underlying syscall if/when you don't need to.
> Just because they chose not to implement it that way doesn't mean that
> it can't be done.
It can be done, it has been done, it just isn't called IO::Select.
> That has always bothered me about IO::Select. An object-oriented
> interface shouldn't just be an alternative spelling of an underlying
> syscall.
The IO::* classes are all just very thin wrappers around the core
functions. Except in the case of IO::Socket (and *maybe* ::Select),
where the core APIs are rather nasty to get right, I've never seen the
point of them. (Except, of course, that there are two or three important
functions that are only available through IO::Handle...) The hoops they
have to jump through to get objects-pretending-to-be-filehandles-
pretending-to-be-objects are just gross, especially the differences
between these four:
my $H = IO::File->new(...);
print $H "foo";
$H->print("foo");
sync $H;
close $H;
You have to remember these were all written right at the very start of
Perl OO, when the whole *idea* of objects was somewhat revolutionary.
It's hardly surprising they don't always stand up to modern standards of
'good' OO programming (and in fact a little surprising when, sometimes,
they do).
Ben
------------------------------
Date: Tue, 20 Nov 2012 00:19:37 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: IO::Select and PerlIO
Message-Id: <ptuqn9-t2q1.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> On 2012-11-19 17:14, Ben Morrow <ben@morrow.me.uk> wrote:
> > Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
> >> Does IO::Select take into account data buffered by PerlIO?
> >
> > No. It can't, because the underlying syscall can't.
>
> That's like saying <> can't read line by line because the underlying
> syscall can't.
OK, yes. But in order to (properly) implement a higher-level inteface on
top of select you would need a library that takes over your program's IO
and runs its own select (or alternative) loop. That's what POE does, and
programming with POE is somewhat different from using native
filehandles.
> >> Specifically, I would like to do something like the following:
> >>
> >> my $s = IO::Select->new();
> >> $s->add($socket_fh);
> >>
> >> while (...) {
> >> print $socket_fh "$request\n";
> >>
> >> while ($s->can_read(0)) {
> >
> > This loop never blocks (assuming your filehandles are nonblocking). You
> > have to block somewhere, usually in select, or you'll just spin round
> > the loop doing nothing and wasting CPU.
>
> No. When $s->can_read returns true, the loop does something: It reads
> the next response and processes it. When there is nothing to do, the
> loop is aborted. So it can't spin around doing nothing.
>
> If the client is consistently faster than the server the outer loop will
> eventually block on print.
Oh, your filehandles are blocking? I was assuming they were nonblocking,
since that's the usual way to use select.
I don't think this is a good way to do socket IO: if you succeed in
writing all but one byte (say) of a request, that print will then block
until the last byte can be written. Since the kernel doesn't unblock a
fd immediately (it waits until at least SO_SNDLOWAT bytes can be written
in one go) that means you will wait longer than you needed to to read
the next response. The normal way of doing things would be to do a
non-blocking write, keep that final byte in a usermode buffer until it
could be written, and in the meanwhile get on with processing reads.
The same thing applies when reading responses: you will end up blocking
on a read which is partially complete when you could be writing. If
you're worried about latency that's not a good idea.
> >> my $response = <$socket_fh>;
> >> # do something with $response
> >> }
> >> }
> >
> > Your options here are:
> >
> > - Use sysread/write, as recommended in the docs.
>
> Yes. I knew about this one.
>
> > - Push a :unix layer, so that print and <> do unbuffered IO.
>
> That's an idea. Unbuffered I/O for <> probably means 1 byte reads which
> doesn't sound appealing (I'm on a Gbit LAN, so the latency I'm trying to
> avoid is actually less than a millisecond per request).
Line-mode <> on a :unix filehandle is extremely inefficient: it does
one-byte read(2)s looking for newlines. :unix basically turns print and
block-mode <> into more convenient aliases for sysread/write.
> > You will have to be aware of this, and handle the buffering
> > yourself as needed (you will almost certainly want to do block
> > reads rather than line reads, for instance).
>
> If I do that I can use sysread.
>
>
> > In all cases that select loop is not sufficient: you are not checking
> > for writability before writing.
>
> This is intentional: I want the process to block when the write buffer
> becomes full. With the amount of buffering in the network layer and
> given that I always read all received responses after each request I'm
> not worried about deadlocks.
>
> > You need to buffer writes as well, and keep trying to write what's
> > left in the buffer until it's all been written.
>
> That's what buffered I/O is for ;-).
Hmmm. Stdio-style buffered IO was only really designed for pipeline-type
programs, where if you end up blocking on read or write you wouldn't
have had anything else to do anyway. Network programs are usually better
written with nonblocking IO and an event loop, where you read or write
whenever you can and queue data for processing or writing as it comes
in/as you generate it. It's perfectly possible (and often a good idea)
to use a library to handle the buffering for you, but those libraries
don't look quite the same as stdio.
> >> to exploit pipelining in a protocol.
> >
> > I'm not sure what you mean here: you are writing and then reading in
> > lockstep,
>
> No, I'm not. I'm only reading if a response has been received. I can
> probably send quite a few requests before the first response trundles
> in.
Yeah, OK; if none of a response has arrived you will carry on writing:
I'd missed that. But if just a portion has arrived you will block
waiting for the rest.
> > If you want to pipeline you need to build a buffer with several
> > requests in,
>
> No. There is no reason to build that buffer beforehand.
Again, the usual way of doing this sort of thing is to write as much as
will fit in the system buffers (and no more), meaning (since you don't
know how much space there is) you need a userland buffer with as much
data as you can reasonably get to pass to write(2). Every time you make
a write(2) which doesn't fill the system buffer, when you could have
included (some of) the next request as well, you're wasting time you
could have saved.
> > then loop around a select for both read and write, sending when you
> > can
>
> Testing whether it is possible to send would be necessary if there was a
> possibility of deadlock (both client and server are blocked trying to
> write). This is highly unlikely in this case, as requests and responses
> are much smaller than the buffer.
I'm... not sure that's the case. I'd have to think more carefully about
it than I'm inclined to at this time of night :). You may be right that
as long as you're careful to empty the read buffer at your end before
every write, and as long as a response is never significantly larger
than the system buffer, you'll be OK, but I'm not certain of that. (The
last condition is not something you can usually assume.)
> > and buffering the next response until you've read it all.
>
>
> >> This wouldn't work with stdio and select(2) in C, but in C, the system
> >> call select is at a lower layer than the stdio and cannot know about
> >> stdio buffers, while in Perl, IO::Select works on filehandles so one
> >> could hope that it is smart enough to know about them. I can't find
> >> anything about that in the docs, though.
> >>
> >> (perldoc -f select says you have to use sysread, but select uses fd
> >> numbers, not filehandles)
> >
> > IO::Select is a very thin layer around the core select(): read the
> > source. All it does is handle the vec()s for you and maintain a map from
> > fds back to filehandles.
>
> That's what I feared. Using sysread isn't a big hassle, but I would have
> hoped that they fixed this when they replaced stdio with PerlIO.
One of the points of PerlIO was that it should look just like stdio (in
fact there is, or was, a :stdio layer that uses real stdio(3)
buffering). Changing the behaviour of IO::Select in a rather fundamental
way would have defeated that.
Ben
------------------------------
Date: Tue, 20 Nov 2012 00:40:57 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: IO::Select and PerlIO
Message-Id: <87k3tht8bq.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
[...]
> The IO::* classes are all just very thin wrappers around the core
> functions. Except in the case of IO::Socket (and *maybe* ::Select),
> where the core APIs are rather nasty to get right, I've never seen the
> point of them.
[...]
> You have to remember these were all written right at the very start of
> Perl OO, when the whole *idea* of objects was somewhat
> revolutionary.
By the time the 'Perl I/O objects' hit the scene, I had been doing
'object-oriented programming' for something like seven or eight years
and the concept is much older. Even Smalltalk was already a successor
of earlier implementations (IIRC). OTOH, I'd completely agree with the
notion that the Perl 'object-oriented I/O' is essentially 'why does
the dog lick its balls' programming, IOW, "We could do it. So, we
did" (and downright awfully at times, eg, in Graham Barr's poll-module
which mostly introduces the most serious deficiency in the select,
that it destroys the interest after each call, by 'carefully deficient
coding' into poll).
> It's hardly surprising they don't always stand up to modern standards of
> 'good' OO programming (and in fact a little surprising when, sometimes,
> they do).
If 'modern standards of OO programming' mean that abstractions for
delayed, block-based I/O intended to make efficient use of block
devices easy, are forcefully introduced into real-time communications
where they have exactly no place, and this even in a language where
the original problem, 'memory management in C is just too hard', does
not and has never existed, they are not particularly modern. Rather
something like "we're mindlessly aping some idea some guy had in 1976
in a completely different context because we don't even understand
that" ...
------------------------------
Date: Sun, 18 Nov 2012 17:32:51 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Module for common perl/shell/python constants
Message-Id: <slrnkai6u3.vcn.willem@turtle.stack.nl>
J?rgen Exner wrote:
) Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> wrote:
)>Is there module which lets me write a single config file with
)>integer/string constants which will be used by both Perl, Bash and
)>Python? Preferably Perl would turn them into compile-time constants.
)>
)>E.g. I'd write "use Shellvars qw(foo.sh); where foo.sh
)>would contain
)> FOO = 3
)> BAR = "baz"
)>Hopefully
)> BAD = "oops
)>would fail rather than produce some arbitrary strange result.
)
) If you need configurations that are compatible across multiple languages
) then typically the greatest common divisor is XML.
XML is most used, yes, but it's a terrible choice. Use YAML, or JSON, or
INI, or something else that is actually designed for this task.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Sun, 18 Nov 2012 15:19:19 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Module for common perl/shell/python constants
Message-Id: <1aa524ce-e93e-433c-9451-2bb6ff2e363e@googlegroups.com>
On Saturday, November 17, 2012 7:09:22 AM UTC-8, Rainer Weikusat wrote:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> > Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no> writes:
>
> >> Is there module which lets me write a single config file with
>
> >> integer/string constants which will be used by both Perl, Bash and
>
> >> Python? Preferably Perl would turn them into compile-time
>
> >> constants.
>
> >
>
>
>
> [...]
>
>
>
>
>
> > A (somewhat crude) way to turn some environment variables into a Perl
>
> > constants could be:
>
> >
>
> > --------------
>
> > package Shellvars;
>
> >
>
> > sub import
>
>
>
> [...]
>
>
>
> > This could be done in a much more sophisticated way, as can be seen in
>
> > constant.pm.
>
>
>
> OTOH, one doesn't have to rewrite it if it could also be reused :-)
>
>
>
> -----------------
>
> package Shellvars2;
>
>
>
> use constant;
>
>
>
> sub import
>
> {
>
> shift;
>
>
>
> @_ = ('MarmiteMermaid', { map { $_, $ENV{$_} } @_});
>
> goto &constant::import;
>
> }
>
>
>
> 1;
Not a proper module but in simple cases,
you could just pass in with @ARGV and constantify in a BEGIN:
BEGIN {
require constant;
constant->import({map{$_,$ENV{$_}} @ARGV });
}
--
Charles DeRykus
------------------------------
Date: Sun, 18 Nov 2012 21:56:05 +0000
From: Henry Law <news@lawshouse.org>
Subject: OpenOffice::OODoc - discussion?
Message-Id: <efGdnVl4pN7rxDTNnZ2dnUVZ8tWdnZ2d@giganews.com>
I'm looking for some help on using OpenOffice::OODoc to read and
manipulate ODF documents. There's a forum at cpanforum.com but the
latest post is three months old and has no follow-ups; the next is over
a year old and also got no response, so I'm ruling it out. Any ideas?
My question relates to the getParentStyle method, which returns the
style name from which a style inherits. It works fine, but if there is
no parent (not in itself an error condition) it issues a warning to
STDERR which is very irritating. I've looked at the code and can see
easily where to patch it, but that's not the sort of thing you do
without discussing it with someone else in the field.
--
Henry Law Manchester, England
------------------------------
Date: Tue, 20 Nov 2012 09:01:54 -0600
From: Mickey Langan <mickey@perusion.net>
Subject: Too long
Message-Id: <slrnkan6r2.54p.mickey@bill.heins.net>
Perl 5.16 takes too damn long to build. Tests are not always good -- making
people waste time on interminable tests of very marginal modules is stupid.
That is all.
--
Mickey
"The secret of a good sermon is to have a good beginning and a good
ending, then having the two as close together as possible."
-- George Burns
------------------------------
Date: Tue, 20 Nov 2012 15:51:19 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Too long
Message-Id: <q4CdnbGGoeplOzbNnZ2dnUVZ8kidnZ2d@giganews.com>
On 20/11/12 15:01, Mickey Langan wrote:
> Perl 5.16 takes too damn long to build. Tests are not always good -- making
> people waste time on interminable tests of very marginal modules is stupid.
>
> That is all.
Is there some extremely good reason why you need to build it yourself,
and do so often? For me as a user of Perl, exhaustive testing seems
like a good idea, however "marginal" the modules, and since I don't have
to do it I can't see the downside.
Message ends.
--
Henry Law Manchester, England
------------------------------
Date: Tue, 20 Nov 2012 17:06:58 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Too long
Message-Id: <iupsn9-jr32.ln1@anubis.morrow.me.uk>
Quoth Mickey Langan <mickey@perusion.net>:
> Perl 5.16 takes too damn long to build. Tests are not always good -- making
> people waste time on interminable tests of very marginal modules is stupid.
Are you running the tests in parallel? It makes a *huge* difference on
modern machines.
TEST_JOBS=6 make -j6 test_harness
Also, those who do not contribute to perl development don't get to
complain about the techniques found useful by those who do. The test
suite finds lots of portability problems. If you don't want to run it,
don't: someone else has probably run it on your platform and made sure
it passed before the release was made.
Ben
------------------------------
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 3821
***************************************
