#!/usr/local/bin/perl

    use CGI::Carp qw(fatalsToBrowser);
    print qq|Content-type: image/png \n\n|;

    use GD;

    # create a new image
    my $im = new GD::Image(100,100);

    # allocate some colors
    my $white = $im->colorAllocate(255,255,255);
    my $black = $im->colorAllocate(0,0,0);       
    my $red = $im->colorAllocate(255,0,0);      
    my $blue = $im->colorAllocate(0,0,255);

    # make the background transparent and interlaced
    $im->transparent($white);
    $im->interlaced('true');

    # Put a black frame around the picture
    $im->rectangle(0,0,99,99,$black);

    # Draw a blue oval
    $im->arc(50,50,95,75,0,360,$blue);

    # And fill it with red
    $im->fill(50,50,$red);

#   my $courier = GD::Font->load('/home/trust/etrust.pro/cgi-bin/trust
+/LiberationSerif-Bold.ttf') or die "Can't load font";
    $im->string(gdSmallFont,5,10,"Testing",$black);

    # make sure we are writing to a binary stream
    binmode STDOUT;

    # Convert the image to PNG and print it on standard output
    print $im->png;  

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'm a co-maintainer of Locale::Maketext::Lexicon and I'd like to make a change to the format of the .po file created by Locale::Maketext::Extract / xgettext.pl.

Currently it writes out each entry in the .po file as:

    #: $filename_1:$line $filename_2:$line ...
    #. (vars passed to maketext sub)
    msgid "string to translate"
    msgstr ""

However, when I edit the file with POEdit, it rewrites the file as:

    #. (vars passed to maketext sub)
    #: $filename_1:$line 
    #: $filename_2:$line ...
    msgid "string to translate"
    msgstr ""

... which causes a large unneccessary diff.

Looking at the gettext manual, having the vars comment before the file location seems to be consistent, but having the file references on new lines is controlled by the option --no-wrap. However, Locale::Maketext::Extract already wraps the msgids, so the behaviour is currently inconsistent.

What I'd like to know is: can I just make this change, or would it affect you with whatever client you use for editing the .po files? Should I be providing output format options instead?

thanks

Clint

Two buttons [-] and [^] appear on the header of CB nodelet.

• [-] folds/unfolds chatterbox
• [^] detach/attach chatterbox from nodelet table. You can move detached chatterbox over screen dragging it by it's header.

I've tested it in FF3 only

Update: a couple of bugs was fixed

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.