Free ian jukes software for linux

Lia is a library for performing Large Integer Arithmetic. It should not be used in a production environment. It will never be better than GNU MP.
It is, however, a nice clean library. The code is simple and easy to read and may be considered valuable to beginner to intermediate level C++ programmers. This is why it has been publicly released.
Lia is free software. In order to keep it that way, it is distributed under the terms of the GNU GPL. Yes, this means you are not permitted to link it against non-free software. But, as was mentioned earlier, why would you want to?
To install type in a nutshell: ./configure && make && make install
See the programs in the test directory for the "Programmers Guide".
See the installed header files in the PREFIX/include/lia directory for the
"Programmers Reference".
Keep in mind that Lia is distributed under the terms of the GNU GPL. That is,
it is free software and may only be linked against binaries compiled from other
free code.
Enhancements:
- Switched to a more libtool friendly versioning scheme.
- Added flexible string conversion routines to convert to and from character strings representing numbers in base 2 to base 256 encoded with programmer definable digits.
- Default string representation changed from hexadecimal to decimal.
- Removed the need for the InvalidParameterException thrown from most arithmetic functions.
- Added GCD function.
- Added ModularExponenet function.
- Renamed sqrttest to functest.

Angst is an active sniffer, based on libpcap and libnet. Angst provides methods for aggressive sniffing on switched local area network environments. It dumps the payload of all the TCP packets received on the specified ports. Moreover, it implements methods for active sniffing. Angst currently provides two active sniffing methods. The first monitors ARP requests, and after enabling IP forwarding on the local host, sends ARP replies mapping all IPs to the local MAC address. The second method floods the local network with random MAC addresses (like macof v1.1 by Ian Vitek), causing switches to send packets to all ports. This is made just for testing purposes and fun. If you compile it on any other platform except the ones listed below, please contact me. As always, angst is published under a BSD-style license, see the included LICENSE file.
Angst has been thoroughly tested on the following platforms:
OpenBSD 2.8 (i386)
OpenBSD 2.7 (i386)
OpenBSD 2.6 (i386)
Also, angst is known to compile and run on:
FreeBSD 4.2-STABLE (i386)
NetBSD 1.4.2 (i386)
Slackware Linux 7.1, with 2.2.13 kernel (i386)
You must first build and install libpcap and libnet. BSD systems have libpcap installed by default. If you test it on any other platform except the ones mentioned, send me the diffs. It should be portable since it is based on libpcap and libnet.
If you run {Free,Net,Open}BSD simply type: make
If you run Linux type: make -f Makefile.linux
In order to compile with debug support, edit the Makefile that corresponds to your platform and remove the comment from -DDEBUG.
In order to install angst type: make install
This will install the angst binary to /usr/local/sbin and the angst manual page to /usr/local/man/man8.
To uninstall angst type: make uninstall
Enhancements:
- Performed a lot of testing on all supported platforms.
- Added the -d switch, useful when you want to enable IP forwarding yourself, and not let angst to do it for you.
- Added the -e switch to specify other ports to monitor than the default ones.
- Linux support, only tested on Slackware Linux 7.1.
- Added a function for enabling IP forwarding on Linux, thanks to charon for
- the feedback.
- NetBSD support, only tested on 1.4.2.
- FreeBSD support, only tested on 4.2-STABLE, thanks to sivitos for the shell account.
- Added a warning output message when no active sniffing method is specified.
- Added an install and uninstall option to the Makefile.
- Created a man page.

JPokerTM is a JPoker Tournament Manager, a Poker Tournament application.
As I am a very keen Python user and also an avid Poker player, I decided to write an Open Source Cross-Platform application in Jython (a Java implementation of Python - see www.jython.org) to firstly make my life easier during our own home games (replacing written notes regarding blinds etc balanced against a pot plant).
There are many many improvements I want to make to this application, which is why it is currently designated as Alpha. However it is perfectly adequate as it stands to support my own home games, so I consider this a reasonable point to release it as v0.1. I would really like to have the chip value display working and that will probably go in v0.2.
This application is not really intended for use in huge tournaments like the WSOP where there will be more that 18 levels, it is more for home games and small card room tournaments. However if I get requests to support larger tournaments, I would certainly consider them.
Enhancements:
- BUGFIX* Added Ante Display.
- Added a chip value display to the tournament window.
- Added a preferences menu option which allows Currency (also FTR (fit to receive) display size in a future release) preferences to be selected.
- Preferences loaded from a file (if not present, default file created on startup).
- *BUGFIX* Pound sign display issue corrected by above.
- *BUGFIX* Ante format was not being provided if selected (TYPO).
- Blind structures now contained in external files, which are loaded into the application on startup.
- Files are simple csv (easily editable in an external application).

NTW Lisp project is a server written in Common Lisp for applications that use the NTW protocol to communicate with a GUI client.
NTW is a collection of three things:
- A protocol used to describe GUI widgets and events.
- A client program which displays widgets described by the protocol and sends back events to the server.
- A set of server libraries in various languages used to write GUI apps that use the NTW protocol to communicate to a client program.
In short, NTW is useful for the type of web applications that people are trying to write using a web browser with "AJAX" but finding that approach too limited/non-portable/broken/difficult.
Main features:
- Speed -- Remote apps can run at a speed which is nearly indistinguishable from a locally running application. Since the client draws the widgets natively, its not necessary to transfer graphical data, only widget state data. This can be done asynchronously, so the responsiveness of the UI never suffers.
- Persistence -- Its just as easy to write the NTW protocol data to disk as it is to the network, so the state of the entire GUI application can be easily saved. This also happens transparently, so the developer doesnt have to spend any time loading and saving data. Also, if a network connection dies or the client computer loses power, the application can be restarted from the point of failure at the next connection.
- Portability -- using the protocol, an NTW server application running on a Unix machine could talk to an NTW client for Windows, and vice versa. So a developer could write a program on Linux that could be run from any OS without any porting necessary. Any language or platform that can read and write data to a network can use the protocol to create GUI apps.
- Scalability -- Since the NTW server does not store or draw widget graphics, the memory and computational overhead of running an NTW application is much less than a comparable X Window application. A low end machine could easily serve hundreds of remote clients.
- Productivity -- Users can run NTW apps without installing anything but the client. Developers can release new versions of their apps without the users having to do anything, much like a web page.

h300goodies project consists of a handful of Perl and shell scripts that were written to help manage a users music collection on an iRiver H320 or H340 digital jukebox.

These scripts dont run on the player natively, but are used when the player is mounted on a local file system via a USB connector.

The scripts will build M3U playlists that you define, scan your collection and build playlists based on the genre in the MP3/Ogg file ID3 tags, scan your collection for long filenames that cause problems with iRivers database software, randomize an existing M3U playlist, and so on.

acoc is a regular-expression based colour formatter for programs that display output on the command-line. It works as a wrapper around the target program, executing it and capturing the stdout stream. Optionally, stderr can be redirected to stdout, so that it, too, can be manipulated. acoc then applies matching rules to patterns in the output and applies colours to those matches.

Ever wondered why the output of your favourite UNIX/Linux commands is still displayed in black-and-white after all these years?

Ever had to search back through your scroll-buffer in search of gcc errors and salient information to tell you what went wrong with your programs execution?

acoc is a regular expression based colour formatter for programs that display output on the command-line. It works as a wrapper around the target program, executing it and capturing the stdout stream. Optionally, stderr can be redirected to stdout, so that it, too, can be manipulated.

acoc then applies matching rules to patterns in the output and applies colour sets to those matches. A picture is worth a thousand words, so look at the sample screenshots in the next section.

Configuration

The configuration files used by the program are /usr/local/etc/acoc.conf, /etc/acoc.conf and ~/acoc.conf. One or more of these must exist. A sample /etc/acoc.conf is supplied with some example matching rules.

Blank lines and those that begin with a # are ignored.

A program configuration stanza is introduced as follows:

[program_spec]

The square brackets are mandatory literal characters. Alternatively, the @ symbol may be used, to allow [ and ] to retain their usual semantics in program specs comprising a regular expression:

@program_spec@

program_spec is defined as one or more instances of the following component, separated by a comma:

invocation[/flags]

where invocation consists of the programs name (not including its directory path component) plus any initial arguments.

Alternatively, invocation may be a regular expression, which can be used to match multiple programs and/or command-line arguments in arbitrary order. Regular expressions are automatically anchored to the beginning of the command line.

flags, if present, is separated from invocation by a slash and consists of one or more of the following characters:

a
continue to attempt to find matching patterns after the first match has been found. By default, acoc will stop processing a line and display it after the first match has been found.
e
redirect the target programs stderr to stdout, allowing it, too, to be matched by rules
p
allocate a pseudo-terminal in which to run the target program

Some programs, such as ls(1), behave differently when their stdout is not connected to a tty. Use of this option will fool the target program into believing it is outputting to a tty, rather than a pipe to acoc.

Use of this flag requires Masahiro Tomitas Ruby/TPty library to be installed. Otherwise, the flag is silently ignored.

Note that the pseudo-terminal communication enabled by this flag is one-way only, from the target program to acoc. It is thus not possible to use acoc in combination with interactive programs, such as the interactive Ruby interpreter (irb).
t
apply colour formatting even if stdout is not a tty. By default, formatting is not applied if the output stream is not attached to a terminal.

Heres an example of a line that introduces a configuration stanza:

[rpm/ae,rpmbuild/ae]

which says to apply the following rules to the rpm and rpmbuild commands, attempt to apply all matching rules, and also apply those rules to the programs stderr stream.

Another example:

[ls/p]

This says to allocate a pseudo-terminal to ls(1), fooling it into believing that its output is being sent to a regular terminal instead of a pipe to acoc.

With this flag, the effect will be this:

$ ls
file1 file2 file3 file4 file5 file6

Without it, ls will detect that its stdout is connected to a pipe and behave accordingly:

$ ls
file1
file2
file3
file4
file5
file6

A third example:

[diff/t,rcsdiff/t,cvs diff/t,p4 diff/t]

This says that the rules that follow should be applied to all invocations of diff(1) and rcsdiff(1), as well as those invocations of cvs(1) and p4 that are followed by the argument diff.

Additionally, colouring should be applied even when stdout is not connected to a tty, so that the colours still show up when the output is displayed in a pager such as more(1) or less(1).

Yet another example:

/ps -.*(e.*f|f.*e)/

In this example, the ps(1) command will be matched, as long as the e and f options are both passed in either order.

An alternative way to write the above spec is:

@ps -.*[ef].*[ef]@

There are two things to note in this alternative:

1. @ has been used to delimit the spec, because [ and ] are required for the character lists in the regular expression.
2. While this form is less specific (in that it allows matches against duplicated command line options), it makes for considerably shorter specs if one wishes to test for the inclusion of a set of more than 2 or 3 command line flags. In the original form, one must manually list all of the possible permutations, which is equal to x! (factorial). For 3 command line flags, this is 6 permutations; for 4, it is 24, etc.

Heres one more example:

[tcpdump/r]

If this were placed in ~/.acoc.conf, it would remove any matching rules that had been installed for the diff command by either /etc/acoc.conf or /usr/local/etc/acoc.conf.

After defining the program name and operational flags, matching rules can be defined. These take the following form:

/regex/[flags] colour_spec

where regex is a Ruby-compatible regular expression. The delimiting / characters can be any character, as long as that character is not present in the regular expression itself. flags, if present, consists of one or more characters from the following list:

g
find every match on the line, not just the first. When using this flag, regex should not include parentheses.

colour_spec is defined as a comma-separated list of one or more colour_groups, which are defined as a plus-separated (+) list of one or more of the following:

* black
* blink
* blue
* bold
* clear
* concealed
* cyan
* dark
* green
* italic
* magenta
* negative
* on_black
* on_blue
* on_cyan
* on_green
* on_magenta
* on_red
* on_white
* on_yellow
* rapid_blink
* red
* reset
* strikethrough
* underline
* underscore
* white
* yellow

Examples of a colour_group are white+bold, black+on_white, etc. A complete colour_spec might look like this:

red+bold,white,yellow+bold,black+on_green

Except when using the g flag, each component of the regex that you wish to colour should be placed in parentheses. Text outside parentheses will be used for matching, but will not be coloured.

For example, examine the following:

/^(d+)foos*(w+)/

This will match a line that starts with more or one digits, followed by the string foo and any amount of white space, followed by one or more word characters. However, only the initial group of digits and the group of word characters will be coloured. The string foo and the white space that follows it will be used for matching, but will not be coloured.

Separated from the regex by white space is the colour_spec. Usually, you will include in this as many colours (separated by commas) as you have parenthesised expressions in the regex. However, its also permissible to have fewer. If, for example, you have three parenthesised expressions in the regex, but only two colours listed in the colour_spec, then the second colour will be used for colouring both the second and third matches.

If you have more colours listed in the colour_spec than there are parenthesised expressions in the regex, the surplus colours are ignored.

When using the g flag to perform a global match on the line, you may list as many colours as you want. The same rules apply here. If there are more matches than colours, the remaining matches will be coloured using the last colour listed. Surplus colours are ignored.