changes:
SimPy 2.0.1 is a bug-fix release of SimPy 2.0. It
repairs bugs and imperfections in libraries, documentation
and models.
SimPy 2.0 has been a major release of the SimPy simulation
package. It runs on all platforms supporting Python (MS Windows,Linux, Mac).
The major new features of that release are
* an Object Oriented API (in addition to the existing API),
* integration of all documentation into one browsable
and searchable HTML document.
SimPy 2.0 is fully backwards compatible with previous
SimPy versions.
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
SimPy 1.8 is a major release with new capabilities, improved documentation
and bug fixes. It is fully backwards compatible with previous versions.
From SimPy 1.8 on, the obsolete Python version 2.2 is no longer supported.
Some of the changes and improvements are:
* New compound yield statements, supporting time-out or event-based
reneging in 'get' and 'put' operations on Store and Level resources.
* yield get on a Store resource can now have a filter function which
selects which and how many items (e.g. "3 parcels weighing less than
3 pounds") should be retrieved.
* The Manual has been thoroughly edited, restructured and rewritten
with a view to greater clarity and readability. It is provided in both
HTML and PDF format.
* The Cheatsheet has been completely rewritten in a tabular format and
reduced to just a few pages. The goal was to turn it into a concise
desktop reference of SimPy commands. The Cheatsheet is provided in both
XLS (MS Excel spreadsheet) and PDF format.
SimPy 1.7.1 is a minor (maintenance) release which fixes a few bugs
in 1.7. The SimPy 1.7.1 API is identical to that of version 1.7.
SimPy 1.7 is fully compatible with version 1.6.1. This major release brings
significant new capabilities for the SimPy modeller and thus a broader
field of applicability to SimPy. It is now very easy to implement models
for scenarios involving:
* producer/consumer relationships between processes,
* multi-process cooperations,
* multi-resource requests, and
* consumable resources.
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
