Free who wants to be a millionaire software for linux

A practical lambda-calculator is a normal-order evaluator for the untyped lambda-calculus, extended with convenient commands and shortcuts to make programming in it more productive.

Shortcuts are distinguished constants that represent terms. Commands define new shortcuts, activate tracing of all reductions, compare terms modulo alpha-conversion, print all defined shortcuts and evaluation flags, etc.

Terms to evaluate and commands are entered at a read-eval-print-loop (REPL) "prompt" or "included" from a file by a special command. A Haskell branch is an embedding of the lambda calculator (as a domain-specific language) into Haskell. The calculator can be used interactively within Hugs or GHCi.

The present calculator implements what seems to be an efficient and elegant algorithm of normal order reductions. The algorithm is "more functional" than the traditionally used approach.

The algorithm seems identical to that employed by yacc sans one critical difference. The calculator also takes a more "functional" approach to the hygiene of beta-substitutions, which is achieved by coloring of identifiers where absolutely necessary. This approach is "more functional" because it avoids a global counter or the threading of the paint bucket through the whole the process. The integration of the calculator with Haskell lets us store terms in variables and easily and intuitively combine them.

The traditional recipe for normal-order reductions includes an unpleasant phrase "cook until done". The phrase makes it necessary to keep track of reduction attempts, and implies an ugly iterative algorithm. Were proposing what seems to be an efficient and elegant technique that can be implemented through intuitive re-writing rules.

Our calculator, like yacc, possesses a stack and works by doing a sequence of shift and reduce steps. The only significant difference from yacc is that the lambda-calculator "reparses" the result after the successful reduce step. The source and the target languages of our "parser" (lambda-calculator) are the same; therefore, the parser can indeed apply itself.

The parsing stack can be made implicit. In that case, the algorithm can be used for normalization of typed lambda-terms in Twelf.

The following examples show that lambda-calculus becomes a domain-specific language embedded into Haskell:

> c0 = f ^ x ^ x -- Church numeral 0
> succ = c ^ f ^ x ^ f # (c # f # x) -- Successor

> c1 = eval $ succ # c0 -- pre-evaluate other numerals
> c2 = eval $ succ # c1
> c3 = eval $ succ # c2
> c4 = eval $ succ # c3

It is indeed convenient to store terms in Haskell variables and pre-evaluate (i.e., normalize) them. They are indeed terms. We can always ask the interpreter to show the term. For example, show c4 yields (f. (x. f (f (f (f x))))).

let mul = a ^ b ^ f ^ a # (b # f) -- multiplication
eval $ mul # c1 ---> (b. b), the identity function
eval $ mul # c0 ---> (b. (f. (x. x))), which is "const 0"

These are algebraic results: multiplying any number by zero always gives zero. We can see now how lambda-calculus can be useful for theorem proving, even over universally-quantified formulas.

The calculator implements Dr. Fairbairns suggestion to limit the depth of printed terms. This makes it possible to evaluate and print some divergent terms (so-called tail-divergent terms):

Lambda_calc> let y_comb = f^((p^p#p) # (c ^ f#(c#c))) in eval $ y_comb#c
c (c (c (c (c (c (c (c (c (c (...))))))))))

It is amazing how well lambda-calculus and Haskell play together.

Html to Xhtml Convertor is a straight-forward Perl script to convert HTML pages into XHTML pages.
It can process batches of files, convert Windows/Unix/Mac line breaks, and deal with attribute minimization, quoting of attribute values, and more.
Installation:
To install, simply run the following command as root: make install
Alternatively, simply move the htx file to wherever you would like. The command above installs it to /usr/local/bin/
Usage:
Use the following command to get usage information after installing:
htx --help
or if the htx file is in the current directory, try:
./htx --help
Example use:
htx --dos --verbose index.html index2.html
That will take a file with DOS line breaks, index.html, convert it
to XHTML as best it can and save the result as index2.html
Version restrictions:
- oes not check for closing < /p >, < /li > or other block-level tags.
- Assumes there are no < or > which are not part of tags, use < and >
- Does not distingish between block and inline tags.
Enhancements:
- Added the --tty option to dump output to STDOUT rather than a file
- Added detection of old ICRA data
- Improved handling of single quoted attribute values
- Removed updating of Pico version
- Fixed a typo with the years in the Changelog file
- Did a couple of very minor internal changes

Not A Commander is yet another file manager modeled after the Norton Commander. Good integration with the command line is the primary goal.
This project is using the technology of Natural Stupidity for development: first get something working at all, then gradually improve it. My primary targets are the features that I personally would use. The features that I wont use anyway are not planned to be implemented at all (though if someone would contribute an implementation I would gladly accept it - as long as it does not break any of the things that I use).
Build
Run `make. That should build all the binary parts. The X11 headers are required for build. You may need to modify the Makefile for peculiarities of your particular system (directory names, libraries etc.).
Installation
Run `make install. By default the `nac binary is instaled into /usr/local/bin and the rest of files is installed into /usr/local/lib/nac (which is referred further as "the NAC directory").
These directory names can be changed in the Makefile. If the configuration file nac.sysrc was present in the NAC directory before installation, it will be moved into nac.sysrc.old.
Configuration
The default configuration of NAC can be changed with rc files. There are two rc files:
per system - nac.sysrc in the NAC directory per user - .nacrc in the users home directory
These files are common Tcl scripts that can be used to change the tunable values. NAC first sets the built-in values, then loads the system-wide rc file (if present), then loads the users rc file (if present). Thus the system-wide script can examine the built-in values and modify them was neccessary, and the users script can do the same thing with the result
of the system-wide script.
Be careful with the syntax, in case of an error in the rc scripts NAC wont start.
The list of the supported tunables and their values can be found at the top of tune.tcl. For now (the alpha phase of development) its expected to be quite liquid and change between snapshot releases. Probably some sort of versioning will be added after it stabilizes.
The sample system rc file included in a release contains only one setting - the name of font to use (most probably you dont have the font "koi9x16" which is the built-in default).
The default initial size of the window is defined by panel dimensions, variables named set panel:filespercolumn (number of rows in panels), panel:ncolumns (number of columns in panels), panel:columnwidth (width of a column in dots). The internal xterm is automatically resized to fit these dimensions. Alternative size in pixels or xterm characters can be
selected with command line options.
Enhancements:
- Various bugs were fixed and workarounds were included for bugs in glibc and Tk.

Scriptol to binary Compiler is a C++ native compiler.

Installation:

It is better to install Scriptol at root of a disk, for example:
c:scriptolc

Once the archive is extracted into the scriptolc directory, you have just to change to this directory to run the compiler.

To use the compiler at command line from any directory, you have to put the compiler into the path variable.

The setup script installs required file into sub-directories, or into the directory given as argument. Before to use the compiler, you have to read the licence, in the doc
directory: licence.html.

Usage:

Just type:
./solc mysource

Type "solc" only to list the options.

If your program is a multi-file project, the source given as parameter must be the main source file, the compiler will know dependencies from "include" statements and will build what is needed.

Exemples:

Type from the main scriptol directory:
./solc -bre demosfibo

Configuring:

By editing the solc.ini file, you may change the second pass compiler (you may have to rebuild the libsol library for this compiler), change the options of the compiler or add header files to include.

To add header files, just add "header=someheader.hpp" lines into the config file.

A xxx.cfg file may be written for each project main source beeing xxx, and if present, it overloads the solc.ini file.

Transfer to Media Device is a script that creates a new Playlist Right Click Menu item for transferring selected playlist items to your iPod via the Media Device Browser.
This script now also supports generic copy to operation for USB mass storage devices. Currently the script will prompt for a destination directory on first copy, in the future this setting will be saved in a configuration file.
This script works with amaroK 1.3beta3 and above.
Usage:
Run from the amaroK script manager. A new menu item will appear in the Playlist right mouse button menu.
Select files in the playlist and Right click -> Transfer to -> iPod for transfering to an iPod.
Select files in the playlist and Right click -> Transfer to -> USB Device for transfering to a USB device.
Enhancements:
- Add support for Creative Nomad Jukebox devices using the kionjb kioslave. Thanks to Ralf T for the patch.

This script is adding a new action item to Konqueror, this will allow you to add Podcasts to amaroK with just 3 clicks.

The item is adding the selected URL to amaroKs Podcast database.

Note that the script is not very dynamic. It will not be able to recognize PHP based Podcasts if its not having the correct mimetype (RDF/RSS/XML).

A Jacks Game is a real-time game that runs in a Web browser using the AJAX (Asynchronous JavaScript and XML) technology.

Multiple users can login in A Jacks Game to explore a common map and earn a common currency as their score.

A Jacks Game is free software released under GNU/GPL Open Source License.

A Sudoku Solver in C is a console-based Linux program, written in C language, that solves Su Doku puzzles using deductive logic. It will only resort to trial-and-error and backtracking approaches upon exhausting its deductive moves.
Puzzles must be of the standard 9x9 variety using the (ASCII) characters 1 through 9 for the puzzle symbols. Puzzles should be submitted as 81 character strings which, when read left-to-right will fill a 9x9 Sudoku grid from left-to-right and top-to-bottom. In the puzzle specification, the characters 1 - 9 represent the puzzle givens or clues. Any other non-blank character represents an unsolved cell.
The puzzle solving algorithm is home grown. I did not borrow any of the usual techniques from the literature, e.g. Donald Knuths "Dancing Links." Instead I rolled my own from scratch as a personal challenge. As such, its performance can only be blamed on yours truly. Still, I feel it is quite fast. On a 333 MHz Pentium II Linux box it solves typical medium force puzzles in approximately 800 microseconds or about 1,200 puzzles per second, give or take. On an Athlon XP 3000 it solves about 6,600 puzzles per sec. (Solving time is dependent upon degree of difficulty, so YMMV.)
Description of Algorithm:
The puzzle algorithm initially assumes every unsolved cell can assume every possible value. It then uses the placement of the givens to refine the choices available to each cell. I call this the markup phase.
After markup completes, the algorithm then looks for singleton cells with values that, due to constraints imposed by the row, column, or 3x3 region, may only assume one possible value. Once these cells are assigned values, the algorithm returns to the markup phase to apply these changes to the remaining candidate solutions. The markup/singleton phases alternate until either no more changes occur, or the puzzle is solved. I call the markup/singleton elimination loop the Simple Solver because in a large percentage of cases it solves the puzzle.
If the simple solver portion of the algorithm doesnt produce a solution, then more advanced deductive rules are applied.
Ive implemented two additional rules as part of the deductive puzzle solver. The first is subset elimination wherein a row/column/region is scanned for X number of cells with X number of matching candidate solutions. If such subsets (or tuples) are found in the row, column, or region, then the candidates values from the subset may be eliminated from all other unsolved cells within the row, column, or region, respectively.
The next deductive rule examines each region looking for candidate values that exclusively align themselves along a single row or column, i.e. a vector. If such candidate values are found, then they may be eliminated from the cells outside of the region that are part of the aligned row or column.
Note that each of the advanced deductive rules calls all preceeding rules, in order, if that advanced rule has effected a change in puzzle markup.
Finally, if no solution is found after iteratively applying all deductive rules, then we begin trial-and-error using recursion for backtracking. A working copy is created from our puzzle, and using this copy the first cell with the smallest number of candidate solutions is chosen. One of the solutions values is assigned to that cell, and the solver algorithm is called using this working copy as its starting point. Eventually, either a solution, or an impasse is reached.
If we reach an impasse, the recursion unwinds and the next trial solution is attempted. If a solution is found (at any point) the values for the solution are added to a list. Again, so long as we are examining all possibilities, the recursion unwinds so that the next trial may be attempted. It is in this manner that we enumerate puzzles with multiple solutions.
Note that it is certainly possible to add to the list of applied deductive rules. The techniques known as "X-Wing" and "Swordfish" come to mind. On the other hand, adding these additional rules will, in all likelihood, slow the solver down by adding to the computational burden while producing very few results. Ive seen the law of diminishing returns even in some of the existing rules, e.g. in subset elimination I only look at two and three valued subsets because taking it any further than that degraded performance.
Enhancements:
- Code optimization has resulted in a 30% increase in speed.