Free area codes software for linux

FARnodes is a protocol simulation and execution environment. FARnodes project comes with a command-line frontend, a protocol code distribution manager, and a statistical analyser based on PyKDE.
Example algorithms like Consensus and several other small tools and a big chunk of documentation make this a suitable entry-level software for people who have some interest in this (somewhat academic) area.
Main features:
- High portability and easy extensibility of the framework due to a pure Python implementation.
- Protocols can assume either fully synchronous or asynchronous systems, or one of FAR (Finite Average Response times) or PS (Partial Synchrony).
- Channels can exhibit unreliable or stubborn behaviour.
- Failure detectors include EA-FD and PS-FD, both eventually perfect, but others can be added.
- Simulations can expect a virtual timer and can be saved and reloaded in many cases.
- Tools for remote execution and graphical data analysis.

Content Area Focus is an extension used to solve the content area focus loss.

Target audience: those who are mostly using the keyboard to navigate around and switch between tabs; frequently they encounter situations in which the content area doesnt have focus.

Method: just giving focus to the content area for any "regular" keystrokes made when the main-window is in focus.

Target project is an AJAX-enabled application that allows users to create and track one or more target areas.

The target area can then be resized and moved to new locations on the image. With a right-click, the movement and resize history can be replayed with DHTML animation and AJAX.

Code::Splice injects the contents of one subroutine at a specified point elsewhere.

SYNOPSIS

use Code::Splice;

Code::Splice::inject(
code => sub { print "fredn"; },
package => main,
method => foo,
precondition => sub {
my $op = shift;
my $line = shift;
$line =~ m/print/ and $line =~ m/four/;
},
postcondition => sub {
my $op = shift;
my $line = shift;
$line =~ m/print/ and $line =~ m/five/;
},
);

sub foo {
print "onen";
print "twon";
print "threen";
print "fourn";
print "fiven";
}

This module removes the contents of a subroutine (usually an anonymous subroutine created just for the purpose) and splices in into the program elsewhere.

Why, you ask?

Write stronger unit tests than the granularity of the API would otherwise allow

Write unit tests for nasty, interdependant speghetti code (my motivation -- hey, you gotta have tests before you can start refactoring, and if you cant write tests for the code, youre screwed)

Fix stupid bugs and remove stupid restrictions in other peoples code in a way thats more resiliant across upgrades than editing files you dont own

Be what "aspects" should be

Screw with your cow-orkers by introducing monster heisenbugs

Play with self-modifying code

Write self-replicating code (but be nice, were all friends here, right?)

The specifics:

The body of the code { } block are extracted from the subroutine and inserted in a place in the code specified by the call to the splice() function. Where the new code is spliced in, the old code is spliced out. The package and method arguments are required and tell the thing how to find the code to be modified. The code argument is required as it specifies the code to be spliced in. That same code block should not be used for anything else under penalty of coredump.

The rest of the argumets specify where the code is to be inserted. Any number of precondition and postcondition arguments provide callbacks to help locate the exact area to splice the code in at. Before the code can e spliced in, all of the precondition blocks must have returned true, and none of the postcondition blocks may have yet returned true. If a postcondition returns true before all of the precondition blocks have, an error is raised. Both blocks get called numerous times per line and get passed a reference to the B OP object currently under consideration and the text of the current line:

precondition => sub {
my $op = shift;
my $line = shift;
$line =~ m/print/ and $line =~ m/four/;
},
... or...
precondition => sub { my $op = shift; $op->name eq padsv and $op->sv->sv =~ m/fred/; },

Its possible to insert code in the middle of an expression when testing ops, but when testing the text of the line of code, the spliced in code will always replace the whole line.
Ill probably drop sending in the opcode in a future version, at least for the precondition/postcondition blocks, or maybe Ill swap them to the 2nd arg so theyre more optional.

Do not attempt to match text in comments as it wont be there. The code in $line is re-generated from the bytecode using B::Deparse and will vary from the original source code in a few ways, including changes to formatting, changes to some idioms and details of the expressions, and formatting of the code with regards to whitespace.

The splicing code will die if it fails for any reason. This will likely change in possible future versions.
There are also label and line arguments that create preconditions for you, for simple cases. Of course, you shouldnt use line for anything other than simple experimentation.

References to lexical variables in the code to be injected are replaced with references to the lexical variables of the same name in the location the code is inserted into. If a variable of the same name doesnt exist there, its an error. ... but it probably shouldnt be an error, at least in the cases where the code being spliced in declares that lexical with my, or when the variable was initiailized entirely outside of the sub block being spliced in and was merely closed over by it.

See the comments in the source code (at the top, in a nice block) for my todo/desired features. Let me know if there are any features in there or yet unsuggested that you want. I wont promise them, but I would like to hear about them.

Acovea implements a genetic algorithm for finding the "best" options for compiling programs with the GCC C and C++ compilers.
ACOVEA (Analysis of Compiler Options via Evolutionary Algorithm) implements a genetic algorithm to find the "best" options for compiling programs with the GNU Compiler Collection (GCC) C and C++ compilers.
"Best", in this context, is defined as those options that produce the fastest executable program from a given source code. Acovea is a C++ framework that can be extended to test other programming languages and non-GCC compilers.
I envision Acovea as an optimization tool, similar in purpose to profiling. Traditional function-level profiling identifies the algorithms most influential in a programs performance; Acovea is then applied to those algorithms to find the compiler flags and options that generate the fastest code.
Acovea is also useful for testing combinations of flags for pessimistic interactions, and for testing the reliability of the compiler.
Modern software is difficult to understand and verify by traditional means. Millions of lines of code produce applications containing intricate interactions, defying simple description or brute-force investigation.
A guided, deterministic approach to testing relies on human testers to envision every possible combination of actions -- an unrealistic proposition given software complexity. Yet, despite that complexity, we need answers to important questions about modern, large-scale software.
What sort of important questions? Consider the GNU Compiler Collection. I write articles that benchmark code generation, a task fraught with difficulties due to the myriad options provided by different compilers. For my benchmarks to have any meaning, I need to know which combination of options produces the fastest code for a given application.
Finding the "best" set of options sounds like a simple task, given the extent of GCC documentation and the conventional wisdom of the GCC developer community. Ah, if it were only so easy! The GCC documentation, while extensive, is also honestly imprecise.
I appreciate this style of documentation; unlike many commercial vendors, who make absolute statements about the "quality" of their products, GCCs documenters admit uncertainties in how various options alter code generation. Indeed, code generation is entirely dependent on the type of application being compiled and the target platform. An option that produces fast executable code for one source code may be detrimental to the performance of another program.
"Conventional wisdom" arrives in my inbox whenever I publish a new article. Ranging from the polite to the insistent to the rude, these e-mails contain contradictory suggestions for producing fast code.
In the vast majority of cases, such anecdotal assertions lack any formal proof of their validity, and, more often than not, the suggested "improvement" is ineffective or detrimental. It has become increasingly obvious that no one --myself included -- knows precisely how all these GCC options work together in generating program code.
I seek the Holy Grail of Optimization -- but exactly what is optimization? Understanding the problem is the first step in finding a solution.
Optimization attempts to produce the "best" machine code from source code. "Best" means different things to different applications; a database shovels chunks of information, while a scientific application is concerned with fast and accurate results; the first concern for an embedded system may be code size.
And it is quite possible that small code is fast, or fast code accurate. Optimization is far from being an exact science, given the diversity of hardware and software configurations.
An optimization algorithm may be as simple as removing a loop invariant, or as complex as examining an entire program to eliminate global common sub-expressions. Many optimizations change what the programmer wrote into a more efficient form, producing the same result while altering underlying details for efficiency; other "optimizations" produce code that uses specific characteristics of the underlying hardware, such as special instruction sets.
Memory architectures, pipelines, on- and off-chip caches -- all affect code performance in ways that are not obvious to programmers using a high-level language. An optimization that may seem to produce faster code may, in fact, create large code that causes more cache misses, thus degrading performance.
Even the best hand-tuned C code contains areas of interpretation; there is no absolute, one-to-one correspondence between C statements and machine instructions. Almost any sequence of source code can be compiled into different -- but functionally equivalent -- machine instruction streams with different sizes and performance characteristics.
Inlining functions is a classic example of this phenomena: replacing a call to a function with the function code itself may produce a faster program, but may also increase program size. Increased program size, may, in turn, prevent an algorithm from fitting inside high-speed cache memory, thus slowing a program due to cache misses.
Notice my use of the weasel word "may" -- inlining small functions sometimes allows other optimization algorithms a chance to further improve code for local conditions, producing faster and smaller code.
Optimization is not simple or obvious, and combinations of algorithms can lead to unexpected results. Which brings me back to the question: For any given application, what are the most effective optimization options?
Enhancements:
- Minor changes in the non-free license.
- Support has been added for the latest versions of libcoyotl and libevocosm.

Geography::Countries is a Perl module with 2-letter, 3-letter, and numerical codes for countries.

SYNOPSIS

use Geography::Countries;

$country = country DE; # Germany
@list = country 666; # (PM, SPM, 666,
# Saint Pierre and Miquelon, 1)

This module maps country names, and their 2-letter, 3-letter and numerical codes, as defined by the ISO-3166 maintenance agency [1], and defined by the UNSD.

The country subroutine.

This subroutine is exported by default. It takes a 2-letter, 3-letter or numerical code, or a country name as argument. In scalar context, it will return the country name, in list context, it will return a list consisting of the 2-letter code, the 3-letter code, the numerical code, the country name, and a flag, which is explained below. Note that not all countries have all 3 codes; if a code is unknown, the undefined value is returned.

There are 3 categories of countries. The largest category are the current countries. Then there is a small set of countries that no longer exist. The final set consists of areas consisting of multiple countries, like Africa. No 2-letter or 3-letter codes are available for the second two sets. (ISO 3166-3 [3] defines 4 letter codes for the set of countries that no longer exist, but the author of this module was unable to get her hands on that standard.) By default, country only returns countries from the first set, but this can be changed by giving country an optional second argument.
The module optionally exports the constants CNT_F_REGULAR, CNT_F_OLD, CNT_F_REGION and CNT_F_ANY. These constants can also be important all at once by using the tag :FLAGS.

CNT_F_ANY is just the binary or of the three other flags. The second argument of country should be the binary or of a subset of the flags CNT_F_REGULAR, CNT_F_OLD, and CNT_F_REGION - if no, or a false, second argument is given, CNT_F_REGULAR is assumed. If CNT_F_REGULAR is set, regular (current) countries will be returned; if CNT_F_OLD is set, old, no longer existing, countries will be returned, while CNT_F_REGION is used in case a region (not necessarely) a country might be returned. If country is used in list context, the fifth returned element is one of CNT_F_REGULAR, CNT_F_OLD and CNT_F_REGION, indicating whether the result is a regular country, an old country, or a region.

In list context, country returns a 5 element list. To avoid having to remember which element is in which index, the constants CNT_I_CODE2, CNT_I_CODE3, CNT_I_NUMCODE, CNT_I_COUNTRY and CNT_I_FLAG can be imported. Those constants contain the indices of the 2-letter code, the 3-letter code, the numerical code, the country, and the flag explained above, respectively. All index constants can be imported by using the :INDICES tag.

The code2, code3, numcode and countries routines.
All known 2-letter codes, 3-letter codes, numerical codes and country names can be returned by the routines code2, code3, numcode and countries. None of these methods is exported by default; all need to be imported if one wants to use them. The tag :LISTS imports them all. In scalar context, the number of known codes or countries is returned.

Wide Area Link Emulator enables you to set and test various parameters of a WAN access link (also known as a bottleneck link) before testing on a fully-functional network.

Any ISP has a high bandwidth LAN (of the order of tens of Mbps, e.g. Ethernet) and a WAN access link with relatively low speeds (of the order of a few Kbps to a few Mbps). To be able to evaluate the ISPs performance, actual tests will have to be conducted on a live, fully functional network. This would imply enabling certain features in communication equipment which could be detrimental to the proper functioning of a commissioned network. To address such a problem of being able to characterize/quantify the network operation in terms of its performance with respect to various parameters, a test-bed emulating the ISPs connectivity to the Internet would be an ideal solution.

An important factor in setting up such a test-bed, is emulating the WAN Access Link. Using complex hardware is costly. Such a link can however be easily implemented by emulating the scenario on popular physical technology such as Ethernet. By changing the TCP/IP stack on a Personal Computer, the rate at which packets are injected into the network can be controlled and other necessary features can easily be added.

WALE was implemented in 2 phases and the first version can emulated bandwidths up to 8Mbps and uses FIFO queues with drop-tail.

WALE v2 can emulate bandwidths of up to 80Mbps(a 10-fold improvement over version 1) due to the stripped down version of Micro-second resolution timer being used in the Linux kernel. WALE also implements differentiated services are recommended by IETF. A hash-based packet classifier is used to classify packets into one of 3 queues (Expedited Forwarding, Assured Forwarding and Best Effort). A simple priority scheduling has been implemented between the queues.

Version 2 has been implemented in the Generic Device Layer of the Linux Kernel. The kernel version is 2.2.19. WALE2 kernel patch can be downloaded here. An ncurses based front end has been implemented for setting and viewing various parameters of the bottleneck link.

MetaC language extends C in a 100% backward compatible way with reflective features and techniques for refactoring, reconfiguring and modifying arbitrary C source code.
Therefore, the extensions provide special metadata types for working with source code information, syntactical structures for the definiton of code templates, and metafunctions to gather information about source code and refactor, modify, delete, or insert code.
Some of the modifications that can be done with MetaC, are also realizable with the C preprocessor. But the C preprocessor suffers certain limitations that can be overcome using MetaC.
The area of applications for MetaC is not limited to specific domains. But its concepts and its motivation has been derived from problems of CASE tools for embedded real-time systems (e.g. Mathworks Matlab, Telelogics Tau, Aonixs STP).
- Source code reconfiguration and refactoring in general.
- Abstraction of APIs and hardware-specific or vendor-specific implementations of well-defined functionallity (ever got locked to a specfic API by a RTOS vendor?).
- Source code instrumentation for WCET-analysis
- Adaption of source code to multiple embedded targets (especially differing native platform APIs) based upon an abstract machine model
- Application specific debug support (e.g. control-flow or data-flow tracing)
- Verification of domain- and application-specific constraints (e.g. MISRAs rules set for C based programs in automotive applicaitons)
Advantages of the Metaprogramming Approach:
- Source code modification is done based upon syntax. In consequence invalid modifications can be detected at the moment they are executed.
- Decision for code modifications can be made upon user parameters and information derived from the source code
- Crosscutting reconfigurations (i.e. reconfigurations concerning multiple functions or modules) of source code are possible.
Enhancements:
- Support for Win32 hosts was added.
- Support for initializer lists was added.
- Some C99 issues were fixed.
- Several more enhancements were made.
- A whole bunch of bugs were fixed.