[29986] in Perl-Users-Digest
Perl-Users Digest, Issue: 1229 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 24 14:09:54 2008
Date: Thu, 24 Jan 2008 11:09: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 Thu, 24 Jan 2008 Volume: 11 Number: 1229
Today's topics:
Re: A "deep" hash to/from a file? <jurgenex@hotmail.com>
Re: A "deep" hash to/from a file? <tzz@lifelogs.com>
Re: Exists a Module to transform RTF to PDF, directly <tzz@lifelogs.com>
Re: File Monitoring modules <tzz@lifelogs.com>
Re: File Monitoring modules xhoster@gmail.com
Re: File Monitoring modules nagandla@gmail.com
File::SortedSeek not working <tzhai2007@gmail.com>
Re: File::SortedSeek not working <glex_no-spam@qwest-spam-no.invalid>
Re: File::SortedSeek not working xhoster@gmail.com
Re: File::SortedSeek not working <tzhai2007@gmail.com>
Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. <simon.chao@fmr.com>
Re: Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: Get an arbitrary hash key, quickly. <uri@stemsystems.com>
Re: Get an arbitrary hash key, quickly. xhoster@gmail.com
Re: RegEx, how to seperate word from digits? <tzz@lifelogs.com>
Relying on $_ <bernie@fantasyfarm.com>
Re: Relying on $_ <smallpond@juno.com>
Re: sorting a list of objects using one of their method <john@castleamber.com>
sprintf rounding with FreeBSD and perl 5.8.x cherbst@gmail.com
Re: sprintf rounding with FreeBSD and perl 5.8.x <glex_no-spam@qwest-spam-no.invalid>
Re: sprintf rounding with FreeBSD and perl 5.8.x cherbst@gmail.com
Re: sprintf rounding with FreeBSD and perl 5.8.x <RedGrittyBrick@SpamWeary.foo>
Re: The Way to Paradise is Perl <smallpond@juno.com>
Re: The Way to Paradise <t.x.michaels@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 24 Jan 2008 14:09:16 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: A "deep" hash to/from a file?
Message-Id: <8q6hp3dnum8tm9fum5sf81pc6m8a98mi9p@4ax.com>
Pat <none@none.none> wrote:
>I would like to build a hash from an input text file. The hash can
>contain other hashes, and so on, to any depth. The format of the input
>file can be anything that is convenient, e.g.:
You may want to have a look a
Data::Dumper - stringified perl data structures, suitable for both
printing and "eval"
It is designed for specifically that purpose.
jue
------------------------------
Date: Thu, 24 Jan 2008 09:24:05 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: A "deep" hash to/from a file?
Message-Id: <86sl0n9rhm.fsf@lifelogs.com>
On Thu, 24 Jan 2008 10:56:59 +0100 Damian Lukowski <damian@tvk.rwth-aachen.de> wrote:
DL> Pat schrieb:
>> Damian Lukowski wrote:
>>
>>> I think, a recursive descent parser will be the best and easiest way
>>> to do it.
>>
>> Yeah, I hoped to come up with something like that, but failed to do
>> the job with a regular expression. The problem is with the nested
>> curly braces. For example, for the following input string...
DL> Thats not, how a descent parser works. Simply speaking, if you want to
DL> parse a branch with all subbranches and leafes, you have to check, if
DL> the string begins with "BRANCHNAME {". If so, call a subroutine, which
DL> parses a branch. This subroutine has to check for other branches and
DL> leafes, and finally it has to chop off the closing curly branch.
DL> This may look like as following:
You should consider Parse::RecDescent for a simple solution to
recursive-descent parsing in Perl 5. It's actually pretty similar to
what Perl 6 will do with grammars. Your code may work, but it's hard to
maintain it if the format changes even slightly.
Anyhow, I wouldn't use P::RD either. The OP should look into a true
structured format like YAML or XML or Config*, as others have suggested.
Even JSON might work; it's a pretty nice format actually. "Simple"
formats like the one the OP shows tend to evolve into ugliness over time
and become unmaintainable messes, so unless there's a very good reason
I'd stick with something more standard.
If a custom format is absolutely necessary, consider losing the braces
and the structure, going to a line-oriented format instead:
root branch_1 sub_branch_1 leaf_1 = This is leaf_1
root branch_1 sub_branch_1 leaf_2 = This is leaf_2
...
(assuming no spaces in node names)
This is much easier to parse, and it's understandable. It's verbose,
but that's a problem I'd be willing to live with. Parsing then becomes
just:
#!/usr/bin/perl
use warnings;
use strict;
use Data::Dumper;
my $config = {};
while (my $line = <DATA>)
{
chomp $line;
my ($path, $data) = split / = /, $line;
my @path = split ' ', $path;
my $where = $config;
while (scalar @path)
{
my $node = shift @path;
if (scalar @path) # do we have more branches?
{
$where->{$node} = {} unless exists $where->{$node};
$where = $where->{$node};
}
else
{
$where->{$node} = $data;
}
}
}
print Dumper $config;
__DATA__
root branch_1 sub_branch_1 leaf_1 = This is leaf_111
root branch_1 sub_branch_1 leaf_2 = This is leaf_112
root branch_1 sub_branch_2 leaf_1 = This is leaf_121
root branch_2 = This is branch 2
root branch_2 = This is branch 2 again
Ted
------------------------------
Date: Thu, 24 Jan 2008 09:33:39 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Exists a Module to transform RTF to PDF, directly
Message-Id: <86lk6f9r1o.fsf@lifelogs.com>
On Wed, 23 Jan 2008 12:27:42 -0800 (PST) lala4life <rafael.avaria@gmail.com> wrote:
l> Exists a module to transform RTF to PDF, directly.
l> In cpan found modules to transform RTF to HTML and then HTML to PDF,
l> but is lossless HTML is not so rich format as RTF.
No, you have to go through HTML AFAIK. You could print to a PDF from
Word, and you may even be able to automate that with Win32::OLE (I have
no idea if that's possible, I've only automated Excel). Direct printing
without conversion will probably give you the best results.
Ted
------------------------------
Date: Thu, 24 Jan 2008 09:07:58 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: File Monitoring modules
Message-Id: <86wspz9s8h.fsf@lifelogs.com>
On Thu, 24 Jan 2008 01:22:57 -0800 (PST) nagandla@gmail.com wrote:
n> until ($terminate)
n> {
...
n> # check for FAM events
n> if ($fam->pending)
n> {
...
n> &process_fam_event($event);
n> }
n> }
Looks like you are just running this in a busy loop, meaning you never
pause to give the rest of the system a chance to catch up. Your process
will be preempted by the kernel if necessary, but otherwise it will take
up all the CPU (which is what you're seeing). Try a sleep(1) for a
1-second pause at the end of the until() loop and see if your CPU
utilization drops; it should.
Ted
------------------------------
Date: 24 Jan 2008 15:37:24 GMT
From: xhoster@gmail.com
Subject: Re: File Monitoring modules
Message-Id: <20080124103725.603$Gy@newsreader.com>
nagandla@gmail.com wrote:
>
> # check for FAM events
> if ($fam->pending)
> {
> my $event;
> eval { $event = $fam->next_event; };
>
> if ($@)
> {
> print "FAM error: rebuilding cache...\n\n\n";
> $fam = undef;
> next;
> }
pending does not block, it returns immediately, and hence forms a tight
loop. Since that isn't what you want to do, then don't do that. Skip
the pending and just use the next_event. That is, replace the above with:
# check for FAM events
my $event = eval { $fam->next_event; };
if ($@) {
print "FAM error: rebuilding cache...\n\n\n";
$fam = undef;
next;
};
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Jan 2008 08:43:58 -0800 (PST)
From: nagandla@gmail.com
Subject: Re: File Monitoring modules
Message-Id: <b2091e62-2525-4044-ae03-9c24a325c4bb@i12g2000prf.googlegroups.com>
On Jan 24, 8:37 pm, xhos...@gmail.com wrote:
> nagan...@gmail.com wrote:
>
> > # check for FAM events
> > if ($fam->pending)
> > {
> > my $event;
> > eval { $event = $fam->next_event; };
>
> > if ($@)
> > {
> > print "FAM error: rebuilding cache...\n\n\n";
> > $fam = undef;
> > next;
> > }
>
> pending does not block, it returns immediately, and hence forms a tight
> loop. Since that isn't what you want to do, then don't do that. Skip
> the pending and just use the next_event. That is, replace the above with:
>
> # check for FAM events
> my $event = eval { $fam->next_event; };
> if ($@) {
> print "FAM error: rebuilding cache...\n\n\n";
> $fam = undef;
> next;
> };
>
> Xho
>
> --
> --------------------http://NewsReader.Com/--------------------
> The costs of publication of this article were defrayed in part by the
> payment of page charges. This article must therefore be hereby marked
> advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
> this fact.
Ya,,Thank U..
As u said pending event is taking so much CPU usage more than(90%)...
I removed the pending event so that the CPU usage came more or less
equal to (5%).....
Thank u
Regards
Nagandla
------------------------------
Date: Thu, 24 Jan 2008 09:12:49 -0800 (PST)
From: worker <tzhai2007@gmail.com>
Subject: File::SortedSeek not working
Message-Id: <7e86f949-12f8-4e2e-8eab-99ec912aa788@x69g2000hsx.googlegroups.com>
Hi, all,
I am using this File::SortedSeek module to search a big data file
and it is not working.
The data file has these entries:
01/01/1960,0.75
01/02/1960,0.00
etc
basically, a date followed by a number
Then, I have this other file contains only the list of valid date
as follows:
01/05/1960
01/07/1960
So, what I am doing is to get a line from the valid date file, then
File::SortedSeek out the matching date in the data file, but no matter
how I try, it is not matching at all,
Is that module real or just a quack?!
thx
bill
------------------------------
Date: Thu, 24 Jan 2008 11:36:33 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: File::SortedSeek not working
Message-Id: <4798cca1$0$493$815e3792@news.qwest.net>
worker wrote:
> Hi, all,
> I am using this File::SortedSeek module to search a big data file
> and it is not working.
>
> The data file has these entries:
>
> 01/01/1960,0.75
> 01/02/1960,0.00
> etc
>
> basically, a date followed by a number
>
> Then, I have this other file contains only the list of valid date
> as follows:
>
> 01/05/1960
> 01/07/1960
>
> So, what I am doing is to get a line from the valid date file, then
> File::SortedSeek out the matching date in the data file, but no matter
> how I try, it is not matching at all,
>
> Is that module real or just a quack?!
Check line 42.
------------------------------
Date: 24 Jan 2008 18:12:38 GMT
From: xhoster@gmail.com
Subject: Re: File::SortedSeek not working
Message-Id: <20080124131239.863$oF@newsreader.com>
worker <tzhai2007@gmail.com> wrote:
> Hi, all,
> I am using this File::SortedSeek module to search a big data file
> and it is not working.
>
> The data file has these entries:
>
> 01/01/1960,0.75
> 01/02/1960,0.00
> etc
>
> basically, a date followed by a number
>
> Then, I have this other file contains only the list of valid date
> as follows:
>
> 01/05/1960
> 01/07/1960
>
> So, what I am doing is to get a line from the valid date file, then
> File::SortedSeek out the matching date in the data file, but no matter
> how I try, it is not matching at all,
>
> Is that module real or just a quack?!
It is far more likely that you are a quack who is using the module
incorrectly. If you showed us the code, we might be able to verify
which if the two is the case.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Jan 2008 10:54:23 -0800 (PST)
From: worker <tzhai2007@gmail.com>
Subject: Re: File::SortedSeek not working
Message-Id: <e39e015e-d847-4aec-85bb-e04e9554d4cd@c23g2000hsa.googlegroups.com>
On Jan 24, 12:36 pm, "J. Gleixner" <glex_no-s...@qwest-spam-
no.invalid> wrote:
> worker wrote:
> > Hi, all,
> > I am using this File::SortedSeek module to search a big data file
> > and it is not working.
>
> > The data file has these entries:
>
> > 01/01/1960,0.75
> > 01/02/1960,0.00
> > etc
>
> > basically, a date followed by a number
>
> > Then, I have this other file contains only the list of valid date
> > as follows:
>
> > 01/05/1960
> > 01/07/1960
>
> > So, what I am doing is to get a line from the valid date file, then
> > File::SortedSeek out the matching date in the data file, but no matter
> > how I try, it is not matching at all,
>
> > Is that module real or just a quack?!
>
> Check line 42.
Hi, I am listing my little test code below, please help: (the problem
is that it can't find a match)
I guess the main thing I didn't get right is the matching pattern that
matches those dates, so I guess that's the part I am seeking help.
thx.
####### Start test code #####
use File::SortedSeek;
my $dfile = './dtest.file';
my $file = './test.file';
open DTEST,">$dfile" or die "0bad\n";
open TEST, ">$file" or die "bad\n";
print DTEST "01/01/1960\n01/02/1960\n"; close(DTEST);
print TEST
"01/10/1949,0.1\n01/02/1950,0.2\n1/1/1960,7.0\n1/2/1960,8.0\n3/3/1980,9.0\n";
close(TEST);
open DTEST,"<$dfile" or die "0bad\n";
open TEST, "<$file" or die "bad\n";
my $line;
my $zline;
$line = <DTEST>;
chomp ($line);
$tell = File::SortedSeek::alphabetic(*TEST,$line,\&munge_string);
$zline = <TEST>;
print "Found it?:: $zline\n";
close(TEST);close(DTEST);
exit(0);
sub munge_string {
my $line = shift || return undef;
# return ($line =~ m/\|(\w+)$/) ? $1 : undef;
# return ($line =~ m/^[0-9]+\/[0-9]+\/[0-9]+,/) ? $1 : undef;
return ($line =~ m/^\/,/) ? $1 : undef;
}
#### End test code ####
------------------------------
Date: 24 Jan 2008 17:25:07 GMT
From: xhoster@gmail.com
Subject: Get an arbitrary hash key, quickly.
Message-Id: <20080124122509.078$og@newsreader.com>
I need a work queue, but I don't really care about the order (LIFO, FIFO,
random) in which things come out of it. Either is pretty simple and
efficient with a Perl array, and either would suffice. But I want the
queue to not hold duplicate entries. I could use an array as a stack or
queue, with a parallel hash to be checked to prevent duplicates from being
entered. But why keep parallel data structures? Just use the hash as the
queue:
while (key %hash) {
my $to_do=each %hash;
delete $hash{$to_do};
## do stuff with $to_do, which might make new entries in %hash
};
Well, except that this gets really slow on large hashes.
I suspect the each operator does a linear scan of all the buckets until it
finds an occupied one. With a hash that used to be big but now isn't (and
so has lots of empty buckets), this behaves poorly, essentially being N^2
to empty a large hash.
If I just use scalar %hash instead of scalar keys %hash, then the slow down
doesn't occur because "each" scans the buckets from where it left off last
time, instead of from the beginning each time. (At first I thought it was
scalar keys %hash that was being slow and was going to post about *that*,
but then I realized that keys' reseting of the iterator was causing "each"
to be slow). But you shouldn't change a hash at the same time you iterate
over it because things might get missed. Presumably, anything missed will
be found on the next time through the iterator, so this might work without
the slowdown:
while (%hash) { # does not reset iterator
my $to_do=each %hash;
next unless defined $to_do; # not a real hash key,
# signals end of iterator
## do stuff with $to_do, which might make new entries in %hash
};
If my speculation on the internals is right, then this would still
perform poorly if the hash first grows very large, then shrinks to
be only a few elements, but those last few elements keep triggering
the addition of just one more element each time. In my case, that
shouldn't be a problem.
Any comments on this code? Is there some less quirky way to do this
efficiently? Is there a simple (as simple as perl's internals can get)
way to fix "each" so that it doesn't have this degenerate case?
Thanks,
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Jan 2008 09:43:32 -0800 (PST)
From: nolo contendere <simon.chao@fmr.com>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <c45e52b1-a655-4d56-91a6-fdfec572b7b3@k2g2000hse.googlegroups.com>
On Jan 24, 12:25=A0pm, xhos...@gmail.com wrote:
> I need a work queue, but I don't really care about the order (LIFO, FIFO,
> random) in which things come out of it. =A0Either is pretty simple and
> efficient with a Perl array, and either would suffice. =A0But I want the
> queue to not hold duplicate entries. =A0I could use an array as a stack or=
> queue, with a parallel hash to be checked to prevent duplicates from being=
> entered. =A0But why keep parallel data structures? =A0Just use the hash as=
the
> queue:
>
> while (key %hash) {
> =A0 my $to_do=3Deach %hash;
> =A0 delete $hash{$to_do};
> =A0 ## do stuff with $to_do, which might make new entries in %hash
>
> };
>
if "do stuff" might make entries in %hash, how do you guarantee you
won't be operating on a duplicate entry, since you delete
$hash{$to_do}?
------------------------------
Date: 24 Jan 2008 18:07:41 GMT
From: xhoster@gmail.com
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <20080124130742.908$AG@newsreader.com>
nolo contendere <simon.chao@fmr.com> wrote:
> On Jan 24, 12:25=A0pm, xhos...@gmail.com wrote:
> > I need a work queue, but I don't really care about the order (LIFO,
> > FIFO, random) in which things come out of it. =A0Either is pretty
> > simple and efficient with a Perl array, and either would suffice.
> > =A0But I want the queue to not hold duplicate entries. =A0I could use
> > an array as a stack or=
>
> > queue, with a parallel hash to be checked to prevent duplicates from
> > being entered. But why keep parallel data structures? Just use the hash
> > as the queue:
> >
> > while (key %hash) {
> > my $to_do=3Deach %hash;
> > delete $hash{$to_do};
> > ## do stuff with $to_do, which might make new entries in %hash
> >
> > };
> >
>
> if "do stuff" might make entries in %hash, how do you guarantee you
> won't be operating on a duplicate entry, since you delete
> $hash{$to_do}?
I want to guarantee that duplicate entries won't be in the queue *at the
same time*. Whether they can be re-entered at a later point is up to
the details of "do stuff", which vary from project to project and which
I am intentionally avoiding.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Jan 2008 18:25:10 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <x78x2fxere.fsf@mail.sysarch.com>
>>>>> "x" == xhoster <xhoster@gmail.com> writes:
x> I need a work queue, but I don't really care about the order (LIFO, FIFO,
x> random) in which things come out of it. Either is pretty simple and
x> efficient with a Perl array, and either would suffice. But I want the
x> queue to not hold duplicate entries. I could use an array as a stack or
x> queue, with a parallel hash to be checked to prevent duplicates from being
x> entered. But why keep parallel data structures? Just use the hash as the
x> queue:
why not use the hash/array pair? and how do you generate dup work
request keys anyway? why not use a ref to the work thing as the key as
that will be unique. then an array will be fine.
x> while (key %hash) {
x> my $to_do=each %hash;
why not do this instead?
while( my $todo = each %hash ) {
#do work
delete $hash{$to_do};
keys %hash ; # reset iterator
the docs say IIRC that keys in a void context will reset the
iterator. keys in a while condition is in a scalar/boolean context and
may just return the number of keys.
and as another poster says, adding hash elements in a loop may change the
iterator order and cause unknown results. you need to do a clean reset
of the hash iterator so the each will work correctly.
x> If I just use scalar %hash instead of scalar keys %hash, then the slow down
x> doesn't occur because "each" scans the buckets from where it left off last
x> time, instead of from the beginning each time. (At first I thought it was
x> scalar keys %hash that was being slow and was going to post about *that*,
x> but then I realized that keys' reseting of the iterator was causing "each"
x> to be slow). But you shouldn't change a hash at the same time you iterate
x> over it because things might get missed. Presumably, anything missed will
x> be found on the next time through the iterator, so this might work without
x> the slowdown:
and you may not see all the elements of the hash as the iterator could
skip over new entries.
the best asnwer is what i said above, do a proper iterator reset after
you process the current work (actually just after the each() call should
work fine too and that would be clearer).
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Architecture, Development, Training, Support, Code Review ------
----------- Search or Offer Perl Jobs ----- http://jobs.perl.org ---------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: 24 Jan 2008 18:59:24 GMT
From: xhoster@gmail.com
Subject: Re: Get an arbitrary hash key, quickly.
Message-Id: <20080124135926.692$d0@newsreader.com>
Uri Guttman <uri@stemsystems.com> wrote:
> >>>>> "x" == xhoster <xhoster@gmail.com> writes:
>
> x> I need a work queue, but I don't really care about the order (LIFO,
> FIFO, x> random) in which things come out of it. Either is pretty
> simple and x> efficient with a Perl array, and either would suffice.
> But I want the x> queue to not hold duplicate entries. I could use an
> array as a stack or x> queue, with a parallel hash to be checked to
> prevent duplicates from being x> entered. But why keep parallel data
> structures? Just use the hash as the x> queue:
>
> why not use the hash/array pair?
Parallel data structures are ugly and easy to screw up because they always
need to be kept in sync. Also, they need to use more memory, which in some
cases may be important. But other than that, there is no reason not to.
That is what I often do, and it works, I just want something neater.
> and how do you generate dup work
> request keys anyway? why not use a ref to the work thing as the key as
> that will be unique. then an array will be fine.
I don't understand what you are saying. What stops an array from
containing many duplicate values, be they references or anything else?
>
> x> while (key %hash) {
> x> my $to_do=each %hash;
>
> why not do this instead?
>
> while( my $todo = each %hash ) {
>
> #do work
> delete $hash{$to_do};
> keys %hash ; # reset iterator
Effectively the same thing, just re-worded. Works, but has the
same slowness issue, presumably for the same reason.
>
> the docs say IIRC that keys in a void context will reset the
> iterator. keys in a while condition is in a scalar/boolean context and
> may just return the number of keys.
Nah, it resets in all contexts. In a void context, that is all it does.
(i.e. it doesn't build the return list and then through it away, or
something like that.)
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Thu, 24 Jan 2008 09:41:06 -0600
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: RegEx, how to seperate word from digits?
Message-Id: <86hch39qp9.fsf@lifelogs.com>
On Thu, 24 Jan 2008 11:28:07 +0100 "Dr.Ruud" <rvtol+news@isolution.nl> wrote:
R> smallpond schreef:
>> kirknew2Reg:
>>> I have a column that contains "suite 111" and "suite222"I need a $
>>> variable containing the word part and aother $ variable containing
>>> the digit part. I have tried variations on this syntax:
>>> (\w*)(\d*)(.*)
>>> (\w*)(\s?)(\d*)(.*)
>>> But nothig I have tried seperates the word from the digits when
>>> there is no space. How do i get 'suite222' to brake in to seperate
>>> variables?
>>
>> How about: /([[:alpha:]]*)\s*(\d*)/
R> To keep up the POSIX-style:
R> /([[:alpha:]]+)[[:blank:]]*([[:digit:]]+)/
R> And [[:blank:]] contains less characters that \s.
R> And [[:alpha:]] can of course be obscured as [^\W\d_].
Just make the \w match non-greedy. The last test case below is
questionable, but the OP didn't specify what to do in that case.
There's also the "match against the reversed string and reverse the
matches" approach :)
Ted
for ("suite 111", "suite222", " 111", "222")
{
if (/^(\w+?)\s*(\d+)$/) # match \w characters conservatively
{
print "$_: $1 - $2\n";
}
else
{
print "$_: no match\n";
}
}
-->
suite 111: suite - 111
suite222: suite - 222
111: no match
222: 2 - 22
------------------------------
Date: Thu, 24 Jan 2008 12:15:57 -0500
From: Bernie Cosell <bernie@fantasyfarm.com>
Subject: Relying on $_
Message-Id: <qihhp31n8icqo4jm24hn0vhreh60q255kj@library.airnews.net>
As a matter of style and expectation, I'm wondering about relying on $_.
Often, just for convenience I'll do a no-var foreach. For example:
foreach (sort keys %SOMEHASH)
{ print "Processing $_\n" ;
my $target = $SOMEHASH{$_} ;
....
}
and I'll refer to $_ here and there in the loop [e.g., if something fails
I'll typically just do a 'die "Error processing $_: $!\n" ;' or the like].
Is that bad form? I just sorted out a minor problem where I was calling an
object method and I was surprised to discover that $_ was clobbered when I
got back from the method.
Is this a bug [even if a minor one] in the package? If not, what are the
rules for when you should and shouldn't expect $_ to get messed up?
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
bernie@fantasyfarm.com Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
Date: Thu, 24 Jan 2008 09:58:50 -0800 (PST)
From: smallpond <smallpond@juno.com>
Subject: Re: Relying on $_
Message-Id: <9d077018-290b-4bae-8739-e0388b96d87c@s19g2000prg.googlegroups.com>
On Jan 24, 12:15 pm, Bernie Cosell <ber...@fantasyfarm.com> wrote:
> As a matter of style and expectation, I'm wondering about relying on $_.
> Often, just for convenience I'll do a no-var foreach. For example:
> foreach (sort keys %SOMEHASH)
> { print "Processing $_\n" ;
> my $target = $SOMEHASH{$_} ;
> ....
> }
> and I'll refer to $_ here and there in the loop [e.g., if something fails
> I'll typically just do a 'die "Error processing $_: $!\n" ;' or the like].
> Is that bad form? I just sorted out a minor problem where I was calling an
> object method and I was surprised to discover that $_ was clobbered when I
> got back from the method.
>
> Is this a bug [even if a minor one] in the package? If not, what are the
> rules for when you should and shouldn't expect $_ to get messed up?
>
It is almost never a good idea to use $_ (or $a or $b) as
the loop variable in a foreach. see perltrap and perlvar.
"my $key" is quite reasonably priced and doesn't
get clobbered by subs that you call.
The rule is pretty simple: there's only one $_ in your
package, and there are many functions that use it implicitly.
Many subs should have local $_ but don't, so it is never good
to assume it will be preserved across a call.
The other thing to remember about foreach is that it creates an
alias for the value, not a copy.
------------------------------
Date: 24 Jan 2008 15:02:50 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: sorting a list of objects using one of their methods?
Message-Id: <Xns9A2F5C093BDB5castleamber@130.133.1.4>
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "JB" == John Bokma <john@castleamber.com> writes:
[..]
> >> >> n*log(n), FK> name would be called log(n) per object.
[snip]
> look at the underlined comment from FK. that is what i didn't
> understand or agree with. actually looking at it now i think he meant
> in the normal sort. his wording wasn't the best IMO.
To me "To be more precise" talks about the naive approach.
> JB> Heh, teach your grandmother to suck eggs. I have a MSc.
>
> so? you know how many people screw up O() numbers?
Not enough to just assume everybody does.
> that of course is not a issue as the higher level sort O(N log N) will
> swamp out the work in each method call. you have to consider name() to
> be a constant factor for the analysis.
If each get_name takes O(N), then it's no longer a constant factor. (I
can't think of any example why it would take O(N), but I've seen enough
code written by people who probably could even make it O(N^2)).
> be a constant factor for the analysis. sure if the compare is
> ridiculously slow (as in something like -M on a file) it could ruin a
> real world sort.
Or if the number of objects is very high.
--
John
http://johnbokma.com/
------------------------------
Date: Thu, 24 Jan 2008 08:51:34 -0800 (PST)
From: cherbst@gmail.com
Subject: sprintf rounding with FreeBSD and perl 5.8.x
Message-Id: <112d0de2-dcb4-4874-8a21-a5d2f2dd0eca@e23g2000prf.googlegroups.com>
I'm getting a weird result with some rounding in a sprintf with perl
5.8.8:
c = 2.47 / 100; # => 0.0247
sprintf("%.1f", 18500 * c); # => 457.0 (NOT on FreeBSD)
sprintf("%.1f", 18500 * 0.0247); # => 456.9
FreeBSD gives 456.9 for both sprintfs, I was able to reproduce it on a
fresh FreeBSD 6.3 install with the perl binary package, and from a
compiled binary.
On Linux perl 5.8.8 gives 457.0, and I get that answer on everything
else I tried (ruby and python on Linux and FreeBSD). I tried using
each of the methods Math::Round, but that is different from sprintf on
Linux, and that is the behavior I was trying to get. Is anybody aware
of something like an unusual CFLAG that might be getting passed when
perl is compiled on FreeBSD?
------------------------------
Date: Thu, 24 Jan 2008 11:03:53 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: sprintf rounding with FreeBSD and perl 5.8.x
Message-Id: <4798c4f9$0$503$815e3792@news.qwest.net>
cherbst@gmail.com wrote:
> I'm getting a weird result with some rounding in a sprintf with perl
> 5.8.8:
>
> c = 2.47 / 100; # => 0.0247
> sprintf("%.1f", 18500 * c); # => 457.0 (NOT on FreeBSD)
> sprintf("%.1f", 18500 * 0.0247); # => 456.9
That's not valid perl, so I have no idea how you're getting a result.
------------------------------
Date: Thu, 24 Jan 2008 09:10:17 -0800 (PST)
From: cherbst@gmail.com
Subject: Re: sprintf rounding with FreeBSD and perl 5.8.x
Message-Id: <f6dd6f28-9d70-4d85-91b7-21d073aa6eb3@c4g2000hsg.googlegroups.com>
On Jan 24, 12:03 pm, "J. Gleixner" <glex_no-s...@qwest-spam-
no.invalid> wrote:
> That's not valid perl, so I have no idea how you're getting a result.
I had omitted the sigils, runs OK otherwise:
---
#!/usr/bin/perl -w
use strict;
my $c = 2.47 / 100; # => 0.0247
printf("%.1f\n", 18500 * $c); # => 457.0 (NOT on FreeBSD)
printf("%.1f\n", 18500 * 0.0247); # => 456.9
---
------------------------------
Date: Thu, 24 Jan 2008 17:39:13 +0000
From: RedGrittyBrick <RedGrittyBrick@SpamWeary.foo>
Subject: Re: sprintf rounding with FreeBSD and perl 5.8.x
Message-Id: <4798cd41$0$21089$da0feed9@news.zen.co.uk>
cherbst@gmail.com wrote:
> I'm getting a weird result with some rounding in a sprintf with perl
> 5.8.8:
>
> c = 2.47 / 100; # => 0.0247
Odd comment! What do you mean "0.0247"?
$c = 2.47 / 100;
does not produce the result 0.0247, since 2.47 and .0247 aren't
representable in finite binary digits:
$ perl -e 'printf("%.20f\n%.20f\n", 2.47, 0.0247);'
2.47000000000000019540
0.02469999999999999973
hence ...
$ perl -e 'printf("%.20f\n%.20f\n", 2.47 / 100, 0.0247);'
0.02470000000000000320
0.02469999999999999973
> sprintf("%.1f", 18500 * c); # => 457.0 (NOT on FreeBSD)
> sprintf("%.1f", 18500 * 0.0247); # => 456.9
$ perl -e 'printf("%.20f\n%.20f\n", 18500*(2.47/100), 18500*0.0247);'
456.95000000000004547474
456.94999999999998863132
$ perl -e 'printf("%.1f\n%.1f\n", 18500*(2.47/100), 18500*0.0247);'
457.0
456.9
> FreeBSD gives 456.9 for both sprintfs, I was able to reproduce it on a
> fresh FreeBSD 6.3 install with the perl binary package, and from a
> compiled binary.
Maybe printing the intermediate results to more digits (as above) would
shed some light?
>
> On Linux perl 5.8.8 gives 457.0, and I get that answer on everything
> else I tried (ruby and python on Linux and FreeBSD). I tried using
> each of the methods Math::Round, but that is different from sprintf on
> Linux, and that is the behavior I was trying to get. Is anybody aware
> of something like an unusual CFLAG that might be getting passed when
> perl is compiled on FreeBSD?
Not I, but I'd guess there is something interesting to see in
perl -V
on your BSD and Linux systems.
------------------------------
Date: Thu, 24 Jan 2008 07:22:10 -0800 (PST)
From: smallpond <smallpond@juno.com>
Subject: Re: The Way to Paradise is Perl
Message-Id: <3ea165fd-a2f4-40e9-91e0-9d0feccc418b@z17g2000hsg.googlegroups.com>
On Jan 24, 4:10 am, abdo911 <jipksa...@gmail.com> wrote:
> We are all in quest of true happiness.
#!/usr/bin/perl
> Those who indulge in illegal talk ...
use warnings;
> This Hadith is quoted by AL->Bokhari.
Use single quotes to avoid unintended expansions.
>
> (May Allah Bless You All)
package Paradise;
bless $ref;
------------------------------
Date: Thu, 24 Jan 2008 10:31:23 -0800 (PST)
From: magoo <t.x.michaels@gmail.com>
Subject: Re: The Way to Paradise
Message-Id: <321824e9-607d-4429-9d6a-3f8c1ad6f53f@h11g2000prf.googlegroups.com>
On Jan 24, 3:10 am, abdo911 <jipksa...@gmail.com> wrote:
> We are all in quest of true happiness. In this world, the idea of
> true/perfect happiness is not feasible because this world is
> inevitably doomed to total annihilation. True happiness is found only
> in dwelling upon Paradise, and enjoying its blessings. However, none
> would enter Paradise except the purified (those who are void of sins,
> void of an atom of grudge or malignance). Since Paradise is created
> only for the purified/pious, those who have evil looks (looking
> lustfully at strange women, and vice versa), who envy others, treat
> their fellowmen badly, hate mankind, or backbite cannot enter
> Paradise. To conclude, none can enter Paradise unless totally
> purified (sin-free).
>
blah, blah, blah,
What the heck is wrong with "looking lustfully at strange women, and
vice versa"?
------------------------------
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 1229
***************************************
