[26057] in Perl-Users-Digest
Perl-Users Digest, Issue: 8263 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jul 21 10:59:58 2005
Date: Wed, 20 Jul 2005 11:05:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 20 Jul 2005 Volume: 10 Number: 8263
Today's topics:
Re: "Can't return a temporary from lvalue subroutine... (Anno Siegel)
Re: "Can't return a temporary from lvalue subroutine... (Anno Siegel)
Re: "Can't return a temporary from lvalue subroutine... <jkrugman345@yahbitoo.com>
Re: copy contructor (Anno Siegel)
How to send a query to the browser from time to time? <me@privacy.net>
Re: How to send a query to the browser from time to tim <1usa@llenroc.ude.invalid>
problem using both Memoize::Expire and DB_File <dejanews@email.com>
Re: using passwd in a perl script (Anno Siegel)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 20 Jul 2005 10:32:45 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <dbl98d$g3r$1@mamenchi.zrz.TU-Berlin.DE>
J Krugman <jkrugman345@yahbitoo.com> wrote in comp.lang.perl.misc:
>
>
> FWIW, I found a bug in bugs.perl.org that seems related to the
> error message in the subject line:
>
> http://rt.perl.org/rt3/Ticket/Display.html?id=30582
>
> In particular, one of the follow ups shows a one-liner that elicits
> the bug:
>
> $ perl -MTie::Hash -we'tie %x,"Tie::StdHash"; sub foo:lvalue {$x{foo}} foo=1'
> Can't return a temporary from lvalue subroutine at -e line 1.
Well, that's exactly your problem, isn't it?
> As far as I can tell, there doesn't seem to be much momentum to
> get this bug fixed (but I know little of the process, so I could
> be way off-base on this).
I don't know the process either, but
http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
has some statistics and other info about bug resolution.
I would imagine that many bugs are resolved not by individual solutions
but by general cleanup actions (sorry, refactoring), perhaps triggered
by the hunt for a different, superficially unrelated bug.
It may be that the frequency of the event "lvalue sub meets tied hash"
is underestimated at first view. Lvalue subs lack control over what
gets stored, and tying offers that control, so "lvalue sub searches
control, finds tied hash" may describe the event better. But that is
not immediately obvious.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 20 Jul 2005 10:46:42 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <dbla2i$g3r$3@mamenchi.zrz.TU-Berlin.DE>
Tassilo v. Parseval <tassilo.von.parseval@rwth-aachen.de> wrote in comp.lang.perl.misc:
> Also sprach J Krugman:
>
> > FWIW, I found a bug in bugs.perl.org that seems related to the
> > error message in the subject line:
> >
> > http://rt.perl.org/rt3/Ticket/Display.html?id=30582
> >
> > In particular, one of the follow ups shows a one-liner that elicits
> > the bug:
> >
> > $ perl -MTie::Hash -we'tie %x,"Tie::StdHash"; sub foo:lvalue {$x{foo}} foo=1'
> > Can't return a temporary from lvalue subroutine at -e line 1.
> >
> > As far as I can tell, there doesn't seem to be much momentum to
> > get this bug fixed (but I know little of the process, so I could
> > be way off-base on this).
>
> Your post here added enough momentum. :-)
>
> The problem was indeed as I described in
> <slrnddp6jr.s2.tassilo.von.parseval@localhost.localdomain>.
> I submitted a patch for it which got applied roughly eight minutes ago.
> Applied means it's now in the development branch 5.9.x. But I assume it
> will also be in 5.8.8 whenever it's due at which point you can start to
> make use of it to your heart's desire.
[clap, clap, clap, bravo]
Open software in action. Can't beat it.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Wed, 20 Jul 2005 11:20:34 +0000 (UTC)
From: J Krugman <jkrugman345@yahbitoo.com>
Subject: Re: "Can't return a temporary from lvalue subroutine..."
Message-Id: <dblc22$phd$1@reader2.panix.com>
In <slrndds776.k4j.tassilo.von.parseval@localhost.localdomain> "Tassilo v. Parseval" <tassilo.von.parseval@rwth-aachen.de> writes:
>The problem was indeed as I described in
><slrnddp6jr.s2.tassilo.von.parseval@localhost.localdomain>.
>I submitted a patch for it which got applied roughly eight minutes ago.
>Applied means it's now in the development branch 5.9.x. But I assume it
>will also be in 5.8.8 whenever it's due at which point you can start to
>make use of it to your heart's desire.
Awesome! Thank you!
j
--
To s&e^n]d me m~a}i]l r%e*m?o\v[e bit from my a|d)d:r{e:s]s.
------------------------------
Date: 20 Jul 2005 10:41:47 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: copy contructor
Message-Id: <dbl9pb$g3r$2@mamenchi.zrz.TU-Berlin.DE>
[this article supercedes an earlier version to correct a coding error]
Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Anno Siegel (anno4000@lublin.zrz.tu-berlin.de) wrote on MMMMCCCXL
> September MCMXCIII in <URL:news:dbj11n$57m$1@mamenchi.zrz.TU-Berlin.DE>:
> %%
> %% That's why I'm preaching that accessors must be documented. An inheriting
> %% class must know what they are and how to override them.
>
>
> But that's breaking encapsulation. 'Accessor's are only a meaningful
> term for the class that defines the accessor - any other class should
> not have to know what is an accessor or not. With proper encapsulation,
> a class, when viewed from the outside, is a black box. The box keeps
> state, and it has some methods where you can poke at the box. Whether
> a method happens to return an attribute or not should be irrelevant.
> If you need to know, you break encapsulation.
True. The fundamental breach in encapsulation is that Perl objects
have a life of their own, they aren't opaque structures (nothing but
objects) like in most OO languages. That flaw can't be removed by
argumentation and paradigm shifts, it's here to stay.
The distinction in accessors and non-accessors can help in making
that breach manageable, not make it go away.
By publishing which methods are accessors and which aren't, you are
making a considerable implementational commitment. In particular,
you can't make an accessor out of what used not to be one. Your
client's code would break.
> How do you subclass a class that keeps state, but doesn't provide
> an accessor?
>
> package Angry::Snake;
>
> sub new {
> bless \do {my $c = int rand 5} => shift;
> }
>
> sub poke_it_with_a_stick {
> my $snake = shift;
> $snake -> attack if $$snake -- < 0;
> }
>
> sub attack { ... }
Mmmmm, nice snakey, pretty snakey, I'm not poking, okay...?
No, you can't inherit ->poke_with_a_stick. That's because it's an
accessor, even if it is not a field accessor in the usual sense.
It accesses (de-references) the object, and so it's out.
If Angry::Snake were written with an overridable method (->snake)
guarding the access, like this:
sub poke_it_with_a_stick {
my $snake = shift;
$snake -> attack if ${ $snake->snake} -- < 0;
}
sub snake { shift }
things would be different. Here's a less aggressive snake that doesn't
always notice when it is poked:
package Sleepy::Snake;
BEGIN { our @ISA = 'Angry::Snake' }
sub new {
bless {
sleepiness => 0.5,
snake => Angry::Snake->new,
}, shift;
}
sub snake { $_[ 0]->{ snake} }
sub poke_it_with_a_stick {
my $sn = shift;
$sn->SUPER::poke_it_with_a_stick if rand > $sn->sleepiness;
}
sub sleepiness {
# $_[ 0]->{ sleepiness} = shift if @_ > 1; # this is in error
$_[ 0]->{ sleepiness} = $_[ 1] if @_ > 1;
$_[ 0]->{ sleepiness};
}
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Wed, 20 Jul 2005 09:35:24 -0300
From: Admin <me@privacy.net>
Subject: How to send a query to the browser from time to time?
Message-Id: <op.st7o9axpuoj956@charles>
I am creating a chat application like Messenger for the web (using the
browser) and I'm wondering if there is a way to
receive new messages from time to time from the server other than
refreshing the page each 5 sec.
If there were a way to have the server-side application send new messages
to the browser this would be awesome because it
would save dramatically on bandwidth. The application would consume
bandwidth only when there are new messages. There
would be no communication client-server until people write a new message.
Do you know if it's possible?
--
Thanks,
Admin.
Want to buy me a book? http://tinyurl.com/78xzb :)
------------------------------
Date: Wed, 20 Jul 2005 13:00:05 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: How to send a query to the browser from time to time?
Message-Id: <Xns96995B8F8B7A9asu1cornelledu@127.0.0.1>
Admin <me@privacy.net> wrote in news:op.st7o9axpuoj956@charles:
> I am creating a chat application like Messenger for the web (using the
> browser) and I'm wondering if there is a way to
> receive new messages from time to time from the server other than
> refreshing the page each 5 sec.
Please note that this is not a Perl question.
> If there were a way to have the server-side application send new
> messages to the browser this would be awesome because it
> would save dramatically on bandwidth. The application would consume
> bandwidth only when there are new messages. There
> would be no communication client-server until people write a new
> message.
If you want, you can search for "server push" using Google.
I do not see what bandwidth has anything to do with any of this.
Anyway, none of this is topical here.
Sinan
--
A. Sinan Unur <1usa@llenroc.ude.invalid>
(reverse each component and remove .invalid for email address)
comp.lang.perl.misc guidelines on the WWW:
http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
------------------------------
Date: Wed, 20 Jul 2005 11:30:54 GMT
From: samwyse <dejanews@email.com>
Subject: problem using both Memoize::Expire and DB_File
Message-Id: <OBqDe.590$LF.25@newssvr27.news.prodigy.net>
Following the example in the Memoize::Expire perldoc, I tried to set up
a disk-backed cache with an expiration time. It doesn't seem to want to
work for me. Below is my test script and its results. Subroutine
'test0' is memoized via a simple cache, 'test1' uses a disk-backed
cache, 'test2' uses an expiring cache, and 'test3' uses both. The test
program calls each subroutine twice and the program itself is run twice;
the problem is evident during the first pass of the second run, where
'test1' doesn't get invoked (as expected, since the value is found in
the disk-based cache) but 'test3' is invoked. (Specifically, the
message "inside test3()" shouldn't be seen in loop 1 of the second run.)
Using 'od -c' against the db files indicates that the data for 'test3'
is never written to disk. Google doesn't seem to turn anything up,
except for lots of copies of the perldoc. I'm running this on a Sun
under Solaris 2.6. My Perl version is 5.6.X (Sorry, I forgot to note
the exact value and I'm at home right now.), and upgrading to 5.8 would
be difficult on this server.
Later today I plan to dig into the internals of Memoize::Expire. Until
then, thanks for any assistance.
Script started on Tue Jul 19 17:21:03 2005
$ cat test-me.pl
#!/usr/bin/perl
use strict;
use Memoize; # Make your functions faster by trading space for time
use Memoize::Expire; # automatic expiration of memoized values
use DB_File;
$Memoize::Expire::DEBUG = 1;
my $lifetime = 60;
sub test0 {
print "inside test0()\n";
return "test0($_[0])";
}
my %test0_hash;
memoize 'test0',
LIST_CACHE => 'FAULT',
SCALAR_CACHE => [ HASH => \%test0_hash ];
sub test1 {
print "inside test1()\n";
return "test1($_[0])";
}
# Set up persistence
tie my %test1_dbfile => 'DB_File',
'/tmp/test1.db', O_CREAT|O_RDWR, 0666;
# Set up memoization, supplying expiring persistent hash for cache
memoize 'test1',
LIST_CACHE => 'FAULT',
SCALAR_CACHE => [ HASH => \%test1_dbfile ];
sub test2 {
print "inside test2()\n";
return "test2($_[0])";
}
my %test2_hash;
# Set up expiration policy, supplying persistent hash as a target
tie my %test2_cache => 'Memoize::Expire',
LIFETIME => $lifetime, # In seconds
HASH => \%test2_hash;
# Set up memoization, supplying expiring persistent hash for cache
memoize 'test2',
LIST_CACHE => 'FAULT',
SCALAR_CACHE => [ HASH => \%test2_cache ];
sub test3 {
print "inside test3()\n";
return "test3($_[0])";
}
# Set up persistence
tie my %test3_dbfile => 'DB_File',
'/tmp/test3.db', O_CREAT|O_RDWR, 0666;
# Set up expiration policy, supplying persistent hash as a target
tie my %test3_cache => 'Memoize::Expire',
LIFETIME => $lifetime, # In seconds
HASH => \%test3_dbfile;
# Set up memoization, supplying expiring persistent hash for cache
memoize 'test3',
LIST_CACHE => 'FAULT',
SCALAR_CACHE => [ HASH => \%test3_cache ];
for (1..2) {
print "*** loop $_\n";
print "--- test0(1) => ", scalar test0(1), "\n";
print "--- test1(1) => ", scalar test1(1), "\n";
print "--- test2(1) => ", scalar test2(1), "\n";
print "--- test3(1) => ", scalar test3(1), "\n";
}
$ rm /tmp/test*.db
$ ./test-me.pl
*** loop 1
inside test0()
--- test0(1) => test0(1)
inside test1()
--- test1(1) => test1(1)
>> Exists 1
Not in underlying hash at all.
inside test2()
>> Store 1 test2(1)
--- test2(1) => test2(1)
>> Exists 1
Not in underlying hash at all.
inside test3()
>> Store 1 test3(1)
--- test3(1) => test3(1)
*** loop 2
--- test0(1) => test0(1)
--- test1(1) => test1(1)
>> Exists 1
Time to live for this item: 60
(Still good)
>> Fetch cached value for 1
>> (ttl: 60, nuses: 65535)
--- test2(1) => test2(1)
>> Exists 1
Time to live for this item: 60
(Still good)
>> Fetch cached value for 1
>> (ttl: 60, nuses: 65535)
--- test3(1) => test3(1)
$ ./test-me.pl
*** loop 1
inside test0()
--- test0(1) => test0(1)
--- test1(1) => test1(1)
>> Exists 1
Not in underlying hash at all.
inside test2()
>> Store 1 test2(1)
--- test2(1) => test2(1)
>> Exists 1
Not in underlying hash at all.
inside test3()
>> Store 1 test3(1)
--- test3(1) => test3(1)
*** loop 2
--- test0(1) => test0(1)
--- test1(1) => test1(1)
>> Exists 1
Time to live for this item: 60
(Still good)
>> Fetch cached value for 1
>> (ttl: 60, nuses: 65535)
--- test2(1) => test2(1)
>> Exists 1
Time to live for this item: 60
(Still good)
>> Fetch cached value for 1
>> (ttl: 60, nuses: 65535)
--- test3(1) => test3(1)
$ exit
script done on Tue Jul 19 17:21:28 2005
------------------------------
Date: 20 Jul 2005 13:13:20 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: using passwd in a perl script
Message-Id: <dblilg$k4i$1@mamenchi.zrz.TU-Berlin.DE>
Joe Smith <joe@inwap.com> wrote in comp.lang.perl.misc:
> yo wrote:
> > solved the problem with
> >
> > @cryptpasswd = ("echo $password | passwd $username --stdin");
> > system("@cryptpasswd");
>
> That's not right. The last line should be without quotes:
>
> system(@cryptpasswd);
>
> Better yet, a simple scalar fits your needs:
>
> $cryptpasswd = "echo $password | passwd $username --stdin";
> system $cryptpasswd;
This effectively publishes the password on most Unix systems. A user
who catches the "echo" in ps will also see the password. Your system
commands, including their parameters, are open for everyone to see,
something to think of when using system(). It is safer to open a pipe
to the passwd command (untested):
open my $pwd, '| passwd $username --stdin' or die "passwd command: $!";
print $pwd $password;
close $pwd or die "passwd returned $?";
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
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 8263
***************************************
