[31927] in Perl-Users-Digest
Perl-Users Digest, Issue: 3190 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 28 03:09:32 2010
Date: Thu, 28 Oct 2010 00:09:11 -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 Thu, 28 Oct 2010 Volume: 11 Number: 3190
Today's topics:
Re: CGI, multiple page data input. <justin.1010@purestblue.com>
Outer scope of a sub inside a sub <koszalekopalek@interia.pl>
Re: Outer scope of a sub inside a sub <derykus@gmail.com>
Re: Outer scope of a sub inside a sub <jl_post@hotmail.com>
Re: Outer scope of a sub inside a sub sln@netherlands.com
Re: Outer scope of a sub inside a sub <xhoster@gmail.com>
Re: Outer scope of a sub inside a sub <bart.lateur@telenet.be>
Re: Outer scope of a sub inside a sub <koszalekopalek@interia.pl>
thought you all might like this... <r@thevoid1.net>
Re: thought you all might like this... <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 27 Oct 2010 09:09:26 +0100
From: Justin C <justin.1010@purestblue.com>
Subject: Re: CGI, multiple page data input.
Message-Id: <ma3lp7-bcn.ln1@zem.masonsmusic.co.uk>
On 2010-10-22, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
> Justin C wrote:
>> On 2010-10-19, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>
>>> It is not clear to me that the direction you indicate is a 'forward'
>>> direction.
>>
>> Xho, the problem is that in some of my programs there are many fields to
>> the forms (invoice lines, often they number in the hundreds), and to
>> add:
>> print hidden(-name=>'some-name', -value=>$cgi->param('some-name'));
>> a few hundred times is extremely ugly.
>
> Well then don't do that. Use a loop. Switching from hidden to session
> isn't going to change that. You can write horrible code either way, if
> you work hard at it.
Oh, I don't have to work hard, it comes perfectly naturally. I am,
however, trying to improve.
> And where do these hundreds of invoice lines come from? Did you make
> the user enter them one by one, each into a different form element? Or
> did you compute them from a more compact form of entry? If the latter,
> why not just send back the compact form, and recompute the list on the
> next submission?
The user copy/pastes. That is an idea, I shall think about it.
>> There has to be a better way. But
>> as Jurgen mentioned, it's not a perl problem, though it can be solved
>> with perl.
>>
>> I've looked at CGI::Session, and decided to re-invent the wheel.
>
> Why?
I know, makes no sense, call it a logic failure. Either I get the hang
of sessions or I don't, what I have proposed appears to fall between the
two, yes it is some kind of session management, but it isn't as robust
as 'real' session management as provided by CGI::Session.
Maybe time to think again.
>> The
>> program is for internal use only and there is nothing to be gained by
>> users messing around with it, so I'm creating a sort of session ID that
>> I will pass in a hidden field, and using Storable to store/retrieve the
>> entire hash submitted by the browser. CGI::Session seemed overkill.
>>
>> For a session ID I'm using:
>> my $sid = md5_hex (int(rand(99999999)));
>
> Why not just use the random integer directly?
Because I stupidly swiped the code from a web-site somewhere and gave no
consideration to why they were doing it that way... I still have no
idea.
> Using md5 this way
> doesn't make accidental collisions less likely. And since you have just
> published your intentions, using an md5 doesn't make malicious ones less
> likely, either.
This is purely for internal use at my employment, and I don't think
there is any way a user here could maliciously use previously uploaded
invoice data to create an invoice for customs. If they wanted to create
a false invoice it's easier to just provide the false data in the first
place.
Thank you for pointing out the errors in my thinking (or errors I make
when I don't think).
Justin.
------------------------------
Date: Wed, 27 Oct 2010 08:45:46 -0700 (PDT)
From: Koszalek Opalek <koszalekopalek@interia.pl>
Subject: Outer scope of a sub inside a sub
Message-Id: <eb1de2b4-4d9b-48ec-9bfa-20d45a54a580@t13g2000yqm.googlegroups.com>
Could you elaborate on the subtlety related to scoping demonstrated
by the listing below?
Routine run_test_1 contains a definition of sub filter().
Filter is then passed in a call to add_elem() as a code reference.
run_test_2 uses a different syntax:
my $filter = sub { ...
and then passes variable $filter.
They work identical in the first run. In the second run, however,
the variable @elems accessed by sub filter is not the same as
the variable defined in the body of run_test_1.
Full disclosure: perl emits the following warning:
Variable "@elems" will not stay shared at /tmp/test.pl line 15
#!/usr/bin/perl
use strict;
use warnings;
use Scalar::Util qw/refaddr/;
sub add_elem {
$_[0]->();
}
sub run_test_1 {
my @elems = ();
sub filter {
printf "%d\n", refaddr \@elems;
push @elems, $_[0];
}
add_elem( \&filter, "abc" );
add_elem( \&filter, "abc" );
printf "Total number of elements %d\n", scalar @elems;
};
sub run_test_2 {
my @elems = ();
my $filter = sub {
printf "%d\n", refaddr \@elems;
push @elems, $_[0];
};
add_elem( $filter, "abc" );
add_elem( $filter, "abc" );
printf "Total number of elements %d\n", scalar @elems;
};
print "--- Test 1 ---\n";
run_test_1();
run_test_1();
print "--- Test 2 ---\n";
run_test_2();
run_test_2();
------------------------------
Date: Wed, 27 Oct 2010 09:50:29 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Outer scope of a sub inside a sub
Message-Id: <ad2a26bc-16eb-4684-99da-dec8ea7394fe@g25g2000yqn.googlegroups.com>
On Oct 27, 8:45=A0am, Koszalek Opalek <koszalekopa...@interia.pl> wrote:
> Could you elaborate on the subtlety related to scoping demonstrated
> by the listing below?
>
> Routine run_test_1 contains a definition of sub filter().
> Filter is then passed in a call to add_elem() as a code reference.
>
> run_test_2 uses a different syntax:
> =A0 =A0my $filter =3D sub { ...
> and then passes variable $filter.
>
> They work identical in the first run. In the second run, however,
> the variable @elems accessed by sub filter is not the same as
> the variable defined in the body of run_test_1.
>
> Full disclosure: perl emits the following warning:
> Variable "@elems" will not stay shared at /tmp/test.pl line 15
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use Scalar::Util qw/refaddr/;
>
> sub add_elem {
> =A0 =A0 =A0 =A0 $_[0]->();
>
> }
>
> sub run_test_1 {
> =A0 =A0 =A0 =A0 my @elems =3D ();
>
> =A0 =A0 =A0 =A0 sub filter {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "%d\n", refaddr \@elems;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 push @elems, $_[0];
> =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 add_elem( \&filter, "abc" );
> =A0 =A0 =A0 =A0 add_elem( \&filter, "abc" );
> =A0 =A0 =A0 =A0 printf "Total number of elements %d\n", scalar @elems;
>
> };
>
> sub run_test_2 {
> =A0 =A0 =A0 =A0 my @elems =3D ();
>
> =A0 =A0 =A0 =A0 my $filter =3D sub {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "%d\n", refaddr \@elems;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 push @elems, $_[0];
> =A0 =A0 =A0 =A0 };
>
> =A0 =A0 =A0 =A0 add_elem( $filter, "abc" );
> =A0 =A0 =A0 =A0 add_elem( $filter, "abc" );
> =A0 =A0 =A0 =A0 printf "Total number of elements %d\n", scalar @elems;
>
> };
>
> print "--- Test 1 ---\n";
> run_test_1();
> run_test_1();
>
> print "--- Test 2 ---\n";
> run_test_2();
> run_test_2();
You'll need to use an anonymous sub instead of
a named one in both.
Add this pragma: 'use diagnostics -verbose;',
to see a full explanation of the error.
--
Charles DeRykus
------------------------------
Date: Wed, 27 Oct 2010 12:40:23 -0700 (PDT)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Re: Outer scope of a sub inside a sub
Message-Id: <a6c235ff-03e1-4f5a-9498-b77fb6eb66c6@f33g2000yqh.googlegroups.com>
On Oct 27, 9:45=A0am, Koszalek Opalek <koszalekopa...@interia.pl> wrote:
> Could you elaborate on the subtlety related to scoping demonstrated
> by the listing below?
>
> They work identical in the first run. In the second run, however,
> the variable @elems accessed by sub filter is not the same as
> the variable defined in the body of run_test_1.
>
> Full disclosure: perl emits the following warning:
> Variable "@elems" will not stay shared at /tmp/test.pl line 15
>
> #!/usr/bin/perl
> use strict;
> use warnings;
> use Scalar::Util qw/refaddr/;
>
> sub add_elem {
> =A0 =A0 =A0 =A0 $_[0]->();
>
> }
>
> sub run_test_1 {
> =A0 =A0 =A0 =A0 my @elems =3D ();
>
> =A0 =A0 =A0 =A0 sub filter {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "%d\n", refaddr \@elems;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 push @elems, $_[0];
> =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 add_elem( \&filter, "abc" );
> =A0 =A0 =A0 =A0 add_elem( \&filter, "abc" );
> =A0 =A0 =A0 =A0 printf "Total number of elements %d\n", scalar @elems;
>
> };
>
> sub run_test_2 {
> =A0 =A0 =A0 =A0 my @elems =3D ();
>
> =A0 =A0 =A0 =A0 my $filter =3D sub {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 printf "%d\n", refaddr \@elems;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 push @elems, $_[0];
> =A0 =A0 =A0 =A0 };
>
> =A0 =A0 =A0 =A0 add_elem( $filter, "abc" );
> =A0 =A0 =A0 =A0 add_elem( $filter, "abc" );
> =A0 =A0 =A0 =A0 printf "Total number of elements %d\n", scalar @elems;
>
> };
>
> print "--- Test 1 ---\n";
> run_test_1();
> run_test_1();
>
> print "--- Test 2 ---\n";
> run_test_2();
> run_test_2();
You are printing out the refaddr of @elems only before you push a
new element onto it, yet not right before you query it for its
length. Consider adding the line:
printf "%d\n", refaddr \@elems;
inside both the filter() and $filter subroutines. With this change, I
see this output:
--- Test 1 ---
4639308
4639308
4639308
Total number of elements 2
4639308
4639308
10075924
Total number of elements 0
--- Test 2 ---
4848924
4848924
4848924
Total number of elements 2
4848924
4848924
4848924
Total number of elements 2
You'll see that, although run_test_1() always adds to the same
@elems array, it seems to be calling scalar() on a different one.
That's why run_test_1() shows @elem as having a different number of
elements on subsequent runs: except for that first time, @elems in
filter() does not match @elems in run_test_1().
In other words, @elems in the filter() subroutine is constructed
only once, whereas @elems in run_test_1() is constructed every time
run_test_1() is called. They only match the first time run_test_1()
is called.
As for run_test_2(), the $filter subroutine is constructed every
time run_test_2() is called, and it uses the @elems array declared in
the previous line.
It's a bit confusing because my output shows that the @elems array
in run_test_2() always has the same refaddr (which is probably what
you're seeing as well). But that's only happening because it gets
cleaned up (as there are no more references to it), and further calls
to run_test_2() are using the same memory space for @elems, now that
it has been freed.
To prevent the same memory space from being re-used, declare a
global @references array at the top of the script, and insert the
line:
push @references, \@elems;
after each declaration of @elems. That (and my earlier suggestion of
printing refaddr(\@elems) inside the filter() and $filter subroutines)
should make it clearer as to which @elems array is being used when.
I hope this helps, Koszalek.
-- Jean-Luc
------------------------------
Date: Wed, 27 Oct 2010 15:10:08 -0700
From: sln@netherlands.com
Subject: Re: Outer scope of a sub inside a sub
Message-Id: <no8hc69p74ohbj201oqkecomj6enbip6eu@4ax.com>
On Wed, 27 Oct 2010 08:45:46 -0700 (PDT), Koszalek Opalek <koszalekopalek@interia.pl> wrote:
>Could you elaborate on the subtlety related to scoping demonstrated
>by the listing below?
>
>Routine run_test_1 contains a definition of sub filter().
>Filter is then passed in a call to add_elem() as a code reference.
>
>run_test_2 uses a different syntax:
> my $filter = sub { ...
>and then passes variable $filter.
>
>They work identical in the first run. In the second run, however,
>the variable @elems accessed by sub filter is not the same as
>the variable defined in the body of run_test_1.
>
>Full disclosure: perl emits the following warning:
>Variable "@elems" will not stay shared at /tmp/test.pl line 15
>
>
The easiest way to see it is to put some debug statements in.
filter() stays in the first scope of test1
the first time its called and everytime.
When you push it goes into the first @elems.
$filter is a new instance of sub {} and
is new to test2 everytime its called.
Every time you push, it goes into a new @elems.
Btw, you are not pushing anything but undef's.
-sln
use strict;
use warnings;
use Scalar::Util qw/refaddr/;
sub add_elem {
$_[0]->( $_[0] );
}
sub run_test_1 {
my @elems = ();
printf "\n\ntest_1 : addr \@elems = %d\n", refaddr \@elems;
sub filter {
push @elems, $_[0];
printf " filter() : addr \@elems = %d, scalar \@elems = %d\n", refaddr \@elems, scalar @elems;
printf " my sub addr = %d\n", refaddr $_[0];
}
add_elem( \&filter, "abc" );
add_elem( \&filter, "abc" );
printf "Total number of elements %d, addr elems = %d\n", scalar @elems, refaddr \@elems;
};
sub run_test_2 {
my @elems = ();
printf "\n\ntest_2 : addr \@elems = %d\n", refaddr \@elems;
my $filter = sub {
push @elems, $_[0];
printf " \$filter->() : addr \@elems = %d, scalar \@elems = %d\n", refaddr \@elems, scalar @elems;
printf " my sub addr = %d\n", refaddr $_[0];
};
add_elem( $filter, "abc" );
add_elem( $filter, "abc" );
printf "Total number of elements %d\n", scalar @elems;
};
print "\n\n\n--- Test 1 ---\n";
run_test_1();
run_test_1();
print "\n\n\n--- Test 2 ---\n";
run_test_2();
run_test_2();
__END__
Variable "@elems" will not stay shared at aa.pl line 15.
--- Test 1 ---
test_1 : addr @elems = 25453388
filter() : addr @elems = 25453388, scalar @elems = 1
my sub addr = 25631444
filter() : addr @elems = 25453388, scalar @elems = 2
my sub addr = 25631444
Total number of elements 2, addr elems = 25453388
test_1 : addr @elems = 2272444
filter() : addr @elems = 25453388, scalar @elems = 3
my sub addr = 25631444
filter() : addr @elems = 25453388, scalar @elems = 4
my sub addr = 25631444
Total number of elements 0, addr elems = 2272444
--- Test 2 ---
test_2 : addr @elems = 25650684
$filter->() : addr @elems = 25650684, scalar @elems = 1
my sub addr = 2272124
$filter->() : addr @elems = 25650684, scalar @elems = 2
my sub addr = 2272124
Total number of elements 2
test_2 : addr @elems = 25651212
$filter->() : addr @elems = 25651212, scalar @elems = 1
my sub addr = 25651196
$filter->() : addr @elems = 25651212, scalar @elems = 2
my sub addr = 25651196
Total number of elements 2
------------------------------
Date: Wed, 27 Oct 2010 18:31:57 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Outer scope of a sub inside a sub
Message-Id: <4cc8e522$0$2201$ed362ca5@nr5-q3a.newsreader.com>
Koszalek Opalek wrote:
>
> Full disclosure: perl emits the following warning:
> Variable "@elems" will not stay shared at /tmp/test.pl line 15
>
...
>
> sub run_test_1 {
> my @elems = ();
At compile time, a memory location is arranged for @elems. The first
time run_test_1 is called, it uses this location set up at compile time.
But on subsequent calls, it sets a new location.
>
> sub filter {
> printf "%d\n", refaddr \@elems;
> push @elems, $_[0];
> }
At compile time, this glombs onto the same memory location as was used
for @elems when the outer scope was compiled. It is not subsequently
recompiled, and so does not re-glomb onto the new addresses when new
addresses come into existence.
>
> sub run_test_2 {
> my @elems = ();
>
> my $filter = sub {
> printf "%d\n", refaddr \@elems;
> push @elems, $_[0];
> };
This is recompiled for each invocation of run_test_2, and so re-glombs
onto the underlying address of the structure behind @elems which is in
use each time it recompiled. (I don't think it is recompiles in full,
they use shortcuts that allows it to re-glomb, with full recompilation.
But it behaves as if it were recompiled)
Xho
------------------------------
Date: Thu, 28 Oct 2010 05:44:32 +0200
From: Bart Lateur <bart.lateur@telenet.be>
Subject: Re: Outer scope of a sub inside a sub
Message-Id: <o0rhc6946c1aco13jnas10uf88trqpar6v@4ax.com>
Koszalek Opalek wrote:
>Could you elaborate on the subtlety related to scoping demonstrated
>by the listing below?
>
>Routine run_test_1 contains a definition of sub filter().
>Filter is then passed in a call to add_elem() as a code reference.
>
>run_test_2 uses a different syntax:
> my $filter = sub { ...
>and then passes variable $filter.
>
>They work identical in the first run. In the second run, however,
>the variable @elems accessed by sub filter is not the same as
>the variable defined in the body of run_test_1.
That is one of the biggest warts in Perl, in my not so humble opinion.
The second is behaving in the way the first should have behaved, and as
it does behave in other more sane languages that have nested subs, and
as it behaves in Javascript.
The first is... well... an abomination.
How it behaves is that the nested sub, even though it is defined inside
a sub, is still a global definition. Test it out, in the second example,
the sub filter is still accessible *outside* the scope of run_test_1.
And it is defined once. It's a closure bound to the variables in the
first invocation of the run of the outer sub. So every time you run
filter, it will access the same, now anonymous, variables, be it if you
run it outside of the outer sub, or inside it.
Why it behaves like that? Well, I'm not sure, but I think it was related
to how BEGIN and END (and INIT, and CHECK...) blocks are actually subs,
and you can have sub definitions inside them. Those subs have to behave
globally, as if they were not inside the BEGIN block. Something like
that.
I once chatted to a few of the top P5P people about it, and they said it
was *never* going to change.
Like I said, I think it's an abomination. I think BEGIN, INIT, CHECK
etc. should be special cased, not just subs, to behave like this, and
normal subs should behave differently: the inner sub should really be
only visible inside the scope of the outer sub, be it with local (so
it'll also be visible in subs that you call from within the outer sub),
or, more sane, truely lexical (the way your second example behaves). But
lexical subs don't exist, unfortunately.
BTW here's an example using local:
sub run_test_3 {
my @elems = ();
local *filter = sub {
printf "%d\n", refaddr \@elems;
push @elems, $_[0];
}
...
}
That local assignment should happen first when the sub is called, even
if the "sub filter" definition in the source happens to be in the end of
the outer sub.
I'm not sure itll behave properly if you depend on \&filter, though...
But plain `filter(...)` invocations should behave well.
--
Bart.
------------------------------
Date: Wed, 27 Oct 2010 22:37:45 -0700 (PDT)
From: Koszalek Opalek <koszalekopalek@interia.pl>
Subject: Re: Outer scope of a sub inside a sub
Message-Id: <61361de6-fbf3-4d39-81d9-8d060a6d27ef@l17g2000yqe.googlegroups.com>
On Oct 28, 5:44=A0am, Bart Lateur <bart.lat...@telenet.be> wrote:
> Koszalek Opalek wrote:
> >Could you elaborate on the subtlety related to scoping demonstrated
> >by the listing below?
>
> That is one of the biggest warts in Perl, in my not so humble opinion.
> The second is behaving in the way the first should have behaved, and as
> it does behave in other more sane languages that have nested subs, and
> as it behaves in Javascript.
Thanks to everyone who posted a reply.
A very interesting thread IMO :-)
A.
------------------------------
Date: Wed, 27 Oct 2010 21:57:12 -0700 (PDT)
From: Robin <r@thevoid1.net>
Subject: thought you all might like this...
Message-Id: <d0e1a426-23d0-4925-b5b6-4679aa9f22ea@26g2000yqv.googlegroups.com>
#!/usr/bin/perl
use Tk;
$m = new MainWindow ();
my $t1 = 400;
$c = $m -> Canvas (-width=>$t1, -height=>400, -background=>"black") ->
pack ();
$l = $m -> Label (-text=>"Write sentences to invade and release good
guys at the same time") -> pack ();
$t = $m -> Scrolled ("Text") -> pack ();
$t -> bind ("<a>", \&d);
$t -> bind ("<u>", \&d);
$t -> bind ("<e>", \&d);
$t -> bind ("<i>", \&d);
$t -> bind ("<o>", \&d);
MainLoop ();
sub d () {
my $e = int rand ($t1);
my $e2 = int rand ($t1);
my $e3 = int rand ($t1);
my $e4 = int rand ($t1);
$c -> create ("rectangle", $e, $e2, $e3, $e4, -outline=>"red");
my $e = int rand ($t1);
my $e2 = int rand ($t1);
my $e3 = int rand ($t1);
my $e4 = int rand ($t1);
$c -> create ("rectangle", $e, $e2, $e3, $e4, -outline=>"black");
my $e = int rand ($t1);
my $e2 = int rand ($t1);
my $e3 = int rand ($t1);
my $e4 = int rand ($t1);
$c -> create ("rectangle", $e, $e2, $e3, $e4, -outline=>"black");
if ($e == 50 or $e == 50 or $e == 301 or $e == 100) {
$z += 1;
$c -> create ("rectangle", $e, $e2, $e3, $e4, -outline=>"yellow");
$l -> configure (-text=>"Your score is $z\n");
}
if ($z == 200) {
$m -> Dialog (-text=>"You win. Now write about what the screen
looked like.") -> Show ();
exit ();
}
}
------------------------------
Date: Thu, 28 Oct 2010 00:32:41 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: thought you all might like this...
Message-Id: <slrnici324.29v.tadmc@tadbox.sbcglobal.net>
Robin <r@thevoid1.net> wrote:
Please choose one posting address and stick with it.
> Subject: thought you all might like this...
Please put the subject of your article in the Subject of your article!
> my $e = int rand ($t1);
> my $e2 = int rand ($t1);
> my $e3 = int rand ($t1);
> my $e4 = int rand ($t1);
> $c -> create ("rectangle", $e, $e2, $e3, $e4, -outline=>"red");
Sequentially numbered variables nearly always indicate that you
are using the wrong data structure. Use an array instead:
my @e = map {int rand($t1)} 1..4;
$c->create("rectangle", @e, -outline=>"red");
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
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 3190
***************************************
