Active members are sought. If you want to take over an existing
subproject or to create a new one, you're welcome, so please show !
If the subproject's name, definition, or place in the hierarchy
displeases you, this can be fixed easily.
Its goal is to ensure the project
identity, coordination and management.
Its maintainer is also a referee
in case no democratic agreement is found.
For the original (latest) page, click
here
Currently maintained by
Faré
(rideau@clipper.ens.fr)
Its goals are to review all existing computing systems
and computing system elements,
and determine what is good or bad about them,
what they lack, and what they do that they shouldn't,
so that the Tunes project may benefit from their experience.
For the original (latest) page, click
here
Currently mismaintained by
Faré
(rideau@ens.fr) - new maintainer sought.
Its goal is to design and implement a high-level language that would
fulfill all expressiveness, reflection, dynamic extensibility and
restrainability, logical specifiability requirements for the Tunes project
(as no available one seems to do).
For the original (latest) page, click
here
Currently maintained by
Faré
(rideau@clipper.ens.fr)
Its goal is to design and implement generic tools to integrate
the Tunes HLL with objects (in source or binary form) from other universes,
or other contexts in the Tunes HLL.
For the original (latest) page, click
here
Currently unmaintained by
Faré
(rideau@clipper.ens.fr)
Its goal is to design and implement tools to transform programs
written in C into well-behaved programs in the Tunes HLL, with
program-dependent customizable context. Instances would allow
(semi) automatic translation of C source for Unix (or even
device drivers from, say, VSTa or Linux) into HLL modules.
For the original (latest) page, click
here
Currently unmaintained by
Faré
(rideau@clipper.ens.fr)
Its goal is to provide
a frame where all common algorithms are
to be written once and for all,
instead of requiring everyone to reinvent incompatible wheels,
and redundantly load the overall network traffic with these copies.
This implies automatic world-wide unique identification of objects,
and constitution of institutions
to promote some objects as "standard".
For the original (latest) page, click
here
Currently unmaintained by
Faré
(rideau@clipper.ens.fr)
Its goal is to define a core subset of the HLL
that be easier to implement for bootstrap purposes,
yet allow for further self-extension into the full HLL.
For the original (latest) page, click
here
Currently unmaintained by
Faré
(rideau@clipper.ens.fr)
Its goal is to develop generic and specific interfaces
between the humans and the computer objects, at all level,
be it immediate interaction or programming style, syntax, etc,
so as to provide the greatest freedom to all users.
It should be nicely integrated into the Tunes HLL.
For the original (latest) page, click
here
Currently maintained by
Chris
(chharris@u.washington.edu)
The Migration
subproject
It should provide a way to allow objects to dynamically fill the available
computer resources,
while respecting the human-defined constraints to please users:
economize computer resources (including time spent),
still communicating to the human user wherever s/he is, etc.
All the migration scheduling should be under
full user control, be it direct, indirect, remote, or purely potential.
Actually, Migration encompasses
Garbage Collecting,
Swapping,
Remote Procedure Call,
Publishing management,
and more.
For the original (latest) page, click
here
Currently mismaintained by
Faré
(rideau@ens.fr) - new maintainer sought.
Its goal is to design and implement a portable low-level language and
object encoding format, that would allow dynamic object migration.
For the original (latest) page, click
here
Currently mismaintained by
Faré
(rideau@ens.fr).
Takers please show.
Its goal is to write some architecture-independent code so that
Tunes would run on top of any POSIX-ly compliant enough system
(i.e. a workstation running some recent Unix clone).
Portability, not efficiency, will be the primary goal,
as "the hardware shall provide enough power".
Thus the code should be modular enough
so that the implementation ported to other platforms
and parts could be replaced by architecture-specific code.
For the original (latest) page, click
here
Currently mismaintained by
Faré
(rideau@ens.fr).
Takers please show.
Its goal is to implement the architecture-dependent code so that
Tunes would run on any intel-based PC compatible computer with a 32 bit
processor.
For the original (latest) page, click
here
Currently mismaintained by
Faré
(rideau@ens.fr) - new maintainer sought.
Page Maintainer: