I have a bunch of C-strings with or without a trailing \0. I want to make them available in Perl as read-only variables. When the perl SV is destroyed the string must not be freed obviously.

Do I need to make those variables magic? Or is there a simpler way?

If I need magic, do I need to implement all of the 8 MGVTBL members? What if some of them are NULL?

I think I need only an svt_free function that does:

        SvPVX(var) = NULL;
        SvCUR(var) = 0;

Is this correct?

I have read somewhere that perl strings do not need the trailing \0 byte. But for some reasons it is normally allocated. Why? Is it necessary? What can happen if there is no trailing \0?

Thanks,
Torsten

use Tk;

my $mw = Tk::MainWindow->new;
my $fr = $mw->Frame(-label=>"myframe");
my $l1 = $fr->Label(-text=>"label1");
my $l2 = $fr->Label(-text=>"label2");
$fr->grid;
$l1->grid;
$l2->grid;

MainLoop;

#!/usr/bin/perl -w

use HTML::TokeParser;
use LWP::Simple;
use Encode;

sub getTitle {
    my $stream = HTML::TokeParser->new(@_);
    if(defined $stream->get_tag("title")) {
        my $title = $stream->get_trimmed_text;
        return encode_utf8($title);
    }
}

my $browser;
my $url = $ARGV[0];

BEGIN {
    use LWP::UserAgent;
    $browser = LWP::UserAgent->new;
    $browser->agent("Mozilla/5.0");
    $browser->timeout(15);
}

my $resp = $browser->get($url);

die "Error getting $url: ", $resp->status_line, "\n"
    unless $resp->is_success;

die "Not HTML, it's ", $resp->content_type, "\n"
    unless $resp->content_type eq 'text/html';

if(my $title = getTitle($resp->content_ref)) {
    print "Title: '$title'\n";
}

What I have been trying to do this morning is understand how the Tree::Simple module works specifically. I want to take an input file that contains a delimited file of child/parents, build a tree, and output a flattened version.

If I had:

apple:fruit
granny smith:apple
rotten granny smith:granny smith
.
.
.
orange|fruit

Fruit:Apple:Granny Smith:Rotten Granny Smith
Fruit:Orange

The example on the module page for Tree::Simple is helpful, but I am trying to figure out how to read in my input file. I am assuming I'd use a while loop. Any tips on tweaking the below code?

use warnings;
use strict;
use Tree::Simple;

  # make a tree root
my $tree = Tree::Simple->new("0", Tree::Simple->ROOT);

  # explicity add a child to it
$tree->addChild(Tree::Simple->new("1"));

  # specify the parent when creating
  # an instance and it adds the child implicity
my $sub_tree = Tree::Simple->new("2", $tree);

  # chain method calls
$tree->getChild(0)->addChild(Tree::Simple->new("1.1"));

  # add more than one child at a time
  $sub_tree->addChildren(
                         Tree::Simple->new("2.1"),
                         Tree::Simple->new("2.2")
                         );

  # add siblings
$sub_tree->addSibling(Tree::Simple->new("3"));

  # insert children a specified index
$sub_tree->insertChild(1, Tree::Simple->new("2.1a"));

  # clean up circular references
$tree->DESTROY();

$tree->traverse(sub {
    my ($_tree) = @_;
    print (("\t" x $_tree->getDepth()), $_tree->getNodeValue(), "\n");
});

Here is what I have so far:

use warnings;
use strict;
use Tree::Simple;

my $tree = Tree::Simple->new("0", Tree::Simple->ROOT);

while(<DATA>) {
    chomp;
    my ($child, $parent) = split ":";

    my $sub_tree = Tree::Simple->new("$parent", $tree);

    $sub_tree->addChild(Tree::Simple->new("$child"));

$tree->DESTROY();

}

$tree->traverse(sub {
    my ($_tree) = @_;
    print (("\t" x $_tree->getDepth()), $_tree->getNodeValue(), "\n");
});


__DATA__
apple:fruit
granny smith:apple
rotten granny smith:granny smith
orange:fruit

fruit
        apple
apple
        granny smith
granny smith
        rotten granny smith
fruit
        orange

#!/usr/local/bin/perl
use strict;

#Create Socket Connection
use IO::Socket::SSL qw(debug3);
my $sock = IO::Socket::SSL->new(
    PeerAddr => 'LOCALHOST',
    PeerPort => '6999',
    SSL_version => 'SSLv3',
    SSL_cipher_list => 'COMPLEMENTOFDEFAULT',
    SSL_error_trap => 1 );
die "Could not create socket: " . IO::Socket::SSL::errstr() unless $so
+ck;

#Get the message
my $socket_message = shift;

print "Message Rec: $socket_message\n";

#Convert the hex message to a string
$socket_message = (hex2string($socket_message));

print "Translated Message: $socket_message\n";

print "*Sending Message*\n";

print $sock $socket_message;

print "*Message Sent*\n";

my $response;

sleep 4; #I wish there was a better way to do this!

#This times out the function so I can get everything from the server.
$SIG{ALRM} = sub { die "timeout" };
eval {
    alarm(1); #Change this 1 to something else for more time.
    while(1){
    sysread($sock, $response, 4000);
}
alarm(0);
};



close($sock);

print "Server Response: $response\n";

$response = (string2hex($response));

print "Server Response: $response\n";

print "Transaction Completed!";

#Hex Functions
sub string2hex
{
        my $in = shift;
        join(' ', map { sprintf("%02X", ord($_)) } split(//, $in));
}

sub hex2string
{
        my $in = shift;
        join('', map { &convert_word($_) } split(/\s+/, $in));
}

sub convert_word
{
        my $word = shift;

        my $rv = '';

        if (length($word) == 2)
        {
                $rv = chr(hex($_));
        }
        elsif (length($word) == 1)
        {
                $rv = $_;
        }

        $rv;
}


exit;

While playing around today with the combination of eval and require, I've discovered that require adds the modules it finds to %INC whether or not they can be fully compiled..

Since some modules don't tolerate repeated reloading and a broken module may compile partially (e.g. BEGIN blocks that make resource intensive DB connections), this makes perfect sense. We don't want to reload modules over and over, whether broken or not.

However, it has one not-so-nice side effect: I can't reliably use require to tell if a module is successfully loaded. My most common use of eval("require $module") is to dynamically include plugins. In general, I only want to enable functionality if the plug-in module compiles successfully.

All will be well and good if my call to eval("require $somePlugIn") just happens to be the first attempt to require this particular module and often it is. On the first attempt eval "require $somePlugIn" obligingly sets $@ to a list of compilation problems. However, successive calls only test to see if $somePlugIn is in %INC and, of course, return true.

The problem comes when a plug-in module is used in more than one place. Two scenarios come to mind: (a) two independently developed parts of an application rely on the same plugin or (b) the module is loaded via Test::More::require_ok and also in the modules being tested. The second scenario actually occurred earlier this afternoon and is the motivation for this question. A call to Test::More::require_ok gave me a false "ok" because it came after a use statement for a module that had also called require for the same plug-in.

When two different location in code, try to require the module, the first place to require it sees the error, but other places that try to require it dynamically via eval "require $somePlugIn ..." do not. They only see the true return value.

Now I could try to prevent problems by setting up my own special version of require. Before trying to load the module using CORE::require, it checks to see if the module is in the broken list and if so returns the original error rather than try to reload it. But this seems rather leaky to me: I can't guarantee that every module will use my special version of require: any module loaded before the module that contains the definition of the special require will use CORE::require, not my special function, and won't get added to my %BROKEN list.

I could also try social controls: A team decision that thou shalt use module Foo::Bar to load all plugins. But that only addresses code developed in house. It increases the likelihood that clients writing their own plug-ins will make a mistake that interferes with our ability to track broken modules. It limits our use of 3rd party modules since they don't necessarily play by our rules (e.g. Test::More). Even in-house social controls are not the perfect solution. Mistakes happen and tracking them down is time consuming. The "shape up or ship out" attitude isn't really the best approach either. Firing repeat offenders isn't really an option if they do a lot of other things "just right".

I am wondering if there is a non-hackish way to tell if a particular module in %INC compiled successfully. By non-hackish, I mean that:

• there is no risk of the broken code being re-executed.
• it isn't leaky or enforced by social controls.

I'm hoping someone will tell me that there is some sort of internal table I can get access to rather than maintaining my own %BROKEN table. Or that maybe someone who knows more than I can suggest a non-leaky way to wrap CORE::require so that I can keep my own table. Or even some totally different approach that makes this a non-problem.

Thanks in advance, beth

I'm currently using Perl to do performance test coordination to benchmark various aspects of a system. The typical cycle is to identify something that you want to generate a scatter graph for (i.e. X/Y plot), and then the items on the X and Y axes. For example "messages per second" on Y, and "processing units" on X. The test coordinator will execute a sequence of tests, incrementing the X value for each test run. Each test run generates a new plot point (X,Y value). This is actually a slight simplification as each test run generates many (X,Y) values, but for different system aspects. For example for a given X we would get both "messages per second" and "cpu utilization of server app".

The desired end product of this process is a nice looking graph somewhere (e.g. web page).

At the end of the test run process I have a bunch of single line entries in a logfile which are the test results. I then have to go through an annoying time consuming process to put these in MS excel, and make graphs. Obviously there are a plethora of much better solutions than this.

Thinking a bit outside the obvious desire to "automate things", it would be nice to have all of the data from these important tests nicely encapsulated and self-describing in a text file. That way it doesn't become a "junk file" on some computer. Another important aspect would be having something that could ingest this data, and given suitable graphing metadata, transform this into a graph, or, in my particular case, transform it into javascript which will render it on a web page (when hooked up to a suitable graph package, like YUI). Thus, I'm looking at this as a classic data representation and transformation problem (for which Perl is perfectly suitable).

My thought was to have a file format that encapsulated a single "test run". The file format would be text, and self-describing. It would have metadata to describe the conditions of the test (e.g. title, hardware, whatever), as well as the data from successive runs. Using this file as input, we would have some sort of additional specification to generate a graph which would have to select the columns and range, as well as handle things like multiple graph plots, etc. The target output rendering would be (*gasp*) javascript, which would be an encapsulated json data object inside a web page presented by some graph package (Yahoo has a nice one that is being developed by their YUI group).

Thus I'm really not necessarily interested in the graphing portion of things (since there are probably many solutions to this old part), but more interested in the middle "transformation" part and the input file formats. The first input file format, as I described, is the test run data container, and the second input file format is the graph metadata container. Of course I'll be using Perl to implement and do all of the transformation work.

Note, I see XML as too heavyweight for such a simple thing.

Now that I've described what I'm after, I'm hoping that some of you will say "hey, that sounds kind of like xyz" (where xyz is the Perl library that does this sort of thing). Alternatively, identifying technology to handle pieces of the whole problem in a nice way is helpful (e.g. use YAML for the file formats so the file formats are generally useful outside of Perl). I could obviously write my own, but am guessing someone has solved this problem in a nice way already.

Since writing On Coding Standards and Code Reviews, several people have asked me:

• Is it worth it to have a coding standard and to perform code reviews?

I should have thought about this earlier because it would have helped focus our coding standard effort on tangible business benefits.

To remedy that oversight, I list below what I see as sound reasons for having a coding standard and for performing code reviews. I'm posting my notes here to gain some useful early feedback.

Why Have a Coding Standard?

Successful software tends to live a long time: bugs are fixed; new features are added; new platforms supported; and the software adapted to new markets. That is, successful software development is a long term activity. If you plan to be successful, you should therefore plan for your code base to be maintained by a succession of many different programmers over a period of many years. Not planning for that is planning to fail.

This is the primary reason why you want a company coding standard: to make long term code maintenance easier.

Notice that if you choose instead not to mandate a coding standard, you'll likely end up with an informal one anyway, as some strong personality in your organisation fills the vacuum by evangelizing their own set of pet coding rules.

The goals of a good coding standard are:

• Improved code maintainability.
• Improved code quality. In particular: testability, supportability, portability, security, efficiency, robustness.
• Improved development speed. Your developers don't need to make all decisions starting from first principles.
• Better teamwork. Don't waste time with needless debates. Spend your creative energy on things that matter.
• Better performance under pressure. Under stress, people fall back on what they've been trained to do.
• Fewer bugs. Good standards should minimize common coding mistakes.
• Shallower learning curve and useful training for new hires -- if your standard mandates proven, well-known idioms and style from the programming mainstream.

The above list represents real business benefits which should help you decide what to put in your coding standard and what to leave out. My experience here is that shorter is definitely better. The longer your coding standard document, the less likely that it will be read, understood and followed.

Why Perform Code Reviews?

• Find and fix defects early.
• Code review often proves more cost effective than testing. (See, for example, The Case for Peer Review).
• Good mentoring/training/learning/team building, especially for new hires.
• Gives broader experience to team members.
• Makes it easier for one team member to maintain another's code.
• Improve overall quality of the code.
• Enforce coding standards.

Of course, code reviews are not free and there is an opportunity cost in that time spent reviewing code means less time spent on other activities.

Monks,

What is the current "preferred" way to do RPC calls to a different machine with Perl? Is SOAP still the main option?

A few years ago I was using a hand-rolled method of remote procedure calls. It involved Storable and some http requests. Oh, by the way, it sucked. Lots of AUTOLOAD and fiddling with @INC lead to code that was difficult to debug and maintain.

However, it did mean that code like the following would work whether the modules it used and the methods it called were "local" or "remote":

use My::Module;

my $obj = My::Module->new( %args );
foreach my $item ( $obj->foo_items )
{
  $item->do_it;
}# end foreach()

At the time we were using Class::DBI for a database ORM. A "stub" base-class on the "client" machines would handle the requests and responses, allowing us to use the same class names on the "client" machines as we did on the remote machine. This worked out very well, but because of the statelessness of http, we could not use database transactions. We used $Data::Dumper::Deparse semantics to serialize a coderef containing the transaction code, and then execute via eval($str) on the remote server. Again - this worked, but it was difficult to debug and maintain.

I wonder how this might work out a bit better at this time - with Moose now and with Perl6 arriving soon.

Intro

My young son has me playing the Chutes and Ladders board game with him. While fun for him, this simple game of chance provides little stimulation (for an adult) after the first few spins of the dial. So, being a geek, I coded up some Perl to dump out how many spins it takes to win a game, how often a player climbs a specific ladder, etc. You know -- absolute crucial knowledge for parents.

Now, I'll be able to impress with nuggets such as: "You'll most likely win in 22 moves! But, don't bet on it because that only happens 2.5% of the time".

Obvious Stats

"10%" means that only about 10% of games will end in 15 moves or less. Similarly, "90%" means that 90% of games will end in 73 moves or less.

The maximum number of moves seems to be infinite. In a sample of 1 million games, the maximum number of moves was 399; after 2 million, it was 437. Maybe there's an asymptote, I don't know. In any case, I think it is practically impossible to be that unlucky. Update: Refer to esper's reply below for more details.

The Code

This program merely dumps out raw data. Statistical analysis software sold separately. Batteries not included.

Other observations

Typical Histogram

Here is a sample histogram of the number of moves for 1 million games:

What fascinating statistics can you dial up?

Perl flows through my life,
Like summer breezes through pines,
Peaceful and Soothing.