Perl on the Pocket PC - Easy!

[ioneabu]

I was complaining before about how difficult it was going to be to get
Perl working on my Pocket PC pda (a Dell Axim 3). The fact that it
does not come with the Perl libraries and that there are registry
changes to make turned me off to trying it. The word 'registry' makes
me cringe. I don't know why I have this aversion to the Windows
registry, but I just do. I guess if you want to keep a secret from me,
hide it in the registry.

Anyway, I was determined to make it work no matter how difficult or
time consuming. I went to
http://www.rainer-keuchel.de/wince/perlce.html for files and
instructions.

It turned out to be very straight forward and easy. As far as the
registry stuff, he lays it out in a sample batch file which makes it
also very easy. I installed ActivePerl on my Windows computer to get
the libraries and I threw in a few more from CPAN. It is really,
really cool to have Perl running on my pda.

Here's my first script, written and executed entirely on the pda. It
is to fix a bunch of files with Weight Watcher's daily points and add
the total at the bottom of each file:

#!/usr/bin/perl
use File::Slurp;
@a = read_dir('\\oldpts\\');
foreach(@a)
{
@b = ();
@b = read_file("\\oldpts\\$_");
if (not (grep /^total/, @b))
{
$c = 0;
map
{
/^(\d+)\s/;
$c += int $&;
} @b;
push @b, "total: $c";
write_file("\\oldpts\\$_",@b);
}
}

I know it is not entirely efficient, but it worked. I couldn't believe
how fast it ran. One second to compile and no time to process dozens
of files. Now I just need the portable keyboard
wana (now using map and grep a little

 

[Paul Lalli]

Just some very basic constructive criticism . . .

#!/usr/bin/perl

would strict and warnings adversely affect your ability to get this
thing to a size proper for the Pocket PC? I know nothing about it, so
that's an honest question. If not, put them in.

use File::Slurp;
@a = read_dir('\\oldpts\\');
foreach(@a)

No real reason for the intermediary variable there.
foreach (read_dir('\\oldpts\\')) {

{
@b = ();
@b = read_file("\\oldpts\\$_");

Almost never any reason to initialize an array to (). Definately no
reason if you then immediately assign it to a different value.

(If this was meant to 'clear' @b before the next loop, simply properly
scope the variable

my @b = read_file("\\oldpts\\$_);

if (not (grep /^total/, @b))
{
$c = 0;
map
{
/^(\d+)\s/;
$c += int $&;

1) $& is generally a Bad Thing. It slows down all regexps in the
program (though not as much as in previous versions)
2) You're using capturing parentheses without using the captured value.
3) You're using values determined from a regular expression without
determining whether that pattern match succeeded. Maybe you're really
really confident about the format of your files, but that's not a good
pattern to fall into:

$c += $1 if /^(\d+)\s/;

} @b;

map() should almost never be used in a void context. Use map when you
want to obtain a list of modified values from an existing list. If
you're not using the modified values (or in this case, not even
modifying them), use a foreach loop instead:

for (@b) {
$c += $1 if /^(\d+)\s/;
}

push @b, "total: $c";
write_file("\\oldpts\\$_",@b);
}
}

I know it is not entirely efficient, but it worked. I couldn't believe
how fast it ran. One second to compile and no time to process dozens
of files. Now I just need the portable keyboard

wana (now using map and grep a little

Knowing how to use them is a good step in the right direction. Knowing
*when* to use them is a better step.

Paul Lalli

 

[ioneabu]

Thanks for tips! I admit I have been lazy and a little sloppy in my
Perl work on the pda. There should be no reason not to use strict and
warnings. Thanks for advice on map.

Typing on the little on-screen keyboard and looking at the tiny screen,
it is easy to get into bad habits. I think this will be a passing fad
for me. It has been a way to do some Perl practicing in my free time
away from my pc. I work at a boring non-programming job, so when I
take a break, I can do a few minutes of Perl on the pda. Probably a
good use for it is to write well formed perl on the desktop that will
be useful for file processing on the pda and then send it over.

wana

 

[wana]

map() should almost never be used in a void context. Use map when you

want to obtain a list of modified values from an existing list. If
you're not using the modified values (or in this case, not even
modifying them), use a foreach loop instead:

for (@b) {
$c += $1 if /^(\d+)\s/;
}

Knowing how to use them is a good step in the right direction. Knowing
*when* to use them is a better step.

Paul Lalli

It just occurred to me why I used map (other than to just use it). I was
under the impression, probably erroneously, that $_ is very safely
localized within the block evaluated by map. If I use $_ myself, I might
forget to explicitly localize it. I was also told a while back that
stating 'local $_' might not be totally protective of a global $_ value in
some cases. I was wondering if the $_ in a map block is localized more
safely than a local $_ in an ordinary block.

It would seem that $_ might not be safe to use in all but the smallest,
simplest scripts. Doesn't it bypass the checking done by using strict?

Thanks!

wana

 

[Anno Siegel]

It just occurred to me why I used map (other than to just use it). I was
under the impression, probably erroneously, that $_ is very safely
localized within the block evaluated by map.

It is, but the same is true for "for" loops (but not for "while").

Anno

 

[Paul Lalli]

It just occurred to me why I used map (other than to just use it). I was
under the impression, probably erroneously, that $_ is very safely
localized within the block evaluated by map.

Yes, $_ is local'ized in a map block. However it is also localized in a
foreach-style loop (as above).

I was wondering if the $_ in a map block is localized more
safely than a local $_ in an ordinary block.

$_ isn't localized in an "ordinary" block unless you do it explicitly.
map and foreach do it automatically.

It would seem that $_ might not be safe to use in all but the smallest,
simplest scripts. Doesn't it bypass the checking done by using

strict?

The "special" variables (all the ones that are listed in perldoc
perlvar) are not subject to the strict 'vars' pragma, no. They always
exist. More to the point, you cannot create lexical variables with
those names, even if you wanted to. This is a run time error:

my $_ = 'foo';

You can only assign temporary values to the already-existing global
variables, with local.

Paul Lalli