[26418] in Perl-Users-Digest
Perl-Users Digest, Issue: 8588 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Oct 30 21:05:47 2005
Date: Sun, 30 Oct 2005 18:05:03 -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 Sun, 30 Oct 2005 Volume: 10 Number: 8588
Today's topics:
[ANNOUNCE] Thread::Resource::RWLock 2.01 <dean.arnold@sbcglobal.net>
FAQ 1.13 Is it a Perl program or a Perl script? <comdog@pair.com>
FAQ 9.13 How do I edit my .htpasswd and .htgroup files <comdog@pair.com>
Re: Performance & Perl robic0@yahoo.com
perl script to pass data to another perl script? <news@cutmeukjay.com>
Re: perl script to pass data to another perl script? xhoster@gmail.com
Re: RTF and UTF-8 files in Perl <matthew.garrish@sympatico.ca>
The Evil American Corprotocracy robic0@yahoo.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 28 Oct 2005 17:46:58 GMT
From: Dean Arnold <dean.arnold@sbcglobal.net>
Subject: [ANNOUNCE] Thread::Resource::RWLock 2.01
Message-Id: <Ip6AKD.103L@zorch.sf-bay.org>
The initial CPAN release of Thread::Resource::RWLock
is now available. Thread::Resource::RWLock provides a read/write
resource locking capability for Perl ithreads, including the
ability to upgrade readlocks to writelocks, or downgrade
writelocks to readlocks, and supports nonblocking and
timed lock requests.
NOTE that this module provides a superset of the capability
of Thread::RWLock, but is intended for ithreads, and uses
different method names and locking algorithms.
The uploaded file
Thread-Resource-RWLock-2.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DA/DARNOLD/Thread-Resource-RWLock-2.01.tar.gz
size: 9456 bytes
md5: 880b4c0c1b1267b24e88714d4000d143
No action is required on your part
Request entered by: DARNOLD (Dean Arnold)
Request entered on: Fri, 28 Oct 2005 17:30:39 GMT
Request completed: Fri, 28 Oct 2005 17:31:36 GMT
Thanks,
-- paused, v460
Regards,
Dean Arnold
Presicient Corp.
------------------------------
Date: Sun, 30 Oct 2005 23:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@pair.com>
Subject: FAQ 1.13 Is it a Perl program or a Perl script?
Message-Id: <dk3jf5$buh$1@reader2.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
1.13: Is it a Perl program or a Perl script?
Larry doesn't really care. He says (half in jest) that "a script is what
you give the actors. A program is what you give the audience."
Originally, a script was a canned sequence of normally interactive
commands--that is, a chat script. Something like a UUCP or PPP chat
script or an expect script fits the bill nicely, as do configuration
scripts run by a program at its start up, such .cshrc or .ircrc, for
example. Chat scripts were just drivers for existing programs, not
stand-alone programs in their own right.
A computer scientist will correctly explain that all programs are
interpreted and that the only question is at what level. But if you ask
this question of someone who isn't a computer scientist, they might tell
you that a *program* has been compiled to physical machine code once and
can then be run multiple times, whereas a *script* must be translated by
a program each time it's used.
Perl programs are (usually) neither strictly compiled nor strictly
interpreted. They can be compiled to a byte-code form (something of a
Perl virtual machine) or to completely different languages, like C or
assembly language. You can't tell just by looking at it whether the
source is destined for a pure interpreter, a parse-tree interpreter, a
byte-code interpreter, or a native-code compiler, so it's hard to give a
definitive answer here.
Now that "script" and "scripting" are terms that have been seized by
unscrupulous or unknowing marketeers for their own nefarious purposes,
they have begun to take on strange and often pejorative meanings, like
"non serious" or "not real programming". Consequently, some Perl
programmers prefer to avoid them altogether.
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: Sun, 30 Oct 2005 17:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@pair.com>
Subject: FAQ 9.13 How do I edit my .htpasswd and .htgroup files with Perl?
Message-Id: <dk2uc5$o0p$1@reader2.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
9.13: How do I edit my .htpasswd and .htgroup files with Perl?
The HTTPD::UserAdmin and HTTPD::GroupAdmin modules provide a consistent
OO interface to these files, regardless of how they're stored. Databases
may be text, dbm, Berkeley DB or any database with a DBI compatible
driver. HTTPD::UserAdmin supports files used by the "Basic" and "Digest"
authentication schemes. Here's an example:
use HTTPD::UserAdmin ();
HTTPD::UserAdmin
->new(DB => "/foo/.htpasswd")
->add($username => $password);
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: Sun, 30 Oct 2005 17:45:45 -0800
From: robic0@yahoo.com
Subject: Re: Performance & Perl
Message-Id: <5blam1t3f74nvn0p86077lscmqdtmp5349@4ax.com>
On Sun, 30 Oct 2005 08:23:53 +0100, "Tassilo v. Parseval"
<tassilo.von.parseval@rwth-aachen.de> wrote:
>Also sprach robic0@yahoo.com:
>
>> Or C?
>>
>> (Disclaimer: I have not delved into the Perl source)
>>
>> How close does Perl follow C as far as primatives?
>
>Sometimes closely, but more often it doesn't follow C at all.
>
>Some operators are implemented in terms of their C counterparts (most
>notably all the bitwise operators).
>
>The biggest differences are probably with arrays (that resize
>dynamically) and strings. Perl strings are implemented on top of C
>char-pointers and yet are infinitely smarter than C strings (e.g. they
>transparently morph from one encoding into the other, ideally with the
>programmer not even noticing it).
>
>And there are of course hash-tables, something that C doesn't have at
>all.
>
>> Can I rely on Perl language constructs to follow C when
>> writing performance code?
>
>Some generic wisdom can probably be applied to writing both C and Perl
>code. One such rule is to avoid the copying around of data although it's
>sometimes not obvious what Perl code will result in a copy.
>
>One difference for example is how C and Perl handle structures. One
>common consideration with C is the order of struct-members that has an
>impact both on memory consumption and performance due to memory
>alignment issues:
>
> struct A {
> char a;
> int32_t b;
> char c[3];
> }; /* 12 bytes on machines that align on 4-byte boundaries */
>
> struct B {
> char a;
> char c[3];
> int32_t b;
> }; /* only 8 bytes */
>
>In Perl, hashes are ordinarily used for modelling structs. They have
>very different characteristics. One is that access to the members is
>resolved at runtime whereas the members of a C structure have a fixed
>memory offset from the base address which the compiler knows about.
>
>On the other hand, certain C constructs might end up being faster in
>Perl. Perl's index() is likely to be faster than C's strstr() as it uses
>Boyer-Moore on the inside and attaches these information to the
>variable.
>
>Likewise length() versus strlen(): Perl's length() happens in constant
>time as the length of each string is stored in the underlying
>data-structure. C on the other hand has to loop over each character to
>find the terminating '\0'.
>
>Another thing to keep in mind is that function calls in Perl are slow.
>In C they are also slower than inlined code, but with Perl the penalty
>is by an order of a few magnitudes more severe. It's even worse with
>method calls as the resolution of every method happens at runtime
>(although perl does cache the information). In C++ method dispatch can
>often by figured out at compile-time unless it's dynamic dispatch. Perl
>only has dynamic dispatch.
>
>I believe the best way to improve the performance of Perl programs is by
>using the Benchmark module to find out which of the conceivable versions
>performs better.
>
>> In a runtime race will a Perl for loop time exactly the same as a
>> C for loop? When the race begins, if not, why not?
>
>The C loop wins. But then the Perl for-loop is more than just a loop:
>It's a generic iterator construct that iterates over any list-alike
>thing.
>
>> Any divergence in stack processing Perl to C?
>
>Perl only uses the stack for passing arguments to and from functions and
>methods. Unlike in C, it has a variadic size. That's why Perl functions
>don't need a prototype. And if they have a prototype, it's for an
>entirely different purpose.
>
>> Is there such a thing as a Perl "temporary" on the stack?
>
>Perl knows about temporaries but they are not created on the stack but
>instead on a separate thing called a scratchpad of which each block gets
>its own. These temporaries aren't blindly destroyed when the block is
>left. Instead, their reference-count is decremented. In the below
>$temporary isn't freed because set_tmp() and get_tmp() still reference
>it in their bodies. That means Perl has real closures:
>
> {
> my $temporary;
> sub set_tmp { $temporary = shift; }
> sub get_tmp { return $temporary; }
> }
> set_tmp 42;
> print get_tmp;
>
>> Why would I need to care about any of this on a "higher level"
>> language, or is Perl a higher level language?
>
>Perl is a higher level language because you never have to worry about
>any of those menial tasks that a C programmer constantly needs to be
>aware of. That comes at a price so a Perl program can easily be 50 times
>slower than a well-written C equivalent.
>
>But there are ways to couple the convenience of Perl with the
>performance of C. Many modules on the CPAN were written in C or C++ (or
>rather in a dialect called XS which facilitates the passing of data from
>Perl to C and vice versa). There is also Inline::C.
>
I use XML::Xerces which wrapps apache xerces-c_2_3_0.dll.
The writer used a XSbot (I think) to auto generate the perl
dll and package. Like you say its just for passing parameters.
Xerces is very powerfull, however, I had to go to the C prototype
site and pick out functionality as the Perl interface writer
just auto-generated Perl wrappers. I had to write custom callbacks,
impose the performance SAX parser I use. Currently, its being used
to validate schema, 100% acurately. I will be using it to write
out xml soon, it has to be picked out. The Apache Perl interface
writer does not want to provide this, but it can be done through
trial and error given the C proto's. Its all there, maybe a thousand
functions (not sure). The schema validation I do though is w3c 2
compliant, 100% accurate. Xerces has to be manually installed,
which is kind of a pain, there is almost NO documentation (as its
just a auto-generated blind wrapper). Thats too bad as I personally
think XML Perl interface should be alot more robust and its actually
extremely lacking in both functionality and ease of use. Ok, its
basically schizoid because of the mainstream XML C community (w3c)
are in this nodal/sax dicotomy dissary. Because of anonymouse
(unamed) arrays in Perl it has a hard time reading - writing
XML. Workarounds are there, but its not for the "faint of heart".
Oh well, big thanks Tassilo for the info. I wish I had more time
to get deeper into this.
>Toying around with any of these is an excellent and fun way to learn
>about the inner workings of Perl because you'll inevitably learn how the
>Perl stack works, how Perl's reference-counting is used to do
>garbage-collection, how Perl's primitive data-types work and so on and
>so forth.
>
>Tassilo
------------------------------
Date: Sun, 30 Oct 2005 19:32:03 -0000
From: "PhEaSaNt PLuCKeR" <news@cutmeukjay.com>
Subject: perl script to pass data to another perl script?
Message-Id: <dk373j$295$1@news6.svr.pol.co.uk>
Keywords: perl
Hello,
Can anyone advise me how to pass data from one script to another script?
The first script monitors data, and I want to pass parameters to that
running script.
A simple solution would be nice, but will I need to look into DDE, or
Threads?
Hope someone has done this :-)
--
James (Ukjay)
------------------------------
Date: 30 Oct 2005 19:48:51 GMT
From: xhoster@gmail.com
Subject: Re: perl script to pass data to another perl script?
Message-Id: <20051030144851.792$e7@newsreader.com>
"PhEaSaNt PLuCKeR" <news@cutmeukjay.com> wrote:
> Hello,
>
> Can anyone advise me how to pass data from one script to another script?
There are lots of ways. The best is often not to do it in the first place.
> The first script monitors data, and I want to pass parameters to that
> running script.
Since the first script is already monitoring data, why not have it monitor
whatever data it is you want passed into it in addition to monitoring
whatever data it is currently monitoring?
> A simple solution would be nice, but will I need to look into DDE, or
> Threads?
I don't know what DDE is.
>
> Hope someone has done this :-)
All the time. The devil is in the details.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Sun, 30 Oct 2005 12:24:26 -0500
From: "Matt Garrish" <matthew.garrish@sympatico.ca>
Subject: Re: RTF and UTF-8 files in Perl
Message-Id: <dl79f.1144$LF3.57003@news20.bellglobal.com>
"V S Rawat" <VSRawat@Invalid.none> wrote in message
news:xn0e93zst5r39c000@xananews...
> 1. How do I open a RTF file as input in Perl and read formatted
> ASCII text from it?
>
You don't. There's no such thing as formatted ASCII text. You could look
into a module such as RTF::Tokenizer if you want to parse apart the RTF file
and extract the text from it. If you want to know what formatting has been
applied you'll also need to check the formatting commands as you go.
> 2. How do I open a UTF-8 (Unicode) file as output in Perl and
> write Unicode text to it?
>
Assuming your data is not already utf8:
[untested]
use Encode;
open(my $out, '>:utf8', 'somefile.dat') or die "Could not open file: $!";
print $out Encode::encode('utf8', $mydata);
close($out) or die "Could not close file: $!";
Otherwise you could skip the encoding step.
Matt
------------------------------
Date: Sun, 30 Oct 2005 17:53:09 -0800
From: robic0@yahoo.com
Subject: The Evil American Corprotocracy
Message-Id: <trtam1hlo9gp4t1vg7kv8jpcgpuc2sqj58@4ax.com>
Been at this for 25 years (since writing assemblers on
zilog/intel's .. z80a/8080/8086, all motorola's, wrote
dynamic link libraries on Amiga 1000's (Lattice c),
.., and up the food chain, basic, c/c++ compilers (all of them),
used emacs editor in 1985, have every issue of Byte magazine (4 sale),
dos extenders, tsr's, device drivers (dos/NT <- people aren't aware
that win32 is just a wrapper into the kernel), gui (lots, with
owner drawn controls), sql, mdac (recordsets, lots, et all),
com (interface), com+ (active X-same,, client side, but I don't
allow it on my machine), jscript (not my fav), here after it
doesen't matter)). I'm probably getting tired of it all.
There are some things through the years that captured my interest,
this thread topic being one. Reason being is that through the
years there are some things that never change, code performance
seems to follow the inherant capabilities of the cpu (assembly).
I'm so old I know and studied how micro-code works.
I have a degree in Mechanical Engineering (82) and discovered
bbs (Mustang software) then Usenet shortly after. WWW was something
that came later. I'll never forget my 2400 Ventel modem. So much
money was spent in those days for so little by todays comparison.
I build my own machines, have since those days. I've always kept
active programming, hours and hours on end. To date estimated at
something over 15 million lines of code. I've been a paid
proffesional programmer (mostly I designed and programmed) since
1983. I think Pascal was my first job on a Univac (tty) working
as a ME. In 1981 I had an electronics elective at my college,
taught by (Phd) the main designer of .... the IBM pc. In 82 it came
out. We were 30 miles from IBM dev center. It was pcdos 1 (hahaha).
All my instructors were Phd's who in the case of my thermo classes
typcially an hour was he starts writing entropy formulea at the top
left of one blackboard, wrapps to the next and the next. That was
a typical day in the thermo classes. I needed an escape. I started
doing programs on my hp30c calculator. That I think brought me
to this point in my life. I believe I have contributed. I believe
that our technical society is built on the shoulders of giants
who stood on other giants shoulders (omg stop this now). Well..
whatever. I'm optimistic about the future.. If corporations,
who think of programmers as a "resource" remember that they are human
beings then it will be ok. Now its offshore and outsourcing started
in the dot com days because they do not have enough so called
technical experts. Cat left the bag, outsourcing is not just for
technical experts anymore. In the future, I'm sure you will place
your McDonalds order to India at the window. Jeez......
Time to "unionize" and get back America.
Let me give you a simple example of how a "baseline" works:
The electric power generating plants burn just enough oil to
produce a baseline of power based on projected need at a certain
seasonal point. This is the cheapest they can produce energy
as it is guaranteed to be consumed using heating oil, the
lowest of the refinery processes. They use it to boil water
that drives their steam turbines. When summer comes, the
energy demand spikes, they have to use added generating power
from machinery such as a jet engine. This doubles their cost
to produce the same KWH as the other fuel. However, it
provides the same electricity but at a higher production
cost. Your not charged that cost unless you go over your
linear usage beyond the baseline, at which you are charged
the doubled price "over" your baseline based on averages.
If you flip the model upside down, whats going on today is
your American wage is "compared" with the "lowest" wage they
can get, and that is the baseline instead of the spike.
The effect is to cause you, an American to take a much
"lower" wage based on the spike, even though you are the
baseline. Remember its flipped, so you the "baseline"
should be at a much higher wage, but you are being
brainwashed to think the spike is the norm.
You would think then that corporations "will" replace
you job with the spike, the offshore workers at 1/10th
the price. In reality, if the 90% baseline Americans
technical "resources" were to decline the offer of
less pay, the corporations in America would be forced
to run their development on the "spike" layer,
representing 10% of development. So they would need
10 years to develope a product that would normally
take 1 year. To be more precise, if all American
developers declined to work for 4 - 1/2 weeks, it would
push back the product release for 1 year. If
off shore developers proportionally declined it would
push back the release for 3 weeks.
Actually it should the the power company model, where
the "spike" is more expensive. Instead its the reverse.
The "spike" is cheaper, and presto chango, the flim-flam
man translates that into "the baseline has to be 1/2
the spike". But in America, you can't pay technical
folks 2 dollars an hour, so the corporate line is
"These experts are making 1/3 rd of what you are, so
you should make at least half" In reality, American
techies are the "baseline" of corprate develpment.
The thought that you can be replaced looms large.
Did you ever think: OK, replace me! When you demand
I come back, be aware I want my lost wages and
without loss of benefits nor pay.
Gentlemen, the demand for technical development
will only "increase". The fact is, you are
brainwashed to think your job is in jepordy
by the "spike" when in reality, you, the
American techinical expert are the "baseline"
for corporate and worldwide development.
The only recourse is to unionize. Engineers do it,
all technical fields do it. Time to act. Right
now the corporate world has the idiom of a
seasonal "hire up" to deliver products, then
"fire down" after. When you see an add for
a "permanent" position specialist to write
a device driver for their product, what does
that mean to you? A device driver could take
at most 3 months to develop. And a company
wants to offer you a "permanent" position?
Well a permanent position pays "alot" less than
a specialized contract one. Gee, why would a
company want you to be permanent for that?
To be continued...
------------------------------
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 8588
***************************************
