[31841] in Perl-Users-Digest
Perl-Users Digest, Issue: 3104 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Aug 29 00:09:47 2010
Date: Sat, 28 Aug 2010 21:09:09 -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 Sat, 28 Aug 2010 Volume: 11 Number: 3104
Today's topics:
Re: Help writing 'simple' loop <sbryce@scottbryce.com>
Re: Help writing 'simple' loop <jurgenex@hotmail.com>
Re: Help writing 'simple' loop <jurgenex@hotmail.com>
Re: Help writing 'simple' loop joey@igetit.invalid
Re: Help writing 'simple' loop <tadmc@seesig.invalid>
Re: Help writing 'simple' loop <tadmc@seesig.invalid>
Re: Help writing 'simple' loop <tadmc@seesig.invalid>
Re: Help writing 'simple' loop <tadmc@seesig.invalid>
Re: Help writing 'simple' loop <tadmc@seesig.invalid>
Re: perldoc (was: Re: FAQ 5.23...) <kkeller-usenet@wombat.san-francisco.ca.us>
Re: perldoc (was: Re: FAQ 5.23...) <ben@morrow.me.uk>
Re: perldoc (was: Re: FAQ 5.23...) <ben@morrow.me.uk>
Re: Writing or copying file to another directory <paul@pstech-inc.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 28 Aug 2010 12:13:40 -0600
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Help writing 'simple' loop
Message-Id: <i5bjkv$pvl$1@news.eternal-september.org>
On 8/28/2010 11:53 AM, joey@igetit.invalid wrote:
> Scott Bryce wrote:
>> BTW, you will find that camel case (mixing upper and lower case in
>> variable names) quickly becomes a pain. Try using @h_right.
>
> Too late. I've been writing with that notation for years.
I starting writing Perl in camel case for the same reason. I wish I
hadn't. It has since become a maintenance problem.
> Outside of declaring variables to comply with Perl's 'strict'
> directive, why is it important to declare variables as local. Why not
> global?
Much of my programming has been using authoring systems, where it is
common not to have local variables. If you have ever spent hours
debugging a problem that was caused by a totally unrelated chunk of code
stomping on your variables, you would know the answer to that question.
Also keeping variables in a subroutine local to the subroutine makes
maintenance of the code much easier. Imagine re-writing a chunk of your
program and breaking your subroutine without knowing it. Or re-writing
your subroutine and breaking the program elsewhere without knowing it.
> I've only defined @hRight so that I could write the loop. Beyond
> that, I have no reason to otherwise collect the variables in an
> array, except to add them.
>
> So, my question remains...is it more efficient to simply add the
> variables?
If you have your heart set on writing this without arrays, then yes, it
would be simpler to just add the values. But everything else about your
program will be clunkier than necessary.
------------------------------
Date: Sat, 28 Aug 2010 11:28:44 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Help writing 'simple' loop
Message-Id: <lpji769rqp9jmrgq834h74rhhgu2njofr7@4ax.com>
joey@igetit.invalid wrote:
>Jürgen Exner wrote:
>
>>JoeyF1276@earthlink.net wrote:
>>>$h1_right through $h10_right are 10 independent integer values.
>>>
>>>$hTotalRight = $h1_right + $h2_right + $h3_right + $h4_right + $h5_right +
>>>$h6_right + $h7_right + $h8_right + $h9_right + $h10_right;
>>>
>>>I can't figure out the syntax for $XXX to write a loop to do the addition.
>>>$hTotalRight = 0;
>>>for ($i=1;$i<11;$i++) {
>>>$hTotalRight = $hTotalRight + $XXX;
>>>}
>>>
>>>What is the syntax for $XXX?
>>
>>It is trivial:
>>
>>my @h_right = (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
>>my $hTotalRight = 0;
>>for my $i (1...10) {
>> $hTotalRight = $hTotalRight + $h_right[$i];
>>}
>>
>Thanks for the input. (Shouldn't the $i range be 0...9?)
Yes, sorry.
>>Now, before you scream "I don't want to use a f*#%$#$ array"
>>
>I have no problem using arrays, but as I pointed out in my post today to
>Tad McClellan, I'm wondering if simple addition isn't more efficient.
Yes, it will be. The loop will add maybe a few microseconds. Is your
application so time critical that a few microseconds matter? Then Perl
is not best choice anyway.
>>you may
>>want to read up on the many, many previous posts as well as the FAQ
>>about "variable as a variable name" regarding why symbolic references
>>are a really, really bad idea.
>
>I understand the issue, but the formalism for which I've written the code
>specifically uses h1, h2, etc.,
Then maybe redesign that formalism to use $h[1], $h[2], ....
I am guessing those 1, 2, ... are actually indices in some mathematical
formula. Then they translate naturally into $h[1], $h[2], etc. Using
$h1, $h2 ... instead is a big mistake that is hurting you now way down
the road.
BTW: if you got a problem with Perl arrays starting with 0 while your
indexed mathematical variables are starting with 1 and you really can't
change those indices for the math variables (today in math formulas 0 is
just as acceptable as starting index as 1), then this might be one of
those rare cases, where altering $[ is justified.
>and I need to maintain syntactical
>identity; hence, $h1_right, $h3_left,etc. It's much easier for me to
>relate to $hn_side versus $sideh[0].
Ahhhhh, now I see. Your real variable is $h. And you got 10 instances of
those. And for each instance you got sides "left" and "right".
And you tried to store all this valuable structural information in the
variable name instead of constructing a proper data structure in the
first place.
What about using e.g.
$h[4]{left}
instead? Wouldn't that reflect what you are trying to express in the
variable name?
$h[4]{left} is how you access an element in an array of hashes, short
AoH. More details see 'perldoc perldata'.
You can also check out
perldoc -q "array of hash"
The answer there is pertinent to the 'left'/'right' hash and the $record
there would be one of the 10 elements in your array.
jue
------------------------------
Date: Sat, 28 Aug 2010 11:38:53 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: Help writing 'simple' loop
Message-Id: <4gli76dn9oi2av0e796kbs6li800juje3r@4ax.com>
joey@igetit.invalid wrote:
>>> for ($i=0;$i<10;$i++) {
>>
>>for my $i (0 .. 9) {
>
>Outside of declaring variables to comply with Perl's 'strict' directive,
>why is it important to declare variables as local. Why not global?
See "Fundamentals of Software Engineering 101", second or third lecture.
No, seriously, the principle of localizing just about anything to the
smallest reasonable scope is so fundamental, I wonder why some people
still argue about it.
Do you really want to run the risk that somewhere far away someone else
in a totally unrelated piece of code happens to use the same variable
name and screws up the value you are relying on?
>>I'm wondering why if you are defining @hRight, are you not using it all
>>along? It seems pointless to have an @hRight variable and still make use
>>of your $h1_right, etc variables. Get rid of them and just use the
>>array. Wherever the initial values are coming from, just load them
>>directly into the array.
>
>I've only defined @hRight so that I could write the loop. Beyond that, I
>have no reason to otherwise collect the variables in an array, except to
>add them.
I do not believe you. If you enumerate variables like $h1, $h2, $h3,
then they are related in some way (why else would you enumerate then
like that?) and there is no reason not to use an array instead.
jue
------------------------------
Date: Sat, 28 Aug 2010 12:33:47 -0700
From: joey@igetit.invalid
Subject: Re: Help writing 'simple' loop
Message-Id: <cdni761tpv8fl4d50dgl8bdb3cnap8ojbd@4ax.com>
Jürgen Exner wrote:
>joey@igetit.invalid wrote:
>>>> for ($i=0;$i<10;$i++) {
>>>
>>>for my $i (0 .. 9) {
>>
>>Outside of declaring variables to comply with Perl's 'strict' directive,
>>why is it important to declare variables as local. Why not global?
>
>See "Fundamentals of Software Engineering 101", second or third lecture.
>
>No, seriously, the principle of localizing just about anything to the
>smallest reasonable scope is so fundamental, I wonder why some people
>still argue about it.
I'm not arguing the point. I was questioning it. I understand the concept
behind maintaining localization.
>Do you really want to run the risk that somewhere far away someone else
>in a totally unrelated piece of code happens to use the same variable
>name and screws up the value you are relying on?
Point well made. (I'd argue that careful coding and naming practice would
avoid this possibility, but using modules forecloses that argument. I use
CGI.)
>
>>>I'm wondering why if you are defining @hRight, are you not using it all
>>>along?
I defined it solely for the instant issue.
>It seems pointless to have an @hRight variable and still make use
>>>of your $h1_right, etc variables.
That's simply a product of your lack of knowledge re my application and
audience. It's not at all pointless to me. Even if I assigned $sideH[n] =
$hn_side, I still have purpose and point to using $hn_side.
>Get rid of them and just use the array. Wherever the initial values are
>coming from, just load them directly into the array.
>>
>>I've only defined @hRight so that I could write the loop. Beyond that, I
>>have no reason to otherwise collect the variables in an array, except to
>>add them.
>
>I do not believe you. If you enumerate variables like $h1, $h2, $h3,
>then they are related in some way (why else would you enumerate then
>like that?) and there is no reason not to use an array instead.
>
They are related only in that they are elements of the same
subset...measured and manipulated values of independent parameters.
Independent symptoms of disease processes, which when added together give
rise to a total symptoms score. The elements are universally known to the
medical community as h1, h2..q1, q2.., etc. I live in that medical
community, and I conform to its standards and practices.
Thanks again for your comments. Yours have been helpful, constructive and
topical wrt my issue.
--
Joey
------------------------------
Date: Sat, 28 Aug 2010 17:13:17 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help writing 'simple' loop
Message-Id: <slrni7j264.fjh.tadmc@tadbox.sbcglobal.net>
joey@igetit.invalid <joey@igetit.invalid> wrote:
> Tad McClellan wrote:
>>Or, even better, instead of assigning to $h1_right assign to $hRight[0]
>>in the first place.
> I've taken all the pertinent advice offered
No you haven't.
> and come up with:
>
> hRight = ($h1_right, $h2_right, $h3_right, $h4_right, $h5_right,
> $h6_right, $h7_right, $h8_right, $h9_right, $h10_right);
Instead of assigning to $h1_right assign to $hRight[0] in the first place.
> addScores(\@hRight);
>
> sub addScores {
> $score = 0;
> for ($i=0;$i<10;$i++) {
> $score = $score + $_[0][$i];
> }
> }
> which works as it should. (I'm using a subroutine as there are six arrays
> to perform the same addition on.)
There isn't much need for a subroutine...
my $total;
$total += $_ for @hRight;
> But...now I'm wondering whether in the pursuit of efficiency and elegance
You have NOT pursued elegance.
An elegant solution would have been to rework your program
to use a data structure more suited to the structure of your data.
> I'm making a mistake by employing the above
Yes.
> instead of simply adding the
> variables, i.e.,
>
> $score = ($h1_right + $h2_right) + ($h3_right + $h4_right) + ($h5_right +
> $h6_right) + ($h7_right + $h8_right) + ($h9_right + $h10_right);
>
> Is there some reason I would want to abandon seeming simplicity in favor
> of 'neat-looking?'
Your *current* solution is abandoning simplicity.
A simple solution would be to have used a data structure more
suited to the structure of your data.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 28 Aug 2010 17:19:47 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help writing 'simple' loop
Message-Id: <slrni7j2ia.fjh.tadmc@tadbox.sbcglobal.net>
joey@igetit.invalid <joey@igetit.invalid> wrote:
> Scott Bryce wrote:
>
>>On 8/28/2010 11:04 AM, joey@igetit.invalid wrote:
>>> I've taken all the pertinent advice offered and come up with:
>>>
>>> hRight = ($h1_right, $h2_right, $h3_right, $h4_right, $h5_right,
>>> $h6_right, $h7_right, $h8_right, $h9_right, $h10_right);
>>
>>ITYM @hRight =
>
> Yes. Typo.
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.
Have you seen the Posting Guidelines that are posted here frequently?
>>BTW, you will find that camel case (mixing upper and lower case in
>>variable names) quickly becomes a pain. Try using @h_right.
>
> Too late. I've been writing with that notation for years. I'm old...and an
> old dog.
We will laugh at you then, live with it.
> why is it important to declare variables as local. Why not global?
Sheesh!
You seem to be trying extra hard to wear out your welcome here...
http://lmgtfy.com/?q=why+are+global+variables+bad
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 28 Aug 2010 17:24:00 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help writing 'simple' loop
Message-Id: <slrni7j2q7.fjh.tadmc@tadbox.sbcglobal.net>
joey@igetit.invalid <joey@igetit.invalid> wrote:
> Jürgen Exner wrote:
>
>>joey@igetit.invalid wrote:
>>>>> for ($i=0;$i<10;$i++) {
>>>>
>>>>for my $i (0 .. 9) {
>>>
>>>Outside of declaring variables to comply with Perl's 'strict' directive,
>>>why is it important to declare variables as local. Why not global?
>>
>>See "Fundamentals of Software Engineering 101", second or third lecture.
>>
>>No, seriously, the principle of localizing just about anything to the
>>smallest reasonable scope is so fundamental, I wonder why some people
>>still argue about it.
>
> I'm not arguing the point. I was questioning it.
The principle of localizing just about anything to the smallest
reasonable scope is so fundamental, I wonder why some people
still question it.
I am beginning to believe that you are, in fact, trolling us...
> I understand the concept
> behind maintaining localization.
If you don't restrict the scope of variables whenever possible,
then you DO NOT understand the concept behind maintaining localization.
(or you are much too silly to be writing programs)
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 28 Aug 2010 17:35:15 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help writing 'simple' loop
Message-Id: <slrni7j3fa.fjh.tadmc@tadbox.sbcglobal.net>
joey@igetit.invalid <joey@igetit.invalid> wrote:
> I'm wondering if simple addition isn't more efficient.
Stop wondering that.
You are very clearly not a programmer.
We are programmers.
We will indoctrinate you to standard best practices if you display
a willingness to become a programmer (ie. one who writes programs).
Have you established that the code using an array is too slow
for your application?
If not, then wondering that is premature:
"Premature optimization is the root of all evil."
http://en.wikiquote.org/wiki/C._A._R._Hoare
See also:
http://en.wikipedia.org/wiki/Anti-pattern
Programmers have been making mistakes for years. Some of them have
developed best practices that help to avoid common mistakes.
Ignore all of that if you would like to re-discover anew all of
the problems in programming that have already been solved,
rather than concentrating on writing code that solves your
real problem.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 28 Aug 2010 17:39:40 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Help writing 'simple' loop
Message-Id: <slrni7j3nj.fjh.tadmc@tadbox.sbcglobal.net>
Jürgen Exner <jurgenex@hotmail.com> wrote:
> joey@igetit.invalid wrote:
>>and I need to maintain syntactical
>>identity; hence, $h1_right, $h3_left,etc. It's much easier for me to
>>relate to $hn_side versus $sideh[0].
>
> Ahhhhh, now I see.
That's what I said when saw that description.
Pulling teeth is easier than getting an accurate description of
the structure of the data being processed, it would appear.
> Your real variable is $h. And you got 10 instances of
> those. And for each instance you got sides "left" and "right".
> And you tried to store all this valuable structural information in the
> variable name instead of constructing a proper data structure in the
> first place.
>
> What about using e.g.
> $h[4]{left}
> instead? Wouldn't that reflect what you are trying to express in the
> variable name?
I was going to say that.
But I'll just quote it instead, as a kind of "me too" thing.
> $h[4]{left} is how you access an element in an array of hashes, short
> AoH. More details see 'perldoc perldata'.
also:
perldoc perlreftut
perldoc perlref
perldoc perldsc
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Sat, 28 Aug 2010 20:04:49 -0700
From: Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>
Subject: Re: perldoc (was: Re: FAQ 5.23...)
Message-Id: <hbvok7x69c.ln2@goaway.wombat.san-francisco.ca.us>
On 2010-08-29, Xiong Changnian <xiong108@xuefang.com> wrote:
>
> But I would go further and abandon all attempt to *explain* Perl entirely
> in plain text. A subset of HTML is extremely widely supported.
The Perl docs are basically POD, and the other tools you mention
(perldoc, perldoc.perl.org, others) are generated from a POD parser.
And Pod::HTML is now part of core Perl, so you could imagine a "make
htmldoc" target that could convert all the Perl POD included in the core
to static HTML files for easy browsing, or imagine including a
perldoc2html script, suitable for a CGI environment, that could do this
on the fly. (Perhaps these things already exist in the Perl tarball,
even.)
Actually, it looks like static HTML files already exist: see the bottom
of http://perldoc.perl.org/index.html , as well as PDFs.
> For
> drawings, SVG is based on XML; there are many ways to view such files.
Does POD support including arbitrary content like SVG, with appropriate
parsers to handle and/or ignore as required? My impression is "not in
its current form", but might be something worth considering?
--keith
--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information
------------------------------
Date: Sun, 29 Aug 2010 04:38:51 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perldoc (was: Re: FAQ 5.23...)
Message-Id: <bb1pk7-k8m1.ln1@osiris.mauzo.dyndns.org>
Quoth Xiong Changnian <xiong108@xuefang.com>:
>
> I believe in documentation and I've created a lot of it. So, I'll venture
> an opinion.
You have some good points, so while my immediate reaction is to say
'whatever, go ahead and rewrite all the standard docs if you like, but
don't expect any help' I'll try to be more constructive... :) I
apologise for the length, but a fuller response seemed necessary.
> While there are excellent reasons for maintaining plain text
> documentation, the format is so limiting that it forces content into
> elaborate and difficult shapes. Nobody would attempt to document a
> machine part or microelectronic circuit without drawings.
>
> By 'drawings', I mean technical diagrams as opposed to photos or
> screenshots, which may be useful but rarely carry their weight. For one
> hardware project, I created about 10 pages of written documentation and
> an equal number of drawing pages; I added one page of photos and that was
> for management.
>
> Some types of software are amenable to a text-only treatment but others
> simply demand diagrams or figures. It is sheer pain to read a plain text
> explanation of how a graphics module works.
>
> Let's also contrast the pure plain text format with rich text that
> includes *bold*, /italic/, colors, headings, alignment, super- and
> subscripts, etc. Again, there are good reasons to avoid these
> elaborations; there are also good reasons to employ them. These are
> pertinent when a computer language is being explained; various levels of
> abstraction are best indicated with clear formatting.
>
> When I consult the standard documentation, I often do not use perldoc
> from a shell, despite it being faster and local. I point my browser to
> perldoc.perl.org. The text is easier to understand, even though the
> markup is generated from POD and the stylesheet applied universally. How
> much more so if human ability was at work?
When I first learned Perl, I did so principally by reading the Camel
book (and I mean actually *reading* it, cover to cover, at least twice),
and by reading through the ActiveState-provided CHM of the standard docs
(again, reading right through every document, though I skimmed the
sections that had been largely lifted into the Camel book). I will
freely admit that I found it a lot easier to absorb the information in
that form, with decent typography and formatting, than I would have
reading in an 80x25 monospace terminal window.
However, both of those were generated directly from POD. (The Camel book
was written in a slightly-expanded version of POD developed by
O'Reilly.) There has been talk, from time to time, of arranging for all
the standard docs and the perldocs of installed modules to be run off to
HTML, with a decent stylesheet and all the links working properly: if
you wanted to help make that a reality, I would consider it time well
spent.
Since POD already allows format-specific markup, it would be possible to
add diagrams where appropriate for the HTML version only; with some
effort it might be possible to do so without including HTML-specific
markup everywhere. Like you, when I'm learning a new module I tend to
stick to reading the HTML on search.cpan.org rather than the nroff-based
output from perldoc; I have on occasion been caught out when the docs I
was reading didn't correspond to the version of the module I had
installed, so having a local copy would be an advantage.
> I'd like to suggest that plain text perldoc might best be reserved for
> the formal technical reference. Somewhere in there should be an exact
> description of every language feature, option, limitation, and bug. It
> may not be easy to find or easy to understand but it is available to
> everyone, everywhere, on any system regardless of situation.
I have to admit, about the only standard docs I refer to any more are
perlfunc (via perldoc -f) when I've forgotten the arguments to a
builtin I don't use much, and perlapi when I'm writing XS, so I'd be
much more interested in seeing module documentation in HTML. It would
have to be done right, though, and with no effort on the user's part:
currently (or, at least, the last time I tried it) the output of
pod2html is not terribly pretty, and it's more effort than it's worth to
get the links to work properly.
One major advantage of POD as a documentation format is that it's no
harder to write than comments. Anyone who's written code that will be
read by someone else quickly gets into the habit of putting a block
comment before every function (more-or-less) explaining what it does,
what its arguments are, any gotchas, and so on. Writing that explanation
as POD instead of a comment is no work at all, and then since you've
started writing docs you're much more likely to go on and finish them.
Adding diagrams, at least with the tools we have now, is much harder:
the diagram ends up as either a big unreadable blob in the middle of
your source file, or in a separate file that (usually) needs a special
editor to modify. Neither is particularly likely to be kept up-to-date
when the code changes.
> But I would go further and abandon all attempt to *explain* Perl entirely
> in plain text. A subset of HTML is extremely widely supported. For
> drawings, SVG is based on XML; there are many ways to view such files.
> Both body text and drawings are encoded in human-readable plain text;
> degradation is as good as it can be.
Certainly diagrams can be helpful, under the right circumstances. Gisle
Aas' 'illguts' (now maintained by Reini Urban as the illguts
distribution on CPAN) is an excellent introduction to the perl guts, and
when I was first learning all that I found B::Graph indispensable.
Getting diagrams into the standard docs is likely to be a lot of work.
Unfortunately there is something of a tendancy on p5p to pick and pick
at any change to the standard docs (we are no less susceptible to the
lure of bikeshed arguments than anyone else; possibly more so, given the
sort of person who tends to enjoy Perl), meaning that the only changes
that tend to go in are indisputable bugfixes. If you're prepared to work
at it, though, it could probably be done.
> Nobody should say, 'You guys should do it this way'; I don't. I have
> considerable background in graphic design and the proper technical
> orientation: I eschew eye candy. My experience is too limited for me to
> play a major role but I will be delighted to put my shoulder to the
> wheel.
It sounds like your experience is perfect: if you make any technical
errors there are *more* than enough people who will be only too willing
to point them out to you (starting with me :)); what is needed here is
someone with the determination and the necessary broad vision to push
the changes through. Make no mistake, though: it would be a *lot* of
work. Probably it would be a lot of work before you even got a single
change committed to the core docs. But if you're up for the challenge it
would certainly be to everyone's advantage.
Ben
------------------------------
Date: Sun, 29 Aug 2010 04:42:18 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: perldoc (was: Re: FAQ 5.23...)
Message-Id: <qh1pk7-k8m1.ln1@osiris.mauzo.dyndns.org>
Quoth Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us>:
> On 2010-08-29, Xiong Changnian <xiong108@xuefang.com> wrote:
>
> > For
> > drawings, SVG is based on XML; there are many ways to view such files.
>
> Does POD support including arbitrary content like SVG, with appropriate
> parsers to handle and/or ignore as required? My impression is "not in
> its current form", but might be something worth considering?
POD currently supports =begin html blocks, which (obviously) contain
arbitrary HTML to be inserted only when generating HTML. They are not
much used, I suspect in part because most programmers find writing HTML
to be too much like hard work (I know I do).
Ben
------------------------------
Date: Sun, 29 Aug 2010 00:05:25 -0400
From: "Paul E. Schoen" <paul@pstech-inc.com>
Subject: Re: Writing or copying file to another directory
Message-Id: <c0leo.27974$yr6.25892@newsfe05.iad>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote in message
news:867hjdw1xl.fsf@red.stonehenge.com...
>>>>>> "Ben" == Ben Morrow <ben@morrow.me.uk> writes:
>
> Ben> I think the Open Source movement might have an issue with this
> Ben> assertion...
>
> Nope. The Open Source movement says the same thing. If bad guys can
> see the source, they can break it easier.
>
> The Open Source movement offsets this with, "but if the good guys can
> also see it, and FIX it, then the risk is appropriately mitigated."
>
> print "Just another Perl hacker,"; # the original
Just to let you know I have fixed the perl script so that it no longer shows
errors using strict and warnings. I am concerned about security especially
now that I have FTP access to the Sierra Club server. For now I just have
links to the web page on my server, as "under construction", and that page
links to the CGI mailer.pl script also on my server which emails the
information to me and also converts it to HTML and copies it to a file.
I have the permissions on these files as 777 but I probably want to remove
the write and possibly the read permissions in the cgi-bin folder. Does an
executable script, accessed by anyone through a link in the web page, have
write permission to files with permission set at, for example, 700? And
should the mailer.pl script have permission 711 to keep anyone other than
myself from reading or writing it?
My problems were mostly because of the host configuration, and the sys admin
told me that it was set up as a "jail" which restricted access. I do believe
it is running SUEXEC. Hopefully now I will not need to deal with those
issues and I will need to balance my efforts between the HTML with
JavaScript on one hand, with the CGI perl script on the other. Since I may
not have the time and enthusiasm to become proficient in perl I may try to
do as much processing as possible in the JavaScript of the HTML document,
although it may be better suited to server side scripting.
Thanks for all your help and patience. I was amused "joey's" thread on the
simple loop.
Paul
www.pstech-inc.com
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3104
***************************************
