[30327] in Perl-Users-Digest
Perl-Users Digest, Issue: 1570 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 23 03:09:43 2008
Date: Fri, 23 May 2008 00:09:08 -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 Fri, 23 May 2008 Volume: 11 Number: 1570
Today's topics:
Re: maintaining order in a hash (without Tie::IxHash) <mjcarman@mchsi.com>
Re: maintaining order in a hash (without Tie::IxHash) <jurgenex@hotmail.com>
Re: maintaining order in a hash (without Tie::IxHash) <uri@stemsystems.com>
Re: maintaining order in a hash (without Tie::IxHash) <jurgenex@hotmail.com>
Re: maintaining order in a hash (without Tie::IxHash) <simon.chao@gmail.com>
Re: maintaining order in a hash (without Tie::IxHash) <szrRE@szromanMO.comVE>
new CPAN modules on Fri May 23 2008 (Randal Schwartz)
Re: Order of operations <mjcarman@mchsi.com>
Re: Out of memory! Yet ... <alexxx.magni@gmail.com>
Re: Perl 6 <@..invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 23 May 2008 01:44:34 GMT
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <6kpZj.121548$TT4.51452@attbi_s22>
Jim Gibson wrote:
>
> Tie is one of those things that I avoid because I don't fully
> understand it
The only thing you need to know about tie() to use Tie:: modules is that
tied variables behaves exactly like a normal variables but have some
extra functionality provided by the class. In the case of Tie::IxHash
that functionality is that keys(), values() and each() return data in
insertion order instead of hash order.
Obviously you need to know more if you want to write your own tie
classes. I suggest doing so. It's probably not a tool that you'll use
often (at least I don't) but when it's extremely useful when you do.
> I suspect it may cause problems.
What is this, superstition? What kind of problems? Tied variables are
definitely slower than non-tied ones -- that's the price of the power --
but the performance penalty isn't significant in most cases. Other
problems are possible, but it's always possible to have bugs in code.
There's nothing special about tie() in that regard.
-mjc
------------------------------
Date: Fri, 23 May 2008 02:33:14 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <9j9c34trn912vn4qq22int6kq9redjrbnt@4ax.com>
nolo contendere <simon.chao@fmr.com> wrote:
[snipping many good points]
>Also, I don't really see the contradiction of the terms 'sorted' and
>'hash'. Just because you associate a key with a value, why can't you
>want those pairs ordered?
True, but I can just as well want to order some other complex data type,
be it employee records or customer orders or US presidents by age when
inaugurated. Or even just primitive data like a set of numbers. To get
any of those into a specific order I put them into a datastructure that
has a first and a next element and conveniently maybe last, previous,
n-th, etc.
If I want a ordered sequence of pairs then an AoA would be the right
data structure, just like maybe a AoH would be the right datastructure
for employee data and the customer orders where each hash represents one
employee record or order.
Hashes don't have those operations. There is no natural 'first' or
'next' element of a hash. Which one would that be? The one that was
added first? The one with the smallest alphanumerical key? The one with
the shortest key? The one with the smallest numerical value? There is
simply no meaningful definition of 'first element of a hash'.
Taking literally sorting a hash is about as meaningful as sorting the
the lenth() function. Which one is the next element after
length('Hello')? The question itself does not make sense. Just the same
way there is no way to say what is the next element after
$myhash{'Hello'}. In contrast the next element after $myarr[5] is
obviously $myarr[6].
Therefore if you want to create some ordering of hash elements it must
be done using an additional datastructue, be it explicit (like your
suggestion with the explicit sortval) or implicit (like Tie::IxHash). In
either case you are creating an additional datastructure on top of the
hash to support that ordering. And therefore it is not a simple hash any
longer.
And that in turn is why I keep saying sorting and hash is a
contradiction. It is conceptually impossible without an additional data
structure that supports 'first' and 'next'.
jue
------------------------------
Date: Fri, 23 May 2008 02:39:09 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <x7k5hloib6.fsf@mail.sysarch.com>
>>>>> "nc" == nolo contendere <simon.chao@gmail.com> writes:
>> Looking at it in context, Uri said:
>>
>> sure you can do it but don't expect it to
>> be a pure hash anymore. caveat coder.
>>
>> There is no insult. None. Zero. Zilch. Nil.http://en.wiktionary.org/wiki/s%C4%B1f%C4%B1r.
nc> Ahh, I do think you're right. I interpreted 'caveat' as an adjective
nc> (with a pejorative undertone), when I think Uri may have meant it as
nc> an imperative verb. Apologies for being overly sensitive, Uri.
you never heard the phrase caveat emptor (buyer beware)? i just made a
variation i have seen before. like sinan said it just means if you do
make an ordered hash, you must beware of the possible issues. nothing
insulting was meant nor said.
and this thread has been perfectly normal. real perl issues discussed
calmly and in some detail. you haven't done anything wrong other than
keeping on the idea that sorted hashes are a good thing. :)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training --- http://perlhunter.com/college.html ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Fri, 23 May 2008 02:39:53 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <ogbc34hbni5ddpn1o5tkkp1t5k7dca2blv@4ax.com>
nolo contendere <simon.chao@fmr.com> wrote:
>On May 22, 5:06 pm, Uri Guttman <u...@stemsystems.com> wrote:
>> caveat coder.
>
>Caveat Coder? Is that an insult?
Why would a warning "coder beware" be an insult?
jue
------------------------------
Date: Thu, 22 May 2008 19:51:17 -0700 (PDT)
From: nolo contendere <simon.chao@gmail.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <a2ef8a66-4713-4cde-a4b4-a0f4be6c283b@e39g2000hsf.googlegroups.com>
On May 22, 10:39=A0pm, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> nolo contendere <simon.c...@fmr.com> wrote:
> >On May 22, 5:06=A0pm, Uri Guttman <u...@stemsystems.com> wrote:
> >> =A0caveat coder.
>
> >Caveat Coder? Is that an insult?
>
> Why would a warning "coder beware" be an insult?
It isn't. My initial (erroneous) interpretation was that Uri was
calling me a "Caveat Coder"--a term I had never heard before, but took
to mean that I made up excuses for employing bad coding practices and
called them good coding practices. I misinterpreted the context.
Dealing with Perl, the irony is not lost on me. :-\. Fortunately,
everyone seems to be good-natured and forgiving about my faux pas (me
making an ass out of myself).
------------------------------
Date: Thu, 22 May 2008 22:33:23 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <g15kv302g2f@news4.newsguy.com>
nolo contendere wrote:
> On May 22, 7:05 pm, "szr" <sz...@szromanMO.comVE> wrote:
>> s...@netherlands.co wrote:
>>> On Thu, 22 May 2008 10:20:17 -0700 (PDT), nolo contendere
>>> <simon.c...@fmr.com> wrote:
>> [...]
>>>> Is there something wrong with my reasoning? Would this solution be
>>>> a good candidate for addition into the FAQ How can I make my hash
>>>> remember the order I put elements
>>>> into it?
>>
>>> Why is it so important to have a hash sorted?
>>> What would a hash be necessary for then?
>>
>>> Wouldn't an array be better in that case?
>>
>> You don't sort the hash. You sort an array containing fields/keys
>> from the hash:
>>
>> my @fields = sort { ... } keys %hash;
>> ...
>> foreach my $field (@fields) {
>> my $item = $hash{$field}
>> ...
>> }
>>
>
> you could just do:
>
> for my $key ( sort keys %hash ) {
> # do something with $hash{$key}
> }
>
> ...but i was talking about maintaining the insertion order, not
> sorting by alpha or number
Ah. Well you could still use the @fields array. Just push each key you
insert but that isn't too intuitive. I believe this is why Tie::IxHash
was invented :-)
--
szr
------------------------------
Date: Fri, 23 May 2008 04:42:19 GMT
From: merlyn@stonehenge.com (Randal Schwartz)
Subject: new CPAN modules on Fri May 23 2008
Message-Id: <K1B12J.4xz@zorch.sf-bay.org>
The following modules have recently been added to or updated in the
Comprehensive Perl Archive Network (CPAN). You can install them using the
instructions in the 'perlmodinstall' page included with your Perl
distribution.
Atompub-0.3.1
http://search.cpan.org/~takeru/Atompub-0.3.1/
Atom Publishing Protocol implementation
----
Cache-FastMmap-1.26
http://search.cpan.org/~robm/Cache-FastMmap-1.26/
Uses an mmap'ed file to act as a shared memory interprocess cache
----
Chooser-1.1.6
http://search.cpan.org/~vvelox/Chooser-1.1.6/
A system for choosing a value for something. Takes a string composed of various tests, arguements, and etc and returns a value based on it.
----
Class-Delegator-0.09
http://search.cpan.org/~dwheeler/Class-Delegator-0.09/
Simple and fast object-oriented delegation
----
Class-Meta-Express-0.11
http://search.cpan.org/~dwheeler/Class-Meta-Express-0.11/
Concise, expressive creation of Class::Meta classes
----
DBIx-Class-VirtualColumns-1.01
http://search.cpan.org/~maros/DBIx-Class-VirtualColumns-1.01/
Add virtual columns to DBIx::Class schemata
----
Deliantra-Client-0.9972
http://search.cpan.org/~mlehmann/Deliantra-Client-0.9972/
----
Devel-Autoflush-0.01
http://search.cpan.org/~dagolden/Devel-Autoflush-0.01/
Set autoflush from the command line
----
Devel-PerlySense-0.0155
http://search.cpan.org/~johanl/Devel-PerlySense-0.0155/
Perl IDE backend with Emacs frontend
----
Error-0.17013
http://search.cpan.org/~shlomif/Error-0.17013/
Error/exception handling in an OO-ish way
----
Exception-Class-DBI-1.00
http://search.cpan.org/~dwheeler/Exception-Class-DBI-1.00/
DBI Exception objects
----
Games-RolePlay-MapGen-1.2.18
http://search.cpan.org/~jettero/Games-RolePlay-MapGen-1.2.18/
The base object for generating dungeons and maps
----
Graph-Easy-0.63
http://search.cpan.org/~tels/Graph-Easy-0.63/
Convert or render graphs (as ASCII, HTML, SVG or via Graphviz)
----
Graph-Easy-As_svg-0.23
http://search.cpan.org/~tels/Graph-Easy-As_svg-0.23/
Output a Graph::Easy as Scalable Vector Graphics (SVG)
----
Graph-Easy-Manual-0.41
http://search.cpan.org/~tels/Graph-Easy-Manual-0.41/
HTML manual for Graph::Easy
----
HTML-CTPP2-2.3.0
http://search.cpan.org/~stellar/HTML-CTPP2-2.3.0/
Perl interface for CTPP2 library
----
HTML-TurboForm-0.08
http://search.cpan.org/~camelcase/HTML-TurboForm-0.08/
----
IPC-SRLock-0.1.48
http://search.cpan.org/~pjfl/IPC-SRLock-0.1.48/
Set/reset locking semantics to single thread processes
----
Language-Lisp-ECLs-0.21
http://search.cpan.org/~vkon/Language-Lisp-ECLs-0.21/
Perl extension for ECL lisp
----
List-Enumerator-0.02
http://search.cpan.org/~satoh/List-Enumerator-0.02/
list construct library
----
Locale-Country-Multilingual-0.04
http://search.cpan.org/~fayland/Locale-Country-Multilingual-0.04/
ISO codes for country identification with multi-language (ISO 3166)
----
Locale-Country-Multilingual-0.05
http://search.cpan.org/~fayland/Locale-Country-Multilingual-0.05/
ISO codes for country identification with multi-language (ISO 3166)
----
Math-Random-MT-Perl-1.02
http://search.cpan.org/~jfreeman/Math-Random-MT-Perl-1.02/
Pure Perl Pseudorandom Number Generator
----
Net-BitTorrent-0.020
http://search.cpan.org/~sanko/Net-BitTorrent-0.020/
BitTorrent peer-to-peer protocol class
----
Net-DNS-GuessTZ-0.001
http://search.cpan.org/~rjbs/Net-DNS-GuessTZ-0.001/
guess the time zone of a host
----
Net-DNS-GuessTZ-0.002
http://search.cpan.org/~rjbs/Net-DNS-GuessTZ-0.002/
guess the time zone of a host
----
Net-SFTP-Foreign-1.37_06
http://search.cpan.org/~salva/Net-SFTP-Foreign-1.37_06/
Secure File Transfer Protocol client
----
ORLite-0.03
http://search.cpan.org/~adamk/ORLite-0.03/
Extremely light weight SQLite-specific ORM
----
PAR-0.980
http://search.cpan.org/~smueller/PAR-0.980/
Perl Archive Toolkit
----
POE-Component-Client-NSCA-0.12
http://search.cpan.org/~bingos/POE-Component-Client-NSCA-0.12/
a POE Component that implements send_nsca functionality
----
POSIX-Regex-0.90.6
http://search.cpan.org/~jettero/POSIX-Regex-0.90.6/
OO interface for the gnu regex engine
----
PerlIO-Util-0.15
http://search.cpan.org/~gfuji/PerlIO-Util-0.15/
A selection of general PerlIO utilities
----
Pg-Pcurse-0.16
http://search.cpan.org/~ioannis/Pg-Pcurse-0.16/
Monitors a Postgres cluster
----
Pod-HtmlEasy-1.0100
http://search.cpan.org/~gleach/Pod-HtmlEasy-1.0100/
Generate personalized HTML from PODs.
----
ProgressMonitor-0.27
http://search.cpan.org/~knth/ProgressMonitor-0.27/
a flexible and configurable framework for providing feedback on how a long-running task is proceeding.
----
Prompt-Timeout-1.00
http://search.cpan.org/~stro/Prompt-Timeout-1.00/
prompt() with auto-selecting default value in case of inactivity
----
Prompt-Timeout-1.01
http://search.cpan.org/~stro/Prompt-Timeout-1.01/
prompt() with auto-selecting default value in case of inactivity
----
Search-Tools-0.17
http://search.cpan.org/~karman/Search-Tools-0.17/
tools for building search applications
----
Sub-Contract-0.05
http://search.cpan.org/~erwan/Sub-Contract-0.05/
Pragmatic contract programming for Perl
----
Test-MinimumVersion-0.008
http://search.cpan.org/~rjbs/Test-MinimumVersion-0.008/
does your code require newer perl than you think?
----
Text-Wrap-Smart-XS-0.05
http://search.cpan.org/~schubiger/Text-Wrap-Smart-XS-0.05/
Wrap text fast into chunks of (mostly) equal length
----
WWW-DomainTools-0.11
http://search.cpan.org/~dbartle/WWW-DomainTools-0.11/
DomainTools.com XML API interface
----
Win32API-Registry-0.30
http://search.cpan.org/~blm/Win32API-Registry-0.30/
Low-level access to Win32 system API calls from WINREG.H
----
Zucchini-0.0.6
http://search.cpan.org/~chisel/Zucchini-0.0.6/
turn templates into static websites
If you're an author of one of these modules, please submit a detailed
announcement to comp.lang.perl.announce, and we'll pass it along.
This message was generated by a Perl program described in my Linux
Magazine column, which can be found on-line (along with more than
200 other freely available past column articles) at
http://www.stonehenge.com/merlyn/LinuxMag/col82.html
print "Just another Perl hacker," # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Fri, 23 May 2008 01:16:30 GMT
From: Michael Carman <mjcarman@mchsi.com>
Subject: Re: Order of operations
Message-Id: <OVoZj.175653$yE1.20971@attbi_s21>
Ben Morrow wrote:
> Yes, I understand the concept in general. I meant a specific example of
> when *perl* reorders operations like that, since I don't believe it ever
> does.
I was afraid of that. ;) I don't know enough about the internals to know
whether or not it does. I suppose the order could change between
versions of Perl, although that doesn't seem likely as it could break
existing code.
-mjc
------------------------------
Date: Fri, 23 May 2008 00:03:30 -0700 (PDT)
From: "alexxx.magni@gmail.com" <alexxx.magni@gmail.com>
Subject: Re: Out of memory! Yet ...
Message-Id: <ac3a2250-4dd2-4dea-8318-d6ddba67f3b8@i76g2000hsf.googlegroups.com>
thank you for your answer!
On 22 Mag, 18:25, s...@netherlands.co wrote:
> On Wed, 21 May 2008 23:32:52 -0700 (PDT), "alexxx.ma...@gmail.com" <alexxx.ma...@gmail.com> wrote:
> >On 21 Mag, 18:11, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
> >> "alexxx.ma...@gmail.com" <alexxx.ma...@gmail.com> wrote innews:e84cae72-e396-40a6-beec-4bad5aa3d615@d77g2000hsb.googlegroups.com:
>
> --<snip>--
>
> >> > The memory-eating line is this:
> >> > for $i(1..$n)
> >> > {
> >> > for $y(1..$ny)
> >> > { for $x(1..$nx) { $AAA[$i][$x][$y]=$a[3+$nx*($y-1)+$x] } }
> >> > print("\n$i>\ttotal size: ",total_size($AAA));
> >> > }
>
> --<sip>--
>
> >> How large is the image? You are basically holding two copies of the
> >> image in memory. Plus, you have the overhead of a multilevel data
> >> structure.
>
> >> Even if you did not run out of memory, this smells. Without knowing any
> >> details, it is hard to say definitely that what you are doing is wrong,
> >> but I would have constructed the AoAoA in $AAA step by step while
> >> reading the data.
>
> --<snip>--
> >> Sinan
> >> --
> >> A. Sinan Unur <1...@llenroc.ude.invalid>
> >> (remove .invalid and reverse each component for email address)
>
> >> comp.lang.perl.misc guidelines on the WWW:http://www.rehabitation.com/clpmisc/
>
> >sorry if I didnt put all the info in - I didnt want to burden the
> >newsgroup too much: my script is large (and of course I used
> --<snip>--
>
> >2) concerning the huge overhead, I cannot avoid it - I need all the
> >images (indexed by $i) in parallel in $AAA[$i][$x][$y], since I have
> >to process each pixel ($x,$y) along $i=1..$n ($n can vary, right now I
> >have ~ 100 images). The alternative would be to continuously open the
> >~100 images and read each time a different pixel: choosing whether to
> >stress the disk or the RAM I choose the latter, but maybe it's too
> >much.
>
> >thanks everybody
>
> > Alessandro
>
> "..since I have"
> ">to process each pixel ($x,$y) along $i=1..$n "
>
> Although a little confused, I thought this was interresting.
>
> You made some statements along with including this code:
>
> for $i(1..$n)
> {
> for $y(1..$ny)
> {
> for $x(1..$nx)
> {
> $AAA[$i][$x][$y]=$a[3+$nx*($y-1)+$x]
> }
>
> }
>
> You said you are reading 100 gray scale images into @a,
> flat file. Since the indices of $AAA never touch the same
> element twice as an lvalue and since $AAA is never referenced
> as an rvalue. This merely rearranges the values of @a into @AAA.
> I am not sure this is a filter or even a conversion of say color to gray.
well, as I said before, I didnt want to post a script too large to the
group, so maybe I've been misunderstood: the images are read in
sequence in @a, so that @a is overwritten each time - no memory waste
there: it will just occupy between 2 and 15MB as you said. $AAA
instead will hold all of them, and I'm unable to avoid this.
A little background: the images are a temporal sequence of
magnetooptical images representing the switching of magnetization, say
from black to white, along time. This meas.tech. is very noisy. The
camera aquire in grayscale, so a given pixel is, say, black along
time, with its value fluctuating below 128, sometimes even going above
(noise), then at some time $t0 we can say it switched above, and start
fluctuating above 128.
We first attempted to make use of morphological operators (open/
close, erode/dilate, tophat) or make convolutions with different
matrices, as these operations are in general able to reduce the noise
by using the spatial information around each pixel. As a matter of
fact, these operations can be problematic, especially in reducing the
number of small avalanches (blocks of pixels switching together). The
general point is that by analyzing each image in isolation, we lose
the useful information provided by the time sequence.
Indeed, a simple but effective starting point is to ignore the spatial
information and consider only the evolution in time for each pixel. A
significant jump in the measured intensity at that pixel represents
the switching time $t0 for the magnetization at that point.
So, having collected all the time sequence in $AAA[][][], I analyze
each pixel ($x,$y) along time $t; I smooth its grayscale values along
time, then differentiate to find the largest jump, thus finding the
"switching time" $t0 for ($x,$y).
At the end, I have a "switching time" matrix @SW[$x][$y] whose values
represent the switching times $t0 at each point. Finally, I use @SW to
reconstruct the filtered images, writing each pixel ($x,$y) in the
image at time $t0 in black if $SW[$x][$y]<$t0, in white otherwise.
Sorry if I didnt explain it before.
>
> Lets do a little bitmap math.
>
> Assume memory conservation:
> 1600 x 1200 pixels x 1 byte/8-bit(plane's) gray scale = 1.9 MB
> 100 gray scale images x 1.9 MB/image = 190 MB
> Using 2 buffers = 380 MB
>
> Assume memory waste:
> 1600 x 1200 pixels x 8 byte/8-bit(plane's) gray scale = 15.36 MB
> 100 gray scale images x 15.36 MB/image = 1.536 GB
> Using 2 buffers = 3.072 GB
>
I didnt understand well: memory conservation vs, waste, how can I be
sure in perl that I use in my matrices 1 byte per pixel? I believed
that perl automatically choose by itself, and it was impossible to
force "byte ($x,$y,$z)" in C-style.
Thanks again!
Alessandro
> You state that you are operating on each pixel "($x,$y) along $i=1..$n ".
> If this is true, this would mean you are using 1 byte per pixel for a
> data buffer.
>
> Its very easy to work with data using bitmasks/bit-wise operators.
>
> For example; $this &= ~($bit << $position);
>
> So if you want to do a few simple bit manipulations, you could add a
> few hundred more images without running out of memory.
>
> Explain what you are doing in greater depth, then you could get some
> help here.
------------------------------
Date: Thu, 22 May 2008 22:59:31 -0700
From: "Gordon Etly" <@..invalid>
Subject: Re: Perl 6
Message-Id: <69n4q5F33foniU1@mid.individual.net>
Sherman Pendley wrote:
> Gordon Etly wrote:
> > Sherman Pendley wrote:
> > > This grudge of yours, and the constant bitching and moaning
> > How interesting. My commenting has as always been in response to
> > someone else, when I see something I really don't like.
> Precisely - you only comment when you don't like something.
No, not *only*, but it's anyone's right to do so. If you don't like it,
don't post.
> > There are times with people from your crowd actively refer back
> > to subjects that were supposedly "closed" already.
> Because I believe that subject to be the root cause of your
> unhappiness with this group.
Far from it. It was more like the straw that broke the camel's back (pun
not really intended.)
> You started your life here with a simple question based on
> a misunderstanding of how TROFF formats man pages - the name
> of the language is capitalized at top of "man perl" because
No, it had nothing to do with the formatting of man pages. That was not
the point I was making, and thus you obviously you missed it entirely.
> > > Or keep whining - I don't care, your latest sock puppet is joining
> > > all your others in my killfile. *plonk*
> > "Gordon Etly", my name, is the only name I've ever used
> I'm talking about your ever-changing email address,
Email addresses are a variable field. They can always change. The name
part is what is usually constant, and that's what matters (that's what
you see when you look at the list of posts in a news group), and my
"ever changing email address" was just a visual aid to demonstrate that
point.
I have never changed my name, so you know who I am - my name *identifies
me*, just as "Sherman Pendley" identifies you. Sure, a name isn't
necessarily a *unique* identifier, but neither is the email address part
(it's possible for multiple people to share one email address, and email
address can change at any given time.)
> Please - if you hate this group so much
Stop trying to put words in my mouth. I never said I hated this news
group. What I dislike is how a certain set of people sometimes conduct
themselves, and refuse to understand that if they do not wish to be
commented upon, then they shouldn't post.
> Or, at least stop being a hypocrite, telling people to killfile you
> and then changing
> your address just to escape those killfiles and get in everyone's
> face again.
There you go again. I never said that. I said that someone wanted to
killfile me, they could do it by my name, because that is constant.
Email addresses are not constant. One can always change it, so
killfiling based on an email address field is inherently unreliable.
--
G.Etly
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 1570
***************************************
