[PEAK] Trellis 0.5b1 feature complete in SVN

[Phillip J. Eby]

All of the previously-announced features, including coroutine-based 
pseudothreads, and observable Dict/List/Set types, are now available 
in Trellis SVN.  You should also now be able to install it in binary 
form using only:

    easy_install svn://svn.eby-sarna.com/svnroot/Trellis

with all the dependencies being supplied from releases on the Cheeseshop.

The documentation isn't done yet, to say the least.  I have some 
stuff in progress on my machine, but it's not in Subversion yet.  The 
best way at the moment to see how the new features work is to look at 
the mini-demos in Internals.txt.

The "List" type didn't turn out as well as I would have hoped for; 
the standard list interface is far too expressive with things like 
sort(), remove(), and reverse(), to be able to generate a meaningful 
change log.  So List objects just provide a 'changed' receiver 
attribute that's True whenever the list changes.  It's also not 
efficient for maintaining very large lists, as it uses a 
copy-on-write strategy to preserve Trellis time invariants (i.e., you 
can only write to the future of an object).

Fortunately, the TrellisDB library will ultimately include a 
list-like type that's a sorted, read-only view of a query set, and 
will be able to give out some kind of simple change events, suitable 
for updating say, a wx grid or table model.

Overall, the Trellis library is now a compelling replacement for the 
portion of the old peak.events that was not devoted to timing, I/O, 
OS signals, or Twisted.  (Those features will be replaced later with 
TrellisIO.)  Indeed, with the new List/Set/Dict types, the Trellis 
far exceeds the old peak.events in what kind of objects can be 
observed, as well as the other major advances.

So, once TrellisIO is available, I'd like to deprecate the legacy 
peak.events code, although I'm not sure how well this will work given 
that peak.tools.supervisor and peak.running.process do not have 
adequate test suites for direct migration to using the Trellis.  (The 
other parts of peak.running that use peak.events are small enough in 
scope and sufficiently testable to allow for refactoring to Trellis 
APIs, however.)

So, it's not clear to me how the main PEAK framework will move 
forward.  I suspect it may be necessary to create a 
separately-installed "PEAK-Legacy" or "PEAK-Unsupported" distribution 
to retain things that get dropped from the mainline core as we move forward.