Free conditionals software for linux

deb-install is a (big) shellskript, that works on top of the package management tools provided by the debian project.
The goal is to create one command that installs any package into your system, or provides information about any package, without the user having to know all the different tools there are.
Version restrictions:
- On some systems bash reports deb-install as culprit if one of its configuration files contains an invalid command. Other then a slightly misleading error message, this doesnt have bad consequences.
Enhancements:
- Made deb-install able to recover from error when working with local files (more exactly: When working with a local file, deb-install remembers the state it is in. After it aborted, you can restart it in such a way, that it enters into that same state again [preferably after you removed the reason for the error].)
- Added option --abort-on , which lets you stop deb-install partway, when working with local files.
- Added option --dpkg-buildpackage, which lets you pass through options to that tool (used to build the .deb file if you compile from source).
- Changed location of user specific configuration files (to ~/.deb-install/deb-install.conf).
- Improved tab completion: It is faster, can expand the tilde (~), and now also works for files and directories containing spaces.
- Changed temp deletion behaviour. Now deb-install only deletes a left over temp directory if you tell it to work with a local file. That means you can install missing packages using apt-get via deb-install when a compile aborts, and resume the compile afterwards.
- Removed tracking of changes to the temp directory. The code was complicated, and now that the temp directory isnt deleted as often, I think the ability is not very useful.
- deb-install doesnt switch into searchmode anymore, if it cant find a file or package. After all, we now have tab completion, and search mode does take quite some time. Who says the user wants to do that?
- Added support for slackware packages.
- Changed interpretation of configuration files: Until now, they were read in by a simple text parser. Now they are executed by bash. This gives the user much more possibilities of how to define the variables (.e.g. conditional defines). Furthermore, all program constants are now redefineable in the conf files.
- Important: Old configuration files are NOT compatible (They contain spaces around "=", were there should be none).
- Added option --, which works just as you probably expect: No more options after this one. This allows for filenames starting with a dash.
- Expanded the documentation.

mod_tee serves to "clone" an document as it is served. mod_tee was hacked up as a quick-and-dirty fix when a Site Valet user complained of problems saving a Valet report: mod_tee now serves to enable registered users to request email copies of any report generated.

The current status is "works for us", but it is not of release quality. It is less-than-complete in several respects. Its probably not a good idea to use it operationally unless youre prepared to get your hands dirty fixing any problems, or pay for support.

Configuration

TeeType FILE|PIPE|SMTP [Destination]
Where to send the cloned output:

FILE - save to a destination file. For testing only!
PIPE - pipes output to a destination program with popen.
SMTP - sends cloned output directly to email at a destination mailserver. Implements SMTP handshake with no error checking - so its a dangerous option!

TeeCondition query|cookie|path|header|env|true|false [key] [val]

Defines a condition for mod_tee to be activated for a request. Values true and false are unconditional, while the others define a QUERY_STRING key, a Cookie, a PATH_INFO component, a request header or an environment variable to trigger the tee. Conditional values require a key. If val is defined then key must match it; otherwise any value of key will activate the tee.

TeeHeader key value

Defines an RFC822-style header to be inserted in front of the body of the page.

File Selection Language (FSL) is a descriptive language for file selection. File Selection Language is used to selectively pick files from a directory structure.
FSL is useful for selective backups, for instance. FSL uses glob patterns as the basic building block.
For fine-tuning the selection, inclusion/exclusion rule combinations and conditional expressions are available. File size and modification date can be used in expressions.
Main features:
- FSL can be used with a command line tool (fsltool) or, for Python programmers, with a programmable interface. For the Python interface, see the documentation of Interpreter.py.
- Several FSL rule files can be combined in a cascading manner similar to CSS. The effect is the same as if the rule files were pasted into a single file.
- Support for both Windows-like and Unix-like paths.
- Strict parse-time type checking to catch as many errors as possible before run-time. For example, you cant say EACH f IF size(5) > 1000 because function size expects filename argument.

XOTcl (XOTcl, pronounced exotickle) is an object-oriented scripting language based on MITs OTcl. XOTcl is intended as a value added replacement for OTcl.
XOTcl is an open source project which was initiated by Gustaf Neumann and Uwe Zdun, its main developers. The following people have contributed to XOTcl: Neophytos Demetriou, Fredj Dridi, Laurent Duperval, Teemu Hukkanen, MichaelL@frogware.com, Kristoffer Lawson, David LeBlanc, Catherine Letondal, Antti Salonen, Daniel Steffen, and Zoran Vasiljevic.
Scripting languages, like Tcl, are designed for glueing components together, provide features like dynamic extensibility and dynamic typing with automatic conversion, that make them well suited for rapid application development.
The basic object system of XOTcl is adopted from OTcl. The object system enables us to define objects, classes, and meta-classes. Classes are special objects with the purpose of managing other objects. ``Managing means that a class controls the creation and destruction of its instances and that it contains a repository of methods accessible for the instances.
Every object may be enhanced with object-specific methods. XOTcl supports single and multiple inheritance. All relationships in XOTcl, including class and superclass relationships, are completely dynamic and can be introspected. Through method chaining without explicit naming of the intended method, ambiguities in name resolution of methods are avoided. This way a shadowed method can be ``mixed into the execution of the current method.
XOTcl combines the ideas of scripting and object-orientation in a way that preserves the benefits of both of them. It is equipped with several new language functionalities that help building and managing complex systems. We added the following support:
Main features:
- Dynamic Object Aggregations, to provide dynamic aggregations through nested namespaces (objects).
- Nested Classes, to reduce the interference of independently developed program structures.
- Assertions, to reduce the interface and the reliability problems caused by dynamic typing and, therefore, to ease the combination of many components.
- Meta-data, to enhance self-documentation of objects and classes.
- Per-object mixins, as a means to improve flexibility of mixin methods by giving an object access to several different supplemental classes, which may be changed dynamically.
- Per-class mixins, as a means to improve flexibility of mixin methods to a class, all instances of the class have access to the mixed in methods like for multiple inheritance, but without the need of intersection classes.
- Filters (per class and per object) as a means of abstractions over method invocations to implement large program structures, like design patterns.
- Conditional Filters and Mixins can be used to perform context aware composition depending on guards (conditions which decide whether the interceptor should be used). All kinds of filters or mixins can be used conditionally.
- Dynamic Component Loading XOTcl integrates the Tcl package loading with architectrual support for integration with object-oriented constructs. Moreover, it provides tracking/tracing of component loading.

PAPI aims to provide the tool designer and application engineer with a consistent interface and methodology for use of the performance counter hardware found in most major microprocessors.
PAPI enables software engineers to see, in near real time, the relation between software performance and processor events.
The Performance API (PAPI) project specifies a standard application programming interface (API) for accessing hardware performance counters available on most modern microprocessors.
These counters exist as a small set of registers that count Events, occurrences of specific signals related to the processors function. Monitoring these events facilitates correlation between the structure of source/object code and the efficiency of the mapping of that code to the underlying architecture.
This correlation has a variety of uses in performance analysis including hand tuning, compiler optimization, debugging, benchmarking, monitoring and performance modeling. In addition, it is hoped that this information will prove useful in the development of new compilation technology as well as in steering architectural development towards alleviating commonly occurring bottlenecks in high performance computing.
PAPI provides two interfaces to the underlying counter hardware; a simple, high level interface for the acquisition of simple measurements and a fully programmable, low level interface directed towards users with more sophisticated needs.
The low level PAPI interface deals with hardware events in groups called EventSets. EventSets reflect how the counters are most frequently used, such as taking simultaneous measurements of different hardware events and relating them to one another.
For example, relating cycles to memory references or flops to level 1 cache misses can indicate poor locality and memory management. In addition, EventSets allow a highly efficient implementation which translates to more detailed and accurate measurements.
EventSets are fully programmable and have features such as guaranteed thread safety, writing of counter values, multiplexing and notification on threshold crossing, as well as processor specific features. The high level interface simply provides the ability to start, stop and read specific events, one at a time.
PAPI provides portability across different platforms. It uses the same routines with similar argument lists to control and access the counters for every architecture. As part of PAPI, we have predefined a set of events that we feel represents the lowest common denominator of every good counter implementation.
Our intent is that the same source code will count similar and possibly comparable events when run on different platforms. If the programmer chooses to use this set of standardized events, then the source code need not be changed and only a fresh compilation and link is necessary. However, should the developer wish to access machine specific events, the low level API provides access to all available events and counting modes.
If an event or feature does not exist on the current platform, PAPI returns an appropriate error code. This significantly reduces the porting effort of code using PAPI because the semantics of each call to PAPI remains the same, just the argument lists need updating. In addition to the standard set, each PAPI implementation supports all native events through the ability to directly accept platform specific counter numbers. Definitions for most, if not all of these, are included as conditional macros in the header file. In this way, PAPI avoids having inefficient code to translate all events for all platforms into a uniform representation and back again.
This translation is only done for the relatively few events defined in the standardized set. Some processors like those in the POWER series have counter groups. They enable access to specific groups of counters, instead of individual events. This presents a serious portability problem, thus PAPI abstracts hardware counters from their groups with a packed naming scheme. Each counter control value or event is made up of the counter group number and the number of the specific counter in that group.
PAPI can be divided into two layers of software. The upper layer consists of the API and machine independent support functions. The lower layer defines and exports a machine independent interface to machine dependent functions and data structures. These functions access the substrate, which may consist of the operating system, a kernel extension or assembly functions to directly access the processors registers.
PAPI tries to use the most efficient and flexible of the three, depending on what is available. Naturally, the functionality of the upper layers heavily depends on that provided by the substrate. In cases where the substrates do not provide highly desirable features, PAPI attempts to emulate them as described below.
PAPI makes sure the underlying operating system or library guards against overflow of counter values.
Each counter can potentially be incremented multiple times in a single clock cycle. This combined with increasing clock speeds and the small precision of some of the physical counters means that overflow is likely to occur.
One of the more advanced features of PAPI is to provide a portable implementation of asynchronous notification when counters exceed a user specified value.
This functionality provides the basis for PAPIs SVR4 compatible profiling calls, that generate an accurate histogram of performance interrupts based on hardware metrics, not on time. Such functionality provides the basis for all line level performance analysis software, from the antiquated days of AT&Ts prof to SGIs SpeedShop. Thus for any architecture with even the most rudimentary access to hardware performance counters, PAPI provides the foundation for a truly portable, source level, performance analysis tool based on real processor statistics.
Enhancements:
- The API was extended to decouple abstraction layers from hardware support and to provide initial support for different types of performance counters.

Calc is arbitrary precision arithmetic system that uses a C-like language. Calc is useful as a calculator, an algorithm prototype, and as a mathematical research tool.
More importantly, calc provides a machine-independent means of computation. Calc comes with a rich set of builtin mathematical and programmatic functions.
For example, the following line can be input:
3 * (4 + 1)
and the calculator will print:
15
Calc as the usual collection of arithmetic operators +, -, /, * as well as ^ exponentiation), % (modulus) and // (integer divide). For example:
3 * 19^43 - 1
will produce:
29075426613099201338473141505176993450849249622191102976
Notice that calc values can be very large. For example:
2^23209-1
will print:
402874115778988778181873329071 ... many digits ... 3779264511
The special . symbol (called dot), represents the result of the last command expression, if any. This is of great use when a series of partial results are calculated, or when the output mode is changed and the last result needs to be redisplayed. For example, the above result can be modified by typing:
. % (2^127-1)
and the calculator will print:
39614081257132168796771975167
For more complex calculations, variables can be used to save the intermediate results. For example, the result of adding 7 to the previous result can be saved by typing:
curds = 15
whey = 7 + 2*curds
Functions can be used in expressions. There are a great number of pre-defined functions. For example, the following will calculate the factorial of the value of old:
fact(whey)
and the calculator prints:
13763753091226345046315979581580902400000000
The calculator also knows about complex numbers, so that typing:
(2+3i) * (4-3i)
cos(.)
will print:
17+6i
-55.50474777265624667147+193.9265235748927986537i
The calculator can calculate transcendental functions, and accept and display numbers in real or exponential format. For example, typing:
config("display", 70)
epsilon(1e-70)
sin(1)
prints:
0.8414709848078965066525023216302989996225630607983710656727517099919104
Calc can output values in terms of fractions, octal or hexadecimal. For example:
config("mode", "fraction"),
(17/19)^23
base(16),
(19/17)^29
will print:
19967568900859523802559065713/257829627945307727248226067259
0x9201e65bdbb801eaf403f657efcf863/0x5cd2e2a01291ffd73bee6aa7dcf7d1
All numbers are represented as fractions with arbitrarily large numerators and denominators which are always reduced to lowest terms. Real or exponential format numbers can be input and are converted to the equivalent fraction. Hex, binary, or octal numbers can be input by using numbers with leading 0x, 0b or 0 characters.
Complex numbers can be input using a trailing i, as in 2+3i. Strings and characters are input by using single or double quotes.
Commands are statements in a C-like language, where each input line is treated as the body of a procedure. Thus the command line can contain variable declarations, expressions, labels, conditional tests, and loops. Assignments to any variable name will automatically define that name as a global variable.
The other important thing to know is that all non-assignment expressions which are evaluated are automatically printed. Thus, you can evaluate an expressions value by simply typing it in.
Many useful built-in mathematical functions are available. Use the:
help builtin
command to list them.
You can also define your own functions by using the define keyword, followed by a function declaration very similar to C.
define f2(n)
{
local ans;
ans = 1;
while (n > 1)
ans *= (n -= 2);
return ans;
}
Thus the input:
f2(79)
will produce;
1009847364737869270905302433221592504062302663202724609375
Functions which only need to return a simple expression can be defined using an equals sign, as in the example:
define sc(a,b) = a^3 + b^3
Thus the input:
sc(31, 61)
will produce;
256772
Variables in functions can be defined as either global, local, or static. Global variables are common to all functions and the command line, whereas local variables are unique to each function level, and are destroyed when the function returns.
Static variables are scoped within single input files, or within functions, and are never destroyed. Variables are not typed at definition time, but dynamically change as they are used.
Enhancements:
- Documentation was written for the # operator, comments, and cscripts.
- Multi-line statement issues were documented.
- Builtins related to user, system, and clock time were added.
- The runtime() builtin output was changed.

InteLib is a library of C++ classes which lets you do Lisp programming within your C++ program even without any additional preprocessing, without all those calling conventions etc.
You can write a C++ code (that is, a code which is accepted by your C++ compiler) thinking in a "Lisp mode" and the code you write will look much like Lisp code altough it will be pure C++.
To give you the essential feeling, the following example is provided.
(defun isomorphic (tree1 tree2)
(cond ((atom tree1) (atom tree2))
((atom tree2) NIL)
(t (and (isomorphic (car tree1)
(car tree2))
(isomorphic (cdr tree1)
(cdr tree2))
))))
Just a Lisp function, isnt it? Now look at the following code:
(L|DEFUN, ISOMORPHIC, (L|TREE1, TREE2),
(L|COND,
(L|(L|ATOM, TREE1), (L|ATOM, TREE2)),
(L|(L|ATOM, TREE2), NIL),
(L|T, (L|AND,
(L|ISOMORPHIC, (L|CAR, TREE1),
(L|CAR, TREE2)),
(L|ISOMORPHIC, (L|CDR, TREE1),
(L|CDR, TREE2))
))))
Obviously the code is just the same, the syntax changed a bit, but its still the same. Well, do I surprise you if I say it is C++ code? If you dont believe, look at the following:
// File isomorph.cpp
#include "lisp/lisp.hpp"
#include "lisp/lsymbol.hpp"
#include "lfun_std.hpp"
LSymbol ISOMORPHIC("ISOMORPHIC");
static LFunctionalSymbol< LFunctionDefun > DEFUN("DEFUN");
static LFunctionalSymbol< LFunctionCond > COND("COND");
static LFunctionalSymbol< LFunctionAtom > ATOM("ATOM");
static LFunctionalSymbol< LFunctionAnd > AND("AND");
static LFunctionalSymbol< LFunctionCar > CAR("CAR");
static LFunctionalSymbol< LFunctionCdr > CDR("CDR");
LListConstructor L;
void LispInit_isomorphic() {
static LSymbol TREE1("TREE1");
static LSymbol TREE2("TREE2");
////////////////////////////////////////////////
//
(L|DEFUN, ISOMORPHIC, (L|TREE1, TREE2),
(L|COND,
(L|(L|ATOM, TREE1), (L|ATOM, TREE2)),
(L|(L|ATOM, TREE2), NIL),
(L|T, (L|AND,
(L|ISOMORPHIC, (L|CAR, TREE1),
(L|CAR, TREE2)),
(L|ISOMORPHIC, (L|CDR, TREE1),
(L|CDR, TREE2))
)))).Evaluate();
//
////////////////////////////////////////////////
}
// end of file
Well, this code is a complete C++ module and it does compile pretty well. No joke, its real.
By the way, dont try to find any use I made out of the macroprocessor. No macros have ever been used by InteLib (except those for conditional compile directives). Instead, just recall that comma is an operator in C++ and can be overloaded for user-invented data types.
Enhancements:
- Some new package-related features are implemented, and the GNU readline autodetection has been fixed.