Free js software for linux

js-search is a javascript indexing and searching.

A client-side library for building a simple inverted index, and searching it.

You can download the source code from SVN with the following command:

svn checkout http://js-search.googlecode.com/svn/trunk/ js-search

jsSnow project is a port of XSnow for Web pages.
The framerate is auto-adjusted, and it works for Mozilla, Netscape (>=4), and IE (>=4).
Enhancements:
- code clearings
- santa moves with storm
- renamed jsSnow_ .js to jsSnow.js

OSSP js is a stand-alone distribution of the JavaScript (JS) programming language reference implementation from Mozilla -- aka "JSRef" or "SpiderMonkey".
OSSP js provides a smart, stand-alone and portable distribution of Mozilla JavaScript through a build environment based on GNU autoconf, GNU libtool and GNU shtool, including support for easy JavaScript build-time feature set selection (ECMA-3, JS-1.5, JS-1.6), optional CLI line editing support, optional "stdio" based File object support and JS/Perl bindings.
Additionally, the C API in "libjs" contains both the JavaScript engine and the required Sun math library ("fdlibm") and with all internal symbols carefully protected under the "js" namespace. Finally, a js-config(1) utility and a pkg-config(1) specification is provided to allow applications to easily build with the JavaScript C API.
OSSP js was created because for OSSP and similar pedantic C coding projects a smart, stand-alone, portable, clean, powerful and robust scripting language engine is required. JavaScript is a great programming language and Mozilla JavaScript "SpiderMonkey" definitely is an acceptable clean, powerful and robust implementation.
Unfortunately there is just a stand-alone distribution released from time to time by Mozilla and it is far away from really being smart, stand-alone and portable. At least for OSSP it was not acceptable having to tell the community that for small and stand-alone C components like the OSSP components they either have to install the great but large Mozilla Firefox application (where Mozilla JavaScript is included) or have to fiddle around theirself with an older stand-alone JavaScript distribution and its weak build environment.
OSSP js combines the best from two worlds: the 1:1 repackaged JavaScript code base from Mozilla and the usual amount of GNU autoconf, GNU libtool and GNU shtool wrappers as always used by OSSP. Additionally, stand-alone ("stdio" instead of NSPR based) File object support was required.
Enhancements:
- The build environment was upgraded to GNU autoconf 2.61 and a jspack(1) command that is a CLI adaption of Dean Edwards JavaScript "packer" was added.

Scheme2Js is a Scheme to Javascript compiler. While some effort has been spent on being as close as possible to R5rs, we concentrated mainly on efficiency.
Usually Scheme2Js produces Javascript code, that is comparable to hand-written code. In order to achieve this performance, Scheme2Js is not completely R5rs compliant. In particular it lacks support for continuations, exact numbers and it treats tail recursion only partially.
Scheme2Js provides several flags, that allow to modify the result:
- --no-js-dot-notation disallows access to JavaScript fields with the dot-notation. This flag disables accesses of the form x.y like in document.getElementById. It is however still possible to access the is a valid expression using the js-field function.
- --mutable-strings: in order to improve the performance of string-operations and to ease the interface between Scheme and JavaScript code, the default implementation maps Scheme strings to JavaScript strings. Contrary to Scheme strings, JavaScript strings are however immutable. This flag maps strings to a JavaScript class, that represents Scheme strings, that are mutable. The resulting code might be slightly slower, and it is more difficult to interface with Javascript code.
- --encapsulate-parts encapsulates the program into an anonymous function. Only global variables are outside of this anonymous function. On one hand this introduces one function call to the anonymous function. But on the other hand most Javascript implementations should run faster with this optimization: usually hashtables are used to represent scopes in JavaScript. By using an anonymous function the programs variables are separated into their own smaller hashtable which (in theory) accelerates accesses to these variables. More importantly the variables are stored in their own hashtable, and not in the global hashtable, which is accessible by the global variable. It is extremely easy to indirectly modify the contents of global variables. Inlining or other common optimizations are hence impossible to do on global variables. By storing the programs variables in an anonymous function these optimizations become again possible.
- --optimize-var-number reduces the number of variables used in the resulting JavaScript code. The code may run faster, but is more difficult to debug, as the variable names are lost and the same variable might be used several times.
- --optimize-while: with this flag Scheme2Js optimizes common while loops. The unoptimized while loops are often of the form:
while(true) {
if(test)
resVar = res;
else {
modify_loop_variable;
continue;
}
break;
}
This optimization looks for these patterns and moves the test into the while loop:
while(!test) {
modify_loop_variable;
}
resVar = res;
This optimization has been implemented only recently and is therefore not yet activated by default.
- --verbose prints some information.
- --no-inlining disables all function inlining (constants might still be inlined).
- --inline-globals lets Scheme2Js inline global functions and constants. This might have two unwanted side-effects: for one, global variables are often used to transfer data between different modules. Some inlined functions are lost if there is no reference to them anymore. If global functions are to be used outside a module, one should not use this flag. (This behavior is likely to change in future versions of Scheme2Js.)
- --unresolved-is-js: if a variable is unbound, the compiler will assume the variable comes from another module, or from JavaScript. See Section Scheme - Javascript for a more detailed discussion of the JavaScript Scheme interface.
- --js-this provides the this variable within Scheme functions. This way, Scheme procedures can be used as methods of JavaScript objects.
- --no-tailrec disables the tailrec to while-loop optimization. If you suspect a bug in the compilers way of translating tail-recs, you could try this flag.
- --no-optimize-calls disables Scheme2Js inlining of binary or unary operations. For instance sci_plus(3, 5) is optimized to (3+5). This optimization is quite important, and theres usually no reason to disable it.
- --no-optimize-consts disables the pre-constant calculation. Unless disabled (with this flag), compound constants are precalculated and their occurrences replaced by a reference to a variable holding the constant. This makes repeated accesses to these constants faster, but introduces new variables.
- --no-optimize-boolify disables the boolify optimization. JavaScripts and Schemes boolify are not equivalent: JavaScript considers false, 0, null and undefined to be false, whereas Scheme only has #f. The unoptimized boolify therefore always adds the test against false: if (test !== false) ... If Scheme2Js can see, that the test itself is a boolean, it can remove the unnecessary !== false test. This flag disables this optimization.
- --d STAGE prints a dot-file (see graphviz) of the AST after stage STAGE. Possible stages are: expand, tree, symbol, node-elim1, tail, inline, constant-propagation, rm-unused-vars, capture, node-elim2, while, (tt "statements"), node-elim3. Usually one doesnt need this flag, unless for debugging purposes.
- --print-locs prints the original locations as comments to the JavaScript file. These locations are currently the character-offset from the beginning of the file.
Enhancements:
- This release adds trampolines.

JavaScript::App is a Perl framework for building dynamic widgets or full applications in Javascript.

SYNOPSIS

see the documentation for "js-app" ("man js-app" or "perldoc js-app")

"js-app" is a Javascript Application framework with which you can build rich web applications and widgets embeddable in web pages.

Linux::Joystick is an object-oriented, pure Perl API for accessing joystick devices under Linux-based operating systems. Linux::Joystick module is capable of using either blocking or non-blocking I/O, and represents each axis change or button press as a Linux::Joystick::Event object.

USAGE

If you want your application to be driven by joystick events, use blocking I/O and an event loop:

use Linux::Joystick;

my $js = new Linux::Joystick;
my $event;

print "Joystick has " . $js->buttonCount() . " buttons ".
"and " . $js->axisCount() . " axes.n";

# blocking reads:
while( $event = $js->nextEvent ) {

print "Event type: " . $event->type . ", ";
if($event->isButton) {
print "Button " . $event->button;
if($event->buttonDown) {
print " pressed";
} else {
print " released";
}
} elsif($event->isAxis) {
print "Axis " . $event->axis . ", value " . $event->axisValue . ", ";
print "UP" if $event->stickUp;
print "DOWN" if $event->stickDown;
print "LEFT" if $event->stickLeft;
print "RIGHT" if $event->stickRight;
} else { # should never happen
print "Unknown event " . $event->hexDump;
}

print "n";
}

# if the while loop terminates, we got a false (undefined) event:
die "Error reading joystick: " . $js->errorString;

You can also use non-blocking I/O, in which case nextEvent() returning undef just means there was no event to read:

my $js = Linux::Joystick->new(nonblocking => 1);
# use this to open 2nd joystick in nonblocking mode instead:
# my $js = Linux::Joystick->new(device => 1, nonblocking => 1);

while(1) {
my $event = $js->nextEvent;

if($event) {
print "Got a joystick eventn";
# process the event here
}

# Do other processing here (graphics, sound, I/O, calculation)

}

It is possible to switch between blocking and non-blocking I/O without reopening the device (see the setNonblocking() method, below).

nessquik is a fast Web-based Nessus scanner that is intended to replace the Nessus stand alone client.
nessquik project uses the prototype.js library to provide a responsive interface even when dealing with all of the available Nessus plugins.
Enhancements:
- A complete redesign of the interface has been done.
- Much more flexibility has been added to the interface as well.
- Scans can be stopped while they are running.
- All scan settings can be configured at creation time.
- An XML-RPC API has been added for third party developers.
- Numerous code fixes and performance enhancements have been made to every part of the system.