[24754] in Perl-Users-Digest
Perl-Users Digest, Issue: 6907 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 25 03:07:08 2004
Date: Wed, 25 Aug 2004 00:05:10 -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 Wed, 25 Aug 2004 Volume: 10 Number: 6907
Today's topics:
-s vs du - different results <zebee@zip.com.au>
Re: -s vs du - different results <uri@stemsystems.com>
Re: -s vs du - different results <jurgenex@hotmail.com>
Re: -s vs du - different results <sholden@flexal.cs.usyd.edu.au>
Re: -s vs du - different results <sholden@flexal.cs.usyd.edu.au>
Re: -s vs du - different results <zebee@zip.com.au>
Re: -s vs du - different results <zebee@zip.com.au>
Re: -s vs du - different results <zebee@zip.com.au>
Re: -s vs du - different results <zebee@zip.com.au>
Re: -s vs du - different results <uri@stemsystems.com>
Re: -s vs du - different results <sholden@flexal.cs.usyd.edu.au>
Re: -s vs du - different results <mgjv@tradingpost.com.au>
Re: -s vs du - different results <sholden@flexal.cs.usyd.edu.au>
5.8.5 make test fails on lib/ExtUtils/Constant with icc <clint@0lsen.net>
Re: 5.8.5 make test fails on lib/ExtUtils/Constant with <tassilo.von.parseval@rwth-aachen.de>
Re: Can this code be better? <nobull@mail.com>
Re: Can this code be better? <nobull@mail.com>
Re: Dereferencing Objects $_@_.%_
Re: Exange of informations and objects between PERL and <kalinaubears@iinet.net.au>
Oracle's RPAD problematic via Perl's DBI module (dn_perl@hotmail.com)
Re: Parsing FileName for upload <zebee@zip.com.au>
Re: Parsing FileName for upload <nobull@mail.com>
performance surprise -- why? <haltingNOSPAM@comcast.net>
Re: performance surprise -- why? <ztirftnek-usenet@yahoo.com>
Re: performance surprise -- why? <uri@stemsystems.com>
Re: performance surprise -- why? <matthew.garrish@sympatico.ca>
Re: performance surprise -- why? <matthew.garrish@sympatico.ca>
PHP in a Perl Script <reachus@netlink.info>
Re: PHP in a Perl Script <noreply@gunnar.cc>
Re: PHP in a Perl Script <postmaster@castleamber.com>
Re: The Perl Journal Vols 1 - 18, & 20 (David Combs)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 25 Aug 2004 04:17:01 GMT
From: Zebee Johnstone <zebee@zip.com.au>
Subject: -s vs du - different results
Message-Id: <slrncio4bg.p1o.zebee@zeus.zipworld.com.au>
As people recommended using stat, I've tried.
But I seem to get different results to du, and different
to what my CD burning prog says.
#!/usr/bin/perl -w
use strict;
use File::Find;
my $total;
my $dir = shift;
find(\&wanted, $dir);
print "total = $total \n";
sub wanted {
$total += -s $File::Find::name;
}
produces:
total = 695543582
Running du -sb on the directory given to that program gets me:
750284800
So what am I missing about -s? That's a huge discrepancy, so
there's something that's not being counted.
I am running it as root, so it's not a permissions problem.
am I overflowing some buffer somewhere?
Zebee
--
Zebee Johnstone (zebee@zip.com.au), proud holder of
aus.motorcycles Poser Permit #1.
"Motorcycles are like peanuts... who can stop at just one?"
------------------------------
Date: Wed, 25 Aug 2004 04:30:10 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: -s vs du - different results
Message-Id: <x7d61fet78.fsf@mail.sysarch.com>
>>>>> "ZJ" == Zebee Johnstone <zebee@zip.com.au> writes:
ZJ> print "total = $total \n";
ZJ> sub wanted {
ZJ> $total += -s $File::Find::name;
ZJ> }
ZJ> produces:
ZJ> total = 695543582
ZJ> Running du -sb on the directory given to that program gets me:
ZJ> 750284800
ZJ> So what am I missing about -s? That's a huge discrepancy, so
ZJ> there's something that's not being counted.
du is not the same as -s.
du measures real blocks in use. unix files (notably dbm types as well as
others) can have gaps so the maximum offset (what -s sees) can be much
greater than the actual storage used. du gets into the inode itself and
finds all the allocated blocks and counts them.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Wed, 25 Aug 2004 04:31:43 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: -s vs du - different results
Message-Id: <PCUWc.3118$9P.397@trnddc04>
Zebee Johnstone wrote:
> But I seem to get different results to du, and different
> to what my CD burning prog says.
[...]
> $total += -s $File::Find::name;
> produces:
> total = 695543582
Which apparently is the sum of the sizes of all files.
> Running du -sb on the directory given to that program gets me:
> 750284800
Which is how much space all files together occupy on the disk.
> So what am I missing about -s?
Nothing. You are just calculating two different things.
> That's a huge discrepancy, so
> there's something that's not being counted.
Not at all. It's just the trivial fact that usually the size of a file and
the amount of disk space it occupies are not identical and in some cases can
be very different, e.g. for sparse files.
jue
------------------------------
Date: 25 Aug 2004 04:57:09 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: -s vs du - different results
Message-Id: <slrncio715.koe.sholden@flexal.cs.usyd.edu.au>
On Wed, 25 Aug 2004 04:17:01 GMT, Zebee Johnstone <zebee@zip.com.au> wrote:
> As people recommended using stat, I've tried.
>
> But I seem to get different results to du, and different
> to what my CD burning prog says.
>
> #!/usr/bin/perl -w
> use strict;
> use File::Find;
> my $total;
> my $dir = shift;
> find(\&wanted, $dir);
>
> print "total = $total \n";
>
> sub wanted {
> $total += -s $File::Find::name;
> }
>
> produces:
> total = 695543582
>
> Running du -sb on the directory given to that program gets me:
> 750284800
>
> So what am I missing about -s? That's a huge discrepancy, so
> there's something that's not being counted.
>
> I am running it as root, so it's not a permissions problem.
>
> am I overflowing some buffer somewhere?
-s is doing a stat(), which will give different answers than
"du -sb" in the presence of symbolic links.
What happens with:
sub wanted {
lstat $_;
$total += -s _;
}
?
--
Sam Holden
------------------------------
Date: 25 Aug 2004 05:05:23 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: -s vs du - different results
Message-Id: <slrncio7gj.koe.sholden@flexal.cs.usyd.edu.au>
On Wed, 25 Aug 2004 04:30:10 GMT, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "ZJ" == Zebee Johnstone <zebee@zip.com.au> writes:
>
> ZJ> print "total = $total \n";
>
> ZJ> sub wanted {
> ZJ> $total += -s $File::Find::name;
> ZJ> }
>
> ZJ> produces:
> ZJ> total = 695543582
>
> ZJ> Running du -sb on the directory given to that program gets me:
> ZJ> 750284800
>
> ZJ> So what am I missing about -s? That's a huge discrepancy, so
> ZJ> there's something that's not being counted.
>
> du is not the same as -s.
>
> du measures real blocks in use. unix files (notably dbm types as well as
> others) can have gaps so the maximum offset (what -s sees) can be much
> greater than the actual storage used. du gets into the inode itself and
> finds all the allocated blocks and counts them.
The '-b' option to GNU du changes that behaviour to calculate the
"apparent size" and not the disk usage (which is silly for a program named
"du", but that's another issue). I don't know the various flavours of
du, but the non-GNU ones I have access to don't have a '-b' option at all.
So it's likely (given my small sample) that the OP is using GNU du.
Also, wouldn't that result in "du" giving a smaller total, not a larger
total?
--
Sam Holden
------------------------------
Date: Wed, 25 Aug 2004 05:15:33 GMT
From: Zebee Johnstone <zebee@zip.com.au>
Subject: Re: -s vs du - different results
Message-Id: <slrncio7p8.r2u.zebee@zeus.zipworld.com.au>
In comp.lang.perl.misc on Wed, 25 Aug 2004 04:30:10 GMT
Uri Guttman <uri@stemsystems.com> wrote:
>
> du is not the same as -s.
>
> du measures real blocks in use. unix files (notably dbm types as well as
> others) can have gaps so the maximum offset (what -s sees) can be much
> greater than the actual storage used. du gets into the inode itself and
> finds all the allocated blocks and counts them.
Much greater? So shouldn't -s therefore come up with a bigger size?
But it came up with a much smaller one.
Or am I misunderstanding what you mean by offset?
Is there a perl method that does the right thing? If -s is
undercounting then it's not very helpful to find sizes...
So it might well be back to du!
Zebee
------------------------------
Date: Wed, 25 Aug 2004 05:18:42 GMT
From: Zebee Johnstone <zebee@zip.com.au>
Subject: Re: -s vs du - different results
Message-Id: <slrncio7v5.r2u.zebee@zeus.zipworld.com.au>
In comp.lang.perl.misc on Wed, 25 Aug 2004 04:31:43 GMT
Jürgen Exner <jurgenex@hotmail.com> wrote:
>
>> That's a huge discrepancy, so
>> there's something that's not being counted.
>
> Not at all. It's just the trivial fact that usually the size of a file and
> the amount of disk space it occupies are not identical and in some cases can
> be very different, e.g. for sparse files.
Which is something not being counted :) If only unused blocks...
I want to take enough files to fit on a CD and put those files in
a directory and then make an CD from the directory.
If -s won't do it, what will? Or do I just use du in backticks?
Zebee
------------------------------
Date: Wed, 25 Aug 2004 05:19:55 GMT
From: Zebee Johnstone <zebee@zip.com.au>
Subject: Re: -s vs du - different results
Message-Id: <slrncio81e.r2u.zebee@zeus.zipworld.com.au>
In comp.lang.perl.misc on 25 Aug 2004 04:57:09 GMT
Sam Holden <sholden@flexal.cs.usyd.edu.au> wrote:
> -s is doing a stat(), which will give different answers than
> "du -sb" in the presence of symbolic links.
There aren't many of those in the given dir
>
> What happens with:
>
> sub wanted {
> lstat $_;
> $total += -s _;
> }
total = 695472130
compared to the simple -s which was total = 695543582
and du which was 750284800
Zebee
------------------------------
Date: Wed, 25 Aug 2004 05:25:34 GMT
From: Zebee Johnstone <zebee@zip.com.au>
Subject: Re: -s vs du - different results
Message-Id: <slrncio8c1.r2u.zebee@zeus.zipworld.com.au>
In comp.lang.perl.misc on 25 Aug 2004 05:05:23 GMT
Sam Holden <sholden@flexal.cs.usyd.edu.au> wrote:
>
> The '-b' option to GNU du changes that behaviour to calculate the
> "apparent size" and not the disk usage (which is silly for a program named
> "du", but that's another issue). I don't know the various flavours of
> du, but the non-GNU ones I have access to don't have a '-b' option at all.
> So it's likely (given my small sample) that the OP is using GNU du.
It's a linux box, so use gnu du, although the info page has nothing about
"apparent size" but says " `du' reports the amount of disk space used by
the specified files and for each subdirectory (of directory arguments). "
and -b, --bytes print size in bytes
I used -b because otherwise it gives it in 1024 byte chunks:
[root@clone backups]# du -s burn
732700 burn
Zebee
------------------------------
Date: Wed, 25 Aug 2004 05:51:09 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: -s vs du - different results
Message-Id: <x7oekzdavs.fsf@mail.sysarch.com>
>>>>> "SH" == Sam Holden <sholden@flexal.cs.usyd.edu.au> writes:
SH> On Wed, 25 Aug 2004 04:30:10 GMT, Uri Guttman <uri@stemsystems.com> wrote:
>>>>>>> "ZJ" == Zebee Johnstone <zebee@zip.com.au> writes:
>>
ZJ> print "total = $total \n";
>>
ZJ> sub wanted {
ZJ> $total += -s $File::Find::name;
ZJ> }
>>
ZJ> produces:
ZJ> total = 695543582
>>
ZJ> Running du -sb on the directory given to that program gets me:
ZJ> 750284800
>>
ZJ> So what am I missing about -s? That's a huge discrepancy, so
ZJ> there's something that's not being counted.
>>
>> du is not the same as -s.
>>
>> du measures real blocks in use. unix files (notably dbm types as well as
>> others) can have gaps so the maximum offset (what -s sees) can be much
>> greater than the actual storage used. du gets into the inode itself and
>> finds all the allocated blocks and counts them.
SH> The '-b' option to GNU du changes that behaviour to calculate the
SH> "apparent size" and not the disk usage (which is silly for a program named
SH> "du", but that's another issue). I don't know the various flavours of
SH> du, but the non-GNU ones I have access to don't have a '-b' option at all.
SH> So it's likely (given my small sample) that the OP is using GNU du.
SH> Also, wouldn't that result in "du" giving a smaller total, not a larger
SH> total?
good point but it still is a real discrepancy. gnu du says:
-b, --bytes
print size in bytes
so it prints the size used in bytes. it still isn't -s.
ls -l pad_bench.pl
-rw-r--r-- 1 uri staff 523 May 3 03:25 pad_bench.pl
perl -le 'print -s "pad_bench.pl"'
523
du -sb pad_bench.pl
1024 pad_bench.pl
so du will add up the unused bytes in the trailing blocks. and it will
still skip missing blocks (maybe he has none of those in that dir tree).
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 25 Aug 2004 06:18:01 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: -s vs du - different results
Message-Id: <slrnciobop.n9p.sholden@flexal.cs.usyd.edu.au>
On Wed, 25 Aug 2004 05:51:09 GMT, Uri Guttman <uri@stemsystems.com> wrote:
[snip du and perl's '-s' giving different results]
>
> good point but it still is a real discrepancy. gnu du says:
>
> -b, --bytes
> print size in bytes
>
> so it prints the size used in bytes. it still isn't -s.
>
> ls -l pad_bench.pl
> -rw-r--r-- 1 uri staff 523 May 3 03:25 pad_bench.pl
> perl -le 'print -s "pad_bench.pl"'
> 523
> du -sb pad_bench.pl
> 1024 pad_bench.pl
>
> so du will add up the unused bytes in the trailing blocks. and it will
> still skip missing blocks (maybe he has none of those in that dir tree).
My du doesn't seem to do that:
; ls -l resolver.pl
-rw-r--r-- 1 sholden pgrad 436 Jul 18 15:58 resolver.pl
; perl -le 'print -s "resolver.pl"'
436
; du -sb resolver.pl
436 resolver.pl
;
But I see that it's a version thing...
; du --version
du (coreutils) 5.2.1
; ./du --version
du (fileutils) 4.1
; du -bs resolver.pl
436 resolver.pl
; ./du -bs resolver.pl
4096 resolver.pl
So the --apparent-size was added sometime between those two versions
and -b changed to be:
-b, --bytes equivalent to `--apparent-size --block-size=1'
The joys of incompatable unix tools - someone should write a portable
scripting language to avoid these issues...
For the OP: You could use blocks count in the stat result, but I
don't know how to determine the blocksize for the filesystem. Plus
it if you are creating a CD image, then you are creating a new
filesystem whose blocksize may well be different so the
count may be useless anyway?
--
Sam Holden
------------------------------
Date: 25 Aug 2004 06:39:29 GMT
From: Martien Verbruggen <mgjv@tradingpost.com.au>
Subject: Re: -s vs du - different results
Message-Id: <slrnciod0v.47i.mgjv@verbruggen.comdyn.com.au>
On Wed, 25 Aug 2004 05:18:42 GMT,
Zebee Johnstone <zebee@zip.com.au> wrote:
> In comp.lang.perl.misc on Wed, 25 Aug 2004 04:31:43 GMT
> Jürgen Exner <jurgenex@hotmail.com> wrote:
>>
>>> That's a huge discrepancy, so
>>> there's something that's not being counted.
>>
>> Not at all. It's just the trivial fact that usually the size of a file and
>> the amount of disk space it occupies are not identical and in some cases can
>> be very different, e.g. for sparse files.
>
> Which is something not being counted :) If only unused blocks...
>
> I want to take enough files to fit on a CD and put those files in
> a directory and then make an CD from the directory.
>
> If -s won't do it, what will? Or do I just use du in backticks?
Have you tried
my ($block_size, $blocks) = (stat $_)[11, 12];
my $du_size = $block_size * $blocks;
If your find doesn't span multiple file systems, $block_size probably
is constant, and you can optimise that out. Even if you span multiple
file systems, the chance is still high that $block_size is constant.
Martien
--
|
Martien Verbruggen | Make it idiot proof and someone will make a
Trading Post Australia | better idiot.
|
------------------------------
Date: 25 Aug 2004 06:55:32 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: -s vs du - different results
Message-Id: <slrnciodv4.oph.sholden@flexal.cs.usyd.edu.au>
On 25 Aug 2004 06:39:29 GMT, Martien Verbruggen <mgjv@tradingpost.com.au> wrote:
> On Wed, 25 Aug 2004 05:18:42 GMT,
> Zebee Johnstone <zebee@zip.com.au> wrote:
>> In comp.lang.perl.misc on Wed, 25 Aug 2004 04:31:43 GMT
>> Jürgen Exner <jurgenex@hotmail.com> wrote:
>>>
>>>> That's a huge discrepancy, so
>>>> there's something that's not being counted.
>>>
>>> Not at all. It's just the trivial fact that usually the size of a file and
>>> the amount of disk space it occupies are not identical and in some cases can
>>> be very different, e.g. for sparse files.
>>
>> Which is something not being counted :) If only unused blocks...
>>
>> I want to take enough files to fit on a CD and put those files in
>> a directory and then make an CD from the directory.
>>
>> If -s won't do it, what will? Or do I just use du in backticks?
>
> Have you tried
>
> my ($block_size, $blocks) = (stat $_)[11, 12];
> my $du_size = $block_size * $blocks;
>
> If your find doesn't span multiple file systems, $block_size probably
> is constant, and you can optimise that out. Even if you span multiple
> file systems, the chance is still high that $block_size is constant.
On my system multiplying those two numbers doesn't work.
; echo a >test.file
; perl -le 'print join "\t", (stat "test.file")[11, 12]'
4096 8
;
Clearly the file uses 1 block (it is only 1 byte) but it is
reported as using 8. It seems to be reporting the block
count in terms of 512 byte blocks even though 4096 byte
blocks are actually used.
Of course (as shown in my other posts) my system seems
a little strange (with a strangely behaving du...)
I'd still argue that taking the file size and rounding up to
a multiple of the blocksize of the CD file system you are
going to create is the only correct approach. But I
know next to nothing about the specifics of those file
systems so there could be tail packing or something to
ruin that approach...
--
Sam Holden
------------------------------
Date: Wed, 25 Aug 2004 04:36:11 GMT
From: Clint Olsen <clint@0lsen.net>
Subject: 5.8.5 make test fails on lib/ExtUtils/Constant with icc
Message-Id: <slrncio5pr.1gei.clint@belle.0lsen.net>
I successfully built Perl 5.8.4 with icc and all went well, but for some
reason 5.8.5 is giving me trouble. The test fails on #27, but my biggest
problem is that I don't know how to reproduce the environment make is
setting up in order to run the test. When I try running various
incarnations, I get Perl complaining about not being able to find Config.pm
in @INC etc. The instructions seem to cater toward running the base tests
manually.
Can anyone throw me a clue on how to run this test by hand so I can figure
out what the heck is happening?
Thanks,
-Clint
------------------------------
Date: Wed, 25 Aug 2004 07:56:16 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: 5.8.5 make test fails on lib/ExtUtils/Constant with icc
Message-Id: <2p2o04FfnjljU1@uni-berlin.de>
Also sprach Clint Olsen:
> I successfully built Perl 5.8.4 with icc and all went well, but for some
> reason 5.8.5 is giving me trouble. The test fails on #27, but my biggest
> problem is that I don't know how to reproduce the environment make is
> setting up in order to run the test. When I try running various
> incarnations, I get Perl complaining about not being able to find Config.pm
> in @INC etc. The instructions seem to cater toward running the base tests
> manually.
>
> Can anyone throw me a clue on how to run this test by hand so I can figure
> out what the heck is happening?
When being in the top-level directory of the source-tree, do:
$ cd t
$ ./TEST base/*.t
Note sure how much this is going to help you. The 27th test appears to
be in base/lex.t so it's apparently something fishy with the Perl lexer.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Tue, 24 Aug 2004 23:07:41 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Can this code be better?
Message-Id: <cgge7e$eem$1@slavica.ukpost.com>
Lou Moran wrote:
> On Tue, 24 Aug 2004 18:51:22 +0100, Brian McCauley <nobull@mail.com>
> wrote:
>>> $loc =~ s/vpn/v/; #needlessly sets STDIN to one letter
>>> $loc =~ s/not/n/; #needlessly sets STDIN to one letter
>>> # print $loc;
>>
>>Er - why do you have code that is commented as needless?
>>
>
> If I don't comment it I will forget what it does in 6 mos when I open
> this back up.
But if you removed it then you wouldn't need to remember what it does.
A very important rule in programming "write less code (unless doing so
makes your code less readable)".
>>>if ($OS eq "0") {
>>> open (HOSTS, '+> C:/WINNT/system32/drivers/etc/hosts') ; #W2K
>>>} elsif ($OS eq "1") {
>>> open (HOSTS, '+> C:/WINDOWS/system32/drivers/etc/hosts') #XP
>>
>>You should always, yes always, check the retun value from open().
>>
>
> How do you mean?
At the very least
open(...) or die "....: $!";
>
>
>>Why are you opening these files read/write?
>>
>
> To intentionally clobber them.
But Why are you opening these files ***READ***/write?
>>>} else {
>>> die "There is no hosts file." ; #Overwrites the hosts
>>
>>Do not include comments that are totally unrelated to the code.
>
>
> I definitely over comment.
Putting a comment on a die statement that says that it "overwrites the
hosts" is not over commenting - it is totally random commenting.
> I feel like I have to in order to be able
> to reuse the code I write. Some of it is cargo culted and some of it
> is divined through perldocs/ORA/c.l.p.m. and it is likely I will not
> retain its meaning when I revisit it months later.
Random comment not related to the acrtion or function of the code will
not aid in this.
------------------------------
Date: Tue, 24 Aug 2004 23:47:57 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Can this code be better?
Message-Id: <cgggiu$elb$2@slavica.ukpost.com>
John W. Krahn wrote:
> Brian McCauley wrote:
>
>> chomp my $loc = lc <STDIN>;
>
> Precedence Brian! You need parentheses for chomp to do the right thing.
>
> chomp( my $loc = lc <STDIN> );
Oops.
------------------------------
Date: Tue, 24 Aug 2004 22:42:56 GMT
From: $_@_.%_
Subject: Re: Dereferencing Objects
Message-Id: <QvPWc.8057$VY.1483@trndny09>
Ala Qumsieh <notvalid@email.com> wrote in message-id:
<fUOWc.7815$QJ3.3036@newssvr21.news.prodigy.com>
>
>$_@_.%_ wrote:
>
>> Read the docs and looked at the module, there apparently
>> is no method provided to access this information.
>
>What information are you talking about exactly? :)
>What is it that you want to get to?
>
>> IO::LineBufferedSessionData appears to be some sort of wrapper for
>> another module named IO::SessionData.
>
>It is a sub-class of IO::SessionData which means it inherits any methods
>and package vars defined in IO::SessionData.
>
>> Im a bit fuzzy on this.. Ive not started OO with exception to
>> seperating data stuff from function stuff.
>
> perldoc perltoot
>
>is a good start.
>
>> Is there another way to dereference this data?
>
>It's simply a hash. You can use keys() to access its keys, and so on.
>But I don't advise this. It's best to stick with its API. I haven't used
>it before, but it seems to be encapsulating some sort of handle. The
>following methods are defined:
>
> read()
> getline()
> write()
> close()
>
>among others. I presume you can do everything you want to do with a
>handle using those methods alone. Or are you looking for something else?
>
>--Ala
Nod.. looking for something else <g>
Since the 'accept' is being not called from IO::Socket but
rather from IO::LineBufferedSessionData I have no apparent way to obtain
the IP address of the connecting client from the data already gathered at
that point (without dereferencing this data).
------------------------------
Date: Wed, 25 Aug 2004 08:24:38 +1000
From: Sisyphus <kalinaubears@iinet.net.au>
Subject: Re: Exange of informations and objects between PERL and JAVA
Message-Id: <412bc156$0$22836$5a62ac22@per-qv1-newsreader-01.iinet.net.au>
Lionel wrote:
> Hi all,
>
> I would like having more informations on how we could exchange
> informations and/or objects between PERL and JAVA.
>
> We have a Java programs that open, maintain and close telnet
> connections, for PERL scripts...
>
> Is it possible, to echange the Java telnet session object to PERL
> programs ? Or thoses two languages could not exchange objects or such
> structure ?
>
> If it's not possible, how could I exchange textual informations
> between a Java program and a PERL script on the same UNIX computer ?
> Socket, Pipe,... ?
>
> Or mayby, there is another solution ?
>
The Inline::Java module might be able to help you out here.
Cheers,
Rob
--
To reply by email u have to take out the u in kalinaubears.
------------------------------
Date: 24 Aug 2004 22:50:41 -0700
From: dn_perl@hotmail.com (dn_perl@hotmail.com)
Subject: Oracle's RPAD problematic via Perl's DBI module
Message-Id: <97314b5b.0408242150.216b914c@posting.google.com>
The following code is returning an unexpected result.
(Untested cut-n-paste; apologies)
Say the table is : students(name CHAR(8))
Entries in Students are : ' ' (8 blanks),
'bob ' and 'dave ' .
use strict ;
use DBI ;
my $st_name = " " ; # non-blank name
my $dstmt = $dbh->prepare("select count(*) from students
where name = RPAD(?,8) ") ; # STMT AA
$dstmt->execute($st_name) or die "sql call failed";
my $num_entries = $dstmt->fetchrow() ;
$dstmt->finish ;
$num_entries should be set to 1; instead it is set to 0.
This problem occurs only for a blank string.
If $st_name = "dave" , then the statements work properly.
If I run the query via sqlplus :
select count(*) from students where name = RPAD(' ',8) ,
the result is 1, as expected.
I am using the getaround :
my $dstmt = $dbh->prepare("select count(*) from students
where trim(name) = ? or (name = ' ' and trim(?) is null) ") ;
$dstmt->execute($st_name, $st_name) or die "sql call failed";
But still I am surprised why STMT AA (above) fails to return
the expected result.
-----------
------------------------------
Date: Tue, 24 Aug 2004 22:24:00 GMT
From: Zebee Johnstone <zebee@zip.com.au>
Subject: Re: Parsing FileName for upload
Message-Id: <slrncinflk.cfp.zebee@zeus.zipworld.com.au>
In comp.lang.perl.misc on 24 Aug 2004 14:49:59 -0700
Tony McGuire <tony@paradoxcommunity.com> wrote:
>
> I've been going batty trying to figure out a routine that will detect
> when there is a full path sent and parse the file name from that path,
> and when there is only a file name sent.
can you give exmaples of the strings you expect?
Don't forget IE on mac :) what strings does that send?
What problems did you have parsing the strings?
Zebee
------------------------------
Date: Tue, 24 Aug 2004 23:45:46 +0100
From: Brian McCauley <nobull@mail.com>
Subject: Re: Parsing FileName for upload
Message-Id: <cggges$elb$1@slavica.ukpost.com>
Tony McGuire wrote:
> If a user selects a file on a Windows box, with IE at least, the FULL
> PATH of the file on the user's system is transmitted to the server.
>
> If the user does the same thing using Opera on a Linux box, and
> apparently Firebird, then only the specific filename gets transmitted
> to the server.
>
> I've been going batty trying to figure out a routine that will detect
> when there is a full path sent and parse the file name from that path,
> and when there is only a file name sent.
>
> I would dearly appreciate anyone who can help with this. I found many
> references to parsing filenames, but nothing I could translate or make
> work for this specific situation.
You problem is fundamentally insoluble. This, of course, is not related
to Perl.
Your problem can be restated as "given a string in which one or more
unspecified characters may act as delimiters extract the portion after
the last delimiter".
In practice however it's usually a valid assumption that the delimiter
is either '/' or '\' an the other one won't appear so you can use
/([^\\\/]+$)/.
------------------------------
Date: Wed, 25 Aug 2004 00:05:59 GMT
From: Joe Davison <haltingNOSPAM@comcast.net>
Subject: performance surprise -- why?
Message-Id: <m2eklwxesi.fsf@Jupiter.local>
I'm searching the genome with a perl script I wrote and encountered a
surprise when I tried to improve the performance -- it got worse, much
worse, and I'm wondering if there's a better way to do my second effort.
Here's the basic problem:
Given a short sequence, say AGTACT, and a chromosome, say
CCCTAAACCCTAAACCCTAAACCCTAAACCTCTGAATCCTTAATCCCTAAATCCCTAAAT...(30MB string).
I want to find all the places in the chromosome where the sequence
occurs.
Method 1: $genome =~ s/($sequence)/\n$1/g;
I then wrote the chopped string to a file and counted the lengths of the
lines using a simple awk program (don't worry about why).
That runs in about 4 seconds on my G3 iBook. But I figured I didn't
really need a second copy of a 30MB file that differed only in the
placement and number of newlines, so why not just save the positions
where it starts? I looked at somebody else's code and tried:
Method 2: $_=$genome;
while( m/$sequence/g) { push @indices,pos();}
and then write out the indices.
I only waited half an hour on my iBook before I killed that one.
I tried again with a couple of smaller files on my G4 desktop.
Method 5MB time 11MB time
1 2.6 sec 5.1 sec
2 48.1 sec 3:20.2 = 200.2 sec
I could give more details, but I tried things like preallocating the
space for @indices without much difference.
It also seems that method 2 is O(N^2). I figure pos() must count chars
from the front every time.
Isn't there a better way to get the position of the last match?
I recognize the benefit in not breaking out of the RE engine, but I'm
surprised at the difference.
Am I missing something completely?
joe
------------------------------
Date: Wed, 25 Aug 2004 01:01:02 GMT
From: kent fritz <ztirftnek-usenet@yahoo.com>
Subject: Re: performance surprise -- why?
Message-Id: <ixRWc.11271$9T1.3878@newssvr27.news.prodigy.com>
Try:
Method 2: $_=$genome;
while( m/$sequence/go) { push @indices,pos();}
I think your regex is recompiling every time. It wouldn't in method #1.
------------------------------
Date: Wed, 25 Aug 2004 02:54:39 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: performance surprise -- why?
Message-Id: <x7d61gexmi.fsf@mail.sysarch.com>
>>>>> "kf" == kent fritz <ztirftnek-usenet@yahoo.com> writes:
kf> Try:
kf> Method 2: $_=$genome;
kf> while( m/$sequence/go) { push @indices,pos();}
kf> I think your regex is recompiling every time. It wouldn't in method #1.
BZZZT! that makes no sense. in neither case is the regex recompiling as
$sequence doesn't change (and /o is fairly obsolete now).
my guess is the difference between munging a string and allocating
scalars for the push. in the first case perl will start building up a
new string and just append stuff as the s///g proceeds so that is fairly
fast. in the second case a new scalar has to be allocated (which takes
time) for each match.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Tue, 24 Aug 2004 23:03:26 -0400
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: performance surprise -- why?
Message-Id: <WjTWc.14585$_H5.460322@news20.bellglobal.com>
"Joe Davison" <haltingNOSPAM@comcast.net> wrote in message
news:m2eklwxesi.fsf@Jupiter.local...
> I'm searching the genome with a perl script I wrote and encountered a
> surprise when I tried to improve the performance -- it got worse, much
> worse, and I'm wondering if there's a better way to do my second effort.
>
> Here's the basic problem:
>
> Given a short sequence, say AGTACT, and a chromosome, say
> CCCTAAACCCTAAACCCTAAACCCTAAACCTCTGAATCCTTAATCCCTAAATCCCTAAAT...(30MB
string).
>
> I want to find all the places in the chromosome where the sequence
> occurs.
>
> Method 1: $genome =~ s/($sequence)/\n$1/g;
> I then wrote the chopped string to a file and counted the lengths of the
> lines using a simple awk program (don't worry about why).
>
> That runs in about 4 seconds on my G3 iBook. But I figured I didn't
> really need a second copy of a 30MB file that differed only in the
> placement and number of newlines, so why not just save the positions
> where it starts? I looked at somebody else's code and tried:
>
> Method 2: $_=$genome;
> while( m/$sequence/g) { push @indices,pos();}
> and then write out the indices.
>
> I only waited half an hour on my iBook before I killed that one.
>
You want foreach, otherwise you get an endless loop (because if the pattern
matches it will keep on matching forever if you're not operating on the
string). As an example, try the following:
my $str = 123454321;
foreach ($str =~ s/1/2/) {
print 1;
}
while ($str =~ /2/) {
print 2;
}
And see if you don't get a whole lot of 2's... : )
Matt
------------------------------
Date: Tue, 24 Aug 2004 23:07:08 -0400
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: performance surprise -- why?
Message-Id: <onTWc.14589$_H5.461307@news20.bellglobal.com>
"Matt Garrish" <matthew.garrish@sympatico.ca> wrote in message
news:WjTWc.14585$_H5.460322@news20.bellglobal.com...
>
> "Joe Davison" <haltingNOSPAM@comcast.net> wrote in message
> news:m2eklwxesi.fsf@Jupiter.local...
> > I'm searching the genome with a perl script I wrote and encountered a
> > surprise when I tried to improve the performance -- it got worse, much
> > worse, and I'm wondering if there's a better way to do my second effort.
> >
> > Here's the basic problem:
> >
> > Given a short sequence, say AGTACT, and a chromosome, say
> > CCCTAAACCCTAAACCCTAAACCCTAAACCTCTGAATCCTTAATCCCTAAATCCCTAAAT...(30MB
> string).
> >
> > I want to find all the places in the chromosome where the sequence
> > occurs.
> >
> > Method 1: $genome =~ s/($sequence)/\n$1/g;
> > I then wrote the chopped string to a file and counted the lengths of the
> > lines using a simple awk program (don't worry about why).
> >
> > That runs in about 4 seconds on my G3 iBook. But I figured I didn't
> > really need a second copy of a 30MB file that differed only in the
> > placement and number of newlines, so why not just save the positions
> > where it starts? I looked at somebody else's code and tried:
> >
> > Method 2: $_=$genome;
> > while( m/$sequence/g) { push @indices,pos();}
> > and then write out the indices.
> >
> > I only waited half an hour on my iBook before I killed that one.
> >
>
> You want foreach, otherwise you get an endless loop (because if the
pattern
> matches it will keep on matching forever if you're not operating on the
> string). As an example, try the following:
>
> my $str = 123454321;
>
> foreach ($str =~ s/1/2/) {
> print 1;
> }
>
> while ($str =~ /2/) {
> print 2;
> }
>
> And see if you don't get a whole lot of 2's... : )
>
That's what I get for skimming. I jumped to conclusions based on your
observation without looking at the modifiers on your regex. The above is not
pertinent in this case...
Matt
------------------------------
Date: Tue, 24 Aug 2004 23:21:09 -0400
From: "Gary" <reachus@netlink.info>
Subject: PHP in a Perl Script
Message-Id: <MATWc.141004$Oi.85750@fed1read04>
I am calling a perl script that writes a WEB page - Plain and simple except
that the perl script also writes out some PHP processing. All works fine
when I just create an html file of the program but when I use perl to write
it the php tags are ignored ?
I have the apache Xbithack on so php is parsed for all html files and the
perl script says it is an html file as below.
This code is called from a WEB page
#!/usr/local/bin/perl
print <<END;
Content-type: text/html
<?php
SCRIPT etc etc
?>
END
PHP tags are just printed on the screen.
Any pointers.
Gary
------------------------------
Date: Wed, 25 Aug 2004 05:27:36 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: PHP in a Perl Script
Message-Id: <2p2fc2FgbeqfU1@uni-berlin.de>
Gary wrote:
> I am calling a perl script that writes a WEB page - Plain and
> simple except that the perl script also writes out some PHP
> processing. All works fine when I just create an html file of the
> program but when I use perl to write it the php tags are ignored ?
Doesn't PHP require the file extension .php?
Btw, what has your question to do with the Perl programming language?
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 25 Aug 2004 04:48:47 GMT
From: John Bokma <postmaster@castleamber.com>
Subject: Re: PHP in a Perl Script
Message-Id: <Xns954FF22F61391castleamber@130.133.1.4>
"Gary" <reachus@netlink.info> wrote in
news:MATWc.141004$Oi.85750@fed1read04:
> I am calling a perl script that writes a WEB page - Plain and simple
> except that the perl script also writes out some PHP processing. All
> works fine when I just create an html file of the program but when I
> use perl to write it the php tags are ignored ?
>
> I have the apache Xbithack on so php is parsed for all html files and
> the perl script says it is an html file as below.
>
> This code is called from a WEB page
>
> #!/usr/local/bin/perl
> print <<END;
> Content-type: text/html
>
> <?php
> SCRIPT etc etc
> ?>
> END
>
> PHP tags are just printed on the screen.
Just a wild guess, I think this by passes the webserver. The webserver
does the execution of PHP and it is being asked to execute (Perl) CGI
now.
If that's the actual script you are using, why? What can you do in PHP
you can't in Perl (ok, I am kidding :-D)
Post real code, and ask real questions.
--
John MexIT: http://johnbokma.com/mexit/
personal page: http://johnbokma.com/
Experienced programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html
------------------------------
Date: Wed, 25 Aug 2004 06:12:57 +0000 (UTC)
From: dkcombs@panix.com (David Combs)
Subject: Re: The Perl Journal Vols 1 - 18, & 20
Message-Id: <cghal9$eup$1@reader1.panix.com>
In article <f%ANc.23219$i_2.997197@news20.bellglobal.com>,
Matt Garrish <matthew.garrish@sympatico.ca> wrote:
>
>"Greg Schmidt" <gregs@trawna.com> wrote in message
>news:8y6n3w9i8xfr.dlg@trawna.com...
>> On Mon, 26 Jul 2004 19:17:33 -0400, Matt Garrish wrote:
>>
>> > "Ray Sutton" <rlsutton@chartermi.net> wrote in message
>> > news:cf239c11.0407261251.6527063c@posting.google.com...
>> >> I have original Perl Journals #1 through #18 and #20. I will sell them
>> >> only as a set. They are in perfect condition. A real bargain at $75
>> >> plus shipping. Contact me at rlsutton@chartermi.net. Thank you.
>> >
>> > But all the best articles were in issue #19. Just doesn't seem worth the
>> > price without it...
>>
>> Just guessing here.... you had an article in issue 19? :-)
>>
>
>No, I just don't like reading advertisements in a technical newsgroup... : )
>
>Matt
>
>
Can't you get all these on the CD that has
all the articles thus far from System Administration (magazine)?
Or was the Perl Journal something entirely different?
David
------------------------------
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 6907
***************************************
