[30047] in Perl-Users-Digest
Perl-Users Digest, Issue: 1290 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 19 14:09:46 2008
Date: Tue, 19 Feb 2008 11:09:09 -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 Tue, 19 Feb 2008 Volume: 11 Number: 1290
Today's topics:
Re: A case with Combinations in Sets xhoster@gmail.com
Re: Number of days since 1/1/2000 <stoupa@practisoft.cz>
Re: Number of days since 1/1/2000 <glex_no-spam@qwest-spam-no.invalid>
Re: Number of days since 1/1/2000 <1usa@llenroc.ude.invalid>
Re: Number of days since 1/1/2000 <1usa@llenroc.ude.invalid>
Re: Number of days since 1/1/2000 <jurgenex@hotmail.com>
Re: Number of days since 1/1/2000 oprah.chopra@gmail.com
Re: Number of days since 1/1/2000 oprah.chopra@gmail.com
Re: Number of days since 1/1/2000 mdonn@harbornet.com
Re: Number of days since 1/1/2000 <uri@stemsystems.com>
Re: Number of days since 1/1/2000 <uri@stemsystems.com>
Re: Number of days since 1/1/2000 <jurgenex@hotmail.com>
Re: Number of days since 1/1/2000 <1usa@llenroc.ude.invalid>
perl data structure <Benson.Hoi@googlemail.com>
Re: perl data structure <1usa@llenroc.ude.invalid>
regexp for accented characters <stoupa@practisoft.cz>
Re: Regular Expression to Replace UPPER Case Text with <jurgenex@hotmail.com>
Re: Regular Expression to Replace UPPER Case Text with <cwilbur@chromatico.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 19 Feb 2008 15:46:10 GMT
From: xhoster@gmail.com
Subject: Re: A case with Combinations in Sets
Message-Id: <20080219104611.879$QA@newsreader.com>
"anirbid.banerjee@gmail.com" <anirbid.banerjee@gmail.com> wrote:
> Hi,
>
> I have two Sets A and B with N DISTINCT elements each. Both A and B
> are related to each other so that B contains complement of A. For eg.A
> = {a, b, c} , B = {a*, b* c*}. I would need a perl script to generate
> all possible combinations between A and B satisfying the following
> conditions:
Since set B is completely and readily determined by set A, there is really
no point in actually having it. Just let it be implied by A.
> a) The number of elements in the Combined set n(C) = N.
> b) None of the combination should contain both an element and its
> complement : i.e. {a, a*, b}, {b,c, c*} are invalid combinations.
> c) There should be exactly 2^N combinations.
So take all numbers from 0 to 2^N and map each bit-position to one of the
elements in A. Call the ones the elements and the zeros the complements to
the elements.
$n=6;
foreach (0..2**$n-1) {
print sprintf "%0${n}b", $_ ;
};
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: Tue, 19 Feb 2008 17:11:38 +0100
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: Re: Number of days since 1/1/2000
Message-Id: <fpf0d8$2chv$1@ns.felk.cvut.cz>
Randal L. Schwartz wrote:
>>>>>> "oprah" == oprah chopra <oprah.chopra@gmail.com> writes:
>
> oprah> One problem with Date::Manip is it is not a standard module
> and not oprah> available on some of the servers I run the code on.
> Since my code is oprah> alrady 100+kb long, I would think requireinf
> another few hundred kb oprah> would be overkill for something I can
> do in one subroutine?
>
> If you are not using Perl in an environment where you can install
> additional modules from the CPAN, you are missing out on at least
> half of what Perl has to offer.
>
> If an ISP says "we support Perl" and then doesn't give you a way to
> install modules in this day and age, I will accuse them of being
> unethical as a business.
>
You are right but many cheap hosting (about $3.99 per month) "support" Perl
but not allow to install additional modules. Some hostings install modules by
request on tech.support but some not.
What you think about my way to "install" modules?
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)
Please reply to <petr AT practisoft DOT cz>
------------------------------
Date: Tue, 19 Feb 2008 11:05:25 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Number of days since 1/1/2000
Message-Id: <47bb0c55$0$10302$815e3792@news.qwest.net>
Gunnar Hjalmarsson wrote:
> J. Gleixner wrote:
>> oprah.chopra@gmail.com wrote:
>>> I am using the following subroutine to calculate the number of days
>>> since 1/1/2000 . Is there any possible bug in it? I know I can use
>>> Date::Manip but it will slow down my program which is around 100 kb
>>> long.
>>
>> It's doubtful that using Date::Manip would slow it down much, if at
>> all. So what if using it added .001 second to the run time?
>
> http://search.cpan.org/perldoc?Date%3A%3AManip#SHOULD_I_USE_DATE::MANIP
>
Interesting. I had assumed that the OP would be making one or very
few calls and while D::M is big and slow one call really would not
have amounted to much time.
Also, I got a good laugh about the reference to the number of
bytes, like that magically equates to how much time something
takes to run.
My program is 12 bytes long, but it takes 1 hour to run and
I don't want to use Date::Manip, which will slow it down even
more... Here is my script:
sleep 3600;
:-)
------------------------------
Date: Tue, 19 Feb 2008 17:39:53 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Number of days since 1/1/2000
Message-Id: <Xns9A4980CEF904Aasu1cornelledu@127.0.0.1>
"jl_post@hotmail.com" <jl_post@hotmail.com> wrote in news:3c95d54e-8ad2-
4434-aaa0-30db5bad2ec4@d21g2000prf.googlegroups.com:
> On Feb 18, 1:22 pm, oprah.cho...@gmail.com wrote:
>>
>> One problem with Date::Manip is it is not a standard module and not
>> available on some of the servers I run the code on.
>
>
> I've had similar problems. I've often had to write Perl scripts
> for customers who either don't have access to CPAN or are forbidden to
> install additional packages (outside of the Perl script I write). As
> a result, I tend to prefer solutions that can be implemented with
> standard modules.
We have been through this a few times in the past, IIRC.
Just copy and paste the code for the module in your script.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.rehabitation.com/clpmisc.shtml>
------------------------------
Date: Tue, 19 Feb 2008 17:46:16 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Number of days since 1/1/2000
Message-Id: <Xns9A4981E4083Fasu1cornelledu@127.0.0.1>
oprah.chopra@gmail.com wrote in news:d6a7945f-8a2b-4109-8e01-
e74118d4fe9c@d21g2000prf.googlegroups.com:
> J. Gleixner wrote:
>> Whenever I see that, instead of sprintf, I say to myself,
>> "Inexperienced coder."
>
> Well I have been coding perl for seven years and and count on one
> hand the number of times I used sprintf. print is simple , why make
> code more unreadable by unncessarily cluttering it with esoteric
> functions? At least that has always been my philosophy. Yes there may
> be more 'technically correct' ways to do things, but I am running a
> business and have to look at the bigger picture . If I hire a new
> perl programmer, will they know the difference between print and
> sprintf?
>
> I can tell you have a PhD, because you suffer from the classic
> ostrich mentality, i.e head is stuck in the ground lookiing at
> details, while you can't see the train coming..
For some reason, your thought process made me think of pots and kettles.
To recap, the relevant part of the thread was:
>>> sub calc_days {
>>>
>>> my ( $mday, $mon, $year ) = ( localtime(time) )[3,4,5];
>>> if ($mday < 10) { $mday = "0$mday"; }
>>
>> Whenever I see that, instead of sprintf, I say to myself,
>> "Inexperienced coder."
Jurgen was being polite. Whenever I see code like that, I think to me
myself, "oh, I have to deal with another stupid code monkey!"
There is no excuse for "0$mday".
There is also no excuse for refusing to learn and insisting on using the
inexcusable construct.
Bye bye ...
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.rehabitation.com/clpmisc.shtml>
------------------------------
Date: Tue, 19 Feb 2008 17:57:43 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <0q5mr3ldsonjsmf1ctuhehtgq35ggi7bnp@4ax.com>
oprah.chopra@gmail.com wrote:
>I am using the following subroutine to calculate the number of days
>since 1/1/2000 . Is there any possible bug in it? I know I can use
>Date::Manip but it will slow down my program which is around 100 kb
>long.
>
>use strict;
>use warnings;
>
>my $days = &calc_days;
>
>print "The number of days since 1/1/2000 is $days\n";
>[very round-about code snipped]
Why not simply get the current time() and 1/1/2000 in seconds since the
epoch and divide the difference between them by 60*60*24?
This will be ignore leap seconds, but I doubt that makes any difference to
whatever you are computing.
jue
------------------------------
Date: Tue, 19 Feb 2008 10:05:47 -0800 (PST)
From: oprah.chopra@gmail.com
Subject: Re: Number of days since 1/1/2000
Message-Id: <5c9de261-ee07-47b1-a3b3-b927818405bf@60g2000hsy.googlegroups.com>
A. Sinan Unur wrote:
> Jurgen was being polite. Whenever I see code like that, I think to
> me myself, "oh, I have to deal with another stupid code monkey!"
> There is no excuse for "0$mday".
>
> There is also no excuse for refusing to learn and insisting on
> using the inexcusable construct.
Let me guess, you have a PhD too? You are all the same, unable to see
the big picture. Instead they focus on the tiny flaws of a system to
convince people that the entire system is flawed. I suppose such
behaviour is fine in the research lab, but in the real world it
creates unncessary red tape to get things done.
It's the old, 'I know better than you' syndrome. we are all at risk
of it, even us uneducated mob. Indeed the more papers one has to
prove how much one knows, the bigger the chance that this syndrome
will strike.
You will always argue they are more accurate while failing to
understand the problems at hand in the real world.
Take this as some 'friendly' humble-pie. You will be surprised how
far little tact will take you.
------------------------------
Date: Tue, 19 Feb 2008 10:19:48 -0800 (PST)
From: oprah.chopra@gmail.com
Subject: Re: Number of days since 1/1/2000
Message-Id: <6d84ef25-8ae8-42bb-8dfd-0f2b675c8265@u69g2000hse.googlegroups.com>
J=FCrgen Exner wrote:
> Why not simply get the current time() and 1/1/2000 in seconds since
the > epoch and divide the difference between them by 60*60*24?
> This will be ignore leap seconds, but I doubt that makes any
difference to > whatever you are computing.
>
How many PhD's did it take to come up with this solution?
------------------------------
Date: Tue, 19 Feb 2008 10:25:37 -0800
From: mdonn@harbornet.com
Subject: Re: Number of days since 1/1/2000
Message-Id: <je7mr3lb2t4i95h9esljtdmn467j9ai1dt@4ax.com>
On Tue, 19 Feb 2008 00:28:45 GMT, Uri Guttman <uri@stemsystems.com>
wrote:
>>>>>> "oc" == oprah chopra <oprah.chopra@gmail.com> writes:
>
> oc> since 1/1/2000 . Is there any possible bug in it? I know I can use
> oc> Date::Manip but it will slow down my program which is around 100 kb
> oc> long.
>
>and how much time have you wasted on your code?
>
> oc> while ($MTH <= ($mon + 1) && $YRW == $year || $MTH <= 12 && $YRW <
> oc> $year) {
>
> oc> ## test for leap year
> oc> my $yeardiv = ($YRW / 4);
> oc> my $yearint = int($yeardiv);
> oc> my $yeardiv1 = ($YRW / 100);
>
>year 2000 WAS a leap year and it is divisible by 100
>
> oc> my $yearint1 = int($yeardiv1);
> oc> if ($yeardiv eq $yearint && $yeardiv1 ne $yearint1) {
> oc> $TM[1] = 29;
> oc> }else { $TM[1] = 28;
> oc> }
>
>do you do that for all the leap years in a period of dates? i don't see
>an array of days for each year.
>
> oc> if ($MTH == ($mon + 1) && $YRW == $year) {
>
> oc> while (++$TDD <= $mday) { $total_days += 1; }
>
> oc> }else{
> oc> while (++$TDD <= $TM[$MTH - 1]) { $total_days += 1; }
>
>that looks like nonsense code. counting up for each date? ever heard of
>addition or subtraction?
>
>use a module.
>
>uri
Not being a high-power programmer like you folks, I did it this way,
which should work until 2100.
use strict;
use warnings;
my ($y, $yd) = (localtime(time))[5,7];
my $yrs = $y - 101;
my $ld = int ($yrs+1)/4;
my $dif = 365 * $yrs + $ld + $yd;
$dif++ if $y%4 == 0 && $yd > 59;
print "$dif\n";
KISS!!
------------------------------
Date: Tue, 19 Feb 2008 18:27:09 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <x7prusby4i.fsf@mail.sysarch.com>
>>>>> "oc" == oprah chopra <oprah.chopra@gmail.com> writes:
oc> A. Sinan Unur wrote:
>> Jurgen was being polite. Whenever I see code like that, I think to
>> me myself, "oh, I have to deal with another stupid code monkey!"
>> There is no excuse for "0$mday".
>>
>> There is also no excuse for refusing to learn and insisting on
>> using the inexcusable construct.
oc> Let me guess, you have a PhD too? You are all the same, unable to see
oc> the big picture. Instead they focus on the tiny flaws of a system to
oc> convince people that the entire system is flawed. I suppose such
oc> behaviour is fine in the research lab, but in the real world it
oc> creates unncessary red tape to get things done.
let me guess, you are a self taught perl coder? you exhibit all the
symptoms, poor style, no interest in learning more perl, not listening
to experienced coders. we see it all the time. and your 'real world'
experience is probably very provincial. try reading some cpan code which
is truly real world as much of it is used all over the world.
oc> It's the old, 'I know better than you' syndrome. we are all at risk
oc> of it, even us uneducated mob. Indeed the more papers one has to
oc> prove how much one knows, the bigger the chance that this syndrome
oc> will strike.
so you admit you are uneducated. must be supporter of shrub then!
oc> You will always argue they are more accurate while failing to
oc> understand the problems at hand in the real world.
you have no clue about the real world no matter how much you claim you
do. bad code is rampant in the real world. that doesn't make it
right. and "0$mday" is bad code as it does more work than sprintf does.
oc> Take this as some 'friendly' humble-pie. You will be surprised how
oc> far little tact will take you.
and you need to learn how to learn. too bad for you. as i said before, i
make a living cleaning up messes like your code. too bad you won't ever
hire me or learn from anyone better than you. i have pity on you, your
projects and your bosses. they all will fail over time.
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: Tue, 19 Feb 2008 18:27:36 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <x7lk5gby3r.fsf@mail.sysarch.com>
>>>>> "oc" == oprah chopra <oprah.chopra@gmail.com> writes:
oc> Jürgen Exner wrote:
>> Why not simply get the current time() and 1/1/2000 in seconds since
oc> the > epoch and divide the difference between them by 60*60*24?
>> This will be ignore leap seconds, but I doubt that makes any
oc> difference to > whatever you are computing.
>>
oc> How many PhD's did it take to come up with this solution?
did you graduate from kindergarten with honors?
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: Tue, 19 Feb 2008 18:46:56 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Number of days since 1/1/2000
Message-Id: <7t8mr31cdiph76a5bk27o3puhf3sok9cpt@4ax.com>
oprah.chopra@gmail.com wrote:
>Jürgen Exner wrote:
>
>> Why not simply get the current time() and 1/1/2000 in seconds since
>the > epoch and divide the difference between them by 60*60*24?
>> This will be ignore leap seconds, but I doubt that makes any
>difference to > whatever you are computing.
>>
>
>How many PhD's did it take to come up with this solution?
???
You see me mystified. Mind to explain how your remark relates to my comment?
jue
------------------------------
Date: Tue, 19 Feb 2008 18:48:02 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: Number of days since 1/1/2000
Message-Id: <Xns9A498C5C95729asu1cornelledu@127.0.0.1>
mdonn@harbornet.com wrote in news:je7mr3lb2t4i95h9esljtdmn467j9ai1dt@
4ax.com:
> Not being a high-power programmer like you folks, I did it this way,
> which should work until 2100.
>
> use strict;
> use warnings;
> my ($y, $yd) = (localtime(time))[5,7];
> my $yrs = $y - 101;
> my $ld = int ($yrs+1)/4;
> my $dif = 365 * $yrs + $ld + $yd;
> $dif++ if $y%4 == 0 && $yd > 59;
> print "$dif\n";
> KISS!!
Simple & correct is better than simple & wrong.
Compare your solution to the truly simple and elegant solution posted by
Gunnar elsethread:
use strict;
use warnings;
my %methods = (
prima_donna_method => \&prima_donna_method,
simple_method => \&simple_method,
);
for my $method ( sort keys %methods ) {
printf "%20s: %d\n", $method, $methods{ $method }->();
}
sub prima_donna_method {
my ($y, $yd) = (localtime(time))[5,7];
my $yrs = $y - 101;
my $ld = int ($yrs+1)/4;
my $dif = 365 * $yrs + $ld + $yd;
$dif++ if $y%4 == 0 && $yd > 59;
return $dif;
}
use Time::Local;
sub simple_method {
my $start = timelocal 0, 0, 0, 1, 0, 2000;
my $today = timelocal 0, 0, 0, (localtime)[3..5];
return sprintf '%.0f', ($today - $start) / 86400;
}
__END__
C:\Home\test> tt0.pl
prima_donna_method: 2606
simple_method: 2971
Ooops. You are off by one year!
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.rehabitation.com/clpmisc.shtml>
------------------------------
Date: Tue, 19 Feb 2008 09:15:35 -0800 (PST)
From: BH <Benson.Hoi@googlemail.com>
Subject: perl data structure
Message-Id: <6ea19315-2409-4fe4-9d34-7dd3346329d7@41g2000hsc.googlegroups.com>
Hi,
I am reading in an comma separator file,
line 1: Field 1, field 2, field 3.., field n
line 2: Field 1, field 2, field 3.., field n
I would like to create a data structure to representing the whole
file.
What is an efficient and easy way to store the above such that, for a
given value for field i, I can extract an array of values for field j,
where 1<=i,j<=n? It's a bit like asking what the best way to store a
spreadsheet is.
Hash of anonymous arrays? How will the syntax be?
Thanks in advance.
Regards,
BH
------------------------------
Date: Tue, 19 Feb 2008 18:36:39 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: perl data structure
Message-Id: <Xns9A498A6EC31AEasu1cornelledu@127.0.0.1>
BH <Benson.Hoi@googlemail.com> wrote in news:6ea19315-2409-4fe4-9d34-
7dd3346329d7@41g2000hsc.googlegroups.com:
> Hi,
>
> I am reading in an comma separator file,
>
> line 1: Field 1, field 2, field 3.., field n
> line 2: Field 1, field 2, field 3.., field n
>
> I would like to create a data structure to representing the whole
> file.
>
> What is an efficient and easy way to store the above such that, for a
> given value for field i, I can extract an array of values for field j,
> where 1<=i,j<=n? It's a bit like asking what the best way to store a
> spreadsheet is.
>
> Hash of anonymous arrays? How will the syntax be?
First off, have you tried DBD-CSV?
http://search.cpan.org/~jzucker/DBD-CSV-0.22/lib/DBD/CSV.pm
This has the advantage that your code can keep on working when the data
are moved to a real database later on.
* How large is the data matrix?
* How large is the typical file?
* How large is the typical result set?
If the file is smallish (dunno, maybe fewer than 10,000 lines with say
10 fields each), the contents static and simple, the queries really as
simple as you make them out to be the obvious solution would be the way
to go.
Obvious solution follows. Generalize as required.
#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;
my @data;
while ( my $obs = <DATA> ) {
$obs =~ s/^\s+//;
$obs =~ s/\s+$//;
next unless length $obs;
push @data, [ split /\s+/, $obs ];
}
print Dumper vlookup( \@data, 2, 50, 3 );
print Dumper vlookup( \@data, 0, 100, 0);
print Dumper vlookup( \@data, 3, 0, 3);
print Dumper vlookup( \@data, 3, 0, 1);
sub vlookup {
my ( $data, $key_col, $key_val, $lookup_col ) = @_;
my @retlist;
for my $obs ( @$data ) {
if ( $obs->[ $key_col ] == $key_val ) {
push @retlist, $obs->[ $lookup_col ];
}
}
return \@retlist;
}
__DATA__
70 140 45 85
190 150 40 30
80 40 45 30
110 20 30 5
50 140 70 95
50 80 60 65
170 150 45 40
150 0 30 0
10 30 50 60
30 130 70 100
110 160 75 75
60 120 80 80
170 130 33 30
90 140 75 75
120 90 35 35
130 40 5 5
50 170 100 100
120 30 5 5
90 170 90 90
190 150 30 30
60 20 30 30
130 150 70 60
0 20 60 60
40 120 70 90
70 160 100 95
180 150 20 35
110 70 40 30
140 140 50 50
170 30 0 0
70 130 60 80
80 20 20 20
100 130 65 65
190 20 0 0
110 30 0 10
180 70 0 0
180 50 0 0
40 120 45 90
60 70 55 55
140 160 60 60
60 140 90 90
150 80 20 15
40 10 30 35
160 100 20 20
80 170 90 95
150 90 30 20
90 70 40 40
40 0 30 30
170 50 0 0
110 180 80 85
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(remove .invalid and reverse each component for email address)
clpmisc guidelines: <URL:http://www.rehabitation.com/clpmisc.shtml>
------------------------------
Date: Tue, 19 Feb 2008 17:21:20 +0100
From: "Petr Vileta" <stoupa@practisoft.cz>
Subject: regexp for accented characters
Message-Id: <fpf0d8$2chv$2@ns.felk.cvut.cz>
I have string in cp1250 codepage and I need to use regexp to extract part of
string. All is simple but I want to run the same script under Perl 5.6.1 and
5.8. And here is the problem.
Example 1
-------------
require utf8 if($] > 5.006001);
$string = "Telefón: 123456789\nFax: 123456789";
$string =~ m/Telef.n:\s+(\d+)\s+Fax:\s+(\d+)/
my ($phone,$fax) = ($1,$2);
This work for Perl 5.6.1 but fail for Perl 5.8. For Perl 5.8 I must write
regexp as
$string =~ m/Telef.+?n:\s+(\d+)\s+Fax:\s+(\d+)/
This modified regexp work for 5.6.1 too but is not clear because possible can
acept string "Telefóon..." too.
Please can anybody describe me how regexp works under Perl 5.8 and "use utf8"
?
--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your mail from
another non-spammer site please.)
Please reply to <petr AT practisoft DOT cz>
------------------------------
Date: Tue, 19 Feb 2008 18:08:40 GMT
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Regular Expression to Replace UPPER Case Text with lower case text
Message-Id: <bb6mr39tge0dfnr5api1u2u5m9kqgodkmd@4ax.com>
RK_78 <riad.kaced@gmail.com> wrote:
>On Feb 18, 2:42 am, penny <kevin.pe...@gmail.com> wrote:
>> Is there a way in Regular Expressions to convert a string that is all
>> in upper case - and replace it with it's lower case equivalent?
>
> $line =~ tr/A-Z/a-z/;
>
>The key point here is the tr/// transliteration operator.
How does A-Z or the tr/// expression for that matter handle non-English
letters?
What about upper case letters that don't have a corresponding lower case
letter? I don't know if such a letter exists. It does for the other
direction, e.g. the Geman sharp s (ß) which is capitalized as double "SS".
Example: Straße ==> STRASSE
Similar examples exist in other languages
I cannot imagine that this tr/// expression will handle these correctly.
jue
------------------------------
Date: 19 Feb 2008 13:35:42 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Regular Expression to Replace UPPER Case Text with lower case text
Message-Id: <8763wk4ww1.fsf@mithril.chromatico.net>
>>>>> "cc" == ccc31807 <cartercc@gmail.com> writes:
cc> Using Perl for web apps is controversial to say the least, and
cc> I can sympathize with your little joke. You DO get laughed at
cc> if you use Perl, and that's not a joke. However, Perl has some
cc> advantages over these other technologies, as well as some
cc> disadvantages.
Over the past 15 years, I've been involved in a variety of online
endeavors, including a significant amount of web software development.
The notion that using Perl for web apps is *controversial* is,
frankly, ludicrous.
What it boils down to is this: if you have competent developers who
choose the language and environment they work in on their technical
merits, your web application will work well. If you have incompetent
developers, or you choose the language and environment based on
marketing or managers' perceptions rather than technical merits, your
web application will not work well.
I have a whole series of anecdotes to illustrate this, but I'll leave
you with punch lines.
"We can't market anything based on Linux, who's heard of Linux? We'll
build it on Microsoft SQL Server instead." -- Project was 200% over
schedule and 300% over budget before the Microsoft plans were scrapped.
"We can't use Ruby on Rails for this. Who takes something with a name
like that seriously?" -- Company is foundering, after spending ~ $1
million patching a broken system instead of replacing it, because the
quoted manager was too risk averse to try an agile framework and
didn't have the budget to hire 20 Java monkeys for the approved
corporate approach.
"Perl can't do this, so I've given it to the Java consultants." --
The team of a dozen Java consultants (who were not so much
*incompetent* as *self-interested*, and were thus more interested in
stretching out the contract as long as possible) took 6 months to
deliver the specified application, which was irrelevant by then as I
had taken a week of downtime to solve that particular problem and four
others.
The person who laughs at you for using Perl is the person you will
leave in your dust, assuming you don't heed his advice.
cc> I understand that this is OT, but I'm just wondering ... Is
cc> there any good reason I shouldn't learn how to develop web
cc> apps in Lisp? I'm just now taking my first baby steps in
cc> constructing Lisp scripts that spit out HTML with data drawn
cc> from data stores, and as far as I can tell, Lisp potentially
cc> has some strengths that Perl does not have (or CF, .NET, JSP,
cc> Python, or any of the others.)
From a technical point of view, there's no reason to avoid Lisp in web
development. From a practical point of view, if you ever intend to
hand this code off to someone else or to work with someone else,
you'll need to find a Lisp enthusiast.
And any theoretical strengths Lisp might have once had have long since
been stolen by other languages; the practical ones, well, let's just
say that the common criticism of Perl, that it's possible to write
write-only code, is multiplied a thousandfold when you start dealing
with Lisp's macro system. And then, on top of that, you have the
rabid Lisp fanbase -- their own worst enemy.
But hey, good luck with that.
Charlton
--
Charlton Wilbur
cwilbur@chromatico.net
------------------------------
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 1290
***************************************