Uniutils consists of five programs for finding out what is in a Unicode file.
They are useful when working with Unicode files when one doesn't know the
writing system, doesn't have the necessary font, needs to inspect invisible
characters, needs to find out whether characters have been combined or in what
order they occur, or needs statistics on which characters occur.
uniname defaults to printing the character offset of each character, its byte
offset, its hex code value, its encoding, the glyph itself, and its name.
unidesc reports the character ranges to which different portions of the text
belong. It can also be used to identify Unicode encodings (e.g. UTF-16be)
flagged by magic numbers.
unihist generates a histogram of the characters in its input, which must be
encoded in UTF-8 Unicode.
ExplicateUTF8 is intended for debugging or for learning about Unicode. It
determines and explains the validity of a sequence of bytes as a UTF8 encoding.
Unirev is a filter that reverses UTF-8 strings character-by-character (as
opposed to byte-by-byte).
U-Boot loader for A13 Olinuxino.
To install this bootloader on an sdcard just do :
dd if=/usr/local/share/u-boot/u-boot-boardname/u-boot-sunxi-with-spl.bin of=/path/to/sdcarddevice bs=1k seek=8 conv=notrunc,sync
This version is patched so that:
* ELF and API features are enabled.
* The default environment is trimmed to just what's needed to boot.
* The saveenv command writes to the file u-boot.env on the FAT partition.
* The DTB file name is chosen based on the board model and passed to ubldr.bin
using the fdtfile env variable. ubldr.bin loads the DTB from /boot/dtb/ on
the FreeBSD partition.
* By default, it loads PIE ubldr.bin from file ubldr.bin on the FAT partition
to address 0x42000000, and launches it.
For information about running FreeBSD on Allwinner boards, see
https://wiki.freebsd.org/FreeBSD/arm/Allwinner
For general information about U-Boot see WWW: http://www.denx.de/wiki/U-Boot
U-Boot loader for Olinuxino Lime.
To install this bootloader on an sdcard just do :
dd if=/usr/local/share/u-boot/u-boot-boardname/u-boot-sunxi-with-spl.bin of=/path/to/sdcarddevice bs=1k seek=8 conv=notrunc,sync
This version is patched so that:
* ELF and API features are enabled.
* The default environment is trimmed to just what's needed to boot.
* The saveenv command writes to the file u-boot.env on the FAT partition.
* The DTB file name is chosen based on the board model and passed to ubldr.bin
using the fdtfile env variable. ubldr.bin loads the DTB from /boot/dtb/ on
the FreeBSD partition.
* By default, it loads PIE ubldr.bin from file ubldr.bin on the FAT partition
to address 0x42000000, and launches it.
For information about running FreeBSD on Allwinner boards, see
https://wiki.freebsd.org/FreeBSD/arm/Allwinner
For general information about U-Boot see WWW: http://www.denx.de/wiki/U-Boot
Data::FormValidator's main aim is to make the tedious coding of input
validation expressible in a simple format and to let the programmer focus
on more interesting tasks.
When you are coding a web application one of the most tedious though
crucial tasks is to validate user's input (usually submitted by way of
an HTML form). You have to check that each required fields is present
and that some fields have valid data. (Does the phone input looks like a
phone number? Is that a plausible email address? Is the YY state
valid? etc.) For a simple form, this is not really a problem but as
forms get more complex and you code more of them this task becames
really boring and tedious.
Data::FormValidator lets you define profiles which declare the
required fields and their format. When you are ready to validate the
user's input, you tell Data::FormValidator the profile to apply to the
user data and you get the valid fields, the name of the fields which
are missing. An array is returned listing which fields are valid,
missing, invalid and unknown in this profile.
Seamus Venasse <svenasse@polaris.ca>
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" :)
From the SquidClamav homepage:
SquidClamav is an antivirus for Squid proxy based on the Awards winnings
ClamAv anti-virus toolkit. Using it will help you securing your home or
enterprise network web traffic. SquidClamav is the most efficient Squid
Redirector and ICAP service antivirus tool for HTTP traffic available for
free, it is written in C and can handle thousand of connections. The way
to add more securing on your network for free is here.
SquidClamav is build for speed and security in mind, it is first used
and tested to secure a network with 2,500 and more users. It is also known
to working fast with 15000+ users.
With SquidClamav You have full control of what kind of HTTP stream must be
scanned by Clamav antivirus, this control operate at 3 different levels:
- At URL level, you can disable virus scanning for a set of web site,
filename extension or anything that can be matched in an URL.
- At client side by disabling virus scan and other redirector call
to a set of username, source Ip addresses or computer DNS name.
- At HTTP header level, where you can disable virus scanning following
the content type or file size.
x2x allows the keyboard and mouse on one ("from") X display to be used
to control another ("to") X display. Since x2x uses the XTEST
extension, the "to" X display must support XTEST.
In the default interface, x2x puts a window on the "from" display.
This window is labeled with the name of the "to" display. Keystrokes
typed into this window go to the window on the "to" display that has
the input focus. Clicking on the x2x window causes the mouse on the
"from" display to control the cursor on the "to" display. Perform-
ing a subsequent multiple button click on the "to" display returns
control to the "from" display.
If the -east or -west options are specified on the command line, x2x
starts up with a different interface. When the mouse moves to the
(east or west) side of the default screen on the "from" display, the
cursor slides over to the "to" display. When the mouse returns to to
side of the "to" display that it entered, it slides back onto the
"from" display.
Unless the -nosel option is specified, x2x relays X selections from
one display to the other.
JComboBox is a composite widget that contains a text Label or Entry, a
Button, and a popup Listbox. It performs the same sort of tasks that can be
accomplished by several other Composite widgets. Some such as BrowseEntry
and Optionmenu are part of the standard Tk distribution, and there are many
others available in CPAN.
JComboBox borrows features from the Java Swing component bearing the same
name, but falls short of being a true clone. Many of the methods and the
general look and feel should be familiar to java developers. JComboBox also
combines several features offered by many of the other "Combo Box"
implementations, and works in two modes: editable and readonly.
In readonly mode, JComboBox offers similar functionality to Optionmenu. It
is basically a labeled button that activates a popup list. An item from the
list is displayed on the Button when selected.
When editable, JComboBox somewhat resembles BrowseEntry. That is, the
widget is composed of an Entry widget with a Button to the right of it. As
in the editable mode, the Button activates a popup Listbox from which a
single item can be selected.
AfterStep is a continuation of the BowMan window manager which was
originally put together by Bo Yang. BowMan was based on the fvwm window
manager, written by Robert Nation. Fvwm was based on code from twm. And so
on... It is designed to emulate some of the look and feel of the NeXTstep
user interface, while adding useful, requested, and neat features. The
changes which comprise AfterStep's personality were originally part of
BowMan development, but due to a desire to move past simple emulation and
into a niche as its own valuable window manager, the current designers
decided to change the project name and move on. BowMan development may
continue, but we will no longer be a part of it.
Major changes from fvwm are:
- NeXTstep-like title bar, title buttons, borders and corners. BowMan's
Wharf is a much worked-out version of GoodStuff. To avoid copyright
complications it is not called a "dock."
- NeXTstep style menu. However, the menus are not controlled by
applications; they are more of pop-up service lists on the root window.
- NeXTstep style icons. These styles are hard-coded in the program, which is
good for the consistent look of the NeXTstep interface.
This module provides a simple way to extend the Math::Symbolic parser with
arbitrary functions that return any valid Math::Symbolic tree. The return
value of the function call is inserted into the complete parse tree at the
point at which the function call is parsed. Familiarity with the
Math::Symbolic module will be assumed throughout the documentation.
This module is not object oriented. It does not export anything. You
should not call any subroutines directly nor should you modify any class
data directly. The complete interface is the call to use
Math::SymbolicX::ParserExtensionFactory and its arguments. The reason for
the long module name is that you should not have to call it multiple times
in your code because it modifies the parser for good. It is intended to be
a pain to type. :-)
The aim of the module is to allow for hooks into the parser without
modifying the parser yourself because that requires rather in-depth
knowledge of the module code. By specifying key => value pairs of function
names and function implementations (code references) as arguments to the
use() call of the module, this module extends the parser that is stored in
the $Math::Symbolic::Parser variable with the specified functions and
whenever "yourfunction(any argument string not containing an unescaped \)
)" occurs in the code, the subroutine reference is called with the
argument string as argument.
The subroutine is expected to return any Math::Symbolic tree. That means,
as of version 0.133, a Math::Symbolic::Operator, a
Math::Symbolic::Variable, or a Math::Symbolic::Constant object. The
returned object will be incorporated into the Math::Symbolic tree that
results from the parse at the exact position at which the custom function
call was parsed.
Please note that the usage of this module will be quite slow at compile
time because it has to regenerate the complete Math::Symbolic parser the
first time you use this module in your code. The run time performance
penalty should be low, however.