Free sega 8 software for linux

SelfLoader is a Perl module created to load functions only on demand.

SYNOPSIS

package FOOBAR;
use SelfLoader;

... (initializing code)

__DATA__
sub {....

This module tells its users that functions in the FOOBAR package are to be autoloaded from after the __DATA__ token. See also "Autoloading" in perlsub.

The __DATA__ token

The __DATA__ token tells the perl compiler that the perl code for compilation is finished. Everything after the __DATA__ token is available for reading via the filehandle FOOBAR::DATA, where FOOBAR is the name of the current package when the __DATA__ token is reached. This works just the same as __END__ does in package main, but for other modules data after __END__ is not automatically retrievable, whereas data after __DATA__ is. The __DATA__ token is not recognized in versions of perl prior to 5.001m.

Note that it is possible to have __DATA__ tokens in the same package in multiple files, and that the last __DATA__ token in a given package that is encountered by the compiler is the one accessible by the filehandle. This also applies to __END__ and main, i.e. if the main program has an __END__, but a module required (_not_ used) by that program has a package main; declaration followed by an __DATA__, then the DATA filehandle is set to access the data after the __DATA__ in the module, _not_ the data after the __END__ token in the main program, since the compiler encounters the required file later.

SelfLoader autoloading

The SelfLoader works by the user placing the __DATA__ token after perl code which needs to be compiled and run at require time, but before subroutine declarations that can be loaded in later - usually because they may never be called.

The SelfLoader will read from the FOOBAR::DATA filehandle to load in the data after __DATA__, and load in any subroutine when it is called. The costs are the one-time parsing of the data after __DATA__, and a load delay for the _first_ call of any autoloaded function. The benefits (hopefully) are a speeded up compilation phase, with no need to load functions which are never used.
The SelfLoader will stop reading from __DATA__ if it encounters the __END__ token - just as you would expect. If the __END__ token is present, and is followed by the token DATA, then the SelfLoader leaves the FOOBAR::DATA filehandle open on the line after that token.

The SelfLoader exports the AUTOLOAD subroutine to the package using the SelfLoader, and this loads the called subroutine when it is first called.
There is no advantage to putting subroutines which will _always_ be called after the __DATA__ token.

Autoloading and package lexicals

A my $pack_lexical statement makes the variable $pack_lexical local _only_ to the file up to the __DATA__ token. Subroutines declared elsewhere _cannot_ see these types of variables, just as if you declared subroutines in the package but in another file, they cannot see these variables.

So specifically, autoloaded functions cannot see package lexicals (this applies to both the SelfLoader and the Autoloader). The vars pragma provides an alternative to defining package-level globals that will be visible to autoloaded routines. See the documentation on vars in the pragma section of perlmod.

SelfLoader and AutoLoader

The SelfLoader can replace the AutoLoader - just change use AutoLoader to use SelfLoader (though note that the SelfLoader exports the AUTOLOAD function - but if you have your own AUTOLOAD and are using the AutoLoader too, you probably know what youre doing), and the __END__ token to __DATA__. You will need perl version 5.001m or later to use this (version 5.001 with all patches up to patch m).

There is no need to inherit from the SelfLoader.

The SelfLoader works similarly to the AutoLoader, but picks up the subs from after the __DATA__ instead of in the lib/auto directory. There is a maintenance gain in not needing to run AutoSplit on the module at installation, and a runtime gain in not needing to keep opening and closing files to load subs. There is a runtime loss in needing to parse the code after the __DATA__. Details of the AutoLoader and another view of these distinctions can be found in that modules documentation.

__DATA__, __END__, and the FOOBAR::DATA filehandle.

This section is only relevant if you want to use the FOOBAR::DATA together with the SelfLoader.

Data after the __DATA__ token in a module is read using the FOOBAR::DATA filehandle. __END__ can still be used to denote the end of the __DATA__ section if followed by the token DATA - this is supported by the SelfLoader. The FOOBAR::DATA filehandle is left open if an __END__ followed by a DATA is found, with the filehandle positioned at the start of the line after the __END__ token. If no __END__ token is present, or an __END__ token with no DATA token on the same line, then the filehandle is closed.

The SelfLoader reads from wherever the current position of the FOOBAR::DATA filehandle is, until the EOF or __END__. This means that if you want to use that filehandle (and ONLY if you want to), you should either

1. Put all your subroutine declarations immediately after the __DATA__ token and put your own data after those declarations, using the __END__ token to mark the end of subroutine declarations. You must also ensure that the SelfLoader reads first by calling SelfLoader->load_stubs();, or by using a function which is selfloaded;
or
2. You should read the FOOBAR::DATA filehandle first, leaving the handle open and positioned at the first line of subroutine declarations.
You could conceivably do both.

Classes and inherited methods.

For modules which are not classes, this section is not relevant. This section is only relevant if you have methods which could be inherited.

A subroutine stub (or forward declaration) looks like

sub stub;

i.e. it is a subroutine declaration without the body of the subroutine. For modules which are not classes, there is no real need for stubs as far as autoloading is concerned.

For modules which ARE classes, and need to handle inherited methods, stubs are needed to ensure that the method inheritance mechanism works properly. You can load the stubs into the module at require time, by adding the statement SelfLoader->load_stubs(); to the module to do this.

The alternative is to put the stubs in before the __DATA__ token BEFORE releasing the module, and for this purpose the Devel::SelfStubber module is available. However this does require the extra step of ensuring that the stubs are in the module. If this is done I strongly recommend that this is done BEFORE releasing the module - it should NOT be done at install time in general.

Multiple packages and fully qualified subroutine names

Subroutines in multiple packages within the same file are supported - but you should note that this requires exporting the SelfLoader::AUTOLOAD to every package which requires it. This is done automatically by the SelfLoader when it first loads the subs into the cache, but you should really specify it in the initialization before the __DATA__ by putting a use SelfLoader statement in each package.

Fully qualified subroutine names are also supported. For example,

__DATA__
sub foo::bar {23}
package baz;
sub dob {32}

will all be loaded correctly by the SelfLoader, and the SelfLoader will ensure that the packages foo and baz correctly have the SelfLoader AUTOLOAD method when the data after __DATA__ is first parsed.

User::grent is an interface to Perls built-in getgr*() functions.

SYNOPSIS

use User::grent;
$gr = getgrgid(0) or die "No group zero";
if ( $gr->name eq wheel && @{$gr->members} > 1 ) {
print "gid zero name wheel, with other members";
}

use User::grent qw(:FIELDS);
getgrgid(0) or die "No group zero";
if ( $gr_name eq wheel && @gr_members > 1 ) {
print "gid zero name wheel, with other members";
}

$gr = getgr($whoever);

This modules default exports override the core getgrent(), getgruid(), and getgrnam() functions, replacing them with versions that return "User::grent" objects. This object has methods that return the similarly named structure field name from the Cs passwd structure from grp.h; namely name, passwd, gid, and members (not mem). The first three return scalars, the last an array reference.

You may also import all the structure fields directly into your namespace as regular variables using the :FIELDS import tag. (Note that this still overrides your core functions.) Access these fields as variables named with a preceding gr_. Thus, $group_obj->gid() corresponds to $gr_gid if you import the fields. Array references are available as regular array variables, so @{ $group_obj->members() } would be simply @gr_members.

The getpw() function is a simple front-end that forwards a numeric argument to getpwuid() and the rest to getpwnam().

To access this functionality without the core overrides, pass the use an empty import list, and then access function functions with their full qualified names. On the other hand, the built-ins are still available via the CORE:: pseudo-package.

Search::Dict is a Perl module to search for key in dictionary file.

SYNOPSIS

use Search::Dict;
look *FILEHANDLE, $key, $dict, $fold;

use Search::Dict;
look *FILEHANDLE, $params;

Sets file position in FILEHANDLE to be first line greater than or equal (stringwise) to $key. Returns the new file position, or -1 if an error occurs.

The flags specify dictionary order and case folding:

If $dict is true, search by dictionary order (ignore anything but word characters and whitespace). The default is honour all characters.

If $fold is true, ignore case. The default is to honour case.

If there are only three arguments and the third argument is a hash reference, the keys of that hash can have values dict, fold, and comp or xfrm (see below), and their correponding values will be used as the parameters.

If a comparison subroutine (comp) is defined, it must return less than zero, zero, or greater than zero, if the first comparand is less than, equal, or greater than the second comparand.

If a transformation subroutine (xfrm) is defined, its value is used to transform the lines read from the filehandle before their comparison.

perlhack is a Perl module that will show you how to hack at the Perl internals.

This document attempts to explain how Perl development takes place, and ends with some suggestions for people wanting to become bona fide porters.
The perl5-porters mailing list is where the Perl standard distribution is maintained and developed. The list can get anywhere from 10 to 150 messages a day, depending on the heatedness of the debate. Most days there are two or three patches, extensions, features, or bugs being discussed at a time.

A searchable archive of the list is at either:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/

or

http://archive.develooper.com/perl5-porters@perl.org/

List subscribers (the porters themselves) come in several flavours. Some are quiet curious lurkers, who rarely pitch in and instead watch the ongoing development to ensure theyre forewarned of new changes or features in Perl. Some are representatives of vendors, who are there to make sure that Perl continues to compile and work on their platforms. Some patch any reported bug that they know how to fix, some are actively patching their pet area (threads, Win32, the regexp engine), while others seem to do nothing but complain. In other words, its your usual mix of technical people.

Over this group of porters presides Larry Wall. He has the final word in what does and does not change in the Perl language. Various releases of Perl are shepherded by a "pumpking", a porter responsible for gathering patches, deciding on a patch-by-patch, feature-by-feature basis what will and will not go into the release. For instance, Gurusamy Sarathy was the pumpking for the 5.6 release of Perl, and Jarkko Hietaniemi was the pumpking for the 5.8 release, and Rafael Garcia-Suarez holds the pumpking crown for the 5.10 release.
In addition, various people are pumpkings for different things. For instance, Andy Dougherty and Jarkko Hietaniemi did a grand job as the Configure pumpkin up till the 5.8 release. For the 5.10 release H.Merijn Brand took over.

Larry sees Perl development along the lines of the US government: theres the Legislature (the porters), the Executive branch (the pumpkings), and the Supreme Court (Larry). The legislature can discuss and submit patches to the executive branch all they like, but the executive branch is free to veto them. Rarely, the Supreme Court will side with the executive branch over the legislature, or the legislature over the executive branch. Mostly, however, the legislature and the executive branch are supposed to get along and work out their differences without impeachment or court cases.

You might sometimes see reference to Rule 1 and Rule 2. Larrys power as Supreme Court is expressed in The Rules:

Larry is always by definition right about how Perl should behave. This means he has final veto power on the core functionality.

Larry is allowed to change his mind about any matter at a later date, regardless of whether he previously invoked Rule 1.

Got that? Larry is always right, even when he was wrong. Its rare to see either Rule exercised, but they are often alluded to.

New features and extensions to the language are contentious, because the criteria used by the pumpkings, Larry, and other porters to decide which features should be implemented and incorporated are not codified in a few small design goals as with some other languages. Instead, the heuristics are flexible and often difficult to fathom. Here is one persons list, roughly in decreasing order of importance, of heuristics that new features have to be weighed against:

Does concept match the general goals of Perl?

These havent been written anywhere in stone, but one approximation is:

1. Keep it fast, simple, and useful.
2. Keep features/concepts as orthogonal as possible.
3. No arbitrary limits (platforms, data sizes, cultures).
4. Keep it open and exciting to use/patch/advocate Perl everywhere.
5. Either assimilate new technologies, or build bridges to them.

Where is the implementation?

All the talk in the world is useless without an implementation. In almost every case, the person or people who argue for a new feature will be expected to be the ones who implement it. Porters capable of coding new features have their own agendas, and are not available to implement your (possibly good) idea.

Backwards compatibility

Its a cardinal sin to break existing Perl programs. New warnings are contentious--some say that a program that emits warnings is not broken, while others say it is. Adding keywords has the potential to break programs, changing the meaning of existing token sequences or functions might break programs.

Could it be a module instead?

Perl 5 has extension mechanisms, modules and XS, specifically to avoid the need to keep changing the Perl interpreter. You can write modules that export functions, you can give those functions prototypes so they can be called like built-in functions, you can even write XS code to mess with the runtime data structures of the Perl interpreter if you want to implement really complicated things. If it can be done in a module instead of in the core, its highly unlikely to be added.

Is the feature generic enough?

Is this something that only the submitter wants added to the language, or would it be broadly useful? Sometimes, instead of adding a feature with a tight focus, the porters might decide to wait until someone implements the more generalized feature. For instance, instead of implementing a "delayed evaluation" feature, the porters are waiting for a macro system that would permit delayed evaluation and much more.

Does it potentially introduce new bugs?

Radical rewrites of large chunks of the Perl interpreter have the potential to introduce new bugs. The smaller and more localized the change, the better.

Does it preclude other desirable features?

A patch is likely to be rejected if it closes off future avenues of development. For instance, a patch that placed a true and final interpretation on prototypes is likely to be rejected because there are still options for the future of prototypes that havent been addressed.

Is the implementation robust?

Good patches (tight code, complete, correct) stand more chance of going in. Sloppy or incorrect patches might be placed on the back burner until the pumpking has time to fix, or might be discarded altogether without further notice.

Is the implementation generic enough to be portable?

The worst patches make use of a system-specific features. Its highly unlikely that nonportable additions to the Perl language will be accepted.

Is the implementation tested?

Patches which change behaviour (fixing bugs or introducing new features) must include regression tests to verify that everything works as expected. Without tests provided by the original author, how can anyone else changing perl in the future be sure that they havent unwittingly broken the behaviour the patch implements? And without tests, how can the patchs author be confident that his/her hard work put into the patch wont be accidentally thrown away by someone in the future?

Is there enough documentation?

Patches without documentation are probably ill-thought out or incomplete. Nothing can be added without documentation, so submitting a patch for the appropriate manpages as well as the source code is always a good idea.

Is there another way to do it?

Larry said "Although the Perl Slogan is Theres More Than One Way to Do It, I hesitate to make 10 ways to do something". This is a tricky heuristic to navigate, though--one mans essential addition is another mans pointless cruft.

Does it create too much work?

Work for the pumpking, work for Perl programmers, work for module authors, ... Perl is supposed to be easy.

Patches speak louder than words

Working code is always preferred to pie-in-the-sky ideas. A patch to add a feature stands a much higher chance of making it to the language than does a random feature request, no matter how fervently argued the request might be. This ties into "Will it be useful?", as the fact that someone took the time to make the patch demonstrates a strong desire for the feature.

If youre on the list, you might hear the word "core" bandied around. It refers to the standard distribution. "Hacking on the core" means youre changing the C source code to the Perl interpreter. "A core module" is one that ships with Perl.

B::Terse - Walk Perl syntax tree, printing terse info about ops.

SYNOPSIS

perl -MO=Terse[,OPTIONS] foo.pl

This version of B::Terse is really just a wrapper that calls B::Concise with the -terse option. It is provided for compatibility with old scripts (and habits) but using B::Concise directly is now recommended instead.

For compatibility with the old B::Terse, this module also adds a method named terse to B::OP and B::SV objects. The B::SV method is largely compatible with the old one, though authors of new software might be advised to choose a more user-friendly output format. The B::OP terse method, however, doesnt work well. Since B::Terse was first written, much more information in OPs has migrated to the scratchpad datastructure, but the terse interface doesnt have any way of getting to the correct pad. As a kludge, the new version will always use the pad for the main program, but for OPs in subroutines this will give the wrong answer or crash.

File::Basename is a Perl module to parse file paths into directory, filename and suffix.

SYNOPSIS

use File::Basename;

($name,$path,$suffix) = fileparse($fullname,@suffixlist);
$name = fileparse($fullname,@suffixlist);

$basename = basename($fullname,@suffixlist);
$dirname = dirname($fullname);

These routines allow you to parse file paths into their directory, filename and suffix.

NOTE: dirname() and basename() emulate the behaviours, and quirks, of the shell and C functions of the same name. See each functions documentation for details. If your concern is just parsing paths it is safer to use File::Specs splitpath() and splitdir() methods.

It is guaranteed that

# Where $path_separator is / for Unix, for Windows, etc...
dirname($path) . $path_separator . basename($path);

is equivalent to the original path for all systems but VMS.

fileparse
my($filename, $directories, $suffix) = fileparse($path);
my($filename, $directories, $suffix) = fileparse($path, @suffixes);
my $filename = fileparse($path, @suffixes);

The fileparse() routine divides a file path into its $directories, $filename and (optionally) the filename $suffix.

$directories contains everything up to and including the last directory separator in the $path including the volume (if applicable). The remainder of the $path is the $filename.

# On Unix returns ("baz", "/foo/bar/", "")
fileparse("/foo/bar/baz");

# On Windows returns ("baz", "C:foobar", "")
fileparse("C:foobarbaz");

# On Unix returns ("", "/foo/bar/baz/", "")
fileparse("/foo/bar/baz/");

If @suffixes are given each element is a pattern (either a string or a qr//) matched against the end of the $filename. The matching portion is removed and becomes the $suffix.

# On Unix returns ("baz", "/foo/bar", ".txt")
fileparse("/foo/bar/baz", qr/.[^.]*/);

If type is non-Unix (see fileparse_set_fstype()) then the pattern matching for suffix removal is performed case-insensitively, since those systems are not case-sensitive when opening existing files.

You are guaranteed that $directories . $filename . $suffix will denote the same location as the original $path.

basename
my $filename = basename($path);
my $filename = basename($path, @suffixes);

This function is provided for compatibility with the Unix shell command basename(1). It does NOT always return the file name portion of a path as you might expect. To be safe, if you want the file name portion of a path use fileparse().

basename() returns the last level of a filepath even if the last level is clearly directory. In effect, it is acting like pop() for paths. This differs from fileparse()s behaviour.

# Both return "bar"
basename("/foo/bar");
basename("/foo/bar/");

@suffixes work as in fileparse() except all regex metacharacters are quoted.

# These two function calls are equivalent.
my $filename = basename("/foo/bar/baz.txt", ".txt");
my $filename = fileparse("/foo/bar/baz.txt", qr/Q.txtE/);

Also note that in order to be compatible with the shell command, basename() does not strip off a suffix if it is identical to the remaining characters in the filename.

dirname

This function is provided for compatibility with the Unix shell command dirname(1) and has inherited some of its quirks. In spite of its name it does NOT always return the directory name as you might expect. To be safe, if you want the directory name of a path use fileparse().

Only on VMS (where there is no ambiguity between the file and directory portions of a path) and AmigaOS (possibly due to an implementation quirk in this module) does dirname() work like fileparse($path), returning just the $directories.

# On VMS and AmigaOS
my $directories = dirname($path);

When using Unix or MSDOS syntax this emulates the dirname(1) shell function which is subtly different from how fileparse() works. It returns all but the last level of a file path even if the last level is clearly a directory. In effect, it is not returning the directory portion but simply the path one level up acting like chop() for file paths.

Also unlike fileparse(), dirname() does not include a trailing slash on its returned path.

# returns /foo/bar. fileparse() would return /foo/bar/
dirname("/foo/bar/baz");

# also returns /foo/bar despite the fact that baz is clearly a
# directory. fileparse() would return /foo/bar/baz/
dirname("/foo/bar/baz/");

# returns .. fileparse() would return foo/
dirname("foo/");

Under VMS, if there is no directory information in the $path, then the current default device and directory is used.

fileparse_set_fstype
my $type = fileparse_set_fstype();
my $previous_type = fileparse_set_fstype($type);

Normally File::Basename will assume a file path type native to your current operating system (ie. /foo/bar style on Unix, foobar on Windows, etc...). With this function you can override that assumption.

Valid $types are "MacOS", "VMS", "AmigaOS", "OS2", "RISCOS", "MSWin32", "DOS" (also "MSDOS" for backwards bug compatibility), "Epoc" and "Unix" (all case-insensitive). If an unrecognized $type is given "Unix" will be assumed.
If youve selected VMS syntax, and the file specification you pass to one of these routines contains a "/", they assume you are using Unix emulation and apply the Unix syntax rules instead, for that function call only.

FileCache is a Perl module to keep more files open than the system permits.

SYNOPSIS

use FileCache;
# or
use FileCache maxopen => 16;

cacheout $mode, $path;
# or
cacheout $path;
print $path @data;

$fh = cacheout $mode, $path;
# or
$fh = cacheout $path;
print $fh @data;

The cacheout function will make sure that theres a filehandle open for reading or writing available as the pathname you give it. It automatically closes and re-opens files if you exceed your systems maximum number of file descriptors, or the suggested maximum maxopen.

cacheout EXPR

The 1-argument form of cacheout will open a file for writing (>) on its first use, and appending (>>) thereafter.

Returns EXPR on success for convenience. You may neglect the return value and manipulate EXPR as the filehandle directly if you prefer.

cacheout MODE, EXPR

The 2-argument form of cacheout will use the supplied mode for the initial and subsequent openings. Most valid modes for 3-argument open are supported namely; >, +>, , |- and -|

To pass supplemental arguments to a program opened with |- or -| append them to the command string as you would system EXPR.

Returns EXPR on success for convenience. You may neglect the return value and manipulate EXPR as the filehandle directly if you prefer.

CAVEATS

While it is permissible to close a FileCache managed file, do not do so if you are calling FileCache::cacheout from a package other than which it was imported, or with another module which overrides close. If you must, use FileCache::cacheout_close.

Although FileCache can be used with piped opens (-| or |-) doing so is strongly discouraged. If FileCache finds it necessary to close and then reopen a pipe, the command at the far end of the pipe will be reexecuted - the results of performing IO on FileCached pipes is unlikely to be what you expect.

The ability to use FileCache on pipes may be removed in a future release.
FileCache does not store the current file offset if it finds it necessary to close a file. When the file is reopened, the offset will be as specified by the original open file mode. This could be construed to be a bug.