[26413] in Perl-Users-Digest
Perl-Users Digest, Issue: 8584 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Oct 28 18:05:34 2005
Date: Fri, 28 Oct 2005 15:05:05 -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 Fri, 28 Oct 2005 Volume: 10 Number: 8584
Today's topics:
FAQ 2.18 What is perl.com? Perl Mongers? pm.org? perl.o <comdog@pair.com>
FAQ 4.10 Why aren't my random numbers random? <comdog@pair.com>
Re: Moving data structure around better than globals? <xx087@freenet.carleton.ca>
Re: Moving data structure around better than globals? (Anno Siegel)
Re: Unintuitive expression evaluation <rvtol+news@isolution.nl>
Re: Unintuitive expression evaluation <tassilo.von.parseval@rwth-aachen.de>
Re: Unintuitive expression evaluation <davidsen@deathstar.prodigy.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 28 Oct 2005 22:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@pair.com>
Subject: FAQ 2.18 What is perl.com? Perl Mongers? pm.org? perl.org? cpan.org?
Message-Id: <dju76k$oa8$1@reader2.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
2.18: What is perl.com? Perl Mongers? pm.org? perl.org? cpan.org?
Perl.com at http://www.perl.com/ is part of the O'Reilly Network, a
subsidiary of O'Reilly Media.
The Perl Foundation is an advocacy organization for the Perl language
which maintains the web site http://www.perl.org/ as a general advocacy
site for the Perl language. It uses the domain to provide general
support services to the Perl community, including the hosting of mailing
lists, web sites, and other services. The web site http://www.perl.org/
is a general advocacy site for the Perl language, and there are many
other sub-domains for special topics, such as
http://learn.perl.org/
http://use.perl.org/
http://jobs.perl.org/
http://lists.perl.org/
Perl Mongers uses the pm.org domain for services related to Perl user
groups, including the hosting of mailing lists and web sites. See the
Perl user group web site at http://www.pm.org/ for more information
about joining, starting, or requesting services for a Perl user group.
http://www.cpan.org/ is the Comprehensive Perl Archive Network, a
replicated worldwide repository of Perl software, see the *What is
CPAN?* question earlier in this document.
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: Fri, 28 Oct 2005 16:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@pair.com>
Subject: FAQ 4.10 Why aren't my random numbers random?
Message-Id: <djti3l$d9l$1@reader2.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
4.10: Why aren't my random numbers random?
If you're using a version of Perl before 5.004, you must call "srand"
once at the start of your program to seed the random number generator.
BEGIN { srand() if $] < 5.004 }
5.004 and later automatically call "srand" at the beginning. Don't call
"srand" more than once---you make your numbers less random, rather than
more.
Computers are good at being predictable and bad at being random (despite
appearances caused by bugs in your programs :-). see the random article
in the "Far More Than You Ever Wanted To Know" collection in
http://www.cpan.org/misc/olddoc/FMTEYEWTK.tgz , courtesy of Tom Phoenix,
talks more about this. John von Neumann said, "Anyone who attempts to
generate random numbers by deterministic means is, of course, living in
a state of sin."
If you want numbers that are more random than "rand" with "srand"
provides, you should also check out the Math::TrulyRandom module from
CPAN. It uses the imperfections in your system's timer to generate
random numbers, but this takes quite a while. If you want a better
pseudorandom generator than comes with your operating system, look at
"Numerical Recipes in C" at http://www.nr.com/ .
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: 28 Oct 2005 15:31:55 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: Moving data structure around better than globals?
Message-Id: <slrndm4h3c.82e.xx087@smeagol.ncf.ca>
At 2005-10-28 09:35AM, Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> When I get worried about globals, I put them into one or (usually) more
> bare blocks and add the necessary accessor routines. Other code must
> go through those. That way I get real access restriction and can also
> compartmentalize (is that really a word?) the mess of globals. The
> bare blocks form lexical islands that can be designed like objects,
> since they combine a set of data with a set of routines to manipulate
> them.
Would you mind posting a short example?
--
Glenn Jackman
NCF Sysadmin
glennj@ncf.ca
------------------------------
Date: 28 Oct 2005 17:44:25 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Moving data structure around better than globals?
Message-Id: <djto1p$3da$1@mamenchi.zrz.TU-Berlin.DE>
Glenn Jackman <xx087@freenet.carleton.ca> wrote in comp.lang.perl.misc:
> At 2005-10-28 09:35AM, Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> > When I get worried about globals, I put them into one or (usually) more
> > bare blocks and add the necessary accessor routines. Other code must
> > go through those. That way I get real access restriction and can also
> > compartmentalize (is that really a word?) the mess of globals. The
> > bare blocks form lexical islands that can be designed like objects,
> > since they combine a set of data with a set of routines to manipulate
> > them.
>
> Would you mind posting a short example?
Wanting to be somewhat realistic, and also to show a few variations of
the basic theme, the example I came up with isn't exactly short.
Suppose you are writing a program that takes user input (which may
come from a batch file) and produces graphics in response to commands --
something like interactive turtle graphics for instance. At some point,
a roundup of your global variables may yield this:
my $x_pos; # graphics cursor x
my $y_pos; # graphics cursor y
my $fg_color # foreground color for graphics
my $bg_color # background color for graphics
my %color_table # map color names to rgb colors
my $use_interactive; # is input from a terminal?
my $last_command; # last input line from user
my $last_reply; # last output to user
I have already sorted them in two blocks, one graphics-related and one
related to the interactive ("shell"-) functions. In a sufficiently
chaotic source they would come up in random order.
Looking over the graphics-related variables, you may decide that the
position variables are always used together, so you'll write combined
get- and set- accessors for x and y. Similarly, when a drawing
routine needs one of the foreground/background colors, it wants the other
too, so these get a combined get-accessor. The user wants to set the
colors independently, so they get individual set-accessors. That suggests
a design for the graphic status like this (untested code):
{ # graphics status
my ( $x_pos, $y_pos); # cursor
sub get_pos { return ( $x_pos, $y_pos) }
sub set_pos {
my ( $x, $y) = @_;
# check validity
( $x_pos, $y_pos) = ( $x, $y);
}
my ( $fg_color, $bg_color) # default foreground/background colors
sub set_fg_color { $fg_color = _encode_color( shift || 'black') }
sub set_bg_color { $bg_color = _encode_color( shift || 'white') }
sub get_colors { return ( $fg_color, $bg_color) }
my %color_table = (
white => 0xFF_FF_FF,
black => 0x00_00_00,
# etc
);
sub _encode_color {
my $name = shift;
return $color_table{ $name} if exists $color_table{ $name};
Carp::croak( "Invalid color name: '$name'");
}
}
That wraps a nice chunk of functionality into an identifiable package (umm,
lexical scope). Code that doesn't need to access the variables directly
goes outside:
sub shove_pos { # move position relative to current
my ( $dx, $dy) = @_;
my ( $x, $y) = get_pos();
set_pos( $x + $dx, $y + $dy);
}
Use similar considerations to corral the shell-related variables into
their lexical scope:
{ # shell status
my $use_interactive = -t STDIN; # no set-accessor, just initialize
sub is_interactive { return $use_interactive }
# more code for $last_command and $last reply
}
What I haven't shown are the necessary changes to the rest of the code
so that it goes through the accessors. The design of the accessor routines
should consider this step and make it easy, it is usually the hardest part.
In any case, the Perl compiler (under strict) will tell you if anything
anywhere still tries to access an ex-global. It's not a matter of test
coverage, you'll know when you're done.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Fri, 28 Oct 2005 17:06:36 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Unintuitive expression evaluation
Message-Id: <djtlv7.14o.1@news.isolution.nl>
Bill Davidsen schreef:
> (1 << 32)
That is a 33-bit value.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Fri, 28 Oct 2005 19:10:07 +0200
From: "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de>
Subject: Re: Unintuitive expression evaluation
Message-Id: <3setakFo4mghU1@news.dfncis.de>
Also sprach Anno Siegel:
> Tassilo v. Parseval <tassilo.von.parseval@rwth-aachen.de> wrote in comp.lang.perl.misc:
>> Also sprach A. Sinan Unur:
>> > Bill Davidsen <davidsen@deathstar.prodigy.com> wrote in
>> > news:mNa8f.3023$Y61.1523@newssvr33.news.prodigy.com:
>
>> I think the left-shift operator could be made smarter so that it always
>> works up to 2**64 - 1, even on 32bit machines.
>
> ...but only if the bit pattern can be preserved. It wouldn't do to return
> the numeric equivalent as a float. So there must be support for 64 bit
> integers, either in hardware or in software. I don't think Perl supplies
> that if the native C doesn't.
Yes, the assumption was that some sort of 64bit integer exists. If it
doesn't, left-shift will remain as it is now. The patch that should do
that is:
--- perl-p-5.8.0@25859~/pp.c 2005-10-27 08:58:48.000000000 +0200
+++ perl-p-5.8.0@25859/pp.c 2005-10-28 08:42:45.000000000 +0200
@@ -1627,12 +1627,32 @@ PP(pp_left_shift)
{
const IV shift = POPi;
if (PL_op->op_private & HINT_INTEGER) {
+#if !defined(USE_64_BIT_INT) && defined(I64TYPE)
+ I64TYPE i = TOPi;
+ i <<= shift;
+ if (i > I32_MAX) {
+ SETn((NV)i);
+ SvNOK_only(TARG);
+ } else
+ SETi(i);
+#else
IV i = TOPi;
SETi(i << shift);
+#endif
}
else {
+#if !defined(USE_64_BIT_INT) && defined(U64TYPE)
+ U64TYPE u = TOPu;
+ u <<= shift;
+ if (u > U32_MAX) {
+ SETn((NV)u);
+ SvNOK_only(TARG);
+ } else
+ SETu(u);
+#else
UV u = TOPu;
SETu(u << shift);
+#endif
}
RETURN;
}
That fails two core-tests, though, and I suspect it's even
backwards-incompatible because there were oudoubtedtly blockheads out
there that assumed some sort of defined behaviour from overflowing
left-shifts in their scripts.
Nonetheless I passed that draft to the porters to see what they think
about it.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
------------------------------
Date: Fri, 28 Oct 2005 19:42:40 GMT
From: Bill Davidsen <davidsen@deathstar.prodigy.com>
Subject: Re: Unintuitive expression evaluation
Message-Id: <Qav8f.3407$Y61.1710@newssvr33.news.prodigy.com>
A. Sinan Unur wrote:
> Bill Davidsen <davidsen@deathstar.prodigy.com> wrote in
> news:mNa8f.3023$Y61.1523@newssvr33.news.prodigy.com:
>
>
>>I am reading a log file which has 32 bit unsigned values, and need to
>>take the difference between them. If the difference is negative I
>>assume that the data counter has rolled over, and I want to add 231 to
>>get the correct value. For readability I wanted to put the value in a
>>variable so it would be obvious what was happening.
>>
>>So I wrote:
>> $Roll32 = (1 << 32); # the way I would for a C macro
>>but the value was (after I did some looking) one! Then I wrote:
>> $Roll32 = 1 << 32; # in case the parens were a issue
>>bit it was still one, so I wrote:
>> $Roll32 = ( 4 * (1 << 30) ); # which works (4G)
>>
>>This is the first time perl has failed to do int=>double conversion
>>when expected (by me).
>
>
> The only thing that failed in this case is you.
Sorry, I didn't realize the word "unintuitive" would not be understood
by some people.
This works on 64 bit machines. This works on 32 bit machines if you
compile for 64 bit integers. This doesn't work on 32 bit machines
without 64 bit integers. However, it does work if you do it at runtime
instead of compile time:
oddball:davidsen> perl -e '
@x=(4,1);
for $a (@x) {
$b=$a<<29;
$c=$a<<30;
print "$a $b $c\n"
}'
4 2147483648 0
1 536870912 1073741824
A feature which works in some places and not in others, and which
doesn't generate compiler warnings in cases where it clearly isn't going
to work certainly qualifies as "unintuitive" for me.
--
bill davidsen
SBC/Prodigy Yorktown Heights NY data center
http://newsgroups.news.prodigy.com
------------------------------
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 8584
***************************************
