[24129] in Perl-Users-Digest
Perl-Users Digest, Issue: 6323 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 29 00:15:46 2004
Date: Sun, 28 Mar 2004 21:15:05 -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 Sun, 28 Mar 2004 Volume: 10 Number: 6323
Today's topics:
Re: fork and wait... <mb@uq.net.au.invalid>
Re: Included directory problem (Myron Turner)
Re: life time of $1? (Myron Turner)
Re: losing data on socket (Vorxion)
Re: losing data on socket <uri@stemsystems.com>
Regex match for one and only one occurrence of a patter (Steve Allgood)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 29 Mar 2004 13:05:20 +1000
From: Matthew Braid <mb@uq.net.au.invalid>
Subject: Re: fork and wait...
Message-Id: <c483pg$p7a$1@bunyip.cc.uq.edu.au>
svetj wrote:
> "svetj" <svetjNO@SPAMtiscali.it> ha scritto nel messaggio
> news:qcw9c.140965$O31.5983134@news4.tin.it...
>
>>Hi,
>>I wrote a perl script that do one query to many db at the same time.
>>this is the code with fork (from "Programming Perl"):
<snip>
>>So, if I uncomment "waitpid($pid,80);" parten process wait for the end of
>
> a
>
>>child,
>>and if child don't stops, can't start next child..
>>But i want to start all childs at the same time,
>>and after the parent process must wait end of all childs for 80 seconds
>
> (for
>
>>example).
>>So where I must write waitpid?
>
>
> Excuse me: all thoes things are to avoid zombie childs..
You can make the parent keep a list of all its children, and have it loop over a
bunch of non-blocking waits until the children are all done.
Eg:
use strict;
use warnings;
use POSIX qw/WNOHANG/;
my @kids = ();
for my $i (0..9) {
my $kid = fork;
if (not defined $kid) {
die "Fork failed - $!\n" unless $! =~ /No more process/;
sleep(5);
redo;
} elsif ($kid) {
# Parent - store kid ID in list
$kids[$i] = $kid;
} else {
# Child
do_something(); # Whatever
print "Child $i done!\n";
CORE::exit;
}
}
while (scalar(@kids)) {
my $i = 0;
for my $k (@kids) {
if (waitpid($k, WNOHANG)) {
# Child has been reaped.
print "Child $i has been reaped!\n";
@kids = grep {$_ != $k} @kids;
}
++$i;
}
}
I'll leave it up to you to fit this to your code :)
------------------------------
Date: Mon, 29 Mar 2004 02:38:38 GMT
From: mturner@ms.umanitoba.ca (Myron Turner)
Subject: Re: Included directory problem
Message-Id: <40678c27.2157882280@news.wp.shawcable.net>
On Sun, 28 Mar 2004 18:39:04 +0200, "chatiman" <chatiman@free.fr>
wrote:
>Hello,
>
>I'm trying to build an installation procedure for a script.
>The script require some aditional modules
>which will be installed on the base "prefix=/my_prefix".
>
>How can I know which path to include in my script ?
>
>As you know the modules get installed in a directory
>which depends on the perl version and other
>parameters. It's sometimes:
>
>my_prefix/lib/site_perl/5.005
>my_prefix/lib/5.00503/
>...
>
>Thanks
>
>
>
>
You do it when you create the Makefile with:
perl Makefile.PL PREFIX=/my/perl/lib/dir/
Myron Turner
www.room535.org
------------------------------
Date: Mon, 29 Mar 2004 02:57:58 GMT
From: mturner@ms.umanitoba.ca (Myron Turner)
Subject: Re: life time of $1?
Message-Id: <40678e4d.2158432241@news.wp.shawcable.net>
On Sat, 27 Mar 2004 14:13:29 -0600, Tad McClellan
<tadmc@augustmail.com> wrote:
>Geoff Cox <geoffacox@dontspamblueyonder.co.uk> wrote:
>
>> I am confused re the $1 issue below
>
> The numbered variables ($1, $2, $3, etc.) and the related punctuation
> set ($+, $&, $`, $', and $^N) are all dynamically scoped
> until the end of the enclosing block or until the next successful
> match, whichever comes first. (See L<perlsyn/"Compound Statements">.)
>
>
>>
>> can I use $1 (and $2) again?
>
>
>You should never use the dollar-digit variables unless you
>have first ensured that the match _succeeded_. (I have
>pointed this out to you before.)
In a loop, if your code depends on testing a numbered $ variable, to
determine whether something has occurred, you can place the regular
expression in an eval:
while(<>) {
my $num = eval{ /(\d+)/; return $1 if $1; return undef; };
check_this_number($num) if $num;
}
If you don't use the eval, then the next time through the loop, there
might not be a number in $_, but $1 would still test true because it
would still hold the number from the previous iteration.
Myron Turner
www.room535.org
------------------------------
Date: 28 Mar 2004 22:59:53 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: losing data on socket
Message-Id: <40679f39_1@news.iglou.com>
In article <x78yhktor8.fsf@mail.sysarch.com>, Uri Guttman wrote:
>>>>>> "V" == Vorxion <vorxion@knockingshopofthemind.com> writes:
>
> V> The code looks fine when you don't have to pare down 1100+ lines to 472 or
> V> so. :)
>
>that isn't what he meant. your coding style needs to be cleaned up.
My coding style "needs" nothing. What you (or others) may prefer to write
and read is another story. Who are you to dictate what is or is not good
style? We'll get back to that question shortly.
>you don't get it. strict is meant to help you. your bypassing it is not
>eaier but harder. finding naming errors and symref stuff is much harder
Every time I've tried strict, it's been nothing but trouble. However...
>and you can declare file lexicals which is the best way to do globals
>in a file. if the variables MUST be package then use our and you won't
>need to fully qualify them everywhere. use the right tools for the job
>and don't shirk your work on declaring things with my.
Okay, I've seen references to our() before but been too busy to pursue it
at the time. It may make using strict a lot easier.
> V> I use curlies on every variable that is referenced as an rvalue,
> V> period, the end. It's a matter of stylistic continuity. If I
> V> -always- do it, it's never confusing, as compared to sometimes
> V> using them, sometimes not.
>
>that makes NO sense. braces for basic variable names are meant to be
>used when you need to disambiguate them in "" string. they have almost
>no other use. your excuse is weak and it means your coding style needs
>to be improved.
Rubbish. My coding style is not weak, it is -explicit-, and it is
-consistant-. I can't help it if a few people are apparently too
weak-minded to actually analyse code rather than complain about the way
it's formatted.
> >>> sub spawn;
> >>
> >> What's this for? You always use parens on functions (and no prototypes
> >> either), so you don't need any forward declarations.
>
> V> man perlipc
>
> V> Talk to the developers themselves, since it's actually in the official
> V> POD for perl. I removed the comment, but they said it was a forward
> V> declaration.
>
>not needed anymore. the pod for that must be wrong or you misunderstood.
The POD file in 5.8.3 contains the line in question, with the comment, on
line 888 of perlipc.pod.
> V> The program has LOTS of lexicals. It's in that 800+ lines I cut loose to
> V> try and post as little as possible.
>
>but the lexicals won't help you find misspelled ones without using strict.
I'm quite capable of catching my own spelling, thank you. Perhaps I'm not
as lazy about doing so as people relying on a program to do their work for
them...
> V> BLOCKLABEL: {
> V> $found_one++, last BLOCKLABEL if ${line} =~ /\Wone\W/;
> V> ...
> V> }
>
>just because it is legal doesn't make it good code. comma is ok for
>short statements that need to be executed together:
>
> $foo = $bar, next if /blah/ ;
>
>note that the example you quoted is like mine but it is not like your
>real code. your code has two completely independent statements with no
>reason to use comma. it misleads the reader of your code and is
>obsfucating it. is that what you want others to think?
If the reader is -that- easily misled, they have no business helping
others, for crying out loud. Then they obviously don't know the syntax, do
they? I'm not claiming to know everything, but for the love of all things
holy, it's -in- the Camel or the perl POD's. I suppose you know better
than Wall, Christiansen, et al.?
> V> Possibly not, but I prefer clean error messages that don't confuse users.
> V> If I have to go in and debug, I can put it in when I test.
>
>that makes no sense. how will you know what environment the user is in?
>the messages from $! are fairly clear and useful.
You haven't dealt with Real World users, have you? :) I'm talking about
people like a secretary that gets confused if you present a -simple- error,
> V> It's an rvalue. I'm simply being consistant, since if I need them
> V> anywhere, it's inconsistant if they're not everywhere.
>
>again, that makes NO sense. try being consistant and never use them
>except when needed in "" strings.
Do you even read what you write, or do you like to hear yourself type?
Try being consistant and ... _EXCEPT_ when...
Since when is an exception consistant?
>that doesn't help someone reading the code on the web or usenet or with
>more or cat or on paper. editing is not reading.
It's not hard to even read, if you know what you're doing. Perhaps you
don't. Christ, if something is in question, you can count, can you not? I
don't even need to count, unless I'm actually debugging, in which case it
takes a second. I just see them as simple references. I -like- them
explicitly declared, period, the end.
>bollocks to you too. style is important. you obviously don't get that
>yet. in time you will. try working with your own code 10 years
>later. hell, try it 6 months later. try having anyone else maintain your
>code without running away screaming. your ego is writing checks you
>can't cash. listen to what experience perl hackers have to say and don't
>slam them.
I've been working on my own code from 4 years ago. Not a problem at all.
Probably because I've been utterly consistant. I've been using the ${var}
syntax consistantly since -before- I started in perl, in fact, from back in
shell scripting. This far predates my use of perl--by a decade or so.
As for ego, who the HELL are you to talk? Who says your style fits my
needs, or my tastes? Who says it's even right? What the hell ever
happened to TIMTOWTDI?
>you post code (which you had to do) you get comments on it. this is
>usenet. get used to it. get a thicker skin. get a better coding style.
I came here looking for assistance on the (non)FUNCTIONALITY of buffering.
I didn't ask for a critical review of my personal choice of code
formatting. I didn't ask for a tutorial on God's One True Way To Code.
I'm not trying to get anything rolled into the bloody linux kernel or
anyone else's project, or perl itself. I'm not even writing a module for
CPAN.
I had a FUNCTIONALITY issue, and all two people have done so far is
actually nitpicked at the stylistic differences between what I do, and
what they want to see people do. If that same time had been applied to the
actual question at hand, I'd likely already have had the answer and been on
my way, that much further ahead.
> V> Thanks for the one good suggestion--which had pretty much nothing
> V> to do with my actual problem. But thanks all the same, that was
> V> shorter, and I got something out of the experience.
>
>and you should have gotten more. too bad your ego is in the way of
>learning something. consistancy to a poor style is not useful to anyone
>but yourself. and if you think you are the only one to ever maintain
>your code, you are sadly mistaken. i doubt you will heed my words any
>more than you did tassilo.
I appreciated the suggesion regarding our(). Despite your childish
refusal to address the actual issue and instead harp on something strictly
tangential to the issue at hand, I find that a helpful pointer. I'll look
it up and perhaps be able to tolerate strict in future.
And WHO has the ego here? As I said, I came here looking for help with
-functionality-, not style. So far, two of you have addressed anything BUT
the question at hand.
Frankly, the "helpfulness" exhibited here so far is less than some of
the high-level linux developers, including the zealots. I've seen some
-real- egos in the last 14 years online, especially in the linux and OSS
communities, but the demonstrations here lead me to believe that c.l.p.m
is filled with a bunch of elitist conformists who like to only address
what is next to irrelevant to the matter at hand, instead of the actual
functionality problems as described in the original post.
So either you don't -know- what's wrong, or you're so petulant and childish
that you won't deign to respond with anything truly useful pertaining the
actuall issue until someone meets your criteria for being worth helping.
If it's the former, say so. If it's the latter, grow the hell up.
>i won't bother to help you again. you are not ready to learn. come back
>in a year when you have some proper humility and an open mind.
You've -got- to be kidding. *laugh* Talk about lack of humility... -I-
am not the one imposing my style on anyone but myself. You two apparently
refuse to look at anything that doesn't have your utter seal of approval
stylistically. -You-, on the other hand, have been so humble as to only
stop short of saying I need to take a class in perl, simply because you
either can't read or don't like my coding style. Who's imposing whose
views? I didn't ask -you- to change -your- style. Feel free to code
however the hell you like. I had a simple question that so far both people
have selectively glossed over entirely, focusing instead on esoteric
bullshit, and puffing themselves up as self-important in the process of
doing so. To be fair, only you did that--the other poster did not puff
themselves up.
Frankly, you're the one that needs the lesson in humility. "Come back in
a year when you have some proper humility and an open mind." ??? Uhm, yes,
spoken like a truly humble person, Uri. Try practicing what you preach.
You've basically just proven yourself a complete and utter hypocrite.
Jolly good show, that! :)
And to top it off, neither of you bothered to actually address the -real-
issue, which is -purely- functional. The only way the amount of curly
braces, or my use of the comma operator could break things is if it made
the program utterly uncompilable, which I assure you is -not- the case.
The only thing wrong with my program is that buffering konks out after
about 30K of input and the rest falls on the floor, whether I use perlio or
stdio with set[v]buf().
One hopes that the rest of the lot here are absolutly -nothing- like you,
and I've simply had a bad one-off experience here with a couple of flakes.
If you're representative, that's indeed a scary thought.
I came here actually hoping to learn something that I -needed- to know. I
could work on style whenever time permits. Hell, I could rewrite all my
code eventually. NOW is NOT the time, I need to get something -DONE- about
this buffering issue. And I was desperate enough to try and ask here.
Looks like I really -was- desperate. Desperate enough that I'll see if
anyone actually has a real subtantive and relevant answer rather than some
gripes about esoteria.
I hate to generalise, but it surely seems like some people spend an awful
lot of time in their ivory towers rather than working in the real world
where things need to actually get done. You basically just performed the
perl equivalent of spellchecking someone's post and bitching about it while
ignoring the content, which in generall is considered piss-poor netiquette,
if nothing else.
Anyone here NOT from the Perl House of Style that would stoop to read some
code that hasn't been sanctified and blessed by the One True Church? Hell,
I'll take functional advice even -from- those people. Hell, I'll even
-listen- to the stylistic advice and take it under advisement, provided it
actually comes with something germaine to the actual problem at hand.
Unfortunately, it did not in either of the last two cases.
Uri, I'd be taking your advice a hell of a lot more seriously than I am if
either one of you had said, "You know, you really should do x, y, and z,
you don't, you might want to strongly consider doing so in future. BUT,
for now, -here's- your functionality problem, and this is how I would
likely go about fixing it within the context of what you presented." And
even give the solution in -your- coding stylistic preference, fine. But
you didn't make yourself even that helpful.
In essence, what I've seen here is akin to taking my car to a mechanic and
told them the transmission is slipping gears, and being told, "Bring it back
once you've had it repainted, and we'll talk." I'd say that's a pretty
useless mechanic. Extrapolate.
One hopes someone actually helpful will step up to the plate. I'm even
-willing- to entertain comments about my style, honestly--if they come
-with- some advice -pertinent- to the situation. It's the utter childish
snobbery of what I was just slapped with, combined with the complete lack
of contextual usefulness of the replies, that has me miffed.
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: Mon, 29 Mar 2004 04:49:34 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: losing data on socket
Message-Id: <x73c7stfz6.fsf@mail.sysarch.com>
>>>>> "V" == Vorxion <vorxion@knockingshopofthemind.com> writes:
V> In article <x78yhktor8.fsf@mail.sysarch.com>, Uri Guttman wrote:
>>
>> that isn't what he meant. your coding style needs to be cleaned up.
V> My coding style "needs" nothing. What you (or others) may prefer to write
V> and read is another story. Who are you to dictate what is or is not good
V> style? We'll get back to that question shortly.
hmm, i just landed a job where my opinions on coding style are prized
very highly and they pay me for it. could a large financial firm be so
off base? or could people who see my talks on coding style at yapc
conferences be so misled too? or do my 30 years of experience coding in
many languages mean nothing? oh, well, i will just quit this
profession. you know so much more than i do and i will never catch up.
>> you don't get it. strict is meant to help you. your bypassing it is not
>> eaier but harder. finding naming errors and symref stuff is much harder
V> Every time I've tried strict, it's been nothing but trouble. However...
you don't know the meaning of trouble until you spend hours to debug
something that strict would catch in milliseconds. your loss. the
computer wants to work for you and you refuse. try using an abacus
instead. more work for you but it isn't strict at all.
>> and you can declare file lexicals which is the best way to do globals
>> in a file. if the variables MUST be package then use our and you won't
>> need to fully qualify them everywhere. use the right tools for the job
>> and don't shirk your work on declaring things with my.
V> Okay, I've seen references to our() before but been too busy to pursue it
V> at the time. It may make using strict a lot easier.
oh, i helped you!!! sorry, i won't make that mistake again. please
forgive me. i know you know all about coding and perl and life. i will
crawl back under my rock now.
V> I use curlies on every variable that is referenced as an rvalue,
V> period, the end. It's a matter of stylistic continuity. If I
V> -always- do it, it's never confusing, as compared to sometimes
V> using them, sometimes not.
>>
it is confusing to all others who read your code. does anyone else in
the world matter to you? what if your mother read your code? wouldn't
she be embarrased by its wacko style? do you want to hurt her feelings?
what kind of son are you?
>> that makes NO sense. braces for basic variable names are meant to be
>> used when you need to disambiguate them in "" string. they have almost
>> no other use. your excuse is weak and it means your coding style needs
>> to be improved.
V> Rubbish. My coding style is not weak, it is -explicit-, and it is
V> -consistant-. I can't help it if a few people are apparently too
V> weak-minded to actually analyse code rather than complain about the way
V> it's formatted.
ok, then you are correct. go tell larry wall how to code or anyone who
is in p5p or writes cpan modules or anyone else in the perl
community. you have to be the only one in the whole planet who always
uses braces for simple variables all the time. you must be right then.
>> >>> sub spawn;
>> >>
>> >> What's this for? You always use parens on functions (and no prototypes
>> >> either), so you don't need any forward declarations.
>>
V> man perlipc
>>
V> Talk to the developers themselves, since it's actually in the official
V> POD for perl. I removed the comment, but they said it was a forward
V> declaration.
>>
>> not needed anymore. the pod for that must be wrong or you misunderstood.
V> The POD file in 5.8.3 contains the line in question, with the comment, on
V> line 888 of perlipc.pod.
V> The program has LOTS of lexicals. It's in that 800+ lines I cut loose to
V> try and post as little as possible.
>>
>> but the lexicals won't help you find misspelled ones without using strict.
V> I'm quite capable of catching my own spelling, thank you. Perhaps I'm not
V> as lazy about doing so as people relying on a program to do their work for
V> them...
V> BLOCKLABEL: {
V> $found_one++, last BLOCKLABEL if ${line} =~ /\Wone\W/;
V> ...
V> }
>>
>> just because it is legal doesn't make it good code. comma is ok for
>> short statements that need to be executed together:
>>
>> $foo = $bar, next if /blah/ ;
>>
>> note that the example you quoted is like mine but it is not like your
>> real code. your code has two completely independent statements with no
>> reason to use comma. it misleads the reader of your code and is
>> obsfucating it. is that what you want others to think?
V> If the reader is -that- easily misled, they have no business
V> helping others, for crying out loud. Then they obviously don't
V> know the syntax, do they? I'm not claiming to know everything, but
V> for the love of all things holy, it's -in- the Camel or the perl
V> POD's. I suppose you know better than Wall, Christiansen, et al.?
ok, all syntax legal. great. why don't you enter some obsfucated or perl
golf contest then? you will win just with your bracing of variables. no
one will understand it and you will be declared the most obscure perl
coder in the universe! all will praise your code!!
now, if all legal syntax code is fine, why do you have ANY ; in your
code? you can join all the statements with ,. since , is the lowest
precedence that would work well. oh what about putting () around all
your simple expressions. just like the bracing of variables, it is legal
and perfectly readable syntax. oh you could choose names for your
variables like $a123, $a124, $a125. very legal and fine syntax.
in case you don't get the point (and i doubt you will) your choices are
what matters in your code, not what the code does.
rules to code by (you may ignore them. hell, you do already):
code is for people, not computers. and code is co
V> You haven't dealt with Real World users, have you? :) I'm talking
V> about people like a secretary that gets confused if you present a
V> -simple- error,
i have dealt with more users and coders and everything else than you
will ever see. but i have also dealt with the likes of you (c guy who
also said, legal syntax is all i need). he was a moron.
>> again, that makes NO sense. try being consistant and never use them
>> except when needed in "" strings.
V> Do you even read what you write, or do you like to hear yourself type?
V> Try being consistant and ... _EXCEPT_ when...
V> Since when is an exception consistant?
since when is doing something for no reason a good reason to do it?
coding is communication. doing something means there is a reason behind
it. bracing a variable because it is an rvalue is a valid
reason. rvalues don't NEED bracing. so you do it to satisfy your poor
sense on style in the name of odd consistancy. but consistancy is not a
reason but a continued way of doing something. your reason is faulty but
you don't see that. you defend it on the wrong grounds.
>> that doesn't help someone reading the code on the web or usenet or with
>> more or cat or on paper. editing is not reading.
V> It's not hard to even read, if you know what you're doing. Perhaps
V> you don't. Christ, if something is in question, you can count, can
V> you not? I don't even need to count, unless I'm actually
V> debugging, in which case it takes a second. I just see them as
V> simple references. I -like- them explicitly declared, period, the
V> end.
it has nothing to do with knowing what you are doing. it has to do with
noise. signal to noise ratio is much lower in your code. you have noise
in the form of braces that cloud the signal in the form of variables. if
larry wanted your style to be the way he would have made it part of the
syntax to require it. braces are allowed for the specific reason to
disabmiguate inside "". there is no other syntactical REASON for using
them. but i bet huffman encoding is not something you would understand.
V> I've been working on my own code from 4 years ago. Not a problem
V> at all. Probably because I've been utterly consistant. I've been
V> using the ${var} syntax consistantly since -before- I started in
V> perl, in fact, from back in shell scripting. This far predates my
V> use of perl--by a decade or so.
bad shell style too. who taught you this mess? they should be fired.
V> As for ego, who the HELL are you to talk? Who says your style fits my
V> needs, or my tastes? Who says it's even right? What the hell ever
V> happened to TIMTOWTDI?
timtowtdi is for getting the job done. you can always do things better
and timtowtdi doesn't preclude that.
>> you post code (which you had to do) you get comments on it. this is
>> usenet. get used to it. get a thicker skin. get a better coding style.
V> I came here looking for assistance on the (non)FUNCTIONALITY of
V> buffering. I didn't ask for a critical review of my personal
V> choice of code formatting. I didn't ask for a tutorial on God's
V> One True Way To Code. I'm not trying to get anything rolled into
V> the bloody linux kernel or anyone else's project, or perl itself.
V> I'm not even writing a module for CPAN.
sorry, you lose. read the rules of posting on usenet. you cannot
formally request only the answers you seek. BZZZZZTT! please try again.
V> I had a FUNCTIONALITY issue, and all two people have done so far is
V> actually nitpicked at the stylistic differences between what I do,
V> and what they want to see people do. If that same time had been
V> applied to the actual question at hand, I'd likely already have had
V> the answer and been on my way, that much further ahead.
well, you hid all your logic behind odd styling. hard to tell what is
wrong with all that noise in the way. i can't get beyond 5 lines of your
code. i must be a weak coder or my eyes are just too sensitive. maybe it
is my deep feelings about perl that are hurt by your code? who knows?
V> I appreciated the suggesion regarding our(). Despite your childish
V> refusal to address the actual issue and instead harp on something strictly
V> tangential to the issue at hand, I find that a helpful pointer. I'll look
V> it up and perhaps be able to tolerate strict in future.
me childish?!! i triple dog dare you to say that to my face!! NYAHH!
NYAHH!! NYAHH!!!
V> And WHO has the ego here? As I said, I came here looking for help
V> with -functionality-, not style. So far, two of you have addressed
V> anything BUT the question at hand.
well, as i said, i can't help you there. i can't read your code without
it causing a migraine. and i don't normally get migraines.
V> Frankly, the "helpfulness" exhibited here so far is less than some
V> of the high-level linux developers, including the zealots. I've
V> seen some -real- egos in the last 14 years online, especially in
V> the linux and OSS communities, but the demonstrations here lead me
V> to believe that c.l.p.m is filled with a bunch of elitist
V> conformists who like to only address what is next to irrelevant to
V> the matter at hand, instead of the actual functionality problems as
V> described in the original post.
elitests of the world unite! we have nothing to lose but our egos!
V> So either you don't -know- what's wrong, or you're so petulant and
V> childish that you won't deign to respond with anything truly useful
V> pertaining the actuall issue until someone meets your criteria for
V> being worth helping. If it's the former, say so. If it's the
V> latter, grow the hell up.
nah, i will just advise my paying clients on coding style. they seem to
like my opinions unlike you. maybe i should charge you for my advice
here? if you paid for it you actually might listen.
>> i won't bother to help you again. you are not ready to learn. come back
>> in a year when you have some proper humility and an open mind.
V> You've -got- to be kidding. *laugh* Talk about lack of humility...
V> -I- am not the one imposing my style on anyone but myself. You two
V> apparently refuse to look at anything that doesn't have your utter
V> seal of approval stylistically. -You-, on the other hand, have
V> been so humble as to only stop short of saying I need to take a
V> class in perl, simply because you either can't read or don't like
V> my coding style. Who's imposing whose views? I didn't ask -you-
V> to change -your- style. Feel free to code however the hell you
V> like. I had a simple question that so far both people have
V> selectively glossed over entirely, focusing instead on esoteric
V> bullshit, and puffing themselves up as self-important in the
V> process of doing so. To be fair, only you did that--the other
V> poster did not puff themselves up.
hmm, 800 lines of hard to read code is not something i care to delve
into. now the fact that i have done major work with I/O in many systems
should allow me to figure it out. but i am too childish to respond in
any helpful way.
V> Frankly, you're the one that needs the lesson in humility. "Come
V> back in a year when you have some proper humility and an open
V> mind." ??? Uhm, yes, spoken like a truly humble person, Uri. Try
V> practicing what you preach. You've basically just proven yourself
V> a complete and utter hypocrite. Jolly good show, that! :)
amen brother!!
can i hear an amen from the readership?
V> And to top it off, neither of you bothered to actually address the
V> -real- issue, which is -purely- functional. The only way the
V> amount of curly braces, or my use of the comma operator could break
V> things is if it made the program utterly uncompilable, which I
V> assure you is -not- the case. The only thing wrong with my program
V> is that buffering konks out after about 30K of input and the rest
V> falls on the floor, whether I use perlio or stdio with set[v]buf().
i see a bug on line 438. or was it on 287? maybe it was on 782? i can't
tell what line it is on. maybe the braces are confusing me?
V> One hopes that the rest of the lot here are absolutly -nothing-
V> like you, and I've simply had a bad one-off experience here with a
V> couple of flakes. If you're representative, that's indeed a scary
V> thought.
i own this newsgroup. all the regulars are my coding slaves! they obey
my stylistic imperatives to the letter or i make them code in cobol!
V> I came here actually hoping to learn something that I -needed- to
V> know. I could work on style whenever time permits. Hell, I could
V> rewrite all my code eventually. NOW is NOT the time, I need to get
V> something -DONE- about this buffering issue. And I was desperate
V> enough to try and ask here. Looks like I really -was- desperate.
V> Desperate enough that I'll see if anyone actually has a real
V> subtantive and relevant answer rather than some gripes about
V> esoteria.
you have a bug in your buffering. rewrite the code in shell and it will
be fixed.
V> I hate to generalise, but it surely seems like some people spend an
V> awful lot of time in their ivory towers rather than working in the
V> real world where things need to actually get done. You basically
V> just performed the perl equivalent of spellchecking someone's post
V> and bitching about it while ignoring the content, which in generall
V> is considered piss-poor netiquette, if nothing else.
hmm. i should be in the real world? i ain't been in an ivory tower in a
good long time. and one thing i did learn there and in the real world,
the style of your work matters as much as the results.
V> Anyone here NOT from the Perl House of Style that would stoop to
V> read some code that hasn't been sanctified and blessed by the One
V> True Church? Hell, I'll take functional advice even -from- those
V> people. Hell, I'll even -listen- to the stylistic advice and take
V> it under advisement, provided it actually comes with something
V> germaine to the actual problem at hand. Unfortunately, it did not
V> in either of the last two cases.
sorry but i only help those who help themselves.
V> Uri, I'd be taking your advice a hell of a lot more seriously than
V> I am if either one of you had said, "You know, you really should do
V> x, y, and z, you don't, you might want to strongly consider doing
V> so in future. BUT, for now, -here's- your functionality problem,
V> and this is how I would likely go about fixing it within the
V> context of what you presented." And even give the solution in
V> -your- coding stylistic preference, fine. But you didn't make
V> yourself even that helpful.
you expect people to drop what they are doing and analyze 800 lines of
code in no time flat? what planet are you from? i am rewriting (for
style reasons of course) a module that is only 600 lines long and it is
mostly html stuff. it is taking be a few days to fully analyze all the
odd logic i see there. your perspective on how much work it is to figure
out a tricky buffering bug boggles me. does it boggle you? maybe it should?
V> In essence, what I've seen here is akin to taking my car to a
V> mechanic and told them the transmission is slipping gears, and
V> being told, "Bring it back once you've had it repainted, and we'll
V> talk." I'd say that's a pretty useless mechanic. Extrapolate.
hmm, maybe you painted over the transmission gears and he doesn't feel
like scraping it off before he can fix it?
V> One hopes someone actually helpful will step up to the plate. I'm
V> even -willing- to entertain comments about my style, honestly--if
V> they come -with- some advice -pertinent- to the situation. It's
V> the utter childish snobbery of what I was just slapped with,
V> combined with the complete lack of contextual usefulness of the
V> replies, that has me miffed.
given your fine upstanding tone, i expect hundreds of regulars here will
devote the next 24 hours to analyzing your code and fixing your bug. in
fact i will order it! minions, please fix his bug. and i mean NOW!!!
V> --
V> Vorxion - Member of The Vortexa Elite
hmm, who is the elitist now?
<apologies to alan shore on the practice. he is a very nice model for
smarmy :)>
have the appropriate amount of fun!
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 28 Mar 2004 18:53:20 -0800
From: chiriones@yahoo.com (Steve Allgood)
Subject: Regex match for one and only one occurrence of a pattern
Message-Id: <e33c37bb.0403281853.2e6a0156@posting.google.com>
I'm trying to match one and only one occurrence of a pattern in a string.
For example, for the pattern 'bc' I want a regex to match 'abcd' but not 'abcdabcd'.
I have tried /bc(?!(.*bc)+)/ but that doesn't work. It just matches the last 'bc'.
Any suggestions?
Thanks,
Steve
------------------------------
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 6323
***************************************
