I'm trying to understand lvalue subs on the opcode level and would appreciate some help. For the motivation please read Another approach to extend lvalues ?

here the perlcode I want to analyze

my $scalar;
test();

sub normal :lvalue {
    proxy();
}
sub proxy :lvalue  {
    $scalar;
}

sub nlv {
    my $x="not lvalue"
}

sub test {
    nlv();
    normal=42;
    print $scalar;
}

Well I'm still struggling to understand the opcodes, but please look at the lines 6-a and k.

my interpretation is that by assigning a value to a lvalue-sub the steps are:

1. cache the value
2. call the lvalue-sub, which returns a var by refrence
3. assign the cached value to this var

so even on the level of the opcodes the lvaluesub has no chance to know which value will be assigned to the variable he returns ... Correct?

I'm a little bit confused about line j, what means "rv2cv" (it's the first time this happens right before a sub call)?

I googled through perlguts op.c and concise.pod but can't get a sufficient answer...

Thanx Rolf

* I know with 5.10 I wouldn't need to do it manually but I'm sticking on 5.8.8. I have to figure out how to safely install two different perl-versions on the same system, so that I can maintain both with aptitude.

I'm doing graph traversal and calculating the Jaccard distance on each pair of vertices. Calculating intersection and union are consuming 98% of my processing time.

I've tried Set::IntSpan, Set::Array and List::Compare, but they are all even slower than my own code. Is there a VERY fast (maybe implemented in C) way to calculate intersection and union on two arrays? Just for interest, my implementation is ($in and $jn are array refs of positive integers):

sub get_int_uni {

        my ($in, $jn) = @_;
        
        my (%int, %uni);
        for my $i (@$in) {
                $uni{$i}++;
        }
        for my $j (@$jn) {
                $int{$j}++ if $uni{$j};
                $uni{$j}++;
        }
        return ((scalar keys %int), (scalar keys %uni));
}

I am in the process of moving a Perl/Tk text editor to Perl/Tkx.

The following code works fine on Windows XP ActivePerl 5.8/5.10 but my OS X testers are getting this error:

invalid command name "tk::text" at tkx-test-1.pl line 24. (There's a FIXME: on the offending line.)

I've searched on this but no results that seemed applicable.

Thanks for any and all responses.

use warnings;
use strict;

use Tkx;

my $VERSION = "1.0.0";
my ($mw, $tw);
$mw = Tkx::widget->new(".");

$tw = $mw->new_tk__text( # FIXME: Barfs on OS X
    -width => 40, 
    -height => 10 );

$tw->g_grid;
$tw->g_focus;

$tw->insert("1.0", "If you can read this it worked.");

Tkx::MainLoop();
exit;

-> more testexec*
::::::::::::::
testexec.pl
::::::::::::::
#!/usr/bin/perl
system("testexec2.pl");
print "Done $0\n";
::::::::::::::
testexec2.pl
::::::::::::::
#!/usr/bin/perl
exec($^X,"testexec3.pl") or print "exec failed - $!\n";
print "Done $0\n";
::::::::::::::
testexec3.pl
::::::::::::::
#!/usr/bin/perl
`sleep 3`;
print "Done $0\n";

FYI: I'm trying to avoid using system() instead of exec() because then I open a can of worms regarding the quoting of arguements to the programs being exec()'d (the arguements themselves may contain quotes and/or spaces, and going through the shell on the two different OS's is a whole lot of extra code I can avoid if exec() would just act right :-)

Aaron

I have a script in which dumps a lot of output to the shell. When I do use the ampersand (&) to run the script as a background process it still prints the same output to the shell. So my questions is: Is it possible for the script to know that it has been put in the background by ampersand so that it can silence itself (re-direct STDOUT/STDERR TO /dev/null)?

Update: Thanks everyone for great feedback. I got what I was looking for and I ended up with a check that was in almuts link:

    171 if (!open(TTY, "/dev/tty")) {
    172     print "no tty\n";
    173 } else {
    174     my $tpgrp = tcgetpgrp(fileno(*TTY));
    175     my $pgrp = getpgrp();
    176     if ($tpgrp == $pgrp) {
    177         print "foreground\n";
    178     } else {
    179         print "background\n";
    180     }
    181 }

switch ( $foo ) {
    case ( tr/I/I/ == 1 ) { $bar = 'low' }
    case ( tr/I/I/ == 2 ) { $bar = 'med' }
    case ( tr/I/I/ == 3 ) { $bar = 'high' }
    else { warn "Bad $_\n" }
}

Use of uninitialized value $_ in transliteration (tr///)

(Update: Because switch doesn't set $_, it filters the source code - in this case "insanely".)

Update: Thanks kyle and jeffa, the lesson is learned - don't use Switch. (jeffa's solution indeed doesn't work - which surprised me)

Update2: moritz has it right, use the (5.010) given-when construct:

given ( $foo ) {
    when ( tr/I/I/ == 1 ) { $bar = 'low' }
    when ( tr/I/I/ == 2 ) { $bar = 'med' }
    when ( tr/I/I/ == 3 ) { $bar = 'high' }
    default { $bar = "drat" }
}

In OOP it really bothers me to write use getter/setters instead of lvalues for simple attributes like in other languages.

As shown in PBP, the problem with lvalue is, that if ever you need a wrapper to control the setting of the attribute you can only rely on tieing the variable or you have to change the API and refactor...

Which is not really an issue of ugly syntax, I found at least two cpan-modules showing that a posteriori FETCH and STORE can be done in a very clean, readable and maintainable syntax. e.g. in Class::Closure

I did some benchmarks showing that accessing a tied variable via lvalue is 4-5 times slower than with a getter sub! : (

Now I "superfound" Re^3: Class::Accessor and Damian's PBP and was quite exited to see Contextual::Return...

So, very curious about how TheDamian fixed the problem, I took a look into the source:

  $impl = tie $_[0], 'Contextual::Return::Lvalue',     
            $subname => $handler, args=>$args;

Do I get it right, it's just another sugar for Tieing? 8 (

Well I don't know how big the trade-off of wrapping lvalues is in other languages ...

But shouldn't this general "banning" of lvalues better be replaced by the rule

It's acceptable to use them as long you are aware that later changing will result in a call-overhead of 400%!

Time critical calls should be done with getter/setters!

???

BTW: Is there any activity to speed up tie? I don't see why the calling mechanism for FETCH and STORE needs to undergo the same slow dynamic ways OOP needs. A kind of "tie :static" might really solve the problem!

Hopefully looking for a serious discussion of this somehow "religious" matter..

  my $blksize  = int ($filesize / 10);
  my $num_read = sysread(SRC, $buffer, $blksize);

Yesterday, I found two vulnerabilities in cbstream that have been there from almost the start. As you may know, cbstream (then called cbupstream) is a bridge that allows you to talk on the perlmonks chatterbox using any IRC client. This requires a login: you have to tell to cbstream about your perlmonks account name and password. There are two modes of login in cbstream: normal login remembers your account details only until you leave the IRC channel, whereas persistent login remembers them until the bridge is shut down and recognizes you when you enter the channel again. This means cbstream has to know someone entering the channel is the same user as the one who logged in persistently, but the mechanism how it did this was buggy. This bug could have allowed someone to send public perlmonks chatter or private messages in the name of anyone who used the persistent login feature.

I have temporarily disabled the persistent login feature yesterday, so now cbstream users have to login each time they enter the channel. This closes the vulnerability.

Kudos to tomaw and jilles who educated me on the workings of the hyperion irc server and thus found these bugs.

The good news is that there is a secure way to implement persistent login with very little user-visible change. I'll do this when I have time (don't hold your breath) and post an update as a reply here when I've done so.

I think we need a place for non-programmer monks.

This idea comes from a non-programmer monk's cry. Personally, I don't agree some gurus' reply. Hacking, writing modules for CPAN or even program in perl ought not to be a requirement for join perlmonks. Some monks have been away from perl for some time would like to stay here but don't mean they still like to write code in perl. If we write a poem in perl, we could post on Poetry , if we write a snippet, we post it on Snippets, but if we named our puppy in perl or simply want to share a joke to monks, where do we post?

Meditations ? Perl News ? It seems a alternative, but the name keeps many people away.