Perl Programming

I had some time this afternoon to do some programming as I whisked myself from Uni to the city to see the new Mac Books (a bit dissapointing, frankly!). I was perling for a few hours and my little application grew to only a modest size before the program became unmanageable.

It should have been easy!

Anyway I'm realising now that I could have done in whole what I only got perhaps 1/4 of the way to doing with

rails noodleTimer

and then a few mySQL table set ups and then I would have been done with it. UI, model. A few scraps of logic in the controller and I would have had a working web app.

Ahh but it's all a learning process.

Now that the last line of assessed perl has been /submit'ed in, I might resolve now to put it aside and move onto better things.

ruby? PHP? Ruby.

This is where perl starts to break down! To loose a bit of steam.
When you start pointing to data structures, you need to keep track of who's pointing to them, because you don't want to get rid of it while other pointers are pointing to it.

A hash just contains a scalar .

Wait a sec, I used this for assignment 1!

It's more efficient to pass a reference for the same reasons that it is better to do it in C.

Wasteful and dangerous to create a temporary handle, so like NEW in C, you can create a new instance of something and get a handle back on it.

I think I'm getting this stuff. Conceptually it makes sense. It's beautiful in its simplicity actually.

Programming is simple. That's my new mantra.

So now we can create higher dimension data structures! Hooray!

I like perl. The debugger warnings are friendly too.

You can use a hash to effectively emulate C structs.

You can write any arbitrary program and have the server execute it.
You put your program in cgi-bin

[] Installing a CGI program at Monash

The client sends a request to run a program, and it gets run, generates any STDOUT it wants and that is sent pretty much straight back to the client.

It's just a standard perl program printing things to std out.

The browser packages up form data and posts it over to the server. It will send those as name values into that perl program.

type name value=" "
Input type submit name value="Gp"

use CGI qw(param);

HTML is a stateless protocol. You can use hidden parameters to make it as if it does have state with the string going back and forth. The other way is to use cookies, which is more secure. So you don't do this if you want to build a secure system.

CGI security is very important
What you're allowing is for someone to log in and run as you!
So you should always check values for correctness.

What about asynchronous javascript: That's server side processing.

My, it IS nice to conceive of a computer program in an instant, and then have it written before you a few hours later, functioning as expected!

I'm beginning to like perl!

#!/usr/bin/perl
#perlWords 1.0 written Wed 12th April 2006 Mathieu Tozer.com
#Keeps track of the words you're reading. Might be useful for language learning.
#WARNING! VERY BASIC FUNCTIONALITY. But it works as far as I can tell : )

#takes as input newTxt.txt and checks against myWords for new words. Adds them if not found.

use Data::Dumper;

# Thaw saved Dictionary, if it exists.
if ( -f "myWords" ) {
    do "myWords";# Restore previous values.
} else {
    %myWordsDict = ( ) ;  # First run.
}

# Print usage message if called with no arguments.
die "Usage: $0 file [...]\n" if @ARGV == 0;

$text = $ARGV[0];
#transient variable for today's words
%todaysWords = ( ) ;
                                # ... do stuff with %myWordsDic ...

#Backquoteoperator used to capture output of another process

@newWords = ;

foreach $current ( @newWords )
{
    if ( exists $myWordsDict { "$current" } ) { #if it's in my dictionary, ( do nothing atm )
#$myWordsDict { "$current" } = ( $myWordsDict { "$current" } + 1 ) #add one to times seen
#print "you have seen $current";
     }
    else { #otherwise add it to my dict and set to 1
        #    print "NEW: $current";
        $myWordsDict { "$current" } = "1";
        #add the word to 'today's words' file with the total number of words
        $todaysWords { "$current" } = $myWordsDict { "$current" } ;
     }
}

print "Today's Words are from $text:\n";
foreach $word ( keys %todaysWords )
{
    print ". $word";
}

# Freeze values for next time before program exit.
open STORAGE, ">myWords";
print STORAGE Data::Dumper->Dump (
                                  [\%myWordsDict],
                                  [qw ( *myWordsDict ) ] ) ;

Up until now, you have only seen stand alone perl.

You might like to use a bit of someone else's functionality.

Much of perl's functionality is contained in modules. There's a whole stack of modules (take a look at CPAN), and you can make your own ones as well.

This means that you don't have to write everything from scratch if you just want to 'knock something up'.

When you want to import a module, you use the

use

statement.

When you write a module (not something we would do in this subject)

package Dog;
ensures that Dog's variables and function don't interfere with anyone else's methods.

Databases are a collection of (consistent!) data.

Persistent Data
We would like to have a mechanism of setting up a database in perl. The hash is a pretty good basis for doing this. The problem with hash is that they are not persistent outside the running of the program. What we would really like is a persistent hash, and that's how we begin with the database.

With a little bit of magic, you can 'tie' a database to a hash, and just access it as though it was a hash. It works in the background, by redefining what the compiler is doing, but you don't need to see any of that. You just need to know how to use hash.

use Data::Dumper

DBM files are common to UNIX,
almost all UNIX implementations have them.
Data is stored in a binary file.
Roughly equivalent to a hash.

When you want to open a database:
Use a dbmopen or tie function.

Perl provides a simple interface to DBM

To tie a hash to a file
dbmopen %hash, "file", 0600

[] learn about UNIX file permissions !

So that's all pretty cool. The problem is that you can't store much in them!
So we have to pack and unpack things.

Hashes work really well when the index is an integer.

You can even do low level stuff by sequentially ordering a binary file and to just use seek to find an arbitrary offset from the start of the file, and then read it in using unpack. It's low level, but very efficient.

Client / server databases.
You can interact with these with DBI interface. This allows you to access DBs on other machines!

DBI insulates you and your perl from the direct DB implementation!
And it's very different to DBM where the DB is on the machine where we are.
You've got a huge range of techniques available to you.

Reccomend that you use the DBM databases for assignment 2.

All the script has to do is get the ‘notes’ folder onto the server. Plonk.

It's hard to make a topic like subroutines interesting.

You have, of course, sigh, the option of sending parameters to a subroutine.

many Unic protrams can act as filters
<> diamond operator. Returns as much input as there is.
If there are no comad line options then it acts like

sub name
{
#body goes here
}

You almost never need to use the & character, only when it's ambiguous. But we're encouraged to use the ampersand and brackets.

@_ is the list that has been passed into me.

Remember the value of pi? It's a good party trick anyway.

returning
Last value evaluated
Can use the return keyword
Return value can be a scalar or list