[22569] in Perl-Users-Digest
Perl-Users Digest, Issue: 4790 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 31 03:05:45 2003
Date: Mon, 31 Mar 2003 00:05:10 -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 Mon, 31 Mar 2003 Volume: 10 Number: 4790
Today's topics:
Re: And... <amiba128@sd6.so-net.ne.jp>
Re: And... <no@spam.for.me.invalid>
array keys for hashes (Interesting) <f_rudzic@localhost.localdomain>
Re: array keys for hashes (Interesting) <uri@stemsystems.com>
Re: array keys for hashes (Interesting) <bwalton@rochester.rr.com>
Re: CGI.pm or roll-your-own? <tassilo.parseval@rwth-aachen.de>
Re: CGI.pm or roll-your-own? <noreply@gunnar.cc>
Re: CGI.pm or roll-your-own? <tore@aursand.no>
Re: CGI.pm or roll-your-own? <tassilo.parseval@rwth-aachen.de>
Re: CGI.pm or roll-your-own? <noreply@gunnar.cc>
Re: CGI.pm or roll-your-own? <jasonp@uq.net.au>
Re: CGI::ContactForm 1.03 - Feedback request <tore@aursand.no>
Re: DBI problem <goldbb2@earthlink.net>
Re: help understand dereferencing chance@austin.rr.com
MSWin32 Active State Perl Question <mooncm.lbkejwiAhEgSfSe@dAcEbSaS>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 30 Mar 2003 22:45:24 -0600
From: "Ami" <amiba128@sd6.so-net.ne.jp>
Subject: Re: And...
Message-Id: <3e87bbcf$0$87914$45beb828@newscene.com>
My e-mail address isn't true. It is the address of the police in Japan.
I have not written the true e-mail address,
'cause I have guarded against the man like you from the beginning.
...Of course excuse for a lot of good persons without you.
I can't recieve anything, even if you send the virus.
All you send to the e-mail address arrives at the police in Japan and be only
checked with your name.
How stupis you are, poor Tore !
To tell the truth, I don't want to talk with you.
You, cann't teach me what I want to know aren't useful to me just like Saddam
Hussein.
So long !
------------------------------
Date: Mon, 31 Mar 2003 07:31:58 GMT
From: Nils Petter Vaskinn <no@spam.for.me.invalid>
Subject: Re: And...
Message-Id: <pan.2003.03.31.08.27.20.341490.1390@spam.for.me.invalid>
On Mon, 31 Mar 2003 06:45:24 +0200, Ami wrote:
> My e-mail address isn't true. It is the address of the police in Japan.
> I have not written the true e-mail address,
> 'cause I have guarded against the man like you from the beginning.
> ...Of course excuse for a lot of good persons without you. I can't
> recieve anything, even if you send the virus. All you send to the e-mail
> address arrives at the police in Japan and be only checked with your
> name.
> How stupis you are, poor Tore !
> To tell the truth, I don't want to talk with you. You, cann't teach me
> what I want to know aren't useful to me just like Saddam Hussein. So
> long !
I don't think you understand what a killfile is. Adding you to his
killfile simply means that his newsreader will skip/ignore any future
messages from you.
Now if you wish to be anonymous on usenet don't use a real email address,
use an address that you're sure won't lead to a real address. Making an
address up and adding .invalid at the end is a good way.
Now for the reasons Tore chose to ignore you:
Don't post in german in an english speaking group, while you were trying
to be polite to one person you ended up beeing impolite to the rest of the
group.
Don't place your reply above the post you respond to put your reply below
it. Replying above (called top posting) makes things harder to read and is
also considered impolite.
Noone cares about your views about Saddam, this is a technical newsgroup.
If you wish to discuss politics use a plitics newsgroup.
regards
NP
------------------------------
Date: Sun, 30 Mar 2003 22:31:29 -0500
From: Frank Rudzicz <f_rudzic@localhost.localdomain>
Subject: array keys for hashes (Interesting)
Message-Id: <rPOha.71354$Y47.245195@weber.videotron.net>
Hi,
If I create a hash with anonymous arrays as keys, as in:
%hash{($a,$b,$c)} = $value;
then weirdness begins here:
foreach $key (keys %hash){
print "$key"; #prints the string "$a $b $c"
local @arr = split ' ', "$key";
print "$arr[0]"; #prints the string "$a $b $c"
print "$arr[1]"; #prints the string ""
}
Can someone describe how I can get just the individual items $a $b and $c
within the 'foreach' loop above? One would expect the 'split' line to split
up the same string that's printed in the first line...
Frank
------------------------------
Date: Mon, 31 Mar 2003 05:14:37 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: array keys for hashes (Interesting)
Message-Id: <x73cl4w23c.fsf@mail.sysarch.com>
>>>>> "FR" == Frank Rudzicz <f_rudzic@localhost.localdomain> writes:
FR> If I create a hash with anonymous arrays as keys, as in:
FR> %hash{($a,$b,$c)} = $value;
FR> then weirdness begins here:
FR> foreach $key (keys %hash){
FR> print "$key"; #prints the string "$a $b $c"
FR> local @arr = split ' ', "$key";
FR> print "$arr[0]"; #prints the string "$a $b $c"
FR> print "$arr[1]"; #prints the string ""
FR> }
FR> Can someone describe how I can get just the individual items $a $b
FR> and $c within the 'foreach' loop above? One would expect the
FR> 'split' line to split up the same string that's printed in the
FR> first line...
perldoc perlvar and look for $; and then read about the hash feature
that variable assists.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Mon, 31 Mar 2003 05:15:21 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: array keys for hashes (Interesting)
Message-Id: <3E87CD83.9050509@rochester.rr.com>
Frank Rudzicz wrote:
> If I create a hash with anonymous arrays as keys, as in:
>
> %hash{($a,$b,$c)} = $value;
The weirdness begins earlier than you thought: that won't compile.
Perhaps you mean:
$hash{($a,$b,$c)} = $value; #?
>
> then weirdness begins here:
>
> foreach $key (keys %hash){
> print "$key"; #prints the string "$a $b $c"
Actually, it prints the string consisting of the same thing as:
join $;,($a,$b,$c);
where $; is the "sub-sep" character (by default ASCII 0x1c). So if you
split on that character, your should see things are fine. See:
perldoc perlvar
for more info.
> local @arr = split ' ', "$key";
> print "$arr[0]"; #prints the string "$a $b $c"
> print "$arr[1]"; #prints the string ""
> }
>
> Can someone describe how I can get just the individual items $a $b and $c
> within the 'foreach' loop above? One would expect the 'split' line to split
> up the same string that's printed in the first line...
Just split on subsep:
my @arr = split $;,$key;
...
>
> Frank
--
Bob Walton
------------------------------
Date: 31 Mar 2003 06:12:48 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b68m90$5df$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Greg Raven:
> In article <slrnb86k1u.4ck.tadmc@magna.augustmail.com>,
> tadmc@augustmail.com (Tad McClellan) wrote:
>
>> Rather than have them learn the 2 lines of code they'd need
>> with CGI.pm, you would have them learn a Whole Lot More lines
>> of punctuation-intensive gobbledy gook?
>>
>> How can that be better for an already overloaded beginner?
>
> Let me give you an example. Let's say that the AOB wants to try CGI.pm,
> and comes across this:
>
> #!/usr/local/bin/perl -w
> use CGI; # load CGI routines
> $q = new CGI; # create new CGI object
> print $q->header, # create the HTTP header
> $q->start_html('hello world'), # start the HTML
> $q->h1('hello world'), # level 1 header
> $q->end_html; # end the HTML
>
> As as self-proclaimed AOB, I get lines one and two; from line three on,
> the mystery begins.
As others already pointed out, the functional interface works just as
well and is easier to grok.
Remember that you are not required to use all of CGI.pm. I, for one,
think that it contains too much stuff. All the HTML-generating functions
could be dropped and should live in a different module. However, it is
no shame to only use the header() and param() function. You can
explicitely restrict yourself to that:
use CGI qw/header param/;
If you feel more comfortable with generating your HTML yourself, feel
free to do so. I do the same: only header() and param() (unless I really
need more, but I never did so far) and all of my HTML lives in large
here-documents. That's it. Thus I can reduce CGI.pm to only two
functions which should 'overload' not even a beginner.
> I realize that the documentation probably gives a more straightforward
> method of using CGI.pm, but there is so bloody much of it, in such
> non-beginner language (even finding it isn't straightforward -- perldoc
> CGI? Why not perldoc CGI.pm?), that after the dazzle of what can be done
> wears off, all that's left is the puzzlement as to how to do any of it.
The fact that it is 'perldoc CGI' instead of 'perldoc CGI.pm' isn't
specific to this module. The '.pm' suffix isn't really part of the
module name but only a convention to help perl find the files. But if
you prefer you can also look it up explicitely:
perldoc /path/to/CGI.pm
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Mon, 31 Mar 2003 08:19:31 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b68mml$2n5i8$1@ID-184292.news.dfncis.de>
Randal L. Schwartz wrote:
>>>>>>"Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>
>>>The code already "doesn't load" what it doesn't need.
>
> Gunnar> I know that you don't need to import all the symbols, but the whole
> Gunnar> thing is still compiled, isn't it?
>
> No, it uses a variant of "SelfLoader" called "the lincoln loader". It
> compiles code of itself only as necessary.
Does it? Thanks for letting us know, Randal, I had really no idea.
Seems like something that should be said more often, btw. (I have seen
more than one post in this group expressing concern about the size of
the module.)
> Really. This can be answered by looking at the code.
Well, I haven't looked too closely at the code, and parts of it is
above my head.
> Why do you keep challenging me EVERY TIME I say something to you?
Do I? Hmm.., maybe I do. Okay, let me try to answer that question.
I think it has something to do with the way you say it. You *say* or
*tell* in a way that I sometimes find patronizing. If you want to
avoid being "challenged", try to *explain* and *convince* instead.
Unfortunately you are not the only one who occationally uses a rather
aggressive arguing style, Randal; it rather seems to be part of the
culture in this group. I don't like that part. It's unnecessary. It's
provocative to me, so I react.
Hope that made some sense.
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Mon, 31 Mar 2003 08:35:05 +0200
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <pan.2003.03.31.05.56.34.507528@aursand.no>
On Mon, 31 Mar 2003 01:19:12 +0200, Gunnar Hjalmarsson wrote:
>> A couple of years ago there were _thousands_ of scripts using CGI.pm on
>> the web. Nobody had ever heard about DoS (for instance). Then DoS
>> rose from hell, and scripters shivered.
>>
>> Thanks to CGI.pm, there where only _one_ file on the planet that needed
>> correction. That same file was uploaded to _one_ site (CPAN). All
>> those who had been using CGI.pm could use _one_ utility to update their
>> server.
> As you may have seen in another post, I have taken my first steps as
> regards CGI.pm. One of the things I noticed was that you need to set a
> variable in order to have CGI.pm check the size of STDIN, so your
> example does not illustrate the 'magic' of CGI IMO.
Yes, it does; I'm illustrating the _main_ point with using CGI.pm as a
module opposed to using cargo cult code in production code.
If you've bothered to _read_ the CGI documentation, you can clearly see
that CGI.pm doesn't want to override anything that's perfectly common in
the normal world, ie. letting people upload n MB to the server.
It's up to _the developer_ to decided if that's something which should be
allowed.
> After all, checking $ENV{'CONTENT_LENGTH'} directly isn't appreciably
> harder, is it?
It is. Updating this in _one module_ is still much better than updating
in thousands of scripts.
--
Tore Aursand
------------------------------
Date: 31 Mar 2003 06:56:19 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b68oqj$73t$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Randal L. Schwartz:
>>>>>> "Gunnar" == Gunnar Hjalmarsson <noreply@gunnar.cc> writes:
>
>Gunnar> Have it ever been considered to split CGI.pm into more than one
>Gunnar> module, or maybe a main CGI.pm module that loads a number of sub
>Gunnar> modules? I'm thinking of a CGI::Param module, for instance, that you
>Gunnar> could use without loading the rest of it.
>
> The code already "doesn't load" what it doesn't need. As probably the
> third or fourth most frequently "used" module on the planet, there's
> been a lot of focus on it over the years.
But CGI.pm arguably has a very odd structure. I think this has
historical reasons. I just out of fun looked at the oldest CGI version I
could find on backpan (2.1). You wouldn't reckognize that it's the
predecessor of the current CGI.pm. It has no functional interface and
thus doesn't make use of any self-loading facilities either.
I think at some time in history there was the point when Lincoln had
better modularized CGI.pm. Instead the source has been contorted in
several very odd (some say interesting;-) ways to keep the structure of
only a single file intact. I am sure that if you were to write CGI.pm
from scratch, you'd choose a different approach (which is the whole
issue of doing things from scratch after all).
>Gunnar> And the documentation should of course be splitted accordingly...
>
> OK, I'm trying very hard not to make a comment about "search" and
> "learn to use a scroll bar".
My $PERLDOC_PAGER doesn't have a scroll-bar. :-)
Of course, you are right here. People should be happy about the
extensive documentation for CGI (or any module) and make frequent use of
'/' and 'n' while viewing it. On the other hand there are some perldocs
I really hate (for instance perlop.pod where I never instantly seem to
find what I am looking for). So wouldn't it be nice to have a
CGI/params.pod and CGI/html.pod etc. that only explained the parts
relating to parameter handling, HTML generation and so forth? I am never
interested in what CGI can do for me with respect to creating HTML. I
usually need documentation for the purely CGI-related things of this
module.
It might also stop people from attempting to come up with their own
broken form-parser once they find it easier to navigate through the
CGI.pm perldocs. It's because people seize a complexity in CGI.pm
(user-wise) that doesn't actually exist. The module is straight-forward
but they erronesouly assume they have to read all of the PODs.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Mon, 31 Mar 2003 08:58:38 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <b68p01$2pck4$1@ID-184292.news.dfncis.de>
Tore Aursand wrote:
> On Mon, 31 Mar 2003 01:19:12 +0200, Gunnar Hjalmarsson wrote:
>>After all, checking $ENV{'CONTENT_LENGTH'} directly isn't appreciably
>>harder, is it?
>
> It is. Updating this in _one module_ is still much better than updating
> in thousands of scripts.
It just struck me... You are talking about editing CGI.pm, while I
was comparing checking the env variable directly with setting the
$CGI::POST_MAX variable in the programs that use CGI. I have never had
root access to a web server, so the other option didn't cross my mind. ;-)
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 31 Mar 2003 00:09:18 -0500
From: Jason Parker-Burlingham <jasonp@uq.net.au>
Subject: Re: CGI.pm or roll-your-own?
Message-Id: <87smt42kch.fsf@freezer.burling>
sholden@flexal.cs.usyd.edu.au (Sam Holden) writes:
> Why anyone would actually use the OO interface is beyond me, since
> it is a domain in which in the *vast* majority of cases you only
> have one instance (I have *never* needed multiple CGI objects in one
> script).
CGI::Application uses it to great effect.
--
``I didn't program you for sarcasm.''
------------------------------
Date: Mon, 31 Mar 2003 08:35:03 +0200
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: CGI::ContactForm 1.03 - Feedback request
Message-Id: <pan.2003.03.31.06.07.26.482354@aursand.no>
On Mon, 31 Mar 2003 00:51:06 +0200, Gunnar Hjalmarsson wrote:
> Looking forward to your comments.
I just had a look at your code (again), and there are still room for
improvements;
1. Use CGI.pm wherever possible. There are a few places where
you ignore the superior CGI.pm. :)
2. Separate Perl code from "other"; I see there is room for
separating HTML, text and configuration directives into
separate files.
3. Instead of 'sub htmlize' I would have used a module for that.
There are a few entitites modules at CPAN.
Happy coding!
--
Tore Aursand
------------------------------
Date: Sun, 30 Mar 2003 22:45:02 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: DBI problem
Message-Id: <3E87B9BE.A6FE78A2@earthlink.net>
Bigus wrote:
>
> Benjamin Goldberg wrote:
> [..]
>>> I was largely hoping that due the predicted usage of it and the
>>> unlikelihood of actions like creating tables and inserting rows
>>> happening at exactly the same time that this problem wouldn't crop
>>> up and if it did, I could fix the DB manually.
>>> I guess it wouldn't be difficult for me to create a temp file,
>>> before the table is created or a row is inserted, put a flag in it,
>>> then delete the file after the action. Then if someone else comes
>>> along and tries the same thing, the script would check for the
>>> presence of the flag and if it finds it waits for a period of time.
>>
>> Unless you create the file using sysopen(), with the O_CREAT|O_EXCL
>> flags, there's *still* a race condition here.
>
> Unless I give each "lock" file a unique name, like "lock-1234.txt",
> "lock-3456", etc using a number randomly generated. Then when an
> instance of the script comes to performing a write task on the DB, it
> can check all files "lock-". In each file there could be a time stamp
> and the name of the table requiring locking (there is a table per
> newsgroup amd about 5 newsgroups). If the instance wants to amend a
> "locked" table it first of all checks the elapsed time between the
> timestamp in the file and present. If this is greater than the timeout
> length of the web server, then it assumes the lock file hasn't been
> deleted properly by a previous instance of the CGI and deletes it, and
> carries on with updating the DB. Otherwise it loops or sleep/loops
> until the lock is freed.
You're making things more and more and more complicated. And there's
probably still a race condition in the scheme you've outlined.
I would suggest you try and find some actual, pre-made, locking scheme,
and not try to roll your own.
>> Oh, and having it wait for a period of time isn't exactly the
>> greatest thing in the world, since you may end up keeping the
>> connection alive overly long -- it's ok to sleep for a little while,
>> but if you can't get the lock quickly enough, have the browser
>> disconnect and try again later.
>> See:
>> http://www.stonehenge.com/merlyn/WebTechniques/col54.html
>
> Interesting. To be honest, I don't have a full grasp of that article
> (what's a sentinel file?), so I'd need to sit down a and read it
> several more times and experiment with test scripts. If my above
> solution is feasible then I might escape that ;-)
The definition of "sentinel" is "One that keeps guard; a sentry."
A sentinel file is a file whose presence guards against two scripts
accessing the same data at once.
>>> However, that raises the question of what happens if someone hits
>>> the stop button their browser and the temp file/flag isn't deleted..
>>> hmmmm.. if you know any websites that discuss methods of
>>> locking/queueing processes like this, please let me know.
>>
>> If you're on *nix, then you can lock a filehandle using flock().
>>
>> If the process exits, the filehandle is automatically unlocked.
>>
>> On windows... I'm not sure. However, I believe that Access offers
>> locking of database tables, through a "LOCK <tablename>" statement.
>>
>> Make sure that you turn off $dbh->{AutoCommit} before acquiring a
>> lock using this method.
>>
>> However... You might not *need* to do any such thing -- if, on
>> inserting your rows, you do something like:
>>
>> $dbh->do( qq{
>> INSERT INTO $groupdb
>> (article, poster, refs, subject, thedate, client, messageid)
>> VALUES (
>> (SELECT MAX(article)+1 from $groubdb),
>> ?, ?, ?, ?, ?, ?
>> )
>> }, {}, $poster, $refs, $subj, $date, $client, $messageid );
>>
>> This should, in a single statement, fetch the max article number, add
>> one to it, and use it for inserting a new row.
>>
>> ... Assuming that that syntax is acceptable to Access. It might not
>> be. If not, then use a different CREATE TABLE statement, to force
>> the 'article' field for new rows to come from a sequence:
>>
>> CREATE TABLE IF NOT EXISTS $groubdb (
>> article integer NOT NULL DEFAULT nextval('article_seq'),
>
> The problem there is that the article number is the one from the
> header of the news posting, and since I discovered a problem with the
> NNTPClient module (or at least that's where the problem *seems* to
> come from) when trying to retrieve the body of some messages using the
> messageid, it looks like I am going to have to make sure I use the
> article id to do such retrieving, so it needs to be the one from the
> header.
Well, in *this* case (where you're not trying to retrieve the max
article number from the table), you no might not need locking at all!
> [..]
>>> "[Microsoft][ODBC Microsoft Access Driver]String data, right
>>> truncated on column number 3 (refs) (SQL-01004)(DBD:
>>> st_fetch/SQLFetch (long truncated DBI attribute LongTruncOk not set
>>> and/or LongReadLen too small) err=-1)"
>>>
>>> Yikes! Any idea what that means? Is it something to do with the data
>>> in column 3? It will either contain one or more references like this
>>> "b7al8f.1d4.1@hamster.local.invalid#
>>> ... b3aln0.1l4.1@hamster.local.invalid"
>>> or a space " ".
>>
>> Obviously, the problem is that it contains a string which is longer
>> than $dbh->{LongReadLen}. You'll have to increase
>> $dbh->{LongReadLen} to be at least as long the longest 'ref' field...
>> or, turn on $dbh->{LongTruncOk}, in which case it will throw away
>> part of the data without complaining.
>
> Yuk.. that sounds a bit messy on the part of DBI if you have to start
> worrying about what length the string in a column in a record that you
> are trying to retrieve is. There are numerous circumstances where you
> might need to collect data of varying length and since a text field in
> Access can only hold 255 chars, it is presumably quite common to need
> to use a memo field.
It's not DBI's fault. It's just how databases (including Access) handle
memo fields.
>> A better solution might have been to set up a seperate table for
>> refs, rather than storing it as a memo field.
>>
>> This would have been done as:
>> CREATE TABLE IF NOT EXISTS refs (
>> article integer NOT NULL REFERENCES $groubdb article,
>> ref text(255) NOT NULL,
>> idx integer NOT NULL DEFAULT nextval('ref_id_seq')
>> )
>>
>> Thus, for each article, there'd be an ordered set of references,
>> where each reference is one row in the 'refs' table. (The 'idx'
>> column is there merely for an 'ORDER BY' clause for your SELECTs.)
>>
>> Figuring out things like this (knowing to use a seperate table
>> instead of a memo field) is really a job for a DBA, not truly a
>> perl-specific task.
>
> Yeah, you are probably right. I'm not sure about having one reference
> per row though. An individual message has a reference for each message
> above it in the thread.. that is, if person1 starts the thread,
> person2 replies, person3 replies to person2, then if you as person 4
> comes along and replies to person3, there will be 3 message id's in
> the references header field of your message. That means the number of
> rows would build up rather quickly, although Access has a limit of
> about 65k rows, IIRC.
For a slightly evil way of compressing the data, use a kind of linked
list.
Suppose that you've got the following messages/reference lists:
msga: foo bar baz
msgb: foo bar baz msga
Does you really need to store 'foo bar baz' for msgb? I don't think
so... after all, unless something screwed up when posting, then having
'msgb' refer to 'msga' *implies* that 'msgb' *also* refers to all the
messages that 'msga' refers to.
> Maybe instead, I could have a row per message and a column per
> reference.
Ugh, no. That's evil and wrong.
[snip]
> Hmmm.. or I could just leave the refs as a # separated string in a
> memo field as it is at the moment ;-)
Hmm, that might be best :) Well, simplest anyway.
> So, in the DBI scheme of things,
> if I were to set $dbh->{LongReadLen} to say 2k, would that be quite
> feasible?
If that's longer than the longest 'refs' field, then yes.
Of course, there's an even easier way -- don't fetch the 'refs' field
unless you need it! In the code you posted, you weren't even using it,
and were only examining the 'article' field. If you'd written your
query as "SELECT article from $groupdb", you wouldn't be running into
this trouble.
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
------------------------------
Date: Mon, 31 Mar 2003 04:41:12 GMT
From: chance@austin.rr.com
Subject: Re: help understand dereferencing
Message-Id: <b68hjd$70a$1@localhost.localdomain>
Benjamin Goldberg <goldbb2@earthlink.net> wrote:
> chance@austin.rr.com wrote:
> Might I ask, what kind of application are you building, that needs
> threads to work right?
Oh, nothing right now. Just wondering.
--
I used to think government was a necessary evil.
I'm not so sure about the necessary part anymore.
------------------------------
Date: Mon, 31 Mar 2003 07:37:36 GMT
From: "BSK" <mooncm.lbkejwiAhEgSfSe@dAcEbSaS>
Subject: MSWin32 Active State Perl Question
Message-Id: <4fSha.1071$4P1.86820@newsread2.prod.itd.earthlink.net>
Hello All,
I am trying to put together some Perl code that will timeout after waiting
so many seconds for input from STDIN. That is, after waiting so many
seconds for the user to supply input by way of STDIN, if the user does not
supply anything then the code just continues on executing by assuming some
default values that would have otherwise been provided by the user. I am
trying to do this with Active State Perl (Version 5.008) on an MSWin32
system (WindowsNT4.0sp6a to be exact). The code that I'm trying to use is
as follows:
$terminate = "x";
$SIG{ALRM} = sub{die "timeout\n"};
eval{
alarm(3);
print '$terminate, ', "$::terminate", ', <end of line>', "\n";
chop($terminate = <STDIN>);
print 'eval executed.', "\n";
print '$terminate, ', "$terminate", ', <end of line>', "\n";
alarm(0);
};
print '$@, ', "$@", ', <end of line>', "\n";
if($@){
if($@ =~ /timeout/){
print "\n\n", '*******', "\n";
print "timeout", "\n";
print '*******', "\n";
}else{
alarm(0);
print "\n\n", 'XXXXXXX', "\n";
print 'alarm 0', "\n";
print 'XXXXXXX', "\n";
}
}
Most of the print statements in the above code are there to give me an idea
of the execution thread that is followed. Apart from the print statements,
this code is pretty much straight out of Christiansen & Torkington's "Perl
Cookbook." I don't understand why this isn't working. Can someone look at
this and tell me what the problem is? According to "perldoc -f alarm" it
appears to me that the alarm function is supported by the MSWin32 port of
Perl. Is there something "special" that has to be done since the code is
working with STDIN?
Thanks for your help.
BSK
[For AntiSpam: Email address is spelled
backwards. Remove every other letter
starting with 'a' in 'SaS'.]
------------------------------
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.
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 4790
***************************************
