[24834] in Perl-Users-Digest
Perl-Users Digest, Issue: 6985 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Sep 10 06:07:27 2004
Date: Fri, 10 Sep 2004 03:05:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 10 Sep 2004 Volume: 10 Number: 6985
Today's topics:
Re: $| (undocumented) magic? <pinyaj@rpi.edu>
*.pl(in server) get http header information(from client <end@dream.life>
Re: *.pl(in server) get http header information(from cl <thepoet_nospam@arcor.de>
Re: another try <mark.clements@kcl.ac.uk>
Building Hierarchical Class Tree from custom Scripting <rossjeff@yahoo.com>
Re: Building Hierarchical Class Tree from custom Script <sholden@flexal.cs.usyd.edu.au>
Re: Efficient Data Storage <aaron@deloachcorp.com>
Re: Perl and Inheritance strangeness. <news@ant-roy.co.uk>
Re: Perl and Inheritance strangeness. (Anno Siegel)
Re: Perl inconsistency <bik.mido@tiscalinet.it>
Re: Perl inconsistency <bik.mido@tiscalinet.it>
Re: Perl inconsistency <bik.mido@tiscalinet.it>
Re: Perl XSLT module? <news@ant-roy.co.uk>
Re: Perl XSLT module? <news@ant-roy.co.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 10 Sep 2004 00:57:20 -0400
From: Jeff 'japhy' Pinyan <pinyaj@rpi.edu>
To: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: $| (undocumented) magic?
Message-Id: <Pine.SGI.3.96.1040910005609.488969A-100000@vcmr-64.server.rpi.edu>
[posted & mailed]
On Thu, 9 Sep 2004, Michele Dondi wrote:
>While trying my hand at a new japh[*], I've found that $| can only
>hold either 0 or 1 (I guess):
>
> # perl -le 'print $|=10'
>
>Though I can't seem to find any mention of this fact in 'perldoc
>perlvar'. BTW: is this behaviour supposed to be supported in the
>future too? And is it always been?
The C code implementing $| basically says "if the value assigned to $| is
true, have $| return 1, otherwise have it return 0". This leads to the
coolness that is
print +("this", "that")[--$|] for 1 .. 10;
--
Jeff "japhy" Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
Senior Dean, Fall 2004 % have long ago been overpaid?
RPI Corporation Secretary %
http://japhy.perlmonk.org/ % -- Meister Eckhart
------------------------------
Date: Fri, 10 Sep 2004 16:22:03 +0800
From: Alont <end@dream.life>
Subject: *.pl(in server) get http header information(from client) failed
Message-Id: <414262a5.3225140@130.133.1.4>
the header Client sent:
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; (R1
1.3); .NET CLR 1.1.4322)
Host: localhost
Content-Length: 52
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: ASPSESSIONIDQGGGGPOC=PPMDJLKAPKGILCKKAFDHCFOM
abc=xxxx&ccc=xxxx
I want get "abc=xxxx&ccc=xxxx" and "Cookie:",the code I wrote:
require HTTP::Headers;
$h = new HTTP::Headers;
$Cookie = $h->header('Cookie');
print $Cookie;
print "I hate you";
print "I love you";
but the result of "print $Cookie;" is empty, where's my fault?
and how to get "abc=xxxx&ccc=xxxx"-------it isn't a pair of value
--
Your fault as a Government is My failure as a citizen
------------------------------
Date: Fri, 10 Sep 2004 11:29:18 +0200
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: *.pl(in server) get http header information(from client) failed
Message-Id: <414173ef$0$28464$9b4e6d93@newsread4.arcor-online.net>
Alont wrote:
> the header Client sent:
> Accept-Encoding: gzip, deflate
> User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; (R1
> 1.3); .NET CLR 1.1.4322)
> Host: localhost
> Content-Length: 52
> Connection: Keep-Alive
> Cache-Control: no-cache
> Cookie: ASPSESSIONIDQGGGGPOC=PPMDJLKAPKGILCKKAFDHCFOM
> abc=xxxx&ccc=xxxx
>
> I want get "abc=xxxx&ccc=xxxx" and "Cookie:",the code I wrote:
> require HTTP::Headers;
> $h = new HTTP::Headers;
> $Cookie = $h->header('Cookie');
[...]
Hi,
what your code does is to create an (empty) HTTP::Headers
object and then try to fetch the (nonexistant) "Cookie"
entry. HTTP::Headers is for creating headers, not for
parsing HTTP requests.
If you are running your perl code as a cgi script, you
should have a look at the CGI module, which gives you
access to POST and GET parameters and header values of
the current request.
Your server-side code would then look like:
---------------------------------
#!/path/to/perl
use strict;
use warnings;
use CGI;
use CGI::Carp; # verbose error output to browser
my $query = new CGI;
my $abc = $query->param('abc') || 'unset';
my $ccc = $query->param('ccc') || 'unset';
my $cookie_value = $query->cookie('ASPSESSIONIDQGGGGPOC') || 'unset';
__END__
-----------------------------------
You can also iterate through all cookies sent back by the client
by using the fetch()-function of CGI::Cookie like
------------------------snip---------------------------
use CGI::Cookie;
my %all_cookies = CGI::Cookie->fetch();
foreach my $cookiename ( keys %all_cookies ) {
my $cookievalue = $all_cookies{$cookiename};
# do something with $cookiename and $cookievalue
}
------------------------snip----------------------------
See
perldoc CGI
perldoc CGI::Cookie
for details.
HTH
-Chris
------------------------------
Date: Fri, 10 Sep 2004 09:48:22 +0200
From: Mark Clements <mark.clements@kcl.ac.uk>
Subject: Re: another try
Message-Id: <41415c47$1@news.kcl.ac.uk>
Darius wrote:
>
> I have many lines in a bad xml file that are like the long one below:
> <word_word1 string="start" date="2004-09-02 07:33:22" id="2033878"
> word_id="2000589" get_id="8647" ><word name="MOVIE"><film
> title="S"things Gotta Give" the_number="531780"
> /></word></word_word1><film title="S'"e Gotta Give"
> the_number="531780" />
Is this merely a learning exercise or do you in fact have a corrupted
xml file that you are trying to fix?
If the former then you need to read the other postings: there are
many(!) xml tools available to make your life easier. Messing around
with xml is not a good way of teaching yourself about regular expressions.
If the latter, is the correct film title always "Somethings gotta give"?
If the film title varies then how are you expecting to tell in each case
with what text the "e or whatever needs to be replaced? Have you
considered restoring from backup?
A more specific subject may help with future postings.
Mark
------------------------------
Date: Thu, 09 Sep 2004 21:05:37 -0700
From: Jeff Ross <rossjeff@yahoo.com>
Subject: Building Hierarchical Class Tree from custom Scripting Language
Message-Id: <9k82k0ld2fo56v0aeskb1l58ki0bfm9e88@4ax.com>
At work I'm using a custom game scripting language, and it's gotten to
be quite bloated. It's fairly similar to Java in that it supports a
lot of class extension.
What I've done so far with Perl is traverse the game tree, found all
the script files, parsed the necessary lines, and now I have an array
that contains hundreds of elements similar to this:
"Class WeaponBaseClass ExtendsFrom GameObject"
"Class StreetLamp ExtendsFrom LightCastera"
"Class AssaultRifle ExtendsFrom WeaponBaseClass"
"Class MoneyClip ExtendsFrom InventoryManager"
"Class GameObject ExtendsFrom BaseGOBJ"
"Class Hud ExtendsFrom RenderMan"
and so on...
Unfortunately, these aren't in any real order..
Since my intention is to thoroughly understand this spaghetti code
system, or at the very least be able to step through the hierarchy
more easily, I would like to find a solution that clearly displays the
parent/child relationships.
I've staged the data so I can easily prepare it for whatever tool or
method I wind up using. Of course it would be ideal to build a UML or
other hyperlinkable visual system.
Any suggestions?
Thanks in advance
-------------------------------
Jeff Ross
rossjeff@yahoo.com
------------------------------
Date: 10 Sep 2004 04:37:55 GMT
From: Sam Holden <sholden@flexal.cs.usyd.edu.au>
Subject: Re: Building Hierarchical Class Tree from custom Scripting Language
Message-Id: <slrnck2bt3.78b.sholden@flexal.cs.usyd.edu.au>
On Thu, 09 Sep 2004 21:05:37 -0700, Jeff Ross <rossjeff@yahoo.com> wrote:
> At work I'm using a custom game scripting language, and it's gotten to
> be quite bloated. It's fairly similar to Java in that it supports a
> lot of class extension.
>
> What I've done so far with Perl is traverse the game tree, found all
> the script files, parsed the necessary lines, and now I have an array
> that contains hundreds of elements similar to this:
>
> "Class WeaponBaseClass ExtendsFrom GameObject"
> "Class StreetLamp ExtendsFrom LightCastera"
> "Class AssaultRifle ExtendsFrom WeaponBaseClass"
> "Class MoneyClip ExtendsFrom InventoryManager"
> "Class GameObject ExtendsFrom BaseGOBJ"
> "Class Hud ExtendsFrom RenderMan"
>
> and so on...
>
> Unfortunately, these aren't in any real order..
>
> Since my intention is to thoroughly understand this spaghetti code
> system, or at the very least be able to step through the hierarchy
> more easily, I would like to find a solution that clearly displays the
> parent/child relationships.
>
> I've staged the data so I can easily prepare it for whatever tool or
> method I wind up using. Of course it would be ideal to build a UML or
> other hyperlinkable visual system.
>
> Any suggestions?
GraphViz makes reasonable "hierarchical" graph layouts which are a good
fit for inheritance heirarchies (strangely enough :). There's a perl
module on cpan "GraphViz" for ease of use from perl. You would simply
turn each of those string into an edge in the graph and display it:
@data = ("Class WeaponBaseClass ExtendsFrom GameObject",
"Class StreetLamp ExtendsFrom LightCastera",
"Class AssaultRifle ExtendsFrom WeaponBaseClass",
"Class MoneyClip ExtendsFrom InventoryManager",
"Class GameObject ExtendsFrom BaseGOBJ",
"Class Hud ExtendsFrom RenderMan",
);
use GraphViz;
my $g = GraphViz->new();
for (@data) {
if (/^Class (\S+) ExtendsFrom (\S+)$/) {
$g->add_edge($2, $1);
} else {
warn "Unprocessed item: $_\n";
}
}
print $g->as_ps();
And pipe the output to a postscript viewer or to a file. Other output
formats are supported if you don't do postscript.
If there's a viewer you like for some other language, you could also
just munge the text into something syntatically correct (but
meaningless) for that language - with the appropriate names - and use
that viewer.
--
Sam Holden
------------------------------
Date: Fri, 10 Sep 2004 00:02:14 -0500
From: "Aaron DeLoach" <aaron@deloachcorp.com>
Subject: Re: Efficient Data Storage
Message-Id: <x4ydnSr0LMPIqNzcRVn-vw@eatel.net>
[...]
>> This project has grown from 1,000 or so users to over 50,000 users. The
>> project has been an overall success, so it's time to spend a little on
>> the investment.
>
> It makes a huge difference whether those 50,000 users access one cgi page
> per week, on average, or one cgi page per minute.
On average, there are approximately 15,000 'hits' each day. These 'hits' are
through 2 different cgi programs, using several different sub-programs each.
>> Currently, we are getting our own servers (in lieu of ISP
>> shared servers) setup with mod_perl and are revisiting a lot of the code
>> to make things more efficient. Hopefully, in a month or so we can make
>> the switch.
>
> Do you have specific performance complaints? One should keep general
> efficiency in mind, but it is better focus on specific problems if they
> exist.
We've noticed some performance issues as the user base grows, and wish to
regain some by moving from the ISP to our own server(s) where we can benefit
from unavailable modules/configurations (mod_perl, etc.). Our ISP is working
with us to smooth the transition and share knowledge. They're a local
company, and we were one of their first customers.
>> At present, user records are stored each in a single file using the
>> Data::Dumper module and the whole project works through the %user = eval
>> <FILE> method.
>
> How big are these files?
Average 4kb. However, we plan to store some additional information in them
to eliminate calls to slower methods/modules. This will make them average
10kb or so.
> Hopefully there are a few subroutines which are invoked throughout the
> program to cause the files to be read or written. If it is IO code, not
> subroutines, which are throughout the program, than any changes will be
> difficult. Then the first thing I would do is leave the actual physical
> storage the same, but consildate all the IO into a few subroutines, so
> that
> you can just swap out subroutines to test different methods.
The entire record (file) is eval(ed) into a href in the beginning of the
program(s). The user actions are performed upon the href until the end of
the session. The href is then written back to the file (replacing the
original contents). Writing is achieved through the Data:Dumper module. Uri
has suggested using different methods which we're looking into.
>> I don't know how much efficiency would be gained by using an alternate
>> storage method. Perhaps MySQL?
>
> My gut feeling is that it would not lead to large performance
> improvements if all you do is use MySQL instead of the file system
> as a bit bucket to store your Data::Dumper strings. Especially if
> your server has a lot of memory and aggresively caches the FS.
Your gut feeling is correct according to our initial research into the db
server/methods. Increasing the FS cache would compensate for any gains from
using a db scenario. Memory is not going to be an issue. It seems that the
mod_perl requirements are going to govern that.
>> None of us are very familiar with
>> databases, although it doesn't seem very hard. We are looking into
>> storing the records as binary files which seems promising, but would like
>> some input on the data storage/retrieval methods available before we do
>> anything.
>
> By binary files, do you mean using Storable rather than Data::Dumper?
We were educated on the Storable module by Uri. Until then, there was just a
knowledge of the process.
> I would expect that to make more of a performance difference than the
> MySQL vs file system.
I'm glad to hear that. It's the way we were hoping to go.
> I'd spend some time investigating where the time is going now.
> Make a script that does something like:
>
> use strict;
> use blahblah;
> ## all the other preliminaries that your real programs have to go through.
>
> exit if $ARGV[0] == 1;
>
> my $data = load_file_for_user($ARGV[1]);
> exit if $ARGV[0] == 2;
>
> my $user_ref = eval $data;
> exit if $ARGV[0] == 3;
>
> Do_whatever_your_most_common_task_is($user_ref);
> exit if $ARGV[0] ==4;
> ### etc.
>
>
> then write another program:
>
> my $start=time;
> foreach my $level (1..4) {
> foreach (1..1000) {
> my $u = randomly_chosen_user();
> system "./first_program.pl $level $u" and die $!;
> };
> print "Level $level, ", $start-time, "\n";
> };
>
> if level 1 time is almost as big as level 4 time, then the overhead
> of compilation and startup is your biggest problem. etc.
Hmmm... I will update you on the results...
Thanks!
------------------------------
Date: Fri, 10 Sep 2004 09:03:04 +0100
From: Anthony Roy <news@ant-roy.co.uk>
Subject: Re: Perl and Inheritance strangeness.
Message-Id: <chrn3n$d4p$1@south.jnrs.ja.net>
Tad McClellan wrote:
> antroy <news@ant-roy.co.uk> wrote:
>
>>Tad McClellan wrote:
>>
>>>Usenet is not email!
>>
>>Thanks for the constructive advice.
>
>
>
> You're welcome.
>
> Can you identify how it is constructive to know the difference?
It's called irony. I think it is a rare thing in Texas.
I won't be continuing with this fork of the thread - it's exactly this
sort of irrelevant banter that annoys me about usenet. Someone asks a
technical question in line with the charter, and someone else responds
with "this is usenet not email", or "use google" or other arbitrary or
useless remark.
Why not use the forums for the purpose they are intended, rather than a
place to simply bitch for the sake of it? I'm sure there are plenty of
forums for that such as alt.pedants.misc or similar.
And before you bother to reply, I am fully aware of the irony (that word
again - look it up) of the fact I'm adding to the very rubbish I'm
complaining about but restate that I won't be posting to this fork of
the thread again.
I'm just glad that there *are* people who are keen to help (thanks Anno)
rather than just waste time and bandwidth with irrelevant rubbish.
--
Anthony Roy.
------------------------------
Date: 10 Sep 2004 08:34:00 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Perl and Inheritance strangeness.
Message-Id: <chroto$alg$1@mamenchi.zrz.TU-Berlin.DE>
Anthony Roy <news@ant-roy.co.uk> wrote in comp.lang.perl.misc:
> Tad McClellan wrote:
> > antroy <news@ant-roy.co.uk> wrote:
> >
> >>Tad McClellan wrote:
> >>
> >>>Usenet is not email!
> >>
> >>Thanks for the constructive advice.
> >
> >
> >
> > You're welcome.
> >
> > Can you identify how it is constructive to know the difference?
>
> It's called irony. I think it is a rare thing in Texas.
>
> I won't be continuing with this fork of the thread - it's exactly this
> sort of irrelevant banter that annoys me about usenet.
Then find yourself a forum that complies with your demands and get
the fuck out of Usenet. What you get here is raw advice, if you asked
for it or not. If you want it with an ego-protective wrapper, you
got to pay.
Anno
------------------------------
Date: Fri, 10 Sep 2004 09:15:19 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl inconsistency
Message-Id: <73j2k0tav5q5rt82c5rfh3jir36pmu10iu@4ax.com>
On Thu, 09 Sep 2004 18:16:27 GMT, Uri Guttman <uri@stemsystems.com>
wrote:
>perl6 fix all of that. it will still be perl and still DWIM in many
I totally agree! That is my impression too...
>place that will make life easier for perl hackers and annoy others who
>don't get it.
Well, it is my understantment (probably very limited in many different
ways, I must admit!) that Perl6's dwimmeries will be to a large extent
a consequence of how many "standard" objects evaluate in certain
contexts[*] rather than ad-hoc magic. Which is fine, IMHO.
Don't misunderstand me: there are some things I do not like about
Perl6, as of what is known about it, just like everyone else. But on
the complex these are overwhelmed by the ones I like, and I'm eager to
see the beast alive!!
In this sense I slightly regret having written that cmt at all, for I
may have conveyed a wrong impression to other people, although less
knowledgeable than you are, unfortunately, so that they may be
misleaded by my words...
[*] There was some discussion about this issue with split() as a topic
example. Similarly, on the p6l list a poster complained about the fact
that reverse() would break laziness on ranges (thus resulting in
inefficient code), to which Larry replied that this is not necessarily
the case provided that the range object is smart enough to handle it,
and there is no reason why it shouldn't be!
But then *you* probably already know this, and have a deeper
understanding of it than I have...
Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"
------------------------------
Date: Fri, 10 Sep 2004 09:15:20 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl inconsistency
Message-Id: <f5j2k0ph7d2g11tmin3u4jpkdeuuhpj2eb@4ax.com>
On Thu, 9 Sep 2004 06:51:08 -0700, "187"
<bigal187@invalid.rx.eastcoasttfc.com> wrote:
>Michele Dondi wrote:
>> BTW: this is one of the reasons why Perl6 is being designed to be more
>> consistent (and IMHO *slightly* less magic).
^^^^ ^^^^^^^^^^
^^^^ ^^^^^^^^^^
>Hmm... isn't that going to defeat some (if not a great deal) of the
>uefulness and greatness of Perl? I, like many other Perl lovers, love
>Perl *becuase* of this usefulness and "magic" :)
Please, take my words with a grain of salt, especially taking into
account the two expressions above, that I (thought to have) stressed
from the start...
First it is only a personal impression, and secondarily I said only
"*slightly* less magic": OTOH it will be *much* more consistent,
powerful and rich of features in so many different ways that is almost
difficult to think of some them! So no: it won't be any less useful
than Perl5 is. And it can only be greater... of course it will take
some time to get accustomed with it. But then you'll still love it,
believe me!
Michele
------------------------------
Date: Fri, 10 Sep 2004 09:15:21 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Perl inconsistency
Message-Id: <lnj2k0t7e7con13vnagstodurvk3aalt3e@4ax.com>
On Thu, 09 Sep 2004 19:42:11 +0200, Mike Mimic <ppagee@yahoo.com>
wrote:
>> BTW: this is one of the reasons why Perl6 is being designed to be more
>> consistent (and IMHO *slightly* less magic).
>
>It is nice to know that. Then I am waiting with impatience for Perl 6,
>because I like that things are consistent (so that there are no special
>cases which are that way just because they are special). If things
>are not consistent you have to remember all special cases and this is
>like learning irregular verbs. :-)
Don't misunderstand me either, just like the other poster did (albeit
"on the other side")! Don't expect Perl6 to be any "simpler" (for some
meaning of "simple" you seem to have in mind) than Perl5 is. Just like
Perl5 you will be allowed to use in a simple minded way, but to get
the best of it you will still have to "learn many irregular verbs",
only that they won't be really irregular (or at least much less so!)
Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"
------------------------------
Date: Fri, 10 Sep 2004 09:03:53 +0100
From: Anthony Roy <news@ant-roy.co.uk>
Subject: Re: Perl XSLT module?
Message-Id: <chrn58$d4p$2@south.jnrs.ja.net>
Eric Bohlman wrote:
...
> Look into XML::LibXSLT and XML::Sablotron (there's also XML::XSLT, but it's
> incomplete and hasn't been touched in a long time).
Thanks,
--
Anthony Roy
------------------------------
Date: Fri, 10 Sep 2004 09:25:29 +0100
From: Anthony Roy <news@ant-roy.co.uk>
Subject: Re: Perl XSLT module?
Message-Id: <chrodq$dhu$1@south.jnrs.ja.net>
Eric Bohlman wrote:
> Look into XML::LibXSLT and XML::Sablotron (there's also XML::XSLT, but it's
> incomplete and hasn't been touched in a long time).
I have had a look at these, and it appears that they are both wrappers
around C programs. Are there any native perl XSLT transformers available
in a better state than XML::XSLT which doesn't have enough functionality
for my requirements?
The trouble is that the server I need to install the modules on (i.e.
the location of my cgi script) is controlled by someone else, and
getting them to install the C programs required will be nigh on impossible.
Thanks,
--
Anthony Roy.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 6985
***************************************
