[31130] in Perl-Users-Digest
Perl-Users Digest, Issue: 2375 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Apr 29 11:18:10 2009
Date: Wed, 29 Apr 2009 08: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 Wed, 29 Apr 2009 Volume: 11 Number: 2375
Today's topics:
Re: Is there a better way to convert foreign characters <nospam-abuse@ilyaz.org>
Re: Is there a better way to convert foreign characters <hjp-usenet2@hjp.at>
Re: Is there a better way to convert foreign characters <hjp-usenet2@hjp.at>
Re: Is there a better way to convert foreign characters <hjp-usenet2@hjp.at>
Re: Is there a better way to convert foreign characters <hjp-usenet2@hjp.at>
Re: linked list <hjp-usenet2@hjp.at>
Re: linked list <jurgenex@hotmail.com>
Re: linked list <bugbear@trim_papermule.co.uk_trim>
Re: Perl is too slow - A statement <vilain@NOspamcop.net>
Re: Perl is too slow - A statement <bugbear@trim_papermule.co.uk_trim>
Re: Perl is too slow - A statement <rvtol+usenet@xs4all.nl>
Re: pod2ipf in Perl 5.10? <pauldespam@despamsmedley.id.au>
Re: Sub indentation trouble <bozo_le_clown@wherever.you.want.com>
Re: Sub indentation trouble <nospam-abuse@ilyaz.org>
Re: Sub indentation trouble <bozo_le_clown@wherever.you.want.com>
Re: Sub indentation trouble <tadmc@seesig.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 29 Apr 2009 09:25:54 GMT
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngvg792.epq.nospam-abuse@chorin.math.berkeley.edu>
On 2009-04-28, Ben Morrow <ben@morrow.me.uk> wrote:
>> >perl -Mcharnames=latin -wle "print qq(\N{AE})"
>> ?
>> >perl -Mcharnames=latin -wle "print lc qq(\N{AE})"
>> ?
>> I must be missing something...
> Peter is talking about byte strings. \N produces utf8 strings, even if
> it didn't need to.
There is no such thing as "byte strings" or "utf8 strings". Strings
are strings...
However, there are such things as bugs in perl:
perl -Mcharnames=latin -wle "print ord chr ord qq(\N{AE})"
198
perl -Mcharnames=latin -wle "print ord lc chr ord qq(\N{AE})"
198
Just a bug,
Ilya
------------------------------
Date: Wed, 29 Apr 2009 12:01:50 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngvg9ce.e01.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-28 16:12, Tim McDaniel <tmcd@panix.com> wrote:
> In article <slrngvdkm3.hk.hjp-usenet2@hrunkner.hjp.at>,
> Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>>In a single-byte encoding which is a superset of ASCII
>>(e.g. ISO-8859-X) the code works, because lc is a noop on all
>>accented characters.
>
> !?!?! So, even if the local is set to Latin-1, lc('A') produces 'a',
> but lc([A with acute accent]) is [A with acute accent]?!
Gunnar and I were specifically talking about the case where *no* locale
is active.
> What sort of nonsense is that?
The sort of nonsense you when when you don't read postings carefully
enough.
hp
------------------------------
Date: Wed, 29 Apr 2009 12:18:08 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngvgab1.e01.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-28 16:31, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
> Peter J. Holzer wrote:
>> On 2009-04-23 19:38, Gunnar Hjalmarsson <noreply@gunnar.cc> wrote:
>>> Tim McDaniel wrote:
[after calling lc]
>>>> Then there should be no need for the capitalized characters in the
>>>> tr///, because there shouldn't be any to match.
>>>
>>> That's true only if a suitable locale is enabled.
>>
>> Or if the $value is a character string.
>
> Hmm.. Yes, so it seems. I wasn't aware of that.
>
><snip>
>
>> (of course I really think you should use character strings if you do
>> operations on characters, and not muck around with byte strings)
>
> So far, I haven't bothered with encoding/decoding when I have been
> working with Latin-1. Are you saying that encoding/decoding is advisable
> even if you are not dealing with UTF-8 or some other encoding with wide
> characters?
Yes.
* Perl knows that a character string is a character string. So matching
against character classes, lc, uc, etc. works automatically.
* You don't have to care about the encoding within your program.
Only for I/O you have to decode/encode, and that can usually be done
with an I/O-layer. So all the encoding-specific stuff is centralized
in one place: Where the file is opened.
For me the rule of thumb is
* When you read character data from an external source, decode it
immediately. If there is an automatic way to do that (I/O layer,
option for the DBD, etc.) use that.
* When you write character data to an external source, encode it as
late as possible. Again, use an automatic way if there is one.
Then, within my program, I know that all character data is in character
strings and everything "just works" whether the data came from a latin-1
file or a utf-8 file or database in big-5. And all the byte data (e.g.,
blobs, images, etc.) is in byte strings, and that also just works.
hp
------------------------------
Date: Wed, 29 Apr 2009 12:28:46 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngvgauu.e01.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-28 20:53, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2009-04-28, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
>> If $value is a byte string and no locale is in effect, lc on a non-ASCII
>> string is poorly defined.
>
> ??? In absense of `use locale', lc should convert to lower-case using
> Unicode case-conversion tables.
For a byte-string? No, it doesn't, and I think it shouldn't (I know some
people disagree on the latter).
> What is "poorly defined" in this semantic?
You don't know whether an octet is a character. For example, IIRC the
ISO-2022-JP encoding uses octets in the range 0x20-0x7F in multi-byte
encodings. If you apply lc (without locale information) to an
ISO-2022-JP encoded string, it blindly replace all octets 0x41-0x5A with
0x61-0x7A, thereby replacing Japanese characters with completely
unrelated Japanese characters.
>> In a single-byte encoding which is a superset of ASCII (e.g. ISO-8859-X)
>> the code works, because lc is a noop on all accented characters.
>
> What exactly do you mean here?
>
> >perl -Mcharnames=latin -wle "print qq(\N{AE})"
> Æ
> >perl -Mcharnames=latin -wle "print lc qq(\N{AE})"
> æ
bernon:~/tmp 12:27 :-) 117% perl -CO -wle 'print qq(\x{C6})'
Æ
bernon:~/tmp 12:27 :-) 118% perl -CO -wle 'print lc qq(\x{C6})'
Æ
hp
------------------------------
Date: Wed, 29 Apr 2009 12:33:44 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Is there a better way to convert foreign characters?
Message-Id: <slrngvgb88.e01.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-29 09:25, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2009-04-28, Ben Morrow <ben@morrow.me.uk> wrote:
>>> >perl -Mcharnames=latin -wle "print qq(\N{AE})"
>>> ?
>>> >perl -Mcharnames=latin -wle "print lc qq(\N{AE})"
>>> ?
>
>>> I must be missing something...
>
>> Peter is talking about byte strings. \N produces utf8 strings, even if
>> it didn't need to.
>
> There is no such thing as "byte strings" or "utf8 strings".
There is. You may wish that this wasn't the case but that's just wishful
thinking. There *are* differences between byte strings and character
strings. These differences are documented. So they exist in both "perl"
and "Perl".
hp
------------------------------
Date: Wed, 29 Apr 2009 11:57:13 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: linked list
Message-Id: <slrngvg93p.e01.hjp-usenet2@hrunkner.hjp.at>
On 2009-04-29 06:45, alexxx.magni@gmail.com <alexxx.magni@gmail.com> wrote:
> please forgive me if this is a dumb question, but I'm unable to code a
> linked list in perl - to be precise I'm able to create it but I'm
> unable to delete nodes...
>
> the linked list contains 2 coordinates 'x','y' for each node:
>
> my $pixies=undef;
>
> for(1..10)
> { $pixies= [ $pixies, {'x'=>int(3*rand()), 'y'=>int(10*rand())} ] }
>
> my $head=$pixies;
>
> for $i(1..10)
> {
> print("$i\t",$pixies->[1]{'x'},"\t",$pixies->[1]{'y'},"\n");
> $pixies=$pixies->[0];
> }
Here you just walked beyond the tenth (= last) node of your list.
So, $pixies is undef here.
>
> # trying to delete the 8th node:
> for $i(1..7)
> { $pixies=$pixies->[0] }
And here you try to walk 7 more steps.
$pixies stays undef (sometimes autovivification is a bitch - there
should be a way to get a warning in this case).
>
> # now!
> $pixies->[0]=$pixies->[0][0];
So here you don't delete the 8th node, you just create a new array,
assign undef to it's element 0, and ...
>
> print"\n\n\tdeleted 8...\n\n\n";
>
> # check:
> $pixies=$head;
immediately overwrite it.
>
> for $i(1..10)
> {
> print("$i\t",$pixies->[1]{'x'},"\t",$pixies->[1]{'y'},"\n");
> $pixies=$pixies->[0];
> }
>
> and I got the same nodes again!!! What am I doing wrong?
You forgot
$pixies=$head;
before
# trying to delete the 8th node:
(You also forgot "use warnings; use strict;", but in that case it
wouldn't have helped).
> Thanks a lot for any help on this...
>
> P.S.: I read often that linked lists implemented this way are not the
> way to go in perl, that you can do the same things with arrays (arrays
> of hashes, in my case).
> Do you agree?
Yes.
> And in that case, how would you delete a node in the
> middle of the array without too much copying around of large
> structures?
Perl arrays really contain only pointers to the elements. So if you
delete 1 element from the middle of a 1-million-element array, you only
have to move 500000 pointers (about 2 MB on a 32 bit system), not
500000 perl scalars. That's pretty fast, especially if you compare it
to the time needed to walk through 500000 nodes.
There may be some situations where a simple singly-linked list is better
than a perl array, but I am sure they are rare. More complicated data
structures (especially various kinds of trees) are useful more often.
hp
------------------------------
Date: Wed, 29 Apr 2009 06:25:49 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: linked list
Message-Id: <p4lgv4djdlfukld6hbpvd5i16mtchbc8pj@4ax.com>
"alexxx.magni@gmail.com" <alexxx.magni@gmail.com> wrote:
>P.S.: I read often that linked lists implemented this way are not the
>way to go in perl, that you can do the same things with arrays (arrays
>of hashes, in my case).
That's correct. In Perl you typically use references only to create
complex data structures. Simple lists are not complex.
>Do you agree? And in that case, how would you delete a node in the
>middle of the array without too much copying around of large
>structures?
perldoc -f splice
splice(@myarray, 7, 1);
jue
------------------------------
Date: Wed, 29 Apr 2009 15:10:28 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: linked list
Message-Id: <c-SdnWONW7pIwmXUnZ2dnUVZ8sednZ2d@posted.plusnet>
Peter J. Holzer wrote:
> There may be some situations where a simple singly-linked list is better
> than a perl array, but I am sure they are rare. More complicated data
> structures (especially various kinds of trees) are useful more often.
A solution I coded long ago (in 'C') was a doubly-linked list of
N element blocks, accessed via an array style API.
An N of 1000 means that random access is 1000 times faster
than a true linked list, the memory overhead is quite low,
and sequential access (in either order) is as fast a normal array.
Deleting can be done efficiently by either shuffling a block, or splitting a block.
Ditto for insertion.
One might consider a "normalise" pass after a lot of manipulation.
BugBear
------------------------------
Date: Wed, 29 Apr 2009 00:19:56 -0700
From: Michael Vilain <vilain@NOspamcop.net>
Subject: Re: Perl is too slow - A statement
Message-Id: <vilain-2D2557.00195629042009@news.motzarella.org>
In article <87skjst4bd.fsf@quad.sysarch.com>,
Uri Guttman <uri@stemsystems.com> wrote:
> >>>>> "NK" == Nathan Keel <nat.k@gm.ml> writes:
>
> NK> Uri Guttman wrote:
>
> >> it also shows you have no clue about what is important these
> >> days. development time is way more expensive than running time. you
> >> can always get a faster computer but you rarely can speed up a
> >> development schedule.
>
> NK> If you know the language, development time isn't an issue, so comparing
> NK> an experience C programmer (whom will have libraries (their own),
> NK> template scripts, etc. to re-use, unless they are an idiot) and compare
> NK> it to an interpreted language and development time, it's likely not
> NK> going to be a whole lot different. And, the compiled code, if it's
> NK> written well, will easily out perform the interpreted code.
>
> study some computer history and come back when you have finished. have
> you ever worked on a computer which actually accounted for your cpu
> time? you don't understand my point which is well known and
> supported. cpu time used to be the major expense in those days,
> developer time is the major expense now.
>
> NK> I quickly turned down the guy's offer, because he said exactly what you
> NK> did above "If people want the program to run faster, they can get a
> NK> faster computer". That's an awful and often ignorant attitude. Never
> NK> settle for code that's inefficient for the sake of a quick turn around
> NK> time. Perl is my favorite language, but if I care about speed (and I
> NK> mean really care), I'll plan to write it in C. If you are speaking
> NK> from experience and how "in the real world", it's important to consider
> NK> that you won't get jobs if you want to create the best programs, that's
> NK> one thing, but hopefully not many people have to work for shitty
> NK> companies that are that clueless (or people above them that force them
> NK> into that situation due to lack of planning or understanding the
> NK> project). But, to each their own. I just hope I never end up having
> NK> to work for someone like that, and luckily I've always been able to
> NK> tell them to f--- off.
>
> you don't get it. study some history as i said. computer power is dirt
> cheap today. cheaper than you realize. developer cost is way more
> expensive. so buying more/faster computers is usually more economical
> than hiring more and better developers. of course this isn't always
> possible but it is a very strong rule of thumb. and note, i am a speed
> freak coder. most of my cpan modules (id: uri) are about doing things as
> fast as possible. and they usually succeed. :)
>
> for a starter, read the mythical man month.
>
> uri
Uri,
I've been around since the mid-1970's and I wrote some of the accounting
packages for systems that didn't have them to charge for CPU time (the
main frame had it but the VAXes didn't, so I wrote the code to do the
accounting for the company).
As a sysadmin, I know full well any tools I write won't be for
day-to-day production use. I was the only admin that could code in C,
FORTRAN, perl, and sh. God knows where this company hired from, but
they didn't seem to hire programmers. I got all the requests for weird
stuff and updates (we've got this program that doesn't work any
more...can you look at it). My boss told me to ignore such requests.
Yes, companies can just "buy bigger computers" but at some point, that's
a waste. Guess you haven't gotten the memo that companies aren't buying
new systems right now. They want to extend the use of their systems
another couple years. You're don't seem to be bothering enough or care
enough about making something better, which is one of my criteria for
being in programming. It's good know where you stand on the mediocracy
scale. A recent slashdot article on programmers talked about a manager
trying to figure out how to balance out his team. He had a couple
really good code monkeys, about 6 hard working, get-it-done people, and
two wastes of airspace. He wanted to know what to do with those last
two. If he has an opening, maybe you should give him a call.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]
------------------------------
Date: Wed, 29 Apr 2009 09:11:46 +0100
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: Perl is too slow - A statement
Message-Id: <xNOdnSJHsY5flmXUnZ2dnUVZ8j1i4p2d@posted.plusnet>
Uri Guttman wrote:
>>>>>> "b" == bugbear <bugbear@trim_papermule.co.uk_trim> writes:
>
> b> Uri Guttman wrote:
>
> >> it also shows you have no clue about what is important these
> >> days. development time is way more expensive than running time. you can
> >> always get a faster computer but you rarely can speed up a development
> >> schedule.
>
> b> Agreed; further, algorithm developement gives
> b> greater speed up than "cycle counting".
>
> better algorithms is not the same as dev time vs cpu time. in the olden
> days cpu time was expensive and programs were smaller so you had to pay
> for cpu usage and it was monitored carefully. today cpu time is dirt
> cheap so it is rarely accounted but programs are larger and take more
> labor costs to write.
Even a modern CPU can be crippled by a square or cube law algorithm
on large data sets. Pixar has render farms for a reason.
In any case, there's no conflict in our ideas.
What needed is a langauge that supports or encourages more sophisticated alogrithms.
>
> b> Jon Bentley, in a rather old book, shows a quicksort
> b> in Basic on a TRS-80 outrunning a fully optimised
> b> bubble sort on a Cray-1 (*)
>
> that would also depend on the data set size.
Of course.
BugBear
------------------------------
Date: Wed, 29 Apr 2009 11:02:36 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Perl is too slow - A statement
Message-Id: <49f817ac$0$198$e4fe514c@news.xs4all.nl>
Uri Guttman wrote:
> you don't get it. study some history as i said. computer power is dirt
> cheap today. cheaper than you realize. developer cost is way more
> expensive. so buying more/faster computers is usually more economical
> than hiring more and better developers. of course this isn't always
> possible but it is a very strong rule of thumb. and note, i am a speed
> freak coder. most of my cpan modules (id: uri) are about doing things as
> fast as possible. and they usually succeed. :)
>
> for a starter, read the mythical man month.
Uri, please stop wasting your precious developer's time on these types,
because they will never get it.
We could also discuss algorithms that run processes in parallel that
wastefully produce overlapping results which are then merged and deduped
in order to get the final result much much earlier then when we would
let a speed addict touch it. But we can't discuss them if we are too
busy implementing them. :)
--
Ruud
------------------------------
Date: 29 Apr 2009 09:55:19 GMT
From: "Paul Smedley" <pauldespam@despamsmedley.id.au>
Subject: Re: pod2ipf in Perl 5.10?
Message-Id: <POn1Xm9ddZOp-pn2-lG0Z7d9N8ugd@smedley.info>
Hi Shmuel,
On Tue, 28 Apr 2009 12:52:26 UTC, Shmuel (Seymour J.) Metz
<spamtrap@library.lspace.org.invalid> wrote:
> In <POn1Xm9ddZOp-pn2-HGd75dgbvE56@smedley.info>, on 04/26/2009
> at 10:07 PM, "Paul Smedley" <pauldespam@despamsmedley.id.au> said:
>
> >I don't see a 5.10.1
>
> Perl 5.10.1 is a projected bug-fix release that is expected imminently. I
> don't know whether you normally do builds for such.
Yeah I probably will - I do for things like mysql, apache2, etc
> >I don't plan on installing any external packages
>
> But is something documented in perlos2 really an external package for an
> OS/2 release? Do you plan on creating an INF the next time around?
I've never even looked at perlos2 - and have no idea how to create an
INF... so I guess that's a know unless someone wants to help create
it.
I'd like to work out why my perl builds can't be used to build mozilla
- just need to find a few more extra hours in the week - getting
harder and harder the way my day job is going right now....
--
Cheers,
Paul.
------------------------------
Date: Wed, 29 Apr 2009 09:54:18 +0200
From: "Julien K." <bozo_le_clown@wherever.you.want.com>
Subject: Re: Sub indentation trouble
Message-Id: <slrngvg1ta.rqi.bozo_le_clown@thabor.lan.ah2d.fr>
On 27-04-2009, Ilya Zakharevich wrote:
> On 2009-04-27, Julien K. <bozo_le_clown@wherever.you.want.com> wrote:
>>> All changes should be documented in cperl-mode.el.
>>
>> So let me rephrase this point:
>>
>> I didn't find the change(s) that led to the modification in 'sub's
>> indentation within all the changes between cperl versions reported in the
>> beginning of cperl.el.
>
> There should be something liek "Major rework of indentation engine".
Indeed, the cperl-5.0 indents subs with return to top-level, and the next
version available on your site does not.
So which variable should I customize to get the 5.0 behaviour back in
cperl-6.2?
> 1/4 ;-)
???
Cheers,
Julien
------------------------------
Date: Wed, 29 Apr 2009 09:29:39 GMT
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Sub indentation trouble
Message-Id: <slrngvg7g3.epq.nospam-abuse@chorin.math.berkeley.edu>
On 2009-04-29, Julien K. <bozo_le_clown@wherever.you.want.com> wrote:
>> There should be something liek "Major rework of indentation engine".
>
> Indeed, the cperl-5.0 indents subs with return to top-level, and the next
> version available on your site does not.
Sorry, I do not understand this sentence...
> So which variable should I customize to get the 5.0 behaviour back in
> cperl-6.2?
The simplest solution would be to switch to a sane indentation style.
I have no idea what you WANT to see with your examples. And until I
know what is the intent, I can't classify this as a bug.
>> 1/4 ;-)
quarter of a smiley?
Ilya
------------------------------
Date: Wed, 29 Apr 2009 12:00:53 +0200
From: "Julien K." <bozo_le_clown@wherever.you.want.com>
Subject: Re: Sub indentation trouble
Message-Id: <slrngvg9al.rqi.bozo_le_clown@thabor.lan.ah2d.fr>
On 29-04-2009, Ilya Zakharevich wrote:
> On 2009-04-29, Julien K. <bozo_le_clown@wherever.you.want.com> wrote:
>>> There should be something liek "Major rework of indentation engine".
>>
>> Indeed, the cperl-5.0 indents subs with return to top-level, and the next
>> version available on your site does not.
>
> Sorry, I do not understand this sentence...
I grabbed the differents cperl from this location:
<http://math.berkeley.edu/~ilya/software/emacs/>
As you said (and as I thought before my initial post ;-) the indentation
works ok for me up to cperl-5.0.
>> So which variable should I customize to get the 5.0 behaviour back in
>> cperl-6.2?
>
> The simplest solution would be to switch to a sane indentation style.
I use the GNU perl-style with various settings like
cperl-extra-newline-before-brace and cperl-extra-newline-before-brace-multiline
set to true. Isn't it sane enough ? ;-)
> I have no idea what you WANT to see with your examples.
Ok, I'll try to be more precise. I prefer the opening brace to be on a
separate line after the 'sub' statement. The closing brace of the 'sub'
declaration is on the same column that the opening one. So far so good.
But the next line _after_ the closing brace indents to the same column as
the closing brace itself:
<<<<
sub test
{ my ($self) = @_ ;
}
# the commment starts at col 2 instead of col 0
>>>>
The if/else/... blocks don't behave like that:
<<<<
if (test)
{
}
# comment that starts at col 0 -- ok
>>>>>
> And until I know what is the intent, I can't classify this as a bug.
I'm not sure it is a bug, maybe I didn't understand well the settings of
cperl.
I've been using cperl nearly every day for Perl programming for the
past five years, and I find it very useful. Thanks a lot for your work (and
now for your help).
Julien
------------------------------
Date: Wed, 29 Apr 2009 08:01:18 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Sub indentation trouble
Message-Id: <slrngvgjsu.gmp.tadmc@tadmc30.sbcglobal.net>
Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2009-04-29, Julien K. <bozo_le_clown@wherever.you.want.com> wrote:
>>> 1/4 ;-)
>
> quarter of a smiley?
Or 1 bucket used and 4 buckets allocated?
1/1 :-)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
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 2375
***************************************
