[31618] in Perl-Users-Digest
Perl-Users Digest, Issue: 2877 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 16 06:09:54 2010
Date: Tue, 16 Mar 2010 03:09:07 -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 Tue, 16 Mar 2010 Volume: 11 Number: 2877
Today's topics:
Re: Asynchronous TCP Socket Connect <hjp-usenet2@hjp.at>
Re: Best Perl compiler, IDE for Win XP, 32bit <FW3006@sbcglobal.net>
Re: Best Perl compiler, IDE for Win XP, 32bit <bart.lateur@telenet.be>
Re: check for file in $PATH <m0t0rbr3th@gmail.com>
Re: Fast way to fill memory <xhoster@gmail.com>
Posting Guidelines for comp.lang.perl.misc ($Revision: tadmc@seesig.invalid
Re: to RG - Lisp lunacy and Perl psychosis <rNOSPAMon@flownet.com>
Re: to RG - Lisp lunacy and Perl psychosis <hjp-usenet2@hjp.at>
Re: to RG - Lisp lunacy and Perl psychosis <rNOSPAMon@flownet.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 15 Mar 2010 23:14:43 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Asynchronous TCP Socket Connect
Message-Id: <slrnhptcaj.is.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-13 13:09, Martijn Lievaart <m@rtij.nl.invlalid> wrote:
> On Fri, 12 Mar 2010 14:39:10 -0800, Jim Gibson wrote:
>>> This is not a Perl question, You are looking for non-blocking sockets.
>>> Whole volumes have been written about this, but best is Stevens "Unix
>>> Network Programming".
>>
>> But asking how to do it in Perl _is_ a Perl question. Alas, I do not
>> know the answer. :(
>
> If you know the concept, the Perl solution is obvious, as Perl just
> exposes the same API.
I disagree. The IO::Socket API (unlike the builtin functions) is
sufficiently abstracted from the system call level that the answer how
to do something is not always obvious.
> Rhe short answer is to set all your sockets to non-blocking, then use a
> select() loop to determine which handle is ready.
But that wasn't the question. The question was how to set the socket to
non-blocking.
hp
------------------------------
Date: Mon, 15 Mar 2010 18:57:42 -0700 (PDT)
From: 2007 <FW3006@sbcglobal.net>
Subject: Re: Best Perl compiler, IDE for Win XP, 32bit
Message-Id: <93f8d692-2533-40e3-88c3-f13669d94337@p3g2000pra.googlegroups.com>
On Mar 14, 8:23=A0pm, Pradeep <p...@ockham.be> wrote:
> On Mar 15, 3:26=A0am, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > Quoth 2007 <FW3...@sbcglobal.net>:
>
> > > I am looking for Perl compiler and possibly an IDE.
>
> > > I have used Active Perl before and was fine with it. =A0I was searchi=
ng
> > > online and there was a recommendation for an IDE too. =A0Then there
> > > seems other IDEs too (Open Perl IDE =A0and Eclipse IDE - which one?).
>
> > > So too many to choose from - any guidance?
>
> > Padre is supposed to be very good nowadays. (I haven't used it myself,
> > but I'm not an IDE person.)
>
> > Ben
>
> Padre is progressing fine for final release and I hope it will have
> great future. I have tried many, but currently I am using Geany.
>
> Pradeep
I checked Padre:
>> The Padre Standalone package contains
>> * Strawberry Perl 5.10.1.1
>> * Padre 0.56 (also reports a bug on it)
Any comments on Strawberry Perl as opposed to Active Perl - I know the
latter doesn't have IDE.
------------------------------
Date: Tue, 16 Mar 2010 08:58:13 +0100
From: Bart Lateur <bart.lateur@telenet.be>
Subject: Re: Best Perl compiler, IDE for Win XP, 32bit
Message-Id: <l4eup59a383vhmpb6pbou263i8c14abske@4ax.com>
2007 wrote:
>Any comments on Strawberry Perl as opposed to Active Perl - I know the
>latter doesn't have IDE.
The core of Perl for both is the same. There's a difference in user
experience, but the difference is not huge, IMHO.
And do not overestimate the importance of an IDE for Perl. Most people
get along just fine with just a test editor; if you can easily invoke
Perl on your current script and capture its output into an editor
windows, you're basically set.
The reason why Strawberry Perl was originally developed is in order to
easily install modules, even more difficult ones, and especially the
modules wrritten in C. But since then, ActivePerl added support for
other C compilers than the one it was originally built with (i.e.
Miscrosoft Visual C), so now you can easily use MinGW instead: all you
have to do is install MinGW, make sure it's in PATH, and ActivePerl will
find it.
Strawberry Perl includes that C compiler. So you have to do fewer things
yourself before you can get to work.
--
Bart.
------------------------------
Date: Mon, 15 Mar 2010 19:32:42 -0700 (PDT)
From: "m!thun" <m0t0rbr3th@gmail.com>
Subject: Re: check for file in $PATH
Message-Id: <b2ffb5b5-69b7-4fb1-a7b4-e0db33a401f3@30g2000yqi.googlegroups.com>
On Mar 15, 3:46=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth "Paul Hovnanian P.E." <p...@hovnanian.com>:
>
> > cerr wrote:
>
> > > My perl script depends on a binary that may be in $PATH and i would
> > > like to check for that file. How can I verify if the file is present
> > > in $PATH without hard coding a full path?
>
> > No need to hardcode $PATH in your app. Just get it from %ENV as $ENV{PA=
TH}.
>
> > So
>
> > sub fnd {
> > =A0 =A0my ($f) =3D @_;
> > =A0 =A0foreach my $p (split /:/, $ENV{PATH}) {
>
> Use File::Spec->path here, or some wrapper. Not all platforms use a
> :-separated PATH, and not all platforms call the pertinant env var 'PATH'=
.
>
> > =A0 =A0 =A0return "$p/$f" if( -x "$p/$f" );
>
> Ditto: File::Spec->catfile, or a wrapper like Path::Class (highly
> recommended).
>
> Ben
I've been using File::Which. I think this is more portable and usable
than the other modules mentioned here.
------------------------------
Date: Mon, 15 Mar 2010 19:10:23 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Fast way to fill memory
Message-Id: <4b9ee690$0$10781$ed362ca5@nr5-q3a.newsreader.com>
Oliver 'ojo' Bedford wrote:
> Hi!
>
> For testing purposes I would like to fill chunks of memory (say 20M) with
> arbitrary data (say bytes with values 1,2,...255,1,...).
>
> What would be the fastest method?
>
> Oliver
Why do you need the fastest way to do it? What would happen if you used
a method that was merely fast enough?
You should probably fill the memory in a way that is similar to the way
it would be filled in the situation you are constructing the test to
test. For example, by repeated linear .=, or by repeated exponential
.=, or by x operator.
Xho
------------------------------
Date: Tue, 16 Mar 2010 02:13:57 -0500
From: tadmc@seesig.invalid
Subject: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
Message-Id: <PrCdnR0ada0osgLWnZ2dnUVZ_jSdnZ2d@giganews.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.9 $)
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_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.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: Mon, 15 Mar 2010 15:23:49 -0800
From: RG <rNOSPAMon@flownet.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <rNOSPAMon-F30374.15234915032010@news.albasani.net>
In article <slrnhpt9hi.is.hjp-usenet2@hrunkner.hjp.at>,
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
> On 2010-03-12 05:04, Ron Garret <rNOSPAMon@flownet.com> wrote:
> > In article <slrnhpisqf.i4n.hjp-usenet2@hrunkner.hjp.at>,
> > "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
> >
> >> In any case I very much doubt that it is much easier to find the bug in
> >> a lisp program which "suddenly started failing silently and
> >> intermittently" than in a Perl program which does the same.
> >
> > I assure you, you are quite mistaken. I have a first-hand data point on
> > that as well:
> >
> > http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf
>
> Interesting paper.
>
> But I don't think it proves your point.
>
> 1) Perl isn't mentioned at all
So? I was responding to a claim you made about Lisp.
> so you cannot draw any conclusions about
> Perl from the paper (neither negative nor positive).
Not from that paper in isolation. But I cited that paper within a
conversational context. Do I need to review it for you?
> 2) The verification tool mentioned doesn't work on Lisp input, but uses
> a specialized modelling language called PROMELA.
That is completely beside the point. The relevant part of the paper is
section 2.3. It has nothing to do with Promela.
> 3) Then the authors built an automated translation tool, but again it
> doesn't translate Lisp to PROMELA, it translates (a subset of) Java
> to PROMELA. So, again, they had to hand-translate Lisp to Java, which
> could then be automatically processed. At least translating Lisp to
> Java was very quick (two hours!) but that may be because
>
> Some of us spotted the potential error situation because it
> resembled the similar error we had found using SPIN in 1997[...]
>
> and the subsequent
>
> focus on the particular code fragment
>
> The error is a text-book example of a race-condition, btw. It is
> discussed in almost identical form in any systems programming class,
> and they could have spotted it because of that and not just because
> the encountered it before.
>
> 4) The RAX team found the error within 24 hours, the JPF team within
> 48 hours (but they also had identified the code fragment as
> suspicious within 12 hours).
>
> In conclusion, there is nothing in the paper which suggests that Lisp in
> particularly easy to model. If anything, they seem to suggest that Java
> is easy to model, although I suspect that "shrinking down" real world
> Java programs to a manageable complexity is still non-trivial, even with
> the help of their abstraction tool.
>
> That two independent teams each found the race condition within less
> than two days is impressive. That may be a hint that Lisp makes it
> relatively easy to spot that kind of error. But without more knowledge
> about the specific case and a direct comparison to other programming
> languages it isn't conclusive.
I didn't say it was conclusive, I said it was a data point.
But FWIW, there are sound theoretical reasons to believe that Lisp
programs are easier to debug than Perl programs, mainly because Lisp has
a REPL and Perl (normally) does not.
But I really don't feel like arguing about this. If you think it's
easier to debug Perl than Lisp then go for it.
rg
------------------------------
Date: Tue, 16 Mar 2010 00:06:36 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <slrnhptfbt.je0.hjp-usenet2@hrunkner.hjp.at>
On 2010-03-15 23:23, RG <rNOSPAMon@flownet.com> wrote:
> In article <slrnhpt9hi.is.hjp-usenet2@hrunkner.hjp.at>,
> "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>> On 2010-03-12 05:04, Ron Garret <rNOSPAMon@flownet.com> wrote:
>> > In article <slrnhpisqf.i4n.hjp-usenet2@hrunkner.hjp.at>,
>> > "Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
>> >> In any case I very much doubt that it is much easier to find the bug in
>> >> a lisp program which "suddenly started failing silently and
>> >> intermittently" than in a Perl program which does the same.
>> >
>> > I assure you, you are quite mistaken. I have a first-hand data point on
>> > that as well:
>> >
>> > http://ti.arc.nasa.gov/m/pub/archive/2000-0176.pdf
>>
>> Interesting paper.
>>
>> But I don't think it proves your point.
>>
>> 1) Perl isn't mentioned at all
>
> So? I was responding to a claim you made about Lisp.
I made a claim about the relative merits of Lisp *and* Perl.
>> so you cannot draw any conclusions about
>> Perl from the paper (neither negative nor positive).
>
> Not from that paper in isolation. But I cited that paper within a
> conversational context. Do I need to review it for you?
I could use the same condescending tone you use, but I won't.
>> 2) The verification tool mentioned doesn't work on Lisp input, but uses
>> a specialized modelling language called PROMELA.
>
> That is completely beside the point. The relevant part of the paper is
> section 2.3. It has nothing to do with Promela.
You didn't say what the relevant part of the paper was. You should
expect that when you cite a paper as support of your claims that one
assumes that the topic of the paper has something to do with your claim.
However, I noticed section 2.3:
>> 4) The RAX team found the error within 24 hours, the JPF team within
>> 48 hours (but they also had identified the code fragment as
>> suspicious within 12 hours).
[...]
>> That two independent teams each found the race condition within less
>> than two days is impressive. That may be a hint that Lisp makes it
>> relatively easy to spot that kind of error. But without more knowledge
>> about the specific case and a direct comparison to other programming
>> languages it isn't conclusive.
>
> I didn't say it was conclusive, I said it was a data point.
But without knowing more about the case and a comparison to other
languages you really can't say whether finding the bug within a day was
fast or slow. I've found similar bugs in C programs within 5 minutes, so
I could claim that C is much easier to debug than Lisp (omitting the
important facts that the C programs where rather short (a few hundred
lines) and were written by students in a systems programming course
(so I expected race conditions and was specifically looking for them)).
> But FWIW, there are sound theoretical reasons to believe that Lisp
> programs are easier to debug than Perl programs, mainly because Lisp has
> a REPL and Perl (normally) does not.
A REPL[1] doesn't help you much finding race conditions or bugs that cause
the program to "start failing silently and intermittently". So it is
moot for the two cases you mentioned. It can be very helpful in other
cases, though.
> But I really don't feel like arguing about this. If you think it's
> easier to debug Perl than Lisp then go for it.
I didn't say that Perl is easier to debug than Perl. I said I doubt that
Lisp is much easier to debug than Perl. There is a slight difference
which you should be able to spot.
hp
[1] The Perl module Devel::REPL is on the first page of Google results
when you search for "REPL".
------------------------------
Date: Mon, 15 Mar 2010 17:55:59 -0800
From: RG <rNOSPAMon@flownet.com>
Subject: Re: to RG - Lisp lunacy and Perl psychosis
Message-Id: <rNOSPAMon-2A692B.17555915032010@news.albasani.net>
In article <slrnhptfbt.je0.hjp-usenet2@hrunkner.hjp.at>,
"Peter J. Holzer" <hjp-usenet2@hjp.at> wrote:
> I could use the same condescending tone you use, but I won't.
But then of course you do:
> I didn't say that Perl is easier to debug than Perl. I said I doubt that
> Lisp is much easier to debug than Perl. There is a slight difference
> which you should be able to spot.
Frustration can drive even the best among us to snarkiness.
Look, I understand what you were saying the first time you said it. But
I disagree with you: I think Lisp is easier to debug than Perl. I have
two data points and one theoretical argument to support my position, but
no hard proof. I might be wrong. But all the evidence I have at my
disposal indicates to me that I am not.
BTW, I disagree with this too:
> A REPL[1] doesn't help you much finding race conditions or bugs that cause
> the program to "start failing silently and intermittently".
A REPL can be very useful in debugging such problems. Having a REPL
aboard DS1 was invaluable in finding and fixing the RAX bug. And
there's another data point in the NASA lore to support this point of
view: there was a similar problem with the Pathfinder Rover that was
found and fixed using a virtually identical process. In this case the
software was written in C, but there was nonetheless a REPL because the
C code was running under vxWorks, which provides a shell that, while not
a full REPL, provides much of the same functionality.
If you have some actual evidence or theoretical arguments to support
your position let's hear them. All I've heard from you so far is
unsupported assertions and arguments of the form, "You haven't proven X,
therefore X is not true." If that's all you've got we'll just have to
agree to disagree.
rg
------------------------------
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 2877
***************************************
