die() (was: which is better ...)
Lost Sheep Of the Porn wrote: On Jan 11, 5:28 am, [EMAIL PROTECTED] (Rob Dixon) wrote: - die() will not show the program file and line number where it was called if there is a newline at the end of its string parameter. Is this... die "Couldn't open filedata for reading: $!\n"; The string parameter? I'd guess Rob means that "Couldn't open filedata for reading: $!\n" is. But as usual it's better to go to the perldoc to gain clarity. From "perldoc -f die": "If the last element of LIST does not end in a newline, the current script line number and input line number (if any) are also printed, and a newline is supplied." -- Gunnar Hjalmarsson Email: http://www.gunnar.cc/cgi-bin/contact.pl -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
Re: Strange interaction of "my"-variables with initialization
Chas. Owens wrote: On Jan 13, 2008 1:20 PM, John W. Krahn <[EMAIL PROTECTED]> wrote: snip Statements don't define scope, braces and files define scope. snip so why should you be able to use it because it has been changed to this my $t = $x if $x; print "$t\n"; You can use it because it is in the same scope. snip And that is why I consider it to be a bug. There is no reason for conditional modifiers to not have their own scope. For instance, the conditional form of for still localizes $_, even though there is no scope for it to be localized in: This is just the way that Perl works: perldoc perlsyn [ SNIP ] Foreach Loops The "foreach" loop iterates over a normal list value and sets the variable VAR to be each element of the list in turn. If the variable is preceded with the keyword "my", then it is lexically scoped, and is therefore visible only within the loop. Otherwise, the variable is implicitly local to the loop and regains its former value upon exiting the loop. If the variable was previously declared with "my", it uses that variable instead of the global one, but it’s still localized to the loop. This implicit localisation occurs only in a "foreach" loop. The same localization of $_ also occurs with map and grep. $ perl -le' $_ = "foo"; map $_ += 1, @x = 1 .. 3; print "$_ @x"; ' foo 2 3 4 John -- Perl isn't a toolbox, but a small machine shop where you can special-order certain sorts of tools at low cost and in short order.-- Larry Wall -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
Re: which is better when reading files
On Jan 11, 5:28 am, [EMAIL PROTECTED] (Rob Dixon) wrote:
> Enjoy_Life wrote:
>
> >
>
>
>
> > hi, who can tell me which is better of the following codes?
> > why there are different methods to read files?
> > thanks
>
> > 1. open(INPUT, "< filedata") or die "Couldn't open filedata for reading:
> > $!\n";
> > while () {
> > print if /blue/;
> > }
> > close(INPUT);
>
> > 2. use IO::File;
> > $input = IO::File->new("< filedata")
> > or die "Couldn't open filedata for reading: $!\n";
>
> > while (defined($line = $input->getline())) {
> > chomp($line);
> > STDOUT->print($line) if $line =~ /blue/;
> > }
> > $input->close();
>
> I suggest that best of all is:
>
> use IO::Handle;
>
> open my $input, '<', 'filedata' or die "Couldn't open filedata for
> reading: $!";
>
> while (my $line = <$input>) {
>next unless $line =~ /blue/;
>print $line;
>
> }
>
> Note the following:
>
> - die() will not show the program file and line number where it was
>called if there is a newline at the end of its string parameter.
>
Is this...
die "Couldn't open filedata for reading: $!\n";
The string parameter?
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
Threaded chat server
Hello Perl gurus,
I'm currently in the process of writing a chat server in Perl.
Everything is all hunky-dory--it parses commands as it should, and is,
of course, quite satisfying. Except for one thing, and that is that it
cannot handle multiple clients at once, which, needless to say, is
kind of useful for a chat program, isn't it? So I've been following
the discussion online of Threads vs. forking vs. non-blocking IO, and
I've decided to try threads, which is neat because this is the first
thing I've ever done with threading. However, my excitement has been
somewhat dampened by the fact that it does not work. It can still
happily handle a single client--no complaints there. However, it can
still ONLY handle a single client. There's probably a hole in my
understanding of threads (e.g., I don't entirely understand what
join() and detach() DO...). Below is the relevant server code, and I
was hoping some kind soul could look at it, suppress his laughter at
my naive code and point me in the right direction.
Code:
...
use threads;
...
sub start {
use IO::Socket;
my ($self, %args) = @_;
my $host = $args{'host'} || $self->{'host'};
my $port = $args{'port'} || $self->{'port'};
my $sock = new IO::Socket::INET(
LocalHost => $host,
LocalPort => $port,
Proto => 'tcp',
Listen=> SOMAXCONN,
Reuse => 1);
$sock or die "Unable to open a port on $host:$port: $!";
print localtime() . ": Started server on $host:$port\n";
$self->{'socket'} = $sock;
$self->{'connected'} = 1;
my ($new_sock, $client_addr);
while(($new_sock, $client_addr) = $sock->accept()) {
my $thread = threads->create(\&handleClient, $self, $new_sock,
$client_addr);
$thread->join();
}
}
Thanks,
Turner
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
Re: Controlling external I/O with Perl
On Sun, 2008-01-13 at 10:28 -0700, Joseph L. Casale wrote: > I have a need at work to monitor external I/O from a PC. Basically I > need to turn outputs on and off and monitor some various inputs for > different ranges. Since I know *some* Perl and the PC won't be doing > anything else I am not worried about making sure the code is > enterprise scalable. Is there any direction anyone can point me to > start my reading into such a requirement? Additionally if anyone knows > of any external hardware with a Perl API that exists, that would be > great! There are multiple solutions to this. Are you using Windows or Unix or other operating system. What type of IO are you using? Serial, parrallel, etc. The answers will probably come from http://search.cpan.org -- Ken Foskey FOSS developer -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
Re: Strange interaction of "my"-variables with initialization
On Jan 13, 2008 1:20 PM, John W. Krahn <[EMAIL PROTECTED]> wrote: snip > Statements don't define scope, braces and files define scope. snip > > so why should you be able to use it because it has been changed to this > > > > my $t = $x if $x; > > print "$t\n"; > > You can use it because it is in the same scope. snip And that is why I consider it to be a bug. There is no reason for conditional modifiers to not have their own scope. For instance, the conditional form of for still localizes $_, even though there is no scope for it to be localized in: #!/usr/bin/perl use strict; use warnings; $_ = "foo"; print "$_\n" for "bar"; print "$_\n"; -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
Re: Strange interaction of "my"-variables with initialization
Chas. Owens wrote:
On Jan 13, 2008 6:22 AM, Peter Daum <[EMAIL PROTECTED]> wrote:
snip
my $t =$x if $x;
snip
$t would be initialized with the value of $x if that was true;
otherwise (at least that's what I would expect) $t should be undefined,
so the result would be as before. The real outcome, however, is:
$t == undef
$t == a
$t == b
$t now retains its value from the last loop iteration.
Is this a bug or a feature (tm)?
If it is a feature, then why isn't the value also retained in the 1st example?
snip
People argue about whether this is a bug or not*. In my opinion, it
is a bug because the variable's scope should be within the if
statement.
Statements don't define scope, braces and files define scope.
You wouldn't expect to be able the use the variable if the
code looked like this
if ($x) {
my $t = $x;
}
The scope is limited because of the braces.
print "$t\n";
so why should you be able to use it because it has been changed to this
my $t = $x if $x;
print "$t\n";
You can use it because it is in the same scope.
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order.-- Larry Wall
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
Re: Strange interaction of "my"-variables with initialization
On Jan 13, 2008 6:22 AM, Peter Daum <[EMAIL PROTECTED]> wrote:
snip
> my $t =$x if $x;
snip
> $t would be initialized with the value of $x if that was true;
> otherwise (at least that's what I would expect) $t should be undefined,
> so the result would be as before. The real outcome, however, is:
>
> $t == undef
> $t == a
> $t == b
>
> $t now retains its value from the last loop iteration.
> Is this a bug or a feature (tm)?
> If it is a feature, then why isn't the value also retained in the 1st example?
snip
People argue about whether this is a bug or not*. In my opinion, it
is a bug because the variable's scope should be within the if
statement. You wouldn't expect to be able the use the variable if the
code looked like this
if ($x) {
my $t = $x;
}
print "$t\n";
so why should you be able to use it because it has been changed to this
my $t = $x if $x;
print "$t\n";
The proper way to get static variables prior to Perl 5.10 is
{
my $counter;
sub inc {
return $counter++;
}
}
With Perl 5.10 we can use state** instead of my:
sub inc {
state $counter;
return $counter++;
}
* http://www.perlmonks.org/?node_id=95940
** http://perldoc.perl.org/functions/state.html
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
Controlling external I/O with Perl
I have a need at work to monitor external I/O from a PC. Basically I need to turn outputs on and off and monitor some various inputs for different ranges. Since I know *some* Perl and the PC won't be doing anything else I am not worried about making sure the code is enterprise scalable. Is there any direction anyone can point me to start my reading into such a requirement? Additionally if anyone knows of any external hardware with a Perl API that exists, that would be great! Thanks for any comments! jlc -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
Re: Strange interaction of "my"-variables with initialization
Peter Daum wrote:
Hi,
Hello,
I just got bitten by a very simple issue, where Perl behaves totally
different from what I had expected;
According to the documentation, lexical variables are visible only after
the line they have been declared in; they may be initialized;
otherwise their value is undefined, so the following short code snippet:
foreach (qw(a b c)) {
my $t;
warn("\$t == ", $t||'undef', "\n");
$t=$_;
}
will 3 times print "$t == undef" (as to be expected).
Now a minor variation:
my $x=undef;
foreach (qw(a b c)) {
my $t =$x if $x;
warn("\$t == ", $t||'undef', "\n");
$t=$_;
}
$t would be initialized with the value of $x if that was true;
otherwise (at least that's what I would expect) $t should be undefined,
so the result would be as before. The real outcome, however, is:
$t == undef
$t == a
$t == b
$t now retains its value from the last loop iteration.
Is this a bug or a feature (tm)?
If it is a feature, then why isn't the value also retained in the 1st example?
perldoc perlsyn
[ SNIP ]
NOTE: The behaviour of a "my" statement modified with a statement
modifier conditional or loop construct (e.g. "my $x if ...") is
undefined. The value of the "my" variable may be "undef", any
previously assigned value, or possibly anything else. Don’t rely on
it. Future versions of perl might do something different from the
version of perl you try it out on. Here be dragons.
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order.-- Larry Wall
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
Strange interaction of "my"-variables with initialization
Hi,
I just got bitten by a very simple issue, where Perl behaves totally
different from what I had expected;
According to the documentation, lexical variables are visible only after
the line they have been declared in; they may be initialized;
otherwise their value is undefined, so the following short code snippet:
foreach (qw(a b c)) {
my $t;
warn("\$t == ", $t||'undef', "\n");
$t=$_;
}
will 3 times print "$t == undef" (as to be expected).
Now a minor variation:
my $x=undef;
foreach (qw(a b c)) {
my $t =$x if $x;
warn("\$t == ", $t||'undef', "\n");
$t=$_;
}
$t would be initialized with the value of $x if that was true;
otherwise (at least that's what I would expect) $t should be undefined,
so the result would be as before. The real outcome, however, is:
$t == undef
$t == a
$t == b
$t now retains its value from the last loop iteration.
Is this a bug or a feature (tm)?
If it is a feature, then why isn't the value also retained in the 1st example?
Regards,
Peter Daum
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
