[28234] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 9598 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 13 14:05:42 2006

Date: Sun, 13 Aug 2006 11:05:04 -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           Sun, 13 Aug 2006     Volume: 10 Number: 9598

Today's topics:
            PerlDoc used in CPAN?--MULTIPOSTED usenet.cop@3955291010.com
        ANNOUNCE: DBIx::Admin::BackupRestore V 1.11 <ron@savage.net.au>
    Re: is it possible to efficiently read a large file? <Mark.Seger@hp.com>
    Re: is it possible to efficiently read a large file? <hjp-usenet2@hjp.at>
    Re: is it possible to efficiently read a large file? <Mark.Seger@hp.com>
    Re: is it possible to efficiently read a large file? <Mark.Seger@hp.com>
    Re: PerlDoc used in CPAN?--MULTIPOSTED <sherm@Sherm-Pendleys-Computer.local>
    Re: PerlDoc used in CPAN?--MULTIPOSTED <john@castleamber.com>
        PerlDoc used in CPAN? <zhushenli@gmail.com>
    Re: PerlDoc used in CPAN? <sherm@Sherm-Pendleys-Computer.local>
    Re: system command won't let go <nobull67@gmail.com>
    Re: system command won't let go <nobull67@gmail.com>
    Re: system command won't let go <tadmc@augustmail.com>
    Re: system command won't let go <mumia.w.18.spam+nospam.usenet@earthlink.net>
    Re: time manipulation help <DJStunks@gmail.com>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sun, 13 Aug 2006 09:26:19 -0500
From: usenet.cop@3955291010.com
Subject:     PerlDoc used in CPAN?--MULTIPOSTED
Message-Id: <1MudndoQatEWq0LZRVn_vQ@giganews.com>

"Davy" <zhushenli@gmail.com> wrote:
>> [ snip and ignore MULTIPOSTED message ]

**********************************************************************
**********   PLEASE  DO  NOT  RESPOND  TO  THIS  THREAD    ***********
**********************************************************************

This message has been multiposted as indicated by these message IDs:
   <1155479132.418250.248360@p79g2000cwp.googlegroups.com>
   <1155479132.418250.248360@p79g2000cwp.googlegroups.com>

This is the 1st auto-detected multiposted message by this author.

######################################################################
# TO THE USENET COMMUNITY: This message has been multiposted, which  #
# is universally considered rude. Therefore, it is requested that    #
# you DO NOT reply to this thread. Doing so only encourages rudeness.#
#                                                                    #
# NOTE: This "Multipost Detector" has been recently-deployed as a    #
# service to the Perl community.  Questions or comments are welcome  #
# (just reply to this message). See the NAQ at the end of this post. #
######################################################################

######################################################################
# TO THE ORIGINAL POSTER (OP): You have posted a multiposted message.#
# (see below for an explanation of what that is and why it is bad).  #
# Many regular participants in technical newsgroups will not respond #
# to a multiposted message if they realize it is multiposted.        #
#                                                                    #
# This thread is therefore (probably) burned (meaning you won't get  #
# any helpful replies). If you wish, you may open a new thread which #
# conforms to ordinary standards of usenet etiquette (see below).    #
#                                                                    #
# This is NOT a flame. This is a COURTESY notice to usenet & the OP. #
# Other participants are respectfully requested to NOT flame, ignore #
# or killfile the OP unless s/he persists in multiposting.           #
######################################################################

######################################################################
# WHAT IS MULTIPOSTING ?  If you post the same question to two (or   #
# more) different newsgroups as separate messages (without           #
# indicating that you have done so) then you have multiposted. This  #
# is NEVER an acceptable practice in usenet. There are two things    #
# which will get you killfiled in a hurry--you can flame a respected #
# group participant (like flaming Randal in a Perl group) or you can #
# multipost.  These are usenet mortal sins which you should avoid if #
# you wish to have a productive usenet experience.                   #
#                                                                    #
# WHY IS MULTIPOSTING RUDE? A question posted in one newsgroup might #
# receive a prompt and expert reply, because some nice person is     #
# kind enough to provide this assistance (free of charge). However,  #
# if the question is multiposted to another newsgroup, ANOTHER nice  #
# person might spend his/her time providing the SAME assistance,     #
# unaware that the question has ALREADY been answered elsewhere.     #
# This WASTES THE TIME of the second person, who was only trying to  #
# be helpful but was actually 'tricked' into wasting his/her time.   #
# The second person has NO WAY to know the question was multiposted  #
# (and already answered) elsewhere unless s/he happens to visit the  #
# other group and notice the multipost (before replying).            #
#                                                                    #
# Most new posters are given the benefit of doubt and are assumed    #
# to have violated these conventions due to a lack of understanding. #
# Posters who persist in such behavior, however, will likely be      #
# flamed, ignored, and/or killfiled by regular group participants.   #
######################################################################

######################################################################
# ABOUT THIS REPLY: This reply was posted by an automated process    #
# which scans selected newsgroups for evidence of multiposting.      #
#                                                                    #
# This is a service to the usenet community to let folks know when   #
# a message has been multiposted.  Many folks prefer not to reply    #
# to such messages, but they might do so 'accidentally' because      #
# they don't realize the message is multiposted.                     #
#                                                                    #
# This reply is also a service to the OP (it is not an attempt to    #
# be "mean" to the OP). Hopefully the OP will become more aware of   #
# usenet etiquette. Someone who takes offense at helpful correction  #
# will probably not have a very satisfying usenet experience.        #
######################################################################

######################################################################
# WHEN/HOW IS MULTIPOSTING OK?  If you post in one newsgroup         #
# but later realize (for whatever reason) that you would prefer to   #
# post the message elsewhere, it is OK to do so provided your new    #
# message references your original post (preferably with a link).    #
# You should also respond to your original post indicating it has    #
# been re-posted elsewhere (preferably with a link). This gives both #
# newsgroup communities visibility to the others' work. If you post  #
# in this manner, this process will NOT flag it as multiposted.      #
######################################################################

######################################################################
# REFERENCES:  The following information may be helpful:             #
#   http://www.faqs.org/faqs/usenet/primer/part1/                    #
#   http://www.catb.org/~esr/faqs/smart-questions.html               #
#   http://web.presby.edu/~nnqadmin/nnq/nquote.html                  #
#   http://www.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html #
######################################################################

######################################################################
# WHY DOES THIS AUTOMATED PROCESS EXIST?  Mainly because of Google   #
# Groups.  GG has made it very easy for anybody to post anything in  #
# usenet (and many GG users don't know much about usenet, and may    #
# not even realize they're posting to a worldwide network which has  #
# nothing to do with Google). Many folks (especially GG users) are   #
# not familiar with usenet etiquette conventions and thus annoy      #
# other participants (the very people whom they are asking for help).#
# This is counterproductive to both the OP and the usenet community  #
# at large. Posters are encouraged to consult the references above   #
# to learn how to ask a good question in a polite manner; doing so   #
# is beneficial to everyone (especially the OP).                     #
######################################################################

######################################################################
# NAQ (the Never Asked Questions - TEMPORARY SECTION)                #
# Q-What ruleset defines a multipost? A--Two MD5 digests are         #
#   calculated (one forwards, one backwards) on the message body     #
#   and stored in a small database. If a new post (new message ID)   #
#    matches these digests, it's a multipost. Author and subject     #
#    lines are not taken into account. Reply messages are ignored.   #
# Q-Are crossposts flagged?  A--No. A message must have an identical #
#   body but a unique message ID to be flagged. A crosspost which is #
#   ALSO multiposted, however, will be flagged.  I may one-day add   #
#   the ability to post a much milder message for crossposts between #
#   Perl groups (it is rarely, if ever, appropriate to crosspost     #
#   between similar groups, and such crossposting is discouraged).   #
# Q-What groups are scanned? A-The main Perl Groups in Google Groups,#
#   namely: comp.lang.perl.misc, perl.beginners, perl.dbi.users,     #
#   comp.lang.perl.modules , perl.beginners.cgi, and alt.perl        #
# Q-You dummy, it's EASY to defeat this scanner! A--Of course it is. #
#   But it's rare to see multiposts which differ in the message body.#
#   An author who deliberately tweaked the content to defeat a scan  #
#   reveals his/her deliberately rude intent (& should be killfiled) #
# Q-Why am I doing this? A--For a better usenet. Some folks try to   #
#   discourage job postings; some discourage off-topic posts. I try  #
#   to discourage multiposts - that's my little pet peeve (and,      #
#   unlike OT posts and the like, it's not obvious when it happens)  #
#   If you don't wish to be bothered with these auto-generated       #
#   responses, please killfile the scanner.                          #
# Q-Who wrote this program? A-- I am not trying to keep my identity  #
#   a big secret (it's easy enough to find out who I am, and group   #
#   regulars probably recognize my rants). But I choose to run this  #
#   scanner anonymously because some posters will be determined to   #
#   take offense at this. If they get mad at me, their anger may     #
#   spill over into future postings that I participate in. I just    #
#   get tired of newbies pitching tantrums any time someone offers   #
#   friendly and helpful correction, so I deny them an easy target.  #
#                                                                    #
#   I will reply (under my own handle) to questions or comments      #
########
msg_hash: 22 - 734d3325737f0e962b9a66865f90c4d0


------------------------------

Date: Sun, 13 Aug 2006 09:02:50 GMT
From: Ron Savage <ron@savage.net.au>
Subject: ANNOUNCE: DBIx::Admin::BackupRestore V 1.11
Message-Id: <J3xxLA.142H@zorch.sf-bay.org>

The pure Perl module DBIx::Admin::BackupRestore V 1.11
is available immediately from CPAN,
and from http://savage.net.au/Perl-modules.html.

On-line docs, and a *.ppd for ActivePerl are also
available from the latter site.

An extract from the docs:

1.11  Sun Aug 13 18:20:00 2006
	- 'fiddle_timestamp' now takes one of these values: 0, 1 or 2, or any of those
values + 128.
		The 128 means the top (left-most) bit in the byte value of this parameter is
set.
		If the top bit is set, another fiddle takes place, after any of the above have
occurred:
		The timestamp is checked against 1970-01-01 00:00:00, and if they match, the
timestamp
		is changed to 1970-01-01 00:00:01. This extra second means the timestamp is
now valid
		under the strict option for MySQL V 5, whereas 1970-01-01 00:00:00 is invalid.




------------------------------

Date: Sun, 13 Aug 2006 08:22:25 -0400
From: Mark Seger <Mark.Seger@hp.com>
To:  xhoster@gmail.com
Subject: Re: is it possible to efficiently read a large file?
Message-Id: <44DF1981.6070104@hp.com>

xhoster@gmail.com wrote:
> Mark Seger <Mark.Seger@hp.com> wrote:
> 
>>I'm trying to read a 3GB file efficiently.  If I do with a benchmarking
>>tool, I use about 6-8% of the cpu and can read it in about 44 seconds -
>>obviously the time if very closely tied to the type of disk, but I'm
>>including that for reference.
> 
> 
> What kind of benchmarking tool is it?  For benchmarking raw disks, or
> the OS FS, or what?  It may be using methods that are simply unavailable to
> a general purpose language like perl.

I'm using a tool called dt, see: 
http://home.comcast.net/~SCSIguy/SCSI_FAQ/RMiller_Tools/dt.html, which 
has been around for years and is very efficient.  All I'm doing is basic 
sequential reads.  Nothing fancy.

>>When I do the same thing in perl using:
>>
>>$reclen=1024*128;
>>while ($bytes=sysread(FILE, $buffer, $reclen))
>>{
>>     $total+=$bytes;
>>}
>>
>>it takes just under 60 seconds
> 
> 
> For me, it takes 7 seconds to read 4e9 bytes with your code and
> buffer size.  If I make it read from /dev/zero rather than a real
> file, then it takes less than 0.5 seconds.  Since Perl doesn't know
> that it is reading from /dev/zero, I would have to assume that at least
> 6.5 of those 7 seconds for the real files are taken up by things outside
> perl's control.

I find that number impossible to believe unless you're doing somethere 
very fancy OR you have more than 4GB RAM and are reading it out of cache 
(that's why I'm reading a 3GB file - I have 3GB of RAM).  A very common 
mistake in benchmarking is to write a file that is < the size of your 
RAM.  After the write the whole file is sitting in memory and none of th 
reads will provide accurate numbers.  To deliver the data at the rate 
you're suggesting, that disk would have do be delivering >500MB/sec and 
I haven't seen any cable of even delivering 100.

>>and used 25-30% of the cpu.
> 
> 
> I don't think CPU reporting in these cases is very meaningful.  Every
> monitoring tool seems to use a different method for how to attribute time
> between user, system, idle, IO-wait, etc.

but it is!  I'd claim if the tools use time that differ by that much 
they're not doing the same thing and the whole point of such a tool is 
to be efficient to show one maximum values.  The fact that I can do 
basci i/o in a simple C program that uses  <10% of the cpu (and I should 
point out that I had forgotten this an average over my 2 cpus, so one of 
them is really using almost 20%), this demonstrates that one can and 
should be able to read without massive consumption in a tool.

>>I'm sure
>>there is a lot of data movement between buffers and am wondering if
>>there is some way to avoid this.  I'm guessing that perhaps perl is
>>generating a new instance of $buffer every pass through the loop and if
>>so that would involve mallocs() and frees() every pass, which I'd like
>>to avoid if possible.
> 
> 
> Since I can't replicate your poor performance, I can't really investigate
> it. But I doubt any of this stuff is worth worrying about.  I'd look at the
> systems level, rather than at perl.

sorry, but if you can't replicate my numbers you must be doing something 
wrong.  are you SURE you cache is empty - it could be as simple as that. 
    See how much memory you have and then write a file bigger than that 
amount.  Now when you read it back you're guaranteed it's not in cache 
and I promise it'll take to much longer to read it back.

-mark

> Xho
> 


------------------------------

Date: Sun, 13 Aug 2006 18:01:09 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: is it possible to efficiently read a large file?
Message-Id: <pan.2006.08.13.16.01.04.637856@hjp.at>

On Sun, 13 Aug 2006 01:54:55 +0000, xhoster wrote:

> Mark Seger <Mark.Seger@hp.com> wrote:
>> I'm trying to read a 3GB file efficiently.  If I do with a benchmarking
>> tool, I use about 6-8% of the cpu and can read it in about 44 seconds -
>> obviously the time if very closely tied to the type of disk, but I'm
>> including that for reference.
[...]
>> When I do the same thing in perl using:
>>
>> $reclen=1024*128;
>> while ($bytes=sysread(FILE, $buffer, $reclen))
>> {
>>      $total+=$bytes;
>> }
>>
>> it takes just under 60 seconds
> 
> For me, it takes 7 seconds to read 4e9 bytes with your code and
> buffer size.

That would be about 570 MB/s. Just for reference, the Seagate Cheetah
300GB Fiberchannel drive (which should be among the fastest you can buy
today) delivers at most 150 MB/s. So either you have 4 of them in a
well-tuned RAID-0 configuration or you have more than 4 GB of RAM and
are reading from the buffer cache. Either way, that doesn't seem like an
average system you are using. The performance Mark is seeing (50-70 MB/s)
is much closer to my experience. 

> If I make it read from /dev/zero rather than a real file, then it
> takes less than 0.5 seconds.

Right. 0.35 Seconds on a 2.4 GHz P4 Xeon.

Also, the difference in CPU usage between dd bs=128k and the perl script
is about 0.2 seconds. Both take about 12 seconds CPU time when reading
from disk, but almost all of that is system time - time the OS needs to
shuffle buffers around, talk to the fiber channel adapters, etc. That
could probably be reduced quite a bit using mmap instead of read.


>> and used 25-30% of the cpu.
> 
> I don't think CPU reporting in these cases is very meaningful.  Every
> monitoring tool seems to use a different method for how to attribute time
> between user, system, idle, IO-wait, etc.

I don't know what platform Mark is using, but on Unixish systems these
statistics are collected by the OS. Not much a monitoring tool (the
shell, usually) can do about it.

So a difference between 6% and 25% CPU usage coupled with an increase in
wall-clock time from 44 to 60 seconds on the same platform is IMHO very
significant and shows that perl does something a lot less efficiently
than Marks unnamed "benchmark tool".

First I'd look at the hardware: Is this an old or low-power cpu, which
would explain the difference between my 0.2 seconds and Marks 16
seconds?

Next I'd check what the perl script is really doing. For me strace
prints for Mark's script a steady stream of

read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072

Finally, I'd look at the script. Mark didn't show how he opened the
file. If he didn't open it in binary mode, an input layer may add a lot
of overhead.

Now that I think of it, I'd reverse the order :-).

>> I'm sure there is a lot of data movement between buffers and am
>> wondering if there is some way to avoid this.

Perl has almost certainly a lot more overhead than C. That's the price
you pay for using a higher-level language. Usually, that overhead
doesn't matter because your script spends most of its time elsewhere,
though.

	hp

-- 
   _  | Peter J. Holzer    | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR       | > ist?
| |   | hjp@hjp.at         | Was sonst wäre der Sinn des Erfindens?
__/   | http://www.hjp.at/ |	-- P. Einstein u. V. Gringmuth in desd



------------------------------

Date: Sun, 13 Aug 2006 08:36:56 -0400
From: Mark Seger <Mark.Seger@hp.com>
To: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: is it possible to efficiently read a large file?
Message-Id: <44DF1CE8.6070506@hp.com>

Ben Morrow wrote:

> Quoth Mark Seger <Mark.Seger@hp.com>:
> 
>>John W. Krahn wrote:
>>
>>
>>>Are you using open() or sysopen() to open the file?  sysread() "bypasses
>>>buffered IO" but your $reclen may be too large (or too small) for efficient
>>>IO.  Your example appears to use $main::buffer which means that the same
>>>variable is used for each read however I don't know whether Perl reallocates
>>>memory for each read.  You could use something like strace(1) to determine
>>>exactly what system calls the program is making.
>>
>>I'm usong open(), but I'll give sysopen() a whirl in the morning.  I 
>>also like the idea abot strace.  my fear is the data is being read into 
>>one buffer and storage is getting allocated for $buffer on each call and 
>>then moved to it.  the challenge is, is there a way to read directly 
>>into the $buffer.  maybe strace() will provide some clues...
> 
> 
> open/sysopen should make no difference. To preallocate a buffer, create
> a long string and overwrite bits of it with substr or directly with
> sysread. You have to do your own buffer manglement as in C, of course,
> but that's how you get efficiency.

I didn't think it would make a differnce but I'm desparate and willing 
to try anything.  8-(

I had created a long string and passed it to sysread but it didn't seem 
to make any difference, and besides one subsequent reads it would 
already be allocated to the proper length by the previous reads.  Or am 
I missing something?

Just to back up a step or two, I wrote a short C program that mallocs a 
buffer and calls fread with the address of the buffer and it runs as 
efficiently and at the same speed as my benchmark tool (which I've 
included a pointer to in a previous response - a very cool tool if you 
haven't tried it yet).

What I don't see how is to pass the address of my buffer to sysread as 
it wants a scalar and so won't that always force it to be created/malloc'd?

Here's exactly what I'm doing, noting that I'm counting the bytes read 
just to make sure I'm reading no more than I should be.  Assuming I 
understand what you were saying, I believe I am preallocating the buffer.

#!/usr/bin/perl -w

$reclen=1024*128;
$buffer=' 'x$reclen;
$filename='/mnt/scratch/test';
open FILE, "<$filename" or die;

$total=0;
$start=time;
while ($bytes=sysread(FILE, $buffer, $reclen))
{
     $total+=$bytes;
}

$duration=time-$start;
printf "Filesize: %5dM  Recsize:%5dK  %5.1fSecs  %6dKB/sec\n",
       $total/(1024*1024), $reclen/1024, $duration, $total/$duration/1024;

-mark
> Ben
> 


------------------------------

Date: Sun, 13 Aug 2006 09:06:53 -0400
From: Mark Seger <Mark.Seger@hp.com>
To:  xhoster@gmail.com
Subject: Re: is it possible to efficiently read a large file?
Message-Id: <44DF23ED.2030806@hp.com>

I realized I didn't answer all your questions.  Sorry about that.  See 
below:

xhoster@gmail.com wrote:
> Mark Seger <Mark.Seger@hp.com> wrote:
> 
>>I'm trying to read a 3GB file efficiently.  If I do with a benchmarking
>>tool, I use about 6-8% of the cpu and can read it in about 44 seconds -
>>obviously the time if very closely tied to the type of disk, but I'm
>>including that for reference.
> 
> 
> What kind of benchmarking tool is it?  For benchmarking raw disks, or
> the OS FS, or what?  It may be using methods that are simply unavailable to
> a general purpose language like perl.

I do believe DT (which I mentioned in an earlier note) uses very basic, 
sequential reads (there are certainly switches to do async and other 
switches as well, but I just use the basics).  If you do care to 
download a copy of it (and I highly recommned it), try the command:

dt of=/tmp/file limit=10g bs=1m disable=compare,verify dispose=keep

to create a 10G file.  As I said before, pick a size at least as large 
as your current RAM to assume it doesn't get cached.  Now read it back 
with the identical command, replacing the 'of' with 'if' (output to 
input).  Here's an example on my machine, remember I only have 3 GB RAM:

[root@cag-dl380-01 mjs]# ./dt of=/mnt/scratch/test limit=3g bs=1m 
disable=compare,verify dispose=keep

Total Statistics:
      Output device/file name: /mnt/scratch/test (device type=regular)
      Type of I/O's performed: sequential (forward)
         Data pattern written: 0x39c39c39 (read verify disabled)
      Total records processed: 3072 @ 1048576 bytes/record (1024.000 Kbytes)
      Total bytes transferred: 3221225472 (3145728.000 Kbytes, 3072.000 
Mbytes)
       Average transfer rates: 50135805 bytes/sec, 48960.747 Kbytes/sec
      Number I/O's per second: 47.813
       Total passes completed: 1/1
        Total errors detected: 0/1
           Total elapsed time: 01m04.25s
            Total system time: 00m08.46s
              Total user time: 00m00.00s
                Starting time: Sun Aug 13 08:57:30 2006
                  Ending time: Sun Aug 13 08:58:35 2006

[root@cag-dl380-01 mjs]# ./dt if=/mnt/scratch/test limit=3g bs=1m 
disable=compare,verify dispose=keep

Total Statistics:
       Input device/file name: /mnt/scratch/test (device type=regular)
      Type of I/O's performed: sequential (forward)
            Data pattern read: 0x39c39c39 (data compare disabled)
      Total records processed: 3072 @ 1048576 bytes/record (1024.000 Kbytes)
      Total bytes transferred: 3221225472 (3145728.000 Kbytes, 3072.000 
Mbytes)
       Average transfer rates: 88252753 bytes/sec, 86184.329 Kbytes/sec
      Number I/O's per second: 84.164
       Total passes completed: 1/1
        Total errors detected: 0/1
           Total elapsed time: 00m36.50s
            Total system time: 00m06.85s
              Total user time: 00m00.02s
                Starting time: Sun Aug 13 09:00:00 2006
                  Ending time: Sun Aug 13 09:00:36 2006

The 2 main things to note are the Average Transfer Rates and the Total 
Elapsed time.  Now here's another run using a file size of 1GB (I left 
out the intermediate stats for the sake of brevity).  As you can see the 
reads are MUST faster (almost 250MB/sec) since it's reading out of 
memory rather than disk:

[root@cag-dl380-01 mjs]# ./dt of=/mnt/scratch/test2 limit=1g bs=1m 
disable=compare,verify dispose=keep

Total Statistics:
       Average transfer rates: 50815988 bytes/sec, 49624.988 Kbytes/sec
           Total elapsed time: 00m21.13s

[root@cag-dl380-01 mjs]# ./dt if=/mnt/scratch/test2 limit=1g bs=1m 
disable=compare,verify dispose=keep

Total Statistics:
       Average transfer rates: 249128033 bytes/sec, 243289.095 Kbytes/sec
           Total elapsed time: 00m04.31s

-mark


------------------------------

Date: Sun, 13 Aug 2006 11:26:17 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: PerlDoc used in CPAN?--MULTIPOSTED
Message-Id: <m2slk0y7vq.fsf@Sherm-Pendleys-Computer.local>

usenet.cop@3955291010.com writes:

> "Davy" <zhushenli@gmail.com> wrote:
>>> [ snip and ignore MULTIPOSTED message ]
>
> **********************************************************************
> **********   PLEASE  DO  NOT  RESPOND  TO  THIS  THREAD    ***********
> **********************************************************************

Get bent. I'll reply to whomever I please, and I'll do so in a manner that's
far more constructive and helpful than your self-riteous whine-bot will
*EVER* be.

sherm--

-- 
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net


------------------------------

Date: 13 Aug 2006 17:00:30 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: PerlDoc used in CPAN?--MULTIPOSTED
Message-Id: <Xns981E7A260C301castleamber@130.133.1.4>

Sherm Pendley <sherm@Sherm-Pendleys-Computer.local> wrote:

> usenet.cop@3955291010.com writes:
> 
>> "Davy" <zhushenli@gmail.com> wrote:
>>>> [ snip and ignore MULTIPOSTED message ]
>>
>> **********************************************************************
>> **********   PLEASE  DO  NOT  RESPOND  TO  THIS  THREAD   
>> *********** 
>> **********************************************************************
> 
> Get bent. I'll reply to whomever I please, and I'll do so in a manner
> that's far more constructive and helpful than your self-riteous
> whine-bot will *EVER* be.

Yup, I agree, the bot post is more annoying and unreadable then a flame 
from a regular.

-- 
John Bokma          Freelance software developer
                                &
                    Experienced Perl programmer: http://castleamber.com/


------------------------------

Date: 13 Aug 2006 07:25:32 -0700
From: "Davy" <zhushenli@gmail.com>
Subject: PerlDoc used in CPAN?
Message-Id: <1155479132.418250.248360@p79g2000cwp.googlegroups.com>

Hi all,

I found there is a PerlDoc comment structure used in CPAN Perl Module.
And HTML document can be generated automatically from Perl file (like
NAME, SYNOPSIS, DESCRIPTION...).

Is there any document talk about how to write the comment structure?
And use what tool to generate the HTML? Thanks!

Davy



------------------------------

Date: Sun, 13 Aug 2006 11:19:37 -0400
From: Sherm Pendley <sherm@Sherm-Pendleys-Computer.local>
Subject: Re: PerlDoc used in CPAN?
Message-Id: <m2wt9cy86u.fsf@Sherm-Pendleys-Computer.local>

"Davy" <zhushenli@gmail.com> writes:

> I found there is a PerlDoc comment structure used in CPAN Perl Module.
> And HTML document can be generated automatically from Perl file (like
> NAME, SYNOPSIS, DESCRIPTION...).
>
> Is there any document talk about how to write the comment structure?

Yes - see 'perldoc perlpod'.

> And use what tool to generate the HTML? Thanks!

See 'perldoc pod2html'.

sherm--

-- 
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net


------------------------------

Date: 13 Aug 2006 06:59:44 -0700
From: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: system command won't let go
Message-Id: <1155477584.638043.28740@b28g2000cwb.googlegroups.com>

rallabs@adelphia.net wrote:

> I am having some difficulties with the 'system' command.

> system "~/runsgood.exe<point.$newID";

> and when I run the script here's what appears in a browser window:
>
> ENTER INPUT FILE NAME WITHOUT  .in EXTENSION
>
> Status: 302 Moved
> Location: ~/cgi-bin/done.cgi
>
>
> The prompt from runsgood.exe appears, just as it does when I run it
> interactively.  The program does its job and the  output does appear in
> my directory as it should, but it cannot get to the last line for some
> reason.

I have no idea what you meant by "it cannot get to the last line".

>  Does anybody know how to stop this?

If you are asking how you can redirect the output of the ~/runsgood.exe
process then why don't you just use a shell redirect as you did to
redirect the input?

system "~/runsgood.exe <point.$newID >/dev/null";

> I was hoping that I would
> get the prompt to disappear because I had no header in the script,

I have no idea what you meant by that.



------------------------------

Date: 13 Aug 2006 07:05:48 -0700
From: "Brian McCauley" <nobull67@gmail.com>
Subject: Re: system command won't let go
Message-Id: <1155477948.557923.119520@h48g2000cwc.googlegroups.com>


rallabs@adelphia.net wrote:

> use CGI qw(:standard -no_xhtml);
> my $co = new CGI;

You should probably decide which of the GCI APIs you are using,
"standard" or OO.

> system "sed s/old/$newID/ point_old >point.$newID";

You know Perl is quite a powerfull text processing language in itself.
Why do you feel the need to use sed?

> system "~/runsgood.exe<point.$newID";
> print $co->redirect('~/cgi-bin/done.cgi');
>
> and when I run the script here's what appears in a browser window:
>
> ENTER INPUT FILE NAME WITHOUT  .in EXTENSION
>
> Status: 302 Moved
> Location: ~/cgi-bin/done.cgi

What web server are you using? I would have expected to see an error
from the web server saying that the GCI script did not generate valid
headers.



------------------------------

Date: Sun, 13 Aug 2006 09:27:55 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: system command won't let go
Message-Id: <slrnedudnb.n45.tadmc@magna.augustmail.com>

rallabs@adelphia.net <rallabs@adelphia.net> wrote:


> system "~/runsgood.exe<point.$newID";


> I was hoping that I would
> get the prompt to disappear


Then redirect the program's STDOUT:

   system "~/runsgood.exe >/dev/null <point.$newID";


-- 
    Tad McClellan                          SGML consulting
    tadmc@augustmail.com                   Perl programming
    Fort Worth, Texas


------------------------------

Date: Sun, 13 Aug 2006 17:08:58 GMT
From: "Mumia W." <mumia.w.18.spam+nospam.usenet@earthlink.net>
Subject: Re: system command won't let go
Message-Id: <K0JDg.8338$0e5.261@newsread4.news.pas.earthlink.net>

On 08/13/2006 07:08 AM, rallabs@adelphia.net wrote:
> [...]
> print $co->redirect('~/cgi-bin/done.cgi');
> 
> and when I run the script here's what appears in a browser window:
> 
> ENTER INPUT FILE NAME WITHOUT  .in EXTENSION
> 
> Status: 302 Moved
> Location: ~/cgi-bin/done.cgi
> [...]

This (~) is your problem. Location headers are supposed to be 
absolute, not relative, and tilde (~) has no meaning in a web 
server context.

print $co->redirect('http://www.mysite.com/cgi-bin/done.cgi');



------------------------------

Date: 13 Aug 2006 08:43:15 -0700
From: "DJ Stunks" <DJStunks@gmail.com>
Subject: Re: time manipulation help
Message-Id: <1155483795.419692.300900@i3g2000cwc.googlegroups.com>

mike888@berlin.com wrote:
> Hi,
>
> I am having problem with "use strict;" with hour manipulation.
> I want my programs to run certain thing between the 11.15pm until
> 6.15am.
> can someone help me?
> thanks alot, i appreciate it.

if you _really_ want to get ahead of the curve you should be using
Perl6::strict in which the strictures have been ratcheted up a notch
and now all lexicals must be defined using "simon says":

  #!/usr/bin/perl

  use warnings;
  use Perl6::strict;
  use Perl6::say;

  simon says $string = 'Hello, World!";
  say $string;

  __END__

-jp



------------------------------

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 9598
***************************************


home help back first fref pref prev next nref lref last post