The Gambit programming system is a full implementation of the Scheme
language which conforms to the R4RS and IEEE Scheme standards. It
consists of two main programs: gsi-gambit, the Gambit Scheme
interpreter, and gsc-gambit, the Gambit Scheme compiler.
Gambit-C is a version of the Gambit programming system in which the
compiler generates portable C code, making the whole Gambit-C system
and the programs compiled with it easily portable to many computer
architectures for which a C compiler is available. With appropriate
declarations in the source code the executable programs generated by
the compiler run roughly as fast as equivalent C programs.
This is a modified version of Aflex/Ayacc for Ada95 parent/child feature
support. A new directive "%unit A.B.C" has been added, enabling the Ada
unit A.B.C to be the parent of the generated lexer/parser.
Aflex/Ayacc are copyrighted by the The University of California.
The cryptographic hash function BLAKE2 is an improved version of the SHA-3
finalist BLAKE. Like SHA-3, BLAKE2 offers the highest security, yet is fast as
MD5 on 64-bit platforms and requires at least 33% less RAM than SHA-2 or SHA-3
on low-end systems. The core algorithm of BLAKE2 is derived from ChaCha, a
stream cipher designed by Daniel J. Bernstein that has been proposed as a
standard cipher for TLS.
ANTLR, ANother Tool for Language Recognition, is a language tool that
provides a framework for constructing recognizers, interpreters,
compilers, and translators from grammatical descriptions containing
actions in a variety of target languages. ANTLR provides excellent
support for tree construction, tree walking, translation, error
recovery, and error reporting.
This package provides the ANTLR v3 C runtime library.
Tools for the conversion to and from UTF-8 Unicode encoding. Note that
RFC-2277 mandates that all "protocols" MUST handle UTF-8 properly.
- utrans converts text files created using any 8-bit character
map into UTF-8;
- uhtrans converts UTF-8 files into 7-bit ASCII with anything
else formatted as an HTML-style tags, e.g. Ӓ (decimal);
- hutrans converts 7-bit ASCII files with HTML-style tags, to UTF-8,
thus complementing the functionality of hutrans;
- ptrans converts UTF-8 files into 8-bit text using any
8-bit character map, thus complementing utrans.
Additionally, tuc is installed if not found. Tuc converts text files
between the DOS/Windows and the Unix formats.
This port depends on ports/converters/libutf-8.
Further details: RFC 2277, and RFC 2279.
This module converts strings from and to 2-byte Unicode UCS2 format.
All mappings happen via 2 byte UTF16 encodings, not via 1 byte UTF8
encoding. To convert between UTF8 and UTF16 use Unicode::String.
For historical reasons this module coexists with Unicode::Map8.
Please use Unicode::Map8 unless you need to care for >1 byte character
sets, e.g. chinese GB2312. Anyway, if you stick to the basic
functionality (see documentation) you can use both modules equivalently.
Practically this module will disappear from earth sooner or later as
Unicode mapping support needs somehow to get into perl's core. If you
like to work on this field please don't hesitate contacting Gisle Aas
and check out the mailing list perl-unicode!
This font is called Isabella because it is based on the calligraphic
hand used in the Isabella Breviary, made around 1497, in Holland,
for Isabella of Castille, the first queen of united Spain.
Apache Pig is a platform for analyzing large data sets that consists of a
high-level language for expressing data analysis programs, coupled with
infrastructure for evaluating these programs. The salient property of Pig
programs is that their structure is amenable to substantial parallelization,
which in turns enables them to handle very large data sets.
At the present time, Pig's infrastructure layer consists of a compiler that
produces sequences of Map-Reduce programs, for which large-scale parallel
implementations already exist (e.g., the Hadoop subproject). Pig's language
layer currently consists of a textual language called Pig Latin, which has
the following key properties:
-- Ease of programming. It is trivial to achieve parallel execution of simple,
"embarrassingly parallel" data analysis tasks. Complex tasks comprised of
multiple interrelated data transformations are explicitly encoded as data flow
sequences, making them easy to write, understand, and maintain.
-- Optimization opportunities. The way in which tasks are encoded permits the
system to optimize their execution automatically, allowing the user to focus
on semantics rather than efficiency.
-- Extensibility. Users can create their own functions to do special-purpose
processing.
Instead of a dry technical overview, I am going to explain the structure of this
module based on its history. I consult at a company that generates customer
leads primarily by having websites that attract people (e.g. lowering loan
values, selling cars, buying real estate, etc.). For some reason we get more
than our fair share of profane leads. For this reason I was told to write a
profanity checker.
For the data that I was dealing with, the profanity was most often in the email
address or in the first or last name, so I naively started filtering profanity
with a set of regexps for that sort of data. Note that both names and email
addresses are unlike what you are reading now: they are not whitespace-separated
text, but are instead labels.
Therefore full support for profanity checking should work in 2 entirely
different contexts: labels (email, names) and text (what you are reading).
Because open-source is driven by demand and I have no need for detecting
profanity in text, only label is implemented at the moment. And you know the
next sentence: "patches welcome" :)
The goal of the lensfun library is to provide an open source database of
photographic lenses and their characteristics. In the past there was an
effort in this direction (see http://www.epaperpress.com/ptlens/), but then
author decided to take the commercial route and the database froze at the
last public stage. This database was used as the basement on which lensfun
database grew, thanks to PTLens author which gave his permission for this,
while the code was totally rewritten from scratch (and the database was
converted to a totally new, XML-based format).
The lensfun library not only provides a way to read the lens database and
search for specific things in it, but also offers a set of algorithms for
correcting images based on detailed knowledge of lens properties and
calibration data. Right now lensfun is designed to correct distortion,
transversal (also known as lateral) chromatic aberrations, vignetting, and
colour contribution of the lens (e.g. when sometimes people says one lens
gives "yellowish" images and another, say, "bluish").