Free yblagulous means poorly defined software for linux

IMAPEngine provides an IMAP server which retrieves via POP3 and organizes mail in a database.
IMAPEngine is an IMAP server that uses a tdbengine database structure to store all accounts, messages, and mailboxes. This means it has nearly no limits in numbers, sizes, and performance, and it uses indexes to sort/find its data.
IMAPEngine is IMAP4Rev1 compatible and also has built-in support for the ACL, ID, IDLE, and UIDPLUS extensions. It is not (yet) an MTA, but it retrieves incoming messages from different POP3 servers. An simple integrated Web interface makes account configuration easy.
Enhancements:
- corrected imapfetch.mod
- included easyserver web server and developed index.mod for web based account configuration
- created imapconfig.mod for basic account setup on command line (better use the web frontend!)
- code cleanups, restructuring and some performance tweaking
- improved the table structure: bodies are stored as BLOB now. This raises the download performance significantly on big emails (more than ~2 MB)
- added the UIDPLUS extension as defined in RFC 2359. Mozilla Mail can handle it properly
- free client dependend flags now can be used (e.g. "Junk" sign of Mozilla Mail)
- the LIST and LSUB commands are now processed as defined in the IMAP4Rev1
- smaller semaphore scopes to each command that writes to the db, so table locks use only the minimum amount of time they need
- added the NAMESPACE extension as defined in RFC 2342
- added the ACL extension as defined in RFC 2086 (the commands are all implemented, but the rights are not yet mentioned by the server)
- added the IDLE extension as defined in RFC 2177 (though not sending any information when idle!)
- added the ID extension as defined in RFC 2971

Essential Management provides a project management system for organizing and writing technical documents.

Essential Management is a multi-user project management system for managing intricate and complex information. Its initial purpose was to allow software development teams to create, maintain, track, and store project requirements on a multi-project basis in a multi-user environment. It has now become more abstract in the type of data it can maintain, allowing the easy addition of new data models and other expansions. Information can be stored in any of several database management systems, and can take advantage of a networked DBMS.

The first and most important feature of the application is that data is stored in a central data repository managed by some database management server; initially PostgreSQL fills this role, but support for others are growing. The repository is fully searchable. An alternative data storage format exists in the form of a locally maintained XML file if the user wishes to use it.

One of the key features Essential Management was designed around is the ability to define and maintain relationships between requirements. Using the software requirement model as an example, our application allows users to define projects; each project is composed of zero or more root requirements, which are typically business level requirements. Each business requirement has zero or more sub-requirements, which either refine the parent business requirement or dive into the functional requirements which allow the business requirement to be achieved. This tree continues to branch and grow deeper until the most basic level that the user wishes to define is reached.

In addition the relationship between parent and child requirements, relationships can be defined between requirements not in the same branch. These relationships may have any meaning the user wishes to define and can be unidirectional or bi-directional.

Essential Management implements the concept of user level permissions, which provides a small measure of security for the projects and their requirements. Additionally, creation of and changes to requirements can be traced to the user who initiated the action.

Finally, the application provides a means to track changes made to requirements during their lifetime so it is possible to determine when a change was made, what information was changed and who edited the requirement.

GNU Radio is a collection of software that when combined with minimal hardware, allows the construction of radios where the actual waveforms transmitted and received are defined by software. What this means is that it turns the digital modulation schemes used in todays high performance wireless devices into software problems.
What is a Software Defined Radio?
Joe Mitola says, "A software radio is a radio whose channel modulation waveforms are defined in software. That is, waveforms are generated as sampled digital signals, converted from digital to analog via a wideband DAC and then possibly upconverted from IF to RF. The receiver, similarly, employs a wideband Analog to Digital Converter (ADC) that captures all of the channels of the software radio node. The receiver then extracts, downconverts and demodulates the channel waveform using software on a general purpose processor."
For our purposes, on the receive side, the idea is to get a wide band ADC as close to the antenna as is convenient, get the samples into something we can program, and then grind on them in software.
Enhancements:
- GNU Radio 2.6 includes sending and receiving data at up to 1Mbit/sec using GMSK. - Theres also support for the new USRP Flex 400 transceiver daughterboards.
- Handling of all daughterboards has been unified, so most apps will work without modification on any of them. For those of you interested in wireless networking, see especially gnuradio-examples/python/gmsk2. Weve got a framework in place to allow you to build and experiment with your own MACs. 2.6 includes the "null MAC". A carrier sense MAC is the next logical step.

Class::Interfaces is a Per module for defining interface classes inline.

SYNOPSIS

# define some simple interfaces
use Class::Interfaces (
Serializable => [ pack, unpack ],
Printable => [ toString ],
Iterable => [ iterator ],
Iterator => [ hasNext, next ]
);

# or some more complex ones ...

# interface can also inherit from
# other interfaces using this form
use Class::Interfaces (
BiDirectionalIterator => {
isa => Iterator,
methods => [ hasPrev, prev ]
},
ResetableIterator => {
isa => Iterator,
methods => [ reset ]
},
# we even support multiple inheritance
ResetableBiDirectionalIterator => {
isa => [ ResetableIterator, BiDirectionalIterator ]
}
);

# it is also possible to create an
# empty interface, sometimes called
# a marker interface
use Class::Interfaces (
JustAMarker => undef
);

This module provides a simple means to define abstract class interfaces, which can be used to program using the concepts of interface polymorphism.

Object::Meta::Plugin::Host are hosts plugins that work like Object::Meta::Plugin. Can serve as a plugin if subclassed, or contains a plugin which can help it to plug.

SYNOPSIS

# if you want working examples, read basic.t in the distribution
# i dont know what kind of a synopsis would be useful for this.

my $host = new Object::Meta::Plugin::Host;

eval { $host->method() }; # should die

$host->plug($plugin); # $plugin defines method
$host->plug($another); # $another defines method and another

# $another supplied the following, since it was plugged in later
$host->method();
$host->another($argument);

$host->unplug($another);

$host->method(); # now $plugins method is used

Object::Meta::Plugin::Host is an implementation of a plugin host, as described in Object::Meta::Plugin.

The host is not just simply a merged hash. It is designed to allow various plugins to provide similar capabilities - methods with conflicting namespace. Conflicting namespaces can coexist, and take precedence over one another. A possible scenario is to have various plugins for an image processor, which all define the method "process". They are all installed, ordered as the effect should be taken out, and finally atop them all a plugin which wraps them into a pipeline is set.

When a plugins method is entered it receives, instead of the host object, a context object, particular to itself. It allows it access to its host, its sibling plugins, and so forth explicitly, while implicitly wrapping around the host, and emulating it with reordered priority - the current plugin is first in the list.

Such a model enables a dumb plugin to work quite happily with others, even those which may take its role. The only rule it needs to keep is that it accesses its data structures using $self-self>, and not $self, because $self is the context object.
A more complex plugin, aware that it may not be peerless, could explicitly ask for the default (host defined) methods it calls, instead of its own. It can request to call a method on the plugin which succeeds it or precedes it in a certain methods stack.

Additionally, by gaining access to the host object a plugin could implement a pipeline of calls quite easily, as described above. All it must do is call $self-host->stack($method)> and iterate that omitting itself.

The interface aims to be simple enough to be flexible, trying for the minimum it needs to define to be useful, and creating workarounds for the limitations this minimum imposes.

The implementation is by no means optimized. I doubt its fast, but I dont really care. Its supposed to create a nice framework for a large application, which needs to be modular.

Benzo is a blabberbot written in python. His means of generating text is a Markov Chain- an algorithm that takes english text as input, and generates output (when addressed) based on statistics gathered from the input text. At least thats what its used for here.

Just a few notes about version 1.0:

1) The implementation of persistence is quite sloppy- the entire brain is loaded into memory on startup and flushed to disk at set intervals - which amounts to an eventuallly large memory footprint and a sizeable CPU hit as the brain is deserialized/serialized. Future versions will be DBM/SQL based, and not have this limitation.

2) The module interface is not cleanly defined yet- so expect cusomizations made now to break in future versions.

3) Ditto for the config file.

4) Ditto for the User DB.

If all that hasnt discouraged you, set the bot loose on your favorite IRC channel. Let him sit and learn for awhile before announcing his presence, or else hell just repeat stuff.

The Analysis & Reconstruction Sound Engine also known as ARSE, is a program that analyses a sound file into a spectrogram and is able to synthetise this spectrogram, or any other user-created image, back into a sound.
The ARSE consists in two main parts, a spectrographer with a base-2 logarithmic frequency scale, and a spectrogram synthetiser.
Unlike most spectrographers which are based on STFTs and perform the analysis by cutting the signal into small time slices to analyse these slices in the frequency domain, the ARSE is based on a filter bank followed by envelope detection, which means that the signal is cut into small frequency-domain slices, and then analysed in the time domain.
The filter bank is, as of now, made up with overlapping bandpass FIR filters defined logarithmically. Once the original signal is filtered with the filter bank, each resulting signal is sent to envelope detection.
Envelope detection in the ARSE isnt based on a Hilbert transform and peak detection, as its usually done. To achieve envelope detection, we first perform a FFT on the signal, zero-pad the beginning of the signal in the frequency domain according to a user-defined setting, then we perform an IFFT, and, now in the time domain, we turn every negative sample into a positive one, and we low-pass filter (and eventually decimate) the signal according to the same user-defined setting as we previously used.
For instance, lets say we have a signal with a sampling frequency of 44,100 Hz, and that we want to obtain an envelope for it which sampling frequency would be 100 Hz. Once we perform the FFT, we add enough zeroes in the frequency domain at the beginning of our signal so that every frequency component shifts by 50 Hz (100 Hz divided by two, it will later appear obvious why), and we perform an IFFT. Our signal now has a sampling frequency of 44,200 Hz (44,100 + 100 Hz), and the original signal which previously spanned from 0 Hz to 22,050 Hz now spans from 50 Hz to 22,100 Hz.
Now we turn every time-domain sample into its absolute value by turning every negative sample into a positive one. To perform this on a signal means that, for example, a sine wave of a certain frequency would become a signal which periodicity would be twice that frequency. Once we low-pass filter that signal to twice that frequency we obtain that signals envelope. In our case, now that we have obtained the absolute values for our signal, since the periodicity of a sine at the lowest frequency - 50 Hz - would now be 100 Hz, we only low-pass filter our signal at 100 Hz to obtain the original signals envelope. We can now decimate the signal to a sample rate of 100 Hz.
The resulting envelope for each frequency band makes the horizontal lines of the image representing the spectrogram. The amplitude of the envelopes translate linearly into intensity in the image.
The spectrogram synthetiser is based on modulation using horizontal lines of the image as envelopes. Each horizontal line is upsampled to the sampling rate of the desired final signals sampling rate, and is then modulated with, depending on the synthetisation mode chosen by the user, sines matching to the central frequency each horizontal line represents, or noise filtered through the filter bank.
Enhancements:
- Replaced fixed phase sine generation with random phase sine generation
- Changed the PRNG
- Removed the unused code
- Removed every call of nearbyint() due to compatibility issues
- Included the necessary files in order to make using ./configure && make && make install