[23954] in Perl-Users-Digest
Perl-Users Digest, Issue: 6155 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 18 14:15:46 2004
Date: Wed, 18 Feb 2004 11:15:15 -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 Wed, 18 Feb 2004 Volume: 10 Number: 6155
Today's topics:
Re: Unexplained output for PERL print statement <xx087@freenet.carleton.ca>
Re: Unexplained output for PERL print statement <bik.mido@tiscalinet.it>
Re: Unexplained output for PERL print statement <gnari@simnet.is>
Using fork() with a telnet-esque socket connection <exide@comcast.net>
Re: Using fork() with a telnet-esque socket connection <usenet@morrow.me.uk>
Re: Using fork() with a telnet-esque socket connection <uri@stemsystems.com>
Re: Using fork() with a telnet-esque socket connection <exide@comcast.net>
Re: Why is Perl losing ground? (G Klinedinst)
Re: Why is Perl losing ground? (G Klinedinst)
Re: Why is Perl losing ground? (G Klinedinst)
Re: Why is Perl losing ground? <nobody@somewhere-else.com>
Re: Why is Perl losing ground? <usenet@morrow.me.uk>
Re: Why is Perl losing ground? <tassilo.parseval@rwth-aachen.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 18 Feb 2004 14:14:11 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: Unexplained output for PERL print statement
Message-Id: <slrnc36spk.r3a.xx087@smeagol.ncf.ca>
Matthew Braid <mb@uq.net.au.invalid> wrote:
> Xavier wrote:
> > I have the following code in my perl script to generate some HTML:
> > printf "\<img src=\"Dir1/%s/%s\"\>\n", $dirname, $filename;
> >
> > looks like
> >
> > ">mg src="Dir1/dirname/filename
>
> What's in $filename? Is there maybe a weird character at the end?
> Maybe there's a carriage return there without a line-feed?
Perhaps you're reading a DOS text file, and chomp-ing?
Can reproduce with:
$dirname='dir'
$filename="file\r"
printf "\<img src=\"Dir1/%s/%s\"\>\n", $dirname, $filename;
# ==> ">mg src="Dir1/dir/file
You might want to trim whitespace off the end of $filename:
$filename =~ s/\s+$//;
--
Glenn Jackman
NCF Sysadmin
glennj@ncf.ca
------------------------------
Date: Wed, 18 Feb 2004 15:57:09 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: Unexplained output for PERL print statement
Message-Id: <l2u6309s7q32th0jcj96im4apgklukq7i4@4ax.com>
On 17 Feb 2004 21:45:11 -0800, spamaway03@yahoo.com (Xavier) wrote:
>Subject: Unexplained output for PERL print statement
^^^^ ^^^^^
[snip]
>I have the following code in my perl script to generate some HTML:
>
>printf "\<img src=\"Dir1/%s/%s\"\>\n", $dirname, $filename;
^^^^^^
1. No such a thing called PERL, see 'perldoc -q difference'
2. It's not a print() statement, but a unnecessary, IMHO printf() one.
^^^^^^^^^^^
3. Also, what about qq|cool foo... "bar baz" foo again|?
Michele
--
you'll see that it shouldn't be so. AND, the writting as usuall is
fantastic incompetent. To illustrate, i quote:
- Xah Lee trolling on clpmisc,
"perl bug File::Basename and Perl's nature"
------------------------------
Date: Wed, 18 Feb 2004 18:11:24 -0000
From: "gnari" <gnari@simnet.is>
Subject: Re: Unexplained output for PERL print statement
Message-Id: <c109qn$487$1@news.simnet.is>
"Robert Stelmack" <robert.h.stelmack*REMOVE*@boeing.com> wrote in message
news:HtA8Jz.I05@news.boeing.com...
[help with obvious \r embedded in print'ed variable value]
> Try printing out the $dirname, $filename just before their use.
actually, for debug prints, allways do them like this:
print "dirname=[$dirname] filename=[$filename]\n" if $debug;
this will make any whitespace/CR be more visible, as the
case where $dirname='a,b';$filename='';
gnari
------------------------------
Date: Wed, 18 Feb 2004 08:34:11 -0800
From: Exide Arabellan <exide@comcast.net>
Subject: Using fork() with a telnet-esque socket connection
Message-Id: <_I6dnTVnouiZCa7dRVn-gg@comcast.com>
Greetings,
Before I get too far into the guts of writing a custom telnet daemon, I
thought i'de test the waters and get some input. Im building an open
source text-based RPG (brings back memories eh? :). Looking to support
anywhere from 50-250 simultaneous connections (just depends on the
host's bandwith), with MySQL as the backend. Majority of my Perl
knowledge is self taught, so my terminology is unique (and thus hard to
ask specific questions). This is my first venture into Perl using socket
connections, and have read about using fork() to create a multithreaded
daemon. What i gathered was each end user connection would spawn a child
process of the parent daemon. Now upon inspecting other common
applications running on my box i was unsure if this is the right way to
go about it. If its not, could someone suggest an alternative?
Exide Arabellan
www.arabellan.com
------------------------------
Date: Wed, 18 Feb 2004 18:31:03 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Using fork() with a telnet-esque socket connection
Message-Id: <c10b17$a0u$1@wisteria.csv.warwick.ac.uk>
Exide Arabellan <exide@comcast.net> wrote:
> Before I get too far into the guts of writing a custom telnet daemon, I
> thought i'de test the waters and get some input. Im building an open
> source text-based RPG (brings back memories eh? :). Looking to support
> anywhere from 50-250 simultaneous connections (just depends on the
> host's bandwith), with MySQL as the backend. Majority of my Perl
> knowledge is self taught, so my terminology is unique (and thus hard to
> ask specific questions). This is my first venture into Perl using socket
> connections, and have read about using fork() to create a multithreaded
> daemon. What i gathered was each end user connection would spawn a child
> process of the parent daemon. Now upon inspecting other common
> applications running on my box i was unsure if this is the right way to
> go about it. If its not, could someone suggest an alternative?
There are four ways to handle multiple simultaneous connections:
1. Single-process. You have one process, which handles creating new
connections and all existing connections, using select(). This is
usually the most efficient solution for small numbers of connections,
but scales badly.
2. Forking. The parent process accepts each new connection and forks a
child to handle it. An example of this is sshd. This can make the
programming simpler (writing a select loop is not very easy), and also
will scale better than the first. There is still an appreciable delay
between a client making a connection and that client being serviced,
however, due to the fork.
3. Pre-forking. The parent initially forks a pool of children, and when
a new connection comes in it is passed to one of the existing children
to handle. When the number of free children gets too low, some more are
forked; contrariwise, when a whole lot have finished their processing
and gone back to waiting some are killed. An example of this is
(traditional) Apache. This is probably the most flexible and responsive
solution, although it still uses a whole process for each connection
which can cause problems if the number is huge.
4. Threaded. Basically, as forking; but instead of creating a new
process a new thread within the current process is created. This is
(usually) the least resource-intensive of these last three, but writing
(traditional) threaded programs adds a whole level of complexity to the
task. Examples of this are Apache/win32 and IIS. With Perl threads in
their current state, I would strongly advise against attempting this on
any decent Unix OS: Perl thread creation as currently implemented is
simply an emulation of fork() within the process, and the OS can do it
more efficiently than perl can.
Ben
--
The cosmos, at best, is like a rubbish heap scattered at random.
- Heraclitus
ben@morrow.me.uk
------------------------------
Date: Wed, 18 Feb 2004 18:47:56 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Using fork() with a telnet-esque socket connection
Message-Id: <x7ptccusv7.fsf@mail.sysarch.com>
>>>>> "BM" == Ben Morrow <usenet@morrow.me.uk> writes:
BM> There are four ways to handle multiple simultaneous connections:
BM> 1. Single-process. You have one process, which handles creating new
BM> connections and all existing connections, using select(). This is
BM> usually the most efficient solution for small numbers of connections,
BM> but scales badly.
where did you get the scales badly from? event loops (which is what
using select is), are general the most efficient way to handle multiple
connections. the only weakness is that you have to deal with any
potential blocking operations. given a pure cpu bound server, an event
loop has the least overhead over the other method. there is no forking,
no thread spawning, no extra context switching, etc. and event loop
design and coding is usually simpler than the others once you get the
hang of it. unfortunately we have a world of kiddies spoonfed that
threads are the only solution to any multiplexing and they can't break
out of that mold. threads have so many problems (in any langauge) that
must be dealt with including synchronization, locking and sharing and no
simple way to scale beyond a single box.
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: Wed, 18 Feb 2004 10:54:32 -0800
From: Exide Arabellan <exide@comcast.net>
Subject: Re: Using fork() with a telnet-esque socket connection
Message-Id: <7eOdnbx2esh0Ka7dRVn-sA@comcast.com>
Ben Morrow wrote:
> There are four ways to handle multiple simultaneous connections:
>
> 1. Single-process. You have one process, which handles creating new
> connections and all existing connections, using select(). This is
> usually the most efficient solution for small numbers of connections,
> but scales badly.
>
> 2. Forking. The parent process accepts each new connection and forks a
> child to handle it. An example of this is sshd. This can make the
> programming simpler (writing a select loop is not very easy), and also
> will scale better than the first. There is still an appreciable delay
> between a client making a connection and that client being serviced,
> however, due to the fork.
>
> 3. Pre-forking. The parent initially forks a pool of children, and when
> a new connection comes in it is passed to one of the existing children
> to handle. When the number of free children gets too low, some more are
> forked; contrariwise, when a whole lot have finished their processing
> and gone back to waiting some are killed. An example of this is
> (traditional) Apache. This is probably the most flexible and responsive
> solution, although it still uses a whole process for each connection
> which can cause problems if the number is huge.
>
> 4. Threaded. Basically, as forking; but instead of creating a new
> process a new thread within the current process is created. This is
> (usually) the least resource-intensive of these last three, but writing
> (traditional) threaded programs adds a whole level of complexity to the
> task. Examples of this are Apache/win32 and IIS. With Perl threads in
> their current state, I would strongly advise against attempting this on
> any decent Unix OS: Perl thread creation as currently implemented is
> simply an emulation of fork() within the process, and the OS can do it
> more efficiently than perl can.
>
> Ben
Thank you for that insight. That is exactly the type of information i
was after. I grep'd the newsgroup for fork() and read a bunch of posts
on 'Fork vs Thread', and have eliminated the Threaded possibility. I do
hope to port this to Win32 in the future, but my main concern is use in
Linux. I'm leaning towards Pre-forking, though im concerned about the
following statement.
> This is probably the most flexible and responsive solution, although
> it still uses a whole process for each connection which can cause
> problems if the number is huge.
Can you give me a ballpark on 'huge'? Flexibility, scaleability, and
response time are key factors (and the main reason i asked the original
question). Im aiming for medium-level consumer servers (512m~1gb ram,
1.0gHz+ cpu).
Exide Arabellan
www.arabellan.com
------------------------------
Date: 18 Feb 2004 07:30:55 -0800
From: g_klinedinst@hotmail.com (G Klinedinst)
Subject: Re: Why is Perl losing ground?
Message-Id: <168f035a.0402180730.4b0b4395@posting.google.com>
Beable van Polasm <beable+unsenet@beable.com.invalid> wrote in message news:<ee8yj1ur2v.fsf@dingo.beable.com>...
> g_klinedinst@hotmail.com (G Klinedinst) writes:
>
> >
> > I know people will say that Perl can be object oriented, but of course
> > it was an afterthought with Perl. Other languages were designed from
> > the ground up to make Objects easy to work with, and not allow a mix
> > of procedural and OO. As projects and applications get larger and more
> > complex people want to use OOP, so they pick a language which is
> > purely OO, and which implements it cleanly.
>
> Have you tried using one of these modules: Class::Struct,
> Class::MethodMaker, or Class::MakeMethods? Using one of them makes
> writing OO Perl very easy, especially the last two modules (available
> from CPAN). There are still a few niggly things, but who knows? Maybe
> Perl6 will fix them.
No, I haven't but thanks for the recommendation. I will take a look at
them and see if they can help me speed up my Perl OOP.
-Greg
------------------------------
Date: 18 Feb 2004 08:12:30 -0800
From: g_klinedinst@hotmail.com (G Klinedinst)
Subject: Re: Why is Perl losing ground?
Message-Id: <168f035a.0402180812.5f0d9df0@posting.google.com>
Ben Morrow <usenet@morrow.me.uk> wrote in message news:
> > In my opinion english and english-like names, as well as less cryptic
> > symbols
>
> At the risk of sounding more pedantic than is necessary :), do you mean
> 'less-cryptic symbols' or 'fewer cryptic symbols'? If the former, then
> yes you could say that Perl's array of $? vars (for instance) is
> cryptic, but they are actually no harder to learn than an api; if the
> latter, then I would argue that replacing them with named functions
> would only alleviate the initial 'what the Hell is that???' shock, and
> the api would still need to be learnt.
I meant the former, the number of variables is fine, it's just the
naming conventions are cryptic. Some sort of mnemonic naming
convention might help people learn.
> I have an irresitable urge to insert this quote here, from
> linux/Documentation/CodingStyle. True, it's about C, but Perl has a lot
> of C heritage:
>
> | C is a Spartan language, and so should your naming be. Unlike Modula-2
> | and Pascal programmers, C programmers do not use cute names like
> | ThisVariableIsATemporaryCounter. A C programmer would call that
> | variable "tmp", which is much easier to write, and not the least more
> | difficult to understand.
Most of the fancy naming conventions, such as Hungarian Notation are
in place to help people remember what is stored in the variable, which
is largely irrelevant in Perl(the $, @, or % tells you). As you point
out some people go way overboard with it, but the theory itself is
solid. Personally I like the capitalization of the words, because I
can't stand reading underscores.
-Greg
------------------------------
Date: 18 Feb 2004 08:23:59 -0800
From: g_klinedinst@hotmail.com (G Klinedinst)
Subject: Re: Why is Perl losing ground?
Message-Id: <168f035a.0402180823.768e84a2@posting.google.com>
"Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote:
> Whenever the topic of readability is discussed, sooner or later regexps
> will be mentioned as the one big evil of unreadability. I would like to
> point out that the concept of regular expressions is far older than
> Perl. Originally they were a different notation for deterministic (or
> indeterministic) finite automata and are able to describe the same
> languages (namely regular languages, hence the name).
>
> It has nothing to do with the programming languages. Regular expressions
> look the same in every programming language (minus some extended
> features that regular expression engines tend to offer; Perl has quite a
> lot of them). Therefore I could argue that using simple regexps is
> actually more readable than a function because anyone with an even
> moderate background in computer science should be able to read them.
>
> Unlike functions. Since function names differ wildly across programming
> languages, the programmer will very likely have to look it up in the
> docs.
Good point Tassilo. RegExp != Perl. I guess more specifically I was
refering to the tendency in Perl to use regexp throughout the code,
rather than relying on functions to handle mundane chores such as
searching for substrings, etc. Maybe with more practice I will be able
to read them a little faster too, because to me currently every one is
like a little hurdle I have to leap before I can keep on reading.
-Greg
------------------------------
Date: Wed, 18 Feb 2004 17:02:35 -0000
From: "Pope Bob" <nobody@somewhere-else.com>
Subject: Re: Why is Perl losing ground?
Message-Id: <10376lb84hi54ef@corp.supernews.com>
G Klinedinst wrote:
>For OOP I believe it is in the interest of programmers
>to shoehorn things into classes a little for the sake of
>uniformity and simplicity.
How can "shoehorning" anything lead to simplicity?
Such a Calvinistic approach to programming cannot be right.
Its somewhat similar to the adage "If all you've got is a hammer,
every problem begins to look like a nail."
------------------------------
Date: Wed, 18 Feb 2004 18:16:21 +0000 (UTC)
From: Ben Morrow <usenet@morrow.me.uk>
Subject: Re: Why is Perl losing ground?
Message-Id: <c10a5l$7gh$5@wisteria.csv.warwick.ac.uk>
g_klinedinst@hotmail.com (G Klinedinst) wrote:
> Ben Morrow <usenet@morrow.me.uk> wrote in message news:
>
> > > In my opinion english and english-like names, as well as less cryptic
> > > symbols
> >
> > At the risk of sounding more pedantic than is necessary :), do you mean
> > 'less-cryptic symbols' or 'fewer cryptic symbols'? If the former, then
> > yes you could say that Perl's array of $? vars (for instance) is
> > cryptic, but they are actually no harder to learn than an api; if the
> > latter, then I would argue that replacing them with named functions
> > would only alleviate the initial 'what the Hell is that???' shock, and
> > the api would still need to be learnt.
> I meant the former, the number of variables is fine, it's just the
> naming conventions are cryptic. Some sort of mnemonic naming
> convention might help people learn.
perldoc English
The fact that noone uses it, though, shows that my point still stands:
it's actually no *harder* to learn an api consisting of symbols than it
is one consisting of words, and learning the api is a step that must be
gone through regardless.
It also comes under Larry's mantra of 'different things should look
different': these variables are *really* *special*, so it's good that
they are instantly recognisable.
> > I have an irresitable urge to insert this quote here, from
> > linux/Documentation/CodingStyle. True, it's about C, but Perl has a lot
> > of C heritage:
> >
> > | C is a Spartan language, and so should your naming be. Unlike Modula-2
> > | and Pascal programmers, C programmers do not use cute names like
> > | ThisVariableIsATemporaryCounter. A C programmer would call that
> > | variable "tmp", which is much easier to write, and not the least more
> > | difficult to understand.
>
> Most of the fancy naming conventions, such as Hungarian Notation are
> in place to help people remember what is stored in the variable, which
> is largely irrelevant in Perl(the $, @, or % tells you). As you point
> out some people go way overboard with it, but the theory itself is
> solid. Personally I like the capitalization of the words, because I
> can't stand reading underscores.
Sorry, but to continue from the same document:
| Encoding the type of a function into the name (so-called Hungarian
| notation) is brain damaged - the compiler knows the types anyway and can
| check those, and it only confuses the programmer. No wonder MicroSoft
| makes buggy programs.
and furthermore, a variable is either local, in which case it is in a
small enough scope that there is no question about what it contains, or
global, in which case what it contains is an api issue just as much as
the parameters of functions.
Also, from perlstyle,pod:
| While short identifiers like $gotit are probably ok, use underscores to
| separate words. It is generally easier to read $var_names_like_this
| than $VarNamesLikeThis, especially for non-native speakers of English.
| It's also a simple rule that works consistently with
| VAR_NAMES_LIKE_THIS.
I would definitely agree with that: an underscore is a much clearer
separator of words than a change in case.
Ben
--
Although few may originate a policy, we are all able to judge it.
- Pericles of Athens, c.430 B.C.
ben@morrow.me.uk
------------------------------
Date: 18 Feb 2004 18:23:33 GMT
From: "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de>
Subject: Re: Why is Perl losing ground?
Message-Id: <c10aj5$8ks$1@nets3.rz.RWTH-Aachen.DE>
Also sprach G Klinedinst:
> "Tassilo v. Parseval" <tassilo.parseval@rwth-aachen.de> wrote:
>
>> Whenever the topic of readability is discussed, sooner or later regexps
>> will be mentioned as the one big evil of unreadability. I would like to
>> point out that the concept of regular expressions is far older than
>> Perl. Originally they were a different notation for deterministic (or
>> indeterministic) finite automata and are able to describe the same
>> languages (namely regular languages, hence the name).
>>
>> It has nothing to do with the programming languages. Regular expressions
>> look the same in every programming language (minus some extended
>> features that regular expression engines tend to offer; Perl has quite a
>> lot of them). Therefore I could argue that using simple regexps is
>> actually more readable than a function because anyone with an even
>> moderate background in computer science should be able to read them.
>>
>> Unlike functions. Since function names differ wildly across programming
>> languages, the programmer will very likely have to look it up in the
>> docs.
>
> Good point Tassilo. RegExp != Perl. I guess more specifically I was
> refering to the tendency in Perl to use regexp throughout the code,
> rather than relying on functions to handle mundane chores such as
> searching for substrings, etc. Maybe with more practice I will be able
> to read them a little faster too, because to me currently every one is
> like a little hurdle I have to leap before I can keep on reading.
It's a little declarative programming language of its own. Although
RegExp != Perl, Perl might have the tightest integration of regular
expressions of all contemporary languages I know. There's not really a
good way to avoid them when programming Perl.
However, the good news is that learning regexps is not a waste of time
as they show up in many places (when using a proper text editor, in the
shell, common UNIX utilities and in other programming languages). Once a
general understanding of how they work has been achieved, there is not
much that could beat them when it comes to readability. What they can do
with 20 characters might need 20 lines when avoiding them. And I always
prefer to read one line over many lines, even when this one line might
be quite complex.
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: 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 6155
***************************************
