[31816] in Perl-Users-Digest
Perl-Users Digest, Issue: 3079 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 16 21:09:23 2010
Date: Mon, 16 Aug 2010 18:09:09 -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 Mon, 16 Aug 2010 Volume: 11 Number: 3079
Today's topics:
Re: combining hashes sln@netherlands.com
Re: combining hashes <tadmc@seesig.invalid>
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <tadmc@seesig.invalid>
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <ben@morrow.me.uk>
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <cartercc@gmail.com>
Re: combining hashes <kkeller-usenet@wombat.san-francisco.ca.us>
Re: combining hashes <kkeller-usenet@wombat.san-francisco.ca.us>
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <kst-u@mib.org>
Re: combining hashes <kst-u@mib.org>
Re: combining hashes <uri@StemSystems.com>
Re: combining hashes <sherm.pendley@gmail.com>
Re: FAQ 4.18 Does Perl have a Year 2000 or 2038 problem <jimsgibson@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 16 Aug 2010 13:39:03 -0700
From: sln@netherlands.com
Subject: Re: combining hashes
Message-Id: <la8j66d1p0rmm4pl53ecqpj19d5u6nih38@4ax.com>
On Mon, 16 Aug 2010 15:53:59 -0400, monkeys paw <monkey@joemoney.net> wrote:
>I have two hashrefs, i want to combine them into one hash.
>I think there is an easier way than what i am doing (shown below):
>
>$fc = {'a' => 'hash'};
>$ref = {'another' => 'hash'};
>
> for (keys %{$fc}) {
> $args{$_} = $fc->{$_};
> }
> for (keys %{$ref}) {
> $args{$_} = $ref->{$_};
> }
Yes, the easier way is this:
$args = {'a' => 'hash', 'another' => 'hash'};
Why do you ask?
-sln
------------------------------
Date: Mon, 16 Aug 2010 15:40:18 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: combining hashes
Message-Id: <slrni6j8af.mdo.tadmc@tadbox.sbcglobal.net>
monkeys paw <monkey@joemoney.net> wrote:
> I have two hashrefs, i want to combine them into one hash.
What do you want to do if the same key is in both of the hashrefs?
> I think there is an easier way than what i am doing (shown below):
>
> $fc = {'a' => 'hash'};
> $ref = {'another' => 'hash'};
>
> for (keys %{$fc}) {
> $args{$_} = $fc->{$_};
> }
> for (keys %{$ref}) {
> $args{$_} = $ref->{$_};
> }
my %args = (%$fc, %$ref);
--
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: Mon, 16 Aug 2010 13:53:47 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <c7f578ea-048b-4580-b9cf-b8e1df09b7cc@i31g2000yqm.googlegroups.com>
On Aug 16, 3:53=A0pm, monkeys paw <mon...@joemoney.net> wrote:
> I have two hashrefs, i want to combine them into one hash.
What do you mean, 'combine them?'
A hash is an ordered data structure indexed by a specific key. To me,
'combining' a hash implies consolidating them so that a common key has
the values referenced in each of the two separate hashes. Obviously,
your choice of a key will determined exactly how you would do this.
Also, how you would handle anomalies would be important as well.
Here is a simple example of combining two hashes that are related, the
first by order and the second by name, combined using the order as the
key with the values of the name and year.
=3D=3D=3D=3D=3D=3D=3D=3Doutput=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
first hash:
first =3D> Washington
second =3D> Adams
fifth =3D> Monroe
third =3D> Jefferson
fourth =3D> Madison
second hash:
Jefferson =3D> 1800
Adams =3D> 1792
Monroe =3D> 1816
Washington =3D> 1788
Madison =3D> 1808
third hash:
first =3D>
name -> Washington, year -> 1788,
second =3D>
name -> Adams, year -> 1792,
third =3D>
name -> Jefferson, year -> 1800,
fifth =3D>
name -> Monroe, year -> 1816,
fourth =3D>
name -> Madison, year -> 1808,
=3D=3D=3D=3D=3D=3D=3D=3D=3Dcode=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
my ($h1, $h2, $h3);
$h1 =3D { first =3D> 'Washington',
second =3D> 'Adams',
third =3D> 'Jefferson',
fourth =3D> 'Madison',
fifth =3D> 'Monroe',
};
$h2 =3D { Washington =3D> 1788,
Adams =3D> 1792,
Jefferson =3D> 1800,
Madison =3D> 1808,
Monroe =3D> 1816,
};
print "\nfirst hash:\n";
foreach my $k (keys %{$h1}) { print "$k =3D> $h1->{$k}\n"; }
print "\nsecond hash:\n";
foreach my $k (keys %{$h2}) { print "$k =3D> $h2->{$k}\n"; }
foreach my $k (keys %{$h1})
{
$h3->{$k} =3D { name =3D> $h1->{$k},
year =3D> $h2->{$h1->{$k}},
}
}
print "\nthird hash:\n";
foreach my $k1 (keys %{$h3})
{
print "\n$k1 =3D> \n";
foreach my $k2 (keys %{$h3->{$k1}})
{
print " $k2 -> $h3->{$k1}{$k2}, ";
}
}
------------------------------
Date: Mon, 16 Aug 2010 15:57:37 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: combining hashes
Message-Id: <slrni6j9au.mk9.tadmc@tadbox.sbcglobal.net>
ccc31807 <cartercc@gmail.com> wrote:
> A hash is an ordered data structure indexed by a specific key.
s/ordered/unordered/;
--
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: Mon, 16 Aug 2010 14:10:53 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <b6361097-b6f0-4b02-af0d-a83358904748@5g2000yqz.googlegroups.com>
On Aug 16, 4:57=A0pm, Tad McClellan <ta...@seesig.invalid> wrote:
> ccc31807 <carte...@gmail.com> wrote:
> > A hash is an ordered data structure indexed by a specific key.
>
> s/ordered/unordered/;
Yes, that's what the book says. My mind's eye sees it differently.
An array (which you would call an ordered data structure) is ordered
only by the numerical index, which is meaningless in terms of
information, i.e., it bears no necessary relation to the content of
the position but only indicated the numerical position in the array.
OTOH, a hash (which you would call an unordered data structure) is
ordered by the value of the key, which provides entry to the data
based on a human understandable value.
Okay, if you have data that carries an intrinsic numerical order, such
as DOW {0 =3D> Sunday, 1 =3D> Monday, ...} or MOY (0 =3D> '', 1 =3D> Jan, 2=
=3D>
Feb, ...} then the array is the way to go.
However, if the data is a complex structure, such as a person, with
various names, an address, DOB, SSN, etc., then my mind's eye
visualizes it as a structured entity based on a unique key. I see it
as a database table with an informational key, rather than a table
with a serial or autoincrement integer as the key.
This is what I meant by 'ordered' and I apologize for the confusion.
CC.
------------------------------
Date: Mon, 16 Aug 2010 22:09:52 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: combining hashes
Message-Id: <02moj7-ukn1.ln1@osiris.mauzo.dyndns.org>
Quoth monkeys paw <monkey@joemoney.net>:
> I have two hashrefs, i want to combine them into one hash.
perldoc -q merge
Ben
------------------------------
Date: Mon, 16 Aug 2010 17:40:47 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87hbiu6xsw.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Aug 16, 4:57 pm, Tad McClellan <ta...@seesig.invalid> wrote:
>> ccc31807 <carte...@gmail.com> wrote:
>> > A hash is an ordered data structure indexed by a specific key.
>>
>> s/ordered/unordered/;
c> Yes, that's what the book says. My mind's eye sees it differently.
change your eyes! :)
c> An array (which you would call an ordered data structure) is
c> ordered only by the numerical index, which is meaningless in terms
c> of information, i.e., it bears no necessary relation to the content
c> of the position but only indicated the numerical position in the
c> array.
but regardless, an array has ORDER. that is the whole idea of indexing
by integers. your limited exposure to other programs (as you so often
say) means you don't get the reason for arrays. they are to keep data in
order. and in perl this means you can also push/pop/shift/splice them
and the rest stay in the order. the order is static after you make any
changes. arrays are also classically fast to index because of the
integer index. in languages like c, array access is hardware level fast
with only a few machine instructions needed in most cases.
c> OTOH, a hash (which you would call an unordered data structure) is
c> ordered by the value of the key, which provides entry to the data
c> based on a human understandable value.
but keys have no order unless you sort them. if you call keys you get
them in a pseudo random order. if you then assign more elements, keys
will likely return them in a DIFFERENT order. hence there is no inherent
order to the elements of a hash. that is the whole point. in classic c
langs, to get access to an element keyed by a string your first pass was
a sequential scan and looking at each key. ordering doesn't help
there. hashes are designed to allow a faster access to any element
regardless of the key. in perl that means they are close to arrays in
speed. in c they are much slower than arrays since you need to do
several serious calculations and such to find the right element. but
they are still faster than any other common key based lookup style
(binary search, trees, etc.)
c> Okay, if you have data that carries an intrinsic numerical order, such
c> as DOW {0 => Sunday, 1 => Monday, ...} or MOY (0 => '', 1 => Jan, 2 =>
c> Feb, ...} then the array is the way to go.
not if you were converting the names to numbers!
c> However, if the data is a complex structure, such as a person, with
c> various names, an address, DOB, SSN, etc., then my mind's eye
c> visualizes it as a structured entity based on a unique key. I see
c> it as a database table with an informational key, rather than a
c> table with a serial or autoincrement integer as the key.
so? that is one view of a particular hash. again the order is in your
mind, not in the hash. you are so brainwashed by dbs that all you see
are records with 'ordered' fields like in a table. this is not how perl
sees it nor how you should when you think hashes.
c> This is what I meant by 'ordered' and I apologize for the confusion.
apology not accepted until you transform your understanding of
hashes. they are not ordered. period. any ordering comes from the
outside or from your db distorted brain! :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 16 Aug 2010 15:04:51 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: combining hashes
Message-Id: <fc2f3847-3d42-4e5c-b30c-3a09c63c3368@j18g2000yqd.googlegroups.com>
On Aug 16, 5:40=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> =A0 c> This is what I meant by 'ordered' and I apologize for the confusio=
n.
>
> apology not accepted until you transform your understanding of
> hashes. they are not ordered. period. any ordering comes from the
> outside or from your db distorted brain! :)
Okey doke, then. Apology withdrawn.
Let me recast my statement: the keys of a hash are ordered in the
sense that the value of the key correlates to the content of the hash,
while the indices of an array are ordered but the values contained in
the array are not necessarily ordered, although they certain can be.
And yes, I know that the order of the items in an array do not change
because they are tied to the numerical order of the index, while the
output order of a hash is nondeterministic.
Further, while my exposure to a variety of programs may be limited,
that in and of itself carries no significance other than not knowing a
great number of programs. If you spread yourself too thin, you lose
the opportunity to gain proficiency with specific tools. Ideally, we
would all like to be both wide and deep, but we have to be judicious
in the use of our time.
Now, Uri, my question concerned the 'combining' of two hashes. What to
you make of the question, and how would you do it?
CC.
------------------------------
Date: Mon, 16 Aug 2010 15:14:48 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: combining hashes
Message-Id: <orpoj7xd8a.ln2@goaway.wombat.san-francisco.ca.us>
On 2010-08-16, ccc31807 <cartercc@gmail.com> wrote:
>
> OTOH, a hash (which you would call an unordered data structure) is
> ordered by the value of the key, which provides entry to the data
> based on a human understandable value.
A Perl hash is *indexed* by the value of the key. It's not ordered
by the value of the key.
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Mon, 16 Aug 2010 15:24:57 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: combining hashes
Message-Id: <qeqoj7xmca.ln2@goaway.wombat.san-francisco.ca.us>
On 2010-08-16, ccc31807 <cartercc@gmail.com> wrote:
>
> Let me recast my statement: the keys of a hash are ordered in the
> sense that the value of the key correlates to the content of the hash,
s/ordered/indexed/;
> Now, Uri, my question concerned the 'combining' of two hashes. What to
> you make of the question, and how would you do it?
See Ben's answer (though it doesn't seem to be in my 5.8.8 docs). But
of course it's on the internets:
http://perldoc.perl.org/perlfaq4.html#How-do-I-merge-two-hashes%3F
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Mon, 16 Aug 2010 18:31:37 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <87sk2e5gvq.fsf@quad.sysarch.com>
>>>>> "c" == ccc31807 <cartercc@gmail.com> writes:
c> On Aug 16, 5:40 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>> c> This is what I meant by 'ordered' and I apologize for the confusion.
>>
>> apology not accepted until you transform your understanding of
>> hashes. they are not ordered. period. any ordering comes from the
>> outside or from your db distorted brain! :)
c> Okey doke, then. Apology withdrawn.
c> Let me recast my statement: the keys of a hash are ordered in the
c> sense that the value of the key correlates to the content of the hash,
c> while the indices of an array are ordered but the values contained in
c> the array are not necessarily ordered, although they certain can be.
you have a strange definition of order. what you say is an association
(hashes used to be called associative arrays), not an ordering. ordering
ALWAYS implies sequence. hashes have no inherent sequence. you can't
have order and also string access at one time without a complex
structure (btree, etc.). strings can't directly index into an array
without converting them to an integer and that is what a hash does
internally. arrays are ALWAYS ordered regardless of how you look at the
data. this is a clear cut definition of hashes and arrays. you keep
looking at the data but the access method or slots are what is important
here. the data is just baggage added to the slot. it could be anything
and nothing but the order/non-order remains the same.
c> And yes, I know that the order of the items in an array do not change
c> because they are tied to the numerical order of the index, while the
c> output order of a hash is nondeterministic.
so keep that view and drop the rest.
c> Further, while my exposure to a variety of programs may be limited,
c> that in and of itself carries no significance other than not
c> knowing a great number of programs. If you spread yourself too
c> thin, you lose the opportunity to gain proficiency with specific
c> tools. Ideally, we would all like to be both wide and deep, but we
c> have to be judicious in the use of our time.
not my point. you really have backwards understanding of the word order.
c> Now, Uri, my question concerned the 'combining' of two hashes. What
c> to you make of the question, and how would you do it?
others have answered it several times. the only thing i would add is
that the ORDER of the hashes on the right side makes a big difference if
there are keys in both hashes. the rightmost one will win out in the
final hash.
here any keys in both left and right will have the value of right's in merged.
%merged = ( %left, %right )
the opposite is true for this.
%merged = ( %right, %left )
and doing listifying of hashes for assignment is much faster than any
looped version. but with a looped version you can do finer grained
control over which hash's values will be used in merged.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 16 Aug 2010 16:33:49 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: combining hashes
Message-Id: <lniq3at9nm.fsf@nuthaus.mib.org>
"Uri Guttman" <uri@StemSystems.com> writes:
[...]
> but keys have no order unless you sort them. if you call keys you get
> them in a pseudo random order. if you then assign more elements, keys
> will likely return them in a DIFFERENT order. hence there is no inherent
> order to the elements of a hash. that is the whole point. in classic c
> langs, to get access to an element keyed by a string your first pass was
> a sequential scan and looking at each key. ordering doesn't help
> there. hashes are designed to allow a faster access to any element
> regardless of the key. in perl that means they are close to arrays in
> speed. in c they are much slower than arrays since you need to do
> several serious calculations and such to find the right element. but
> they are still faster than any other common key based lookup style
> (binary search, trees, etc.)
[...]
Even in C, you can build a string-keyed data structure that
doesn't require examining each key, such as a binary tree or even
a hash table. The difference is that, unlike Perl, C doesn't have
built-in hashes. (And neither did Perl until Larry wrote the code
to implement them -- in C.)
I agree with you about how Perl hashes work. I suspect that
ccc31807 understands the issues, but is using "ordered" in a very
non-standard way. In other words, I suspect that the meaning of
"ordered" is the only issue here.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Mon, 16 Aug 2010 16:41:31 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: combining hashes
Message-Id: <lneidyt9as.fsf@nuthaus.mib.org>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth monkeys paw <monkey@joemoney.net>:
>> I have two hashrefs, i want to combine them into one hash.
>
> perldoc -q merge
Only if you have Perl 5.10.1 or later. For Perl 5.10.0, I get:
No documentation for perl FAQ keyword `merge' found
Here's the output from 5.10.1 (also posted to this newsgroup 3 days ago,
subject "FAQ 4.56 How do I merge two hashes?"):
How do I merge two hashes?
(contributed by brian d foy)
Before you decide to merge two hashes, you have to decide what to do if
both hashes contain keys that are the same and if you want to leave the
original hashes as they were.
If you want to preserve the original hashes, copy one hash (%hash1) to
a new hash (%new_hash), then add the keys from the other hash (%hash2
to the new hash. Checking that the key already exists in %new_hash
gives you a chance to decide what to do with the duplicates:
my %new_hash = %hash1; # make a copy; leave %hash1 alone
foreach my $key2 ( keys %hash2 )
{
if( exists $new_hash{$key2} )
{
warn "Key [$key2] is in both hashes!";
# handle the duplicate (perhaps only warning)
...
next;
}
else
{
$new_hash{$key2} = $hash2{$key2};
}
}
If you don’t want to create a new hash, you can still use this looping
technique; just change the %new_hash to %hash1.
foreach my $key2 ( keys %hash2 )
{
if( exists $hash1{$key2} )
{
warn "Key [$key2] is in both hashes!";
# handle the duplicate (perhaps only warning)
...
next;
}
else
{
$hash1{$key2} = $hash2{$key2};
}
}
If you don’t care that one hash overwrites keys and values from the
other, you could just use a hash slice to add one hash to another. In
this case, values from %hash2 replace values from %hash1 when they have
keys in common:
@hash1{ keys %hash2 } = values %hash2;
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Mon, 16 Aug 2010 19:47:18 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: combining hashes
Message-Id: <8739ue5ddl.fsf@quad.sysarch.com>
>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
KT> "Uri Guttman" <uri@StemSystems.com> writes:
KT> [...]
>> but keys have no order unless you sort them. if you call keys you get
>> them in a pseudo random order. if you then assign more elements, keys
>> will likely return them in a DIFFERENT order. hence there is no inherent
>> order to the elements of a hash. that is the whole point. in classic c
>> langs, to get access to an element keyed by a string your first pass was
>> a sequential scan and looking at each key. ordering doesn't help
>> there. hashes are designed to allow a faster access to any element
>> regardless of the key. in perl that means they are close to arrays in
>> speed. in c they are much slower than arrays since you need to do
>> several serious calculations and such to find the right element. but
>> they are still faster than any other common key based lookup style
>> (binary search, trees, etc.)
KT> [...]
KT> Even in C, you can build a string-keyed data structure that
KT> doesn't require examining each key, such as a binary tree or even
KT> a hash table. The difference is that, unlike Perl, C doesn't have
KT> built-in hashes. (And neither did Perl until Larry wrote the code
KT> to implement them -- in C.)
please don't tell me how to do searching in c. i was doing that in PL/I
before your parents were born! :) i was comparing how close to the metal
c's arrays are vs all string lookups.
KT> I agree with you about how Perl hashes work. I suspect that
KT> ccc31807 understands the issues, but is using "ordered" in a very
KT> non-standard way. In other words, I suspect that the meaning of
KT> "ordered" is the only issue here.
that is what i keep hammering into his anvil of a head! :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 16 Aug 2010 19:55:18 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: combining hashes
Message-Id: <m2sk2et8nt.fsf@sherm.shermpendley.com>
ccc31807 <cartercc@gmail.com> writes:
> Let me recast my statement: the keys of a hash are ordered in the
> sense that
They're not ordered, in any sense. They're indexed, which is not the
same thing.
No offense, but we can't simply make up new meanings for established
terms. Doing so would make communication impossible. Just accept that
the word does not mean what you thought it did, learn the correct defi-
nition, and move on. Mistakes are part of the learning process, and we've
all made them, so there's no sense in being prideful or stubborn about
this one.
sherm--
--
Sherm Pendley
<camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Mon, 16 Aug 2010 15:48:34 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: FAQ 4.18 Does Perl have a Year 2000 or 2038 problem? Is Perl Y2K compliant?
Message-Id: <160820101548344127%jimsgibson@gmail.com>
In article <Exiao.72274$KT3.11744@newsfe13.iad>, PerlFAQ Server
<brian@theperlreview.com> wrote:
> You're still out of luck if you need to keep tracking of decaying
> protons though.
"tracking" -> "track"
------------------------------
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 3079
***************************************
