[32549] in Perl-Users-Digest
Perl-Users Digest, Issue: 3815 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 9 11:09:24 2012
Date: Fri, 9 Nov 2012 08:09:07 -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 Fri, 9 Nov 2012 Volume: 11 Number: 3815
Today's topics:
how does $#array work internally? <tessarek@evermeet.cx>
Re: how does $#array work internally? <rweikusat@mssgmbh.com>
Re: how does $#array work internally? <ben@morrow.me.uk>
Re: how does $#array work internally? <tessarek@evermeet.cx>
Re: how does $#array work internally? <tessarek@evermeet.cx>
Re: how does $#array work internally? <kst-u@mib.org>
Re: how does $#array work internally? <glex_no-spam@qwest-spam-no.invalid>
Re: how does $#array work internally? <rweikusat@mssgmbh.com>
Re: how does $#array work internally? <ben@morrow.me.uk>
Re: how does $#array work internally? <tessarek@evermeet.cx>
Re: how does $#array work internally? <ben@morrow.me.uk>
Re: how does $#array work internally? <rweikusat@mssgmbh.com>
Re: how does $#array work internally? <bugbear@trim_papermule.co.uk_trim>
Re: how does $#array work internally? <ben@morrow.me.uk>
Re: STDOUT and STDERR from command lines <juliani.moon@gmail.com>
Re: Trampoline sub <derykus@gmail.com>
utf-2d (was: Re: Why "Wide character in print"?) <rvtol+usenet@xs4all.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 08 Nov 2012 12:19:41 -0500
From: Helmut Tessarek <tessarek@evermeet.cx>
Subject: how does $#array work internally?
Message-Id: <k7gpit$brb$1@news.albasani.net>
I'm wondering how the $#array construct works internally.
Does perl iterate through the array and return the highest index or does perl
use some meta data within the array structure?
The reason why I ask is the following:
I need the number of elements in a certain array several times throughout my
code. I build the array at the beginning and after that it does not change
anymore.
So I can use a variable which I increment during the construction of the array
or I could use $#array+1 to get the number of elements.
I need the number of elements several times in my code, so if perl has to
iterate through the array every time I use $#array, it is better for
performance to use a separate variable which I increment while building the
array....
Cheers,
Helmut
------------------------------
Date: Thu, 08 Nov 2012 18:33:02 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how does $#array work internally?
Message-Id: <87mwysx7vl.fsf@sapphire.mobileactivedefense.com>
Helmut Tessarek <tessarek@evermeet.cx> writes:
> I'm wondering how the $#array construct works internally.
>
> Does perl iterate through the array and return the highest index or does perl
> use some meta data within the array structure?
>
> The reason why I ask is the following:
>
> I need the number of elements in a certain array several times throughout my
> code. I build the array at the beginning and after that it does not change
> anymore.
> So I can use a variable which I increment during the construction of the array
> or I could use $#array+1 to get the number of elements.
Assuming that @array would be the array in question, you can get the
number of elements by evaluating that in scalar context, eg
scalar(@array). $#array is a more complex operation because it is
possible to assign to $#array in order to change the array
length. Depending on your version of perl, it will either just return
the 'array fill pointer' value (according to
http://www.perlmonks.org/?node_id=801691, since 5.12) or it will
create a 'magic SV' return value whose vtable has a get and a set
operation with the get-operation returns the fill ptr/ highest used
index in the array and the set-operation presumably changing it (very
likely, but I haven't checked that).
The short answer is 'meta data'.
------------------------------
Date: Thu, 8 Nov 2012 18:54:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how does $#array work internally?
Message-Id: <tobtm9-ram.ln1@anubis.morrow.me.uk>
Quoth Helmut Tessarek <tessarek@evermeet.cx>:
> I'm wondering how the $#array construct works internally.
>
> Does perl iterate through the array and return the highest index or does perl
> use some meta data within the array structure?
Perl knows how long arrays are, and that information is stored directly
in the array structure. Even for tied arrays, they have to implement
FETCHSIZE, so $#array will be as efficient as the tie implementation can
make it.
Ben
------------------------------
Date: Thu, 08 Nov 2012 14:56:47 -0500
From: Helmut Tessarek <tessarek@evermeet.cx>
Subject: Re: how does $#array work internally?
Message-Id: <k7h2pc$1s1$1@news.albasani.net>
On 08.11.12 13:33 , Rainer Weikusat wrote:
> Assuming that @array would be the array in question, you can get the
my bad, yes, 'array' is the name of the array.
> number of elements by evaluating that in scalar context, eg
> scalar(@array). $#array is a more complex operation because it is
it is a well-formed array (no holes), so I thought $#array (if using meta
data) is less expensvce than 'scalar @array' or does scalar @array also use
meta data?
> possible to assign to $#array in order to change the array
> length. Depending on your version of perl, it will either just return
> the 'array fill pointer' value (according to
> http://www.perlmonks.org/?node_id=801691, since 5.12) or it will
> create a 'magic SV' return value whose vtable has a get and a set
> operation with the get-operation returns the fill ptr/ highest used
> index in the array and the set-operation presumably changing it (very
> likely, but I haven't checked that).
thanks for detailed explanation.
------------------------------
Date: Thu, 08 Nov 2012 14:57:55 -0500
From: Helmut Tessarek <tessarek@evermeet.cx>
Subject: Re: how does $#array work internally?
Message-Id: <k7h2rf$1s1$2@news.albasani.net>
On 08.11.12 13:54 , Ben Morrow wrote:
> Perl knows how long arrays are, and that information is stored directly
> in the array structure. Even for tied arrays, they have to implement
> FETCHSIZE, so $#array will be as efficient as the tie implementation can
> make it.
thx for the info.
------------------------------
Date: Thu, 08 Nov 2012 13:19:28 -0800
From: Keith Thompson <kst-u@mib.org>
Subject: Re: how does $#array work internally?
Message-Id: <lnbof7lrmn.fsf@nuthaus.mib.org>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> Assuming that @array would be the array in question, you can get the
> number of elements by evaluating that in scalar context, eg
> scalar(@array). $#array is a more complex operation because it is
> possible to assign to $#array in order to change the array
> length.
[...]
Yes, but assigning to $#array also changes the result of
scalar(@array). (I'm sure you know that, I'm just trying to avoid
confusion.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Thu, 08 Nov 2012 15:21:09 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: how does $#array work internally?
Message-Id: <509c2245$0$63204$815e3792@news.qwest.net>
On 11/08/12 13:56, Helmut Tessarek wrote:
> On 08.11.12 13:33 , Rainer Weikusat wrote:
>> Assuming that @array would be the array in question, you can get the
>
> my bad, yes, 'array' is the name of the array.
>
>> number of elements by evaluating that in scalar context, eg
>> scalar(@array). $#array is a more complex operation because it is
>
> it is a well-formed array (no holes), so I thought $#array (if using meta
> data) is less expensvce than 'scalar @array' or does scalar @array also use
> meta data?
Use either. In many cases 'scalar' isn't needed.
perldoc perlintro
...
You might be tempted to use "$#array + 1" to tell you how many
items there are in an array. Don't bother. As it happens,
using @array where Perl expects to find a scalar value
("in scalar context") will give you the number of elements
in the array:
if (@animals < 5) { ... }
Seriously though, if your code is slow, it's not because you are
using $# or scalar @arr. Either one is not going to be *that*
'expensvce' [expensive].
"premature optimization is the root of all evil." -- Donald Knuth
------------------------------
Date: Thu, 08 Nov 2012 21:33:19 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how does $#array work internally?
Message-Id: <87fw4jye3k.fsf@sapphire.mobileactivedefense.com>
Helmut Tessarek <tessarek@evermeet.cx> writes:
> On 08.11.12 13:33 , Rainer Weikusat wrote:
>> Assuming that @array would be the array in question, you can get the
>
> my bad, yes, 'array' is the name of the array.
>
>> number of elements by evaluating that in scalar context, eg
>> scalar(@array). $#array is a more complex operation because it is
>
> it is a well-formed array (no holes), so I thought $#array (if using meta
> data) is less expensvce than 'scalar @array' or does scalar @array also use
> meta data?
NB: The description below is only true for 'real' arrays.
Both calculations are done based on the structure member which holds
the highest used index in the array. Evaluating the array in scalar
context is actually less expensive for two reason:
1. In Perl versions prio to 5.12, no intermediate 'magic SV' is
created because the result of this evaluation is not an
lvalue.
2. Calculating the number of elements is done by adding 1 to
the 'highest used index' value. But calcluating $#array
requires adding the current 'first index' value ($[, =>
perval(3pm)).
NB: On the computer where I tested this, the difference was about
0.000002s (2E-6).
-------------------
use Benchmark;
my @a = 1 .. 200;
timethese(-5,
{
len => sub {
my $l;
$l = @a;
return $l;
},
last => sub {
my $l;
$l = $#a;
return $l
}});
------------------------------
Date: Thu, 8 Nov 2012 21:45:05 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how does $#array work internally?
Message-Id: <1oltm9-9vn.ln1@anubis.morrow.me.uk>
Quoth Helmut Tessarek <tessarek@evermeet.cx>:
> On 08.11.12 13:33 , Rainer Weikusat wrote:
> > Assuming that @array would be the array in question, you can get the
>
> my bad, yes, 'array' is the name of the array.
>
> > number of elements by evaluating that in scalar context, eg
> > scalar(@array). $#array is a more complex operation because it is
>
> it is a well-formed array (no holes), so I thought $#array (if using meta
> data) is less expensvce than 'scalar @array' or does scalar @array also use
> meta data?
Perl arrays never have holes. Scalar @array uses the same metadata as
$#array, so it is just as cheap (cheaper sometimes, as Rainer pointed
out).
Ben
------------------------------
Date: Thu, 08 Nov 2012 17:02:40 -0500
From: Helmut Tessarek <tessarek@evermeet.cx>
Subject: Re: how does $#array work internally?
Message-Id: <k7ha5a$i29$1@news.albasani.net>
On 08.11.12 16:21 , J. Gleixner wrote:
> Seriously though, if your code is slow, it's not because you are
> using $# or scalar @arr. Either one is not going to be *that* 'expensvce'
> [expensive].
My code is not slow, but I agree with your statement. I still wanted to know
which one is more expensive.
> "premature optimization is the root of all evil." -- Donald Knuth
I disagree - to a certain extent. There is a difference between premature
optimization and performance aware coding.
Methinks it was Donald who suggested to use rather a prefix incrementer
instead of a postfix incrementer (once upon a time when compilers did not do
these things under the covers (if possible, because semantically valid)).
------------------------------
Date: Thu, 8 Nov 2012 23:34:16 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how does $#array work internally?
Message-Id: <o4stm9-7mp.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Helmut Tessarek <tessarek@evermeet.cx> writes:
> >
> > it is a well-formed array (no holes), so I thought $#array (if using meta
> > data) is less expensvce than 'scalar @array' or does scalar @array also use
> > meta data?
>
> NB: The description below is only true for 'real' arrays.
>
> Both calculations are done based on the structure member which holds
> the highest used index in the array. Evaluating the array in scalar
> context is actually less expensive for two reason:
>
> 1. In Perl versions prio to 5.12, no intermediate 'magic SV' is
> created because the result of this evaluation is not an
> lvalue.
It's perhaps worth pointing out that even after 5.12, $#array still
returns a magic SV if it's evaluated in lvalue context. Since subs are
allowed to modify their arguments, this means a call like foo($#array)
will have to create a magic SV, even if foo() isn't in fact going to
modify the length.
> 2. Calculating the number of elements is done by adding 1 to
> the 'highest used index' value. But calcluating $#array
> requires adding the current 'first index' value ($[, =>
> perval(3pm)).
As of 5.16 this is no longer true: $[ no longer exists, not even as the
lexically-scoped pragma it has been since (IIRC) 5.6.
scalar(@array) will still (probably) be slightly faster, since $#array
requires two ops (rv2av followed by av2arylen):
~% perl -MO=Concise,-exec -e'$#a'
-e syntax OK
1 <0> enter
2 <;> nextstate(main 1 -e:1) v:{
3 <$> gv(*a) s
4 <1> rv2av[t1] sKR/1
5 <1> av2arylen vK/1
6 <@> leave[1 ref] vKP/REFC
whereas scalar(@array) is implemented by rv2av directly:
~% perl -MO=Concise,-exec -e'scalar @a'
-e syntax OK
1 <0> enter
2 <;> nextstate(main 1 -e:1) v:{
3 <$> gv(*a) s
4 <1> rv2av[t1] sK/1
5 <@> leave[1 ref] vKP/REFC
Ben
------------------------------
Date: Fri, 09 Nov 2012 11:42:56 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: how does $#array work internally?
Message-Id: <874nkzq9xb.fsf@sapphire.mobileactivedefense.com>
"J. Gleixner" <glex_no-spam@qwest-spam-no.invalid> writes:
[...]
> You might be tempted to use "$#array + 1" to tell you how many
> items there are in an array. Don't bother. As it happens,
> using @array where Perl expects to find a scalar value
> ("in scalar context") will give you the number of elements
> in the array:
>
> if (@animals < 5) { ... }
This is also a stupid thing to do because evaluating @animals in
scalar context means perl will do the + 1 in compiled code, as opposed
to execuing Perl (perl?) bytecode to perform the same operation.
> Seriously though, if your code is slow, it's not because you are
> using $# or scalar @arr. Either one is not going to be *that*
> expensvce' [expensive].
... and if you just insert a
for my $i (1 .. 100) {
my $j = $i * 938289897227;
}
between any two lines of the 'productive' code, that's probably also
not going to have much of a detrimental effect. But that's not a good
reason to actually do that.
> "premature optimization is the root of all evil." -- Donald Knuth
In 1943, Joseph Goebbels held an infamous speech in the so-called
'Sportpalast' in Berlin where he repeatedly asked his (carefully
selected) audience whether they wanted to have 'the total war' and
elicited enthusiatic 'Yes! Yes!' shoutings from the audience. Since
this has been recorded on film, the affirmative part of this event
really ought to be useful as generic answer to any question aka
'everything can be proven with the help of a set of suitable
out-of-context quotes'.
In the given case, this 'quote' used to be a piece of advice to people
writing machine code supposed to be executed in the fairly byzantine
(by today's standards) CISC CPUs Knuth happened to be intimately
familiar with: "Don't worry about making maximally clever use of the
instruction set of the machine. Rather build a working 'inefficient'
solution and improve that afterwards". Translated to the 'Perl
universe', it should roughly become "Don't use the 'Perl golf'
approach for solving actual problems". Rather different from the use
you put it to, isn't it?
------------------------------
Date: Fri, 09 Nov 2012 15:21:43 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: how does $#array work internally?
Message-Id: <DdmdnegSFaMaggDNnZ2dnUVZ8g-dnZ2d@brightview.co.uk>
Helmut Tessarek wrote:
> I'm wondering how the $#array construct works internally.
>
> Does perl iterate through the array and return the highest index or does perl
> use some meta data within the array structure?
The latter. It's more like a Pascal string than a 'C' String.
BugBear
------------------------------
Date: Fri, 9 Nov 2012 15:45:18 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: how does $#array work internally?
Message-Id: <e1lvm9-jsc2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> In 1943, Joseph Goebbels held an infamous speech in the so-called
Godwin. You lose.
Ben
------------------------------
Date: Thu, 8 Nov 2012 07:05:12 -0800 (PST)
From: Joe <juliani.moon@gmail.com>
Subject: Re: STDOUT and STDERR from command lines
Message-Id: <318c9d59-7494-4607-b6d7-1076fe810a94@googlegroups.com>
Wow, it's great to learn. THANK YOU ALL so much!
(I would have no way to find them myself :-)
joe
------------------------------
Date: Thu, 8 Nov 2012 11:31:07 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Trampoline sub
Message-Id: <1e4a12e4-dfe1-4f4c-90d3-d52331508edf@googlegroups.com>
On Wednesday, November 7, 2012 9:37:43 AM UTC-8, Rainer Weikusat wrote:
> "C.DeRykus" <derykus@gmail.com> writes:
>
> > On Monday, November 5, 2012 6:45:45 AM UTC-8, Rainer Weikusat wrote:
>
> >> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
>
>
> [...]
>
>
>
> >> When building state machines in C, I usually use a function pointer
>
> >> as 'state variable' because this implies there's no need to
>
> >> explicitly written, state-dependent control transfer code. The
>
> >> first time I did this in Perl, it occurred to me that it should be
>
> >> possible to simplify the 'obvious' implementation,using a
>
> >> module-global scalar variable holding a reference to the
>
> >> subroutine to be executed next, to one which just invokes the
>
> >> subroutine by name
>
>
>
> [...]
>
>
>
> >> ------------
>
> >>
>
> >> package FlipFlop;
>
> >>
>
> >>
>
> >>
>
> >> require Exporter;
>
> >>
>
> >>
>
> >>
>
> >> our @ISA = qw(Exporter);
>
> >>
>
> >> our @EXPORT = qw(v);
>
> > -----
>
> > qw(*v); # <----------
>
> >
>
> > Ran into this by accident. Exporting the actual glob
>
> > makes your flipflop work:
>
> >
>
> > our @EXPORT = qw( *v );
>
> >
>
> > $ perl -MFlipFlop -le 'while(1) { print v();sleep 1}'
>
> > 0
>
> > 1
>
> > ...
>
> >
>
> > Here's the relevant bit from perlmod:
>
> >
>
> > What makes all of this important is that the
>
> > Exporter module uses glob aliasing as the import/
>
> > export mechanism. Whether or not you can properly
>
> > localize a variable that has been exported from a
>
> > module depends on how it was exported:
>
> >
>
> > @EXPORT = qw($FOO); # Usual form, can't be
>
> > # localized
>
> > @EXPORT = qw(*FOO); # Can be localized
>
>
>
> [...]
>
>
>
> > So, evidently, Perl has to be able localize the
>
> > glob... to do the glob twiddle on the fly.
>
>
>
> This is going to become somewhat lengthy ...
>
>
>
> What the text you quoted refers to as 'can be localized' is another
>
> side effect of the glob export. I think I should first show the
>
> difference between this "can't be localized" and "can be
>
> localized". Assuming that a file named Localized.pm with the following
>
> content
>
>
>
> -----------
>
> package Localized;
>
>
>
> require Exporter;
>
>
>
> our @ISA = qw(Exporter);
>
> our @EXPORT = qw($a_var a_sub);
>
>
>
> our $a_var = 3;
>
>
>
> sub a_sub {
>
> return $a_var + 1;
>
> }
>
>
>
> 1;
>
> ------------
>
>
>
> is available in the perl module search path, the program included
>
> below
>
>
>
> ------------
>
> use Localized;
>
>
>
> print a_sub(), "\n";
>
>
>
> {
>
> local $a_var = 55;
>
>
>
> print a_sub(), ' ', $a_var, "\n";
>
> }
>
> ------------
>
>
>
> will print
>
>
>
> ,----
>
> | 4
>
> | 4 55
>
> `----
>
>
>
> The reason for this can be seen by modifying it as follows:
>
>
>
[ ... ]
>
>
>
> Here, the GP associated with both names is identical and rebinding the
>
> SV slot of this GP thus causes a change visible to the a_sub
>
> subroutine. With this change, the output of the original program
>
> becomes
>
>
>
> ,----
>
> | 4
>
> | 56 55
>
> `----
>
>
>
> This 'GP' export is also what causes the subroutine switching in the
>
> FlipFlop example to work as intended: Since both FlipFlop::v and
>
> main::v share a GP, changing the CV slot of this GP in FlipFlop is
>
> also visible in main. The downsides of this for a pure subroutine
>
> export/ import are that changes in the importing module may now effect
>
> changes in the exporting module, as demonstrated in the a_var example,
>
> which is not exactly obvious and usually not intended, and that this
>
> still doesn't guarantee that modifications to the FlipFlop symbol
>
> table will remain visible in main: This only works for as long as both
>
> continue to share the GP and it is possible to cause a new GP to be
>
> assigned to either v, eg, by assigning a different glob to *v.
Good explanation. I'm kinda surprised perlsub
doesn't toss in a quick warning reminder about
the power/danger of typeglob aliasing - esp.
potential damage to encapsulation if there's
a sub call.
Perhaps a more simplistic, yet safer FlipFlop approach would just use 'state':
package FlipFlop;
require Exporter;
our @ISA = qw(Exporter);
our @EXPORT = qw( v );
state $flip = 0;
sub v { $flip =!$flip; return $flip ? 0 : 1}
1;
--
Charles DeRykus
------------------------------
Date: Thu, 08 Nov 2012 19:39:25 +0100
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: utf-2d (was: Re: Why "Wide character in print"?)
Message-Id: <509bfc5d$0$6864$e4fe514c@news2.news.xs4all.nl>
On 2012-11-05 23:48, Ben Morrow wrote:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>>> (In practice it would break XS, so it probably won't happen, which is a
>>> shame. UTF-8 was a very bad choice of internal representation, in
>>> retrospect, though it seemed to make sense at the time. It makes a great
>>> many internal operations much more complicated than they need to be,
>>> because you can no longer index into an array to find a particular
>>> character in the string.)
>>
>> The only way to provide that is to store all characters as integer
>> values large enough to encompass all conceivably existing Unicode
>> codepoints. Otherwise, you're going to have multibyte characters and
>> consequently, 'indexing into the array to find a particular character
>> in the string' won't work anymore.
>
> Yes. That's called 'a 32-bit int', and is the standard wchar_t C
> representation of Unicode. A sensible alternative would be a 1/2/4-byte
> upgrade scheme somewhat similar to the current Perl scheme, but with all
> the alternatives being constant width; a smarter alternative would be to
> represent a string as a series of pieces, each of which could make a
> different choice (and, potentially, some of which could be shared or CoW
> with other strings).
Let's invent the byte-oriented utf-2d.
The bytes for the special (i.e. non-ASCII) characters have the high bit
on, and further still have a meaningful value, such that they can be
matched as a (cased) word-character / digit / whitespace, punctuation, etc.
Per special character position there can be an entry in the side table,
that defines the real data for that position.
The 80-8F bytes are for future extensions. An 9E-byte can prepend a data
part. An 9F byte (ends a data part and) starts a table part.
An ASCII buffer remains as is. A latin1 buffer also remains as is,
unless it contains a code point between 80 and 9F.
Possible usage of 90-9F, assuming " 0Aa." collation:
90: .... space
91: ...# digit
92: ..#. upper
93: ..## upper|digit
94: .#.. lower
95: .#.# lower|digit
96: .##. alpha
97: .### alnum
98: #... punct
99: #..# numeric?
9A: #.#. ...
9B: #.## ...
9C: ##.. ...
9D: ##.# ...
9E: ###. SOD (start-of-data)
9F: #### SOT (start-of-table)
--
Ruud
------------------------------
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 3815
***************************************
