[17048] in Perl-Users-Digest
Perl-Users Digest, Issue: 4460 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Sep 28 14:10:30 2000
Date: Thu, 28 Sep 2000 11:10:15 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <970164615-v9-i4460@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Thu, 28 Sep 2000 Volume: 9 Number: 4460
Today's topics:
Re: newbie question (Jon S.)
Re: newbie question <sariq@texas.net>
Re: newbie question nobull@mail.com
Re: newbie question (Craig Berry)
Re: Perl Programmer needed for a quick gig <jeff@vpservices.com>
Re: Perl Programmer needed for a quick gig <gstaylor@netscape.net>
Re: Perl Programmer needed for a quick gig (Phillip Smith)
Re: Perl Programmer needed for a quick gig (Phillip Smith)
Perl trouble i0519@my-deja.com
Re: Perl trouble <godzilla@stomp.stomp.tokyo>
Re: Perl trouble <yanick@babyl.sympatico.ca>
Re: Perl vs. PHP/Java <fs.mail@wanadoo.be>
Re: Problem w/ associative arrays (Anno Siegel)
Re: Problem w/ associative arrays (Abigail)
Re: Programming the Perl DBI (Jon S.)
Re: Questions about space-saving techniques (James Weisberg)
Re: Questions about space-saving techniques <tim@ipac.caltech.edu>
Re: Questions about space-saving techniques <lr@hpl.hp.com>
Re: retrieve the date and size of a file running (Arthur Darren Dunham)
Rounding Numbers... <lmoran@wtsg.com>
Re: Rounding Numbers... <yanick@babyl.sympatico.ca>
Re: Send HTMLmail via Perl Script joshfeingold@my-deja.com
Re: Sorry - TOTAL newbie <anmcguire@ce.mediaone.net>
Re: Sorry - TOTAL newbie <paulmaguire@ntlworld.com>
splitting lines with a regex <news@#nospam#althepal.com>
Re: splitting lines with a regex <jeff@vpservices.com>
Re: What does this do?! <tim@ipac.caltech.edu>
Re: Where is NDBM_File.pm? <philipg@atl.mediaone.net>
Re: Where is NDBM_File.pm? <OfficerS@aries.tucson.saic.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 28 Sep 2000 16:11:36 GMT
From: jonceramic@nospammiesno.earthlink.net (Jon S.)
Subject: Re: newbie question
Message-Id: <39d36ce1.10106853@news.earthlink.net>
On Thu, 21 Sep 2000 23:59:35 -0000, cberry@cinenet.net (Craig Berry)
wrote:
>Marvinas (Marvinas@Takas.lt) wrote:
>: Is there a function in Perl for translation from string to integer and
>: otherwise? I have $int="23" and I want $int=23.
>
>Perl scalars automagically behave as strings where a string is expected,
>and as numbers where a number is expected. There's no need to do an
>explicit conversion.
Is there an easy way to check if a scalar is a number?
When I came across this, I couldn't figure out a regexp that would
work, but I was using Perl DBI/DBD, so I used the "lookslikenumber"
function. (I forget the exact name now.)
But, how would I check if I wasn't using that module? I couldn't find
it in any of the FAQ's or my books... just lots of references to the
fact that Perl doesn't care if it's a number or a string.
Jon
------------------------------
Date: Thu, 28 Sep 2000 11:39:41 -0500
From: Tom Briles <sariq@texas.net>
Subject: Re: newbie question
Message-Id: <39D3744D.18AA5E87@texas.net>
"Jon S." wrote:
>
> On Thu, 21 Sep 2000 23:59:35 -0000, cberry@cinenet.net (Craig Berry)
> wrote:
>
> >Marvinas (Marvinas@Takas.lt) wrote:
> >: Is there a function in Perl for translation from string to integer and
> >: otherwise? I have $int="23" and I want $int=23.
> >
> >Perl scalars automagically behave as strings where a string is expected,
> >and as numbers where a number is expected. There's no need to do an
> >explicit conversion.
>
> Is there an easy way to check if a scalar is a number?
Yes. It's a FAQ.
> When I came across this, I couldn't figure out a regexp that would
> work, but I was using Perl DBI/DBD, so I used the "lookslikenumber"
> function. (I forget the exact name now.)
looks_like_number()
perldoc DBI
> But, how would I check if I wasn't using that module? I couldn't find
> it in any of the FAQ's or my books... just lots of references to the
> fact that Perl doesn't care if it's a number or a string.
You must not have looked very hard.
Just:
perldoc -q number
would have found the answer.
perldoc -q 'number/whole'
will find it a bit more quickly.
- Tom
------------------------------
Date: 28 Sep 2000 17:52:59 +0100
From: nobull@mail.com
Subject: Re: newbie question
Message-Id: <u94s308nmc.fsf@wcl-l.bham.ac.uk>
jonceramic@nospammiesno.earthlink.net (Jon S.) writes:
> On Thu, 21 Sep 2000 23:59:35 -0000, cberry@cinenet.net (Craig Berry)
> wrote:
>
> >Marvinas (Marvinas@Takas.lt) wrote:
> >: Is there a function in Perl for translation from string to integer and
> >: otherwise? I have $int="23" and I want $int=23.
> >
> >Perl scalars automagically behave as strings where a string is expected,
> >and as numbers where a number is expected. There's no need to do an
> >explicit conversion.
>
> Is there an easy way to check if a scalar is a number?
>
> When I came across this, I couldn't figure out a regexp that would
> work, but I was using Perl DBI/DBD, so I used the "lookslikenumber"
> function. (I forget the exact name now.)
Do you mean looks-like-a-number or is-a-number?
Both questions are answered here frequently but only the former is
answered in the FAQ.
(~$x ne ~"$x") will tell you if $x _is_ a number.
> I couldn't find it in any of the FAQ's or my books...
Does your FAQ not have "How do I determine whether a scalar is a
number/whole/integer/float?"
But that answer is flawed, because it only tells you if it
looks-like-a-number.
> just lots of references to the fact that Perl doesn't care if it's
> a number or a string.
Well, yes 99.99% of the time you don't care if something that looks
like a number actually is a number.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: Thu, 28 Sep 2000 18:03:37 -0000
From: cberry@cinenet.net (Craig Berry)
Subject: Re: newbie question
Message-Id: <st71vp4n1esac1@corp.supernews.com>
Jon S. (jonceramic@nospammiesno.earthlink.net) wrote:
: Is there an easy way to check if a scalar is a number?
Yes, for various types of "number" (integer, floating point, with or
without exponential notation, and so forth). The FAQ covers this
exhaustively.
: But, how would I check if I wasn't using that module? I couldn't find
: it in any of the FAQ's or my books... just lots of references to the
: fact that Perl doesn't care if it's a number or a string.
Watch your phrasing at the end, there; in Perl, 'string' is a superset of
'number'. :) See perlfaq4, "How do I determine whether a scalar is a
number/whole/integer/float?" By the way, I found this in one try using
perldoc -q 'is a number'
--
| Craig Berry - http://www.cinenet.net/~cberry/
--*-- "Quidquid latine dictum sit, altum viditur."
|
------------------------------
Date: Thu, 28 Sep 2000 09:31:07 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: Perl Programmer needed for a quick gig
Message-Id: <39D3724B.DD644063@vpservices.com>
Phillip Smith wrote:
>
> We've had a Perl script developed... and we're convinced it's trash.
> It does what it's supposed to -- but barely and it's not very smooth
> or secure.
>
> You are a Perl programmer with a free afternoon ('cause that's all it
> will take) and enjoy laughing at other people's sloppy work.
Hmm, let's see, you have the expertise to know how bad this script is
and how long it will take to fix it and you can't fix it yourself? That
seems rather unbelievable to me. It makes me wonder how you will
evaluate the work of the person you hire to fix it.
> You would
> like to make some bucks and help out a small web development company
> in Canada.
>
> You're a star! We're happy! World peace is next on your agenda...
You would like to post a job opportunity in a newsgroup without the word
"jobs" in the title? We're unhappy! Common politeness is next on your
agenda...
--
Jeff
------------------------------
Date: Thu, 28 Sep 2000 09:50:30 -0700
From: Skot <gstaylor@netscape.net>
Subject: Re: Perl Programmer needed for a quick gig
Message-Id: <39D376D6.5A41A484@netscape.net>
Phillip Smith wrote:
>
> Hi,
>
> We've had a Perl script developed... and we're convinced it's trash.
> It does what it's supposed to -- but barely and it's not very smooth
> or secure.
>
> You are a Perl programmer with a free afternoon ('cause that's all it
> will take) and enjoy laughing at other people's sloppy work. You would
> like to make some bucks and help out a small web development company
> in Canada.
How do you know it will only take an afternoon?
Skot
------------------------------
Date: Thu, 28 Sep 2000 16:46:55 GMT
From: phillip.smith@sympatico.ca (Phillip Smith)
Subject: Re: Perl Programmer needed for a quick gig
Message-Id: <39d373ac.59475271@news1.on.sympatico.ca>
On Thu, 28 Sep 2000 09:31:07 -0700, Jeff Zucker <jeff@vpservices.com>
wrote:
Jeff, you are right -- and I apologize.
I'm young and brash and prone to uncontrollable behaviour (such as
that post)...
...but I was really stuck.
As for my Perl programming capabilities, you are correct. If I had the
time and patience to program it -- I would.
Unfortunatly, I'm trying to run the business -- which, incidentally,
takes up about 27 of the 24 hours I have each day. You do the math.
I'm sorry to have upset the few people that I did... but I've recieved
several positive responses... and I'm just trying to help you help me
help you... ; )
Cheers,
p.
>Phillip Smith wrote:
>>
>> We've had a Perl script developed... and we're convinced it's trash.
>> It does what it's supposed to -- but barely and it's not very smooth
>> or secure.
>>
>> You are a Perl programmer with a free afternoon ('cause that's all it
>> will take) and enjoy laughing at other people's sloppy work.
>
>Hmm, let's see, you have the expertise to know how bad this script is
>and how long it will take to fix it and you can't fix it yourself? That
>seems rather unbelievable to me. It makes me wonder how you will
>evaluate the work of the person you hire to fix it.
>
>> You would
>> like to make some bucks and help out a small web development company
>> in Canada.
>>
>> You're a star! We're happy! World peace is next on your agenda...
>
>You would like to post a job opportunity in a newsgroup without the word
>"jobs" in the title? We're unhappy! Common politeness is next on your
>agenda...
>
>--
>Jeff
------------------------------
Date: Thu, 28 Sep 2000 16:48:51 GMT
From: phillip.smith@sympatico.ca (Phillip Smith)
Subject: Re: Perl Programmer needed for a quick gig
Message-Id: <39d374ff.59814398@news1.on.sympatico.ca>
On Thu, 28 Sep 2000 09:50:30 -0700, Skot <gstaylor@netscape.net>
wrote:
Same response as I've posted to a similar question...
>Phillip Smith wrote:
>>
>> Hi,
>>
>> We've had a Perl script developed... and we're convinced it's trash.
>> It does what it's supposed to -- but barely and it's not very smooth
>> or secure.
>>
>> You are a Perl programmer with a free afternoon ('cause that's all it
>> will take) and enjoy laughing at other people's sloppy work. You would
>> like to make some bucks and help out a small web development company
>> in Canada.
>
>How do you know it will only take an afternoon?
>
>Skot
------------------------------
Date: Thu, 28 Sep 2000 15:56:25 GMT
From: i0519@my-deja.com
Subject: Perl trouble
Message-Id: <8qvpn4$7qa$1@nnrp1.deja.com>
Hi,
I am using Perl to program a CGI. I found a bug in my program, which
is that when we push the form summit button in the Homepage as quickly
as we could, we are so surprised to find that the Perl is too slow to
handle our request and lead to an error.
So, how to prevent user's send their form too quickly?
Regards,
Andrew
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 28 Sep 2000 09:34:58 -0700
From: "Godzilla!" <godzilla@stomp.stomp.tokyo>
Subject: Re: Perl trouble
Message-Id: <39D37332.6B364B0F@stomp.stomp.tokyo>
i0519@my-deja.com wrote:
> I am using Perl to program a CGI. I found a bug in my program, which
> is that when we push the form summit button in the Homepage as quickly
> as we could, we are so surprised to find that the Perl is too slow to
> handle our request and lead to an error.
> So, how to prevent user's send their form too quickly?
Are you familiar with a notion some of us know as common sense?
How many visitors will sit, staring intently at their monitor,
mouse posed and ready to click on a submit button the very
instant it appears?
Jeeeshhh.... this one must a variation on Abigail's September crowd.
Print your submit button as the last item of your form action,
then work on writing higher quality troll articles. This one
is inanely annoying.
Godzilla!
--
Dr. Kiralynne Schilitubi ¦ Cooling Fan Specialist
UofD: University of Duh! ¦ ENIAC Hard Wiring Pro
BumScrew, South of Egypt ¦ HTML Programming Class
------------------------------
Date: Thu, 28 Sep 2000 17:23:02 GMT
From: Yanick Champoux <yanick@babyl.sympatico.ca>
Subject: Re: Perl trouble
Message-Id: <W7LA5.298656$1h3.6801844@news20.bellglobal.com>
i0519@my-deja.com wrote:
: Hi,
: I am using Perl to program a CGI. I found a bug in my program, which
: is that when we push the form summit button in the Homepage as quickly
: as we could, we are so surprised to find that the Perl is too slow to
: handle our request and lead to an error.
: So, how to prevent user's send their form too quickly?
Coat your users' keyboards with morphine?
Seriously, there is no way to control how frenetically users
can reload a page. What you can do, however, is to make sure
that the cgi script fails gracefully, if it has to fail (ie,
tells the user that the server ressources are busy something
else instead of dying a messy death).
This being said, perhaps showing us the barfing code woul help
us pinpoint what is wrong with it...
Joy,
Yanick
--
eval" use 'that poor Yanick' ";
print map{ (sort keys %{{ map({$_=>1}split'',$@) }})[hex] }
qw/8 b 15 1 9 10 11 15 c b 13 1 12 b 13 f 1 c 9 a e b 13 0/;
------------------------------
Date: Thu, 28 Sep 2000 17:06:27 +0200
From: "Frank Sonnemans" <fs.mail@wanadoo.be>
Subject: Re: Perl vs. PHP/Java
Message-Id: <20000928.170627.652@scuba.sbs-online.com>
In article <slrn8t134e.ej9.rgarciasuarez@rafael.kazibao.net>,
rgarciasuarez@free.fr (Rafael Garcia-Suarez) wrote:
> fritz.heinrichmeyer@fernuni-hagen.de wrote in comp.lang.perl.misc:
>>Hello,
>>
>>i consider the move from php to perl, as i think there are at least
>>three phantastical replacements for php, even Zope (Mason, Embperl,
>>Apache::ASP) and perl is more powerful (multiple return, read syntax for
>>nested hashes and nested list, "a breath of lisp" btw. )
>
> The thing I miss the most with PHP is regular expressions. Other things
> are not so important for most CGI programs.
>
Actually PHP4 supports Perl style regular expressions.
------------------------------
Date: 28 Sep 2000 15:14:54 -0000
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Problem w/ associative arrays
Message-Id: <8qvn9e$ag$1@lublin.zrz.tu-berlin.de>
<lishy1950@my-deja.com> wrote in comp.lang.perl.misc:
>Hello
>I'm working with an array and getting the following error message:
>
>Didn't enter because index = *filename*
This isn't a Perl error message. Does your program produce it?
>I set my array base to 1, which is what I want:
>$[ = 1;
Setting $[ is *strongly* discouraged. The feature is still there to
keep elderly scripts happy, but it's no longer used in production code.
>It seems the array is off by 1. The script is very long, but basically I
>set the @files=("numerous file names");, set variables in the files into
>hashes: %somevar= ("blah","N","blah","N");. Any ideas or suggestions?
>I consulted the Programming Perl book, but I'm not sure where to
>specifically find examples of this.
This sounds almost like you changed $[ as an afterthought, in a partly
or completely written program. There's hardly a chance to make this
work in a substantial script. Change it back.
Anno
------------------------------
Date: 28 Sep 2000 15:57:22 GMT
From: abigail@foad.org (Abigail)
Subject: Re: Problem w/ associative arrays
Message-Id: <slrn8t6qgk.lo9.abigail@alexandra.foad.org>
Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMDLXXXV
September MCMXCIII in <URL:news:8qvn9e$ag$1@lublin.zrz.tu-berlin.de>:
{}
{} Setting $[ is *strongly* discouraged. The feature is still there to
{} keep elderly scripts happy, but it's no longer used in production code.
Elderly scripts that are still around are very much likely to be
production code. Backwards compatibility isn't remained for your toy
program you spend 5 minutes at in 1993 and never looked at again -
it's for keeping production code in production.
Abigail
--
perl -wle 'print "Prime" if (1 x shift) !~ /^1?$|^(11+?)\1+$/'
# Two carp darting in
# the pool. A pair of nesting
# swallows. A pike darts.
------------------------------
Date: Thu, 28 Sep 2000 16:35:17 GMT
From: jonceramic@nospammiesno.earthlink.net (Jon S.)
Subject: Re: Programming the Perl DBI
Message-Id: <39d372d3.11629303@news.earthlink.net>
On Wed, 27 Sep 2000 20:42:49 -0400, Sid Malhotra <sxm124@po.cwru.edu>
wrote:
>I am looking to buy "Programming the PERL DBI: Database Programming with
>PERL" by Alligator Descartes and Tim Bruce. I need to start writing
>scripts with better databases than the plain text that I am using right
>now.
>
>Any suggestions? Comments?
I love the book. I hold it in one hand and keep my browser pointed to
the doc's at www.mysql.com or the DBI docs page and I do fine.
Also, if you do you use mysql, you'll find the Oreilly book on msql
mysql has the chapter on CGI programming posted online at the oreilly
page.
Jon
------------------------------
Date: Thu, 28 Sep 2000 16:36:42 GMT
From: chadbour@wwa.com (James Weisberg)
Subject: Re: Questions about space-saving techniques
Message-Id: <usKA5.5654$l35.133134@iad-read.news.verio.net>
In article <eXvA5.10675$td5.1897801@news1.rdc2.pa.home.com>,
Ben Kennedy <bkennedy@hmsonline.com> wrote:
>"James Weisberg" <chadbour@wwa.com> wrote in message
>news:zHsA5.5155$l35.125439@iad-read.news.verio.net...
>> And then, if I wrote that correctly, @record will unpack correctly
>> using $packstring as the reference instruction. So at this point it is
>> speculation whether or not the 40-bytes tacked on to the beginning of
>> the record string, for every record, saves more memory than simply
>> packing the whole record as a string of long ints as above. Certainly
>> I know this will take more processing time, but that I'm willing to
>> sacrifice for a significant memory savings.
>
>That depends solely on your data. You could also probably optimize your
>pack template somewhat, by doing things such as turning CCCC to C4 - you'd
>have to burn another byte to specify the length of the template.
Yes, tinkering around a bit more, I wrote two functions:
sub dbrec_compress {
my $packstr = "";
for (@_) {
if (! defined $_ )
{ $_ = '';
$packstr .= 'a'}
elsif ( $_ < 0 )
{ die "Negative field record $_ not permitted in db.\n")}
elsif ( $_ < 256 )
{ $packstr .= 'C'}
elsif ( $_ < 65536 )
{ $packstr .= 'S'}
elsif ( $_ < 4294967296)
{ $packstr .= 'L'}
else { die "Field record $_ too large to pack.\n")}
}
my $packlen = length($packstr);
return pack("Ca$packlen$packstr", $packlen, $packstr, @_);
}
sub dbrec_uncompress {
my $record = shift;
my $packlen = unpack("C", $record);
my $packstr = unpack("a$packlen", substr($record, 1));
return unpack($packstr, substr($record, $packlen + 1));
}
The packlen is stored as a C-type at the beginning of each record
and it is used to decode how many elements are being represented in the
packstring. The packstring is then unpacked; and then finally the
record itself is unpacked and returned. I could modify this a bit more
to squeeze CCCC into C4 as you suggest above, and that would change
packlen, but it shouldn't break the code above as packlen is simply
the length of $packstr (and not the number of elements in the record).
If you're interested, I could use a suggestion on how to take a
typical packstring like: (LCCCaCaCCaCaCaaaaaaaaaaCCCaaaaaCCCaaaaaC)
and turn that into (LC3aCaC2aCaCa10C3a5C3a5C). Just as an exercise
in efficiency, it would be interesting to see how different Perl
hackers write that operation.
>But overall, is it really even worth it? Your original post mentioned
>"several thousand records", and even at 40 integers per record, is not a
>huge amount of resources.
Well now you're asking the tough questions! ;-)
First off, I probably didn't explain things very clearly in my
original post because I didn't want to bog down the reader with details
that were not germane to compressing the record.
There may be more than 40 fields per record; it depends on the type
of database being constructed. That's why I wrote the functions above so
that they do not depend on a strict 40-element record length. And I should
have said there could be as many as several thousand records *per day*.
My hash keys are $date, $object, $interval. Thus I can represent several
days worth of objects in my hash. The $interval value is basically a time
of day reference. Currently I've broken the day into 5-minute slices and
represented it by numbers 1-288, but that too could change if I want a
finer granularity (thus creating more records per day).
Now you see how more and more memory could be chewed up.
>Another thing, your original post mentioned only needing to
>process one record at a time - why not then iterate over the tied hash with
>each()? Then only one record is in memory at a time.
And this here is an even tougher question!
And it's one I've been wrestling with for a while. As I said in my
original post, I'm using MLDBM to do multidimensional ties. And because
of the way MLDBM works, it's a bit finicky FETCHing records out of the
database. In fact, given a $date and an $object, it FETCHes *all*
records (i.e. all intervals) associated with that date and object. I
cannot control that part (and you can see the MLDBM man page for more
if interested).
But at that point I can either chose to stuff all the records into
a big hash, $DB{$date}{$object}{$interval} = @record, or I can loop over
the records and decide which ones I want and then do something with them.
I decided up front that I would write a generic read_db() function
and store all the records for all of the requested objects for all of
the requested days in memory BEFORE I decided what should be done next;
and return the caller the $DB hash with all of that information.
Now you see on the downside that I can potentially use up a lot of
memory that way (hence my original questions). But on the plus side, only
the downstream functions need to concern themselves about what to do with
all these records. And while I only need to process a record at a time,
the goal is to make packets out of this information and I could very well
want to re-use a record several times to make several packets and so for
the price of one FETCH, I can keep the record in memory and potentially
use it several times using a direct lookup in the hash.
Eventually, this program might develop batch-processing capabilities,
whereby several different packets are asked for and the needed records are
FETCHed once and processed for all the submitted jobs. Or perhaps the
program might even stay resident in memory as some kinda server process
and clients could connect to it and also submit jobs. At that point,
having the records in memory might save a lot of FETCH time. So the goal
was to be able to keep about 30days worth of records in memory without
taking up so much space the process started swapping.
And if you're still reading, that seemed like a superior strategy
IF I could severely reduce the memory requirements and keep the processing
time down as well. On the the other hand, MLDBM requires what's known as
a Data Serializer to build database records and it defaults to DataDumper
which is a real pig, both in the size of the records stored on disk and
the time it takes to recall them. So then I used FreezeThaw and that was
like an order of magnitude better than DataDumper. But still, if I wanted
to FETCH several thousand records *per day*, it still took quite a bit of
time (and memory) to do it. So at that point, if I could save a great
chunk of memory by packing records to save FETCH time, I'd do it. However,
then I tried the Storable Serializer and that was like almost an order of
magnitude better than FreezeThaw! So at this point I'm at a crossroads
because FETCHing those several thousand records per day is taking like a
second instead of several seconds and so I could FETCH a whole month's
worth of records in under a minute to create packets without needing to
stuff them all in memory BEFORE I process them. And since the vast majority
of requests will not be for a month's worth of records, it may make sense
to just FETCH the records out of the database for every request and not
even worry about compressing them in memory. I would need to modify my
read_db() function to take as an argument, some function pointer so that
it could be called for each record of the tied database.
Sorry you asked? ;-)
If you have any comments on that, I'd be glad to here them. For
me, programming is every bit as much about technique as it is about form.
So if my technique is bad, having great form doesn't matter much.
>Another thing occured
>to consider, which maybe someone else can answer - you seem satisfied with
>the storage on disk, but want to save space in memory, but what is the
>overhead of Perl variables (maybe the space saved is negligable)? And does
>Perl automatically select the best storage mechanism for numbers? These
>things I do not know.
I don't think so. I believe these numbers FETCHed out of the database
are are simply stored as strings and then converted to numbers as needed
in context. That's why explicitely using pack to turn an array record into
a vector of packed L's, S's, and C's takes much less memory.
>> Is this portable? I believe assuming a 1-byte char is pretty portable
>> but assuming a 2-byte short might not be. If you pack a number < 65536 as
>> an unsigned short, are you gaurenteed to return 2 as its length on any
>> machine which doesn't store 2-byte shorts? If this is not portable, should
>> the uncompress function above refer to some global vars which know the
>> size of these datatypes:
>
>from perlfunc pack, a signed short is exactly 16 bits, and a signed long is
>exactly 32 bits - an integer might vary though. I imagine that assuming a 8
>bit char is probably ok too.
Right:
S An unsigned short value.
(This 'short' is _exactly_ 16 bits, which may differ from
what a local C compiler calls 'short'.)
That I'll buy. But is assuming the length of an S-packed value
to be 2, always and forever, portable? I guess that's true as well
if Perl is ignoring what the local C compiler calls a short.
Thanx again for any comments.
--
World's Greatest Living Poster
------------------------------
Date: Thu, 28 Sep 2000 10:27:02 -0700
From: Tim Conrow <tim@ipac.caltech.edu>
Subject: Re: Questions about space-saving techniques
Message-Id: <39D37F66.80FABA8A@ipac.caltech.edu>
James Weisberg wrote:
> My idea, which is just in the "think-about" stage at this point,
> might be to build a pack string of 40-chars which describe the size
> of each element in the 40-field data set and instead of returning an
> array, return the pack string. Then perhaps I could do something like
>
> $packstring = rec_compress(@record);
> $DB{$date}{$object}{$interval} =
> pack "40a".$packstring, $packstring, @record;
>
> The idea being that the first 40-chars of the record string
> describes the packing of the next 40 elements so that I could write:
Well, if you're going to go that far, you may as well go further. Have
rec_compress return a bit string rather than pack templates. Since you're only
concerned about 3 options (1 byte, 2 bytes, 3 bytes) and unconcerned about run
time, something like this might work.
my $i;
my $packstr="";
vec($packstr,$i++,2) = $_<256 ? 0 : ($_<65536 ? 1 : 2) for (@record);
For @record==40 numbers, length($packstr)=10. I leave the rest to you.
--
-- Tim Conrow tim@ipac.caltech.edu |
------------------------------
Date: Thu, 28 Sep 2000 10:40:01 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Questions about space-saving techniques
Message-Id: <MPG.143d224eb798330098add0@nntp.hpl.hp.com>
In article <usKA5.5654$l35.133134@iad-read.news.verio.net> on Thu, 28
Sep 2000 16:36:42 GMT, James Weisberg <chadbour@wwa.com> says...
...
> If you're interested, I could use a suggestion on how to take a
> typical packstring like: (LCCCaCaCCaCaCaaaaaaaaaaCCCaaaaaCCCaaaaaC)
> and turn that into (LC3aCaC2aCaCa10C3a5C3a5C). Just as an exercise
> in efficiency, it would be interesting to see how different Perl
> hackers write that operation.
More people would see your challenge were it not buried amidst a 186-
line post.
s/(([A-Za-z])\2+)/$2 . length $1/eg
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 28 Sep 2000 16:58:01 GMT
From: add@netcom.com (Arthur Darren Dunham)
Subject: Re: retrieve the date and size of a file running
Message-Id: <8qvtap$gid$1@slb6.atl.mindspring.net>
In article <8qv123$ju6$1@nnrp1.deja.com>, <pim53@my-deja.com> wrote:
>In article <8qtco4$a2p$1@nnrp1.deja.com>,
> Glenn West <westxga@my-deja.com> wrote:
>> In article <8qt6lf$4ao$1@nnrp1.deja.com>,
>> pim53@my-deja.com wrote:
>> > Hi,
>> > I want to retrieve the date of last modification
>> > of a file and its size.
>> > So I used -s and -M to get that.
>> > But somehow, for a file that is running at the
>> > same time this test return that the file doesn't
>> > exist even it does.
>> > SO I used th `ls`command but I cannot get a full
>> > date like 09/27/2000 17:45:56
>> > How can I do?
>> > Thanks...
>>
>> perldoc -f stat
>>
>> Sent via Deja.com http://www.deja.com/
>> Before you buy.
>>
>
>`stat` doesn't work since the file doesn't exist from the Perl script!
I have no idea what you mean by this.
You have a file that 'ls' can see but 'stat' can't? I doubt that.
--
Darren Dunham ddunham@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco Bay Area
< Please move on, ...nothing to see here, please disperse >
------------------------------
Date: Thu, 28 Sep 2000 13:00:33 -0400
From: Lou Moran <lmoran@wtsg.com>
Subject: Rounding Numbers...
Message-Id: <36u6tss5tkosbfnu0hho5ctk0s767pkbj4@4ax.com>
--I have looked in perldoc, but I'm not very god at it yet... viva la
html in activestate... anylou...
--I don't want any rounding on numbers. even if the number is
9.999999 I want it to be 9, not 10.
--how? or better, where?
Registered Linux user number 187055
------------------------------
Date: Thu, 28 Sep 2000 17:56:42 GMT
From: Yanick Champoux <yanick@babyl.sympatico.ca>
Subject: Re: Rounding Numbers...
Message-Id: <uDLA5.298666$1h3.6804135@news20.bellglobal.com>
Lou Moran <lmoran@wtsg.com> wrote:
: --I have looked in perldoc, but I'm not very god at it yet... viva la
: html in activestate... anylou...
: --I don't want any rounding on numbers. even if the number is
: 9.999999 I want it to be 9, not 10.
: --how? or better, where?
Where: perldoc -f int
How: $integer_part = int( $float );
Joy,
Yanick
--
eval" use 'that poor Yanick' ";
print map{ (sort keys %{{ map({$_=>1}split'',$@) }})[hex] }
qw/8 b 15 1 9 10 11 15 c b 13 1 12 b 13 f 1 c 9 a e b 13 0/;
------------------------------
Date: Thu, 28 Sep 2000 15:51:07 GMT
From: joshfeingold@my-deja.com
Subject: Re: Send HTMLmail via Perl Script
Message-Id: <8qvpd7$7l1$1@nnrp1.deja.com>
Thanks to all for their help... I got it working.
Josh
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 28 Sep 2000 11:14:52 -0500
From: "Andrew N. McGuire " <anmcguire@ce.mediaone.net>
Subject: Re: Sorry - TOTAL newbie
Message-Id: <Pine.LNX.4.21.0009281103150.19613-100000@hawk.ce.mediaone.net>
On Thu, 28 Sep 2000, eyedunno quoth:
e> Hi,
Hello!
e> Sorry about this but could somebody please take 3 seconds to show me how to
e> write this in Perl
Why don't you take 30 minutes to research it for yourself?
[ snip ]
e> mystr$ = "heres a short one"
Hmmm. The '$' goes on front -> $mystr, and statements in Perl are
separated by ';'.
e> for i = 0 to len(mystr$) step 2
^^ !!!
^^ -> No '$' sign
!!! -> There is no len operator (perldoc -f length)
e> I've tried
I see very little evidence of that, you look as though you made just enough
of an attempt to throw together something so that you can say "I've tried".
e> -------------------------------
e> open (MYFILE, "myfile.txt");
No error checking. (perldoc -f open)
e> my @myfile = <MYFILE>;
e> close (MYFILE);
Do you want to slurp the file, or do a line at a time iteration over it?
Perhaps:
while (<MYFILE>) {
# statements ...
}
It may not be what you want, but consider it.
e> for ( $i = 0; $i <= $#myfile; $i=$i+2 ) {
e> ....}
.... is not valid Perl syntax, again you look as though you have thrown
just enough together to attempt to justify not doing your own research.
e> but it doesn't work :-(
Of course it doesn't. Start with 'perldoc perl', figure out which sections
of TFM are pertinent, and read them.
anm
--
$ENV{PAGER} = 'cat';
system perldoc => '-t', '-F', $0;
=head1
Just another Perl Hacker
------------------------------
Date: Thu, 28 Sep 2000 18:24:06 +0100
From: "eyedunno" <paulmaguire@ntlworld.com>
Subject: Re: Sorry - TOTAL newbie
Message-Id: <A2LA5.1406$7h.14509@news2-win.server.ntlworld.com>
Thanx Seiu
YOU obviously understood that all I was asking for was a simple syntax check
and that the first example was a BASIC (Andrew) example of what I was trying
to achieve in Perl!
Yes , I had tried plenty of sites for the proper 'for' syntax but only found
examples such as
for $i (1..10) or
for ( $i = 0; $i <= $#myfile; $i++ )
but none that would replace my mistaken $i=$i+2
in
for ( $i = 0; $i <= $#myfile; $i=$i+2 ) {
....}
The last three replies were obviously from EXPERTS, that why
1) They couldn't see the OBVIOUS mistake (even I knew it was obvious, I just
didn't know how to fix it!)
2) Some have that much experience with programming, they don't even
recognize BASIC.
Anyhow
Thanx Seiu
------------------------------
Date: Thu, 28 Sep 2000 16:54:05 GMT
From: Alex Hart <news@#nospam#althepal.com>
Subject: splitting lines with a regex
Message-Id: <NIKA5.563$uO1.45819@typhoon1.ba-dsg.net>
I can't figure out how to make perl do this. Can someone please help??
Thanks.
I have text coming in from an email. Sometimes the text contains
carriage returns, and sometimes not. I want to split up the lines into
pieces that can easily fit on the screen. I figure that 60 chars or so
is safe, but 80 might be OK too. What I'd like to do is split the line
at 60 characters (at the next space at least), unless there's a \n
within 80 characters (from the beginning.).
This is how I do it now :
$email_body =~ s/\n|(.{60}.*?\s)/$1\n/g; # puts a \n at the first space
after 60 characters
but with this I get stuck with a lot of 2 word lines when there is a \n
at character 75. How can I have it look ahead to see if there is a \n
within 20 characters before splitting the line. Thanks.
- Alex
------------------------------
Date: Thu, 28 Sep 2000 10:03:00 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: splitting lines with a regex
Message-Id: <39D379C4.C893484A@vpservices.com>
Alex Hart wrote:
>
> I have text coming in from an email.
> ...
> but with this I get stuck with a lot of 2 word lines when there is a \n
> at character 75.
That is only one of the many problems you will face. Perhaps you would
be better off with Damian's new module, Text::Autoformat, the README for
which begins:
Text::Autoformat provides intelligent formatting of plaintext without
the need for any kind of embedded mark-up. The module recognizes
Internet quoting conventions, a wide range of bulleting and number
schemes, centred text, and block quotations, and reformats each
appropriately.
--
Jeff
------------------------------
Date: Thu, 28 Sep 2000 10:39:05 -0700
From: Tim Conrow <tim@ipac.caltech.edu>
Subject: Re: What does this do?!
Message-Id: <39D38239.9452BD@ipac.caltech.edu>
Gwyn Judd wrote:
> >
> >Are we looking at a demented implementation of
> >the solitaire game, per any chance?
>
> Very good, I knew you'd get the name right eventually! Although it's not
> a version of the game per-se but rather an encryption algorithm that can
> be carried out with a pack of cards, hence the name solitaire. I think
> if you read the code with that in mind you will be able to understand
> how it works much more easily.
>
> It was invented by a guy called Neal Stephenson for his book
> "Cryptonomicon" which is I believe the only novel ever written for
> computer geeks. Very worthwhile.
Just a note about credit where it's due: Neal Stephenson didn't invent this very
interesting cipher, he just wrote about it. It was developed Bruce Schneier. Do
a goolgle search on "cryptonomicon solitaire". E.g.
http://www.hedonism.demon.co.uk/paul/solitaire/
--
-- Tim Conrow tim@ipac.caltech.edu |
------------------------------
Date: Thu, 28 Sep 2000 15:26:56 GMT
From: "Philip Garrett" <philipg@atl.mediaone.net>
Subject: Re: Where is NDBM_File.pm?
Message-Id: <4rJA5.23512$2z2.4303399@typhoon.southeast.rr.com>
<innoventures@my-deja.com> wrote in message
news:8qv9cm$pkc$1@nnrp1.deja.com...
> Okay, hopefully I'm not being as stupid as I suspect I'm being, but here
> we go:
>
> I upgraded to Perl 5.6.0, but I can't find NDBM_File.pm which one of my
> CGI programs need.
>
> Is it supposed to be installed as part of the standard distribution, as
> a part of the AnyDBM_File.pm package.
NDBM_File comes standard with perl 5.6.0, but it's not part of AnyDBM_File.
The most likely reason that it's not installed is that you don't have the
ndbm library and/or headers installed where Configure could see them.
Install the ndbm library first (if you use Linux, there may be a package you
can install).
> How do I install this functionality?
cd perl-5.6.0/ext/NDBM_File
perl Makefile.PL
make
su -c 'make install'
hth,
p
------------------------------
Date: Thu, 28 Sep 2000 10:03:44 -0700
From: Sarah Officer <OfficerS@aries.tucson.saic.com>
To: innoventures@my-deja.com
Subject: Re: Where is NDBM_File.pm?
Message-Id: <39D379F0.9062F086@aries.tucson.saic.com>
Are you on a unix machine? When I configure, I append all stdout &
stderr to a log file. I had a little trouble getting GDBM_File.pm
on one of my platforms, and it turned out that the system wasn't
finding the gdbm library correctly. I still don't know why, but by
tweaking configure parameters I got it to work.
I do this:
sh ./Configure -des -Dlocincpth=/foo/include
-Dloclibpth=foo/lib/$MACHINE -Dprefix=/install/me/here
-Uinstallusrbinperl >& log
Then
grep -i dbm log
I saw that gdbm_open wasn't found by configure even though the
symbol was in my loclibpth library. So I added to Configure
parameters "-Di_gdbm -Dusenm". Search in the INSTALL file and
you'll see what these parameters are about. These corrected the
problem.
Another possibility is that the NDBM_File.pm exists, but your
PERL5LIB environment variable doesn't include the correct path.
I hope this helps.
Sarah
officers-nospam@aries.tucson.saic.com
innoventures@my-deja.com wrote:
>
> Okay, hopefully I'm not being as stupid as I suspect I'm being, but here
> we go:
>
> I upgraded to Perl 5.6.0, but I can't find NDBM_File.pm which one of my
> CGI programs need.
>
> Is it supposed to be installed as part of the standard distribution, as
> a part of the AnyDBM_File.pm package.
>
> How do I install this functionality?
>
> Can you help me with this?
>
> Sample Program:
>
> #!/usr/bin/perl
> use NDBM_File;
> tie(%h, 'NDBM_File', 'userinfo.dbm', O_RDWR|O_CREAT, 0640);
> print "Content-type: text/html\n\n";
> print "<pre>\n";
> print %h;
> print "</pre>\n";
> untie %h;
>
> This should just dump the contents of the file, but instead it gives
> this:
>
> Can't locate loadable object for module NDBM_File in @INC (@INC
> contains: /usr/lib/perl5/5.6.0/i686-linux /usr/lib/perl5/5.6.0
> /usr/lib/perl5/site_perl/5.6.0/i686-linux /usr/lib/perl5/site_perl/5.6.0
> /usr/lib/perl5/site_perl .) at ./test.cgi line 4
> Compilation failed in require at ./test.cgi line 4.
> BEGIN failed--compilation aborted at ./test.cgi line 4.
>
> Can you PLEASE help me fix this so I can use this CGI program?
>
> Thanks!
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 V9 Issue 4460
**************************************
