[31805] in Perl-Users-Digest
Perl-Users Digest, Issue: 3068 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 9 16:09:24 2010
Date: Mon, 9 Aug 2010 13:09:06 -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 Mon, 9 Aug 2010 Volume: 11 Number: 3068
Today's topics:
Re: Help with threads <NoSpamPleaseButThisIsValid3@gmx.net>
Re: Help with threads sln@netherlands.com
Re: Help with threads <a@a.com>
Re: Makefile.PL / ExtUtils::MakeMaker refuses to pick u <nospam-abuse@ilyaz.org>
Re: Question re calling subroutines <kst-u@mib.org>
Re: Question re calling subroutines <uri@StemSystems.com>
Re: Question re calling subroutines <tadmc@seesig.invalid>
Re: sysopen failures <marc.girod@gmail.com>
Re: sysopen failures <marc.girod@gmail.com>
Re: sysopen failures <ben@morrow.me.uk>
Re: sysopen failures <hjp-usenet2@hjp.at>
Re: sysopen failures <m@rtij.nl.invlalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 09 Aug 2010 10:25:29 +0200
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: Re: Help with threads
Message-Id: <4c5fbb7a$0$7655$9b4e6d93@newsspool1.arcor-online.net>
On 08.08.2010 21:40, sln@netherlands.com wrote:
> The while condition has to be protected as well.
> Something like a while(1) condition then:
... whatever else needs locking. It is easy to forget some locking
somewhere.
So my suggestion is to
use Thread::Queue;
then enqueue all svg filenames in a queue. Now create threads which
convert files while dequeue_nb retuns a filename.
Wolf
------------------------------
Date: Mon, 09 Aug 2010 04:41:02 -0700
From: sln@netherlands.com
Subject: Re: Help with threads
Message-Id: <f6qv565oltb9tsppr2murmas2i7ea5gq9d@4ax.com>
On Mon, 09 Aug 2010 10:25:29 +0200, Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net> wrote:
>On 08.08.2010 21:40, sln@netherlands.com wrote:
>> The while condition has to be protected as well.
>> Something like a while(1) condition then:
>
>... whatever else needs locking. It is easy to forget some locking
>somewhere.
>
>So my suggestion is to
>use Thread::Queue;
>
>then enqueue all svg filenames in a queue. Now create threads which
>convert files while dequeue_nb retuns a filename.
>
>Wolf
Of course, but the OP is taking small steps first.
-sln
------------------------------
Date: Mon, 09 Aug 2010 19:28:35 +0700
From: michael20545 <a@a.com>
Subject: Re: Help with threads
Message-Id: <i3os9m$2lus$1@adenine.netfront.net>
Thank you Martin, Willem, sln, Wolf for your replies,
but I found that Inkscape does not work (at least on Windows) in
multiple instances :(
But your suggestions were useful for creating graphs with gnuplot (11
vs 27 seconds for creating 215 graphs).
Here is the last version (thanks Wolf for suggestion to use Thread::Queue).
use strict;
use threads;
use threads::shared;
use Thread::Queue;
my @files=<*.gp>;
my $q=new Thread::Queue;
$q->enqueue($_) for @files;
my @threads;
push @threads,threads->new(\&make_svg,$_) for 1..3;
$_->join for @threads;
sub make_svg
{
my $thrnum=$_[0];
while(my $file=$q->dequeue_nb)
{
print "$thrnum $file\n";
`gnuplot $file`;
}
}
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
------------------------------
Date: Mon, 9 Aug 2010 19:57:09 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Makefile.PL / ExtUtils::MakeMaker refuses to pick up files in /bin
Message-Id: <slrni60ncl.mma.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-08-05, Klaus <klaus03@gmail.com> wrote:
>> > unless ($^O eq 'MSWin32' or $^O eq 'linux') {
>> > die "Error-0010: File::Vctools can only run on \$^O = 'MSWin32' or
>> > 'linux', but found \$^O = '$^O'";
>> > }
>>
>> Why do you think so?!
>
> Well, the package "File::Vctools" installs some *.pl scripts that in
> turn, generate other *.pl scripts, these "other" *.pl scripts call
> system() with slashes (on Linux) or backslashes (on Windows) as a
> directory separator.
And system() calls WHAT? If used correctly [*], paths with slashes work
fine on Windows. As they do on hundreds of other OSes...
[*] Paths SHOULD be *quoted* (unless multi-arg system() is used)
anyway, right?
[If you KNOW that your system() uses some (broken) program which
bulks on /-paths on Windows, you can use \ on Windows, and /
otherwise. This would cover all but a handful of OSes.]
> It is difficult to control what separator has to be used. I managed to
> test successfully on Linux and on Windows, but I don't have any other
> operating system available, so guessing what separator works for which
> other operating system would certainly be a waste of testers time
> (even if it is just an automated test / test smoker)
Using catdir()/catfile() is bullet-proof, but one may need to get used
to the idea that directories and files may "live in different
namespace worlds".
Yours,
Ilya
------------------------------
Date: Mon, 09 Aug 2010 12:46:21 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Question re calling subroutines
Message-Id: <lnd3tr1sdu.fsf@nuthaus.mib.org>
"Uri Guttman" <uri@StemSystems.com> writes:
>>>>>> "H" == HerbF <HerbF@earthlink.net> writes:
> H> I typically call subroutines without using parenthesis, e.g., &abc;. I
> H> have one routine where I pass variables and I call it as:
>
> that is poor perl code and perl4 style. don't use & for sub calls as it
> has side effects you may not know about. read perldoc perlsub for more.
>
> H> Should I be using parenthesis at the subroutine, i.e.,
>
> H> sub abc (A,B,C) {...}
>
> that has nothing to do with parens at the sub call itself. perl doesn't
> support named arguments like you have there so it won't do any good to
> try it.
>
> sub calls should be made with parens is the common style rule and not
> with &.
I tend to omit parentheses in many cases where they're not necessary.
For example, I might write:
sub Foo;
...
my $x = Foo 42; # rather than Foo(42)
...
sub Foo {
my($arg) = @_;
return $arg + 1;
}
Would you consider this to be a bad habit? (I don't use "&" on
calls, and I've broken my previous habit of using prototypes.)
I know that parentheses are necessary for something like:
print "Foo 42 = ", Foo(42), "\n";
because without them the "\n" is passed to Foo, not to print.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Mon, 09 Aug 2010 16:00:06 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Question re calling subroutines
Message-Id: <87zkwv36bd.fsf@quad.sysarch.com>
>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
KT> I tend to omit parentheses in many cases where they're not necessary.
KT> For example, I might write:
KT> sub Foo;
KT> ...
KT> my $x = Foo 42; # rather than Foo(42)
KT> ...
KT> sub Foo {
KT> my($arg) = @_;
KT> return $arg + 1;
KT> }
that only works if you declare Foo before you call it. perl can't tell
if a bareword is a sub if it hasn't seen it before unless you use parens.
look at these examples which show why always using parens is a good thing:
perl -we 'sub foo {print "hello\n" } ; foo'
hello
perl -we 'foo; sub foo {print "hello\n" }'
Unquoted string "foo" may clash with future reserved word at -e line 1.
Useless use of a constant in void context at -e line 1.
perl -we 'foo(); sub foo {print "hello\n" }'
hello
KT> Would you consider this to be a bad habit? (I don't use "&" on
KT> calls, and I've broken my previous habit of using prototypes.)
yes, as i show above. btw, predeclaring also works for exported subs
from a module. still i use parens. only with protoyped subs that need to
look like builtins might i skip the parens.
KT> I know that parentheses are necessary for something like:
KT> print "Foo 42 = ", Foo(42), "\n";
KT> because without them the "\n" is passed to Foo, not to print.
that is a precedence issue, not a predeclared one. if Foo were
predeclared with a prototype of a single arg, the parens wouldn't be
needed and it would work.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Mon, 09 Aug 2010 15:00:49 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Question re calling subroutines
Message-Id: <slrni60nds.tgq.tadmc@tadbox.sbcglobal.net>
Keith Thompson <kst-u@mib.org> wrote:
> "Uri Guttman" <uri@StemSystems.com> writes:
>>>>>>> "H" == HerbF <HerbF@earthlink.net> writes:
>> H> I typically call subroutines without using parenthesis, e.g., &abc;. I
>> H> have one routine where I pass variables and I call it as:
>>
>> that is poor perl code and perl4 style. don't use & for sub calls as it
>> has side effects you may not know about. read perldoc perlsub for more.
>>
>> H> Should I be using parenthesis at the subroutine, i.e.,
>>
>> H> sub abc (A,B,C) {...}
>>
>> that has nothing to do with parens at the sub call itself. perl doesn't
>> support named arguments like you have there so it won't do any good to
>> try it.
>>
>> sub calls should be made with parens is the common style rule and not
>> with &.
>
> I tend to omit parentheses in many cases where they're not necessary.
> For example, I might write:
>
> sub Foo;
> ...
> my $x = Foo 42; # rather than Foo(42)
> ...
> sub Foo {
> my($arg) = @_;
> return $arg + 1;
> }
>
> Would you consider this to be a bad habit?
I would consider that a bad habit with regard to user-defined functions.
I usually omit parens for builtin functions.
I just object to the need for the forward declaration, which is not
needed if you use parens in the function call.
A weak reason, I'll admit.
--
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, 9 Aug 2010 04:50:35 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: sysopen failures
Message-Id: <1b671d72-edaf-41aa-8edb-1926a7c88f99@g33g2000yqc.googlegroups.com>
On Aug 7, 1:10=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> If the network filesystem doesn't support O_EXCL, then the open will
> succeed even though it shouldn't (or it will fail every time with
> EINVAL), it won't fail when the file doesn't exist.
Thanks.
> No. sysopen is the closest you can get to the OS.
OK.
> Yes. Most likely causes are IMHO:
>
> =A0* The file really exists at the time. You have to find out why
> =A0 =A0(maybe your script is supposed to remove the file before it
> =A0 =A0terminates and it either doesn't do it or a previous invocation
> =A0 =A0hasn't finished yet). If you know why the solution is probably
> =A0 =A0obvious.
> =A0* The file did exist and has already been removed at the time the
> =A0 =A0script runs, but the information about the file's existence is sti=
ll
> =A0 =A0cached by the OS. In this case you should check the configuration =
of
> =A0 =A0the file system (on both the client and the server).
Well, I have to figure out how either could be possible.
I cannot see what in the code could remove anything...
Those files are left to be accessible from a web page.
There is a loop which increments a digit in the file name and tries
100 times.
I don't think this is very smart, but I cannot see how the 100
different files could exist.
The error returned in the end is of course only the one for the last
try.
So that I don't *know* why the 99 first attempts failed.
But in the general case, I cannot find the 100th file either.
I may leave this for a while: I have more urgent, and the symptom has
stopped for now.
But I don't doubt it will come back.
Thanks.
Marc
------------------------------
Date: Mon, 9 Aug 2010 04:53:44 -0700 (PDT)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: sysopen failures
Message-Id: <d57dbbfc-bed0-41e2-94f6-56c34a61a098@x25g2000yqj.googlegroups.com>
On Aug 7, 6:40=A0pm, "John W. Krahn" <jwkr...@example.com> wrote:
> Or true.
Indeed.
> By that time $! could have been changed by some other system function.
Yes.
> You need to capture or print the value of $! immediately after the
> system function that sets it, for example:
Yes...
> *Note that "$mode" is really the permissions field, and the MODE field
> is actually "O_EXCL | O_CREAT | O_WRONLY".
I saw that. It was set to 0444.
Thanks. I'll save a pointer to this and come back later.
Marc
------------------------------
Date: Mon, 9 Aug 2010 13:54:47 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: sysopen failures
Message-Id: <nda5j7-jt7.ln1@osiris.mauzo.dyndns.org>
Quoth jwkrahn@shaw.ca:
>
> sysopen my $FILE, $file, O_EXCL | O_CREAT | O_WRONLY, $mode or do {
> warn "Cannot open '$file' $!";
> return 0;
> };
>
>
> *Note that "$mode" is really the permissions field, and the MODE field
> is actually "O_EXCL | O_CREAT | O_WRONLY".
While it is correct that the fourth argument is the permissions, and
that perldoc -f sysopen calls the third and fourth arguments MODE and
PERMS respectively, open(2) calls the second argument (corresponding to
Perl's third) 'int flags' and the third 'mode_t mode'. So it's not an
unreasonable name for the variable.
Ben
------------------------------
Date: Mon, 9 Aug 2010 16:17:08 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: sysopen failures
Message-Id: <slrni603f4.rkb.hjp-usenet2@hrunkner.hjp.at>
On 2010-08-09 11:50, Marc Girod <marc.girod@gmail.com> wrote:
[sysopen(... O_EXCL ...) fails with EEXIST although the file shouldn't
exist]
> Well, I have to figure out how either could be possible.
> I cannot see what in the code could remove anything...
> Those files are left to be accessible from a web page.
> There is a loop which increments a digit in the file name and tries
> 100 times.
> I don't think this is very smart, but I cannot see how the 100
> different files could exist.
>
> The error returned in the end is of course only the one for the last
> try.
> So that I don't *know* why the 99 first attempts failed.
> But in the general case, I cannot find the 100th file either.
I would log each failure with all the details I can think of. In this
case:
* exact name of the file to be created
* $! immediately after the failure
* cwd at the time of the failure
* try to lstat the file just after the failure (but after logging $!,
or you will change it!) and log all relevant information if the
file exists - this will help you to determine where the spurious
files come from
> I may leave this for a while: I have more urgent, and the symptom has
> stopped for now.
> But I don't doubt it will come back.
If you add the diagnostics now you will have the information next time
the problem occurs.
hp
------------------------------
Date: Mon, 9 Aug 2010 19:32:15 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: sysopen failures
Message-Id: <vlq5j7-slo.ln1@news.rtij.nl>
On Mon, 09 Aug 2010 04:50:35 -0700, Marc Girod wrote:
> Well, I have to figure out how either could be possible. I cannot see
> what in the code could remove anything... Those files are left to be
> accessible from a web page. There is a loop which increments a digit in
> the file name and tries 100 times.
> I don't think this is very smart, but I cannot see how the 100 different
> files could exist.
>
> The error returned in the end is of course only the one for the last
> try.
> So that I don't *know* why the 99 first attempts failed. But in the
> general case, I cannot find the 100th file either.
Stupid suggestion and does not match exactly what you wrote above, but:
Are there maybe two instances of your program running and interfering
with each other?
M4
------------------------------
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 3068
***************************************
