[12164] in Perl-Users-Digest
Perl-Users Digest, Issue: 5764 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 24 13:47:29 1999
Date: Mon, 24 May 99 10:00:22 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 24 May 1999 Volume: 8 Number: 5764
Today's topics:
Re: A GLOB????? <joaob@despodata.pt>
Re: conditional regexp matching. Please advise. (Ilya Zakharevich)
Re: date conversion and comparison routines (Kai Henningsen)
Re: Does any body have a pointer to CGI SPACE Games? <cassell@mail.cor.epa.gov>
Re: Execute a command from perl... <bakulin@eximb.kiev.ua>
Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Pe (Ilya Zakharevich)
Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Pe <cassell@mail.cor.epa.gov>
Re: Filename Demanger. (Matthew Bafford)
Re: Filename Demanger. <jdporter@min.net>
Re: HELP: can't locate loadable object for module Time: <cassell@mail.cor.epa.gov>
Re: Large flatfile Database (Cameron Laird)
Re: List of files in a directory? (Michel Dalle)
Re: Mac-specific Perl help requested - The Answer (yet <josh@bitwell.net>
Re: NT Peer Web Services <latsharj@my-dejanews.com>
Re: Perl "constructors" <jdporter@min.net>
Re: Perl "constructors" <jdporter@min.net>
Re: Perl "constructors" <jdporter@min.net>
Re: Perl "constructors" <jdporter@min.net>
Re: Perl "constructors" <jdporter@min.net>
Re: Perl "constructors" (Kai Henningsen)
perl and hp 64 bit... mark_f_edwards@my-dejanews.com
Re: Puzzled? Subroutine Problem <jdporter@min.net>
Results not displaying. <jim.ray@west.boeing.com>
Results not Displaying. <jim.ray@west.boeing.com>
s/$TAG/blabla <andre.pletschette@ltam.lu>
Re: s/$TAG/blabla <this.is@not.my.address.ok>
Re: simple question <cassell@mail.cor.epa.gov>
Sprite: Arrays in v3.2. <dd@volnet.freeserve.co.uk>
Re: system info cnsxxx9@my-dejanews.com
the user or 'require' vs. 'use' when using constant mod <jhilgedi@indiana.edu>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 24 May 1999 16:19:43 +0100
From: =?iso-8859-1?Q?Jo=E3o?= Bonina <joaob@despodata.pt>
Subject: Re: A GLOB?????
Message-Id: <37496E0F.4FC83E0C@despodata.pt>
Jonathan Stowe wrote:
>
>
> I assume your problem is with the print() method where you should be
> passing it a reference to a filehandle glob like:
>
> $mail->print(\*STDOUT);
>
Well, the problem wasn't the print() method, it was creating the object
itself with the new() method.
But thanks anyway, I've managed to solve my problem.
------------------------------
Date: 24 May 1999 16:27:10 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: conditional regexp matching. Please advise.
Message-Id: <7ibuku$ng7$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to Ronald J Kimball
<rjk@linguist.dartmouth.edu>],
who wrote in article <1dsa1cj.gnskgl1b1ijxeN@[207.60.170.90]>:
> > and the hope that it can indeed be done using some manipulation of the ?! or
> > ?= operations.
>
> It probably could, but I suspect that the result would be ugly and less
> efficient.
> I believe that some operations just work better when split among several
> regexes.
"Work better"? It is not clear what you mean here. I assume "look
better".
Returning to the case in question, the posted solutions indeed look
better than a possible solution in one REx. But only because of the
anchoring and since the thing could be parsed in one way only.
If backtracking is important to the question at hand, then it is
usually very hard to "split" the problem into parts, and then the
"advanced" RExen like
(0x)?([\da-fA-F]+)(?(1)|h)
help a lot.
Hope this helps,
Ilya
------------------------------
Date: 24 May 1999 14:36:00 +0200
From: kaih=7HUguzFXw-B@khms.westfalen.de (Kai Henningsen)
Subject: Re: date conversion and comparison routines
Message-Id: <7HUguzFXw-B@khms.westfalen.de>
rra@stanford.edu (Russ Allbery) wrote on 23.05.99 in <ylso8n8sx9.fsf@windlord.stanford.edu>:
> Kai Henningsen <kaih=7HQ00Wumw-B@khms.westfalen.de> writes:
> > rra@stanford.edu (Russ Allbery) wrote:
>
> >> I usually use Date::Format to convert them to Unix timestamps and do my
>
> > Don't you mean Date::Parse?
>
> Er. Yes. Thanks.
It's just that I very recently used this in a mail/news gateway :-)
(Unidirectional gateway for a single news/mailreader using non-RFC format,
because the native converter doesn't quite do what I want (doesn't handle
multiparts in any sane way, tends to cut long lines, and so on).
Incidentally, this is making me painfully aware that MIME::Parser is
*SLOW*! Surely parsing a single mail or article should not need something
on the order of a second?!)
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (rra@stanford.edu)
------------------------------
Date: Mon, 24 May 1999 09:58:46 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: Does any body have a pointer to CGI SPACE Games?
Message-Id: <37498546.6C4B0F11@mail.cor.epa.gov>
Venugopal Thammana wrote:
>
> Hi! folks,
>
> I am looking for some nice website where I can find some CGI scripts
> for Games, especially something related to SPACE.
This seems so incredibly not appropriate for this newsgroup.
Even if you're hoping that the games would be in Perl, instead
of C or C++ or Java (that could be a game slow enough for me to
win). But I'll give you some advice anyway. Try:
http://www.cgi-resources.com/
and look through their CGI games.
> Thanks for the help.
> Venu
You're welcome. And in future, please be considerate of
others, and only post appropriate questions in this ng.
Perl programming questions, where you are working on a Perl
program and need some advice. Read through the auto-email
you got form gnat, which explains this and also gives some
excellent advice on programming in Perl.
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Mon, 24 May 1999 19:06:38 +0300
From: "Boris Bakulin" <bakulin@eximb.kiev.ua>
Subject: Re: Execute a command from perl...
Message-Id: <2.07b3.2GVAJ.FC8VF2@eximb.kiev.ua>
In <7i6ojo$qa0$1@news.misnet.net> denny@chuang.com (denny@chuang.com) wrote:
Hi all,
How do I execute a unix command from perl?
Are there any examples to check out?
Thank you!
denny@taching.com.tw
try this:
#!/usr/local/bin/perl -w
use File::Copy;
system ("rm bob");
Bob
------------------------------
Date: 24 May 1999 16:37:55 GMT
From: ilya@math.ohio-state.edu (Ilya Zakharevich)
Subject: Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Perl Y2K compliant?
Message-Id: <7ibv93$ntq$1@mathserv.mps.ohio-state.edu>
[A complimentary Cc of this posting was sent to Michael Stillwell
<mist@yoyo.cc.monash.edu.au>],
who wrote in article <slrn7khblq.353.mist@fangorn.cs.monash.edu.au>:
> On 23 May 1999 19:14:04 GMT, Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
> : On p5p we are trying to design ways to tight the screws of Perl to
> : make it better suitable for these tasks, but this process is in its
> : childhood yet. Basically, now only use strict and -w are your
> : helpers, but this is a very poor help.
>
> [ ... ]
>
> I do not understand any of this at all. Are you saying that
> it is difficult to prove the correctness of Perl
> acripts/programs?
It is not *difficult*, it is impossible. Perl documentation *does not
describe* what Perl operations do. In many cases it at most *hints*
on what one may expect from the operations. (`perldoc -f vec' gives a
worst possible case, but at least at this case somebody did *try* to
document things, it is just that the documenter did not realize that
his prose contains no description of the operation.)
Try to find a definition what $a = $b + $c does. Or what $a = $b | $c
does. In fact the absence of such documenation is quite
understandable: *all* the existing versions of Perl have the result of
$a = $b + $c;
*undefined*! You need one of my latest jumbo patches to make $a
depend on *values* of $b and $c (and, of course, active pragmas) only,
and not on the *history of access* to the values of $b and $c. And my
patch works on 32-bit machines only, 64-bit Perl is another can of
worms.
> Can you give some examples of the things
> that are being fixed? Also, is Perl better or worse than
> other languages? (e.g. C, which you more or less describe as
> "silly"?)
What has localtime() (which I discussed) has to do with C? It is in
C90, but in my ballpark it does not make it into C as a *language*.
But this is of course only a linguistic try of excuse from my side...
C is well defined as a language, Perl is not even close.
Ilya
------------------------------
Date: Mon, 24 May 1999 09:40:20 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: FAQ 4.16: Does Perl have a year 2000 problem? Is Perl Y2K compliant?
Message-Id: <374980F4.2C7F58E7@mail.cor.epa.gov>
Michael Stillwell wrote:
> [Ilya's fine discussion snipped by me]
>
> I do not understand any of this at all. Are you saying that
> it is difficult to prove the correctness of Perl
> acripts/programs? Can you give some examples of the things
> that are being fixed? Also, is Perl better or worse than
> other languages? (e.g. C, which you more or less describe as
> "silly"?)
You can't 'prove' the correctness of any program that really
does anything useful. In any language. And 'correct' programs
still don't always work, since sometimes they have to interact
with broken software.
The issue here is simple: Perl doesn't have a Y2K problem, but
it is almost as east to create one in Perl as it is to do it
in C. Anyone who uses stuff from Matt's Script Archive (to name
one offender who has been named in this ng recently) is at
risk of having a *known* Y2K bug in his/her software. 'Known'
as in having been pointed out in this ng.
Lots of people who can't be bothered to check things in
mmanuals when they get odd results will stumble and fall
over the output of Perl's (local|gm)time functions. We see
them here all the time, asking why they got a result that
has last month's date in it. :-(
Contrary to TomC's position on this, I do not believe that
this is MS-specific. This is part of human psychology.
People who see that '99' for the $year part (and already
have a psychological set on the subject) will blithely
go on about their business, totally unaware that their
implicit assumption is wrong.
In the words of Pete (Richard Holmes) Hawkins Ph.D.,
the world-renowned hydrologist, "Real men don't read manuals."
Choose one:
:-)
:-(
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Mon, 24 May 1999 15:06:59 GMT
From: dragons@dragons.duesouth.net (Matthew Bafford)
Subject: Re: Filename Demanger.
Message-Id: <slrn7kip95.2q4.dragons@dragons.duesouth.net>
[heavy snippage follows]
On Mon, 24 May 1999 01:30:50 -0300, Foozle <pgeorge@ns.sympatico.ca>
held some poor sysadmin at gun point while typing in the following:
: example:
:
: -rw-rw-r-- 1 pgeorge pgeorge 0 May 23 08:04 c:\nsmail\McTasty.jpg
:
: #!/usr/bin/perl
Ack! No '-w' on the end.
#!/usr/bin/perl -w
Although this tells you nothing in this case, it will help you in the
future.
: $d = "";
: $x = "";
Strange variable names.
: $rename = "/bin/mv";
Not necessary.
: while($x = <*>) {
Ok, that works.
: $d = $x;
Again, the variable names can be confusing.
: print "Name before mangling : $d\n";
: $x =~ s/(\\|:|\\\\)/_/g;
Using a substitution where a tr would be better:
$x =~ tr/\\|:/___/;
: print "Name after mangling : $x\n";
: exec ("$rename","$d","$x",@ARGV);
You called exec properly, but there are a few minor details there.
For one, there is no need for the quotes.
exec($rename, $d, $x, @ARGV);
works fine.
Also, why have @ARGV on the end? If someone provides arguments to your
script, this might mess mv up.
Lastly, using the built in rename might be better.
rename($d, $x) or die "Can't rename $d to $x: $!\n";
: }
: c:\nsmail\McTasty.jpg
Since your code is functionally ok, I have a feeling your problem has
more to do with the shell that's used for globbing (<*>).
For example, observe:
bash) echo *
This_File_will.work.jpg c:\nsmail\McTasty.jpg demangle
csh|tcsh) echo *
This_File_will.work.jpg c:
smail\McTasty.jpg demangle
One way to work around this is to use opendir, readdir, and closedir to
read the filenames in yourself.
Also, as a general workaround, this program might help out a lot:
#!/usr/bin/perl -w
# Stolen from Larry Wall
# Modified to take the eval out of the loop.
# Doing so gained an increase in speed.
$op = shift or die "Usage: rename expr [files]\n";
chomp(@ARGV = <STDIN>) unless @ARGV;
eval "sub change_it{ $op } 1";
die "$@\n$op\n" if $@;
for ( @ARGV ) {
$was = $_;
change_it();
rename($was,$_) unless $was eq $_;
}
Which you would call as:
rename 'tr/\\:|/___/' *
(using bash, of course :-)
: Thank You Muchly
HTH,
: -George-
--Matthew
------------------------------
Date: Mon, 24 May 1999 16:24:00 GMT
From: John Porter <jdporter@min.net>
Subject: Re: Filename Demanger.
Message-Id: <7ibuet$68v$1@nnrp1.deja.com>
In article <3748D5FA.140E59E3@ns.sympatico.ca>,
Foozle <pgeorge@ns.sympatico.ca> wrote:
> Im extremely new to Perl no idea wtf im doing particularly just
> needed something that'd demangle queer filenames from newsgroup binary
> posts that are valid to unix
> but are impossible to move over to a samba shared drive (files
> particularly with : and \'s in them)
>...
> #!/usr/bin/perl
> $x = "";
> $d = "";
> $rename = "/bin/mv";
>
> while($x = <*>) {
> $d = $x;
> print "Name before mangling : $d\n";
> $x =~ s/(\\|:|\\\\)/_/g;
> print "Name after mangling : $x\n";
> exec ("$rename","$d","$x",@ARGV);
> }
>...
> For some reason it isnt touching the "c:\nsmail..." filename for
some
> reason
> even though it too contains ': and \' .Can any help me out a little
on
> this one ? If you completely re-write my script can you please put
ample
> inline comments so I know whats going on (more or less).
There are all kinds of ways in which your program could be improved,
but I'd say you've done pretty good for a first attempt.
To address your actual problem: you're calling exec() but you should
be calling system(). See the documentation for these two functions
for all the details (run perldoc); but in a nutshell, exec() doesn't
return to your perl script!
--
John Porter
Put it on a plate, son. You'll enjoy it more.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 09:54:16 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: HELP: can't locate loadable object for module Time::Hires in @INC
Message-Id: <37498438.D8A9FD19@mail.cor.epa.gov>
jbell@263.net wrote:
>
> Hi, all,
>
> When I was trying to use this module, it says:
>
> can't locate loadable object for module Time::Hires in @INC(...)
>
> I checked my code, nothing seems wrong.
> what could be the problem?
Well, maybe you're missing this line at the top of your code:
use diagnostics;
which would have explained in more detail what this means.
Whenever you get an error message you don't understand, you
can go to the perldiag manpage [via man or perldoc, or even
an HTML reader if you've got the HTML version too] and read
what the error message means.
In your case, it means exactly what it says. You tried to
use() or require() Time::Hires somewhere in your program, and
Perl hunted for it to no avail. It couldn't find it
anywhere in @INC. Perhaps you need to tell Perl what the
correct spelling is:
Time::HiRes
and watch those three caps in there. If that doesn't work,
the perldiag page has some helpful suggestions as well.
Just look up your error in there.
> Thanks in advance!
You're welcome.
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---
Deja.com:
Share what you think you know.
Learn what you don't know to be correct.
This should be the motto for the entire Web. :-)
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: 24 May 1999 10:37:18 -0500
From: claird@Starbase.NeoSoft.COM (Cameron Laird)
Subject: Re: Large flatfile Database
Message-Id: <7ibrne$epv$1@Starbase.NeoSoft.COM>
In article <37494d1b@newsread3.dircon.co.uk>,
Jonathan Stowe <gellyfish@gellyfish.com> wrote:
>Danny Verkade <webmaster@mybegin.com> wrote:
>> Hi,
>>
>> Does anyone know a script that can handle a very large flatfile
>> database? (About 100.000 and growing..) I definetelly do not want to use
>> SQL, although this seems much more logical. Hope some one can help me
>> with this
>
>I dont think we can help you much unless you tell us what it is you want
>to do with this database. I mean we've all written programs that deal
>with large textfiles but you can bet your arse that none of them are going
>to do what you want.
>
>In the meantime you might look at the DBD::CSV module from CPAN.
.
.
.
I'll speculate that DBD::CSV indeed does everything Mr. Verkade
requires. I'll further speculate that there SQL implementations
that meet all his requirements, although he doesn't realize it
yet.
For those interested in variations on this topic, we're in
the midst of a series on (roughly) in-memory database managers
<URL:http://www.sunworld.com/swol-05-1999/swol-05-regex.html>.
While Perl hasn't made an explicit appearance lately, all the
stories have Perl connections that I'll happily detail if
there's interest.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
claird@NeoSoft.com +1 281 996 8546 FAX
------------------------------
Date: Mon, 24 May 1999 16:53:41 GMT
From: michel.dalle@usa.net (Michel Dalle)
Subject: Re: List of files in a directory?
Message-Id: <7ic053$afc$1@xenon.inbe.net>
In article <7iboot$ou8$1@cronkite.cc.uga.edu>, Mike Thomas <mthomas@arches.uga.edu> wrote:
>OK, is it me or have I just missed something here. I want to go to a
>directory then read in all the files names there. This will be used in a
>zip command. When I read in the files using glob or <location/*> the first
>file is always left out, code snipette follows;
Well, you probably just missed the PERLFUNC: readdir post from Tom. :-)
So either you wait for another month until it comes around again, or you grab
your local Perl documentation and look up opendir, readdir and closedir...
Michel.
------------------------------
Date: Mon, 24 May 1999 16:55:13 GMT
From: Josh Pointer <josh@bitwell.net>
Subject: Re: Mac-specific Perl help requested - The Answer (yet another followup)
Message-Id: <3749854A.57F6@bitwell.net>
Chris Nandor wrote:
>
> In article <3748E22A.60BF@bitwell.net>, josh@bitwell.net wrote:
>
> # Henry, \n is not an operating system definition; it's a Perl definition.
> # On UNIX, it corresponds to ASCII 10 (\f?). On Mac, ASCII 13 (\r). The
> # mapping of \n is not immutable.
>
> You're wrong. Perl depends on the C compiler's definition of \n, it does
> not supply its own.
The behavior can be controlled and modified.
> # Insulting me serves no useful purpose.
>
> Yet insulting Matthias serves a purpose?
I would appreciate if you would quote the passage from any post I've
made which attacks or insults Matthias. Upon review, I'm confident
you'll find none.
> # Where one finds offense in this, I don't quite know.
>
> It was where you attacked Matthias.
I have not attacked Matthias at any point or time. Again, I would be
interested to know what I've said that you consider to be an attack on
anyone.
>It was also where you asserted that MacPerl does things improperly, which is incorrect.
MacPerl's behavior deviates from Perl's. Period. The method for dealing
with a given text file in a given situation varies. That behavior is not
documented. Explain to me, please, how you conclude that this assertion
is incorrect. If possible, please refer if you must to my original post
for a description of the scenario in which this deviation can be found.
If you'd like help in repeating it, I'd be glad to do what I can.
Upon doing this, please explain to me how you can say this variance
doesn't exist. If you come to agree that the variance does in fact
exist, please explain to me why you and others are so off-put by the
notion that the variance should be documented, and that the
responsibility for primary documentation lies with the developer.
>
> --
> Chris Nandor mailto:pudge@pobox.com http://pudge.net/
> %PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10 1FF77F13 8180B6B6'])
I am becoming genuinely stunned at the reaction to this suggestion.
Josh Pointer
josh@gte.net
------------------------------
Date: Mon, 24 May 1999 14:55:37 GMT
From: Dick Latshaw <latsharj@my-dejanews.com>
Subject: Re: NT Peer Web Services
Message-Id: <7ibp99$29q$1@nnrp1.deja.com>
In article <uosoexXp#GA.56@nih2naac.compuserve.com>,
Steve ATtwell <112366.360@CompuServe.COM> wrote:
> However when I try to invoke a PERL script (example below) via
> browser I always get a 'http/1.0 - 501' error message in my
> browser window. Can anyone help ? Where am I going wrong?
What happens when you run the script from the command line?
What does it say in the server error log?
--
Regards,
Dick
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 15:26:24 GMT
From: John Porter <jdporter@min.net>
Subject: Re: Perl "constructors"
Message-Id: <7ibr2t$3qv$1@nnrp1.deja.com>
In article <7i592o$t2m$1@nnrp1.deja.com>,
armchair@my-dejanews.com wrote:
> In article <7i3s4k$tmj$1@nnrp1.deja.com>,
> John Porter <jdporter@min.net> wrote:
> >...
>
> I guess I missed it. We know that we have a char *. It is not a number
> or string. You raise one highly unlikely scenario that I am very
> surprised Russ Allberry hasn't jumped all over you about - 1.) you say
> that maybe the function is casting a x pointer to a char * before
> returning it and your raise another point that is related to a
> programming error in code - 2. maybe we have a char * that is not
> pointing to a null-terminated character array. This and the
> identical in principal "legal SGML" question has you making a type of
> "argument" that we see regarding legislation to outlaw something such
as
> guns - show an example where the proposed restrictions/changes would
not
> have been sufficient in a case - then try and make the listener take
a
> bogus logical step to - "so restrictions/laws/requirements/changes do
> not help AT ALL".
I appreciate your trying to deal with me on this, but somehow we manage
to continue to talk past each other.
I barely understand what you're saying, above, and I have no idea
whatsoever how it relates to what I said before.
> > Scalar* p = get_next();
> >
> > // Hmm. Maybe p points to a String, maybe to an Integer.
>
> But we know it points. It's not a number or string via built-in types,
> nor does it point to them.
Variables in Perl (scalars, arrays, hashes) are, under the hood,
pointers to data structures; but the language "sugar-coats" the use
of these pointers. So your objection here is null. I was trying to
show how Perl works using C++ syntax. I should perhaps have used
references, rather than pointers, to make my point, since that is
C++'s equivalent sugar-coating.
(Btw, p could indeed point to any type, including built-ins.
Maybe not in an ideal system, but it's still possible, and common.)
> Here's a point you could/may be making: by looking at the code which
> follows the declaration one can usually pick up the type. Such as
>
> my $p = $a->get_next();
> $p++; # clearly number (we hope)
>
> my $p = $a->get_next();
> my $z = $p . ".doc"; # gotta be a string (fingers crossed)
Presumably both ++ and . can be overloaded, so both of those
assumptions are probably premature.
Another thing to remember is that Perl was originally, and is still
primarily, a text processing language. Its support for numeric
computation is not nearly as transparent or as powerful as its
support for string-based operations. Lacking any other info (or
insight), it is best to assume that a scalar contains a string;
because even if it doesn't, it WILL, transparently, if used as a
string. Vice-versa, too, of course.
> my $p = $a->get_next();
> DoSomething($p); # oops can't quite remember what the DoSomething
> # function does or takes - gotta look at it or
> # $a->get_next() to have a clue about $p.
Maybe. But in a well-designed system, you don't need to know the
exact class of p, if it is descended from Object (or whatever), and
DoSomething is defined to take Objects.
Reminds me of the typical event-driven system, where you have e.g.:
e = next_even();
dispatch(e);
At this point in the code, you don't care whether it was a mouse click
event, a keystroke event, a timer event, etc.
So similarly in other systems, you don't care whether the datum is
a number or a string.
> I wasn't suggesting that you need to check the type of $a as in
> " my $a = my_func(); "
> in code. You can assume my_func() is giving you the right thing - just
> suggesting that explicit types makes a program easier to follow.
The philosophy of OO says that types should be abstracted. Different
systems abstract them to different levels, and perhaps the best we
can say is that this is proper. In Perl, it was decided that -- most
of the time -- numbers and strings should be dealt with via a common
abstraction, i.e. a common superclass.
--
John Porter
Put it on a plate, son. You'll enjoy it more.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 15:38:51 GMT
From: John Porter <jdporter@min.net>
Subject: Re: Perl "constructors"
Message-Id: <7ibrqa$4br$1@nnrp1.deja.com>
In article <7i5b2g$u8n$1@nnrp1.deja.com>,
armchair@my-dejanews.com wrote:
> The fact that [the variable] represents temperature should be
> reflected in the variable name, and the ranges/units should be given
> with a comment in Perl or C++. Can't disagree with that at all. But if
> type declaration doesn't tell me everything, does it tell me nothing?
Perhaps the fact that the value is to be used as a number, or was
originally a number, can also simply be reflected in the variable name.
Or perhaps the only thing you need your "type declaration" to tell you
is that the value is scalar in dimension.
> int a = object.GetHooziwhatzit(); // C++
>
> my $a = $object->GetHooziwhatzit(); # Perl
>
> The C++ programmer does not know the range of a Hooziwhatzit, nor the
> real world phenomenem it is representing, unless given comments/good
> variable names, but they do know at declaration how it is represented
> (code reader is not the original programmer).
>
> The Perl programmer (code reader) still wonders - in addition to what
> the C++ programmer ponders above - is a Hooziwhatzit represented by
an
> object, string or number? Maybe it doesn't matter, maybe it probably
> doesn't matter,
Maybe it *shouldn't* matter, and the only reason anyone ever thinks
it "does" matter is because they're used to having to explicitly
write and read such declarations.
What you'll find in Perl is what the rest of us have found: it's one
less thing to have to worry about, one less thing to have to think
about. But as I said before, if you're writing numerical analysis
routines -- FFT, matrix math, etc. -- there are better choices than
Perl.
> ...maybe the Perl programmer always comments and gives good
> variable names that reflect the type, but it certainly doesn't make
the
> code _easier_ to read.
"Ease of reading" is a famous chimera, especially in this newsgroup.
I contend that a sentence with *fewer* semantic tokens is easier to
read, vs. one with more.
The big dog bit me.
vs.
The dog bit me.
Hmm. Which is "easier to read"?
> In Perl I would be tempted to always write
>
> my $a = $object->GetHooziwhatzitNumber(); #or
> my $a = $object->GetHooziwhatzitString(); # or
> my $a = $object->GetHooziwhatzitObject(); # depending on Hooziwhatzit
>...
Tempted, that is, until you learned to actually write Perl in Perl,
rather than writing C++ in Perl.
--
John Porter
Put it on a plate, son. You'll enjoy it more.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 15:47:23 GMT
From: John Porter <jdporter@min.net>
Subject: Re: Perl "constructors"
Message-Id: <7ibsab$4ph$1@nnrp1.deja.com>
In article <7HPvwTKHw-B@khms.westfalen.de>,
kaih=7HPvwTKHw-B@khms.westfalen.de (Kai Henningsen) wrote:
> Perl might be good as a first language. It's certainly good as a
tenth
> language.
>
> But it seems it's terrible as a *second* language.
>
> Then again, that's probably true of any language.
I'm one of the rare Perl advocates who claims that Perl is really
crummy as a first, or even second language.
One should know at least C (or some Algol language), and a shell
language before diving into Perl. But the more the better.
Also, the more languages you know before Perl, the more you
*appreciate* Perl, because it's better than any of them.
--
John Porter
Put it on a plate, son. You'll enjoy it more.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 15:59:09 GMT
From: John Porter <jdporter@min.net>
Subject: Re: Perl "constructors"
Message-Id: <7ibt0c$590$1@nnrp1.deja.com>
In article <xkfzp2ygvug.fsf@valdemar.col.hp.com>,
Eric The Read <emschwar@rmi.net> wrote:
> Perl really only has one type of exception:
> $@. It's not even *possible* for Perl to automatically propogate
> "uninteresting" exceptions, because there's only one kind.
Obviously. If were possible, it we be done (presumably).
> Another
> annoying thing is that a subroutine can raise an exception, and the
> caller is not forced to deal with it. This severely limits the
> usefulness of eval/die as an exception handling mechanism, to my mind.
IMHO, if it *forced* you to do something, *that* would be limiting.
Perl *permits*. It assumes that the programmer knows what she's doing.
The programmer has to be responsible. Perl doesn't believe in
bondage-and-discipline. But if that's what you want -- there's always
Java.
--
John Porter
Put it on a plate, son. You'll enjoy it more.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 16:14:08 GMT
From: John Porter <jdporter@min.net>
Subject: Re: Perl "constructors"
Message-Id: <7ibtsd$5qk$1@nnrp1.deja.com>
In article <7i5e9d$76$1@nnrp1.deja.com>,
armchair@my-dejanews.com wrote:
> In article <7i46he$5cc$1@nnrp1.deja.com>,
> John Porter <jdporter@min.net> wrote:
> > In article <7hu1qs$o54$1@nnrp1.deja.com>,
> > armchair@my-dejanews.com wrote:
> > > > > Or perhaps I have done something that most Perl programmers
> > > > > have not:
> > > > > had to modify other people's code.
> >
> > Perhaps. Or more likely, you need to get out more, and take
> > a look around.
> >
> > Last project I was on, I had to maintain/enhance a 10,000-line
> > system, on which at least five people had worked before me.
> > 100% Perl.
>
> I'm not allowed out.
Then what are doing making any kind of statements about how your
experience compares to anyone else's?
> But since you are, give me the percentage breakdown
> on how Perl is being used (CGI-BIN, database scripts, sysadmin
> functions) and what percentage of their time Perl programmers are
> maintaing the code of others? And what is a typical size for a Perl
> program? How many people are using objects exstensively? inheritance?
Is
> the stuff on CPAN getting good usage at each site?
Sorry, I don't know what the real numbers are.
But I do know that your guess about what "most Perl programmers"
have done was really arrogant.
--
John Porter
Put it on a plate, son. You'll enjoy it more.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: 24 May 1999 14:39:00 +0200
From: kaih=7HUgvFJHw-B@khms.westfalen.de (Kai Henningsen)
Subject: Re: Perl "constructors"
Message-Id: <7HUgvFJHw-B@khms.westfalen.de>
rra@stanford.edu (Russ Allbery) wrote on 23.05.99 in <yl1zg859tq.fsf@windlord.stanford.edu>:
> Kai Henningsen <kaih=7HPvvm5mw-B@khms.westfalen.de> writes:
>
> > Every language has some things it's not suitable for. What I'm saying
> > here is that few people would care if, for Perl, that included
> > "long-running demons that MUST NOT, ever, die".
>
> Given that Perl currently can't handle signals properly, Perl *already*
> isn't a very good language for writing such things in.
<shrug> Perl's signal handling has so far been good enough for the stuff
I've been using it for (which wasn't much, granted).
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (rra@stanford.edu)
------------------------------
Date: Mon, 24 May 1999 16:36:38 GMT
From: mark_f_edwards@my-dejanews.com
Subject: perl and hp 64 bit...
Message-Id: <7ibv6m$6qq$1@nnrp1.deja.com>
if anyone has any experience getting perl to COMPILE in
64 bit, please let me know...
i have tried:
export CCOPTS="+DA2.0W" ,
but some of the 64 bit libraries are not there.... i will keep trying!
mark.edwards@sunh.com
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 16:40:53 GMT
From: John Porter <jdporter@min.net>
Subject: Re: Puzzled? Subroutine Problem
Message-Id: <7ibvek$755$1@nnrp1.deja.com>
In article <19990523114312.23703.00004008@ng-ci1.aol.com>,
bkrapf9811@aol.com (BKrapf9811) wrote:
> For some reason (I hope someone can tell me why), I get an error when
ever I
> try to execute the following script.
>
> ====== Here's the Script ========
> #!/usr/bin/perl
>
> require("cgi-lib.pl");
>
> &ReadParse(*input);
>
> $first=$input{'first'};
> $last=$input{'last'};
> $status=$input{'status'};
>
> print "Content-type: text/html\n\n";
> print"<HTML><HEAD><TITLE>test page</TITLE></HEAD>\n";
> print"<BODY><P><B>ASCE Reserver02</B>";
> print"<P>Your entered the following values:";
> print"<P>$first<BR>$last<BR>$status";
> print"</BODY></HTML>\n";
> ======== End Script =============
>
> ===== Here's the error ========
> Internal Server Error
>
> The server encountered an internal error or misconfiguration and was
unable to
> complete your request.
>
> Please contact the server administrator, root@localhost and inform
them of the
> time the error occurred, and anything you might have done that may
have caused
> the error.
> ===== End Error ===========
There's a couple of issues here, the most important of which is that
you learn to debug your perl programs. The first thing to do is to
let perl help you find the errors. Step 1: add -w to the #! line,
like so:
#!/usr/bin/perl -w
This catches more problems and gives better messages.
Have you run the script at the command prompt? The error message
you get in your browser is not nearly as informative as what you'll
get by running the script from the prompt. Also, if the script runs
fine at the prompt but erroneously over the web, that indicates a
certain class of errors; this is helpful to know.
Whenever you post to the newsgroup asking for help debugging something,
you should include the output of running perl with the -V option:
perl -V
This will tell us what version of perl you have, and other helpful info.
The other thing I would suggest to you is to use the CGI.pm module,
rather than cgi-lib.pl. It's much better written, more powerful,
more flexible, and is found in just about every recent installation
of Perl. Your script above could be rewritten using CGI like so:
#!/usr/bin/perl -w
use CGI;
use CGI::Carp qw(fatalsToBrowser); # better diagnostics in the browser
my $q = new CGI;
my $first = $q->param('first');
my $last = $q->param('last');
my $status = $q->param('status');
print(
$q->header,
$q->start_html( -title => 'test page' ), $q->p,
$q->b( 'ASCE Reserver02' ), $q->p,
'Your entered the following values:', $q->p,
$first, $q->br,
$last, $q->br,
$status,
);
When you run this script from the command prompt, it will let
you enter cgi parameters, so you can test the functionality fully
without having to go through the browser. Then, when you test in
the browser, it will catch any (well, most) errors and display them
in the browser, rather than simply telling you, "Server error" or
whatever.
--
John Porter
Put it on a plate, son. You'll enjoy it more.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 14:30:06 GMT
From: "news.boeing.com" <jim.ray@west.boeing.com>
Subject: Results not displaying.
Message-Id: <FC8qxz.F9L@news.boeing.com>
I am running NT 4.0, IIS4 and Perl 5x. I have a Perl script that runs fine
in PerlBuilder. When I run the script on the Web, nothing gets displayed.
Here is what I do. I have a directory of some files, run a script that will
build a table of the results. This has worked in the past, but once I
loaded IIS 4, things do not work like they use to.
Thank you for your help.
--
Jim Ray
Delta Program NT Administrator
The Boeing Company
714-896-2038
jim.ray@west.boeing.com
------------------------------
Date: Mon, 24 May 1999 15:03:08 GMT
From: "news.boeing.com" <jim.ray@west.boeing.com>
Subject: Results not Displaying.
Message-Id: <FC8sH1.2Jv@news.boeing.com>
I found out that, regular statments like.
print "This is a test\n"; prints ok.
print "<b>This is a test <b>\n"; does not.
I looks like all HTML lines are being ignored and I have no clue why.
Thanks for the help.
--
Jim Ray
Delta Program NT Administrator
The Boeing Company
714-896-2038
jim.ray@west.boeing.com
------------------------------
Date: Tue, 25 May 1999 16:33:17 +0200
From: "Pletschette Andri" <andre.pletschette@ltam.lu>
Subject: s/$TAG/blabla
Message-Id: <7ibo0k$d8i$1@calais.pt.lu>
How can I write: s/$TAG/blabla ?
I think the problem is that Perl is looking for the text $TAG, not for the
value of the $TAG-Variable, does nobody have a solution for this problem?
___________________________________ ____
Pletschette Andri andre.pletschette@ltam.lu
www.grosbous.lu
------------------------------
Date: Mon, 24 May 1999 16:33:26 +0100
From: Bob MacCallum <this.is@not.my.address.ok>
Subject: Re: s/$TAG/blabla
Message-Id: <37497146.3D270BF7@not.my.address.ok>
Pletschette Andri wrote:
>
> How can I write: s/$TAG/blabla ?
>
> I think the problem is that Perl is looking for the text $TAG, not for the
> value of the $TAG-Variable
not at all, your $TAG variable (and you should use lower
case for variable names if you don't want to get flamed here)
might contain characters which mean something to the
regular expression machinery
# for example
$regexp = 'boys+girls';
# will not match
$text = 'the boys+girls love it';
print "yes\n" if ($text =~ /$regexp/);
# try the equivalent of
$regexp = quotemeta 'boys+girls';
--
from bob maccallum - email me at
initial.surname@icrf.icnet.uk
------------------------------
Date: Mon, 24 May 1999 09:23:00 -0700
From: David Cassell <cassell@mail.cor.epa.gov>
Subject: Re: simple question
Message-Id: <37497CE4.C9BB492D@mail.cor.epa.gov>
John Callender wrote:
>
> Ronald J Kimball <rjk@linguist.dartmouth.edu> wrote:
> > Howie <noone@home.com> wrote:
>
> >> noone@home.com (Howie) wrote:
> >> >simple question, but I can't seem to find a reference to it. How do I convert
> >> >a string to lowercase?
>
> > $email = lc($email);
>
> Warning: I am aware that the following question has nothing to do with
> Perl. I am also aware that there are users of this group who find such
> non-Perl questions objectionable. Such users are free, of course, to
> take any action they deem appropriate in response to my callous
> disregard for their sensibilities, but I didn't want them to be
> confused about whether or not *I* am confused about the first two
> points I've stipulated above.
Hey, it's not nice to make me laugh with a mouth full of beverage!
Getting V-8 juice off this keyboard is a pain...
> Whew.
I think you may be overly concerned about this issue. I don't
worry about it nearly as much as you do [apparently], and
the ng gurus only bite my head off once a quarter or so. :-)
> Anyway, I'm curious about something: It looks to me like this person is
> thinking of downcasing a bunch of email addresses. My understanding of
> email addressing conventions is that while it is safe to treat the
> hostname part of an email address as case-insensitive, to do so with
> the username part (the part to the left of the @, I mean) runs the risk
> of rendering a case-sensitive address nondeliverable. I'm curious to
> know if this bit of folklore I picked up somewhere is actually true,
> and if so, what sorts of systems might display this sort of behavior,
> and what people think a reasonable guess would be as to how widespread
> such behavior is in the general population of email addresses.
>
> So, is there anyone out there who:
>
> 1) knows, or at least has an informed opinion on, the answer, and
> 2) is actually following this thread, and
> 3) is willing to violate the subject-matter norms by following up, and
> 4) hasn't already killfiled me for my off-topic blather?
I would categorize myself as fulfilling points 2,3, and 4.
I too have been 'told' that some addresses are case-sensitive.
But, even with X400 addresses, I have not seen one actually
fail due to an upper-case/lower-case translation. Still, that
could have been due to the gateway/OS at the other end, instead
of a true X400 resolution. Nor have I seen a difference when
sending e-mail to people using particularly-reviled win32-based
mail systems whose names will be avoided to spare more flamewars
here.
I'm sure someone will direct us to the proper RFC, though.
At least you don't have to worry about this with addresses
like *@qz.to . :-)
David
--
David Cassell, OAO cassell@mail.cor.epa.gov
Senior computing specialist
mathematical statistician
------------------------------
Date: Mon, 24 May 1999 15:34:22 +0100
From: Daniel Dammann <dd@volnet.freeserve.co.uk>
Subject: Sprite: Arrays in v3.2.
Message-Id: <3749636D.E2AC6473@volnet.freeserve.co.uk>
Dear Group,
Using the module sprite.pm version 3.1. I have once created an
online database, which I now have to adopt to the new release
version sprite 3.2. The problem is: Wherever I expect to get a
record from the database file back, the only element which really comes
back always looks as strange as ARRAY(0x14013dfb8).
Looking for online reference, I came across the revision notes
of the new sprite version (but no documentation which could help
me with this problem).
> Columns are no longer returned as a null-delimited string,
> but as an array reference. However, you have the option of
> asking Sprite to return the _records_ either as an array or
> a reference.
Is there anybody out there who could give me advice about how
to vary the sprite SQL request
@data = $rdb->sql ("select * from $datafile where $query");
to make use of the option mentioned above (null-delimited string
instead of array reference)!? I would be very grateful.
Best regards,
Daniel.
------------------------------
Date: Mon, 24 May 1999 15:35:27 GMT
From: cnsxxx9@my-dejanews.com
Subject: Re: system info
Message-Id: <7ibrjv$43c$1@nnrp1.deja.com>
pity I don't have ftp acces...firewall and all that
:-(
> Not exactly, but do research this at reference.perl.com,
> via DejaNews, and get the OverCR script 9writtin in perl)
> at
>
> ftp://jaxlug.jaxcan.org/pub/overcr/overcr-1.49.02.tar.gz
>
> HTH,
> -Sneex- :]
>
> > is there a module to get system info?
> >
> > e.g. free hard disk space, total memory, current shell,
> > and also current running processes?
> >
> > TIA
> >
> > C.
> > --
> >
> > Christopher.Shaw (AT) PanCredit.com (wk)
> > chris (AT) mdrive.freeserve.co.uk (home)
> >
> >
> > --== Sent via Deja.com http://www.deja.com/ ==--
> > ---Share what you know. Learn what you don't.---
>
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
------------------------------
Date: Mon, 24 May 1999 10:54:27 -0500
From: "John Hilgedick" <jhilgedi@indiana.edu>
Subject: the user or 'require' vs. 'use' when using constant module
Message-Id: <7ibs8h$qb4$1@jetsam.uits.indiana.edu>
I ran into some odd behavior today and wanted to bounce it off the group. I
have a module I created in which I declare several constants. I want to use
those constants in a number of other cgi scripts. If I "include" the module
in the cgi script with 'require', the constants don't seem to be defined (I
just get "0";s) but if I change 'require' to 'use', I get the proper values.
After reading up more on the differences between 'use' and 'require', it
looks like 'require' doesn't "compile" your module until you actually
'reference a symbol in it'. Now... since the constant module is really just
a pragma that directs that constant declarations should be 'converted' into
subroutines, perhaps these guys DON'T EXIST if you just refer to a constant
in the module BEFORE you invoke any subroutines in that module.
Any thoughts?
-john
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 5764
**************************************
