Free units of measurement software for linux

Units-filter is a basic standalone filter written in C, flex, and bison.
It inputs strings like "1.5e3 nN.m.s^-1" (which could be the time growth ratio of a torque) and outputs the value in standard SI units, followed by the physical dimension of this value.
units-filter can be embedded in educational test systems, in order to analyze a students answer to a problem of physics or chemistry.
Enhancements:
- The support for quantities with a particular number of significative digits was added.
- For example, the entry "1.02m#5" or "1.0200m" are equivalent and signify a distance measurement precise at the sub-millimeter scale.
- Both would yield the output "1.0200e+00 m".

Unit Circle project shows the relationship between trigonometric and angles functions like sine and cosine. To do this, the program implements an interactive "unit circle" (radius = 1) diagram, where the user can click or drag to set angles and see how the values of trigonometric functions change accordingly.

The unit circle (where the radius equals 1) provides a very clear demonstration of how various trigonometric functions relate to angles and one another. Draw an angle line from the origin to a point on the circumphrence of the circle; the (x,y) coordinates of that point will will be the cosine and sine of the angle.

In Unit Circle, use the mouse to set the angle line by either clicking or dragging the pointer inside the diagram. Or, change the trigonmetric values in the fields, and the angle will automatically adjust.

The inspiration for this program was provided by my home-schooled daughters, who had difficulty understanding the nature of trigonometry. As an educational tool, Unit Circle has been a success, and it may evolve into a larger application for exploring other aspects of trigonometry and geometry.

Test::Unit::TestCase is a unit testing framework base class.

SYNOPSIS

package FooBar;
use base qw(Test::Unit::TestCase);

sub new {
my $self = shift()->SUPER::new(@_);
# your state for fixture here
return $self;
}

sub set_up {
# provide fixture
}
sub tear_down {
# clean up after test
}
sub test_foo {
# test the foo feature
}
sub test_bar {
# test the bar feature
}

(Taken from the JUnit TestCase class documentation)

A test case defines the "fixture" (resources need for testing) to run multiple tests. To define a test case:

implement a subclass of TestCase
define instance variables that store the state of the fixture
initialize the fixture state by overriding set_up()
clean-up after a test by overriding tear_down().

Each test runs in its own fixture so there can be no side effects among test runs. Here is an example:

package MathTest;
use base qw(Test::Unit::TestCase);

sub new {
my $self = shift()->SUPER::new(@_);
$self->{value_1} = 0;
$self->{value_2} = 0;
return $self;
}

sub set_up {
my $self = shift;
$self->{value_1} = 2;
$self->{value_2} = 3;
}

For each test implement a method which interacts with the fixture. Verify the expected results with assertions specified by calling $self->assert() with a boolean value.

sub test_add {
my $self = shift;
my $result = $self->{value_1} + $self->{value_2};
$self->assert($result == 5);
}

Once the methods are defined you can run them. The normal way to do this uses reflection to implement run_test. It dynamically finds and invokes a method. For this the name of the test case has to correspond to the test method to be run. The tests to be run can be collected into a TestSuite. The framework provides different test runners, which can run a test suite and collect the results. A test runner either expects a method suite() as the entry point to get a test to run or it will extract the suite automatically.

If you do not like the rather verbose backtrace that appears when a test fails, you can use the quell_backtrace() method. You will get any message provided, but not the backtrace.

Test::Unit::Procedural Perl module contains a procedural style unit testing interface.

SYNOPSIS

use Test::Unit::Procedural;

# your code to be tested goes here

sub foo { return 23 };
sub bar { return 42 };

# define tests

sub test_foo { assert(foo() == 23, "Your message here"); }
sub test_bar { assert(bar() == 42, "I will be printed if this fails"); }

# set_up and tear_down are used to
# prepare and release resources need for testing

sub set_up { print "hello worldn"; }
sub tear_down { print "leaving world againn"; }

# run your test

create_suite();
run_suite();

Test::Unit::Procedural is the procedural style interface to a sophisticated unit testing framework for Perl that is derived from the JUnit testing framework for Java by Kent Beck and Erich Gamma. While this framework is originally intended to support unit testing in an object-oriented development paradigm (with support for inheritance of tests etc.), Test::Unit::Procedural is intended to provide a simpler interface to the framework that is more suitable for use in a scripting style environment. Therefore, Test::Unit::Procedural does not provide much support for an object-oriented approach to unit testing - if you want that, please have a look at Test::Unit::TestCase.

You test a given unit (a script, a module, whatever) by using Test::Unit::Procedural, which exports the following routines into your namespace:

assert()

used to assert that a boolean condition is true

create_suite()

used to create a test suite consisting of all methods with a name prefix of test

run_suite()

runs the test suite (text output)

add_suite()

used to add test suites to each other

For convenience, create_suite() will automatically build a test suite for a given package. This will build a test case for each subroutine in the package given that has a name starting with test and pack them all together into one TestSuite object for easy testing. If you dont give a package name to create_suite(), the current package is taken as default.

Test output is one status line (a "." for every successful test run, or an "F" for any failed test run, to indicate progress), one result line ("OK" or "!!!FAILURES!!!"), and possibly many lines reporting detailed error messages for any failed tests.
Please remember, Test::Unit::Procedural is intended to be a simple and convenient interface. If you need more functionality, take the object-oriented approach outlined in Test::Unit::TestCase.

p-unit is a framework for benchmarking performance. The project records memory consumption and execution time, and generates results in the form of plain text, image, and PDF file. Users can also easily register their own reporters by implementing PUnitEventList.
Test Suite and Test Class
Test suite and test class are two important concepts in p-unit. p-unit does not require any special type for a test class, so every class can be a test class. Of course, it includes junit test cases. There is one special interface for special p-unit only test class - p-unitTest. p-unit executes a normal test as following procedure:
invoke setUp if there is.
invoke the test method.
invoke tearDown method.
Noticed that setUp and tearDown will also be regarded as a part of performance test. If you dont want to count them into performance data, you need to implement p-unitTest interface, which will be executed as:
invoke setUpBeforeWatchers.
invoke setAfterWatchers.
invoke the test method.
invoke tearDownBeforeWatchers.
invoke tearDownAfterWatchers.
As the name suggests, you can put the setUp and tearDown code into the setUpBeforeWatchers and tearDownAfterWatchers.
Time/Memory Record
p-unit records the memory and time consumption of running a test method. There is a "watcher" concept in p-unit, which supervises the status during running the test method. By default, memory watcher and time watcher are installed. p-unit supports user-defined watcher too. The user only needs to implement the Watcher interface and register it to p-unit method runner.
Enhancements:
- Changes to adopt the Apache License 2.0.
- A customized watcher infrastructure to make it possible to report results from test cases.
- A new EventListener that sets public test fields on start up.

Java Units Generator and Converter (JUGC) is a Java tool and library for converting between measuring units.
It makes it possible to define units, their relationships and translations in files, to generate code from those definitions and deploy the generated code as a library in a Java project.
The generated code can then be used to convert values from one unit to another.
Enhancements:
- This initial version does the basic conversions using double precision floating point.

Hardware Monitor applet is a small program for the Gnome panel which tries to be a beautiful all-round solution to hardware monitoring.
It also tries to be user-friendly and generally nice and sensible, integrating pleasantly with the rest of your Gnome desktop.
Main features:
- A graphical view where each monitor is represented by a (time, measurement) colored curve
- A bar-plot view with a horizontal bar per monitor
- A column view with a column (time, measurement) diagram for each monitor
- A textual view which simply lists the monitors and the currently measured values
- A flame view which produces spiffy flames, the sizes of which are determined by the values of the monitored device
And the applet supports monitoring the following hardware characteristics:
- CPU usage (all CPUs, or one at the time) - niced background processes such as SETI@home are automatically ignored
- Memory usage - cache and buffers are automatically ignored
- Swap usage
- Load average
- Disk usage (or disk space free)
- Network throughput (Ethernet, wireless, modem, serial link), either incoming or outgoing or both
- Temperatures from internal sensors (e.g. system board and CPU temperatures)
- Fan speeds from internal sensors
- To avoid eating CPU time when it is scarce, the applet lowers its priority.