[27444] in Perl-Users-Digest
Perl-Users Digest, Issue: 9077 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 22 18:05:42 2006
Date: Wed, 22 Mar 2006 15:05:07 -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 Wed, 22 Mar 2006 Volume: 10 Number: 9077
Today's topics:
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <emschwar@fc.hp.com>
Re: A Problem With GD <markem@airmail.net>
Re: A Problem With GD <abigail@abigail.nl>
Code review request. <jack@abc.net>
Re: Code review request. <someone@example.com>
Re: Getting a CPAN module to install in the location of <Patrick_member@newsguy.com>
How to run perl cgi under TomCat server? <xxx@nospam.com>
Re: Safe Pipe Open question xhoster@gmail.com
Re: Term::ReadKey not working on one linux box <mm@mohr.de>
Re: unicode conversion <nospam@home.com>
Re: unicode conversion <corff@zedat.fu-berlin.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 22 Mar 2006 11:33:28 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <12232gsgtrhhq7d@corp.supernews.com>
Uri Guttman wrote:
>>>>>>"MM" == Mark Manning <markem@airmail.net> writes:
>
>
> MM> Abigail wrote:
> >> Website? Why would you need the web to read the Perl documentation?
> >> Perl comes with its own documentation.
>
> MM> Ah! Found it! :-) You are absolutely correct. :-)
>
> abigail usually is.
>
> MM> I look on the web because usually the documentation is kept up better
> MM> on-line than what you get with the Perl distribution. Not that the
> MM> documentation is bad that comes with Perl - just that updates are
> MM> usually being done on-line faster. So I look there first.
>
> huh? where did you learn that misinformation? how do you compare the
> online docs to the ones that come with perl and know which is more
> updated? do you check the versions of the docs? do you track changes
> with diff? in fact you should know that the docs that come with EACH
> installation of perl are always the most up to date docs for THAT
> version. the web stuff is put up later and it 100% the same content as
> the docs that install with perl. this is why we always recommend using
> the docs that come with perl, they are correct for that version of perl
> and you always have them. hope this clears things up.
>
> uri
>
Yes, but you are forgetting that people do not update their installation of Perl
every time a single change is made to the documentation. Thus, the ones that
are on-line would (in most cases) be more up-to-date than the ones on your
system. That is just common sense.
------------------------------
Date: 22 Mar 2006 10:40:31 -0700
From: Eric Schwartz <emschwar@fc.hp.com>
Subject: Re: A Problem With GD
Message-Id: <87k6amwf74.fsf@localhost.localdomain>
Mark Manning <markem@airmail.net> writes:
> Yes, but you are forgetting that people do not update their
> installation of Perl every time a single change is made to the
> documentation. Thus, the ones that are on-line would (in most cases)
> be more up-to-date than the ones on your system. That is just common
> sense.
It is also wrong. The documentation is released at the same time new
versions of Perl are released; if you use more recent documentation
than the version of Perl you have, it may well reference syntax,
modules or functions that don't exist in your version, which is not
only frustrating, but wrong. You seem to be confusing "up-to-date"
with "applicable to the version I'm using". That is not sense of any
kind, common or un-. :)
-=Eric
------------------------------
Date: Wed, 22 Mar 2006 12:06:02 -0600
From: Mark Manning <markem@airmail.net>
Subject: Re: A Problem With GD
Message-Id: <12234dv6im96772@corp.supernews.com>
(I know I'm going to hate myself for doing this...)
When the computer world was young we used to have 8bit computers. In order to
have such things as floats, shorts, longs, doubles, and the like, the 8bit
computers had to have software which dealt with the extra bytes. Floats were,
at one point actually made up of two bytes and doubles used four bytes. Things
were defined, as robic0 has said:
char => 1 byte
int => 2 bytes
short => undefined at the time
long => undefined at the time
float => 2 bytes
double => 4 bytes
When 16bit computers came along we then had:
char => 1 byte
int => 2 bytes
short => int
long => 4 bytes (equivalent to a long long today - which is NOT to say 4 bytes =
8 bytes - but which is to say that longs were thought of the same way as long
versus long longs are thought of today)
float => 4 bytes
double => 8 bytes
Long operations were very slow compared to today's computers as was float and
double because they were software based and not hardware based. In all cases,
the larger sizes were based upon char or int.
Then came the floating point math units and then the math co-processors. Once
these came along, the various sizes were fixed (or became constant) and these
definitions haven't changed in quite a while. Thus, as robic0 has been saying:
There are:
char => 8 bytes
Unicode => 2 chars linked together to form one unicode character
int => whatever the word size is of your computer. That being 8, 16,32, 64,
128, etc....
short => 2 chars or 16bits
long => 4 chars or 32bits
float => whatever the word size is of your computer.
double => 2 floats
Once the floating point math units and/or math coprocessors came along, all math
was shoved off to those units. All that is necessary is for the computer to
know where the item is stored and how many bytes to grab and send off to the
math unit. Thus, everything could be reduced to just being chars and it would
all still work. So why there are even two different types is beyond me. My
best guess would be the "If it ain't broke - don't fix it" motto.
(And the bonus question is: why do chars always come back as int? It is only
because that has been the standard way to do it since C was first written.)
And personally, I think they should have used QUAD after LONG instead of LONG
LONG since they were originally going by the DEC words. So it should have been
short, long, quad, octo for the integers. For the real variables I would have
thought that maybe they would have used float (single), double, and triple.
Makes more sense than long long or long double. What are we going to do when we
go to 128 bit computers? Call them long long long and double double or maybe
double long double? Whatever happened to the KISS principle in naming things?
------------------------------
Date: 22 Mar 2006 21:26:18 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: A Problem With GD
Message-Id: <slrne23g7q.bs.abigail@alexandra.abigail.nl>
Mark Manning (markem@airmail.net) wrote on MMMMDLXXXVI September MCMXCIII
in <URL:news:12232gsgtrhhq7d@corp.supernews.com>:
@@
@@
@@ Yes, but you are forgetting that people do not update their installation of
@@ every time a single change is made to the documentation. Thus, the ones tha
@@ are on-line would (in most cases) be more up-to-date than the ones on your
@@ system. That is just common sense.
Ah, you prefer to use documentation of that doesn't match the version
of the product you are using. Very useful. I do that all the time.
I remember the fun we had when the documentation said my TV, which always
showed pictures in B&W, was able to show colour images.
Abigail
--
perl -Mstrict='}); print "Just another Perl Hacker"; ({' -le1
------------------------------
Date: Wed, 22 Mar 2006 21:37:24 GMT
From: Michael Press <jack@abc.net>
Subject: Code review request.
Message-Id: <jack-C65D9A.13372422032006@newsclstr02.news.prodigy.com>
Hello. I am reading in a line of permutation cycles,
preparatory to multiplying them. Want to parse the line
into tokens for linear scanning: permutation elements
and parentheses. Also want to initialize a hash whose
key element pairs are permutation elements. The initial
state of the hash is to be the identity map. I thought
I could make this code more tight or efficient, but
failed; particularly the map <- grep pipe. Will someone
comment on this code? Thanks for listening.
________________CUT_______________
#! /usr/bin/perl -w
sub pm;
while (<DATA>) { pm $_ }
sub pm
{
my $z;
my @line;
my %p;
# Parse the cycles, and initialize the permutation map.
$z = shift (@_);
@line = $z =~ m/(\w+|[()])/g;
%p = map { $_ => $_ } grep { m/\w+/} @line;
printf ("%s\n", join ':', @line), "\n";
while (( $key, $value) = each (%p)) { printf "%7s%7s\n", $key, $value}
}
__END__
(99)(0)(3)(1 4 2 6)(5 10 7)(8 9 )(1 2 4 8 9 3 6 )(5 7)(0 2 )(1 5 99)(3 10)(4 7 8 )(6)(9)
________________CUT________________
--
Michael Press
------------------------------
Date: Wed, 22 Mar 2006 22:05:11 GMT
From: "John W. Krahn" <someone@example.com>
Subject: Re: Code review request.
Message-Id: <rSjUf.238$%H.103@clgrps13>
Michael Press wrote:
> Hello. I am reading in a line of permutation cycles,
> preparatory to multiplying them. Want to parse the line
> into tokens for linear scanning: permutation elements
> and parentheses. Also want to initialize a hash whose
> key element pairs are permutation elements. The initial
> state of the hash is to be the identity map. I thought
> I could make this code more tight or efficient, but
> failed; particularly the map <- grep pipe. Will someone
> comment on this code? Thanks for listening.
>
> ________________CUT_______________
> #! /usr/bin/perl -w
>
> sub pm;
>
> while (<DATA>) { pm $_ }
Put the code inside the while loop instead of calling a subroutine.
> sub pm
> {
> my $z;
> my @line;
> my %p;
Define and declare the variables at the same time.
> # Parse the cycles, and initialize the permutation map.
> $z = shift (@_);
> @line = $z =~ m/(\w+|[()])/g;
You don't need the capturing parentheses in the pattern.
> %p = map { $_ => $_ } grep { m/\w+/} @line;
>
> printf ("%s\n", join ':', @line), "\n";
Use print instead of printf. The ', "\n"' at the end is not doing anything so
why is it there?
> while (( $key, $value) = each (%p)) { printf "%7s%7s\n", $key, $value}
> }
>
> __END__
> (99)(0)(3)(1 4 2 6)(5 10 7)(8 9 )(1 2 4 8 9 3 6 )(5 7)(0 2 )(1 5 99)(3 10)(4 7 8 )(6)(9)
sub pm {
my %p = map { /\w/ ? ( $_ => $_ ) : () } my @line = $_[0] =~ /\w+|[()]/g;
print join( ':', @line ), "\n";
while ( my ( $key, $value ) = each %p ) {
printf "%7s%7s\n", $key, $value;
}
}
John
--
use Perl;
program
fulfillment
------------------------------
Date: 22 Mar 2006 13:16:11 -0800
From: Patrick Flaherty <Patrick_member@newsguy.com>
Subject: Re: Getting a CPAN module to install in the location of my choice.
Message-Id: <dvseqr0mgs@drn.newsguy.com>
In article <dvqphc02c1r@drn.newsguy.com>, Patrick Flaherty says...
>
>
>Been using ActiveState perl for a while. And even VMS perl (the latter has been
>quite handy in handling our legacy system).
>
>With new modules always used PPM. Was aware of CPAN and had looked around
>there. But, in retrospect, I guess ever module I'd actually done a ppm 'search'
>and then 'install' on had been in the ActiveState repository.
>
>Today I find a module on CPAN that I need: MQSeries-1.23. And then I find that
>it's not in PPM!
>
> Duh. Then learn a good bit about repositories in general.
>
> Can't use PPM. Instead use:
>
> 1. perl -MCPAN -e shell then
> 2. cpan> make install H/HB/HBIERSMA/MQSeries-1.23.tar.gz
>
>Didn't build at first - finally realized I needed to have the actual MQSeries
>client from IBM installed. We do own this; found the kit; and installed it.
>
> And then it built with the above cpan command (make install).
>
>Except for one problem. It didn't put the install module into my standard perl
>tree (installation). Which is c:\perl.
>
> Instead it put it under
>
> z:\.cpan\build
>
>Which is where I find myself located when I open a CMD window. Looking among my
>environment vars, I find both HOME and HOMEDRIVE mapped to Z:\ (and maybe
>there's something more mapping to Z: that I've missed [and that the cpan install
>used]).
>
>So how do I repoint the CPAN install to C:\? Which is apparently not my default
>drive, as seen from something.
>
> pat
>
>
nmake install
in
z:\.cpan\Build\MQSeries-1.23
puts it under c:\perl
The fact that the module goes under a 'Build' directory under
.cpan should be a tip-off.
however it goes under C:\Perl\site\lib\MSWin32-x86-multi-thread
where, for some reason, the documentation doesn't seem to integrate.
Nevertheless I can (at a first pass), compile and run:
use MQClient::MQSeries;
$Name = 'NODENAME';
$Hconn = MQCONN($Name,$CompCode,$Reason);
MQDISC($Hconn,$CompCode,$Reason);
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
------------------------------
Date: Wed, 22 Mar 2006 14:13:50 +0000
From: Leo <xxx@nospam.com>
Subject: How to run perl cgi under TomCat server?
Message-Id: <dvs7oo$5heh$1@osf1.gmu.edu>
Dear All,
I have installed TomCat server in my linux computer. I hope to practice
some PERL cgi programming. I searched Google and I cannot find anything
particularly useful. Could anybody give me some information or advice?
Many thanks!
------------------------------
Date: 22 Mar 2006 20:22:12 GMT
From: xhoster@gmail.com
Subject: Re: Safe Pipe Open question
Message-Id: <20060322153005.568$cr@newsreader.com>
Mike Paolucci <paolucci@dunsel.cuug.ab.ca> wrote:
> I'm getting unexplained errors when I read from a log file. I'm using a
> "Safe Pipe Open", and my reference for this is:
>
> http://www.litespeed.net/perldocs/lib/Pod/perlipc.html#Using_open_for_IPC
Your code bears little resemblence to what this reference discusses under
the heading of "Safe Pipe Opens". A key point of "Safe Pipe Open" is that
you bypass the shell by using
open my $fh, "-|" or die;
followed by a safe exec call. You clearly are not doing that.
(I'm not saying you need to be doing that, only that you should know
what it is you are doing, and safe pipe open is not what you are doing.)
> my $fh;
> open( $fh, "grep $ipAddress $logFile | tail 2>&1 |" ) or
> die "Cannot open logfile!!\n";
Your problem may (or may not) be related to the 2>&1.
Why are you doing that?
...
> The code works perfectly and displays no errors.
If it did emit error messages, would you know?
> The probem is that
> when I look in the system error file I see lines and lines of:
What is the system error file? Is that the same thing as perls STDERR?
>
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
> grep: writing output: Broken pipe
>
> Why are these errors there?
grep tried to write to tail, but tail was no longer listening. I've seen
this on some systems (SunOS, for example) when piping into head. It is
obvious why head stops listening early. Why tail would stop listening, I
don't know. I think you have a OS/shell problem, rather than a Perl
problem.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Wed, 22 Mar 2006 23:58:01 +0100
From: Martin Mohr <mm@mohr.de>
Subject: Re: Term::ReadKey not working on one linux box
Message-Id: <dvskif$2u9$00$1@news.t-online.com>
Ilya Zakharevich wrote:
> One possibility: Perl (and TRK) were not compiled on this particular
> machine, but compiled somewhere else. This "somewhere else" package
> is broken (as most out-of-site-compiled pieces of software on Unix
> are).
Term::ReadKey has been compiled on the respective machines. Perl itself
not, but I have never compiled a perl myself. I don't want to sound
ungraceful, but how likely can this be the cause? Do you have an idea
for another test before I try to recompile perl and mess up the rest of
my system?
Thanks,
Martin
------------------------------
Date: Wed, 22 Mar 2006 18:55:46 GMT
From: "Nospam" <nospam@home.com>
Subject: Re: unicode conversion
Message-Id: <S4hUf.15625$814.7049@newsfe5-win.ntli.net>
<corff@zedat.fu-berlin.de> wrote in message
news:489p9eFj1mbiU1@uni-berlin.de...
> Nospam <nospam@home.com> wrote:
> : I am trying to convert some unicode to their equivalent characters,
however
> : it is not printing out the character
>
> : my $w = print
> :
unidecode("\x{25163}\x{34920}\x{36275}\x{29699}\x{20026}\x{33258}\x{30001}")
>
> You don't unidecode here. Simply say chr() instead of \x{} does the trick.
> chr() takes decimal numbers as such, while the \x{} notation insists in
> being fed with hex data.
>
> Your assignments work if you define your strings as:
>
> my $w=chr(25163).chr(34920).......;
>
> print $w will tell you something about wristwatches, soccer and freedom
then.
>
> If you really meant a statement like $w="print chr(65)" to print a letter
"A"
> by saying
>
> $w;
>
> then this doesn't work either; you really wanted to say:
>
> eval $w;
>
This may sound like a silly question, but I am not well versed with e val,
if I was to use the character represented with $w within quotes, would
something like this work:
my $w=chr(25163).chr(34920).......;
eval $w;
print "In chinese $w";
------------------------------
Date: 22 Mar 2006 21:24:58 GMT
From: <corff@zedat.fu-berlin.de>
Subject: Re: unicode conversion
Message-Id: <48dtlaFjr6ksU1@uni-berlin.de>
Nospam <nospam@home.com> wrote:
: This may sound like a silly question, but I am not well versed with e val,
: if I was to use the character represented with $w within quotes, would
: something like this work:
: my $w=chr(25163).chr(34920).......;
: eval $w;
: print "In chinese $w";
No. You'd say
my $w=chr(25163.chr(...)....;
print $w;
# or:
print "Chinese: $w\n";
Using eval is not meaningful here. Look again at the former statement:
You said - my $w="print chr(25163)...". Now, if you print $w, like
print $w;
it will show - what? Right, it will show: "print chr(25163)..." (without
the quotation marks, of course).
That's certainly not what you want; you want the result of that statement,
not the statement itself. Hence you have to _eval_uate the statement,
meaning: treat the contents of this variable not as passive data to be
printed or otherwise manipulated, treat this data as piece of _code_.
The code will be executed if you say:
eval $w;
which would be equivalent to saying
print chr(25163);
The eval operator can be quite useful if you have code which should be
input at runtime; think of your mini shell interpreter realized in Perl,
rather than in bash, e.g.
Oliver.
--
Dr. Oliver Corff e-mail: corff@zedat.fu-berlin.de
------------------------------
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 9077
***************************************
