wxPerl: adding a GUI to the twitter script (part 1)

So far, I've only dabbled with Perl console applications. There is nothing wrong about them, and if you come from the Linux world you are probably quite familiar with running a program from the command line.
The standard Windows users however may not be as comfortable around CLI (Command Line interface) apps as they are around Graphical User Interface (GUI) programs.

I. Describing the need

• The first need is to provide a simple GUI interface. I am tired of opening a shell, going to the script directory and typing something like:
  perl twit.pl -s "I am so lazy" -a
  every time I want to update my Twitter and Identica messages. I just want to type my text and click on a "Send" button.
• Monitor the number of characters being typed so that it doesn't go over the 140-character limit.
• Provide a standalone application that my mom would find easy to use.
• I would also like to have the possibility of removing the last post for both Twitter and Identica, in case of a spelling mistake detected after sending the update for example.

II. Technical choices
From using Padre, wxPerl is already installed on my system in the form of the Wx module. I'll hence be using it (and it will help me understand the innards of Padre as a bonus).
Other options for GUI librairies would be Tk and Win32::GUI (the last one for Windows only obviously).

To build the standalone application, I have Perl2Exe in mind. However, I have not done much research on the subject yet. If you want to tell about your favorite choice in the comments section, I'll select from the list (or I might open a poll). Documention for the Wx module also mentions PAR and Perl2App.

II. Design the UI
Here's the list of needed elements:

• Text box to enter up to 140 characters (2 lines of 70?)
• 2 check boxes for twitter
• 2 check boxes for identica
• 1 "Send" button
• 1 "Delete Last" button
• 1 menu item to create/open login file

Let's try to lay it out in Paint first:

• Errors will be displayed through message boxes.
• In the Login menu, choices will be:
  - "Select Login File": window opens asking for file location. Default location used at start up.
  Parses selected file and displays error message if format not recognized.
  Stores login + password for whatever social website is recognized
  Back in the main form, Twitter and/or Identica boxes are greyed out if no login is found.
  No login/password encryption planned for the moment
  - "Edit Login File" : window first pops up asking for login file location.
  Allows the login file to be edited from the application.
• The Twitter and Identi.ca boxes of the "Status" area will both be checked by default (if logins are provided)
• Not sure how I'm going to implement the "Delete Last" functionality yet. There is a destroy_status() method in the Net::Twitter module. I'll have to read the doc.

Reviewing the design, I am wondering about the double Twitter and Identica checkboxes. Wouldn't one set be enough? Unless each set is updated in parallel: setting the top (resp. bottom) Twitter box would also set the bottom (resp. top) Twitter box. What's your take on this?

I'd like to use Test Driven Development for this little project but I have no experience in either TDD or writing tests for Perl applications.

For TDD, I know that you must first write a test, check that it fails, code so that the test succeeds then write the next test. Once some tests are written and pass, you can improve the program's code knowing that you have a test suite ready to check that all the features still work. That's about the extent of my knowledge on this subject but it sounds like fun :)

Concerning the tests themselves, I've read through Modern Perl Book's recent posts on testing but it hasn't sunk in with me yet. I guess I'll have to start by looking into this.

Larry Wall's quote of the day:
"The whole intent of Perl 5's module system was to encourage the growth of Perl culture rather than the Perl core."

wxPerl: adding a GUI to the twitter script (part 1)

So far, I've only dabbled with Perl console applications. There is nothing wrong about them, and if you come from the Linux world you are probably quite familiar with running a program from the command line.
The standard Windows users however may not be as comfortable around CLI (Command Line interface) apps as they are around Graphical User Interface (GUI) programs.

I. Describing the need

• The first need is to provide a simple GUI interface. I am tired of opening a shell, going to the script directory and typing something like:
  perl twit.pl -s "I am so lazy" -a
  every time I want to update my Twitter and Identica messages. I just want to type my text and click on a "Send" button.
• Monitor the number of characters being typed so that it doesn't go over the 140-character limit.
• Provide a standalone application that my mom would find easy to use.
• I would also like to have the possibility of removing the last post for both Twitter and Identica, in case of a spelling mistake detected after sending the update for example.

II. Technical choices
From using Padre, wxPerl is already installed on my system in the form of the Wx module. I'll hence be using it (and it will help me understand the innards of Padre as a bonus).
Other options for GUI librairies would be Tk and Win32::GUI (the last one for Windows only obviously).

To build the standalone application, I have Perl2Exe in mind. However, I have not done much research on the subject yet. If you want to tell about your favorite choice in the comments section, I'll select from the list (or I might open a poll). Documention for the Wx module also mentions PAR and Perl2App.

II. Design the UI
Here's the list of needed elements:

• Text box to enter up to 140 characters (2 lines of 70?)
• 2 check boxes for twitter
• 2 check boxes for identica
• 1 "Send" button
• 1 "Delete Last" button
• 1 menu item to create/open login file

Let's try to lay it out in Paint first:

• Errors will be displayed through message boxes.
• In the Login menu, choices will be:
  - "Select Login File": window opens asking for file location. Default location used at start up.
  Parses selected file and displays error message if format not recognized.
  Stores login + password for whatever social website is recognized
  Back in the main form, Twitter and/or Identica boxes are greyed out if no login is found.
  No login/password encryption planned for the moment
  - "Edit Login File" : window first pops up asking for login file location.
  Allows the login file to be edited from the application.
• The Twitter and Identi.ca boxes of the "Status" area will both be checked by default (if logins are provided)
• Not sure how I'm going to implement the "Delete Last" functionality yet. There is a destroy_status() method in the Net::Twitter module. I'll have to read the doc.

Reviewing the design, I am wondering about the double Twitter and Identica checkboxes. Wouldn't one set be enough? Unless each set is updated in parallel: setting the top (resp. bottom) Twitter box would also set the bottom (resp. top) Twitter box. What's your take on this?

I'd like to use Test Driven Development for this little project but I have no experience in either TDD or writing tests for Perl applications.

For TDD, I know that you must first write a test, check that it fails, code so that the test succeeds then write the next test. Once some tests are written and pass, you can improve the program's code knowing that you have a test suite ready to check that all the features still work. That's about the extent of my knowledge on this subject but it sounds like fun :)

Concerning the tests themselves, I've read through Modern Perl Book's recent posts on testing but it hasn't sunk in with me yet. I guess I'll have to start by looking into this.

Larry Wall's quote of the day:
"The whole intent of Perl 5's module system was to encourage the growth of Perl culture rather than the Perl core."

Write better Perl with Perl::Critic

I have recently discovered a simple-to-use static code analysis tool for Perl.
It will examine your source file and list a series of warnings when it notices contructs that are different from the recommended practices.

Let me present you the Perl::Critic module, which allows the creation of a very simple script as described in the documentation.

use Modern::Perl;
use Perl::Critic;

die "No file name as argument\n" if (@ARGV == 0);
my $file = $ARGV[0];

my $critic = Perl::Critic->new();
my @violations = $critic->critique($file);
print @violations;

With this bit of code, you can check any Perl file for Policy violations within the program itself.

If you name the above script critic.pl, you can also analyze external programs by typing "perl critic.pl AnyPerlFile.pl".
However, as Chris pointed out in the comments section (thanks!), there is a simpler way: use the perlcritic command line interface provided with the Perl::Critic module.
There are many available options to customize your analysis.

You can apply any policy that you would like. The default is the one described in Damian Conway's "Perl Best Practices" (PBP) book. A summary of all available policies on CPAN can be found here.

There is actually an even better way to use the Perl::Critic tool than the command line: the perlcritic website where you can jump directly to the offending lines in your code. You are also able to click on links taking you to the PBP's page related to the warning being displayed!

I find it a great way to learn good Perl programming tips with very little effort, as all the information is only one click away!

[Edit] For more in-depth information about Perl::Critic, take a look at this article from Perl Training Australia.

Larry Wall quote of the day:
"If someone stinks, view it as a reason to help them, not a reason to avoid them."

Write better Perl with Perl::Critic

I have recently discovered a simple-to-use static code analysis tool for Perl.
It will examine your source file and list a series of warnings when it notices contructs that are different from the recommended practices.

Let me present you the Perl::Critic module, which allows the creation of a very simple script as described in the documentation.

use Modern::Perl;
use Perl::Critic;

die "No file name as argument\n" if (@ARGV == 0);
my $file = $ARGV[0];

my $critic = Perl::Critic->new();
my @violations = $critic->critique($file);
print @violations;

With this bit of code, you can check any Perl file for Policy violations within the program itself.

If you name the above script critic.pl, you can also analyze external programs by typing "perl critic.pl AnyPerlFile.pl".
However, as Chris pointed out in the comments section (thanks!), there is a simpler way: use the perlcritic command line interface provided with the Perl::Critic module.
There are many available options to customize your analysis.

You can apply any policy that you would like. The default is the one described in Damian Conway's "Perl Best Practices" (PBP) book. A summary of all available policies on CPAN can be found here.

There is actually an even better way to use the Perl::Critic tool than the command line: the perlcritic website where you can jump directly to the offending lines in your code. You are also able to click on links taking you to the PBP's page related to the warning being displayed!

I find it a great way to learn good Perl programming tips with very little effort, as all the information is only one click away!

[Edit] For more in-depth information about Perl::Critic, take a look at this article from Perl Training Australia.

Larry Wall quote of the day:
"If someone stinks, view it as a reason to help them, not a reason to avoid them."

Plain Old Documentation (POD)

Perl allows documentation to be integrated into your programs easily thanks to the Plain Old Documentation (POD) system.
Most modules from CPAN can be parsed for comments and documentation using the perldoc command from the shell.
For example, typing "perldoc Net::Twitter" will display information on the Twitter module (if installed). Perl will ignore Pod statements when parsing through the code.
This is a convenient way to always find documentation related to a given program, as the program contains the user manual within itself.

There are a few keywords to know, as well as basic principles.
Here are the two most basic statements:

=head1 TITLE

Super duper comment here

=cut

The Pod parser will behave differently if you write the text at the start of the line or if you type space or tab characters before.

• Ordinary paragraphs will reformat your text (such as wrapping, justifying, etc.). Start writing on the first column, like in the example above.
• Verbatim paragraphs will not be reformated. The first character of the text should be a space or a tab.

I'll let you read more details on the perldoc page.
Also, don't forget to add an empty line before and after each Pod command. Some parsers might get confused if you don't.
Use C<text> when writing an example of code, F<text> for file names and B<text> for shell command names.

The real cool thing about Pod is that you can sprinkle bits of comments all over the code.
I have rewritten twit.pl to version 0.2.1 to follow perlstyle rules (mainly renaming variables and functions) and to add Pod comments.

The script can be found here.

As you will see, I have kept each part of the doc as close as possible to the relevant part of the code, such as in the first lines below:

#!/usr/bin/perl
use Modern::Perl;

=head1 NAME

twit.pl - Script to update your status on twitter.com and/or identica

=cut

my $PROG_NAME = "twit.pl";

=head1 VERSION

This is version 0.2.1

=cut

my $VERSION   = "v0.2.1";
my $version_date = "March 7th 2009";

=head1 DEPENDENCIES

Getopt::Long
Net::Twitter

=cut

use Getopt::Long;   # To parse the command line
use Net::Twitter;   # API to twitter.com and identi.ca

This makes it easy to update the doc when the code changes.
Also, the get_help subroutine (the function formerly known as Help) has been rewritten to call the twit.pl script in a reentrant sort of way with the system command:

sub get_help {
system("perldoc $0"); # $0 contains the name of the file containing the Perl script being executed
exit;
} # End of get_help

Larry Wall quote of the day:
"You have to admit that it's difficult to misplace the Perl sources. :-) "

When using Pod, you can also include documentation in Larry's statement.

Plain Old Documentation (POD)

Perl allows documentation to be integrated into your programs easily thanks to the Plain Old Documentation (POD) system.
Most modules from CPAN can be parsed for comments and documentation using the perldoc command from the shell.
For example, typing "perldoc Net::Twitter" will display information on the Twitter module (if installed). Perl will ignore Pod statements when parsing through the code.
This is a convenient way to always find documentation related to a given program, as the program contains the user manual within itself.

There are a few keywords to know, as well as basic principles.
Here are the two most basic statements:

=head1 TITLE

Super duper comment here

=cut

The Pod parser will behave differently if you write the text at the start of the line or if you type space or tab characters before.

• Ordinary paragraphs will reformat your text (such as wrapping, justifying, etc.). Start writing on the first column, like in the example above.
• Verbatim paragraphs will not be reformated. The first character of the text should be a space or a tab.

I'll let you read more details on the perldoc page.
Also, don't forget to add an empty line before and after each Pod command. Some parsers might get confused if you don't.
Use C<text> when writing an example of code, F<text> for file names and B<text> for shell command names.

The real cool thing about Pod is that you can sprinkle bits of comments all over the code.
I have rewritten twit.pl to version 0.2.1 to follow perlstyle rules (mainly renaming variables and functions) and to add Pod comments.

The script can be found here.

As you will see, I have kept each part of the doc as close as possible to the relevant part of the code, such as in the first lines below:

#!/usr/bin/perl
use Modern::Perl;

=head1 NAME

twit.pl - Script to update your status on twitter.com and/or identica

=cut

my $PROG_NAME = "twit.pl";

=head1 VERSION

This is version 0.2.1

=cut

my $VERSION   = "v0.2.1";
my $version_date = "March 7th 2009";

=head1 DEPENDENCIES

Getopt::Long
Net::Twitter

=cut

use Getopt::Long;   # To parse the command line
use Net::Twitter;   # API to twitter.com and identi.ca

This makes it easy to update the doc when the code changes.
Also, the get_help subroutine (the function formerly known as Help) has been rewritten to call the twit.pl script in a reentrant sort of way with the system command:

sub get_help {
system("perldoc $0"); # $0 contains the name of the file containing the Perl script being executed
exit;
} # End of get_help

Larry Wall quote of the day:
"You have to admit that it's difficult to misplace the Perl sources. :-) "

When using Pod, you can also include documentation in Larry's statement.

Perl naming convention for subroutine names

Disclaimer
Welcome to all readers of Perlsphere. Mine is a blog of little pretention where I narrate my personal experience with learning Perl. As such, the code that can be found in DamienLearnsPerl's pages should be taken with a grain of salt as it might be inaccurate (oops). I am calling upon the understanding and experience of more proficient Perl users to point out those mistakes or suggest better and more "perlish" ways to program.

Perl Naming Conventions
For example, my last post about the twitter script triggered an interesting comment today.

Anonymous said...

Some new Perl culture for you to learn: subroutine names that are AllSquishedTogether() are frowned upon. The convention is names_like_this() - lowercase, with underscores separating words.

My first reaction was: "As long as I am using a way to name variables and methods that is coherent throughout the program, why couldn't I CapitalizeAndSquish as I please?"
Then I got to think: "Well, I guess that would be alright if I was the only person maintaining the script. But what would happen on projects where several developers contribute to the code? There would need to exist a common naming convention, so that the code doesn't look like a patchwork of different tabulation and personal formatting standards..."

So, tickled by Anonymous' remark, I embarked upon a Google trip to uncover documented Perl naming conventions...

The first tip I found was from webreference.com:

When selecting names for your general subroutines, it's recommended that you use all lower case names; since, by convention, subroutine names with all capital letters indicate actions that are triggered automatically as needed by Perl; such as AUTOLOAD or DESTROY, and mixed case names are often utilized as package names. [...] keep your user-defined subroutine names to all lower case and you'll avoid this ambiguity in the future.

There is more or less the same description from perldoc perlsub:

Subroutines whose names are in all upper case are reserved to the Perl core, as are modules whose names are in all lower case. A subroutine in all capitals is a loosely-held convention meaning it will be called indirectly by the run-time system itself, usually due to a triggered event. Subroutines that do special, pre-defined things include "AUTOLOAD", "CLONE", "DESTROY" plus all functions mentioned in perltie and PerlIO::via.

The Camel book also adds that all upper case subs could be used for constants.

However, I also found this tutorials:
- Picking Up Perl (granted, it's from 2001), where they show an example of a subroutine called HowdyEveryone{}

I continued my journey and stumbled upon the Perl::Critic::Policy::NamingConventions::Capitalization and Perl::Critic::Policy::NamingConventions::ProhibitMixedCaseSubs modules on CPAN. They are both based upon recommendations from Damian Conway's book Perl Best Practices and enforce the all-lower-case-naming policy for subroutines.

But the piece of information I found most useful was definitely perlstyle, the Perl style guide. There can be found a list of recommendations to make your Perl program easier to maintain and understand. Abstract:

While short identifiers like $gotit are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.

Function and method names seem to work best as all lowercase. E.g., $obj->as_string().

You can use a leading underscore to indicate that a variable or function should not be used outside the package that defined it.

I will therefore try to follow the following guidelines:
- ALL CAPS: automatically triggered subroutines and constants
- Mixed Case: package names
- lower case with words separated by underscores: variables and user-defined subroutines
- lower case starting with a "_": internal function/variable

What about you? What do you take as reference for naming conventions? Do you use different standards than those described in perltype?

Perl naming convention for subroutine names

Disclaimer
Welcome to all readers of Perlsphere. Mine is a blog of little pretention where I narrate my personal experience with learning Perl. As such, the code that can be found in DamienLearnsPerl's pages should be taken with a grain of salt as it might be inaccurate (oops). I am calling upon the understanding and experience of more proficient Perl users to point out those mistakes or suggest better and more "perlish" ways to program.

Perl Naming Conventions
For example, my last post about the twitter script triggered an interesting comment today.

Anonymous said...

Some new Perl culture for you to learn: subroutine names that are AllSquishedTogether() are frowned upon. The convention is names_like_this() - lowercase, with underscores separating words.

My first reaction was: "As long as I am using a way to name variables and methods that is coherent throughout the program, why couldn't I CapitalizeAndSquish as I please?"
Then I got to think: "Well, I guess that would be alright if I was the only person maintaining the script. But what would happen on projects where several developers contribute to the code? There would need to exist a common naming convention, so that the code doesn't look like a patchwork of different tabulation and personal formatting standards..."

So, tickled by Anonymous' remark, I embarked upon a Google trip to uncover documented Perl naming conventions...

The first tip I found was from webreference.com:

When selecting names for your general subroutines, it's recommended that you use all lower case names; since, by convention, subroutine names with all capital letters indicate actions that are triggered automatically as needed by Perl; such as AUTOLOAD or DESTROY, and mixed case names are often utilized as package names. [...] keep your user-defined subroutine names to all lower case and you'll avoid this ambiguity in the future.

There is more or less the same description from perldoc perlsub:

Subroutines whose names are in all upper case are reserved to the Perl core, as are modules whose names are in all lower case. A subroutine in all capitals is a loosely-held convention meaning it will be called indirectly by the run-time system itself, usually due to a triggered event. Subroutines that do special, pre-defined things include "AUTOLOAD", "CLONE", "DESTROY" plus all functions mentioned in perltie and PerlIO::via.

The Camel book also adds that all upper case subs could be used for constants.

However, I also found this tutorials:
- Picking Up Perl (granted, it's from 2001), where they show an example of a subroutine called HowdyEveryone{}

I continued my journey and stumbled upon the Perl::Critic::Policy::NamingConventions::Capitalization and Perl::Critic::Policy::NamingConventions::ProhibitMixedCaseSubs modules on CPAN. They are both based upon recommendations from Damian Conway's book Perl Best Practices and enforce the all-lower-case-naming policy for subroutines.

But the piece of information I found most useful was definitely perlstyle, the Perl style guide. There can be found a list of recommendations to make your Perl program easier to maintain and understand. Abstract:

While short identifiers like $gotit are probably ok, use underscores to separate words in longer identifiers. It is generally easier to read $var_names_like_this than $VarNamesLikeThis, especially for non-native speakers of English. It's also a simple rule that works consistently with VAR_NAMES_LIKE_THIS.

Function and method names seem to work best as all lowercase. E.g., $obj->as_string().

You can use a leading underscore to indicate that a variable or function should not be used outside the package that defined it.

I will therefore try to follow the following guidelines:
- ALL CAPS: automatically triggered subroutines and constants
- Mixed Case: package names
- lower case with words separated by underscores: variables and user-defined subroutines
- lower case starting with a "_": internal function/variable

What about you? What do you take as reference for naming conventions? Do you use different standards than those described in perltype?

CPAN module updates

CPAN goodness
In the CPAN shell, if you type 'h' you will get a compact help menu.
I was wondering if it was possible to list all the modules on your system that have an update available on CPAN. After a few Google searches, it turned out that the answer was already in the help menu:

Upgrade r WORDs or /REGEXP/ or NONE report updates for some/matching/all modules

I initially did type "cpan> r" but nothing visible was happening and I interrupted the command. It actually takes more than a few seconds to list them all, I guess it depends on the number of installed modules on your system. An indicator showing that the process is alive would be nice to have. More patience would be nice to have also (on my side). Here's what the report gave on my system (click to enlarge):

This is how I noticed that the Net::Twitter module had been bumped to version 2.10 from 2.06.
The change log can be found here.
I typed "upgrade Net::Twitter" in the cpan shell and I was set.

Padre v0.28
Trying to upgrade Padre (change log for Padre version 0.28) using "upgrade Padre" was a failure.
I had to pull out the "force install Padre" command. I'll have to investigate if the problem still happens for next release. Maybe there's something wrong with my setup.

Larry Wall quote of the day:
"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

CPAN module updates

CPAN goodness
In the CPAN shell, if you type 'h' you will get a compact help menu.
I was wondering if it was possible to list all the modules on your system that have an update available on CPAN. After a few Google searches, it turned out that the answer was already in the help menu:

Upgrade r WORDs or /REGEXP/ or NONE report updates for some/matching/all modules

I initially did type "cpan> r" but nothing visible was happening and I interrupted the command. It actually takes more than a few seconds to list them all, I guess it depends on the number of installed modules on your system. An indicator showing that the process is alive would be nice to have. More patience would be nice to have also (on my side). Here's what the report gave on my system (click to enlarge):

This is how I noticed that the Net::Twitter module had been bumped to version 2.10 from 2.06.
The change log can be found here.
I typed "upgrade Net::Twitter" in the cpan shell and I was set.

Padre v0.28
Trying to upgrade Padre (change log for Padre version 0.28) using "upgrade Padre" was a failure.
I had to pull out the "force install Padre" command. I'll have to investigate if the problem still happens for next release. Maybe there's something wrong with my setup.

Larry Wall quote of the day:
"What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"

Using the Modern::Perl module

I recently had a warning in the GUI version of twit.pl (work in progress):
v-string in use/require non-portable at C:\Perl\usr\Blog\twit_1_0_0.pl line 73

The incriminated line 73 was:
use 5.10.0;

I googled the error string and Tom Wyant's ticket on Perl came up. It helped me understand the issue at hand and how to fix it.
However, for more in-depth information, I pushed my way to perldoc.perl.org

v-string refers to a version string: be warned, the version strings have ben deprecated since Perl 5.8.1 and this is why you will get a warning.
Version strings start with a "v" (example: v1.0). Strings that have 2 decimal points (eg. v1.0.0) are automatically considered as version strings.

In Perl, you can use underscores in numeric values between digits to make them easier to read.
For example, 1200.0053 can be represented as 1_200.00_53.

To remove the v-string warning, I replaced the line
use 5.10.0;
by use 5.010_000;

(use 5.010 also works but not use 5.10: the Perl compiler will look for version 5.100)

Or you can also use the Modern::Perl module written by chromatic.
Among other things, Modern::Perl will include the following pragmas:

use 5.010_000;
use strict;
use warnings;

In order to install the module from Padre, all is required is that you go to:
Perl>Install Module...>Install CPAN Module
You will see the window below:


Enter Modern::Perl and let CPAN work its magic!

Larry Wall quote of the day:
"Perl itself is usually pretty good about telling you what you shouldn't do."

Possible next posts:

• Perl template - Part II: Adding Help and Version procedures
• Perl help resources
• Improving on twit.pl: Graphical User interface
• POD
• Install Google Analytics on your Blogger blog and stats for DLP

Using the Modern::Perl module

I recently had a warning in the GUI version of twit.pl (work in progress):
v-string in use/require non-portable at C:\Perl\usr\Blog\twit_1_0_0.pl line 73

The incriminated line 73 was:
use 5.10.0;

I googled the error string and Tom Wyant's ticket on Perl came up. It helped me understand the issue at hand and how to fix it.
However, for more in-depth information, I pushed my way to perldoc.perl.org

v-string refers to a version string: be warned, the version strings have ben deprecated since Perl 5.8.1 and this is why you will get a warning.
Version strings start with a "v" (example: v1.0). Strings that have 2 decimal points (eg. v1.0.0) are automatically considered as version strings.

In Perl, you can use underscores in numeric values between digits to make them easier to read.
For example, 1200.0053 can be represented as 1_200.00_53.

To remove the v-string warning, I replaced the line
use 5.10.0;
by use 5.010_000;

(use 5.010 also works but not use 5.10: the Perl compiler will look for version 5.100)

Or you can also use the Modern::Perl module written by chromatic.
Among other things, Modern::Perl will include the following pragmas:

use 5.010_000;
use strict;
use warnings;

In order to install the module from Padre, all is required is that you go to:
Perl>Install Module...>Install CPAN Module
You will see the window below:


Enter Modern::Perl and let CPAN work its magic!

Larry Wall quote of the day:
"Perl itself is usually pretty good about telling you what you shouldn't do."

Possible next posts:

• Perl template - Part II: Adding Help and Version procedures
• Perl help resources
• Improving on twit.pl: Graphical User interface
• POD
• Install Google Analytics on your Blogger blog and stats for DLP

New colors

That white background was just frying my eye balls out, especially late at night!
Let it not be said that I don't take care of my readers' health. It is not Blackle yet but it is an improvement for sensitive eyes (I think... except if my new choice of colors makes you sick...).

New colors

That white background was just frying my eye balls out, especially late at night!
Let it not be said that I don't take care of my readers' health. It is not Blackle yet but it is an improvement for sensitive eyes (I think... except if my new choice of colors makes you sick...).