[30888] in Perl-Users-Digest
Perl-Users Digest, Issue: 2133 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 16 09:09:44 2009
Date: Fri, 16 Jan 2009 06:09:07 -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 Fri, 16 Jan 2009 Volume: 11 Number: 2133
Today's topics:
Re: fastest way to allocate memory ? <dmwREMOVEUPPERCASE@coder.cl>
Re: fastest way to allocate memory ? <dmwREMOVEUPPERCASE@coder.cl>
Re: IPC::Shareable::SharedMem: shmget: Permission denie <dmwREMOVEUPPERCASE@coder.cl>
Re: opening a file <cartercc@gmail.com>
Re: opening a file <syscjm@sumire.gwu.edu>
Re: opening a file <syscjm@sumire.gwu.edu>
Posting Guidelines for comp.lang.perl.misc ($Revision: tadmc@seesig.invalid
Re: processing text <RedGrittyBrick@spamweary.invalid>
Re: processing text <syscjm@sumire.gwu.edu>
Re: unable to open file <syscjm@sumire.gwu.edu>
Re: What do you need to have to be considered a Master <g_m@remove-comcast.net>
Re: XML::Parser help <bugbear@trim_papermule.co.uk_trim>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 16 Jan 2009 05:47:41 -0300
From: Daniel Molina Wegener <dmwREMOVEUPPERCASE@coder.cl>
Subject: Re: fastest way to allocate memory ?
Message-Id: <H9CdnTBo1dRu1O3UnZ2dnUVZ_srinZ2d@giganews.com>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
georg.heiss@gmx.de <georg.heiss@gmx.de>
on Friday 16 January 2009 05:04
wrote in comp.lang.perl.misc:
> Hi, i try to allocate 10GB of memory on my box and it takes about 27
> seconds.
> Is there a faster way to do this?
You can try using the mmap(2) syscall from perl. There is
a module that you can try from CPAN:
http://search.cpan.org/~swalters/Sys-Mmap-0.13/Mmap.pm
I don't know another options, since the POSIX module can't
do this task and mmap(2) isn't commint from POSIX, but is
present in SUSv3:
http://www.opengroup.org/onlinepubs/000095399/functions/mmap.html
>
> my $gras = "A" x (1024 * 1024 * 10000);
> my $needle = "B";
> print "\nAllocated " . length($gras) . " byte buffer\n";
> $gras = $gras.$needle;
> print "Allocated " . length($gras) . " byte buffer\n";
> if ($gras ~~ /$needle/) {print "found needle\n"; }
> ###
>
> $ time perl memtake.pl &
> Allocated 10485760000 byte buffer
> Allocated 10485760001 byte buffer
> found needle
>
> real 0m27.280s
> user 0m13.429s
> sys 0m13.839s
Best regards,
- --
.O. | Daniel Molina Wegener | FreeBSD & Linux
..O | dmw [at] coder [dot] cl | Open Standards
OOO | http://coder.cl/ | FOSS Developer
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)
iEYEARECAAYFAklwSbEACgkQxyPEFPXO3WHp4QCff1o6+TncH53LSVcmTSkxhNHK
Fw4An12TwZ2amaD5G5AKCfe5AKI1R7HG
=E1P4
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 16 Jan 2009 05:50:47 -0300
From: Daniel Molina Wegener <dmwREMOVEUPPERCASE@coder.cl>
Subject: Re: fastest way to allocate memory ?
Message-Id: <8oCdnYEbDLEw1-3UnZ2dnUVZ_tudnZ2d@giganews.com>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
georg.heiss@gmx.de <georg.heiss@gmx.de>
on Friday 16 January 2009 05:04
wrote in comp.lang.perl.misc:
> Hi, i try to allocate 10GB of memory on my box and it takes about 27
> seconds.
> Is there a faster way to do this?
Hey, also is there another module called IPC, that
contains a submodule called Mmap:
IPC::Mmap
I think that this one is more standard for perl ;)
>
> my $gras = "A" x (1024 * 1024 * 10000);
> my $needle = "B";
> print "\nAllocated " . length($gras) . " byte buffer\n";
> $gras = $gras.$needle;
> print "Allocated " . length($gras) . " byte buffer\n";
> if ($gras ~~ /$needle/) {print "found needle\n"; }
> ###
>
> $ time perl memtake.pl &
> Allocated 10485760000 byte buffer
> Allocated 10485760001 byte buffer
> found needle
>
> real 0m27.280s
> user 0m13.429s
> sys 0m13.839s
Best regards,
- --
.O. | Daniel Molina Wegener | FreeBSD & Linux
..O | dmw [at] coder [dot] cl | Open Standards
OOO | http://coder.cl/ | FOSS Developer
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)
iEYEARECAAYFAklwSmsACgkQxyPEFPXO3WHcawCgiq/o4SBWWysDgMa9zHPbLlLR
UUUAn38s6bcFrwP4fRU5hrcCjuGdNMbg
=Axyj
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 16 Jan 2009 05:56:29 -0300
From: Daniel Molina Wegener <dmwREMOVEUPPERCASE@coder.cl>
Subject: Re: IPC::Shareable::SharedMem: shmget: Permission denied
Message-Id: <8sydndjmcJKe0e3UnZ2dnUVZ_gGdnZ2d@giganews.com>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
kath <nitte.sudhir@gmail.com>
on Friday 16 January 2009 03:59
wrote in comp.lang.perl.misc:
> Hi,
> I have a simple script to test variable sharing between two perl
> processes,
> use IPC::Shareable;
> $robj = {status=>'init'};
> tie $robj->{status}, 'IPC::Shareable', 'data_glue', {create => 1, mode
> => 664, destroy => 1};
> $pid = fork();
> unless(defined $pid){
> print "Error durigng fork\n";
> }
> if($pid){
> $robj->{parent=>'parent'};
> }else{
> tie $robj->{status}, 'IPC::Shareable', 'data_glue', {create => 0, mode
> => 664, destroy => 0};
> $robj->{status} = 'updated';
> sleep(5);
> exit(0);
> }
> print "\n", $robj->{status}, "\n";
>
> When i run i get following error.
> IPC::Shareable::SharedMem: shmget: Permission denied
> at /usr/lib/perl5/site_perl/5.8.3/IPC/Shareable.pm line 566
> Could not create shared memory segment:
> at test_ipc_shareable.pl line 3
Well, you are making the user to create the block under 0664
permissions, are the both users in the same group? In other case,
if both users are on different group they can't handle the shared
memory block.
If you are under Linux, remember that when you create a new user,
the user holds a new individual group, and is not invited to new
groups until you invite him.
Try setting both users in the same group by inviting them...
>
> Problem: I get above error when run as user account other than
> 'root' . But the script used to work before, but started throwing this
> error, after server where this script runs was down due to storage
> corruption. I am getting this error after server came online.
> I am using perl v5.8.3 and IPC::Shareable v0.60. I tried reinstalling
> the package, using cpan shell, force make IPC::Shareable', but the
> unfortunately 'test IPC::Shareable' fails.
>
> Does any one know how to resolve this? Because running as 'root'
> creates other problems for my main scripts.
>
> Thanks in advance,
> katharnakh.
Best regards,
- --
.O. | Daniel Molina Wegener | FreeBSD & Linux
..O | dmw [at] coder [dot] cl | Open Standards
OOO | http://coder.cl/ | FOSS Developer
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)
iEYEARECAAYFAklwS8EACgkQxyPEFPXO3WEmzQCdGyopJC+y9Tk8sUZW2B8rSq3A
74IAnA3/AThKFEeAntYehpFK8QDCb4rG
=VtpM
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 16 Jan 2009 05:31:35 -0800 (PST)
From: cartercc <cartercc@gmail.com>
Subject: Re: opening a file
Message-Id: <59e3b155-7c17-4037-8e49-5767c408faf4@a12g2000yqm.googlegroups.com>
On Jan 15, 4:06=A0pm, Charlton Wilbur <cwil...@chromatico.net> wrote:
> Where did you throw personal convenience into the mix?
In fact, my wife and I had made plans for that weekend, and she was
very upset when I called her Friday afternoon and told her that I had
to work over the weekend. If I had planned to work the weekend, it
wouldn't have been a big deal, but I didn't lose any time because I
took three days later.
> You're doing unprofessional work because you're acceding to your
> manager's demands to do things that are quick and dirty.
Let's explore this. Is 'quick and dirty' ever appropriate? Microsoft
did QDOS (Quick and Dirty Operating System) early on, IIRC. In my
practice I often take short cuts and ignore best practices for one-
time scripts where the output is more important than the script. I
don't think it's necessarily unprofessional to do 'quick and dirty'
and at times it may be unprofessional to follow all the recommended
practices for a very small job. Besides, it's my manager's call, and
if he wants quick and dirty, shouldn't I comply? We're not talking
about critical health or safety issues here.
>=A0You're
> rationalizing it as a first effort that merely validates the spec, but
> what it boils down to is this: =A0you, as a *professional*, by claiming
> that term, are responsible for the quality of the code you produce. =A0
Absolutely! But the 'quality' relates to the output, not the code. I'm
in my fifth year at my current job, and I've NEVER had a customer look
at my code to see if it's up to snuff ... but I've had customers
complain plenty of times about the output the code produces.* We are
judged by the work product, not necessarily by the means used to
produce the work. No one here gives a rat's ass about the quality of
my code, except for me.
> This means pushing back when the manager tells you to do something
> inappropriate.
Absolutely! But there's a difference between 'inappropriate' and an
unreasonably short deadline. I very rarely get impossible deadlines,
but when I do, I make every effort to get the work done by the
deadline. If the deadline passes without the job being finished, then
it's on the manager, not me, and that's all the 'pushing back' that's
needed.
> Didn't you start a thread some time back about crisis mode programming?
> Do you really not see a connection between your willingness to work on
> deathmarch and panic-driven schedules without pushing back, and the
> frequency with which you have to deal with crises?
Hey, a large part of my job is to produce reports, and it's common for
the customer to request the report at the very last minute. These may
be crises, but they are not of my making. At the end of the day it's
the customer that faces the consequences of the crisis. Despite that,
I make the effort to do my job in such a way that no one can fault me
for the failure to get the work done on time. (Please note that my job
is NOT writing software but producing reports -- I just produce
reports by scripting.)
> I am a firm believer in the maxim "A failure to prepare or plan on your
> part does not constitute an emergency on mine."
I totally agree. My version of this is, 'Procrastination on your part
does not constitute an emergency on my part.'
> I have had managers who were walking repositories of self-created crises
> and emergencies. =A0I pushed back hard against the self-created deadlines=
,
> and when I found managers who were impossible to train, I got out of
> those jobs as quickly as I could.
I only have one manager, and I've seen him once this year. He
generally leaves me alone, and I probably don't get an assignment from
him more than once a month. OTOH, I have lots of customers, some of
whom give me plenty of time but others who notoriously send in jobs at
or past their deadline.
> I advise you to do likewise.
My general approach is to meet or beat the deadline without
complaining. If I can't, I explain that I can't do a 12 hour job in
three hours --- BUT I MAKE SURE THAT THIS IS SEEN AS AN EXPLANATION
AND NOT AS AN EXCUSE. People know that I try hard, and most customers
are willing to accept the consequences of their own procrastination.
CC
-----------------
* There are many reasons a customer would complain about the output,
ranging from an ambiguous specification, to garbage input, to my not
understanding what was needed. Case in point: this week, an
administrator requested a report on 'all active students.' He got a
list of tens of thousands of names when he was expecting a couple of
dozen names, and he complained. What he wanted was HIS active
students, but what he requested was ALL active students, and I gave
him what he asked for, not what he meant to ask for. Also, it's not
uncommon for me to misunderstand the request, so I take credit for a
reasonable share of the blame.
------------------------------
Date: Fri, 16 Jan 2009 07:45:13 -0600
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: opening a file
Message-Id: <slrngn13r9.qiu.syscjm@sumire.gwu.edu>
On 2009-01-16, cartercc <cartercc@gmail.com> wrote:
<snip>
>
> Let's explore this. Is 'quick and dirty' ever appropriate? Microsoft
> did QDOS (Quick and Dirty Operating System) early on, IIRC. In my
I couldn't have come up with a better argument for keeping the hell away
from "quick and dirty" work if I'd had a week to work one out.
<snip>
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: Fri, 16 Jan 2009 07:49:00 -0600
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: opening a file
Message-Id: <slrngn142c.qiu.syscjm@sumire.gwu.edu>
On 2009-01-16, cartercc <cartercc@gmail.com> wrote:
<snip>
>
> Absolutely! But the 'quality' relates to the output, not the code. I'm
Wrong. So, so, so wrong.
> in my fifth year at my current job, and I've NEVER had a customer look
> at my code to see if it's up to snuff ... but I've had customers
> complain plenty of times about the output the code produces.* We are
> judged by the work product, not necessarily by the means used to
> produce the work. No one here gives a rat's ass about the quality of
> my code, except for me.
Nobody who drives across a bridge gives a rat's ass about the details of
its structural integrity--until the day the bridge collapses. Maybe the
critical failure of your code won't cost lives, but it's still your
professional responsibility.
<snip>
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: Fri, 16 Jan 2009 08:13:37 GMT
From: tadmc@seesig.invalid
Subject: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.8 $)
Message-Id: <RkXbl.2109$%54.2018@nlpi070.nbdc.sbc.com>
Outline
Before posting to comp.lang.perl.misc
Must
- Check the Perl Frequently Asked Questions (FAQ)
- Check the other standard Perl docs (*.pod)
Really Really Should
- Lurk for a while before posting
- Search a Usenet archive
If You Like
- Check Other Resources
Posting to comp.lang.perl.misc
Is there a better place to ask your question?
- Question should be about Perl, not about the application area
How to participate (post) in the clpmisc community
- Carefully choose the contents of your Subject header
- Use an effective followup style
- Speak Perl rather than English, when possible
- Ask perl to help you
- Do not re-type Perl code
- Provide enough information
- Do not provide too much information
- Do not post binaries, HTML, or MIME
Social faux pas to avoid
- Asking a Frequently Asked Question
- Asking a question easily answered by a cursory doc search
- Asking for emailed answers
- Beware of saying "doesn't work"
- Sending a "stealth" Cc copy
Be extra cautious when you get upset
- Count to ten before composing a followup when you are upset
- Count to ten after composing and before posting when you are upset
-----------------------------------------------------------------
Posting Guidelines for comp.lang.perl.misc ($Revision: 1.8 $)
This newsgroup, commonly called clpmisc, is a technical newsgroup
intended to be used for discussion of Perl related issues (except job
postings), whether it be comments or questions.
As you would expect, clpmisc discussions are usually very technical in
nature and there are conventions for conduct in technical newsgroups
going somewhat beyond those in non-technical newsgroups.
The article at:
http://www.catb.org/~esr/faqs/smart-questions.html
describes how to get answers from technical people in general.
This article describes things that you should, and should not, do to
increase your chances of getting an answer to your Perl question. It is
available in POD, HTML and plain text formats at:
http://www.rehabitation.com/clpmisc.shtml
For more information about netiquette in general, see the "Netiquette
Guidelines" at:
http://andrew2.andrew.cmu.edu/rfc/rfc1855.html
A note to newsgroup "regulars":
Do not use these guidelines as a "license to flame" or other
meanness. It is possible that a poster is unaware of things
discussed here. Give them the benefit of the doubt, and just
help them learn how to post, rather than assume that they do
know and are being the "bad kind" of Lazy.
A note about technical terms used here:
In this document, we use words like "must" and "should" as
they're used in technical conversation (such as you will
encounter in this newsgroup). When we say that you *must* do
something, we mean that if you don't do that something, then
it's unlikely that you will benefit much from this group.
We're not bossing you around; we're making the point without
lots of words.
Do *NOT* send email to the maintainer of these guidelines. It will be
discarded unread. The guidelines belong to the newsgroup so all
discussion should appear in the newsgroup. I am just the secretary that
writes down the consensus of the group.
Before posting to comp.lang.perl.misc
Must
This section describes things that you *must* do before posting to
clpmisc, in order to maximize your chances of getting meaningful replies
to your inquiry and to avoid getting flamed for being lazy and trying to
have others do your work.
The perl distribution includes documentation that is copied to your hard
drive when you install perl. Also installed is a program for looking
things up in that (and other) documentation named 'perldoc'.
You should either find out where the docs got installed on your system,
or use perldoc to find them for you. Type "perldoc perldoc" to learn how
to use perldoc itself. Type "perldoc perl" to start reading Perl's
standard documentation.
Check the Perl Frequently Asked Questions (FAQ)
Checking the FAQ before posting is required in Big 8 newsgroups in
general, there is nothing clpmisc-specific about this requirement.
You are expected to do this in nearly all newsgroups.
You can use the "-q" switch with perldoc to do a word search of the
questions in the Perl FAQs.
Check the other standard Perl docs (*.pod)
The perl distribution comes with much more documentation than is
available for most other newsgroups, so in clpmisc you should also
see if you can find an answer in the other (non-FAQ) standard docs
before posting.
It is *not* required, or even expected, that you actually *read* all of
Perl's standard docs, only that you spend a few minutes searching them
before posting.
Try doing a word-search in the standard docs for some words/phrases
taken from your problem statement or from your very carefully worded
"Subject:" header.
Really Really Should
This section describes things that you *really should* do before posting
to clpmisc.
Lurk for a while before posting
This is very important and expected in all newsgroups. Lurking means
to monitor a newsgroup for a period to become familiar with local
customs. Each newsgroup has specific customs and rituals. Knowing
these before you participate will help avoid embarrassing social
situations. Consider yourself to be a foreigner at first!
Search a Usenet archive
There are tens of thousands of Perl programmers. It is very likely
that your question has already been asked (and answered). See if you
can find where it has already been answered.
One such searchable archive is:
http://groups.google.com/advanced_group_search
If You Like
This section describes things that you *can* do before posting to
clpmisc.
Check Other Resources
You may want to check in books or on web sites to see if you can
find the answer to your question.
But you need to consider the source of such information: there are a
lot of very poor Perl books and web sites, and several good ones
too, of course.
Posting to comp.lang.perl.misc
There can be 200 messages in clpmisc in a single day. Nobody is going to
read every article. They must decide somehow which articles they are
going to read, and which they will skip.
Your post is in competition with 199 other posts. You need to "win"
before a person who can help you will even read your question.
These sections describe how you can help keep your article from being
one of the "skipped" ones.
Is there a better place to ask your question?
Question should be about Perl, not about the application area
It can be difficult to separate out where your problem really is,
but you should make a conscious effort to post to the most
applicable newsgroup. That is, after all, where you are the most
likely to find the people who know how to answer your question.
Being able to "partition" a problem is an essential skill for
effectively troubleshooting programming problems. If you don't get
that right, you end up looking for answers in the wrong places.
It should be understood that you may not know that the root of your
problem is not Perl-related (the two most frequent ones are CGI and
Operating System related), so off-topic postings will happen from
time to time. Be gracious when someone helps you find a better place
to ask your question by pointing you to a more applicable newsgroup.
How to participate (post) in the clpmisc community
Carefully choose the contents of your Subject header
You have 40 precious characters of Subject to win out and be one of
the posts that gets read. Don't waste them. Take care while
composing them, they are the key that opens the door to getting an
answer.
Spend them indicating what aspect of Perl others will find if they
should decide to read your article.
Do not spend them indicating "experience level" (guru, newbie...).
Do not spend them pleading (please read, urgent, help!...).
Do not spend them on non-Subjects (Perl question, one-word
Subject...)
For more information on choosing a Subject see "Choosing Good
Subject Lines":
http://www.cpan.org/authors/id/D/DM/DMR/subjects.post
Part of the beauty of newsgroup dynamics, is that you can contribute
to the community with your very first post! If your choice of
Subject leads a fellow Perler to find the thread you are starting,
then even asking a question helps us all.
Use an effective followup style
When composing a followup, quote only enough text to establish the
context for the comments that you will add. Always indicate who
wrote the quoted material. Never quote an entire article. Never
quote a .signature (unless that is what you are commenting on).
Intersperse your comments *following* each section of quoted text to
which they relate. Unappreciated followup styles are referred to as
"top-posting", "Jeopardy" (because the answer comes before the
question), or "TOFU" (Text Over, Fullquote Under).
Reversing the chronology of the dialog makes it much harder to
understand (some folks won't even read it if written in that style).
For more information on quoting style, see:
http://web.presby.edu/~nnqadmin/nnq/nquote.html
Speak Perl rather than English, when possible
Perl is much more precise than natural language. Saying it in Perl
instead will avoid misunderstanding your question or problem.
Do not say: I have variable with "foo\tbar" in it.
Instead say: I have $var = "foo\tbar", or I have $var = 'foo\tbar',
or I have $var = <DATA> (and show the data line).
Ask perl to help you
You can ask perl itself to help you find common programming mistakes
by doing two things: enable warnings (perldoc warnings) and enable
"strict"ures (perldoc strict).
You should not bother the hundreds/thousands of readers of the
newsgroup without first seeing if a machine can help you find your
problem. It is demeaning to be asked to do the work of a machine. It
will annoy the readers of your article.
You can look up any of the messages that perl might issue to find
out what the message means and how to resolve the potential mistake
(perldoc perldiag). If you would like perl to look them up for you,
you can put "use diagnostics;" near the top of your program.
Do not re-type Perl code
Use copy/paste or your editor's "import" function rather than
attempting to type in your code. If you make a typo you will get
followups about your typos instead of about the question you are
trying to get answered.
Provide enough information
If you do the things in this item, you will have an Extremely Good
chance of getting people to try and help you with your problem!
These features are a really big bonus toward your question winning
out over all of the other posts that you are competing with.
First make a short (less than 20-30 lines) and *complete* program
that illustrates the problem you are having. People should be able
to run your program by copy/pasting the code from your article. (You
will find that doing this step very often reveals your problem
directly. Leading to an answer much more quickly and reliably than
posting to Usenet.)
Describe *precisely* the input to your program. Also provide example
input data for your program. If you need to show file input, use the
__DATA__ token (perldata.pod) to provide the file contents inside of
your Perl program.
Show the output (including the verbatim text of any messages) of
your program.
Describe how you want the output to be different from what you are
getting.
If you have no idea at all of how to code up your situation, be sure
to at least describe the 2 things that you *do* know: input and
desired output.
Do not provide too much information
Do not just post your entire program for debugging. Most especially
do not post someone *else's* entire program.
Do not post binaries, HTML, or MIME
clpmisc is a text only newsgroup. If you have images or binaries
that explain your question, put them in a publically accessible
place (like a Web server) and provide a pointer to that location. If
you include code, cut and paste it directly in the message body.
Don't attach anything to the message. Don't post vcards or HTML.
Many people (and even some Usenet servers) will automatically filter
out such messages. Many people will not be able to easily read your
post. Plain text is something everyone can read.
Social faux pas to avoid
The first two below are symptoms of lots of FAQ asking here in clpmisc.
It happens so often that folks will assume that it is happening yet
again. If you have looked but not found, or found but didn't understand
the docs, say so in your article.
Asking a Frequently Asked Question
It should be understood that you may have missed the applicable FAQ
when you checked, which is not a big deal. But if the Frequently
Asked Question is worded similar to your question, folks will assume
that you did not look at all. Don't become indignant at pointers to
the FAQ, particularly if it solves your problem.
Asking a question easily answered by a cursory doc search
If folks think you have not even tried the obvious step of reading
the docs applicable to your problem, they are likely to become
annoyed.
If you are flamed for not checking when you *did* check, then just
shrug it off (and take the answer that you got).
Asking for emailed answers
Emailed answers benefit one person. Posted answers benefit the
entire community. If folks can take the time to answer your
question, then you can take the time to go get the answer in the
same place where you asked the question.
It is OK to ask for a *copy* of the answer to be emailed, but many
will ignore such requests anyway. If you munge your address, you
should never expect (or ask) to get email in response to a Usenet
post.
Ask the question here, get the answer here (maybe).
Beware of saying "doesn't work"
This is a "red flag" phrase. If you find yourself writing that,
pause and see if you can't describe what is not working without
saying "doesn't work". That is, describe how it is not what you
want.
Sending a "stealth" Cc copy
A "stealth Cc" is when you both email and post a reply without
indicating *in the body* that you are doing so.
Be extra cautious when you get upset
Count to ten before composing a followup when you are upset
This is recommended in all Usenet newsgroups. Here in clpmisc, most
flaming sub-threads are not about any feature of Perl at all! They
are most often for what was seen as a breach of netiquette. If you
have lurked for a bit, then you will know what is expected and won't
make such posts in the first place.
But if you get upset, wait a while before writing your followup. I
recommend waiting at least 30 minutes.
Count to ten after composing and before posting when you are upset
After you have written your followup, wait *another* 30 minutes
before committing yourself by posting it. You cannot take it back
once it has been said.
AUTHOR
Tad McClellan and many others on the comp.lang.perl.misc newsgroup.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Fri, 16 Jan 2009 10:10:43 +0000
From: RedGrittyBrick <RedGrittyBrick@spamweary.invalid>
Subject: Re: processing text
Message-Id: <49705d24$0$11933$db0fefd9@news.zen.co.uk>
George wrote:
> I thought I was past trouble working with simple file manipulations, but I
> seem to be stumped here again:
>
>
> #!/usr/bin/perl
> use strict;
> use warnings;
>
> my $filename = 'larry1.txt';
> my $outfile = 'processed1.txt'
> open my $fh, '<', $filename or die "cannot open $filename: $!";
> open my $gh, '>', $outfile or die "cannot open $filename: $!";
^^^^^^^^ ^^^^^^^^^^
> while (<$fh>) {
> s/%%/%\n/;
> print $gh, $_;
> }
> close($fh)
> close($gh)
>
--
RGB
------------------------------
Date: Fri, 16 Jan 2009 07:52:40 -0600
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: processing text
Message-Id: <slrngn1498.qiu.syscjm@sumire.gwu.edu>
On 2009-01-16, George <george@example.invalid> wrote:
> On Thu, 15 Jan 2009 14:19:33 -0500, Uri Guttman wrote:
>
>>>>>>> "G" == George <george@example.invalid> writes:
>>
>> G> I thought I was past trouble working with simple file manipulations, but I
>> G> seem to be stumped here again:
>>
>>
>> G> #!/usr/bin/perl
>> G> use strict;
>> G> use warnings;
>>
>> G> my $filename = 'larry1.txt';
>> G> my $outfile = 'processed1.txt'
>>
>> missing ;
>>
>> that causes that and the next line to be a single long statement which
>> is parsed wierdly and spits out lots of error.
>>
>> G> open my $fh, '<', $filename or die "cannot open $filename: $!";
>> G> open my $gh, '>', $outfile or die "cannot open $filename: $!";
>> G> while (<$fh>) {
>> G> s/%%/%\n/;
>> G> print $gh, $_;
>>
>> the file handle arg to print doesn't get a comma afterwards
>>
>> G> }
>> G> close($fh)
>> G> close($gh)
>>
>> uri
>
> Thx uri.
>
> I looked back over this error message, and it doesn't "look like" I failed
> to use a ;. I guess one of the things you always have to look for is if
> you get an error on line 7, go look to see if line 6 is terminated
> properly.
>
Yes. Failure to use needed semicolons fatally confuses the perl parser
and you get all kinds of bizarre error messages as a result (if you think
about it, if perl could figure out where you needed semicolons, it wouldn't
need you to put them there!). Your thought on looking for missing semicolons
is a very good one.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: Fri, 16 Jan 2009 07:57:08 -0600
From: Chris Mattern <syscjm@sumire.gwu.edu>
Subject: Re: unable to open file
Message-Id: <slrngn14hk.qiu.syscjm@sumire.gwu.edu>
On 2009-01-16, Tintin@teranews.com <Tintin@teranews.com> wrote:
<snip>
> Tad J McClellan wrote:
>>
>> FindBin tells you where the program is.
>>
>> Where the program is does not matter with regard to relative paths.
>
> It does in relation to the OP's question. It is quite common to
> reference configuration files or similar from a Perl/CGI script in
> relation to the location where the script exists.
No, it isn't. That's Tad's point. Relative pathnames are relative to your
current working directory. Period. It is pointless to speculate how your
CWD may relate to where your script is located when you can just find out
where the CWD is, and also set it to where you want it to be.
>
> As we know, the CGI spec does not guarantee the current working
> directory is the same as the script location, so knowing the path
> relative to the directory the Perl script lives in can be much more
> useful than the current working directory.
>
>
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
------------------------------
Date: Fri, 16 Jan 2009 08:02:25 -0500
From: "~greg" <g_m@remove-comcast.net>
Subject: Re: What do you need to have to be considered a Master at Perl?
Message-Id: <v9ydnSfJAaxgGe3UnZ2dnUVZ_tfinZ2d@giganews.com>
"~greg" > ...
> Yesterday I learnt how to match balanced parentheses:
>
> use strict;
> use warnings;
> $|=1;
>
> my $test = 'this is a test of ((((hugs))))';
>
> my $P;
> $P = qr/\((?:(?>[^()]+)|(??{$P}))*\)/o;
>
> $test =~ s/$P/bugs/o;
>
> print $test;
>
>
Note that here I've added the /o ( == substitute variable values "only once")
optimizing modifier to the above. And yet it still works! (-for me)
So I'd say that a Perl Master is anyone who can explain to me
exactly why it worked --at all!
(--ie, explicate the perlfre passage quoted below in clearer concepts.)
Because I apparently got the idea from perlre, where it says
(--and note the warnings, in particular:
Because perl's regex engine is not currently re-entrant,
delayed code may not invoke the regex engine
either directly with m// or s/// ) ...
)....
---------------------------------------------
Quote from "perlre - Perl regular expressions" ...
(??{ code })
WARNING: This extended regular expression feature is considered experimental,
and may be changed without notice. Code executed that has side effects
may not perform identically from version to version
due to the effect of future optimisations in the regex engine.
This is a "postponed" regular subexpression.
The code is evaluated at run time,
at the moment this subexpression may match.
The result of evaluation is considered
as a regular expression and matched
as if it were inserted instead of this construct.
Note that this means that the contents of capture buffers
defined inside an eval'ed pattern are not available
outside of the pattern, and vice versa,
there is no way for the inner pattern
to refer to a capture buffer defined outside.
Thus,
('a' x 100)=~/(??{'(.)' x 100})/
will match, it will not set $1.
The code is not interpolated.
As before, the rules to determine where the code ends
are currently somewhat convoluted.
The following pattern matches a parenthesized group:
$re = qr{
\(
(?:
(?> [^()]+ ) # Non-parens without backtracking
|
(??{ $re }) # Group with matching parens
)*
\)
}x;
See also (?PARNO) for a different, more efficient way to accomplish the same task.
Because perl's regex engine is not currently re-entrant,
delayed code may not invoke the regex engine either
directly with m// or s///), or indirectly with functions such as split.
Recursing deeper than 50 times without consuming any input string
will result in a fatal error. The maximum depth is compiled into perl,
so changing it requires a custom build.
------------------------------
Date: Fri, 16 Jan 2009 10:39:50 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: XML::Parser help
Message-Id: <Y6Odna1hELhq_u3UnZ2dnUVZ8uadnZ2d@posted.plusnet>
hymie! wrote:
> Greetings.
>
> I have a perl script that uses XML::Parser. I don't understand fully
> how it works. Alas, that doesn't stop me from having to maintain it.
>
> $self is a large reference that carries around a whole bunch of stuff --
> data, functions, etc.
>
> I see where my script sets up some handlers including
> End => sub {$self->endElement(@_)},
>
> I see where the endElement function has some arguments
> my ($expat, $el) = @_;
>
> I see where we are checking $el for the name of the node we are processing
> and taking entries out of that node.
> if($el eq "NewsLines") {
> my $v = delete $self->item->{HeadLine};
> $self->doc->{"HEADLINE"} = $v if defined($v);
>
> The problem I'm having is that knowing I'm in a node named "NewsLines" is
> not sufficient. This horrible XML file is a bastardization of NewsML.
> As such, NewsLines could appear in any of these places:
>
> /NewsML/NewsItem/NewsComponent/NewsLines
> /NewsML/NewsItem/NewsComponent/NewsComponent/NewsLines
> /NewsML/NewsItem/NewsComponent/NewsComponent/NewsComponent/NewsLines
>
> I need to ensure that I am looking at either
> /NewsML/NewsItem/NewsComponent/NewsLines
> or
> /NewsML/NewsItem/NewsComponent/NewsComponent/NewsLines
> but **never**
> /NewsML/NewsItem/NewsComponent/NewsComponent/NewsComponent/NewsLines
>
> and my knowledge of XML and/or XML::Parser is not that strong.
>
> Can somebody give me a push?
Yes; declare both a Start and End handler and push the Element name
on a stack (array!) in Start(), and pop the stack in End();
The stack is then an easily accessible source
of the information you require; it could be easily mapped
to an XPath like format (as in your examples) and
tested with a regexp for example.
BugBear
------------------------------
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 V11 Issue 2133
***************************************
