[31586] in Perl-Users-Digest
Perl-Users Digest, Issue: 2845 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 2 18:09:27 2010
Date: Tue, 2 Mar 2010 15:09:11 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 2 Mar 2010 Volume: 11 Number: 2845
Today's topics:
Re: Can you compile a perl executable? <tadmc@seesig.invalid>
Re: flushing buffer for printing to the screen <uri@StemSystems.com>
Re: flushing buffer for printing to the screen <willem@snail.stack.nl>
Re: flushing buffer for printing to the screen <ben@morrow.me.uk>
Re: flushing buffer for printing to the screen <efoss@fhcrc.org>
Re: flushing buffer for printing to the screen <uri@StemSystems.com>
Re: flushing buffer for printing to the screen <uri@StemSystems.com>
Re: flushing buffer for printing to the screen <hjp-usenet2@hjp.at>
Re: flushing buffer for printing to the screen <uri@StemSystems.com>
Re: how to speed up a string-substitution loop? <uri@StemSystems.com>
Re: how to speed up a string-substitution loop? <uri@StemSystems.com>
Re: Search a Large files backwards <mud_saisem@hotmail.com>
Re: Search a Large files backwards <sreservoir@gmail.com>
Re: Search a Large files backwards <tadmc@seesig.invalid>
Re: Search a Large files backwards <tadmc@seesig.invalid>
Re: Search a Large files backwards <uri@StemSystems.com>
Re: Search a Large files backwards <uri@StemSystems.com>
strange behavior <efoss@fhcrc.org>
Re: strange behavior <uri@StemSystems.com>
Re: strange behavior <ben@morrow.me.uk>
Re: strange behavior <efoss@fhcrc.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 02 Mar 2010 14:09:40 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Can you compile a perl executable?
Message-Id: <slrnhoqrt0.ake.tadmc@tadbox.sbcglobal.net>
Steve <steve@staticg.com> wrote:
> On Mar 2, 10:08 am, Jürgen Exner <jurge...@hotmail.com> wrote:
>> Steve <st...@staticg.com> wrote:
>> >If I made an application, and wanted to make it portable, is it
>> >possible to compile it into a single binary?
>>
>> See "perldoc -q compile":
>> Â Â Â Â "How can I compile my Perl program into byte code or C?"
> Thanks!
Can it be that you did not search the Perl FAQ before
posting to the Perl newsgroup?
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Tue, 02 Mar 2010 14:29:35 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <87ljeawmhs.fsf@quad.sysarch.com>
>>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:
JE> "efoss@fhcrc.org" <efoss@fhcrc.org> wrote:
>> I want to be certain that a print statement is immediately executed.
>> Googling around led me to use "$| = 1". Is this correct? Here is an
>> example of how I'm using it:
>>
>> $| = 1;
>> $test = 3;
>> print "test is $test\n";
JE> Yes, that is the correct use of $|.
actually that never uses $| ! the print string ends in newline so it
will always be flushed to stdout. $| is meant for when you print text
without a newline (say a prompt or partial output or to a socket).
also since the program ends there, you also won't see any difference
with setting $| or not as stdout gets flushed then as well. you need to
print a string without a newline and then sleep or wait for input or
something to see the difference.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 2 Mar 2010 20:41:26 +0000 (UTC)
From: Willem <willem@snail.stack.nl>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <slrnhoqtvm.2ik7.willem@snail.stack.nl>
Uri Guttman wrote:
) actually that never uses $| ! the print string ends in newline so it
) will always be flushed to stdout. $| is meant for when you print text
) without a newline (say a prompt or partial output or to a socket).
)
) also since the program ends there, you also won't see any difference
) with setting $| or not as stdout gets flushed then as well. you need to
) print a string without a newline and then sleep or wait for input or
) something to see the difference.
AFAIK, not true if stdout is redirected to a file.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Tue, 2 Mar 2010 21:42:07 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <fad067-o62.ln1@osiris.mauzo.dyndns.org>
Quoth "Uri Guttman" <uri@StemSystems.com>:
> >>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:
>
> JE> "efoss@fhcrc.org" <efoss@fhcrc.org> wrote:
> >> I want to be certain that a print statement is immediately executed.
> >> Googling around led me to use "$| = 1". Is this correct? Here is an
> >> example of how I'm using it:
> >>
> >> $| = 1;
> >> $test = 3;
> >> print "test is $test\n";
>
> JE> Yes, that is the correct use of $|.
>
> actually that never uses $| ! the print string ends in newline so it
> will always be flushed to stdout. $| is meant for when you print text
> without a newline (say a prompt or partial output or to a socket).
Huh? That's only if the filehandle is line-buffered; AFAIK PerlIO only
supports line-buffering for direct output to a tty.
Ben
------------------------------
Date: Tue, 2 Mar 2010 13:58:45 -0800 (PST)
From: "efoss@fhcrc.org" <efoss@fhcrc.org>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <c4c08485-83a1-439b-99a4-153f3a5aa1ad@e19g2000prn.googlegroups.com>
Thanks all.
Eric
------------------------------
Date: Tue, 02 Mar 2010 17:07:41 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <877hpuv0lu.fsf@quad.sysarch.com>
>>>>> "W" == Willem <willem@snail.stack.nl> writes:
W> Uri Guttman wrote:
W> ) actually that never uses $| ! the print string ends in newline so it
W> ) will always be flushed to stdout. $| is meant for when you print text
W> ) without a newline (say a prompt or partial output or to a socket).
W> )
W> ) also since the program ends there, you also won't see any difference
W> ) with setting $| or not as stdout gets flushed then as well. you need to
W> ) print a string without a newline and then sleep or wait for input or
W> ) something to see the difference.
W> AFAIK, not true if stdout is redirected to a file.
then the original question is moot. obviously he is asking about stdout
to a terminal where this matters (or a socket which i covered). and for
sockets, the correct call is syswrite anyhow. you can even use it for
stdout and bypass all buffering and not need to deal with $|.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 02 Mar 2010 17:08:54 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <873a0iv0jt.fsf@quad.sysarch.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> Quoth "Uri Guttman" <uri@StemSystems.com>:
>> >>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:
>>
JE> "efoss@fhcrc.org" <efoss@fhcrc.org> wrote:
>> >> I want to be certain that a print statement is immediately executed.
>> >> Googling around led me to use "$| = 1". Is this correct? Here is an
>> >> example of how I'm using it:
>> >>
>> >> $| = 1;
>> >> $test = 3;
>> >> print "test is $test\n";
>>
JE> Yes, that is the correct use of $|.
>>
>> actually that never uses $| ! the print string ends in newline so it
>> will always be flushed to stdout. $| is meant for when you print text
>> without a newline (say a prompt or partial output or to a socket).
BM> Huh? That's only if the filehandle is line-buffered; AFAIK PerlIO only
BM> supports line-buffering for direct output to a tty.
and the bare print in his code goes to stdout which goes to the tty by
default. hence my comments which assumed those things. otherwise $| is
fairly useless. see my other post for more.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 2 Mar 2010 23:03:06 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <slrnhor2oq.v1.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-02 19:29, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:
> JE> "efoss@fhcrc.org" <efoss@fhcrc.org> wrote:
> >> I want to be certain that a print statement is immediately executed.
> >> Googling around led me to use "$| = 1". Is this correct? Here is an
> >> example of how I'm using it:
> >>
> >> $| = 1;
> >> $test = 3;
> >> print "test is $test\n";
>
> JE> Yes, that is the correct use of $|.
>
> actually that never uses $| ! the print string ends in newline so it
> will always be flushed to stdout. $| is meant for when you print text
> without a newline (say a prompt or partial output or to a socket).
No. When the file handle (here STDOUT) doesn't point to a tty, it is
only flushed when the buffer is full not after each line.
> also since the program ends there, you also won't see any difference
> with setting $| or not as stdout gets flushed then as well.
This is correct.
hp
------------------------------
Date: Tue, 02 Mar 2010 17:32:49 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: flushing buffer for printing to the screen
Message-Id: <878waatkvi.fsf@quad.sysarch.com>
>>>>> "PJH" == Peter J Holzer <hjp-usenet2@hjp.at> writes:
PJH> On 2010-03-02 19:29, Uri Guttman <uri@StemSystems.com> wrote:
>>>>>>> "JE" == Jürgen Exner <jurgenex@hotmail.com> writes:
JE> "efoss@fhcrc.org" <efoss@fhcrc.org> wrote:
>> >> I want to be certain that a print statement is immediately executed.
>> >> Googling around led me to use "$| = 1". Is this correct? Here is an
>> >> example of how I'm using it:
>> >>
>> >> $| = 1;
>> >> $test = 3;
>> >> print "test is $test\n";
>>
JE> Yes, that is the correct use of $|.
>>
>> actually that never uses $| ! the print string ends in newline so it
>> will always be flushed to stdout. $| is meant for when you print text
>> without a newline (say a prompt or partial output or to a socket).
PJH> No. When the file handle (here STDOUT) doesn't point to a tty, it is
PJH> only flushed when the buffer is full not after each line.
but as i keep posting, the code as shown goes to stdout and the tty
unless he redirects it. it is obvious he is looking for the support of
print to the terminal without a newline. that is almost the only real
use for $|.
>> also since the program ends there, you also won't see any difference
>> with setting $| or not as stdout gets flushed then as well.
PJH> This is correct.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 02 Mar 2010 14:23:40 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <87tysywmrn.fsf@quad.sysarch.com>
>>>>> "AK" == Adam Kellas <adam.kellas@gmail.com> writes:
AK> On Mar 2, 1:06 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>> can you make a pattern that would match ANY of the strings you want to
>> match? even a alternation might do well enough. then you can do a
>> single s/// with the replacement value being looked up in the $variables
>> (poor name) hash.
AK> Thanks, I will try this.
>> also why would speed be an issue here? it looks like it would be done
>> off line to fix up makefile output.
AK> You're right, this is done more or less off line and in theory should
AK> not be too performance sensitive. But this exhibits really
AK> pathological behavior - for reasons I don't understand, though it
AK> works fine in small unit-test setups it can appear to hang for hours
AK> on end in real-world situations. During that time strace shows that
AK> perl is calling the brk() system call over and over.
you would have to post all the code and some data and hopefully that
would exhibit the problem. calling brk() means you are doing serious
data allocation which shouldn't happen in this style of code. maybe you
are doing something else that you didn't tell us. s/// ops on a string
may add some ram needs but not insane amounts. massive unnecessary ram
needs are usually leaks, either a rare perl bug or some poorly designed
data structure that leaks.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 02 Mar 2010 14:26:58 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: how to speed up a string-substitution loop?
Message-Id: <87pr3mwmm5.fsf@quad.sysarch.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> As a rule of thumb, any single perl op (s/// is a single op) is likely
BM> to be faster than the equivalent algorithm using multiple ops (substr,
BM> index, the assignment and the while loop add up to quite a lot of ops
BM> between them). Lvalue substr is also likely to be slower than 4-arg
BM> substr (since it's much more magical).
totally agree. perl guts are almost always faster than the equivilent in
perl lang. the rule is to try to stay inside perl as much as
possible. there are a few exceptions but not in this case.
BM> Your post xthread (about the process sitting in brk(2)) suggests a lot
BM> of string copying. You could try running through the source string and
BM> building a single result string as an alternative, which should avoid
BM> most of the copying. If you have some idea of an upper bound on the
BM> length of the destination string (if your de-substitutions always make
BM> the string shorter, for instance) you could even try preallocating the
BM> destination string like this:
BM> my $dest = "x" x $dest_size;
BM> $dest = "";
and my solution of a single s///g with all the keys and lookup in a hash
for the replacement will speed it up. fewer ops and much less realloc as
it will build up a single new string as it does the replacements. it may
realloc some but nowhere like with the lvalue substr and such the OP
used.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 2 Mar 2010 12:11:51 -0800 (PST)
From: mud_saisem <mud_saisem@hotmail.com>
Subject: Re: Search a Large files backwards
Message-Id: <7fa33962-72e4-47cd-97f8-a6e06b2075d8@u19g2000prh.googlegroups.com>
On Mar 2, 6:34=A0pm, "Uri Guttman" <u...@StemSystems.com> wrote:
> >>>>> "ms" =3D=3D mud saisem <mud_sai...@hotmail.com> writes:
>
> =A0 >> why no modules? that is always a bad excuse. you can always cut/pa=
ste
> =A0 >> the code in the worst case or use local::lib to install them local=
ly.
> =A0 >>
> =A0 >> so the answer is to use File::ReadBackwards
>
> =A0 ms> The point of not using modules is because I would like to learn
> =A0 ms> and understand how to achieve this first. Simply using the module
> =A0 ms> because it is easy is not going to teach me anything.
>
> you didn't say that. it helps to know your motivation.
>
> and you can learn how to do it well by studying the code in the
> module. writing it for yourself may not show you all that you need to
> learn to do it well. it happens to be written by me and it needs to do
> more than a simple loop to handle all the cases and be fast and easy to
> use.
>
> =A0 ms> I don't understand why you say not using the module is a bad
> =A0 ms> excuse ?
>
> because we get people here who say they can't use modules and have many
> poor excuses for why they can't. it is a common whine.
>
> uri
>
> --
> Uri Guttman =A0------ =A0u...@stemsystems.com =A0-------- =A0http://www.s=
ysarch.com--
> ----- =A0Perl Code Review , Architecture, Development, Training, Support =
------
> --------- =A0Gourmet Hot Cocoa Mix =A0---- =A0http://bestfriendscocoa.com=
---------
Yes, I have no problems with modules or using modules. I just wanted
to find away to do it without a module.
I don't want to be a perl programer that has to rely on other
programmers work or solutions, even though they are developed from
very good programmers such as yourself.
I must admit that I am quite surprised that a developer with your
calibre is in google groups offering support and help to others.
I will take your advise onboard and download your module and study the
code. I am not sure how much of it I will follow, but I will give it a
shot anyway.
------------------------------
Date: Tue, 02 Mar 2010 15:53:22 -0500
From: sreservoir <sreservoir@gmail.com>
Subject: Re: Search a Large files backwards
Message-Id: <hmjts7$af9$1@speranza.aioe.org>
On 3/2/2010 3:11 PM, mud_saisem wrote:
> Yes, I have no problems with modules or using modules. I just wanted
> to find away to do it without a module.
> I don't want to be a perl programer that has to rely on other
> programmers work or solutions, even though they are developed from
> very good programmers such as yourself.
problem: you can't. somebody else wrote and probably compiled your perl.
> I must admit that I am quite surprised that a developer with your
> calibre is in google groups offering support and help to others.
it's usenet. and most of us are volunteers.
> I will take your advise onboard and download your module and study the
> code. I am not sure how much of it I will follow, but I will give it a
> shot anyway.
it is comment-a-line code; I find it easy to understand, but a bit
difficult to read. matter of opinion, though.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
------------------------------
Date: Tue, 02 Mar 2010 14:58:17 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Search a Large files backwards
Message-Id: <slrnhoquo5.apc.tadmc@tadbox.sbcglobal.net>
mud_saisem <mud_saisem@hotmail.com> wrote:
>> --
>> Uri Guttman  ------  u...@stemsystems.com  --------  http://www.sysarch.com--
>> ----- Â Perl Code Review , Architecture, Development, Training, Support ------
>> ---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com---------
It is bad manners to quote .sigs.
Have you seen the Posting Guidelines that are posted here frequently?
> I must admit that I am quite surprised that a developer with your
> calibre
Puhleeze! He's already big-headed, encouragement is uncalled for.
:-)
> is in google groups offering support and help to others.
He is NOT in google groups.
He is in the comp.lang.perl.misc Usenet newsgroup.
Google has no connection to this newsgroup, other merely providing
a (poor) interface to it.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Tue, 02 Mar 2010 15:06:34 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Search a Large files backwards
Message-Id: <slrnhoqv7m.at5.tadmc@tadbox.sbcglobal.net>
sreservoir <sreservoir@gmail.com> wrote:
> On 3/2/2010 3:11 PM, mud_saisem wrote:
>> Yes, I have no problems with modules or using modules. I just wanted
>> to find away to do it without a module.
>> I don't want to be a perl programer that has to rely on other
^^^^^^^^^^^^^^
>> programmers work or solutions, even though they are developed from
>> very good programmers such as yourself.
>
> problem: you can't. somebody else wrote and probably compiled your perl.
In case you are wondering what sreservoir is going on about:
perldoc -q 'perl.*Perl'
What's the difference between "perl" and "Perl"?
That is, you meant "Perl programmer" above.
A "perl programmer" is a C programmer!
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
------------------------------
Date: Tue, 02 Mar 2010 16:57:54 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Search a Large files backwards
Message-Id: <87fx4iv125.fsf@quad.sysarch.com>
>>>>> "ms" == mud saisem <mud_saisem@hotmail.com> writes:
ms> On Mar 2, 6:34 pm, "Uri Guttman" <u...@StemSystems.com> wrote:
>>
>> because we get people here who say they can't use modules and have many
>> poor excuses for why they can't. it is a common whine.
ms> Yes, I have no problems with modules or using modules. I just
ms> wanted to find away to do it without a module. I don't want to be
ms> a perl programer that has to rely on other programmers work or
ms> solutions, even though they are developed from very good
ms> programmers such as yourself.
relying on other people's work is the mark of a good programmer. you do
it all the time just by using perl itself or your OS, etc. there is no
way anyone could write up all the code they would want to use today. i
know http well enough but i wouldn't replace LWP with my own code. i
might modify it or offer patches or feature requests, etc.
ms> I must admit that I am quite surprised that a developer with your
ms> calibre is in google groups offering support and help to others.
why not? larry himself used to inhabit this group a decade ago. there
are plenty of top perl coders who help out in one of the many possible
forums (usenet, web, irc, mailing lists, etc.).
ms> I will take your advise onboard and download your module and study
ms> the code. I am not sure how much of it I will follow, but I will
ms> give it a shot anyway.
the code is very straightforward and does exactly what you want with all
the bugs fixed and edge conditions handled. it is better to learn from a
working module than to struggle to write your own. the whole concept of
reading lines backwards requires some deeper understanding of files and
i/o which would take you a good while to learn if you don't know it
yet.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 02 Mar 2010 17:05:57 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Search a Large files backwards
Message-Id: <87bpf6v0oq.fsf@quad.sysarch.com>
>>>>> "s" == sreservoir <sreservoir@gmail.com> writes:
s> On 3/2/2010 3:11 PM, mud_saisem wrote:
>> Yes, I have no problems with modules or using modules. I just wanted
>> to find away to do it without a module.
>> I don't want to be a perl programer that has to rely on other
>> programmers work or solutions, even though they are developed from
>> very good programmers such as yourself.
s> problem: you can't. somebody else wrote and probably compiled your perl.
>> I must admit that I am quite surprised that a developer with your
>> calibre is in google groups offering support and help to others.
s> it's usenet. and most of us are volunteers.
>> I will take your advise onboard and download your module and study the
>> code. I am not sure how much of it I will follow, but I will give it a
>> shot anyway.
s> it is comment-a-line code; I find it easy to understand, but a bit
s> difficult to read. matter of opinion, though.
and which is more important - reading or understanding code? you have to
realize i have been coding for 36 years and doing perl for 17. my style
(commenting included) has evolved to make sure anyone can understand
what i wrote with the least amount of effort. it may be more verbose
than some but the comments are written to explain WHY i did something as
the code is WHAT i did.
here is a tidbit to learn:
code (all the text in a source file) is a record of all your logical
decisions that you made when implementing a program. it is the one place
where your ego should shine forth. you want readers of your code to be
impressed with how much care you put into it thinking about them.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 2 Mar 2010 14:00:16 -0800 (PST)
From: "efoss@fhcrc.org" <efoss@fhcrc.org>
Subject: strange behavior
Message-Id: <861d1938-b211-45f8-bd57-9f752a430f97@m35g2000prh.googlegroups.com>
I've run into a strange problem. I have a program that is a few
hundred lines long. I run it and it runs fine and gives me the correct
output (at least when I check a few of the output calculations
manually.) But here are some screwy things that disturb me:
1. If I comment out a module that I'm not even using, I get a
"Segmentation fault" error. (The difference is "use FileHandle;"
versus "#use FileHandle;".)
2. If I get the "Segmentation fault" error and then I comment out a
numerical sort of an array (which is working correctly), then the
"Segmentation fault" error goes away.
3. If I run the program on my debugger rather than from a terminal,
the program runs fine.
4. If I run the program on a different computer and run it from a
terminal, the program runs fine.
I don't remember ever getting "Segmentation fault" as an error message
in Perl - I think of that as a "C error", since I've seen it many
times writing C code. Does anyone have an idea what's going wrong?
(I'm not posting the code because it's long and I'm quite certain that
the details of the code won't be relevant, but I'm happy to post it.)
Thanks.
Eric
------------------------------
Date: Tue, 02 Mar 2010 17:13:24 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: strange behavior
Message-Id: <87ljeatlrv.fsf@quad.sysarch.com>
>>>>> "eo" == efoss@fhcrc org <efoss@fhcrc.org> writes:
eo> I've run into a strange problem. I have a program that is a few
eo> hundred lines long. I run it and it runs fine and gives me the correct
eo> output (at least when I check a few of the output calculations
eo> manually.) But here are some screwy things that disturb me:
eo> 1. If I comment out a module that I'm not even using, I get a
eo> "Segmentation fault" error. (The difference is "use FileHandle;"
eo> versus "#use FileHandle;".)
FileHandle is obsolete anyhow. never use it. it actually just wraps
IO::Handle. and you rarely need IO::Handle as IO::File or others are
what you want.
eo> 2. If I get the "Segmentation fault" error and then I comment out a
eo> numerical sort of an array (which is working correctly), then the
eo> "Segmentation fault" error goes away.
you are doing something very wrong. hard to divine it with no code.
eo> 3. If I run the program on my debugger rather than from a terminal,
eo> the program runs fine.
eo> 4. If I run the program on a different computer and run it from a
eo> terminal, the program runs fine.
eo> I don't remember ever getting "Segmentation fault" as an error message
eo> in Perl - I think of that as a "C error", since I've seen it many
eo> times writing C code. Does anyone have an idea what's going wrong?
eo> (I'm not posting the code because it's long and I'm quite certain that
eo> the details of the code won't be relevant, but I'm happy to post it.)
perl has rare segment faults. if you can force this everytime, then
report it to p5p (the perl core developers) with the perlbug program.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 2 Mar 2010 22:21:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: strange behavior
Message-Id: <kjf067-fb2.ln1@osiris.mauzo.dyndns.org>
Quoth "efoss@fhcrc.org" <efoss@fhcrc.org>:
> I've run into a strange problem. I have a program that is a few
> hundred lines long. I run it and it runs fine and gives me the correct
> output (at least when I check a few of the output calculations
> manually.) But here are some screwy things that disturb me:
>
> 1. If I comment out a module that I'm not even using, I get a
> "Segmentation fault" error. (The difference is "use FileHandle;"
> versus "#use FileHandle;".)
A segfault is *always* a bug in perl, or in an XS module. This symptom
you describe, of the problem going away when random things are changed
slightly, probably indicates some sort of memory allocation error. If a
piece of code somewhere is (say) dereferencing a pointer after it's been
freed, whether that will segfault or not depends on whether that piece
of memory has been reused yet, and that in turn depends on the exact
details of what has been allocated so far.
Things to try, in order:
- Try it with 5.10.1, in case the bug has been found and fixed. Try
it with the latest versions of any XS modules you are using, for
the same reason.
- Get the 5.11.5 source tarball, build perl with -DDEBUGGING, and
try it with that. If it still fails you're likely to get an
assertion failure much nearer the real bug.
- If you're up to it, provoke a failure under gdb and attempt to
work out what's going on, or run perl under valgrind to check for
allocation errors.
- Report a bug, including as much detail as you can. You need to cut
as much as you can out of your test case without making the
failure go away. This can be tedious, especially with a heisenbug
like this.
Ben
------------------------------
Date: Tue, 2 Mar 2010 15:05:11 -0800 (PST)
From: "efoss@fhcrc.org" <efoss@fhcrc.org>
Subject: Re: strange behavior
Message-Id: <ad50fbd3-9c15-4c97-a562-b40d3867175f@b5g2000prd.googlegroups.com>
On Mar 2, 2:21=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth "ef...@fhcrc.org" <ef...@fhcrc.org>:
>
> > I've run into a strange problem. I have a program that is a few
> > hundred lines long. I run it and it runs fine and gives me the correct
> > output (at least when I check a few of the output calculations
> > manually.) But here are some screwy things that disturb me:
>
> > 1. If I comment out a module that I'm not even using, I get a
> > "Segmentation fault" error. (The difference is "use FileHandle;"
> > versus "#use FileHandle;".)
>
> A segfault is *always* a bug in perl, or in an XS module. This symptom
> you describe, of the problem going away when random things are changed
> slightly, probably indicates some sort of memory allocation error. If a
> piece of code somewhere is (say) dereferencing a pointer after it's been
> freed, whether that will segfault or not depends on whether that piece
> of memory has been reused yet, and that in turn depends on the exact
> details of what has been allocated so far.
>
> Things to try, in order:
> =A0 =A0 - Try it with 5.10.1, in case the bug has been found and fixed. T=
ry
> =A0 =A0 =A0 it with the latest versions of any XS modules you are using, =
for
> =A0 =A0 =A0 the same reason.
>
> =A0 =A0 - Get the 5.11.5 source tarball, build perl with -DDEBUGGING, and
> =A0 =A0 =A0 try it with that. If it still fails you're likely to get an
> =A0 =A0 =A0 assertion failure much nearer the real bug.
>
> =A0 =A0 - If you're up to it, provoke a failure under gdb and attempt to
> =A0 =A0 =A0 work out what's going on, or run perl under valgrind to check=
for
> =A0 =A0 =A0 allocation errors.
>
> =A0 =A0 - Report a bug, including as much detail as you can. You need to =
cut
> =A0 =A0 =A0 as much as you can out of your test case without making the
> =A0 =A0 =A0 failure go away. This can be tedious, especially with a heise=
nbug
> =A0 =A0 =A0 like this.
>
> Ben
Thanks very much. I just tried the first one - installing Perl 5.10.1.
I had 5.10.0 before, which I checked with "perl -v". I then went
here:
http://www.activestate.com/activeperl/downloads/
and I downloaded the recommended version. (I'm using MacOS X with the
Snowleopard operating system.) Below is what it said it recommended:
Recommended version(s) for your platform:
ActivePerl 5.10.1.1007 for Mac OS X (Universal)
I then restarted my computer and tried again and got the same error.
However, then when I tried "perl -v" again, it said that I was using
5.10.0 rather than 5.10.1. I'm puzzled by this, since installing perl
was pretty straight forward - just clicking "next" a bunch of times
and accepting all the default settings. I'll screw around more with
this to see if I can figure out what I'm doing wrong.
Thanks again for your help.
Eric
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2845
***************************************
