Free provided definition software for linux

Objective Modula-2 programming language is a hybrid between Smalltalk and Modula-2 based on the object model and runtime of Objective-C.

The design is an example how native Cocoa/GNUstep support can be added to static imperative programming languages without implementing a bridge.

The projects scope encompasses the design of the Objective Modula-2 programming language and the implementation of a compiler to implement it. The initial compiler will generate Objective-C source code.

Word Inspector project is a GTK frontend to Dict dictionary program.

The dict program allows you to search through one or more dictionary-like reference books for a word, then displays its definition.

Word Inspector expands that by allowing you to enter words to look up more easily, easily look up words that appear in the definition for another word, and automatically look up a word in the X Windows selection.

Curses::Application provides the Curses Application Framework.

Curses::Application attempts to relieve the programmer of having to deal directly with Curses at all. Based upon Curses::Widgets and Curses::Forms, all one should have to do is define the application forms and contents in the DATA block of a script. Curses::Application will take care of the rest.

This module follows many of the conventions established by the Curses::Widgets and Curses::Forms modules, being built upon that framework. One area of special note, however, is the declaration of forms used within the application.

Curses::Application differentiates between forms and form definitions. A form is an instance of any particular form definition. Keeping that line of separation simplifies the development of MDI (Multiple Document Interface) applications.
Form definitions can be provided in two ways: as a list of definitions in the main::DATA block, or individually by using the addFormDef method. The former would normally be the simplest way to do so.

At the end of your script, declare a DATA block using Perls __DATA__ token. In that DATA block place a hash declaration (%forms) which contains a key/value pair for each form definition. The key being the name of the definition, and the value being a hash reference to the form declarations (see the Curses::Forms pod for directives available to that module). The only extra key that should be in each forms hash reference should be a TYPE directive, which would point to a module name relative to the base Curses::Forms class. If you omit this key, then it will be assumed that the form is a Curses::Forms object, or some custom derivative as specified in ALTPATH.

Geometry Description Markup Language (GDML) workpackage is primarly ment to provide geometry data exchange format for the LCG applications. The workpackage consists of the GDML Schema part, which is a fully self-consistent definition of the GDML syntax and the GDML I/O part which provides means for writing out and reading in GDML files.
The GDML Schema does not depend in any way on the GDML I/O packages. In particular, new extensions to the GDML I/O packages can be implemented (interfaces to new application, like for instance visualisation, editors, etc), while the GDML Schema definition remains unchanged.
Enhancements:
- The loop machinery was improved so that any volume can be used in a loop.
- An installation script was added along with support for auxiliary volume information.
- A SimpleExtension example that shows how to extend GDML with custom elements was added.
- The obsolete PyGDML package was removed.

Crossword Formatter consists of a script to easily format HTML crossword puzzles.
Crossword Fromatter is a simple script that generates valid XHTML code for static crossword puzzles from a simple definition file. The package also includes CSS files for proper display of the crossword puzzle.
With no arguments, the cwd.pl script reads a crossword definition file from standard input and writes an HTML version of the puzzle to standard output.
Enhancements:
- This release adds a Javascript solving interface and small bugfixes.

Myco::Entity is a common base class for all Myco entity classes.

SYNOPSIS

### Entity class definition

package Myco::Foo;
use base qw(Myco::Entity);

# Start building metadata
my $metadata = Myco::Entity::Meta->new
( name => __PACKAGE__,
tangram => { table => Foo }
);

$metadata->add_attribute(name => attr1, type => string);
$metadata->add_attribute(name => attr2, type => string);

# class-specific methods defined ...
#

# Fill in $schema with all added_attributes and discover other metadata
$metadata->activate_class;



### Entity class usage

use Myco::Foo;

# Constructor
$obj = Myco::Foo->new;
$obj = Myco::Foo->new(attr1 => value, attr2 => value);

# Access class metadata (see Myco::Entity::Meta)
$meta = Myco::Foo->introspect;
$meta = $obj->introspect;

# Accessors
$obj->get_attr1; # get attribute value
$obj->set_attr1(value); # set attribute value

# Instance methods
$id = $obj->save; # update objects state in persistent
# storage, create new record if needed;
# returns objects Tangram id
$obj->destroy;
$obj->modify(attr1 => val, attr2 => val);
$object_id = $obj->id;
$obj->is_transient; # returns true if object is in Tangram
# transient storage

## object retrieval (see class Myco documentation
# for full detail)

$obj = Myco->load($object_id);

# fetch all objects of given type
@objects = Myco->select(ref $obj);

Provides, via inheritence, common interface in support of basic lifecycle needs for myco entity objects.

This is accomplished through the encapsulation of the CPAN module Class::Tangram which provides a basis for "in-memory" object behavior. Consult its documentation for details on schema definition syntax, getter/setter behavior, check functions, etc.

The common interface for object persistence behavior (referred within myco as "transaction" behavior) is provided through defintion of a handful of related instance methods. This is done with reliance on the services of the class Myco, which encapsulates the functionality of Tangram::Storage and provides system-wide connection handling.

Parse::Nibbler is Perl module to parse huge files using grammars written in pure perl.

Create a parser object using the ->new method. This method is provided by the Parse::Nibbler module and should not be overridden.

The main functionality of the Parse::Nibbler module is the Register subroutine. This subroutine is used to define the rules of your grammar. The Register subroutine takes two parameters: A string and a code reference.

The string is the name of the rule (i.e. the name of the subroutine/method)

The code reference is a reference to the code to execute for this rule.

The Register subroutine will take the code reference, wrap it up in another subroutine that acts as a closure, and then installs that code reference as a subroutine with the name matching the given string.

The wrapper code (the closure) is the same for every rule. The wrapper code handles quantifiers, calls the rule, and decides what to do based on the rule passing or failing.
A rule is a code reference with a given string name that have been passed to Register. Here is an example of a rule:
Register ( Name, sub { my $p = shift; $p->AlternateValues( Jim, Scotty, Spock );
}
);

The parser object will always be passed in as the first parameter to your rule. You must pass this into any further rules or any Parse::Nibbler methods.

In the above example, the rule, "Name" is Registered. "Name" calls one of the builtin methods, AlternateValues, defined below. Once a rule is Registered, other rules can call it:
Register ( MedicalDiagnosis, sub { my $p = shift; $p->AlternateValues("Hes", "Shes"); $p->ValueIs("dead"); $p->ValueIs(","); $p->Name; $p->ValueIs("!"); } );

This code registers a rule called "MedicalDiagnosis". It uses some builtin methods, but it also calls the rule just registered, "Name".

Once a user defines a rule, they can use it in other rules by simply calling it as they would call a method.

Rules registered with the Parse::Nibbler module can be called with quantifiers. Quantifiers are passed into the Rule when you call it in your grammar by passing in a string that matches the format described here.

Quantifiers allow you to specify the quantity of rules present. Quantifiers also allow you to specify whether multiple rules have separators.

Quantifiers are specified using the following string format:

{quantifier}

This indicates that there are zero or one Name rules expected: $p->Name({?});
This indicates that there are zero or more Name rules expected: $p->Name({*});
This indicates that there are one or more Name rules expected: $p->Name({+});
This indicates that there are exactly three Name rules expected: $p->Name({3});
This indicates there are 1 to 3 Name rules expected: $p->Name({1:3});
This indicates there are at least 2 Name rules expected: $p->Name({2:);

Separators are specified using the following string format:

/separator/

This indicates 1 or more Name rules, each separated by a comma:

$p->Name({1:}/,/);

It is the job of the Register function to make sure this additional functionality is provided transparently and automagically to you.

If you call a rule with no quantifier and no separator, the rule will assume the quantifier is 1 and there is no separator.

Additional Parse::Nibbler methods are provided to simplify rule definition and to provide smart, automatic error handling, etc. You grammars should only call other rules that you defined, or these methods explained below.

(Note: these methods do not take quantifiers)
############### Method: ValueIs ###############
Parameters: One parameter, required. A string containing the expected value.
Example: $p->ValueIs( stringvalue );
Description:
This method will look at the next lexical and determine if its value matches that of the stringvalue given as a parameter. If it does not match, an exception is raised and the rule fails.
If the values do match, then the parser stores the lexical, and the rule continues.
####################### Method: AlternateValues #######################
Parameters: A list of string parameters, at least two values.
Example: $p-AlternateValues( value1, value2 );
Description:
This method behaves like the ValueIs method, except that it will recieve a list of allowed alternate expected values. The first match that succeeds causes the rule to pass and return.
If no match occurs, then an exception is raised and the rule aborts.
If a match does occur, the parser stores the lexical, and the rule continues.
############## Method: TypeIs ##############
Parameters: One parameter, required. A string containing the expected type.
Description:
This method will look at the next lexical item, and determine if the lexical type matches the type given as a parameter.
Valid type values depend on the Lexer that you use, but possible values may include "Identifier" and "Number", etc.
Use this in a case where your rule requires an identifier type, for example, but it does not care what the name of the identifier is for the rule.
If a match occurs, the parser stores the lexical and the rule continues.
If a match does not occur, an exception is raised, and the rule aborts.
###################### Method: AlternateRules ######################
Parameters: A list of string parameters, at least two.
Example: $p->AlternateRules( Rule1, Rule2 );
Description:
You can describe rule alternation in your rule by calling this method. The method takes a list of strings whose string values match the names of the valid alternate rule names.
In the above example, the McCoy rule is either a declaration of profession or a medical diagnosis. These are two rules that are defined in the same package. The AlternateRules method allows you to define multiple rules that may be valid at the same point in the text.
If a rule in the parameter list succeeds, the AlternateRule method succeeds, and returns immediately.
If no rule succeeds, an exception is thrown, and the rule aborts.
This rule expects either a "DeclareProfession" rule or a "MedicalDiagnosis" rule to be present.
Register ( McCoy, sub { my $p = shift; $p->AlternateRules( DeclareProfession, MedicalDiagnosis ); } );
You can specify quantifiers as part of the alternate rule strings.
$p->AlternateRules( DeclareProfession({+}), MedicalDiagnosis );
The above example indicates that you can have one or more DeclareProfession rules OR ALTERNATELY you can have exactly one MedicalDiagnosis rule.

EXPORT

Register, used to register the rules in your grammar.