[30325] in Perl-Users-Digest
Perl-Users Digest, Issue: 1568 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu May 22 16:09:48 2008
Date: Thu, 22 May 2008 13:09:15 -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, 22 May 2008 Volume: 11 Number: 1568
Today's topics:
Re: creating directory before a module is loaded. <hsggwk@gmail.com>
Re: creating directory before a module is loaded. <pue@gmx.net>
Re: creating directory before a module is loaded. <glex_no-spam@qwest-spam-no.invalid>
Re: creating directory before a module is loaded. <hsggwk@gmail.com>
Re: maintaining order in a hash (without Tie::IxHash) <uri@stemsystems.com>
Re: maintaining order in a hash (without Tie::IxHash) <simon.chao@fmr.com>
Re: maintaining order in a hash (without Tie::IxHash) <1usa@llenroc.ude.invalid>
Re: maintaining order in a hash (without Tie::IxHash) <jimsgibson@gmail.com>
Re: maintaining order in a hash (without Tie::IxHash) <uri@stemsystems.com>
Re: maintaining order in a hash (without Tie::IxHash) <simon.chao@fmr.com>
Re: maintaining order in a hash (without Tie::IxHash) <simon.chao@fmr.com>
Re: maintaining order in a hash (without Tie::IxHash) <simon.chao@fmr.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@fmr.com>
using m//g to parse multi-line records without an outsi <astankevich@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 May 2008 12:19:50 -0700 (PDT)
From: gsa <hsggwk@gmail.com>
Subject: Re: creating directory before a module is loaded.
Message-Id: <dcb893d2-5c2b-4c9a-a2dd-bbfdb08e8057@d19g2000prm.googlegroups.com>
Should the BEGIN block be the very first thing in the file? I did try
using a BEGIN block and it still did not work.
On May 22, 11:39 am, Slickuser <slick.us...@gmail.com> wrote:
> BEGIN
> {
> #Create directory here
> #mkdir
>
> }
>
> On May 22, 10:33 am, gsa <hsg...@gmail.com> wrote:
>
> > I am a beginner and have a stupid question. I have this code
> > mainCode.cgi that uses the module example.pm. example.pm in turn uses
> > the CPAN module Inline.pm. Inline needs a directory to build stuff and
> > this directory needs to be present before Inline is loaded. How do I
> > tell mainCode.cgi to create a directory before it loads example.pm? I
> > do not want to write a wrapper that will create the directory and then
> > call mainCode.cgi. What is the best way to do this? Hope I am being
> > clear and thanks a lot for all your help.
>
> > -G
Should
------------------------------
Date: Thu, 22 May 2008 21:33:01 +0200
From: =?ISO-8859-1?Q?Andreas_P=FCrzer?= <pue@gmx.net>
Subject: Re: creating directory before a module is loaded.
Message-Id: <69lvq0F345594U1@mid.individual.net>
gsa schrieb:
> I am a beginner and have a stupid question. I have this code
> mainCode.cgi that uses the module example.pm. example.pm in turn uses
> the CPAN module Inline.pm. Inline needs a directory to build stuff and
> this directory needs to be present before Inline is loaded.
No, it doesn't.
Excerpt from 'perldoc Inline' (Section: The Inline DIRECTORY):
If Inline cannot find the directory in any of these places it will
create a '_Inline/' directory in either your current directory or the
directory where your script resides.
How do I
> tell mainCode.cgi to create a directory before it loads example.pm? I
> do not want to write a wrapper that will create the directory and then
> call mainCode.cgi. What is the best way to do this?
IMHO the best way would be to create a directory that will be used for
all Invocations of mainCode.cgi and hardcode it in example.pm:
use Inline ( C => Config => DIRECTORY =>
'/path/to/dir/you/created/yourself/');
> -G
Greetings,
Andreas Pürzer
--
Have Fun,
and if you can't have fun,
have someone else's fun.
The Beautiful South
------------------------------
Date: Thu, 22 May 2008 14:36:00 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: creating directory before a module is loaded.
Message-Id: <4835cb21$0$87065$815e3792@news.qwest.net>
gsa wrote:
> Should the BEGIN block be the very first thing in the file?
Typically it is, but it doesn't have to be at the beginning.
When in doubt, consult the documentation or at least test it
on your own by writing a short script to see if it makes
a difference.
perldoc perlmod
Look for BEGIN
>I did try using a BEGIN block and it still did not work.
'did not work' is not at all helpful to anyone. Show your
code.
------------------------------
Date: Thu, 22 May 2008 13:03:59 -0700 (PDT)
From: gsa <hsggwk@gmail.com>
Subject: Re: creating directory before a module is loaded.
Message-Id: <b24289a1-d18b-4522-947c-752b8afdf7db@j33g2000pri.googlegroups.com>
Hi all,
Thanks for your responses. Here is part of my test code.
testInline.pl
---------------
#!/usr/bin/perl -
w
use strict;
use lib './libPvalueCalculation';
use pvalueCalculation;
BEGIN {
my $return= `mkdir /tmp/RAP/test`;
print "return: $return\n";
}
pvalueCalculation.pm
---------------------
#!/usr/bin/perl -
w
use strict;
use Inline (C => Config =>
DIRECTORY => '/tmp/RAP/test',
UNTAINT => '0',
);
If I remove the use pvalueCalculation.pm line from testInline.pm, the
directory is created, no problems. But the moment I use the module, it
throws up the following message and the directory does not get
created.
Invalid value '/tmp/RAP/test' for config option DIRECTORY
at libPvalueCalculation/pvalueCalculation.pm line 20
BEGIN failed--compilation aborted at libPvalueCalculation/
pvalueCalculation.pm line 583.
Compilation failed in require at testInline.pl line 4.
BEGIN failed--compilation aborted at testInline.pl line 4.
So I think the module pvalueCaculation gets loaded before the begin
block executes? This code sits in the cgi-bin so I cannot let it
create a directory in the same place. I have to use /tmp which we
clean up pretty often. So essentially, this directory needs to be
created by the script. Hope this makes sense. Thanks a lot.
------------------------------
Date: Thu, 22 May 2008 18:24:58 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <x74p8qw611.fsf@mail.sysarch.com>
>>>>> "nc" == nolo contendere <simon.chao@fmr.com> writes:
nc> On May 22, 1:35 pm, Uri Guttman <u...@stemsystems.com> wrote:
>> >>>>> "nc" == nolo contendere <simon.c...@fmr.com> writes:
>>
>> nc> then if you need to access the hash in the order in which items were
>> nc> inserted, you could simply:
>>
>> nc> for my $key ( sort { $hash{$a}{sortval} <=> $hash{$b}{sortval} } keys
>> nc> %hash ) {
>> nc> # do something
>> nc> }
>>
>> and how do you set the sortval for each key? how do you know the order
>> of insertion without a counter (internal to this hash or external)? also
>> do you realize that construction means the top level keys are really
>> hash refs and not the original key? and where is the value for each key?
nc> Below is an example, used in conjunction with File::Find
an example of what??
nc> #!/usr/bin/perl
nc> use strict; use warnings;
nc> use Data::Dumper;
nc> use File::Basename;
nc> use Getopt::Long;
nc> use File::Find;
nc> my ( $tree1, $tree2 ) = ( '', '' );
useless initialization.
nc> GetOptions( "tree1=s" => \$tree1,
nc> "tree2=s" => \$tree2 ) or die $USAGE;
nc> my ( %src, %tgt, $ctr1, $ctr2, %diffs );
nc> find( \&get_src_info, $tree1 );
nc> find( \&get_tgt_info, $tree2 );
nc> for my $key ( sort { $src{$a}{sortval} <=> $src{$b}{sortval} } keys
nc> %src ) {
now that i see this is a dirtree compare (btw, unix diff -r can do this
for you), i still don't see the need to keep find order. the order of
entries in directories is not stable as it depends on the file system,
any deletions and inserts and how file::find reads the dirs. you have a
single level hash of each tree so where would insert order matter?
nc> sub get_src_info {
nc> my ( $mode, $uid, $gid, $size, $mtime ) =
nc> (stat( $File::Find::name ))[2,4,5,7,9];
nc> $src{$File::Find::name} = {
nc> mode => $mode,
nc> uid => $uid,
nc> gid => $gid,
nc> size => $size,
nc> mtime => $mtime,
nc> sortval => ++$ctr1,
gack, a global counter used by a callback!
this isn't even usable as a module. you hardwired it to be a standalone
script. so how would posting this complex code be a useful FAQ answer?
>> well, if your answer covered all of those questions (and possibly more
>> as i haven't delved into this much) and showed working code, maybe. but
>> pointing to a working module is better and easier for almost all FAQ
>> answers. the excuse of not wanting/able to install modules is usually
>> bogus as there are many ways to install modules on almost any platform.
nc> There are certainly ways of installing modules on machines by
nc> circumventing the "process", but this can be risky, and it can be very
nc> difficult to propagate the modules to prod machines.
installing your own code is not any easier/harder than installing pure
perl modules on production machines. you can even cut/paste the module
code into your scripts if that is the only way. as i said, there are
almost no good excuses for not using a module.
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: Thu, 22 May 2008 11:35:09 -0700 (PDT)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <c488ee9d-a5e5-4fd7-8728-fbd3dad1726a@2g2000hsn.googlegroups.com>
On May 22, 2:24=A0pm, Uri Guttman <u...@stemsystems.com> wrote:
> >>>>> "nc" =3D=3D nolo contendere <simon.c...@fmr.com> writes:
>
> =A0 nc> On May 22, 1:35=A0pm, Uri Guttman <u...@stemsystems.com> wrote:
> =A0 >> >>>>> "nc" =3D=3D nolo contendere <simon.c...@fmr.com> writes:
> =A0 >>
> =A0 >> =A0 nc> then if you need to access the hash in the order in which i=
tems were
> =A0 >> =A0 nc> inserted, you could simply:
> =A0 >>
> =A0 >> =A0 nc> for my $key ( sort { $hash{$a}{sortval} <=3D> $hash{$b}{sor=
tval} } keys
> =A0 >> =A0 nc> %hash ) {
> =A0 >> =A0 nc> =A0 =A0 # do something
> =A0 >> =A0 nc> }
> =A0 >>
> =A0 >> and how do you set the sortval for each key? how do you know the or=
der
> =A0 >> of insertion without a counter (internal to this hash or external)?=
also
> =A0 >> do you realize that construction means the top level keys are reall=
y
> =A0 >> hash refs and not the original key? and where is the value for each=
key?
>
> =A0 nc> Below is an example, used in conjunction with File::Find
>
> an example of what??
>
An example of my initial proposal of a substitute for Tie::IxHash that
maintains the insertion order of elements into a hash.
> =A0 nc> #!/usr/bin/perl
>
> =A0 nc> use strict; use warnings;
> =A0 nc> use Data::Dumper;
> =A0 nc> use File::Basename;
> =A0 nc> use Getopt::Long;
> =A0 nc> use File::Find;
>
> =A0 nc> my ( $tree1, $tree2 ) =3D ( '', '' );
>
> useless initialization.
>
yeah, if i called the script with no options, i got the uninitialized
value warning.
> =A0 nc> GetOptions( "tree1=3Ds" =3D> \$tree1,
> =A0 nc> =A0 =A0 =A0 =A0 =A0 =A0 "tree2=3Ds" =3D> \$tree2 ) or die $USAGE;
>
> =A0 nc> my ( %src, %tgt, $ctr1, $ctr2, %diffs );
>
> =A0 nc> find( \&get_src_info, $tree1 );
> =A0 nc> find( \&get_tgt_info, $tree2 );
>
> =A0 nc> for my $key ( sort { $src{$a}{sortval} <=3D> $src{$b}{sortval} } k=
eys
> =A0 nc> %src ) {
>
> now that i see this is a dirtree compare (btw, unix diff -r can do this
> for you), i still don't see the need to keep find order. the order of
> entries in directories is not stable as it depends on the file system,
> any deletions and inserts and how file::find reads the dirs. you have a
> single level hash of each tree so where would insert order matter?
>
diff -r looks great! wasn't aware of that one...
Well, the need isn't there. But this was just supposed to illustrate
how i set the sortval value, as you asked earlier in the thread.
> =A0 nc> sub get_src_info {
>
> =A0 nc> =A0 =A0 my ( $mode, $uid, $gid, $size, $mtime ) =3D
> =A0 nc> (stat( $File::Find::name ))[2,4,5,7,9];
> =A0 nc> =A0 =A0 $src{$File::Find::name} =3D {
> =A0 nc> =A0 =A0 =A0 =A0 mode =A0 =A0=3D> $mode,
> =A0 nc> =A0 =A0 =A0 =A0 uid =A0 =A0 =3D> $uid,
> =A0 nc> =A0 =A0 =A0 =A0 gid =A0 =A0 =3D> $gid,
> =A0 nc> =A0 =A0 =A0 =A0 size =A0 =A0=3D> $size,
> =A0 nc> =A0 =A0 =A0 =A0 mtime =A0 =3D> $mtime,
> =A0 nc> =A0 =A0 =A0 =A0 sortval =3D> ++$ctr1,
>
> gack, a global counter used by a callback!
>
should i have used a closure instead?
> this isn't even usable as a module. you hardwired it to be a standalone
> script. so how would posting this complex code be a useful FAQ answer?
>
my code wasn't meant to be a submission for review, but rather a
conceptual demonstration.
> =A0 >> well, if your answer covered all of those questions (and possibly m=
ore
> =A0 >> as i haven't delved into this much) and showed working code, maybe.=
but
> =A0 >> pointing to a working module is better and easier for almost all FA=
Q
> =A0 >> answers. the excuse of not wanting/able to install modules is usual=
ly
> =A0 >> bogus as there are many ways to install modules on almost any platf=
orm.
>
> =A0 nc> There are certainly ways of installing modules on machines by
> =A0 nc> circumventing the "process", but this can be risky, and it can be =
very
> =A0 nc> difficult to propagate the modules to prod machines.
>
> installing your own code is not any easier/harder than installing pure
> perl modules on production machines. you can even cut/paste the module
> code into your scripts if that is the only way. as i said, there are
> almost no good excuses for not using a module.
>
cut/paste module code into my scripts? that doesn't seem like an
elegant solution, and what about pre-reqs?
------------------------------
Date: Thu, 22 May 2008 19:03:15 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <Xns9AA69920DA12Easu1cornelledu@127.0.0.1>
nolo contendere <simon.chao@fmr.com> wrote in
news:c488ee9d-a5e5-4fd7-8728-fbd3dad1726a@2g2000hsn.googlegroups.com:
> On May 22, 2:24 pm, Uri Guttman <u...@stemsystems.com> wrote:
>> installing your own code is not any easier/harder than installing
>> pure perl modules on production machines. you can even cut/paste the
>> module code into your scripts if that is the only way. as i said,
>> there are almost no good excuses for not using a module.
>>
>
> cut/paste module code into my scripts? that doesn't seem like an
> elegant solution, and what about pre-reqs?
It is elegant enough. You can even automate the process of constructing
the script to ship. Do the same for all modules which your script
depends on.
Personally, I would much prefer packaging a lib subdirectory with the
script.
In any case, the point Uri is making is simple. There is really no good
excuse not to use CPAN modules. Sure XS code requires access to a
compiler on the target machine but using CPAN modules does not require
you to install in system directories.
Sinan
--
A. Sinan Unur <1usa@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/
------------------------------
Date: Thu, 22 May 2008 12:06:40 -0700
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <220520081206408667%jimsgibson@gmail.com>
In article
<7d5cdff9-da1a-4877-932e-68d6583be4e6@k37g2000hsf.googlegroups.com>,
nolo contendere <simon.chao@fmr.com> wrote:
> Many times, there exists a module on CPAN that solves a problem I'm
> attempting to solve.
> I'm aware that generally the better choice to solving such a problem
> is to use the CPAN module.
> However, regarding the problem of maintaining sort order of a hash,
> and the Tie::IxHash module, I have a question.
>
> I've heard that Tie::IxHash can be a little slow, and the cost of
> using this in addition to installation costs (where developers don't
> have the permission to have modules installed, especially across all
> environments, and the process for having the module(s) installed by
> admins can be trying to say the least) is much higher than the simple
> solution of adding an extra sortval attribute to a hash value, where
> the value of sortval is simply an incremented counter.
>
> then if you need to access the hash in the order in which items were
> inserted, you could simply:
>
> for my $key ( sort { $hash{$a}{sortval} <=> $hash{$b}{sortval} } keys
> %hash ) {
> # do something
> }
>
>
> 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?
I happen to agree that the FAQ on this topic is a little deficient by
only recommending a Tie'd solution. Tie is one of those things that I
avoid because I don't fully understand it, and I suspect it may cause
problems.
I would suggest two other alternatives for maintaining the order of
hash keys that might be simpler than your suggestion:
1. Prepend a fixed number of characters to each key, and strip them off
when retrieving the key (e.g. '00key1', '01key2', etc.).
2. Save the keys in a separate array and iterate over the array. This
is the simplest approach at the expense of duplicate storage of the
keys.
--
Jim Gibson
------------------------------
Date: Thu, 22 May 2008 19:12:10 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <x7iqx6up9x.fsf@mail.sysarch.com>
>>>>> "nc" == nolo contendere <simon.chao@fmr.com> writes:
>> an example of what??
nc> An example of my initial proposal of a substitute for Tie::IxHash that
nc> maintains the insertion order of elements into a hash.
>> nc> my ( $tree1, $tree2 ) = ( '', '' );
>>
>> useless initialization.
>>
nc> yeah, if i called the script with no options, i got the uninitialized
nc> value warning.
you should check if they were set after the GetOptions call. if not,
then you die or set them to a default like . (doable in GetOptions).
>> nc> GetOptions( "tree1=s" => \$tree1,
>> nc> "tree2=s" => \$tree2 ) or die $USAGE;
>>
>> nc> find( \&get_tgt_info, $tree2 );
>>
>> nc> for my $key ( sort { $src{$a}{sortval} <=> $src{$b}{sortval} } keys
>> nc> %src ) {
>>
>> now that i see this is a dirtree compare (btw, unix diff -r can do this
>> for you), i still don't see the need to keep find order. the order of
>> entries in directories is not stable as it depends on the file system,
>> any deletions and inserts and how file::find reads the dirs. you have a
>> single level hash of each tree so where would insert order matter?
>>
nc> diff -r looks great! wasn't aware of that one...
nc> Well, the need isn't there. But this was just supposed to illustrate
nc> how i set the sortval value, as you asked earlier in the thread.
but you haven't answered my latest question, why do you need insert
order here? i pointed out that dir scanning order is meaniningless (it
isn't stable or predictable) and you use a single level hash too. why
waste all the effort on maintaining a sort order if you never needed it
to begin with?
>> nc> sub get_src_info {
>>
>> nc> my ( $mode, $uid, $gid, $size, $mtime ) =
>> nc> (stat( $File::Find::name ))[2,4,5,7,9];
>> nc> $src{$File::Find::name} = {
>> nc> mode => $mode,
>> nc> uid => $uid,
>> nc> gid => $gid,
>> nc> size => $size,
>> nc> mtime => $mtime,
>> nc> sortval => ++$ctr1,
>>
>> gack, a global counter used by a callback!
>>
nc> should i have used a closure instead?
if you wanted it to be a proper module, yes. this is another advantage
of the cpan module, it can be used multiple times in a program whereas
your example is hardwired to one use. also the cpan module is meant to
be tied to a hash which is very different than your solution.
>> this isn't even usable as a module. you hardwired it to be a standalone
>> script. so how would posting this complex code be a useful FAQ answer?
>>
nc> my code wasn't meant to be a submission for review, but rather a
nc> conceptual demonstration.
still, i review code when i see it and feel like it. :)
nc> cut/paste module code into my scripts? that doesn't seem like an
nc> elegant solution, and what about pre-reqs?
why not? better than cutting/pasting your own code which may nor work
nor do all you want it to do. it may be a last resort and i don't
recommend it but it works. as for prereqs, install them the same way. if
you need code from cpan then you do what is necessary. if you can write
your own code then do it. i just say that your example is not a good one
as the ordering isn't even needed and your code is too hardwired for one
usage to be a good example. the FAQ needs quality answers and the cpan
module is one.
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: Thu, 22 May 2008 12:24:53 -0700 (PDT)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <e9b4ed3a-1413-432f-bc72-595ff562adf9@27g2000hsf.googlegroups.com>
On May 22, 3:03=A0pm, "A. Sinan Unur" <1...@llenroc.ude.invalid> wrote:
> nolo contendere <simon.c...@fmr.com> wrote innews:c488ee9d-a5e5-4fd7-8728-=
fbd3dad1726a@2g2000hsn.googlegroups.com:
>
> > On May 22, 2:24=A0pm, Uri Guttman <u...@stemsystems.com> wrote:
> >> installing your own code is not any easier/harder than installing
> >> pure perl modules on production machines. you can even cut/paste the
> >> module code into your scripts if that is the only way. as i said,
> >> there are almost no good excuses for not using a module.
>
> > cut/paste module code into my scripts? that doesn't seem like an
> > elegant solution, and what about pre-reqs?
>
> It is elegant enough. You can even automate the process of constructing
> the script to ship. Do the same for all modules which your script
> depends on.
>
> Personally, I would much prefer packaging a lib subdirectory with the
> script.
Good point.
------------------------------
Date: Thu, 22 May 2008 12:28:36 -0700 (PDT)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <4c143157-fc71-49dc-94ad-d492df52fd1a@2g2000hsn.googlegroups.com>
On May 22, 3:06=A0pm, Jim Gibson <jimsgib...@gmail.com> wrote:
> In article
> <7d5cdff9-da1a-4877-932e-68d6583be...@k37g2000hsf.googlegroups.com>,
>
>
>
> nolo contendere <simon.c...@fmr.com> wrote:
> > Many times, there exists a module on CPAN that solves a problem I'm
> > attempting to solve.
> > I'm aware that generally the better choice to solving such a problem
> > is to use the CPAN module.
> > However, regarding the problem of maintaining sort order of a hash,
> > and the Tie::IxHash module, I have a question.
>
> > I've heard that Tie::IxHash can be a little slow, and the cost of
> > using this in addition to installation costs (where developers don't
> > have the permission to have modules installed, especially across all
> > environments, and the process for having the module(s) installed by
> > admins can be trying to say the least) is much higher than the simple
> > solution of adding an extra sortval attribute to a hash value, where
> > the value of sortval is simply an incremented counter.
>
> > then if you need to access the hash in the order in which items were
> > inserted, you could simply:
>
> > for my $key ( sort { $hash{$a}{sortval} <=3D> $hash{$b}{sortval} } keys
> > %hash ) {
> > =A0 =A0 # do something
> > }
>
> > 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
> > =A0 =A0 =A0 =A0 =A0 into it?
>
> I happen to agree that the FAQ on this topic is a little deficient by
> only recommending a Tie'd solution. Tie is one of those things that I
> avoid because I don't fully understand it, and I suspect it may cause
> problems.
>
> I would suggest two other alternatives for maintaining the order of
> hash keys that might be simpler than your suggestion:
>
> 1. Prepend a fixed number of characters to each key, and strip them off
> when retrieving the key (e.g. '00key1', '01key2', etc.).
I've done something similar before, creating a composite key, with a
delimiter (like '|'), then I split the key and sort the sortval
component of the composite key. Problem here though is that you lose
the 'uniquifying' property of hashes for the original key if you are
attaching a unique counter to the original key.
>
> 2. Save the keys in a separate array and iterate over the array. This
> is the simplest approach at the expense of duplicate storage of the
> keys.
>
I like this solution. A little redundancy, but not much can go wrong
with it. Thanks!
------------------------------
Date: Thu, 22 May 2008 12:34:30 -0700 (PDT)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <2a52d4aa-05ab-4865-8312-339cc3866aca@8g2000hse.googlegroups.com>
On May 22, 3:12=A0pm, Uri Guttman <u...@stemsystems.com> wrote:
> >>>>> "nc" =3D=3D nolo contendere <simon.c...@fmr.com> writes:
>
> =A0 >> an example of what??
>
> =A0 nc> An example of my initial proposal of a substitute for Tie::IxHash =
that
> =A0 nc> maintains the insertion order of elements into a hash.
>
> =A0 >> =A0 nc> my ( $tree1, $tree2 ) =3D ( '', '' );
> =A0 >>
> =A0 >> useless initialization.
> =A0 >>
>
> =A0 nc> yeah, if i called the script with no options, i got the uninitiali=
zed
> =A0 nc> value warning.
>
> you should check if they were set after the GetOptions call. if not,
> then you die or set them to a default like . (doable in GetOptions).
>
True.
> =A0 >> =A0 nc> GetOptions( "tree1=3Ds" =3D> \$tree1,
> =A0 >> =A0 nc> =A0 =A0 =A0 =A0 =A0 =A0 "tree2=3Ds" =3D> \$tree2 ) or die $=
USAGE;
> =A0 >>
> =A0 >> =A0 nc> find( \&get_tgt_info, $tree2 );
> =A0 >>
> =A0 >> =A0 nc> for my $key ( sort { $src{$a}{sortval} <=3D> $src{$b}{sortv=
al} } keys
> =A0 >> =A0 nc> %src ) {
> =A0 >>
> =A0 >> now that i see this is a dirtree compare (btw, unix diff -r can do =
this
> =A0 >> for you), i still don't see the need to keep find order. the order =
of
> =A0 >> entries in directories is not stable as it depends on the file syst=
em,
> =A0 >> any deletions and inserts and how file::find reads the dirs. you ha=
ve a
> =A0 >> single level hash of each tree so where would insert order matter?
> =A0 >>
>
> =A0 nc> diff -r looks great! wasn't aware of that one...
> =A0 nc> Well, the need isn't there. But this was just supposed to illustra=
te
> =A0 nc> how i set the sortval value, as you asked earlier in the thread.
>
> but you haven't answered my latest question, why do you need insert
> order here? i pointed out that dir scanning order is meaniningless (it
> isn't stable or predictable) and you use a single level hash too. why
> waste all the effort on maintaining a sort order if you never needed it
> to begin with?
>
The need isn't there, as I said before. I thought I might have a use
for it, then discovered I didn't, but left the "sorting" code there
just in case. But, if, as you say, it's unreliable, it's kind of moot.
> =A0 >> =A0 nc> sub get_src_info {
> =A0 >>
> =A0 >> =A0 nc> =A0 =A0 my ( $mode, $uid, $gid, $size, $mtime ) =3D
> =A0 >> =A0 nc> (stat( $File::Find::name ))[2,4,5,7,9];
> =A0 >> =A0 nc> =A0 =A0 $src{$File::Find::name} =3D {
> =A0 >> =A0 nc> =A0 =A0 =A0 =A0 mode =A0 =A0=3D> $mode,
> =A0 >> =A0 nc> =A0 =A0 =A0 =A0 uid =A0 =A0 =3D> $uid,
> =A0 >> =A0 nc> =A0 =A0 =A0 =A0 gid =A0 =A0 =3D> $gid,
> =A0 >> =A0 nc> =A0 =A0 =A0 =A0 size =A0 =A0=3D> $size,
> =A0 >> =A0 nc> =A0 =A0 =A0 =A0 mtime =A0 =3D> $mtime,
> =A0 >> =A0 nc> =A0 =A0 =A0 =A0 sortval =3D> ++$ctr1,
> =A0 >>
> =A0 >> gack, a global counter used by a callback!
> =A0 >>
>
> =A0 nc> should i have used a closure instead?
>
> if you wanted it to be a proper module, yes. this is another advantage
> of the cpan module, it can be used multiple times in a program whereas
> your example is hardwired to one use. also the cpan module is meant to
> be tied to a hash which is very different than your solution.
>
> =A0 >> this isn't even usable as a module. you hardwired it to be a standa=
lone
> =A0 >> script. so how would posting this complex code be a useful FAQ answ=
er?
> =A0 >>
>
> =A0 nc> my code wasn't meant to be a submission for review, but rather a
> =A0 nc> conceptual demonstration.
>
> still, i review code when i see it and feel like it. :)
>
Guess I can't stop you :-).
> =A0 nc> cut/paste module code into my scripts? that doesn't seem like an
> =A0 nc> elegant solution, and what about pre-reqs?
>
> why not? better than cutting/pasting your own code which may nor work
> nor do all you want it to do. it may be a last resort and i don't
> recommend it but it works. as for prereqs, install them the same way. if
> you need code from cpan then you do what is necessary. if you can write
> your own code then do it. i just say that your example is not a good one
> as the ordering isn't even needed and your code is too hardwired for one
> usage to be a good example. the FAQ needs quality answers and the cpan
> module is one.
>
I hadn't thought of packaging up the code in a lib dir, as Sinan
suggested. That's probably what you meant earlier, but I missed it.
Good point.
------------------------------
Date: Thu, 22 May 2008 19:34:38 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <x71w3uuo8h.fsf@mail.sysarch.com>
>>>>> "nc" == nolo contendere <simon.chao@fmr.com> writes:
>> 2. Save the keys in a separate array and iterate over the array. This
>> is the simplest approach at the expense of duplicate storage of the
>> keys.
>>
nc> I like this solution. A little redundancy, but not much can go wrong
nc> with it. Thanks!
that is pretty much what the tie module does IIRC. plenty can still go
wrong with it and that is that the 'order' is still affected by deletes
and later additions. if you repeatedly add and delete you can fill up
the array and waste lots of storage. accessing a large hash by sorting a
subkey is slow and has to be done again each time you modify the
hash. my point is that order and hash are not compatible. there will
always be some aspect that will be exposed to the coder or some
compromise made. a hash has no order for its keys and forcing some order
means you don't really have a hash anymore, just something with hashlike
behavior.
and you still haven't answered WHY you need ordering in the example
code. i don't see how you benefit from the dir tree scan order.
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: Thu, 22 May 2008 19:50:16 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <o7jb34hop3s1cpnc40240k410sk2un0tjs@4ax.com>
nolo contendere <simon.chao@fmr.com> wrote:
>However, regarding the problem of maintaining sort order of a hash,
>and the Tie::IxHash module, I have a question.
Maybe I am old-fashioned but to me 'sorted' and 'hash' is a
contradiction in terms. A hash is a (partial) mapping from string to
scalar and mappings do not have a sequence.
Arrays are different because their domain (natural numbers) does have a
natural order, therefore arrays inherit this order.
If you are trying to force an order on a hash then probably you are
using the wrong data structure in the first place and you would be
better off using an array.
Just my 2 cents.
jue
------------------------------
Date: Thu, 22 May 2008 13:04:55 -0700 (PDT)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: maintaining order in a hash (without Tie::IxHash)
Message-Id: <e24c5c7c-d07c-4da9-a368-b6e25a1db4e9@2g2000hsn.googlegroups.com>
On May 22, 3:50=A0pm, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> nolo contendere <simon.c...@fmr.com> wrote:
> >However, regarding the problem of maintaining sort order of a hash,
> >and the Tie::IxHash module, I have a question.
>
> Maybe I am old-fashioned but to me 'sorted' and 'hash' is a
> contradiction in terms. A hash is a (partial) mapping from string to
> scalar and mappings do not have a sequence.
> Arrays are different because their domain (natural numbers) does have a
> natural order, therefore arrays inherit this order.
>
> If you are trying to force an order on a hash then probably you are
> using the wrong data structure in the first place and you would be
> better off using an array.
>
I understand that in many cases people who bring up ordered hashes
would be better served by using another data structure, but it seems
that enough people have asked about this, and it is useful enough to
have a module written for it on CPAN, and be included in the FAQ. Now
before you argue that just because lots of people ask about it and it
is a module doesn't mean that it's useful, don't forget my last caveat
that it is in the FAQ. Lots of people ask about variable variable
names too (symrefs, whatever you want to call them), but they are much
more harmful than useful, and their use is discouraged by the majority
of knowledgeable Perl hackers out there, and there is no FAQ
encouraging the use of a module that manages symrefs.
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?
------------------------------
Date: Thu, 22 May 2008 13:07:55 -0700 (PDT)
From: Alex Stankevich <astankevich@gmail.com>
Subject: using m//g to parse multi-line records without an outside delimiter
Message-Id: <3101a95e-5b38-45eb-81b8-e20f3a1e3559@z72g2000hsb.googlegroups.com>
undef $/;
$file = <DATA>;
print "---using m//g ---\n";
while ($file =~ /^(From \w+\@xyz.com.*?)(?=^From \w+\@xyz.com)/gms) {
print $1;
print '<' x 60, "\n";
}
print "---using split---\n";
foreach (split /From \w+\@xyz.com/, $file) {
print $_;
print '<' x 60, "\n";
}
__DATA__
From mail@xyz.com
Header1: val1
To: abc@xyz.com
Subject: bla
body 1 of the email
From root@xyz.com
Header1: val1
To: abc@xyz.com
Subject: bla
body 2 of the email
From user01@xyz.com
Header1: val1
To: abc@xyz.com
Subject: bla
body 3 of the email
I have a data file with multi-line records where the records are
delimited by some character pattern which is also part of the
beginning of the record. I'd like to iterate through these records
while capturing the entire record in a scalar variable.
I'm looking for help with fixing the regex I have in the while loop to
not leave out the last record in the file, and suggestions for better
ways of approaching this problem altogether.
I'm using perl 5.8.0 on linux.
I've looked through perlfaq6 for help in improving the regex and also
in "Master Regular Expressions". However, I couldn't figure out the
right way to fix the regex.
The faq and the book suggested the split as another approach, however,
the problem with it is that I don't know how to capture the string
which matches it, and because it's part of the record (its beginning),
I need to retain it.
Thanks in advance for your help,
Alex.
------------------------------
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 1568
***************************************
