[26378] in Perl-Users-Digest
Perl-Users Digest, Issue: 8550 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Oct 20 21:05:26 2005
Date: Thu, 20 Oct 2005 18:05:04 -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 Thu, 20 Oct 2005 Volume: 10 Number: 8550
Today's topics:
How to pass lock to the parent process? <h.b.furuseth@usit.uio.no>
Re: How to pass lock to the parent process? xhoster@gmail.com
Re: How to pass lock to the parent process? <h.b.furuseth@usit.uio.no>
Re: Microsoft Hatred FAQ <mscottschilling@hotmail.com>
Re: why the perl docs suck <Fred@fred.net>
Re: why the perl docs suck <Fred@fred.net>
Re: why the perl docs suck <Fred@fred.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 21 Oct 2005 02:10:41 +0200
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Subject: How to pass lock to the parent process?
Message-Id: <hbf.20051021wfl3@bombur.uio.no>
I need a to pass a file lock to the parent process - and
to detect that this works.
The best answer would be passing a file descriptor through a socket, but
I couldn't find how to do that with Perl.
Another way is to open() the file in the parent and flock() it in the
child - that works on my host, but I don't know how to test reliably if
it works. Perl can use either the C system call flock(), lockf() or
fcntl() for file locks, and I don't even know if it is reliable for the
flock() system call.
use Fcntl qw(:flock);
open(LK, "+>/tmp/foobar.lock") or die;
unless (fork()) {
# Child
flock(LK, LOCK_EX) or die;
exit(0);
}
# Parent
wait; die if $?;
# LK is locked
--
Hallvard
------------------------------
Date: 21 Oct 2005 00:32:34 GMT
From: xhoster@gmail.com
Subject: Re: How to pass lock to the parent process?
Message-Id: <20051020203234.613$1s@newsreader.com>
Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote:
> I need a to pass a file lock to the parent process - and
> to detect that this works.
Why? If the parent needs the lock, why not have the parent lock it?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: Fri, 21 Oct 2005 02:41:10 +0200
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Subject: Re: How to pass lock to the parent process?
Message-Id: <hbf.20051021vx8w@bombur.uio.no>
xhoster@gmail.com writes:
>Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote:
>> I need a to pass a file lock to the parent process - and
>> to detect that this works.
>
> Why? If the parent needs the lock, why not have the parent lock it?
Well, that's another way. But there are several children. Each should
start processing as soon as its lock can be acquired. I don't want to
need to go through the whole program to make it thread-safe, so the
parent can just wait for one file lock at a time - at least if it uses
flock().
--
Hallvard
------------------------------
Date: Thu, 20 Oct 2005 22:07:51 GMT
From: "Mike Schilling" <mscottschilling@hotmail.com>
Subject: Re: Microsoft Hatred FAQ
Message-Id: <XyU5f.5227$tV6.3045@newssvr27.news.prodigy.net>
"Steven D'Aprano" <steve@REMOVETHIScyber.com.au> wrote in message
news:pan.2005.10.20.13.46.50.253609@REMOVETHIScyber.com.au...
> On Thu, 20 Oct 2005 13:17:14 +0000, axel wrote:
>
>> Employees have *no* obligations towards the shareholders of a company.
>> They are not employed or paid by the shareholders, they are employed
>> by the company itself which is a separate legal entity.
>>
>> It is a different matter for the board of directors of a company.
>
> The board of directors are also employees of the company. That's why the
> company can fire them.
The relationships are a bit more complex than that:
The shareholders elect a Board of Directors to represent their interests.
The board then hires a management staff, which reports to them. The
management staff hires other employees, who report (directly or indirectly)
to management.
An employee who refuses to act as directed, claiming that he's thinking of
the shareholders' interests, can be fired for cause. His only recourse
would be to become a shareholder (not hard), and then get the attention of
either the board or a large block of shareholders (much harder). If
management is actually breaking the law (say by Enron-like looting) rather
than simply making decisions he considers suboptimal, he can also go to the
authorities, but he does this in his capacity as private citizen; his status
as employee gives him no additional rights or responsibilities in this
respect.
As Axel says, a regular employee has no direct obligations towards the
shareholders.
------------------------------
Date: Thu, 20 Oct 2005 18:11:29 -0500
From: "Fred@fred.net" <Fred@fred.net>
Subject: Re: why the perl docs suck
Message-Id: <c98gl1ll4t7v682lkgq72fbjljnvno7p04@4ax.com>
On 20 Oct 2005 11:40:50 GMT, Robert Sedlacek <phaylon@dunkelheit.at>
wrote:
>Fred@fred.net <Fred@fred.net> wrote
>
>> Imagine a world without rules.... it's not as ridiculous as it sounds.
>> One of my favorite quotes is:
>
>I'm sorry to inform you that Mr. Crowley meant someones individual higher
>will, also personalized in the Holy Guardian Angel.
>
>Love is the Law, Love under Will.
>
>
>p
Ah, an educated man. He said that after, much later and after, the
original writing.
From the web:
<WEB_SNIP>
The Book of the Law is heavy on poetry, but light on theology. It
generally encourages a libertine approach to life, the use of "strange
drugs" and various obscure adjurations like "Let my servants be few &
secret" and "Choose ye an island!"
Crowley would maintain throughout his life that "Do what thou wilt"
was not intended as a blanket permission for all sorts of depraved
behavior , but rather an instruction that people should learn and
discover their "true wills", the important works and desires of their
lives, and follow through on them.
</WEB_SNIP>
Fred: Implicit in this is the notion that whatever you seek, one
should be allowed that pursuit. Hence the admonishment to "do as thou
wilt".
The entire notion of Thelema exists between the lines: "Do what thou
wilt shall be the whole of the law," and "Love is the law, love under
will."
Fred
------------------------------
Date: Thu, 20 Oct 2005 18:38:16 -0500
From: "Fred@fred.net" <Fred@fred.net>
Subject: Re: why the perl docs suck
Message-Id: <oa9gl19o7r5bj8flvkn5e2gkmvi1gf1egt@4ax.com>
On Thu, 20 Oct 2005 15:29:16 -0000, "David K. Wall"
<darkon.tdo@gmail.com> wrote:
>Fred@fred.net <Fred@fred.net> wrote:
>
>> I submit for consideration of everyone or no one that the
>> guidelines for posting to this ng are so restrictive that deciding
>> whether a certain post should be or should not be made is more
>> tedious than solving the problem on one's own?
>
>No. I've often run into problems when writing a Perl program and
>thought of asking for help here. In the process of isolating the
>problem enough to post a short but self-contained piece of code that
>exhibits the problem I'm having, then explaining what I wanted to
>happen versus what actually happened, I almost always find the source
>of the problem on my own.
That is exactly in the spirit of what I was trying to say.
> I don't reread the guidelines every time I
>have a question, I just try to write the sort of post *I* would want to
>read. Pretty simple, really -- the guidelines are just a summary of
>common sense and courtesy.
The are large holes in the guidlines.
For example, let's say I've been using perl for 1 year,daily. I might
want to ask a question here about a way of doing somthing, and as such
have no code to post. I haven't tried anything becuase I am stuck.
Sort a hash on keys as well as values. That stuck me for a little
while.
I could have asked the question straight away... here... and got
flamed:
1. What, is this your homework??? LOSER!!!
2. Hey buddy, RTFM, ya know???????
3. This ain't a "code for free" service!
And so, right off the bat, benn in violation of the guidlines. And
have nasty replies to boot.
That's my issue.
Ladies, if you like the heat, stay in the kitchen.
>
>To repeat: following the guidelines will teach you -- if you don't
>already know -- an approach to finding answers for yourself, a skill
>more valuable than the answer to any specific question.
Again I assert a legitimate post would not have to include source
code. They may be asking for ideas only, being well acquainted with
perl syntax and control structures and references, etc, et al.
If YOU cannot ascertain the skill of the user in the first glance at a
post, you haven't been here long enough. There are tons of posts I
never read due to the poor formulation of the subject. And I reject
the notion entirely that erroneous answers are the bane of the ng, as
has been opined, they are typically linked to stupid posts (Dumb
subject line) to begin with and are therefore easily avoided.
Fred
------------------------------
Date: Thu, 20 Oct 2005 19:02:02 -0500
From: "Fred@fred.net" <Fred@fred.net>
Subject: Re: why the perl docs suck
Message-Id: <uobgl11dggs1944kofqfuq902tvjkp8plr@4ax.com>
On 20 Oct 2005 14:47:18 GMT, Eric Bohlman <ebohlman@omsdev.com> wrote:
>"Fred@fred.net" <Fred@fred.net> wrote in
>news:otldl1tcn1olhcmovghrih3t0j953i9nml@4ax.com:
>
>> Imagine a world without rules.... it's not as ridiculous as it sounds.
>> One of my favorite quotes is:
>>
>> "Do what thou wilt shall be the whole of the law."
>
>Belief systems that incorporate such ideas usually qualify that sort of
>statement with provisos that one's conduct not harm others.
>
>An example of newsgroup conduct that does in fact harm others is the
>asking of simple FAQs. When that happens, the people on the group who
>know what they're talking about face a dilemma. Do they
>
>1) Waste their time (which is usually part of their spare time) answering
>the FAQ? If so, they have less time available to help people with
>questions that can't be answered simply by reading the manual and that
>require actual expertise. Harm's been done, as a valuable resource has
>been made less available.
>
>2) Ignore the post? If so, the history of this group shows that people
>who don't know what they're talking about will chime in and give
>incorrect or seriously incomplete answers. Harm's been done, as the
>group has become a conduit for misinformation.
>
>> I submit for consideration of everyone or no one that the guidelines
>> for posting to this ng are so restrictive that deciding whether a
>> certain post should be or should not be made is more tedious than
>> solving the problem on one's own?
>
>I can only wonder if you're reading the same guidelines as I am.
I would disagree to:
>2) Ignore the post? If so, the history of this group shows that people
>who don't know what they're talking about will chime in and give
>incorrect or seriously incomplete answers. Harm's been done, as the
>group has become a conduit for misinformation.
As I have stated before, a person familiar with this ng can spot an
idiot subject line, from 10 miles off. So, if 'they' draw friendly
fire in the form on incorrect replies it's entirely appropriate.
That's my point. Ignore.
Fred
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8550
***************************************
