[29065] in Perl-Users-Digest
Perl-Users Digest, Issue: 309 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Apr 5 16:10:12 2007
Date: Thu, 5 Apr 2007 13:09:17 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 5 Apr 2007 Volume: 11 Number: 309
Today's topics:
Grab a redirected URL infomation, howto? lihao0129@gmail.com
Re: How to turn off "Caps Lock" from Perl script. <hjp-usenet2@hjp.at>
Re: How to turn off "Caps Lock" from Perl script. <uri@stemsystems.com>
Re: perl OOP <hjp-usenet2@hjp.at>
Re: perl OOP <bik.mido@tiscalinet.it>
Re: perl OOP <cwilbur@chromatico.net>
Re: Perl reliability? <greg.ferguson@icrossing.com>
Re: Perl reliability? <greg.ferguson@icrossing.com>
Re: Perl reliability? <greg.ferguson@icrossing.com>
Re: Perl reliability? <mikejohnson@volcanomail.com>
Re: Perl reliability? <mikejohnson@volcanomail.com>
Re: Testing against a list of values ? <bik.mido@tiscalinet.it>
Re: Testing against a list of values ? <uri@stemsystems.com>
Re: Testing against a list of values ? <bik.mido@tiscalinet.it>
Re: Testing against a list of values ? <noreply@gunnar.cc>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 5 Apr 2007 11:45:03 -0700
From: lihao0129@gmail.com
Subject: Grab a redirected URL infomation, howto?
Message-Id: <1175798703.030935.211460@p77g2000hsh.googlegroups.com>
Hi, there:
I have a question about grabbing the URI information of a redirected
weblink. For example, in my Apache configuration file, I added:
ErrorDocument 404 /error.html
then if I enter a wrong URL like:
http://myweb.com/dir/non-exist.html
the httpd server will automatically redirect my request to
http://myweb.com/error.html...
Now I want to display some dynamic information in error.html, for
example, the original request URL:
http://myweb.com/dir/non-exist.html
In HTML::Mason, I tried adding:
$m->request_comp->source_file
# returns /comp/root/error.html
$r->uri()
# returns /error.html
which are not what I wanted..
Are there any functions in mod_perl or HTML::Mason or other APIs that
I can grab '/dir/non-exist.html' from within '/error.html'..
Thank you very much for your input and suggestions..
Best regards,
Hao
------------------------------
Date: Thu, 5 Apr 2007 18:16:58 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: How to turn off "Caps Lock" from Perl script.
Message-Id: <slrnf1a87q.hh1.hjp-usenet2@yoyo.hjp.at>
On 2007-04-04 16:03, Uri Guttman <uri@stemsystems.com> wrote:
> easy way to redfine keys so capslock becomes control like it was
> before ibm ruined the keyboard. know why they did that? capslock was a
> useful key on manual typewriters since you had to really push hard on
> shift to lift up the key carriage. when electric typewriters came out
> they kept that evn though it wasn't hard to push shift anymore
> (especially with the selectric golf ball where keys were all
> electronic). so when ibm created the pc they wanted to keep it just
> like the office typewriter to ease conversions. well, they kept
> capslock but needed a control key so they put that in a lousy place.
Historically that can't be right. The first IBM keyboards did have the
control key where caps lock is now and caps lock in the lower right
corner[1][2]. The caps-lock key only moved to its current position in
1986. IBM may have considered catering to former typewriter users more
important than catering to existing computer users, but they had to make
a conscious decision to *change* the layout - they didn't just keep
the typewriter layout.
(BTW, the story I heard at that time was that IBM had to change it to
conform to existing standards: The layout for typewriters was
standardized and the keyboards of "text processing systems" had to be
the same as for typewriters, so if they wanted to sell their computers
for that purpose they had to supply conforming keyboards).
hp
[1] http://www.pcguide.com/ref/kb/layout/stdXT83-c.html
[2] http://www.pcguide.com/ref/kb/layout/stdAT84-c.html
--
_ | Peter J. Holzer | Blaming Perl for the inability of programmers
|_|_) | Sysadmin WSR | to write clearly is like blaming English for
| | | hjp@hjp.at | the circumlocutions of bureaucrats.
__/ | http://www.hjp.at/ | -- Charlton Wilbur in clpm
------------------------------
Date: Thu, 05 Apr 2007 14:36:48 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How to turn off "Caps Lock" from Perl script.
Message-Id: <x7r6qyacsf.fsf@mail.sysarch.com>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
PJH> Historically that can't be right. The first IBM keyboards did have the
PJH> control key where caps lock is now and caps lock in the lower right
PJH> corner[1][2]. The caps-lock key only moved to its current position in
PJH> 1986. IBM may have considered catering to former typewriter users more
PJH> important than catering to existing computer users, but they had to make
PJH> a conscious decision to *change* the layout - they didn't just keep
PJH> the typewriter layout.
PJH> (BTW, the story I heard at that time was that IBM had to change it to
PJH> conform to existing standards: The layout for typewriters was
PJH> standardized and the keyboards of "text processing systems" had to be
PJH> the same as for typewriters, so if they wanted to sell their computers
PJH> for that purpose they had to supply conforming keyboards).
that may be the correct story but it isn't far from what i tell. the
typewriter market did decide to put the almost never needed anymore
capslock in control's spot. as if anyone would care if it really was put
in the lower right corner. you press it once and later again. it doesn't
need to be an easy spot. control is used so much more in computers but
they kowtowed to the marketers who always know 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: Thu, 5 Apr 2007 17:11:28 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: perl OOP
Message-Id: <slrnf1a4d0.hh1.hjp-usenet2@yoyo.hjp.at>
On 2007-04-05 11:19, Xiong Changnian <please@nospam.net> wrote:
> In article <slrnf19cth.h89.abigail@alexandra.abigail.be>,
> Abigail <abigail@abigail.be> wrote:
>> My correction was for the benefit of everyone who had read your
>> post...
>
> Was it really? Because I'm starting to get the distinct impression that
> a majority of posts to this group are made to trash the egos of other
> posters,
Yes, I got the impression that you got this impression.
Get rid of it. If you view every correction as a personal attack, you
won't get any value out of this group (or any other discussion group I
know of).
> Now I remember why I departed the world of engineering, eventually to
> arrive in education. My students do not expect me to be 100% accurate
> and 100% precise, 100% of the time; indeed, they accept it when I tell
> them that it is both undesirable and impossible to so be.
They probably still expect you to correct them if they are wrong, don't
they? They know they are imperfect and they know they will never achieve
perfection, yet they are there to get closer to perfection. If you as
their teacher don't correct their errors for fear of hurting their
feelings, you aren't doing them a service.
This group is a discussion group, not a classroom. There is no teacher,
and there are no students. Speaking only for myself, I am here learn
something new and share what I already know. I try to be as precise and
truthful as possible, but I know that I will make errors - sometimes
because of lack of knowledge, sometimes because I cannot express myself
in a clear an unambiguous manner. So somebody will (hopefully) correct
me - I don't view that as an attack on my honor, but as help: On the one
heand I learn something new, on the other hand it takes pressure from
me: If I make a mistake its not be a big problem - somebody else will
post the correct answer.
hp
--
_ | Peter J. Holzer | Blaming Perl for the inability of programmers
|_|_) | Sysadmin WSR | to write clearly is like blaming English for
| | | hjp@hjp.at | the circumlocutions of bureaucrats.
__/ | http://www.hjp.at/ | -- Charlton Wilbur in clpm
------------------------------
Date: Thu, 05 Apr 2007 18:47:59 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: perl OOP
Message-Id: <51aa139odef83h1rul2p6rt0ffa7pcf3tb@4ax.com>
On Thu, 5 Apr 2007 17:11:28 +0200, "Peter J. Holzer"
<hjp-usenet2@hjp.at> wrote:
>something new and share what I already know. I try to be as precise and
>truthful as possible, but I know that I will make errors - sometimes
>because of lack of knowledge, sometimes because I cannot express myself
>in a clear an unambiguous manner. So somebody will (hopefully) correct
>me - I don't view that as an attack on my honor, but as help: On the one
Well said!
http://groups.google.it/group/comp.lang.perl.misc/search?q=%22I+stand+corrected%22+author%3Adondi
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: 05 Apr 2007 13:35:38 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: perl OOP
Message-Id: <87ejmyafmd.fsf@mithril.chromatico.net>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
PJH> So somebody will (hopefully) correct me - I don't view that
PJH> as an attack on my honor, but as help: On the one heand I
PJH> learn something new, on the other hand it takes pressure from
PJH> me: If I make a mistake its not be a big problem - somebody
PJH> else will post the correct answer.
Actually, one of the things I like most on Usenet is when I make a
technical post in comp.lang.c and come back a couple hours later to
find no corrections. That crowd values correctness over congeniality.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
Date: 5 Apr 2007 09:02:03 -0700
From: "gf" <greg.ferguson@icrossing.com>
Subject: Re: Perl reliability?
Message-Id: <1175788923.264705.19080@e65g2000hsc.googlegroups.com>
It would help if you showed code. Debugging apps without code is
tough.
Do you have warnings and strict enabled?
Do you have PrintError and RaiseError enabled in the DBI connect()
statement when you create your database handles? If not, are you
testing every call to the DBI to handle errors?
Have you read the "Threads and Thread Safety" section of the DBI docs,
especially the part that says "Using DBI with perl threads is not yet
recommended for production environments. For more information see
http://www.perlmonks.org/index.pl?node_id=288022"?
I built a multi-threaded spider using DBI and LWP that runs a minimum
of 10 LWP sessions, each feeding data to another thread that handles
all the database writes. It's been stable, even when chewing on REALLY
big customer sites analyzing their pages. (I've had a lot more LWP
sessions running than 10, but I don't remember if it was on our
biggest customers or just during testing. Either way it ran without
crashing.)
Because you're seeing intermittent errors I'd suggesting making sure
all your DBI calls have the error status checked afterward to make
sure they succeed, or make sure you've enabled PrintError and
RaiseError. If you go (or have gone) with the last path, then the DBI
will crash out when something happens that it doesn't like. Well...
not really crash... more a controlled cessation of program
execution. :-)
You could try wrapping your DBI calls in eval{} blocks as an
additional attempt to keep the code running but sometimes its better
to just get the inevitable over with quickly so you can get to the
debugging phase with the real error messages intact.
Anyway, that's the sort of stuff I'd check without having access to a
minimum code sample reproducing the problem.
------------------------------
Date: 5 Apr 2007 09:02:54 -0700
From: "gf" <greg.ferguson@icrossing.com>
Subject: Re: Perl reliability?
Message-Id: <1175788973.083546.229610@y80g2000hsf.googlegroups.com>
It would help if you showed code. Debugging apps without code is
tough.
Do you have warnings and strict enabled?
Do you have PrintError and RaiseError enabled in the DBI connect()
statement when you create your database handles? If not, are you
testing every call to the DBI to handle errors?
Have you read the "Threads and Thread Safety" section of the DBI docs,
especially the part that says "Using DBI with perl threads is not yet
recommended for production environments. For more information see
http://www.perlmonks.org/index.pl?node_id=288022"?
I built a multi-threaded spider using DBI and LWP that runs a minimum
of 10 LWP sessions, each feeding data to another thread that handles
all the database writes. It's been stable, even when chewing on REALLY
big customer sites analyzing their pages. (I've had a lot more LWP
sessions running than 10, but I don't remember if it was on our
biggest customers or just during testing. Either way it ran without
crashing.)
Because you're seeing intermittent errors I'd suggesting making sure
all your DBI calls have the error status checked afterward to make
sure they succeed, or make sure you've enabled PrintError and
RaiseError. If you go (or have gone) with the last path, then the DBI
will crash out when something happens that it doesn't like. Well...
not really crash... more a controlled cessation of program
execution. :-)
You could try wrapping your DBI calls in eval{} blocks as an
additional attempt to keep the code running but sometimes its better
to just get the inevitable over with quickly so you can get to the
debugging phase with the real error messages intact.
Anyway, that's the sort of stuff I'd check without having access to a
minimum code sample reproducing the problem.
------------------------------
Date: 5 Apr 2007 09:14:14 -0700
From: "gf" <greg.ferguson@icrossing.com>
Subject: Re: Perl reliability?
Message-Id: <1175789654.109453.275850@d57g2000hsg.googlegroups.com>
On Apr 4, 5:15 pm, "MikeJohnson
> It parses through a log file, builds up a large hash, then writes to a
> SQL Server database using DBI.
This is a pretty common task - something we do here a lot, but I've
never seen a need for threads or even for building a large data
structure to handle the log parsing and insertion.
Are you doing some sort of checks and cross-referencing of the
contents of the log file before insertion? A lot of times I think in
that way, and then later remember (or get "remembered" by our VP who's
a DB whiz) that the database has a lot of built-in functionality that
can replace front-end coding. That reduces the problem to simply
loading, cleaning up data, and inserting it and letting the database
handle uniqueness or collating.
Just something to think about.
------------------------------
Date: 5 Apr 2007 11:47:09 -0700
From: "MikeJohnson" <mikejohnson@volcanomail.com>
Subject: Re: Perl reliability?
Message-Id: <1175798829.862408.75710@e65g2000hsc.googlegroups.com>
My thanks to Jamie and gf for your excellent informative replies.
I plan on removing the threading now.
I saw the ActiveState Graphical Debugger crashing at program-exit time
once I added threading-
not an auspicious sign.
I carefully read the threading provisos in `perldoc threads`,
although not the "Things you need to know before programming Perl
ithreads" info referenced above.
The program uses a very simple threading paradigm- one reader and one
writer.
I do not share DBI handles across threads
(although I do use DBI on separate connections in both threads).
I enable PrintError, but not RaiseError.
I check the result of every DBI call explicitly.
My code to obtain a database connection is below for example.
my $dbh = DBI->connect ($dbi_connectionstring, { PrintError => 1,
RaiseError => 0 });
if (! defined($dbh))
{
my $debug_msg = "Error connecting!\n";
$debug_msg .= "Error was:\n";
$debug_msg .= "$DBI::errstr\n"; # $DBI::errstr is the error
received from the SQL server
&LogErrorMessage ($debug_msg);
return 0;
}
# Note: Disabling AutoCommit here, as opposed to as connection
parameter, seems to work.
$dbh->{AutoCommit} = 0;
# Note: from: http://backpan.cpan.org/authors/id/T/TI/TIMB/DBI_WhatsNewTalk_200607.pdf
$dbh->{ShowErrorStatement} = 1;
I also added a SIG{__WARN__} handler to try to catch and log all
warnings usually sent to stdout.
Thanks again for your replies.
Hopefully the program will run stably once threading is removed.
I considered looking into creating a debug build from Perl source on
Mac OS X or Linux.
This way if the program crashed I would have some symbolic stack trace
info.
I do not know if a debug build with symbol tables is available through
ActiveState.
Thank you,
Mike
------------------------------
Date: 5 Apr 2007 12:11:39 -0700
From: "MikeJohnson" <mikejohnson@volcanomail.com>
Subject: Re: Perl reliability?
Message-Id: <1175800298.982315.45890@d57g2000hsg.googlegroups.com>
FYI here is my code to write records to a database.
I have not had time to add prototypes to functions.
Your comments on my errors are welcomed...
Thanks,
Mike
# Insert all saved rows in database.
# (Hopefully DBD-ODBC will attempt to insert all these records
efficiently).
# NOTE: The record-at-a-time code currently use a hard-coded field
count.
sub WriteRecordsToDatabase
{
my $dbConnection = $_[0];
my $insert_statement_handle = $_[1];
# Third passed parameter is a scalar containing a reference to an
array.
my $ref_array_of_rows = $_[2];
# Fourth parameter is reference to scalar.
my $records_written = $_[3];
my ($debug_msg, $rc);
#
# Sanity-check parameters
#
if ((!$dbConnection) || (!$insert_statement_handle) || (!
$ref_array_of_rows) || (!$records_written))
{
$debug_msg = "WriteRecordsToDatabase: Bad parameter(s)!\n";
&LogErrorMessage ($debug_msg);
return 0;
}
my @tuple_status;
my $next_record_to_write = 0;
my $records_just_written = 0;
eval
{
# Internally calls anonymous subroutine which continually shifts off
an element at a time from
# a dereference of a scalar reference to array.
# $rc = $insert_statement_handle->execute_for_fetch ( sub { shift @
$ref_array_of_rows }, \@tuple_status );
# Internally calls anonymous subroutine which returns an element at
a time from
# a dereference of a scalar reference to array.
$rc = $insert_statement_handle->execute_for_fetch ( sub { return @
$ref_array_of_rows[$next_record_to_write++] }, \@tuple_status );
};
if ($@)
{
# NOTE: Generate more descriptive error message using $tuple_status!
$debug_msg = "WriteRecordsToDatabase: " . $@ . "\n";
&LogErrorMessage ($debug_msg);
return $rc;
}
if (!$rc)
{
$debug_msg = "WriteRecordsToDatabase: bad return code: " .
$DBI::errstr . "\n";
&LogWarningMessage ($debug_msg);
#=================================================================================================
# After sleeping a short random time (to try to let any DB
congestion dissipate,
# re-insert just those records that failed in execute_for_fetch,
individually using execute.
#=================================================================================================
#
# From DBI documentation:
# "If \@tuple_status is passed then the execute_for_fetch method
uses it to return status information.
# The tuple_status array holds one element per tuple.
# If the corresponding execute() did not fail then the element holds
the return value from execute(), which is typically a row count.
# If the execute() did fail then the element holds a reference to an
array containing ($sth->err, $sth->errstr, $sth->state)."
#
# To grab a list of those tuples that failed:
# my @errors = grep { ref $_ } @tuple_status;
#
# To print a sample list of those tuples that failed:
# if (!$rc)
# {
# for my $tuple (0..@last_names-1)
# {
# my $status = $tuple_status[$tuple];
# $status = [0, "Skipped"] unless defined $status;
# next unless ref $status;
# printf "Failed to insert (%s, %s): %s\n", $first_names[$tuple],
$last_names[$tuple], $status->[1];
# }
# }
# Sleep a random period between 0 and 60 seconds, to try to let any
DB congestion dissipate.
sleep (int (rand (60)));
for my $retry_index (0..@$ref_array_of_rows - 1)
{
my $retry_tuple = $tuple_status [$retry_index];
if (ref $retry_tuple)
{
&LogWarningMessage ("WriteRecordsToDatabase: Retrying individual
insert after execute_for_fetch failed with: $retry_tuple->[1]\n");
my $a = @$ref_array_of_rows[$retry_index]->[0];
my $b = @$ref_array_of_rows[$retry_index]->[1];
my $c = @$ref_array_of_rows[$retry_index]->[2];
my $d = @$ref_array_of_rows[$retry_index]->[3];
my $e = @$ref_array_of_rows[$retry_index]->[4];
if (($insert_statement_handle->execute ($a, $b, $c, $d, $e)) != 1)
{
$debug_msg = "WriteRecordsToDatabase: execute failed with: " .
$DBI::errstr . "\n";
&LogErrorMessage ($debug_msg);
return -1;
}
eval
{
$rc = $dbConnection->commit();
};
#
# Note: Can commit fail with a retry-able error on SQL Server?
#
if ($@)
{
$debug_msg = "WriteRecordsToDatabase: execute: commit failed: " .
$@ . "\n";
&LogErrorMessage ($debug_msg);
return $rc;
}
if (!$rc)
{
$debug_msg = "WriteRecordsToDatabase: execute: commit: bad return
code: " . $DBI::errstr . "\n";
&LogErrorMessage ($debug_msg);
return -1;
}
$records_just_written++;
} # tuple failed
else
{
# tuple succeeded- record must've been written.
$records_just_written++;
}
} # for every row in array of rows
} # if execute_for_fetch failed
else
{
$records_just_written = $rc;
eval
{
$rc = $dbConnection->commit();
};
#*******************************************************************************
# Notes:
#
# 1. In the case of SQLite, commit can fail with SQLITE_BUSY.
# If so, consider sleeping then retrying commit.
#
# 2. However, also in the case of SQLite,
# if all access to the local database is controlled by mutex,
# commit is more likely to succeed, because only one process at a
time
# will be reading or writing the database.
#
# 3. Can commit fail with a retry-able error on SQL Server?
#
#*******************************************************************************
if ($@)
{
$debug_msg = "WriteRecordsToDatabase: execute_for_fetch: commit
failed: " . $@ . "\n";
&LogErrorMessage ($debug_msg);
return $rc;
}
if (!$rc)
{
$debug_msg = "WriteRecordsToDatabase: execute_for_fetch: commit:
bad return code: " . $DBI::errstr . "\n";
&LogErrorMessage ($debug_msg);
return -1;
}
}
$$records_written += $records_just_written;
return $records_just_written;
} # WriteRecordsToDatabase
------------------------------
Date: Thu, 05 Apr 2007 17:11:56 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Testing against a list of values ?
Message-Id: <iu3a13paqr8o8omvo9tjufq3e5d0dv1r42@4ax.com>
On Thu, 05 Apr 2007 10:54:28 -0400, Uri Guttman <uri@stemsystems.com>
wrote:
>and that rebuilds the anon hash each time which is not nice if it is
>called more than once. maybe in a cgi or single shot script it would be
>ok.
>
>a simple way to make a hash of keys with undef values is:
>
> my %isa_foo ;
> @isa_foo{ @values } = () ;
Yes, yes, yes. I don't feel a *compelling* need for such a beast as
that I hinted to in the other post. But occasionally I miss it.
Precisely when I *want* to check if if a single value is in a list,
and want to do so *only once*, possibly in one *single statement*.
>i think i have seen tricks (randal?) on how to merge those line and i
>bet abigail or damian could do it with an anon hash. but that is getting
Well, C<do> is always our friend. Still not syntactically sweet enough
for me! ;-)
>to wacky for my taste. whenever i have a list of things to test against,
>i usually need the list as an array too so making an array of foo and a
Well, a situation that springs to mind is this: the other day I wanted
to check if a coderef is lvalue'd but attributes::get() returns a list
of the attributes defined on a ref, so I'm exactly under the
circumstances described above. Basically I may want something short
enough to be used as in
if ( islvalued($ref) ) { ... }
without having to write a separate sub for that.
>hash of isa_foo is best IMO (michele: see, i shifted there!)
Whoa!!
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Thu, 05 Apr 2007 14:34:21 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Testing against a list of values ?
Message-Id: <x7vegaacwi.fsf@mail.sysarch.com>
>>>>> "MD" == Michele Dondi <bik.mido@tiscalinet.it> writes:
MD> On Thu, 05 Apr 2007 10:54:28 -0400, Uri Guttman <uri@stemsystems.com>
MD> wrote:
>> and that rebuilds the anon hash each time which is not nice if it is
>> called more than once. maybe in a cgi or single shot script it would be
>> ok.
>>
>> a simple way to make a hash of keys with undef values is:
>>
>> my %isa_foo ;
>> @isa_foo{ @values } = () ;
MD> Yes, yes, yes. I don't feel a *compelling* need for such a beast as
MD> that I hinted to in the other post. But occasionally I miss it.
MD> Precisely when I *want* to check if if a single value is in a list,
MD> and want to do so *only once*, possibly in one *single statement*.
MD> Well, a situation that springs to mind is this: the other day I wanted
MD> to check if a coderef is lvalue'd but attributes::get() returns a list
MD> of the attributes defined on a ref, so I'm exactly under the
MD> circumstances described above. Basically I may want something short
MD> enough to be used as in
MD> if ( islvalued($ref) ) { ... }
then List::Util::first is your friend. building a temp hash from a list
and then looking it up is at least O(N) (more caps!) as it has to scan
all the keys. first is O(N) but will scan on average only half of the
keys.
if ( first { $_ eq 'lvalue' } attributes::get($ref) ) { ... }
the hash test is almost always better when you check it more than
once. and as i said i use it if i have the list of keys in advance since
saying $isa_foo{$key} is nice and readable.
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: Thu, 05 Apr 2007 21:28:47 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Testing against a list of values ?
Message-Id: <n6ja13hnmg6qkk33eumpan2k9jllm14dbo@4ax.com>
On Thu, 05 Apr 2007 14:34:21 -0400, Uri Guttman <uri@stemsystems.com>
wrote:
> MD> if ( islvalued($ref) ) { ... }
>
>then List::Util::first is your friend. building a temp hash from a list
>and then looking it up is at least O(N) (more caps!) as it has to scan
>all the keys. first is O(N) but will scan on average only half of the
>keys.
I also knew this too. (And incidentally I'm not that concerned about
performance in this case, who would be?) Still stressing the point:
I'm *occasionally* concerned that there's not an immediate idiom to do
this in terms of basic language syntax. Like in: "TMTOWTDI, but all of
them satisfy me at, say, 90%." This won't take my sleep away, anyway.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Thu, 05 Apr 2007 21:42:28 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: Testing against a list of values ?
Message-Id: <57l1t9F2ck675U1@mid.individual.net>
Uri Guttman wrote:
> a simple way to make a hash of keys with undef values is:
>
> my %isa_foo ;
> @isa_foo{ @values } = () ;
>
> i think i have seen tricks (randal?) on how to merge those line
my %isa_foo = map { $_ => undef } @values;
Is that a trick? ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
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 309
**************************************
