Free slice software for linux

SVGSlice application can generate chopped up images from Inkscape SVG drawings.

To figure out where to cut, SVGSlice can use Inkscapes built in guides (for simpler, grid-like cuts), or it can use a specially named "slices" layer that contains rectangles that mark areas to slice.

Demo files showing both approaches are included.

Sub::Slice::Manual is a Perl module with user guide for Sub::Slice.

USING Sub::Slice

Sub::Slice is a way of breaking down a long-running process and maintaining state across a stateless protocol. This allows the client to draw a progress bar or abort the process part-way through.

The mechanism used by Sub::Slice is similar to the session management used on many web user authentication systems. However rather than simply passing an ID back as a token as these systems do, in Sub::Slice a data structure with richer information is passed to the client, allowing the client to make some intelligent decisions rather than blindly maintain state.

Use of Sub::Slice is best explained with a minimal example. Assume that there is a remoting protocol between the client and server such as XML/HTTP. For the sake of brevity, assume that methods called in package Server:: on the client are magically remoted to the server.

The server does two things. The first is to issue a token for the client to use:

#Server
sub create_token {
my $job = new Sub::Slice();
return $job->token;
}
The second is to provide the routine into which the token is passed for each iteration:
sub do_work {
my $token = shift;
my $job = new Sub::Slice(token => $token);

at_start $job sub {
my $files = files_to_process();

#Store some data defining the work to do
$job->store("files", $files);
};

at_stage $job "each_iteration" sub {

#Get some work
my $files = $job->fetch("files");
my $file = shift @$files;

my $was_ok = process_file($file);

#Record we did the work
$job->store("files", $files);

#Check if theres any more work left to do
$job->done() unless(@$files);

};
}

The client somehow gets a token back from the server. It then passes this back to the server for each iteration. It can inspect the token to check if there is any more work left.

#Client
my $token = Server::create_token();
for(1 .. MAX_ITERATIONS) {
Server::do_work($token);
last if $token->{done};
}

Dice3DS project is a set of Python modules for dealing with 3D Studio format files. I have released it under the terms of a BSD-style license.
3D Studio is a 3D graphics modeling and rendering program that saved it images in a rather simple binary file format known as 3DS format. Although 3D Studio has not released the details of the 3DS format, it has been reverse engineered by some ambitious people, and I used the information to write Dice3DS, a Python package that slices and dices 3DS files.
Dice3DS requires Python 2.2 or higher, as it uses metaclass programming, and Python Numeric. Note that it is not a wrapper for lib3ds; its a Pure Python module.
There are two packages in Dice3DS: Dice3DS, and Dice3DS.example. The latter includes some modules that exemplify the use of Dice3DS, although they are not very versatile.
Heres a brief description of each module:
Dice3DS.dom3ds
Slice and dice 3DS files.
Provides for reading, writing, and manipulating 3DS files. Its
called dom3ds because its reminiscent of XML-DOM: it converts the 3DS
file into a hierarchy of objects, in much the same way XML-DOM
converts an XML file into a hierarchy of objects called the Document
Object Model. The dom3ds module creates an object for each chunk in
the 3DS file, which can be accessed hierarchially as attributes.
For example, once a 3DS file is loaded, you could the smoothing data
of the second object like this:
dom.mdata.objects[2].ntri.faces.smoothing.array
Dice3DS.util
Utitily function for Dice3DS.
Defines some routines for calculating normals and transforming points.
Dice3DS.example.basicmodel
Basic abstract classes representing a 3DS model.
Defines some classes that represent objects and materials of a 3DS
file in a more convienient form. It has methods to convert from the
DOM format. The classes can serve as base classes for more advanced
uses.
Dice3DS.example.glmodel
Classes for rendering 3DS models in OpenGL.
Defines some classes (based on Dice3DS.example.basicmodel) with some
additional methods to draw the model in OpenGL, or create a display
list to do so. Requires PyOpenGL.
Dice3DS.example.gltexture
OpenGL texture object abstraction.
Provides a class that is an abstraction of OpenGL texture objects. It
can create textures from image files, and automatically generates
mipmaps if requested. Requires PyOpenGL and Python Imaging Library.
Dice3DS.example.modelloader
Example of loading 3DS models.
Provides functions to load a 3DS model and creating a GLModel (or
BasicModel) from it. Shows how to load models from the filesystem, or
directly from a zip file.
Enhancements:
- The code was changed to use the constants defined in the "numpy" namespace instead of the "Numeric" namespace, since numpy no longer seems to provide the Numeric constants.
- The advantage is that it works for numpy 1.0.
- The disadvantage is that you can no longer backport it to Numeric by changing the import statements.
- Most inexplicably, the behavior of numpy.sum changed and broke the calculation of normals.
- Thus, the builtin sum is used in util.py instead of numpy.sum.

Quasi project is a Python shell which supports pluggable "contexts" for non-Python commands, such as OS commands, MySQLdb queries and external programs.

The smart-eyed reader will have noticed the use of the built-in quoted() method in the examples above. There are a number of these that are available in the interpreter namespace (the source is, as youd expect, in quasi.py):

* quoted() returns any string surrounded by either single or double quotes (single-quotes as default). If passed a list, it returns a list of the strings, each quoted(), joined with whitespace. Currently it uses Pythons repr() as a quick-and-dirty way to do this.
* dquoted does the same, but uses double-quotes and will escape any double-quotes already in a string.
* commas() joins the elements of a list with commas; this is mostly for Windows work.
* modules() returns a list of the currently imported modules in the interpreter namespace; just to make ones working life a little easier.
* Bag() is a useful class.

Bags can behave like dicts (in that they have a keys() method, and you can access values using the x[y] syntax) or like objects (in that you can access values using the x.y syntax). You must always assign values using the former (x[y]), but after that you can reference values either way.

A Bag will also remember the order in which values were assigned; this is used in the SQL context, for example, so that a Bags keys or values are always returned in the order that a SELECT obtained them.

There are also a number of built-in shell commands. Unlike nearly everything else that gets typed into Quasi, these execute in the namespace of the shell, not the interpreter. More on that another time, but it means that any variables your Python code may have defined are not accessible to built-in shell commands. This is why none of them need any real arguments:

* exit: exit Quasi.
* help: show lots of help on various sorts of command.
* credits: show the names of the people who have contributed to Quasi.
* license: show the Quasi (BSD-style) license.
* history: show the command history. Supports slice notation (1:20), plus history searching. For example, history sq will find all command lines that begin with "sq".
* recall: recall a previous command or set of them.

This is very useful when youve been writing indented code and want to recall a set of previous lines. Same syntax as history - specify a single line or a slice-like set of them.

Recall has a limitation; it requires a functional readline module available, to insert the recalled command into the input buffer for editing. If that cant be done, the recalled line(s) are printed to allow copying and pasting. Also, if more than one line is recalled, theres no way to edit them, so theyre executed.

There are also a set of built-in commands which execute in the interpreter namespace and can, therefore, do variable-substitution trickery:

* cd: change directory. You can do cd $x to change to the directory whose path is in variable x.
* pwd: return the current working directory. You can do x=`pwd` to return the path of the current working directory into x, or just type pwd to see it.
* pushd, popd: Oh come on... they work like the bash equivalents, ok? Both return the directory where they end up, as a string, so x=`pushd subDirectory` or here=`popd` work.

PDL::Indexing Perl module contains a tutorial on how to index piddles.

This manpage should serve as a first tutorial on the indexing and threading features of PDL.

This manpage is still in alpha development and not yet complete. "Meta" comments that point out deficiencies/omissions of this document will be surrounded by square brackets ([]), e.g. [ Hopefully I will be able to remove this paragraph at some time in the future ]. Furthermore, it is possible that there are errors in the code examples. Please report any errors to Christian Soeller (c.soeller@auckland.ac.nz).

Still to be done are (please bear with us and/or ask on the mailing list, see PDL::FAQ):

document perl level threading
threadids
update and correct description of slice
new functions in slice.pd (affine, lag, splitdim)
reworking of paragraph on explicit threading

Indexing and threading with PDL

A lot of the flexibility and power of PDL relies on the indexing and looping features of the perl extension. Indexing allows access to the data of a pdl object in a very flexible way. Threading provides efficient implicit looping functionality (since the loops are implemented as optimized C code).

Pdl objects (later often called "pdls") are perl objects that represent multidimensional arrays and operations on those. In contrast to simple perl @x style lists the array data is compactly stored in a single block of memory thus taking up a lot less memory and enabling use of fast C code to implement operations (e.g. addition, etc) on pdls.

pdls can have children

Central to many of the indexing capabilities of PDL are the relation of "parent" and "child" between pdls. Many of the indexing commands create a new pdl from an existing pdl. The new pdl is the "child" and the old one is the "parent". The data of the new pdl is defined by a transformation that specifies how to generate (compute) its data from the parents data. The relation between the child pdl and its parent are often bidirectional, meaning that changes in the childs data are propagated back to the parent. (Note: You see, we are aiming in our terminology already towards the new dataflow features. The kind of dataflow that is used by the indexing commands (about which you will learn in a minute) is always in operation, not only when you have explicitly switched on dataflow in your pdl by saying $a->doflow. For further information about data flow check the dataflow manpage.)

Another way to interpret the pdls created by our indexing commands is to view them as a kind of intelligent pointer that points back to some portion or all of its parents data. Therefore, it is not surprising that the parents data (or a portion of it) changes when manipulated through this "pointer". After these introductory remarks that hopefully prepared you for what is coming (rather than confuse you too much) we are going to dive right in and start with a description of the indexing commands and some typical examples how they might be used in PDL programs. We will further illustrate the pointer/dataflow analogies in the context of some of the examples later on.

There are two different implementations of this ``smart pointer relationship: the first one, which is a little slower but works for any transformation is simply to do the transformation forwards and backwards as necessary. The other is to consider the child piddle a ``virtual piddle, which only stores a pointer to the parent and access information so that routines which use the child piddle actually directly access the data in the parent. If the virtual piddle is given to a routine which cannot use it, PDL transparently physicalizes the virtual piddle before letting the routine use it.

Currently (1.94_01) all transformations which are ``affine, i.e. the indices of the data item in the parent piddle are determined by a linear transformation (+ constant) from the indices of the child piddle result in virtual piddles. All other indexing routines (e.g. ->index(...)) result in physical piddles. All routines compiled by PP can accept affine piddles (except those routines that pass pointers to external library functions).

Note that whether something is affine or not does not affect the semantics of what you do in any way: both

$a->index(...) .= 5;
$a->slice(...) .= 5;

change the data in $a. The affinity does, however, have a significant impact on memory usage and performance.

ies2iv project opens an IESNA file and translates it to the Open Inventor format in order to represent it in 3D and visualize it with software like ivview.

Usage:

ies2iv [--help | -h] [-t] [-p] < file1 > [file2...]

ies2iv: exports one or several IES files to Open Inventor file format
-p: number of horizontal slices
-t: number of vertical slices
-i : exports the corresponding igloo

Frottle (Freenet throttle) is a project to control traffic on wireless networks. Such control eliminates the common hidden-node effect even on large scale wireless networks. Frottle is currently only available for Linux wireless gateways using iptables firewalls, with plans to develop a windows client in the future.
Frottle is made to schedule the traffic of each client, using a master node to co-ordinate actions. This eliminates collisions, and prevents clients with stronger signals from receiving bandwidth bias.
Frottle has been developed and tested on the large community wireless network of WaFreeNet. We have found running frottle has given us a significant improvment in the network usability. Testing results will be documented here as time permits.
Frottle currently operates as a userspace application, receiveing outbound packets via the iptables QUEUE functionality. Access to the network is controlled by the frottle master, sending each client a control packet (token) which contains information about how much data can be sent at this time.
Each client receives its token and sends any required data, one at a time. This eliminates collisions, and with a reasonable signal packetloss is virtually zero. Also, since each client gets a limited slice of the bandwidth, everyone can get fair access regardless of their signal strength. Whilst this mechanism does result in increased latency, overall network performance and utilisation can significantly increase.
Main features:
- Traffic queues built in to frottle assign different, dynamic priorities to different traffic. Most traffic has a default priority. Traffic to/from specified ports (and ICMP packets) are made high priority. Traffic for connections that have done more than 2 MB of data and have a rate of more than 5 KB/s are made low priority. When a client is polled, high priority traffic is sent first, then default, then low until the poll quota is used.
-
- Realtime info on each clients performance is available from the master in a html file and optionally at each client in a similar html file. (The names and locations of these files is set in /etc/frottle.conf.)

AppFuse project is an application for "kickstarting" webapp development. Download, extract and execute ant new to instantly be up and running with a Struts+Spring+Hibernate app running on Tomcat/MySQL app. Uses Ant, XDoclet, Spring, Hibernate (or iBATIS), JUnit, jMock, StrutsTestCase, Canoos WebTest, Struts Menu, Display Tag Library, OSCache, JSTL and Struts (Spring MVC, WebWork, Tapestry and JSF are also options).
To learn more about AppFuse, its history, goals and future, checkout AppFuse: Start Your J2EE Web Apps on java.net. You can also watch this video, which shows you how to create a project with AppFuse - as well as gives you a tour of its out-of-the-box features.
The Spring Framework has greatly enhanced AppFuse since February 2004. Its used throughout for its Hibernate/iBATIS support, declarative transactions, dependency binding and layer decoupling. This clean and simple framework has greatly reduced the complexity of AppFuse, and also eliminated many lines of code. In short, for J2EE - its the best thing since sliced bread.
Enhancements:
- This releases major new features are upgrading to Spring 2.0, Hibernate 3.2, and Facelets + Ajax4JSF integration for the JSF option.
- In addition, many libraries have been fixed and a few bugs have been squashed.