Mini Glossary

Code still in testing, but mostly complete and stable. Useable. All major interfaces and specs are unlikely to change.

alpha

Code in early stages of development. May have some functionality. Major interfaces may change.

pipedream

Still in the planning/idea stage. No or little actual code to show. Yet!

Current Project List

Release 0.1: 3 December 2001

These are projects which I'm currently working on, or haven't given up on yet! All genuinely helpful hands welcome to roll up their sleeves and join in. At the moment, its just me, so there's no mailing lists or whatever, just contact me direct.

+ECCO Models

ECCO website ECCO is an economic/environmental modelling methodology. This project aims to develop a simulation harness for ECCO models that can be deployed locally or across networks. My previous development of these models was done with a piece of software called Professional Dynamo, so the starting point is to create something that can read dynamo scripting language. I am aiming to build something that compiles and runs the models, not a model development environment (which is what PD is). The core package contains classes for describing simulation models and for running them and collecting their results. A gui harness using my why toolkit i also in there. I'm currently in process of ditching this in favour of the dog gui. Currently, the simulator can handle large models (2000+ equations) and runs at a reasonable speed on modern computers. My main development plans for the future are to enhance the gu to allow modular custom views that can be loaded dynamically. This is on hold for the next couple of months uintil I see whether the Uncle Unc gui project delivers a workable gui harness. packages: ulu.sim.dyn ulu.sim.dyn.macros ulu.sim.dyn.parser ulu.sim.dyn.tools ulu.why requires: dog [newer versions only] development status: beta

+Uncle Unc

Uncle Unc website Unc is the 'Universal Network Client'. 'Uncle Unc' sounds nice, and Uncles are generally helpful chaps. Unc aims to be an all-round helpful good egg for system administrators and anyone who works in a networked environment. The de facto standard for computer interaction these days is the windows explorer style file manager that presents a GUI view of the local file system and acts as a launch-pad for an array of helper programs (yes, I know the Mac got there first. Read Konqueror, Nautilus, whatever else if you use a GUI Linux desktop). Trends in computing are moving away from the desktop file system towards a more networked environment, in which we interact with a whole range of items organised in lists. The Windows 'Network Neighbourhood' SMB/Cifs protocol tackles this in one way, by allowing a user to map remote computers into the local file system. Uncle Unc tries to take a more flexible approach. The user interface doesn't know what a file system is, or a network or anything else. All it understands is a very thin layer of interfaces, of items arranged in views (e.g. files in directories). Any collection of data can be wrapped so as to present these interfaces, and then Uncle Unc can show them to you. The same goes for the user interface. The interfaces that Uncle Unc understands can be displayed in a gui explorer-like client. Equally, it could be displayed in a web-based gui, or a voice-based one, a command-line gui, a WAP display, whatever. Because there is no single standard UI, any ui that understands Unc's interfaces can correctly display any resource that does. And any resource exposed via Unc's interfaces can automatically be viewed in any ui. That's the theory, at any rate. Time will tell how it holds up to the harsh realities of life. Possible future development in user interfaces and network services are logged on the projects page. If you have any other good ideas along these lines,, please mail me. If you're an open source developer with a project that you think might usefully interact with Uncle Unc, please, please mail me!! packages: ulu.view ulu.view.ui.gui ulu.view.sys.fs ulu.view.sys.refl requires: dog for the ui.gui. As this is currently the only ui for unc, that's a strong dependency! development status: Implemented components are in late alpha. I would classify them as beta but for the fact that I haven't yet felt ready to finalise the core API until I've done a few more services and had a little experience on what can and can't be decoupled so neatly. Everything else in pipedream stage right now, but I'm moving fast on this one.

+Part Box

I played around with bird-flocking algorithms for a while. i played around with elastic interval geometry too, and l-systems, and a range of other 3D things I might call 'procedural geometries'. The Part Box started out simply as a way of extending my 2D bird-flocks into 3D, and is currently attempting to unify a range of 3D modelling techniques. A 'part' is a generic point-mass body, possessing a position and orientation in 3d space. Both of these are tracked dynamically, that is, the position, velocity and acceleration of each is recorded (and any of the three can be set as primary controller from which the others derive). Forces can be attached to parts. Both part and force are generic interfaces, with a number of implementations of each. Simple forces can attract or repel from a fixed point in space. Variations attach these points' locations to individual parts or to the centre-pooint of a group of parts. Any number of forces can be stacked onto a part. A higher-level interface called 'Organiser' is responsible for knitting together parts and forces in interesting ways. The framework is hopefully generic enough to allow representations of many kinds of spatial dynamics. I have successfully built simple chase sequences, oscillations, and simple swarming patterns using the framework. Elastic interval geometry (spring and mass systems) are the next big challenge. Ideally, I would like to be able to create simulations that can switch back-and-forth between flocking and EIG structures. There is a generic interface for viewers of the particle system being modelled. A fairly crude AWT-only version and a fancier realtime render using idx3d were implemented. I may look into java3D again at some point - it has apparently come some way since the early days when I last used it. When running, the system is controlled by a python interpreter in the console window/DOS prompt from which it was launched. It can also accept python scripts from files as input, and a few demos of these are bundled under ulu/sim/part/py This project's currently on the back burner. Once Uncle Unc is up and running, I may use it as a test application-as-a-service and bring it back to life. packages: ulu.sim.part requires: idx3d [optionally] development status: early beta. Main interfaces are in place, a few sample demo scripts are up, but it hasn't really produce any mind-blowing graphics yet!

+Utilities

This is a space in which to document and highlight a few of the things in the ulu.ut package, my dumping ground of useful bits and pieces that don't really qualify as projects in their own rights. There are useful generic quicksort and bubblesort implementations in there, utilising an ulu.ut.Comparable interface that is identical to the java2 Comparable interface. I rolled my own to support those damn applets! There is a very useful FileFinder class that recursively traverses the filesystem and optionally dives down zip and jar files too. Two concrete implementations of this are a java class finder, now fully employed by Uncle Unc, and a FileSplicer class that does a quick job of inserting and replacing text in multiple files. I use this to add in the navigation menus to this website, and to stitch in the GPL preamble to all the source files. And there's probably more good stuff in there that I've forgotten about.