[23605] in Perl-Users-Digest
Perl-Users Digest, Issue: 5812 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Nov 16 18:05:45 2003
Date: Sun, 16 Nov 2003 15:05:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 16 Nov 2003 Volume: 10 Number: 5812
Today's topics:
Re: ALRM weirdness in Perl 5.8.0 <admin@asarian-host.net>
Re: ALRM weirdness in Perl 5.8.0 <nospam-abuse@ilyaz.org>
Re: arrange form data in same order as on form <flavell@ph.gla.ac.uk>
Re: Chomp doesn't work for me <pilsl_usenet@goldfisch.at>
Re: Chomp doesn't work for me <mikeflan@earthlink.net>
Re: Chomp doesn't work for me <mikeflan@earthlink.net>
Re: Chomp doesn't work for me <usenet@morrow.me.uk>
Re: Chomp doesn't work for me <invalid-email@rochester.rr.com>
Re: Chomp doesn't work for me <mikeflan@earthlink.net>
Re: dbmopen question <usenet@morrow.me.uk>
Re: dbmopen question <uri@stemsystems.com>
Re: dbmopen question <usenet@morrow.me.uk>
Re: Echo '*' chars instead of what's typed <syscjm@gwu.edu>
grouping hashrefs to trees <perl@my-header.org>
Re: grouping hashrefs to trees <usenet@morrow.me.uk>
Re: Help <tore@aursand.no>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 16 Nov 2003 17:22:47 +0100
From: "Mark" <admin@asarian-host.net>
Subject: Re: ALRM weirdness in Perl 5.8.0
Message-Id: <qKidnSfATprGOSqiRVn-sQ@giganews.com>
"Ilya Zakharevich" <nospam-abuse@ilyaz.org> wrote in message
news:bp6hl5$nti$1@agate.berkeley.edu...
> <usenet@morrow.me.uk>], who wrote in article
<bp4m5j$43q$1@wisteria.csv.warwick.ac.uk>:
> > > I guess I will need something entirely different then to break out
> > > of the eval {} within a thread. Any ideas? :)
> >
> > You want another thread that sleeps for a while and then kills the
first.
>
> Do not forget to find which signal is generated when thread is killed,
> and install a handler for this like this:
>
> $SIG{TERM} = sub {die "thread killed"};
>
> Then (on most systems?) the thread termination sequence will run.
Terminating an entire thread is one thing; breaking out of an eval {} with a
local SIG handler, within a running thread, is quite another. And, reading
people correctly here, it seems the latter is not possible; at least not
with a regular signal. I have more or less resigned to that fact. For now, I
have done something ugly. I wrote a small connecter utility, in C, that I
shell out to, in order to do the virus-test. Along the lines of spamc/spamd.
I know, it is not a pretty solution. But one that works until something
better comes along.
As a sidenote, I have been thinking that maybe ALRM should never use 'safe
signals'. Because ALRM is typically used to break precisely out of an area
where 'safe signals' are no longer honored. Put in Windoze (eew) terms: to
break free of programs that "stopped responding". In my case, the AVP daemon
that hangs. Sticking to the example, the AVP daemon always honors 'safe
signals', *except when it hangs. And especially when it "stopped
responding", the need to have an ALRM catch the timeout is most required.
What you would need, schematically, is a new command, like "endscopetimer",
which means something like: "break out of current innermost lexical scope
after x seconds". Something based on a per-thread timer, and not on a
regular SIG handler. I will not hold my breath waiting for its arrival,
though. :) But should such a command ever appear, I would be among the first
to hail its advent.
- Mark
------------------------------
Date: Sun, 16 Nov 2003 18:47:35 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: ALRM weirdness in Perl 5.8.0
Message-Id: <bp8go7$195h$1@agate.berkeley.edu>
[A complimentary Cc of this posting was sent to
Mark
<admin@asarian-host.net>], who wrote in article <qKidnSfATprGOSqiRVn-sQ@giganews.com>:
> > > You want another thread that sleeps for a while and then kills the
> first.
> >
> > Do not forget to find which signal is generated when thread is killed,
> > and install a handler for this like this:
> >
> > $SIG{TERM} = sub {die "thread killed"};
> >
> > Then (on most systems?) the thread termination sequence will run.
>
> Terminating an entire thread is one thing; breaking out of an eval {} with a
> local SIG handler, within a running thread, is quite another.
In my example I meant that this is not going to be catched by eval {}.
Sorry for not having made it explicit. And let me repeat: I'm not
sure that Perl is smart enough to terminate the thread immediately
when uncaught die() is seen in "a secondary" thread: I'm not sure that
a longjmp() out of the signal handler for terminate-thread signal is
portable enough.
> And, reading people correctly here, it seems the latter is not
> possible; at least not with a regular signal.
At least it is not possible on most implementations of threads (here I
mean system-call stuff implementation, not Perl implementation).
> What you would need, schematically, is a new command, like "endscopetimer",
> which means something like: "break out of current innermost lexical scope
> after x seconds". Something based on a per-thread timer
Not possible with most implementations.
Hope this helps,
Ilya
------------------------------
Date: Sun, 16 Nov 2003 20:57:47 +0000
From: "Alan J. Flavell" <flavell@ph.gla.ac.uk>
Subject: Re: arrange form data in same order as on form
Message-Id: <Pine.LNX.4.53.0311162043340.21124@ppepc56.ph.gla.ac.uk>
On Sat, 15 Nov 2003, Gunnar Hjalmarsson wrote:
> Alan J. Flavell wrote:
> > Then it's probably indefensible to run it from the traditional CGI
> > in the first place:
>
> Some may claim it is. (For some reason that comment wasn't unexpected.
> ;-) )
Well, it isn't just me, is it? If you already know what answers
you're going to get, why do you raise the question, without addressing
the points that you know are going to be made?
It wasn't me who challenged you to produce the benchmarks, but it
could just as well have been. The first, second, and third rules of
optimisation are "don't optimise yet", you know.
> > you should be looking to run it from mod_perl or other persistent
> > environment, where the overhead of loading CGI.pm is no longer of
> > any relevance since it's not being done per-invocation any more.
>
> I have already done that, so the program is prepared to be (and is
> actually in a few cases) run under mod_perl. However, there are
> hundreds or 1,000+ users, and most of them don't have access to
> mod_perl...
Then it would seem that general robustness and resilience are of more
importance to you (and your users) than saving those last few cycles
of CPU. Furthermore, when a new version of CGI.pm came out, with some
new browser weakness to workaround, or some new obscure security
loophole discovered, they could get the benefits in short order,
instead of waiting for you to diagnose and fix the implications for
homespun code.
(Of course, you could develop a dual-mode version, that takes
advantage of mod_perl when available, and works as a regular CGI when
it isn't. I gather than CGI.pm makes it rather easy to do that...)
> > "sensible"? - I'd have to reserve judgment until I saw the full
> > implications, including the security review and some sensible
> > assessment of the implications for long-term maintainability.
>
> Even if I provided a link in my reply to Randal, I ask you to please
> not do that, Alan, at least not yet...
>
> I started to write that program more than three years ago, and at that
> time my programming experience basically consisted of having modified
> a couple of Matt's Scripts. :)
That's OK, we all have to start somewhere. But if I was still coding
the same Perl4-style scripts that I started Perl with in around 1994
or so, then I'd need my head examined.
And given your commendable honesty about your existing code, I really
am rather surprised that you maintain that your choice of homespun
code must be the right one for your particular situation. In the end,
you *might* sometimes turn out to be right, but I'd want to see that
proved by more than just energetic handwaving, if you'll excuse me.
all the best
------------------------------
Date: Sun, 16 Nov 2003 13:33:15 +0100
From: peter pilsl <pilsl_usenet@goldfisch.at>
Subject: Re: Chomp doesn't work for me
Message-Id: <3fb76f9f$1@e-post.inode.at>
Mike Flannigan wrote:
>
> 1) I could not chomp the new line off the end of the
> 2nd column ($_->[1]) no matter what I did. I tried
> about 8 different things and they either turned the
> string into a "1", a"0", or nothing at all. What's the proper
> (simple) way to do it?
>
Additionally to the comments of the others covering the usage/syntax of
chomp :
Did you check if your setting of $/ corresponds to the convention file you
are using as input ?
If processing some files from other OS (i.e. win-files on linux) you might
need to modify $/ or use other ways to get rid of the newlines.
You are aware that different systems/application might use different bytes
as newline. The most common are \n and \r.
I often run into problems like this and often end up doing something like
chomp;
s/\r$//;
best,
peter
--
peter pilsl
pilsl_usenet@goldfisch.at
http://www.goldfisch.at
------------------------------
Date: Sun, 16 Nov 2003 15:04:16 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Chomp doesn't work for me
Message-Id: <3FB792AA.354CBA42@earthlink.net>
"Eric J. Roode" wrote:
> These are not errors. These are warnings. Warning you that you are
> using an undef value at some point. Line 27, to be exact.
Hey, I finally got rid of all of them by removing the blank
line at the front of DATA, and the new line at the end
of it.
Never did get the chomp or substr to work, but will
eventually.
Mike
------------------------------
Date: Sun, 16 Nov 2003 15:31:19 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Chomp doesn't work for me
Message-Id: <3FB79901.74E46F53@earthlink.net>
peter pilsl wrote:
> Additionally to the comments of the others covering the usage/syntax of
> chomp :
>
> Did you check if your setting of $/ corresponds to the convention file you
> are using as input ?
> If processing some files from other OS (i.e. win-files on linux) you might
> need to modify $/ or use other ways to get rid of the newlines.
> You are aware that different systems/application might use different bytes
> as newline. The most common are \n and \r.
Well, I thought about that. But all I did was print "$/", which
printed a blank line. Didn't tell me much, but I think this is
not the problem anyway, though it could be. I also don't
know how to really check is correctly for /r /n or whatever.
> I often run into problems like this and often end up doing something like
>
> chomp;
> s/\r$//;
>
Bingo. This worked:
$_->[1] =~ s/\n$//;
Just force it yourself, I guess, if efficiency isn't at a
premium.
I appreciate your help.
_____________________
use strict;
use warnings;
my %nam;
my $nam;
my $namt = "";
my $lc;
my @data=<DATA>;
#chomp @data;
@data = map [ split /!/, $_, 2 ], @data;
#my @data = map [ split /!/, $_, 2 ], <DATA>;
foreach (@data) {
$_->[1] =~ s/\n$//;
if (($_->[0] eq "#") and ($_->[1] eq "#")) {
# if (((substr $_->[0],1) eq "#") and ((substr $_->[1],1) eq "#")) {
$nam{$namt}++;
# $loc{$loct}++;
$namt = "";
next;
}
else {
$namt .= "$_->[0] $_->[1]";
}
}
for (keys %nam) {
print "$_\t$nam{$_}\n";
}
__DATA__
New!#
Friendship!"T.42-R.4,"
Bap.!S.36 Fran.
#!#
Swieder Cem.!Crawford
#!#
#!#
Swieder Cem.!Crawford
#!#
Swieder Cem.!Crawford
#!#
Swieder Cem.!Crawford
#!#
Swieder Cem.!Crawford
#!#
#!#
#!#
Swieder Cem.!Crawford
#!#
#!#
Swieder Cem.!Crawford
#!#
Swieder Cem.!Crawford
#!#
Lick Creek!"T.39-R.4,"
Cem.!S.34 Craw.
#!#
Cherryville!#
Bap. Cem.!Cherryville*
#!#
Cherryville!#
Bap. Cem.!Cherryville*
#!#
New!"T.42-R.4,"
Friendship!S.36 Fran.
Bap.!#
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
Jewell!"Jewell,"
#!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
Jewell!"Jewell,"
#!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
Jewell!"Jewell,"
#!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
#!"Jewell,"
Jewell!"Hamilton, IA"
#!#
New!#
Friendship!"T.42-R.4,"
Bap.!S.36 Fran.
#!#
------------------------------
Date: Sun, 16 Nov 2003 16:08:41 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Chomp doesn't work for me
Message-Id: <bp87e9$f84$1@wisteria.csv.warwick.ac.uk>
Mike Flannigan <mikeflan@earthlink.net> wrote:
> Well, I thought about that. But all I did was print "$/", which
> printed a blank line.
Heh. Surprising, that :).
$, = " "; $\ = "\n";
print ord($/), ord("\r"), ord("\n");
> I also don't know how to really check is correctly for /r /n or
> whatever.
\r, \n.
> Bingo. This worked:
> $_->[1] =~ s/\n$//;
You may want to go for robustness, and use s[\015$|\015?\012$][] which
removes most line endings on most systems (EBCDIC excepted, as usual).
> use strict;
> use warnings;
>
> my %nam;
> my $nam;
> my $namt = "";
> my $lc;
>
> my @data=<DATA>;
> #chomp @data;
> @data = map [ split /!/, $_, 2 ], @data;
Or:
my $EOL = qr[\015$|\015?\012$];
my @data = map { s/$EOL//; [ split /!/, $_, 2 ] } <DATA>;
Ben
--
"The Earth is degenerating these days. Bribery and corruption abound.
Children no longer mind their parents, every man wants to write a book,
and it is evident that the end of the world is fast approaching."
-Assyrian stone tablet, c.2800 BC ben@morrow.me.uk
------------------------------
Date: Sun, 16 Nov 2003 19:11:48 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: Chomp doesn't work for me
Message-Id: <3FB7CBB8.9020409@rochester.rr.com>
Mike Flannigan wrote:
> "Eric J. Roode" wrote:
>
>
>>These are not errors. These are warnings. Warning you that you are
>>using an undef value at some point. Line 27, to be exact.
>>
>
> Hey, I finally got rid of all of them by removing the blank
> line at the front of DATA, and the new line at the end
> of it.
>
> Never did get the chomp or substr to work, but will
> eventually.
>
Mike, have you been using the Perl debugger? If not, check it out -- it
is a *huge* help for all those instances when you're not sure why
something is going wrong. Invoke it as:
perl -d programname.pl
and look in:
perldoc perldebug
for documentation and a bit of a starter on how to use it. The "x"
command is most helpful for peeking at the values of things.
You will probably find that the "undef" values that are giving you
warnings are due to the use of split() on strings which don't contain
something the matches split()'s pattern -- in your case, data lines
which are somehow missing a tab character. The debugger will help you
notice stuff like that.
Regarding chomp(): Is there any chance you are reading a file with line
endings for a different OS? Like a text file written on Windoze being
read on Unix? What chomp() actually does is remove trailing instances
of that string stored in variable $/ (but you knew that since you read
perldoc -f chomp). So a Windoze file read on Unix may still have
trailing \013 characters after chomp() is applied, for example.
Regarding attachments on usenet (a previous topic in this thread): have
you read the posting guidelines for this newsgroup, where is says:
"Don't attach anything to the message." ?
What should you do? It also says:
"put them [attachments] in a publically accessible place (like a Web
server) and provide a pointer to that location."
> Mike
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Sun, 16 Nov 2003 22:14:53 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Chomp doesn't work for me
Message-Id: <3FB7F798.2E727E65@earthlink.net>
Bob Walton wrote:
> Mike, have you been using the Perl debugger? If not, check it out -- it
> is a *huge* help for all those instances when you're not sure why
> something is going wrong. Invoke it as:
>
> perl -d programname.pl
>
> and look in:
>
> perldoc perldebug
>
> for documentation and a bit of a starter on how to use it. The "x"
> command is most helpful for peeking at the values of things.
>
> You will probably find that the "undef" values that are giving you
> warnings are due to the use of split() on strings which don't contain
> something the matches split()'s pattern -- in your case, data lines
> which are somehow missing a tab character. The debugger will help you
> notice stuff like that.
Thanks. I'll try that.
I don't know why, but that thing has scared me all
along. I've never tried it, but for some reason I'm
kinda scared of it. Must be a repressed memory
from the old computer languages :-)
> Regarding chomp(): Is there any chance you are reading a file with line
> endings for a different OS? Like a text file written on Windoze being
> read on Unix? What chomp() actually does is remove trailing instances
> of that string stored in variable $/ (but you knew that since you read
> perldoc -f chomp). So a Windoze file read on Unix may still have
> trailing \013 characters after chomp() is applied, for example.
>
I don't think so. It was created from MS Excel and
everything done on Windoze.
> Regarding attachments on usenet (a previous topic in this thread): have
> you read the posting guidelines for this newsgroup, where is says:
>
> "Don't attach anything to the message." ?
>
> What should you do? It also says:
>
> "put them [attachments] in a publically accessible place (like a Web
> server) and provide a pointer to that location."
>
And expose my web site to all you hackers :-)
I'm just kidding. I will do that.
------------------------------
Date: Sun, 16 Nov 2003 08:07:06 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: dbmopen question
Message-Id: <bp7b7a$604$1@wisteria.csv.warwick.ac.uk>
Default@User011011101101.net wrote:
> Just wondering if anyone can help me figure out what this dbmopen
> option is all about.
>
> dbmopen(my %WORDS, $dbfile,0666) # There see that number?
>
> What is that? No better yet where in perldoc can i find information
on this?
perldoc -f dbmopen
and for an explanation of what the number means, perldoc -f umask.
<snip>
> #!
> use strict;
> use warnings;
> print "\n" . ' ' . '='x78 . "\n Creates a database of words and how " .
> "often each word has been seen.\n " . '='x78 . "\n\n";
> our $files = lc(shift) || help() && die "\n";
Why our()? my would be better.
If you're not going to die with a message, use exit.
> my $opt1 = lc(shift);
> my $opt2 = lc(shift);
> my $opt3 = lc(shift);
> my $opt4 = lc(shift);
> my $opt5 = lc(shift);
> my $opt6 = lc(shift);
my %opts;
$_ = 1 for @opts{map {lc} @ARGV};
then you can test for individual options with 'if ($opts{"-?"})'
&c. Or alternatively, use one of the Getopt modules from CPAN.
<snip>
> die "\n".'Quitting: "'."$new_db".'" was not created'."\n"
Don't put "\n" on the end of warn and die messages: it causes Perl to
omit valuable information about where the error occurred.
Ben
--
If you put all the prophets, | You'd have so much more reason
Mystics and saints | Than ever was born
In one room together, | Out of all of the conflicts of time.
ben@morrow.me.uk |----------------+---------------| The Levellers, 'Believers'
------------------------------
Date: Sun, 16 Nov 2003 08:10:53 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: dbmopen question
Message-Id: <x7d6bsn376.fsf@mail.sysarch.com>
>>>>> "BM" == Ben Morrow <usenet@morrow.me.uk> writes:
BM> my %opts;
BM> $_ = 1 for @opts{map {lc} @ARGV};
if you are going to do some map/slice stuff at least do it in a clear
style:
my %opts = map { lc => 1 } @ARGV ;
but as you said using some getopts module is best.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sun, 16 Nov 2003 08:43:10 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: dbmopen question
Message-Id: <bp7dau$6e0$1@wisteria.csv.warwick.ac.uk>
Uri Guttman <uri@stemsystems.com> wrote:
> >>>>> "BM" == Ben Morrow <usenet@morrow.me.uk> writes:
>
> BM> my %opts;
> BM> $_ = 1 for @opts{map {lc} @ARGV};
>
> if you are going to do some map/slice stuff at least do it in a clear
> style:
>
> my %opts = map { lc => 1 } @ARGV ;
Ach, yes, I always forget that a map can return more or fewer elements
than its input.
Ben
--
perl -e'print map {/.(.)/s} sort unpack "a2"x26, pack "N"x13,
qw/1632265075 1651865445 1685354798 1696626283 1752131169 1769237618
1801808488 1830841936 1886550130 1914728293 1936225377 1969451372
2047502190/' # ben@morrow.me.uk
------------------------------
Date: Sun, 16 Nov 2003 17:29:06 -0500
From: Chris Mattern <syscjm@gwu.edu>
Subject: Re: Echo '*' chars instead of what's typed
Message-Id: <3FB7FA32.8070205@gwu.edu>
Ben Morrow wrote:
> Andrew DeFaria <Andrew@DeFaria.com> wrote:
>
>>-=-=-=-=-=-
>>[Alternative: text/html]
>>-=-=-=-=-=-
>
>
> DON'T do that.
>
>
>>Tad McClellan wrote:
>>
>>>If you have a properly installed perl, then you already have it.
>>
>>The perl is the perl that was installed when I installed Mandrake 9.1.
>>
>>
>>>Looks like wherever it got installed is not in your path...
>>
>>Looks like perldoc isn't installed:
>
> <snip rpmage>
>
> Then you will need to ask a Mandrake group/list how to install it. A
> proper install of perl will always include perldoc: I would have
> thought it would have been in perl-{,base-,devel-}5.8.0-17mdk, but it
> seems Mandrake in their infinite wisdom have put it somewhere else.
>
Personally, I would regard that as broken, and bitch at Mandrake about
it.
Chris Mattern
------------------------------
Date: Sun, 16 Nov 2003 16:38:44 +0100
From: Matija Papec <perl@my-header.org>
Subject: grouping hashrefs to trees
Message-Id: <4v5frvknfe9206kgmaq348aovp3tb071uf@4ax.com>
I need to group hashrefs into branches where every instance in branch has
something in common with others. The problem is that no one can tell which
attribute will be dominant, so I guess there should be some counting before
actual grouping into branches. Please tell me that somebody already has
invented the wheel. :)
my @rules = (
{
'source-port' => 23,
protocol => "tcp",
},
{
source => '6.11.6.6/24',
},
{
protocol => 'udp', 'source-port' => 53,
source => '64.11.6.6',
},
{
protocol => 'udp', 'source-port' => 53,
source => '164.11.6.6',
},
{
protocol => 'udp', 'source-port' => 53,
source => '164.11.6.7',
},
{
protocol => 'udp', 'source-port' => 53,
source => '164.11.6.8',
},
);
--
Matija
------------------------------
Date: Sun, 16 Nov 2003 16:38:34 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: grouping hashrefs to trees
Message-Id: <bp896a$g36$1@wisteria.csv.warwick.ac.uk>
Matija Papec <perl@my-header.org> wrote:
> I need to group hashrefs into branches where every instance in branch has
> something in common with others. The problem is that no one can tell which
> attribute will be dominant, so I guess there should be some counting before
> actual grouping into branches. Please tell me that somebody already has
> invented the wheel. :)
You may find Data::Favorites helpful.
Ben
--
For the last month, a large number of PSNs in the Arpa[Inter-]net have been
reporting symptoms of congestion ... These reports have been accompanied by an
increasing number of user complaints ... As of June,... the Arpanet contained
47 nodes and 63 links. [ftp://rtfm.mit.edu/pub/arpaprob.txt] * ben@morrow.me.uk
------------------------------
Date: Sun, 16 Nov 2003 21:01:42 +0100
From: Tore Aursand <tore@aursand.no>
Subject: Re: Help
Message-Id: <pan.2003.11.15.16.13.34.605918@aursand.no>
On Sat, 15 Nov 2003 15:51:58 +0000, Ben Morrow wrote:
>> No browsers - that I'm aware of - supports execution of Perl scripts.
>> I might be wrong, though.
> If you install PerlScript which comes with AS perl then IE will... ;)
But, uh, ehm, who uses IE these days? *panicking*
:-)
--
Tore Aursand <tore@aursand.no>
------------------------------
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.
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 V10 Issue 5812
***************************************
