[24714] in Perl-Users-Digest
Perl-Users Digest, Issue: 6869 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 16 09:06:07 2004
Date: Mon, 16 Aug 2004 06:05:08 -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 Mon, 16 Aug 2004 Volume: 10 Number: 6869
Today's topics:
Re: Counting text area <john.sharpe@nospambtinternet.co.uk>
Earthquake forecasting program Aug. 16, 2004 <edgrsprj@ix.netcom.com>
Extract same text from file. (Ryan Keeling)
Re: Extract same text from file. <josef.moellers@fujitsu-siemens.com>
Re: Extract same text from file. <tore@aursand.no>
Re: Extract same text from file. <matrix_calling@yahoo.dot.com>
Re: Extract same text from file. <matrix_calling@yahoo.dot.com>
Re: Good way to un-chomp an array <matrix_calling@yahoo.dot.com>
Re: Good way to un-chomp an array <eam@7ka.mipt.ru>
Re: Good way to un-chomp an array <sholden@flexal.cs.usyd.edu.au>
has anybody write bioinformatics programme with perl <hugoyg@163.com>
Re: has anybody write bioinformatics programme with per (Anno Siegel)
IPC::Shareable exceptionally slow on large segs <admin@asarian-host.net>
Re: IPC::Shareable exceptionally slow on large segs (Anno Siegel)
Placeholder in an sql query (dn_perl@hotmail.com)
Re: Placeholder in an sql query <tore@aursand.no>
Regexp: substituting \n with <br /> except in certain p <mr@sandman.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 16 Aug 2004 07:44:11 +0000 (UTC)
From: John S <john.sharpe@nospambtinternet.co.uk>
Subject: Re: Counting text area
Message-Id: <Xns954758ED4A36Bjohnsharpenospambtin@217.32.252.50>
Gunnar Hjalmarsson <noreply@gunnar.cc> wrote in news:2o9scnF8db61U1@uni-
berlin.de:
> John S wrote:
>> Tore Aursand wrote:
>>> On Fri, 13 Aug 2004 10:26:56 +0200, Davidd Sargent wrote:
>>>
>>>> What I want is on the results page for it to count the number of
>>>> subdomains (each domain will be seperated by \n (a newline)).
>>>
>>> 1. Read the FORM data by using CGI.pm.
>>> 2. Get the lines by splitting on "\n"
>>> 3. Process each line, discard those which doesn't meet your "subdomain
>>> requirements".
>>> 4. Present the result for the user.
>>
>> textarea comes back with \r as well.
>
> Only on Windows (of course), and not if you use a library that takes
> care of it, such as CGI.pm (as Tore suggested) or cgi-lib.pl.
> Otherwise you can binmode STDOUT to prevent the \r pecularity.
>
When this is run from an Apache server:
----------------------------------------------------
#!/usr/bin/perl -T
use strict;
use warnings;
use CGI;
my $q = new CGI;
my $fe = $q->param( 'friend_email' ); # text area
my $msg;
if ( $fe =~ /\r/ ){
$msg = 'found \r'
}
else{
$msg = '\r not found'
}
print $q -> header,
$q -> start_html( -title=>'test' ),
$q -> p( 'testing text area ),
$q -> p( $fe ),
$q -> p( $msg ),
$q -> end_html;
-----------------------------------------------------------
I get 'found \r'.
Normally it doesn't matter until, as in this case, it is a list of emails
for example. It took me ages to track it down.
Used IE 6 browser on XP.
------------------------------
Date: Mon, 16 Aug 2004 11:53:32 GMT
From: "edgrsprj" <edgrsprj@ix.netcom.com>
Subject: Earthquake forecasting program Aug. 16, 2004
Message-Id: <0f1Uc.23551$nx2.17009@newsread2.news.atl.earthlink.net>
August 16, 2004 Posted to sci.geo.earthquakes and other Newsgroups
Newsgroup Readers: I recommend that you send copies of this report to any
government officials and researchers that you know who are interested in
earthquake forecasting science.
The information in this report represents expressions of personal opinion.
This is an introductory report regarding a Perl language earthquake
forecasting computer program which is now generating good results. I
personally believe that the program has the potential to enable us to
accurately forecast the approach of a reasonable percentage of the
destructive earthquakes which are occurring around the world. This report
will explain how the program works.
That program is presently already fully operational and in use. But
for it to be effectively used by governments etc. around the world it will
probably be necessary for some organization to "fine tune" the program code
and the output data format and take charge of circulating the program and
instructing government personnel regarding how to use it.
Note: I don't have time to get into a lengthy discussion regarding this
subject matter. If you post a response which asks questions which require
lengthy answers, which are too difficult to answer, or if you ask too many
questions I am not going to be able to respond to your note. Also, it might
take me a few days to respond to any questions.
This subject matter involves earthquakes, geophysics, celestial mechanics,
and Perl language computer programming. That is why this report has been
posted to a number of Newsgroups. If you wish to respond in just one of
them I would recommend sci.geo.earthquakes.
Present Theories:
*** Earthquakes occur when fault zones collect enough strain energy as the
result of tectonic plate movements etc. that their rock layers fracture.
*** The actual times when many earthquakes occur and when certain types of
fault zone process related electromagnetic energy field fluctuations (EM
signals) are being generated are controlled by forces which are directly
and/or indirectly related to the positions of the sun and the moon in the
sky. The sun and moon gravities are controlling those forces. They add
enough additional strain energy to the fault zone to trigger the earthquake.
*** A given fault zone will tend to fracture when those forces bend,
stretch, and compress its rock layers in certain directions. Years,
decades, and even centuries may pass before the fault zone has stored enough
energy for another earthquake to occur and it is once again bent etc. in
such a manner that one is triggered. But this process is sufficiently
repetitive and reliable that it can be used to forecast earthquakes.
A computer program can be used to compare the times when those EM signals
are generated with the times when earthquakes occurred in the past. And
when matches are found between the signals and past earthquakes then that
can serve as an indicator that a new earthquake is about to occur in the
general area where the past one occurred.
With the program I am presently using:
About 500 EM signals are detected each year. They last from 0.25 to 20
seconds. That short duration time can make it a little difficult to detect
them. But it makes them ideal for use with this type of computer program.
For each data point, about 3 months worth of signals, usually between 100
and 200, are compared one by one with the roughly 25,000 earthquakes I have
in my database. They occurred during the years 1990 through the present.
To present a somewhat simplified picture, when signal # 1 is compared with
the first earthquake in the database the earthquake is given a rating on a 0
to 100 scale for how well the signal matched the earthquake. Then signal #
1 is compared with earthquake # 2.
When all of the earthquakes have been checked the same steps are taken for
signal # 2. And when those checks are finished the results of the first
series of tests are added to the results of the second series of tests.
This then continues for each of the signals.
When all of the comparisons are done the result is a list of 25,000
earthquakes which has a single probability rating for each earthquake which
shows how it matched all of the signals combined.
Some of those 150 or so signals will have preferentially matched one
earthquake. And as a result it will have a higher rating. Some will have
preferentially matched another etc.
The list is adjusted so that the earthquake which was the best match for all
of the signals (the highest results rating) is multiplied by some factor so
that it has a final rating of 100. And all of the other earthquakes are
then multiplied by that factor. They then have final ratings which range
from 0 to 100.
The next steps provide the information regarding when and where an
earthquake is going to occur.
A complete run like that takes about 30 minutes on a 700 Meg speed computer.
And that series of tests is repeated about every 3 days.
With each new test date the signals for the oldest 3 day period are removed
from the test list. And signals detected during the latest 3 day period are
added to it. So the list of signals gradually changes with time.
If an earthquake at say 122W and 36N has a final rating of:
50 on day 1
60 on day 4
80 on day 7
93 on day 10
97 on day 13
99 on day 16
That gradual increase in final ratings would then indicate that another
earthquake could be about to occur near 122W and 36N.
If and when it did occur, say on day 17, the final ratings for the 122W and
36N earthquake in the list would usually begin to go down as the warning
signals which pointed to it were gradually removed from the test signal
list.
Because some 25,000 earthquakes which occurred around the world are given
ratings with each series of tests, and because some of the signals during
that 90 day test signal period will point to one earthquake and some will
point to another, the final results list which is generated every 3 days
shows were earthquakes around the world might be about to occur.
An example for a single earthquake:
On December 22, 2003 the following destructive earthquake occurred in
California, U.S.A.
2003/12/22 19:15:56 35.71N 121.10W 7.6 6.5 CENTRAL CALIFORNIA
(NEIS data)
My data processing computer program was not fully operational until April of
2004. And so I could not use it to watch for that earthquake at the time
that it occurred. However I recently used the program to test the signals
which were detected back around then to see how well it might have done if
it had existed last December. And it generated the following data.
These were the final ratings for the following earthquake which is one of
the ones in my 25,000 earthquake data table. It was one of the
geographically closest ones to that December 22 earthquake.
1989/10/18 00:04:15 37.03N 121.88W 19.0 7.1 SAN FRANCISCO, CALIFORNIA
The dates in this list are the end dates for each 3 month test signal
period. The Pa: numbers represent final ratings for that San Francisco
earthquake when it was compared with all of the 25,000 earthquakes in the
database. The Pd: numbers represent final rating for that earthquake when
it was compared with only those earthquakes in the database which produced
fatalities.
Test Date Pa: Pd:
03/10/30 71: 75
03/11/25 87: 89:
03/12/07 92: 94:
03/12/15 91: 96:
03/12/22 93: 97:
03/12/25 90: 95:
03/12/30 91: 94:
04/01/15 91: 91:
04/02/19 74: 81:
04/03/20 65: 69:
04/04/13 72: 77:
04/05/18 66: 67:
Both the Pa: and Pd: final results numbers peaked beginning around December
7, continuing through December 30. And if that computer program had been
operational back in December, and had government officials here in the U.S.
and earthquake forecasters seen those numbers reach a peak for that San
Francisco earthquake which occurred at 37N and 122W, then they might have
been able to check that general area for other signs of an approaching
earthquake such as large, fresh cracks in building foundations, radon gas
releases, abrupt changes in ground water table levels etc. And perhaps it
would have been possible to determine that the December 22 earthquake which
occurred at 36N and 121W was getting ready to occur.
PRESENT STATUS OF THIS FORECASTING PROGRAM
This is not a futuristic computer program which will become available 10
years from now. It is already fully operational. And several other people
that I know of have it running on their computers at this time. Signal data
are being collected each day. And for the past few months I have been
storing final results data at one of my Web sites for examination and use by
government officials etc. around the world. Anyone who can run a Perl
language program on his or her computer can confirm the results himself or
herself.
The computer program and its enormous database files were also until
recently available as free downloads from my Web site. However, that site
allows just a limited number of visits each month (bandwidth allowance).
And a few weeks ago it had become so popular that the monthly bandwidth was
exceeded and the site temporarily shut down. When that happened I removed
most of the large download files etc. from the site so that it would not
crash immediately after it started running again. Additionally, I am in the
process of producing a new final results Web page which has a format which
makes it easier to interpret the data.
I recently received the formal U.S. copyright ownership papers for one
version of that Perl language data processing computer program. And, if I
do not receive more requests than I can respond to I can send people e-mail
copies of a version which is presently several months old but which produces
the same type of data as the latest version. The final results data are
simply formatted a little differently with the latest version. To run the
program you need to first install a Perl computer language compiler on your
computer. That takes just a few minutes. The following Web page contains
instructions for how to obtain a free copy of a Perl compiler:
http://www.freewebz.com/eq-forecasting/Perl.html
The following file contains a copy of my earthquake forecasting Perl
program. However that file does not contain the very large support files
which are presently needed to run it.
http://www.freewebz.com/eq-forecasting/311.zip
That Perl program was designed to run with Windows XP. It will also run
with Windows 98. To get it to run with other operating systems such as UNIX
it is probably necessary to change some of its internal statements. I
myself would not know what changes needed to be made. However, this is a
text program. And such changes should be easy to make with any text editor
if you are familiar with Perl language computer programming.
The computer program works quite well with the EM signal data that I myself
am collecting. It remains to be seen how well it will work with other types
of data including EM signal data being collected by other people around the
world.
The next planned step is to create a new version of the final results data
Web page and store it at my Web site for demonstration purposes. That might
take a few days or perhaps as much as a few weeks. And at that time a
program update note will probably be posted to the Newsgroups.
Longer range, additional data need to be generated and evaluated. The Perl
program should be rewritten using a more conventional programming format.
It presently simply consists of a group of subroutines which have been
linked together. Perhaps a different programming language should be used.
The program contains scores of software settings which can be optimized for
better performance. More sophisticated data processing routines should be
added. And geophysicists should try to determine why the program actually
works. It relies on an unusual geophysical theory model for how earthquakes
are being triggered. And although the computer program produces good data
indicating that the theory model has some value, the actual earthquake
triggering mechanism is not yet understood.
This is not a funded research effort. It is not being run in connection
with any formal research group. And I myself have only limited amounts of
time to devote to the effort. Progress is therefore not as rapid as I would
like. But it is being slowly made.
This first report was intended to simply let people know that the earthquake
forecasting computer program which was described here now exists and to
provide a preliminary explanation of how it works.
COMMENT: THE PERL COMPUTER LANGUAGE
Without being an expert on this subject I believe that the Perl language was
probably created in part so that people who are not professional computer
programmers could have a versatile language for use which was inexpensive
(it is actually free), widely available, well supported, powerful, and not
too difficult to learn. I would say that if that was the case then this
application demonstrates that this goal was achieved. And the development
of an effective, inexpensive, and easily used computer program for
forecasting earthquakes and doing advanced research on them would certainly
have to be considered an important application for any computer language.
------------------------------
Date: 16 Aug 2004 02:44:31 -0700
From: ryankeeling@gmail.com (Ryan Keeling)
Subject: Extract same text from file.
Message-Id: <b1d57b3e.0408160144.31cea472@posting.google.com>
Hi
I have the following text file which I want to use to populate text
files containing data only relevant to a particular project. Is it
possible for me to group similar lines together and put them in their
own text file? Such as a file containing all entries for
MS102_PCP.Implementation and another file for MS102_PCP.Support.
Any help would be greatly appreciated!
2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
2004:01:09:5:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:1.0
2004:01:20:2:04:MS102_PCP:Belfast:Charge:PCP:Standards:6.5
2004:01:19:1:04:MS102_PCP:Belfast:Charge:PCP:Standard:7.5
2004:02:03:2:06:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
2004:03:03:3:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Support:+:2.5
2004:03:26:5:13:MS102_PCP:Belfast:Charge:PCP:Support:+:7.5
2004:03:29:1:14:MS102_PCP:Belfast:Charge:PCP:Support:+:8.0
2004:03:30:2:14:MS102_PCP:Belfast:Charge:PCP:Implementation:+:8.0
2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Project-Control:+:7.5
2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:2.0
2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:0.7
Ryan
------------------------------
Date: Mon, 16 Aug 2004 11:52:36 +0200
From: Josef Moellers <josef.moellers@fujitsu-siemens.com>
Subject: Re: Extract same text from file.
Message-Id: <cfpvvb$img$1@nntp.fujitsu-siemens.com>
Ryan Keeling wrote:
> Hi=20
> I have the following text file which I want to use to populate text
> files containing data only relevant to a particular project. Is it
> possible for me to group similar lines together and put them in their
> own text file? Such as a file containing all entries for
> MS102_PCP.Implementation and another file for MS102_PCP.Support.
>=20
> Any help would be greatly appreciated!
>=20
>=20
> 2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
> 2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
> 2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
> 2004:01:09:5:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:1.0
> 2004:01:20:2:04:MS102_PCP:Belfast:Charge:PCP:Standards:6.5
> 2004:01:19:1:04:MS102_PCP:Belfast:Charge:PCP:Standard:7.5
> 2004:02:03:2:06:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
> 2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
> 2004:03:03:3:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
> 2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Support:+:2.5
> 2004:03:26:5:13:MS102_PCP:Belfast:Charge:PCP:Support:+:7.5
> 2004:03:29:1:14:MS102_PCP:Belfast:Charge:PCP:Support:+:8.0
> 2004:03:30:2:14:MS102_PCP:Belfast:Charge:PCP:Implementation:+:8.0
> 2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Project-Control:+:7.5
> 2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:2.0
> 2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:0.7
Answer to your question: yes.
Obvious counter-question: what have you tried so far and where have you=20
had problems?
Since your data is reasonably structured, I'd use split and then create=20
a filename from fields 8 and 9 to append the current line to. If the=20
data isn't too much, you can use a hash of arrays to collect the data=20
and write it out in one go.
--=20
Josef M=F6llers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize
-- T. Pratchett
------------------------------
Date: Mon, 16 Aug 2004 12:06:10 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: Extract same text from file.
Message-Id: <pan.2004.08.16.10.06.10.232279@aursand.no>
On Mon, 16 Aug 2004 02:44:31 -0700, Ryan Keeling wrote:
> I have the following text file which I want to use to populate text
> files containing data only relevant to a particular project. Is it
> possible for me to group similar lines together and put them in their
> own text file? Such as a file containing all entries for
> MS102_PCP.Implementation and another file for MS102_PCP.Support.
>
> 2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
> 2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
> 2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
> [...]
Yes, it is _very_ possible. What have you tried so far? You want to look
into 'perldoc -f split', for example.
--
Tore Aursand <tore@aursand.no>
"A teacher is never a giver of truth - he is a guide, a pointer to the
truth that each student must find for himself. A good teacher is
merely a catalyst." (Bruce Lee)
------------------------------
Date: Mon, 16 Aug 2004 15:43:35 +0530
From: Abhinav <matrix_calling@yahoo.dot.com>
Subject: Re: Extract same text from file.
Message-Id: <eU%Tc.12$bW.120@news.oracle.com>
Ryan Keeling wrote:
> Hi
> I have the following text file which I want to use to populate text
> files containing data only relevant to a particular project. Is it
> possible for me to group similar lines together and put them in their
> own text file? Such as a file containing all entries for
> MS102_PCP.Implementation and another file for MS102_PCP.Support.
>
> Any help would be greatly appreciated!
>
>
> 2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
> 2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
> 2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
> 2004:01:09:5:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:1.0
> 2004:01:20:2:04:MS102_PCP:Belfast:Charge:PCP:Standards:6.5
> 2004:01:19:1:04:MS102_PCP:Belfast:Charge:PCP:Standard:7.5
> 2004:02:03:2:06:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
> 2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
> 2004:03:03:3:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
> 2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Support:+:2.5
> 2004:03:26:5:13:MS102_PCP:Belfast:Charge:PCP:Support:+:7.5
> 2004:03:29:1:14:MS102_PCP:Belfast:Charge:PCP:Support:+:8.0
> 2004:03:30:2:14:MS102_PCP:Belfast:Charge:PCP:Implementation:+:8.0
> 2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Project-Control:+:7.5
> 2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:2.0
> 2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:0.7
>
Something like this (untested) ?
use strict;
use warnings;
while (<STDIN>)
{
my @outStr = split ':';
system qq(echo '$_' >> '$outStr[9].txt');
}
Regards
--
Abhinav
------------------------------
Date: Mon, 16 Aug 2004 15:46:45 +0530
From: Abhinav <matrix_calling@yahoo.dot.com>
Subject: Re: Extract same text from file.
Message-Id: <cX%Tc.13$bW.118@news.oracle.com>
Abhinav wrote:
> Ryan Keeling wrote:
>
>
>>Hi
>>I have the following text file which I want to use to populate text
>>files containing data only relevant to a particular project. Is it
>>possible for me to group similar lines together and put them in their
>>own text file? Such as a file containing all entries for
>>MS102_PCP.Implementation and another file for MS102_PCP.Support.
>>
>>Any help would be greatly appreciated!
>>
>>
>>2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
>>2004:01:07:3:02:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
>>2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
>>2004:01:09:5:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:1.0
>>2004:01:20:2:04:MS102_PCP:Belfast:Charge:PCP:Standards:6.5
>>2004:01:19:1:04:MS102_PCP:Belfast:Charge:PCP:Standard:7.5
>>2004:02:03:2:06:MS102_PCP:Belfast:Charge:PCP:Support:+:2.0
>>2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:5.5
>>2004:03:03:3:10:MS102_PCP:Belfast:Charge:PCP:Implementation:+:7.5
>>2004:03:02:2:10:MS102_PCP:Belfast:Charge:PCP:Support:+:2.5
>>2004:03:26:5:13:MS102_PCP:Belfast:Charge:PCP:Support:+:7.5
>>2004:03:29:1:14:MS102_PCP:Belfast:Charge:PCP:Support:+:8.0
>>2004:03:30:2:14:MS102_PCP:Belfast:Charge:PCP:Implementation:+:8.0
>>2004:01:05:1:02:MS102_PCP:Belfast:Charge:PCP:Project-Control:+:7.5
>>2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:2.0
>>2004:01:06:2:02:MS102_PCP:Belfast:Charge:PCP:Meetings:+:0.7
>>
>
>
> Something like this (untested) ?
>
> use strict;
> use warnings;
>
> while (<STDIN>)
> {
> my @outStr = split ':';
> system qq(echo '$_' >> '$outStr[9].txt');
Oops ..this should be
system qq(echo '$_' >> '$outStr[5]$outStr[9].txt');
>
> }
> Regards
>
> --
> Abhinav
------------------------------
Date: Mon, 16 Aug 2004 12:50:08 +0530
From: Abhinav <matrix_calling@yahoo.dot.com>
Subject: Re: Good way to un-chomp an array
Message-Id: <FlZTc.3$bW.73@news.oracle.com>
Jürgen Exner wrote:
> Matt Garrish wrote:
>
>>"John Bokma" <postmaster@castleamber.com> wrote in message
>>
>>>"Matt Garrish" <matthew.garrish@sympatico.ca> wrote in
>>>
>>>>"Suresh Govindachar" <initiallast-name@yahoo.xyz> wrote in message
>>>>
>>>>> for(my $i=0; $i<scalar @lines; $i++)
>>>>
>>>>for my $i (0..$#lines)
>>
>>Everyone else's baby is always uglier... : )
>>
>>Granted there are other ways that don't require the array index, but
>>it was only meant as a drop-in replacement for the original.
>
>
> You almost never need the array index in Perl. I would guess over 98% of all
> array processing is done one element at a time and for that the canonical
> form is
>
> for (@array) {
> process_element;
> }
>
Disgressing from the topic, could anyone please explain how (if at all)
this is different from
foreach (@array) {
process_element;
}
And when to use this instead of the former ?
> The only exception (i.e. the only case where you need an array index) is if
> in order to process a given element you need dynamic access to other array
> element, e.g. in bubble sort to compare the element with its neighbor. But
> in real life those case are surprisingly rare.
>
TIA
--
Abhinav
------------------------------
Date: Mon, 16 Aug 2004 10:23:08 +0300
From: "Eugene Mikheyev" <eam@7ka.mipt.ru>
Subject: Re: Good way to un-chomp an array
Message-Id: <cfpnc2$2s6g$1@news.univ.kiev.ua>
these are the same. 'for' and 'foreach' are synonyms
------------------------------
Date: 16 Aug 2004 07:37:36 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: Good way to un-chomp an array
Message-Id: <slrnci0p20.ono.sholden@flexal.cs.usyd.edu.au>
On Mon, 16 Aug 2004 12:50:08 +0530,
Abhinav <matrix_calling@yahoo.dot.com> wrote:
> Jürgen Exner wrote:
>
>>
>> for (@array) {
>> process_element;
>> }
>>
>
> Disgressing from the topic, could anyone please explain how (if at all)
> this is different from
>
> foreach (@array) {
> process_element;
> }
>
> And when to use this instead of the former ?
It is exactly the same.
Use that when you want to type an extra four characters.
Use:
foreach($i=0;$i<10;++$i) {
print "$i\n";
}
When you want to confuse yourself later.
--
Sam Holden
------------------------------
Date: Mon, 16 Aug 2004 16:36:52 +0800
From: "hugo" <hugoyg@163.com>
Subject: has anybody write bioinformatics programme with perl
Message-Id: <2oba7mF8rs97U1@uni-berlin.de>
let talk about bioinformatics more.
------------------------------
Date: 16 Aug 2004 11:02:29 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: has anybody write bioinformatics programme with perl
Message-Id: <cfq485$k3c$2@mamenchi.zrz.TU-Berlin.DE>
hugo <hugoyg@163.com> wrote in comp.lang.perl.misc:
> let talk about bioinformatics more.
That happens on a mailing list. See http://www.perl.org/community.html
and look for BioPerl.
Anno
------------------------------
Date: Mon, 16 Aug 2004 12:08:58 +0200
From: "Mark" <admin@asarian-host.net>
Subject: IPC::Shareable exceptionally slow on large segs
Message-Id: <d_2dnbftlrpeGr3cRVn-vg@giganews.com>
Hello,
I have been experimenting with IPC::Shareable 0.60 on FreeBSD 4.10-p2, using
perl 5.8.5. Everything works great... for small memory segments, that is.
With a default memory segment size of 64K, things fly.
If I increase the requested memory segment to a more useable size, say 1M,
reading/writing to the tied hash suddenly takes considerably longer (in
fact, it seems the lookup/write time is directly proportionate to the
increase in memory size). What does that mean? In practice, it means a
single hash lookup on a 1M segment takes about 1/2 second! Which is, IHMO,
indeed exceptionally long.
I have 32M free shared memory, mapped to physical memory exclusively
(unswappable). So that cannot be the cause. Does anyone have any ideas as to
why this occurs?
Thanks,
- Mark
------------------------------
Date: 16 Aug 2004 10:52:53 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: IPC::Shareable exceptionally slow on large segs
Message-Id: <cfq3m5$k3c$1@mamenchi.zrz.TU-Berlin.DE>
Mark <admin@asarian-host.net> wrote in comp.lang.perl.misc:
> Hello,
>
> I have been experimenting with IPC::Shareable 0.60 on FreeBSD 4.10-p2, using
> perl 5.8.5. Everything works great... for small memory segments, that is.
> With a default memory segment size of 64K, things fly.
>
> If I increase the requested memory segment to a more useable size, say 1M,
> reading/writing to the tied hash suddenly takes considerably longer (in
> fact, it seems the lookup/write time is directly proportionate to the
> increase in memory size). What does that mean? In practice, it means a
> single hash lookup on a 1M segment takes about 1/2 second! Which is, IHMO,
> indeed exceptionally long.
>
> I have 32M free shared memory, mapped to physical memory exclusively
> (unswappable). So that cannot be the cause. Does anyone have any ideas as to
> why this occurs?
From a glance at IPC::Shareable it seems that your 32 MB of hash is
potentially expanded ("thawed") for every access. That would explain
some delay.
At the risk of appearing old-fashioned, let me add that using shared
memory directly for storing mass data appears as a huge waste of
resources. Conceptually, shared memory is the most basic of IPC
mechanisms. It used to be used as sparingly as possible to implement
other mechanisms that protect larger areas of memory.
Anno
------------------------------
Date: 16 Aug 2004 00:12:07 -0700
From: dn_perl@hotmail.com (dn_perl@hotmail.com)
Subject: Placeholder in an sql query
Message-Id: <97314b5b.0408152312.71b24698@posting.google.com>
I want to use placeholder to escape special characters directly
via DBI while constructing an sql query.
The following code works properly :
=====================================
use vars qw($check_name) ;
$check_name = "Peter" ;
$dstmt = $dbh->prepare("select count(*) from student
where st_name='$check_name' "); # statement 2
$dstmt->execute() or die "sql call failed"; # statement 3
$num_entries = $dstmt->fetchrow() ;
$dstmt->finish ;
=====================================
I get the correct value in $num_entries and it happens to be 3.
But if I change statements 2 and 3 to use placeholder, I get
$num_entries = 0 (instead of 3). I am wondering why.
New statements #s 2 and 3
$dstmt = $dbh->prepare("select count(*) from student
where st_name=? ");
$dstmt->execute($check_name) or die "sql call failed";
Please advise.
------------------------------
Date: Mon, 16 Aug 2004 11:11:41 +0200
From: Tore Aursand <tore@aursand.no>
Subject: Re: Placeholder in an sql query
Message-Id: <pan.2004.08.16.09.11.40.680032@aursand.no>
On Mon, 16 Aug 2004 00:12:07 -0700, dn_perl@hotmail.com wrote:
> The following code works properly :
>
> =====================================
> use vars qw($check_name) ;
>
> $check_name = "Peter" ;
> $dstmt = $dbh->prepare("select count(*) from student
> where st_name='$check_name' "); # statement 2
> $dstmt->execute() or die "sql call failed"; # statement 3
> $num_entries = $dstmt->fetchrow() ;
> $dstmt->finish ;
> =====================================
>
>
> I get the correct value in $num_entries and it happens to be 3.
>
> But if I change statements 2 and 3 to use placeholder, I get
> $num_entries = 0 (instead of 3). I am wondering why.
>
> New statements #s 2 and 3
>
> $dstmt = $dbh->prepare("select count(*) from student
> where st_name=? ");
> $dstmt->execute($check_name) or die "sql call failed";
I can't see what's wrong, actually, but I would have cleaned up the code a
little just to be sure. Also make sure you're using 'strict' and
'warnings';
my $check_name = 'Peter';
my $dstmt = $dbh->prepare( 'SELECT COUNT(*) FROM student WHERE st_name = ?' );
$dstmt->execute( $check_name );
my ( $num_entries ) = $dstmt->fetchrow_array();
$dstmt->finish();
--
Tore Aursand <tore@aursand.no>
"The science of today is the technology of tomorrow." (Edward Teller)
------------------------------
Date: Mon, 16 Aug 2004 12:16:45 +0200
From: Sandman <mr@sandman.net>
Subject: Regexp: substituting \n with <br /> except in certain places
Message-Id: <mr-C59514.12164516082004@individual.net>
Textblock (indented for clarity):
Hello, my nickname is Sandman, here is
a list of things I like:
<ol>
<li> Perl
<li> PHP
<li> MySQL
</ol>
I want to replace newlines with "<br />\n" in this textblock, for displaying it
to a browser - but I don't want to replace it inside some specified html-tags -
in this case "ol", but also "ul", "pre" and "xmp".
So, the resulting text block should be:
Hello, my nickname is Sandman, here is<br />
a list of things I like:<br />
<br />
<ol>
<li> Perl
<li> PHP
<li> MySQL
</ol>
Is there a fancy regexp for this? I know how to exclude certain characters with
the [^...] 'switch', but what about whole blocks of text? In pseudo-code:
[^<(ol|ul|pre|xmp)>].
--
Sandman[.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 V10 Issue 6869
***************************************
