[24131] in Perl-Users-Digest
Perl-Users Digest, Issue: 6325 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 29 03:10:40 2004
Date: Mon, 29 Mar 2004 00:10:07 -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 Mon, 29 Mar 2004 Volume: 10 Number: 6325
Today's topics:
Re: losing data on socket <spamtrap@dot-app.org>
Re: losing data on socket <uri@stemsystems.com>
Re: losing data on socket (Vorxion)
Re: losing data on socket <tassilo.parseval@rwth-aachen.de>
Re: losing data on socket <tassilo.parseval@rwth-aachen.de>
Re: losing data on socket <bernard.el-haginDODGE_THIS@lido-tech.net>
Re: losing data on socket <tassilo.parseval@rwth-aachen.de>
Re: losing data on socket (Vorxion)
Re: losing data on socket <tassilo.parseval@rwth-aachen.de>
Re: Regex match for one and only one occurrence of a pa <tadmc@augustmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 29 Mar 2004 00:45:33 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: losing data on socket
Message-Id: <Ofydna67H41pKvrdRVn-vw@adelphia.com>
Vorxion wrote:
> Every time I've tried strict, it's been nothing but trouble.
When the "check engine" light comes on in your car, do you check to see what
the problem is, or do you disconnect the light?
Strictures and warnings are Perl's "check code" lights. Don't just
disconnect the lights - fix the problems they're trying to tell you about.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Mon, 29 Mar 2004 05:54:15 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: losing data on socket
Message-Id: <x7wu54ryew.fsf@mail.sysarch.com>
>>>>> "SP" == Sherm Pendley <spamtrap@dot-app.org> writes:
SP> Vorxion wrote:
>> Every time I've tried strict, it's been nothing but trouble.
SP> When the "check engine" light comes on in your car, do you check to see what
SP> the problem is, or do you disconnect the light?
SP> Strictures and warnings are Perl's "check code" lights. Don't just
SP> disconnect the lights - fix the problems they're trying to tell
SP> you about.
oh, please stop with the auto analogies. his car needs painting before
we can fix the engine. :)
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: 29 Mar 2004 01:28:59 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: losing data on socket
Message-Id: <4067c22b_1@news.iglou.com>
In article <x73c7stfz6.fsf@mail.sysarch.com>, Uri Guttman wrote:
>
>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.
More humility, I see. *cough* Pot, kettle.
I never -ever- claimed to know more than anyone. If I -knew- it, I
wouldn't have come asking for help, would I? Logic 101, anyone?
>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?
My mother wouldn't know perl from a hole in the ground. :)
>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.
I'm not the one imposing my style on everyone/anyone else. I never said
you're wrong, I said I don't do it your way, and here's why.
>ok, all syntax legal. great. why don't you enter some obsfucated or perl
That was -hardly- obfuscated.
>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.
Actually, I've done that. I actually like code that will do things like:
foreach my $keyword ($q->params) {
${${keyword}} = $q->params($keyword);
}
I specifically use variable variable names in any number of situations.
You'll note that I left out my extra curly braces JUST for you, excepting
the possibility that the inner ones in the variable variable assignment
weren't needed--I've never seen it done any other way. I suspect they're
redundant but didn't test it.
>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.
The choices only matter if the code actually works. If you made all the
right choices but your code isn't working, it pretty much doesn't matter
how "right" you were, you just wasted a lot of time.
>rules to code by (you may ignore them. hell, you do already):
>
> code is for people, not computers. and code is co
Completing your thought helps if you want to communicate. :)
>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.
I actually never said legal syntax was all I need. Don't put words in my
mouth. I said I -had- a style, and I stick to it. You just don't happen
to like it. There's a difference between my insisting on -my- modicum of
style, and what you said I said.
> V> Since when is an exception consistant?
>
>since when is doing something for no reason a good reason to do it?
I dunno...I've done pet projects on a lark just to see how to do it and
learn, and later had it parlay into being able to help someone out. It
happens.
>coding is communication. doing something means there is a reason behind
Coding is communication. Fine, if you want to get metaphysical about it.
The interpreter knows exactly what I mean. So do I when I work on my code.
You know, I wasn't coding it for anyone here to review, honestly. I was
working quite nicely on my own, and my extra braces would have harmed not a
flea. I hit a technical snag, I posted a (quite concise) plain-English
explanation of the problem, and someone -asked- for the code. I pared it
down best I could so that I wasn't posting the full thing. About 99% of my
lexically scoped stuff was tossed in that chopping. You're basically
bitching about curly braces, period. Someone asked to see my code. They
didn't tell me to rewrite it any particular way before they would look at
it. Furthermore, they asked for -my- code, not what my code would look
like if -they- wrote it.
>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.
If you can do something 100% of the time and it works, why have exceptions
that will be confusing? It's consistant. You don't suddenly make mistakes
in the middle of "" strings because you forgot, because you -always- do it.
And it hurts nothing to do it.
I don't even care to dispute the point. Style was never -my- issue. I
just want to know what's up with the buffering...where am I actually
screwing up so that the buffers don't fully buffer. When I assign a more
than ample buffer (even just a 1MB buffer), I expect all 50K of my data to
arrive unmolested. That's the issue. I'm not saying it's perl's fault,
I'm -asking- what the issue is.
Fine, if you don't want to look at my code, just plain tell me how it's
supposed to work then, because it doesn't appear to past a certain point.
>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.
If Larry wanted my code a certain way, he'd write the project himself. :)
He didn't disallow it. In fact, he allows for it, because with -w on, I
will indeed see ambiguous rvalues get altered to the non-brace form. I
have no idea why some are considered ambiguous when they're always rvalues.
I don't really care too much, either.
And the noise doesn't actually bother me--in fact, it helps me in several
ways.
>bad shell style too. who taught you this mess? they should be fired.
It's perfectly valid when you're trying to prevent variables from using
the wrong name. That's when I started it generically, when it didn't hurt
anything to do it consistantly.
>timtowtdi is for getting the job done. you can always do things better
>and timtowtdi doesn't preclude that.
At the -moment-, all I want to do better is buffer my incoming data on a
socket. I'm not sure which part of that is so difficult to understand.
Really, take as many issues with my style as you like. You can even
consider yourself right. I don't mind a bit.
ALL I need to know -at this time- is how to get the buffering working
right. If there's a refrence in the Camel or POD's that I've missed, by
all means point me at it. It'll have nothing to do with my style, and we
can rehash that some other time at leisure.
> 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.
*laugh* I didn't get answers, per se. I got a lot of unsolicited
stylistic pointers, but no actual answers. Oh, you mean replies? Yeah,
don't I know it?
But you know, when someone's asking for help with something specific, and
you do nothing to help their problem, but instead gratuitously post to rip
on their style, you're not making yourself look anything but petty. You're
certainly not being helpful to the immediate issue.
>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?
Yeah, who knows, because obviously you know -what- they do, and that
they're harmless. So just bloody look past them. Christ, run it through
perl and nuke any ${ and \w} you find. It's really -not- that hard. I
have a few references somewhere to an actual @{$hash{'value'}} that are
legitimately needed, although I'm not sure if they made the cut I posted.
>me childish?!! i triple dog dare you to say that to my face!! NYAHH!
>NYAHH!! NYAHH!!!
I would, if we were. Without hesitation.
>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.
Fine, so be it. Then do you have any general suggestions related to socket
input buffering that are salient to the point at hand that have NO relation
to my code at hand, but would point me in the right direction?
>elitests of the world unite! we have nothing to lose but our egos!
Quite true.
>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.
If I was paying for advice (and I'm strongly considering hiring someone
to either bang out the relavent few lines of code necessary to get the
buffering working), I'd expect a solution, not a bunch of lip service as
to our stylistic differences. As it is, I'll take that kind of behaviour
here, but not without rebuttal, since you -insist- on bringing it 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.
Where do you get 800? 472 after snipping. I cut most of it, and it's
<1200 total. I highly doubt vim lied to me when I saved it.
>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?
You really -are- being childish. What's worse is you're -supposedly- such
a professional. It doesn't show. Then again, professional != mature, so
maybe my expectations are at fault.
>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!
I wouldn't doubt it at this point. :)
> 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.
I'd prefer to just rewrite it in perl. The solution is probably all of one
to ten lines of code, which can be written in ANY STYLE YOU LIKE. :)
>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.
And my style works for me. Focus on the actual issue for a change. The
style won't matter if there -are- no results.
>sorry but i only help those who help themselves.
That's what I -thought- I was doing when I posted here after banging on it
from different directions for a while myself. It hasn't been for lack of
effort on my part.
My curly braces are not nuking my buffering. You and I both know it. So
that statement about not helping myself holds zero water.
>you expect people to drop what they are doing and analyze 800 lines of
472.
>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?
It's not theoretically tricky at all. In fact, it's -supposed- to work
with stdio using setbuf() or setvbuf(). Apparently it's just plain
supposed to work under perlio.
Hell, point me at a perl-specific networking book, and I'll gladly go buy
it tomorrow.
> 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?
No, I meant the body, and I bloody well think you knew it. Your "point"
hasn't escaped me, either. Fine, a brief alternative will suffice. I know
the socket creation and my reads/writes are working. All I need is the
buffering to work properly. So about how many lines of code is that to
whip out, if you know as much as you say you do? I'm betting <10. I'm
actually betting it's one critical line, but I'd say a workaround is
probably on the order of 10. Rough guess.
So show me how it's suppsosed to work and let -me- extrapolate from -your-
example. Your code is better than mine anyway, no?
>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!!!
Given the plain-English summation, there shouldn't be a need to look at the
code at all. As for the not getting only the replies you want--back atcha,
since you and the other person obviously didn't like the code they -asked-
to see.
That notwithstanding, I could use -some- helpful pointers -regarding
correct socket buffering-. Even a rough checklist of things not to forget
might help.
> V> --
> V> Vorxion - Member of The Vortexa Elite
>
>hmm, who is the elitist now?
It's the name of a squadron I used to fly with in an online multiplayer
game called Continuum/Subspace. Squad names tended to be flashy.
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: 29 Mar 2004 06:52:26 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: losing data on socket
Message-Id: <c48h3a$75d$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Vorxion:
> In article <c47jll$kov$1@nets3.rz.RWTH-Aachen.DE>, Tassilo v. Parseval wrote:
>>Also sprach Vorxion:
>>
>>So it's neither a lexical nor a package variable (to which local() can
>>be applied). What is it then? There are only those two flavour of
>>variables. In your case $main_buffer is a package variable as you say
>>that it lives in the package 'main'. In this case it could be subject to
>>local(), of course.
>
> Global to the package main::, I suppose is what I meant.
>
>>This code is a mess, I am afraid. I doubt people will be able to spot
>>the problem in it. Here are some comments that should help you to clean
>>up your code a bit. Maybe it will help you to find out what is wrong.
>
> The code looks fine when you don't have to pare down 1100+ lines to 472 or
> so. :)
>
>>You are not using strictures. A program of a certain size (and yours
>>does qualify) will benefit from using strict along with lexical
>>variables. I wouldn't be surprised if your program behaved badly due to
>>too many global variables and actions-at-a-distance arising from that.
>>Therefore:
>
> No, I'm certainly not using strict. I've tried that and it -insists- on
> making you reference every variable by a package name if it's not lexical.
> I -need- some package variables, period, and I see no reason to bloat the
> code by referencing main:: everywhere.
You don't have to do that. Either use our() or do a preliminary
use vars qw/$first_global $second_global .../;
Once you have done that and it still complains, it means you made a typo.
That's a huge help because you no longer have to check those trivial
things yourself.
>>> $local_addr = inet_ntoa(scalar(gethostbyname(${local_host} || 'localhost')));
>>
>>What are those curlies doing there? They are not wrong, but they serve
>>no purpose either. All they do is harm readability. Ditch them here and
>>everywhere else where you are using them.
>
> I use curlies on every variable that is referenced as an rvalue, period,
> the end. It's a matter of stylistic continuity. If I -always- do it, it's
> never confusing, as compared to sometimes using them, sometimes not.
At least you gave me a very hard time reading it. When I see curlies in
the vicinity of a '$', I first assume there is some sort of
hash-subscript. People have different reading and understanding habits,
I grant you that. But since you posted your codes to have others read
it, it can't hurt to toe the line a bit. The more easily we (the group) can
read your code, the more likely it is that we can find the source of
yours problems.
>>> sub spawn;
>>
>>What's this for? You always use parens on functions (and no prototypes
>>either), so you don't need any forward declarations.
>
> man perlipc
>
> Talk to the developers themselves, since it's actually in the official
> POD for perl. I removed the comment, but they said it was a forward
> declaration.
Yes, alright, it is a forward declaration. perlipc.pod neglected to
mention why it used one in one of the code snippets. The outline was:
...
sub spawn; # forward declaration
...
for (...) {
...
spawn sub {
$| = 1;
...
};
}
sub spawn {
my $coderef = shift;
...
}
Apparently the author of this code snippet wanted to be able to call
spawn() without braces. Had he instead written:
sub spawn {
my $coderef = shift;
...
}
...
spawn sub {
...
};
he could have got rid of the forward declaration. But again: forward
declarations are only needed when you put the implemention of functions
at the bottom of a script _and_ the function either has a prototype or
you want to call them without parens.
Anyway, it's not a serious issue. Your forward declaration isn't going
to hurt anyone but it doesn't hurt either to know what they are really
for.
>>> ##### Set reaper.
>>> my $waitedpid = 0;
>>
>>Interestingly enough, you used a lexical variable here. Why here and not
>>elsewhere?
>
> The program has LOTS of lexicals. It's in that 800+ lines I cut loose to
> try and post as little as possible.
Your program has LOTS of variables in general. ;-)
>>> ${cli_logfile} = '__FLTbogus', fl_die(27,"Daemon mode called without absolutely pathed working directory.");
>>
>>I find using the comma like this confusing. This line looks as though it
>>contains two statements. Don't unecessarily join them into on.
>
> It does contain two statements. I learned this syntax from doing something
> like:
>
> BLOCKLABEL: {
> $found_one++, last BLOCKLABEL if ${line} =~ /\Wone\W/;
> ...
> }
>
> Since it worked there, I use it where possible to combine code. Works
> fine. It was in the docs somewhere (probably the Camel) as an example of
> how to emulate a 'case' type functionality.
Note that I didn't complain about the comma where you used it with a
statement-modifier. There you need in fact something that turns two
statements into one so a comma (or sometimes 'and' or '&&') is in order.
>>Also, fl_die() looks like a function that terminates your program. Why
>>do you first assign to a variable just to die immediately afterwards.
>>Is it maybe because fl_die() accesses the value of $cli_logfile? If so,
>>this is a poor way of passing data around. Pass it as a proper argument:
>>
>> fl_die(27, '...', '__FLTbogus');
>>
>>The first argument '27', is that a sort of error-code? Maybe you declare
>>those as constants. 27 looks rather meaningless to me (and maybe even to
>>you when you read your program again in a few months without touching it
>>in between).
>
> You entirely misunderstand what it's doing. I'm setting cli_logfile (ouch,
> I screwed up and used {}'s on an lvalue...works but goes against my
> style...since fixed here), so that it's set when fl_die() calls fl_log(),
> and then calling fl_die().
Keep in mind though that fl_die() can also pass the value of
$cli_logfile on to fl_log().
Apparently your situation is that you have a program which requires a
lot of global data. Sometimes there is nothing one can do about that.
Perl gives you a lot of ways organizing your data and variables in such
a situation. Always using package globals might not be the best. There
are other means, such as using an object (one that incorporates and
encapsulates all the global stuff so it is no longer floating around the
main logic of the program). Sometimes closures can be used: a closure is
a function that has some variables attached to it:
use strict;
{
my $var;
sub set_var { $var = shift }
sub get_var { $var }
}
set_var("foo"); # sets the above '$var'
print get_var(); # prints: "foo"
# compile time error: '$var' is only visible from within the block
$var = "bar";
Note how fl_die() and fl_log() could be built on top of such a closure:
set_logfile("die.log");
fl_die(27, "message");
{
my $logfile;
sub set_logfile { $logfile = shift }
sub get_logfile { $logfile }
}
sub fl_die {
my ($err, $msg) = @_;
fl_log(@_);
die $msg;
}
sub fl_log {
my ($err, $msg) = @_;
open F, ">", get_logfile() or die $!;
print F "$err: $msg\n";
}
I still think that passing the file as argument is preferable here, but
there you have another way of arranging things.
> Yes, 27 is an error code that's both logged, and used for exit(). And no,
> I don't want to put them all in fl_die or anywhere else so that I can
> easily search for the number in the code and find out exactly where I
> konked out.
If you use Perl's die() without a terminating newline, you get the line
number in the error message.
>>> use POSIX;
>>> chdir('/') or fl_die(10,"Could not chdir prior to daemonisation.");
>>
>>Wouldn't hurt to include $! in the error message:
>
> Possibly not, but I prefer clean error messages that don't confuse users.
> If I have to go in and debug, I can put it in when I test.
But it could help the user. When he gets a "permission denied", he knows
that he might have to change the permission on a certain file or
directory to make it work.
>>I think you should try to decrease your character-count a bit. All those
>>braces make your code harder on the eye. I particularly hate
>>
>> ${child_pids{${child}}}
>> # should be
>> $child_pids{$child}
>
> It's an rvalue. I'm simply being consistant, since if I need them
> anywhere, it's inconsistant if they're not everywhere.
>
>>Keep in mind that humans aren't very good at deciphering hordes of
>>nested delimiters (especially when they are all the same).
>
> That's what the % key in vi (or the default matching mode in emacs) is for.
>:)
But wouldn't it be so much nicer if one didn't even need the help of the
editor for that? I use '%' sometimes on largish block structures to
figure out where blocks end (you need it quite often when you are
staring at the source code of perl as it uses a somewhat idiosyncratic
way of indentation).
>>I suppose you got the idea by now. My honest suggestion would be to
>>dispose of this whole code and re-start from scratch. Before you do so,
>>find a consistent coding style that requires less characters (I've
>>seldom seen a program where the lines are that long throughout the whole
>>code). Maybe you have a preliminary read of 'perldoc perlstyle' for a
>>start. Apart from that, pay particular attention to the scoping of your
>>variables and try to use less of them as well. In other spots, introduce
>>a few variables where it increases readability. The above
>>while-condition is such an example. For that you could also write a
>>function with a descriptive name that returns a booleans value.
>
> Bollocks. I don't care what the preferred style of the authors is; I have
> my own. It's (aside from that one lvalue typo, which probably snuck in
> during a copy/paste/alter) consistant. The code is -not- invalidated simply
> because you can't be bothered to read it because it's -explicitly- written.
> There's nothing -wrong- with the code per se. The only thing wrong is that
> the buffering isn't working, which may or may not be something I did, or it
> could be perl (I'd find that odd). And the buffering is not working in
> perlio if you just depend on that and leave set[v]buf() out entirely,
> either. That's how I -originally- had it.
>
> I was asking for help on a buffering issue, not a debate on stylistic
> differences of representing code. Someone says I didn't post enough to go
> on, post the code--fine. I posted the code. Now you say I gave too much
> to go on. Surreal. Pick one.
I didn't say you posted too much (not in the sense of posting too much
semantic content). What I meant to say was that I cannot follow the
logic of your code. Being in this group is just a hobby for me (and all
others). I am not getting paid to review other people's code and so I
give up when things get too tedious and tricky. I didn't not address
your actual problem because I was being malicious. I would have
addressed it, had I been able to find it. Your coding style prevented me
from doing that.
> Thanks for the one good suggestion--which had pretty much nothing to do
> with my actual problem. But thanks all the same, that was shorter, and I
> got something out of the experience.
That's how usenet works. You make a posting and other people start
discussing certain aspects of it...or sometimes they talk about other
non-related things. You cannot control it. Therefore it is advisable to
present the problem in a way that makes talking about side-issues
harder for the audience.
Anyway, I am happy you didn't take my criticism (that was targeted
towards your code and not you) personally. Whenever people do that,
they've already lost.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 29 Mar 2004 07:11:45 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: losing data on socket
Message-Id: <c48i7h$7qu$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Uri Guttman:
>>>>>> "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.
Probably that's not even the issue here (which is not taken to be a sign
of disrespect towards your coding-style;-). It's only about what this
group expects from code that gets posted here. The group is supposed to read
it and therefore it has the right to demand a certain style. It's about
helping those people that are supposed to help you.
> 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.
Easy, Uri. Not everyone not instantly agreeing with you is a moron. I
think it happens all the time that people develop a certain habit (the
OP says he does those things deliberately so he at least made some
preliminary considerations) and feel a bit hurt when told that their way
is flawed in one way or the other. At some point they might give up
their resistance. Some people are more easily convinced than others. If
however someone turns out to be immune against any good advice (no
matter how long and hard one tries), well, then calling him words could
be justified. :-)
> 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?
That's all there is to point out: People can't help because they don't
understand the OP's code. What else is there to say? The OP now should
draw his own conclusions from that. The only sensible conclusion would
be to make his code readable to the group and thus make their life
easier. However, he cannot be forced to do that. Likewise, the group
cannot be forced to help him and so I am pretty serene about this whole
business. The OP has a problem he needs to solve, not the group.
> V> Vorxion - Member of The Vortexa Elite
>
> hmm, who is the elitist now?
I wondered about that, too. I had to bite my lips not to make any
snippish remark. ;-)
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Mon, 29 Mar 2004 09:15:26 +0200
From: "Bernard El-Hagin" <bernard.el-haginDODGE_THIS@lido-tech.net>
Subject: Re: losing data on socket
Message-Id: <Xns94BB5D6BDAC3Celhber1lidotechnet@62.89.127.66>
vorxion@knockingshopofthemind.com (Vorxion) wrote:
[...]
> 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?
Since when is it *not*? Always do 'A' except when 'B' occurs *is*
consitant. Surely even someone as stubborn and misguided as you can see
that?
--
Cheers,
Bernard
------------------------------
Date: 29 Mar 2004 07:23:24 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: losing data on socket
Message-Id: <c48itc$8dj$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Vorxion:
> In article <x73c7stfz6.fsf@mail.sysarch.com>, Uri Guttman wrote:
>>you have a bug in your buffering. rewrite the code in shell and it will
>>be fixed.
>
> I'd prefer to just rewrite it in perl. The solution is probably all of one
> to ten lines of code, which can be written in ANY STYLE YOU LIKE. :)
Alright. So please tell us _which_ ten lines of code need a rewrite and
then the group will fix them.
See, no one knows which lines those are and no one can find them
_because_ your style leaves a lot to be desired readability-wise. Please
don't expect the people in this group to sacrifize a good amount of time
to wade through the several hundred lines of your code. They are willing
to help, but they might not be that willing.
And since the tone of this threads appears to become a bit harsher by
now: Stop that immediately (and no, no one cares whether it was you or
Uri or anyone else who started with it). You asked the group to find a
bug in your program. Beggars can't be choosers. Wouldn't it therefore be
wise to just give in on the matters discussed right now and let people
focus on the real problem again? By defending your grounds you'll lead
them astray further.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: 29 Mar 2004 02:26:50 -0500
From: vorxion@knockingshopofthemind.com (Vorxion)
Subject: Re: losing data on socket
Message-Id: <4067cfba_1@news.iglou.com>
In article <Ofydna67H41pKvrdRVn-vw@adelphia.com>, Sherm Pendley wrote:
>Vorxion wrote:
>
>> Every time I've tried strict, it's been nothing but trouble.
>
>When the "check engine" light comes on in your car, do you check to see what
>the problem is, or do you disconnect the light?
Generally, take it to a mechanic. :) I'm absolutely mechanically
disinclined. *chuckle*
>Strictures and warnings are Perl's "check code" lights. Don't just
>disconnect the lights - fix the problems they're trying to tell you about.
The "problems" they were telling me about were perfectly valid variables
inside the main:: package. I knew they were there, knew the risks of using
them non-lexically, and chose that risk. Just iike driving without a
seatbelt, probably. :)
I just did a `perldoc -f our`, and yes, it looks like that will solve my
problem with strict. Of course, it's a PITA to go adding a variable to
that list whenever I need a new variable, "just because". OTOH, C was just
as strict, so I can likely live with it.
I fail to see why one should have to explicitly scope something inside
main:: when it's already inside main:: according to strict. :)
However, in the unlikely even that my buffer variable is being...nuked
somehow (I fail to see how), I may indeed to to the pain of hunting down
all my variables that are meant to be scoped to main:: and explicitly
defining them. Am I to assume that our(%hashname); will indeed also cover
$hashname{whatever} instances as well, since it's referencing part of the
hash namespace?
--
Vorxion - Member of The Vortexa Elite
------------------------------
Date: 29 Mar 2004 07:48:49 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: losing data on socket
Message-Id: <c48kd1$9go$1@nets3.rz.RWTH-Aachen.DE>
Also sprach Vorxion:
> In article <Ofydna67H41pKvrdRVn-vw@adelphia.com>, Sherm Pendley wrote:
>>Vorxion wrote:
>>
>>> Every time I've tried strict, it's been nothing but trouble.
>>
>>When the "check engine" light comes on in your car, do you check to see what
>>the problem is, or do you disconnect the light?
>
> Generally, take it to a mechanic. :) I'm absolutely mechanically
> disinclined. *chuckle*
>
>>Strictures and warnings are Perl's "check code" lights. Don't just
>>disconnect the lights - fix the problems they're trying to tell you about.
>
> The "problems" they were telling me about were perfectly valid variables
> inside the main:: package. I knew they were there, knew the risks of using
> them non-lexically, and chose that risk. Just iike driving without a
> seatbelt, probably. :)
>
> I just did a `perldoc -f our`, and yes, it looks like that will solve my
> problem with strict. Of course, it's a PITA to go adding a variable to
> that list whenever I need a new variable, "just because". OTOH, C was just
> as strict, so I can likely live with it.
>
> I fail to see why one should have to explicitly scope something inside
> main:: when it's already inside main:: according to strict. :)
It isn't only about scoping. Every non-qualified variable will
automatically be put into the current package by perl (unless it was a
lexical which does not live in a package). our() also tells perl that
you have a variable that you want to access unqualified. Whenever you
mistype it, perl will croak at compile time because you didn't tell it
to allow unqualified access to this (misspelled) variable:
use strict;
our $variable;
...
# typo: perl wont even finish compilation of your program
$variabel = 1;
It's the same with C. A C compiler will also barf on misspelled
variables. Perl will only do so if you use strictures. And that's why
you should use them as well.
> However, in the unlikely even that my buffer variable is being...nuked
> somehow (I fail to see how), I may indeed to to the pain of hunting down
> all my variables that are meant to be scoped to main:: and explicitly
> defining them. Am I to assume that our(%hashname); will indeed also cover
> $hashname{whatever} instances as well, since it's referencing part of the
> hash namespace?
Yes, you are to assume that. Array and hash subscripts are always ok
when you declared the array or hash in question properly (with my() or
our()). Note how perl can catch this error:
use strict;
our $var;
...
$var{ key } = 1;
Again error at compile-time because perl only knows of $var and not of
%var.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval
------------------------------
Date: Sun, 28 Mar 2004 22:58:33 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Regex match for one and only one occurrence of a pattern
Message-Id: <slrnc6fb7p.ai1.tadmc@magna.augustmail.com>
Steve Allgood <chiriones@yahoo.com> wrote:
> 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?
print "matched\n" if s/bc/bc/g == 1;
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
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 6325
***************************************
