Ports Search

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.