[31696] in Perl-Users-Digest
Perl-Users Digest, Issue: 2959 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat May 22 11:09:27 2010
Date: Sat, 22 May 2010 08:09: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 Sat, 22 May 2010 Volume: 11 Number: 2959
Today's topics:
Re: bit-twiddling on 32-bit machines <hjp-usenet2@hjp.at>
Re: bit-twiddling on 32-bit machines <hjp-usenet2@hjp.at>
Re: bit-twiddling on 32-bit machines <hjp-usenet2@hjp.at>
Re: bit-twiddling on 32-bit machines <ben@morrow.me.uk>
Conflict between 32 and 64bit (WAS: FAQ 5.6 How can I c <jurgenex@hotmail.com>
Re: Conflict between 32 and 64bit (WAS: FAQ 5.6 How can <ben@morrow.me.uk>
Re: Debugging question: tracing the origin of an error. <ben@morrow.me.uk>
Re: Efficiently searching multiple files <tadmc@seesig.invalid>
Re: Efficiently searching multiple files <awkster@yahoo.com>
Re: Efficiently searching multiple files sln@netherlands.com
Re: Efficiently searching multiple files <john@castleamber.com>
Re: getting results of multiple simultaneous system com <ben@morrow.me.uk>
Re: How to avoid zombies? <ben@morrow.me.uk>
Re: Where to get the document for a library function in <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 22 May 2010 11:01:18 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhvf7au.3au.hjp-usenet2@hrunkner.hjp.at>
On 2010-05-21 00:56, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> I take it that there is no Perl on 1s complement machines?
This seems very likely.
hp
------------------------------
Date: Sat, 22 May 2010 10:57:53 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhvf74k.3au.hjp-usenet2@hrunkner.hjp.at>
On 2010-05-21 16:24, sln@netherlands.com <sln@netherlands.com> wrote:
> On Thu, 20 May 2010 13:02:08 +0200, "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>>On 2010-05-19 23:56, sln@netherlands.com <sln@netherlands.com> wrote:
>>> On Wed, 19 May 2010 23:44:50 +0100, Ben Morrow <ben@morrow.me.uk> wrote:
>>>>and a C program the does the same operations on a signed 32bit integer
>>> ^^ .........^^
>>> This is redundant. There is only unsigned and int.
>>
>>Wrong. "integer" is not the same as "int". The C standard knows five
>>standard signed integer types and six standard unsigned integer types.
>>And "int" and "unsigned" are just abbreviations of "signed int" and
>>"unsigned int", respectively.
>
> Technically there are no "integer types", they are integral types.
Please read the standard.
hp
------------------------------
Date: Sat, 22 May 2010 11:58:04 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <slrnhvfalc.3au.hjp-usenet2@hrunkner.hjp.at>
On 2010-05-20 14:58, Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote:
> On 2010-05-19, Ben Morrow <ben@morrow.me.uk> wrote:
>> Can you give an example of things not behaving as expected?
>
> I was presuming that such things happens left and right, so I did not
> try to remember the problems people were reporting. But I may try to guess...
>
> And: I do not have Perl with 64-bit IV AND 64-bit NV around, so all
> this is just a conjecture: I expect the the following things to break:
>
> rounding by int($n + 0.t);
what is $n here (conceptually)? An integer? Then it doesn't make sense
to round it. A floating point value? Then adding 0.5 doesn't change the
type and whether IVs are 32 bit or 64 bit doesn't matter.
> $x + 0.5 >= $x
Again, this is already "broken" (i.e., a false assumption) on large
numbers, making IVs 64 bit doesn't change that.
A better example would be where something like
$large_even_integer/2
where the result is exact in integer arithmetic but must be rounded in
FP arithmetic. However, perl (at least since 5.8.8) does the right thing
here: The result is an IV with the exact result. (how does it do this?)
hp
------------------------------
Date: Sat, 22 May 2010 15:09:08 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: bit-twiddling on 32-bit machines
Message-Id: <455lc7-cg2.ln1@osiris.mauzo.dyndns.org>
Quoth "Peter J. Holzer" <hjp-usenet2@hjp.at>:
>
> A better example would be where something like
>
> $large_even_integer/2
>
> where the result is exact in integer arithmetic but must be rounded in
> FP arithmetic. However, perl (at least since 5.8.8) does the right thing
> here: The result is an IV with the exact result. (how does it do this?)
The code is in pp_divide in pp.c. Basically, if there is a chance the
division will produce an exact integer result that can't be represented
as a float, the code will
- make both numbers positive
- do the division in unsigned ints
- if the result was exact (checked with an unsigned-int multiply)
- return an unsigned int if the result should be positive,
- return a (negated) signed int if the result should be negative
and it fits,
- otherwise cast the int to a float and return the negation of
that (which may be inaccurate, but that can't be helped);
- else
- do a floating-point division
Ben
------------------------------
Date: Sat, 22 May 2010 07:03:10 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Conflict between 32 and 64bit (WAS: FAQ 5.6 How can I copy a file?)
Message-Id: <3aofv5d5ml81qoah16l6fdhg483nkstgra@4ax.com>
PerlFAQ Server <brian@theperlreview.com> wrote:
>5.6: How can I copy a file?
> Use the "File::Copy" module. It comes with Perl and can do a true copy
> across file systems, and it does its magic in a portable fashion.
Which reminds me:
The other day I ran into a problem with File::Copy regarding 32 vs. 64
bits. We have a standardized environment which is shared across several
hundred machines, some 32bit, some 64 bit.
When I tried to use File::Copy I got an error message basically stating
that it has been compiled for 32 bit and cannot be run on 64 bit (sorry,
I don't have the exact error message. Happened at work and I would need
to get back to the office for a repro).
Currently I am the OS copy command via system() because I wanted to
avoid doing this:
> If you can't use "File::Copy", you'll have to do the work yourself: open
> the original file, open the destination file, then print to the
> destination file as you read the original. You also have to remember to
> copy the permissions, owner, and group to the new file.
But of course that's not a good solution.
Is there a version of File::Copy that is agnostic to 32/64bit? Or are
there other suggestions for how to deal with a mixed 32/64bit
environment? Using separate environments for 32 and 64 bit machines is
not an option.
jue
------------------------------
Date: Sat, 22 May 2010 15:39:55 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Conflict between 32 and 64bit (WAS: FAQ 5.6 How can I copy a file?)
Message-Id: <ru6lc7-cg2.ln1@osiris.mauzo.dyndns.org>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
> PerlFAQ Server <brian@theperlreview.com> wrote:
> >5.6: How can I copy a file?
> > Use the "File::Copy" module. It comes with Perl and can do a true copy
> > across file systems, and it does its magic in a portable fashion.
>
> Which reminds me:
> The other day I ran into a problem with File::Copy regarding 32 vs. 64
> bits. We have a standardized environment which is shared across several
> hundred machines, some 32bit, some 64 bit.
>
> When I tried to use File::Copy I got an error message basically stating
> that it has been compiled for 32 bit and cannot be run on 64 bit (sorry,
> I don't have the exact error message. Happened at work and I would need
> to get back to the office for a repro).
I presume this wasn't actually talking about File::Copy itself (which is
pure-perl and thus portable) but about some module it loaded (probably
Scalar::Util).
> Is there a version of File::Copy that is agnostic to 32/64bit? Or are
> there other suggestions for how to deal with a mixed 32/64bit
> environment? Using separate environments for 32 and 64 bit machines is
> not an option.
You can't use XS modules across architectures, you need a copy per-arch.
If you'd followed the standard directory structure for your perl
install, you would have something like
/usr/local/lib/perl5/site_perl/5.10.0
PP modules
/usr/local/lib/perl5/site_perl/5.10.0/i386-freebsd
XS modules for 32bit
/usr/local/lib/perl5/site_perl/5.10.0/amd64-freebsd
XS modules for 64bit
(the details will be different for different OSs and processors,
obviously). This will work correctly, in that each perl will look in the
arch-independant and the correct arch-dependant directory only, so will
only see modules for the correct arch. You will need to install
arch-dependant modules twice, but the installed files won't conflict.
For some reason a lot of vendor distributions of perl seem to break
this. The standard build on Win32 also breaks this. In both cases (and,
really, in general) the best solution is to build your own perl
installed in /opt/perl or somewhere, with the correct directory
structure.
Ben
------------------------------
Date: Sat, 22 May 2010 14:43:12 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Debugging question: tracing the origin of an error.
Message-Id: <gk3lc7-a52.ln1@osiris.mauzo.dyndns.org>
Quoth Ted Byers <r.ted.byers@gmail.com>:
> On May 20, 8:27 am, Ben Morrow <b...@morrow.me.uk> wrote:
> > Quoth Ted Byers <r.ted.by...@gmail.com>:
> > > On May 19, 6:54 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > > > Quoth Ted Byers <r.ted.by...@gmail.com>:
> >
> > > > > Trace:
> > > > > k:/Projects/NewRiskModel/Simple.Risk.Model.pl, (eval), k:/Projects/
> > > > > NewRiskModel/Simple.Risk.Model.pl, Win32::TieRegistry::DESTROY, C:/
> > > > > Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> > > > > (eval), C:/Perl/site/lib/Win32/TieRegistry.pm, Line: 1485
> >
> > > > > Can't call method "FETCH" on an undefined value at C:/Perl/site/lib/
> > > > > Win32/TieRegistry.pm line 1485, <DATA> line 335 during global
> > > > > destruction.
> >
> > > > Am I correct that line 1485 of your copy of Win32/TieRegistry.pm is the
> > > > last line here?
> >
> > > > sub DESTROY
> > > > {
> > > > my $self= shift(@_);
> > > > return if tied(%$self);
> > > > my $unload;
> > > > eval { $unload= $self->{UNLOADME}; 1 }
<snip>
> >
> > Can you confirm that the code does in fact get as far as l1485, and
> > doesn't get any further? (Take out the 'confess', and put a 'warn'
> > before 'eval { $unload=...' and another before 'my $debug=...'.)
> >
> > If it does, then the only remaining option is that $self->{UNLOADME}
> > *is* tied, and that the tied object is getting destroyed before its
> > parent. You can confirm this by changing the Devel::Peek::Dump line you
> > added before to
> >
> > Devel::Peek::Dump($self->{UNLOADME});
> >
> > If that output includes the MAGIC line I mentioned above, post it.
>
> Yes, it is confirmed that it gets to line 1485 and no further.
>
> And changing the peek line as suggested produces the following:
>
> SV = PVLV(0x185b6b4) at 0x22245bc
> REFCNT = 1
> FLAGS = (TEMP,GMG,SMG)
> IV = 0
> NV = 0
> PV = 0
> MAGIC = 0x243554c
> MG_VIRTUAL = &PL_vtbl_defelem
> MG_TYPE = PERL_MAGIC_defelem(y)
OK, that's a perfectly ordinary non-existent hash element.
I now have no idea at all what's going on.
> What next?
>
> Would this be an issue with DBI, or the MySQL driver?
It might. At this point the only possibility I can see is some sort of
corruption of perl's stack, which could be caused by any XS module you
are using. If you want to track this down further you will need to start
producing a minimal failing example, which won't be easy if this is some
sort of memory-corrupton bug since they tend to have unpredictable
consequences.
> Is it likely to do any harm? The program runs fine otherwise. I am
> just troubled that this error arises after the code I wrote finishes.
> And seeing the name of the package where the error occurs is
> "TieRegistry", I am concerned this error may introduce, or be a
> consequence of, errors in my registry.
I seriously doubt it has anything to do with your registry. As for
whether it's a problem or not, I really don't know without knowing the
cause. If the program appears to do its job correctly you could decide
to simply ignore it.
Sorry I couldn't be more help.
Ben
------------------------------
Date: Fri, 21 May 2010 14:22:11 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Efficiently searching multiple files
Message-Id: <slrnhvdn0u.28n.tadmc@tadbox.sbcglobal.net>
[ Thank you for not top-posting ]
Jorge <awkster@yahoo.com> wrote:
> On May 20, 6:11Â pm, Tad McClellan <ta...@seesig.invalid> wrote:
>> Jorge <awks...@yahoo.com> wrote:
>> > Yeah Uri and J gave the program a good going-over so I have plenty to
>> > look at there and now I can add your pointers to the list.
>>
>> [ snip TOFU. Please stop doing that! ]
>>
>> TOFU is "Top Over Fullquote Under" also known as "top posting".
>>
>> You were asked nicely (twice!) to stop doing that years ago,
>> yet you continue.
>>
>> I hereby banish you to perpetual invisibility!
>>
>> *plonk*
>>
>> --
>> Tad McClellan
>> email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
>> The above message is a Usenet post.
>> I don't recall having given anyone permission to use it on a Web site.
It is bad manners to quote .sigs too...
You really should learn how to post to Usenet if you plan
to post to Usenet...
http://web.presby.edu/~nnqadmin/nnq/nquote.html
Have you seen the Posting Guidelines that are posted here frequently?
Their purpose is to help avoid this sort of thing...
> Yes I was warned (and IMO not in a nice way)
Here's what I said:
[ snip TOFU. Please stop doing that! ]
[ snip yet more TOFU. Please stop doing that before it is too late! ]
What was not nice about it?
I was trying to save you from getting killfiled.
I failed.
> but it has been 3 years
> since I posted and simply had forgotten about that incident.
Not top-posting is standard netiquette, the incident would never
have happened if you just deigned to post in the accepted manner
from the get-go.
> Sometimes
> sh*t happens.
Sometimes people are banished to eternal invisibility.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Fri, 21 May 2010 12:50:52 -0700 (PDT)
From: Jorge <awkster@yahoo.com>
Subject: Re: Efficiently searching multiple files
Message-Id: <485c6035-4aa1-4bc0-a9f6-1614f0b45a6c@i31g2000vbt.googlegroups.com>
On May 21, 12:22=A0pm, Tad McClellan <ta...@seesig.invalid> wrote:
> [ Thank you for not top-posting ]
>
>
>
>
>
> Jorge <awks...@yahoo.com> wrote:
> > On May 20, 6:11=A0pm, Tad McClellan <ta...@seesig.invalid> wrote:
> >> Jorge <awks...@yahoo.com> wrote:
> >> > Yeah Uri and J gave the program a good going-over so I have plenty t=
o
> >> > look at there and now I can add your pointers to the list.
>
> >> [ snip TOFU. Please stop doing that! ]
>
> >> TOFU is "Top Over Fullquote Under" also known as "top posting".
>
> >> You were asked nicely (twice!) to stop doing that years ago,
> >> yet you continue.
>
> >> I hereby banish you to perpetual invisibility!
>
> >> *plonk*
>
> >> --
> >> Tad McClellan
> >> email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
> >> The above message is a Usenet post.
> >> I don't recall having given anyone permission to use it on a Web site.
>
> It is bad manners to quote .sigs too...
>
> You really should learn how to post to Usenet if you plan
> to post to Usenet...
>
> =A0 =A0http://web.presby.edu/~nnqadmin/nnq/nquote.html
>
> Have you seen the Posting Guidelines that are posted here frequently?
>
> Their purpose is to help avoid this sort of thing...
>
> > Yes I was warned (and IMO not in a nice way)
>
> Here's what I said:
>
> =A0 =A0 [ snip TOFU. Please stop doing that! ]
>
> =A0 =A0 [ snip yet more TOFU. Please stop doing that before it is too lat=
e! ]
>
> What was not nice about it?
>
> I was trying to save you from getting killfiled.
>
> I failed.
>
> > but it has been 3 years
> > since I posted and simply had forgotten about that incident.
>
> Not top-posting is standard netiquette, the incident would never
> have happened if you just deigned to post in the accepted manner
> from the get-go.
>
> > Sometimes
> > sh*t happens.
>
> Sometimes people are banished to eternal invisibility.
>
> --
> Tad McClellan
> email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
> The above message is a Usenet post.
> I don't recall having given anyone permission to use it on a Web site.- H=
ide quoted text -
>
> - Show quoted text -
I'm not so thinned-skinned that I can't take criticism. On the other
hand, the one comment years ago "before it's too late", came across as
a threat and an ambiguous one at that. If it was intended to
communicate the fact that I had violated the TOS (more than once) and
I was in jeopardy of being tombstoned ... then it should have been
worded as such and not left as an open-ended statement that left me
guessing what "or else" means.
Fast forward to today ... I have pled guilty and right here and now,
apologize to the forum for the disruption and promise to not top-post
again. There's not much more I can say or do.
Before banishing me to eternal invisibility, I should at least have
the chance to face the wheel.
------------------------------
Date: Fri, 21 May 2010 14:02:36 -0700
From: sln@netherlands.com
Subject: Re: Efficiently searching multiple files
Message-Id: <65tdv5p76valo0btu8mh27oq9vbnmd2j62@4ax.com>
On Fri, 21 May 2010 12:50:52 -0700 (PDT), Jorge <awkster@yahoo.com> wrote:
>Before banishing me to eternal invisibility, I should at least have
>the chance to face the wheel.
The Pit, The Pendulem
------------------------------
Date: Fri, 21 May 2010 18:38:31 -0500
From: John Bokma <john@castleamber.com>
Subject: Re: Efficiently searching multiple files
Message-Id: <87d3woq0zs.fsf@castleamber.com>
Tad McClellan <tadmc@seesig.invalid> writes:
> Here's what I said:
>
> [ snip TOFU. Please stop doing that! ]
>
> [ snip yet more TOFU. Please stop doing that before it is too late! ]
>
> What was not nice about it?
Maybe you should stop addressing people like they are 3 year old? I've
mentioned this before but you really DO NOT HAVE TO POST.
Ah, well, there was a time I was a bit like you. I have grown up since,
so there is hope.
--
John Bokma j3b
Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
------------------------------
Date: Thu, 20 May 2010 14:42:41 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: getting results of multiple simultaneous system commands
Message-Id: <hrqfc7-9ag.ln1@osiris.mauzo.dyndns.org>
Quoth David Resnick <lndresnick@gmail.com>:
> I need to execute multiple simultaneous system() statements. I
> originally did this using perl threads each invoking a system cmd,
> waiting for them to be joinable, then harvesting the return status
> with join(). The system commands are well behaved in that they will
> finish eventually (have built in time limits). Unfortunately, I
> discovered that the perl I need to use on some of our systems was
> built without threads and replacing it isn't an option.
>
> Is there a nice way to do this AND get the return values of the
> processes launched in single threaded perl? Repeated system("$cmd &")
> would execute all the processes, but I would need some way to get the
> return status. Fork and exec would also work, but same issue. I
> could run a wrapper that calls system and writes the result to a file
> I guess, but that feels clunky. Any suggestions that seem nicer?
Manual fork/exec is going to be easiest, but you need to do things in
the right order. For each process, fork in the parent and then exec in
the child. That way all the external processes are children of your
original process, so you can get all their exit statussesses with a loop
around wait or waitpid. (wait is easier, but only if there aren't going
to ever be any other children.)
Ben
------------------------------
Date: Thu, 20 May 2010 14:39:44 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How to avoid zombies?
Message-Id: <0mqfc7-9ag.ln1@osiris.mauzo.dyndns.org>
Quoth "christoph.rabel@gmail.com" <christoph.rabel@gmail.com>:
> Hi!
> I have inherited a server application which was moved to Linux a
> couple of weeks ago. Now we see a lot of defunct processes in the
> process list.
>
> Essentially we spawn a new thread for each client. communicate "talks"
> a while with it and closes the connection afterwards. As it seems, the
> spawned processes end up as zombies. Can I avoid this behavior easily?
> Or is ignoring it the best approach?
When you say 'thread', do you mean an ithread (created with threads.pm)
or do you mean a Unix process?
> Here is some code to illustrate our approach:
> (I simplified it slightly, removed some error checking)
> while (($paddr = accept(CLIENT, SERVER)) || !$time_to_die) {
> if ($paddr) {
> my ($port, $iaddr) = sockaddr_in($paddr);
> my $name = gethostbyaddr($iaddr, AF_INET);
> my $ip = inet_ntoa($iaddr);
> logMsg(2, $ip . "(" . $name . "):" . $port . "
> connected");
> spawn (sub {
> communicate($ip, $port);
> });
> }
> }
You haven't shown us what 'spawn' does.
If these are true processes, then IIRC on Linux you can avoid zombies
with
$SIG{CHLD} = "IGNORE";
This is not portable to all Unices, however, so if that may matter in
the future write a proper SIGCHLD handler that calls waitpid. See
perlipc for how to do that.
If these are ithreads, then you probably want to ->detach them.
Ben
------------------------------
Date: Sat, 22 May 2010 15:24:14 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Where to get the document for a library function in command line (linux)?
Message-Id: <e16lc7-cg2.ln1@osiris.mauzo.dyndns.org>
Quoth Peng Yu <pengyu.ut@gmail.com>:
> I'm not sure where to get the help page for a perl library function
> (such as getops from Getopt::Std) from linux command line. Maybe this
> is described in man perl. But I may overlook it. Would you please let
> me know how to do it?
>
> P.S. I could use webpage documentation. But I prefer command line
> help.
There isn't any way other than looking all through 'perldoc Getopt::Std'
until you find the right function (or using the search in your pager, of
course). I've often thought it would be good to have something like
'perldoc -f Getopt::Std::getpos', but not enough to make it happen :).
Ben
------------------------------
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 2959
***************************************
