this is to inform you about the release of eric3 3.8.0. It is available
The list below summarizes the difference between eric3 3.7.x and 3.8.x
- too long list of bugfixes to mention here
- these usability enhancements
-- added possibility for path translation for passive debugging
and remote debugging (Configuration Dialog -> Debugger -> General)
-- added support for project specific debugger settings
(see Project menu -> Debugger)
-- added support for special watchpoint conditions
(variable is created, variable is changed)
-- added capability to generate source documentation using CSS style
sheets to the eric3-doc utility (including the default style and
a style with reversed headers) (Note: eric3-helpviewer cannot
show the styles due to the limited HTML support in QTextBrowser)
-- added the flag '-t' to eric-doc and eric-api to tell them
to look for additional files
-- added additional lexers (CSS files, TeX files,
Diff files, Make Files, Properties Files and Batch Files)
(QScintilla > 1.5.x is required)
-- some interface cleanups and little reorganization of the
-- added action to open multiple files
-- added the capability to use %-codes for entering command line
arguments. Supported codes are:
%D directory of the current editor
%F filename of the current editor
%H home directory of the current user
%U user name of the current user
%% the percent sign
This functionality is available in the following dialogs:
configuration dialog, Debugger->General page
version control system, Command Options
cvs, Execute Command
subversion, Execute Command
mercurial, Execute command
-- added a configuration option to set the default encoding for
files, that don't contain an encoding marker
-- added the capability to delete shapes to the graphics dialogs
-- some optimisations and additions in the project browsers
-- added configurable filetype associations for projects
-- changed "Add file dialog" to allow the addition of
multiple files to the project
-- enhanced Ruby support (thanks to Richard Dale)
-- changed the shell completion to use the Scintilla userlist.
It is activated by pressing the TAB key and deactivated
by pressing the ESC key (without selection) or the TAB or
ENTER key (with selection).
-- extended task management with categorization and a colorized
-- added a templates system
-- added support for cx_Freeze (FreezePython)
-- added support for PyLint
-- added the commandline option "--nokde" to disable usage of the
-- switching the editor will highlight the current file in
the project browser
-- added a context menu for the "Listspace" view manager
-- added an incremental quicksearch to the search toolbar
-- added support for Mercurial VCS
What is it?
eric3 is a Python and Ruby IDE with batteries included. For details see
the eric3 home page.
=== Announcing Circe 0.0.3b1 ===
Circe Mainpage: http://circe.nick125.com/
Circe Download Page: http://circe.nick125.com/node/2
=== New features/bug fixes ===
We have added several bug fixes, and new features, such as unicode,
into the 0.0.3 beta 1 release.
=== Whats Circe? ===
Circe is a multiplatform IRC client written in the Python language that
utilizes the wxpython library for the graphical interface. Circe
features Unicode, Scripting, and many other features.
A new beta version of release 2.2 is available on sourceforge
(http://karrigell.sourceforge.net). It fixes the bugs that have been
- management of global scripts
- incorrect options in the default configuration file
- bug in mod_py, it didn't manage the line separator on Unix / Linux
Thanks to all who have reported bugs. I plan to release the final 2.2
version within 2 weeks
Over the last three weeks of on-and-off work I've developed and have
just released PyJudy 1.0, a wrapper to the Judy sparse dynamic array
library. It is available for download at
Judy, from http://judy.sourceforge.net/ , is ...
a C library that provides a state-of-the-art core technology that
implements a sparse dynamic array. Judy arrays are declared simply
with a null pointer. A Judy array consumes memory only when it is
populated, yet can grow to take advantage of all available memory
if desired. Judy's key benefits are scalability, high performance,
and memory efficiency. A Judy array is extensible and can scale up
to a very large number of elements, bounded only by machine memory.
Since Judy is designed as an unbounded array, the size of a Judy
array is not pre-allocated but grows and shrinks dynamically with
the array population.
Continuing from the PyJudy page at
PyJudy arrays are similar to Python dictionaries and sets. The
primary difference is that PyJudy keys are sorted; by unsigned
value if an integer, byte ordering if a string and object id if
a Python object. In addition to wrapping the underlying Judy
functions, PyJudy implements a subset of the Python dictionary
interface for the JudyL and JudySL API and a subset of the set
interface for the Judy1 API, along with some extensions for
iterating a subrange of the sorted keys, values and items.
In my performance tests I found that overall JudyL arrays were a
bit slower than Python dictionaries. Part of that might be my
inexperience with the details of writing Python extensions. Part
might be that JudyL arrays are sorted.
I found that the Judy1 arrays were faster than the set class
in Python 2.4. It'll be interesting to see how Raymond's new
set implementation affects that.
I did not do any memory comparisons.
PyJudy is distributed under the MIT license because that
has few upper-case letters than the BSD one.
Announcing Speedometer 2.1
Speedometer home page:
New in this release:
- New simultaneous display of multiple graphs with options for stacking
graphs vertically or horizontally
- New labels to differentiate each graph
- Removed 0-32 B/s from display to make more room for higher speeds
- Fixed a wait_creation bug
Speedometer is a console bandwidth and file download progress monitor with
a logarithmic bandwidth display and a simple command-line interface.
Speedometer requires Python 2.1 or later and Urwid 0.8.9 or later for
full-console bar graph display. Urwid may be downloaded from:
Speedometer is released under the GNU LGPL.
Available at : http://www.defuze.org/oss/atomixlib/
* It breaks the compatibility with previous version. Mainly you do not need to
pass the current atom element being constructed to the Atomix methods. Instead
the Atomix class keeps an handle to that element internally.
* It adds a lot more documentation via docstrings and an epydoc version of the
* It fixes some issues with XHTML content
* It is more flexible for creating the atom document (feed or entry based).
* It improves performances of atomixlib since 0.2.0
A Python module to facilitate Atom 1.0 documents generation.
I would like to thank Uche Ogbuji for discussing atomixlib so much and giving me
some very neat ideas.
- Sylvain Hellegouarch
This message was sent using IMP, the Internet Messaging Program.
Leo 4.4a2 has been withdrawn due to problems that can cause Leo to lose what
you have recently typed.
Leo 4.4a3 will be released in about a week.
Edward K. Ream email: edreamleo(a)charter.net
Beta 0.18 of MMA - Musical MIDI Accompaniment - is now
available for downloading. Included in this release:
Enhancements to lyrics, macros, command line macro define,
various bug fixes, and minor syntax changes.
MMA is a accompaniment generator -- it creates midi tracks
for a soloist to perform with. User supplied files contain
pattern selections, chords, and MMA directives. For full details
If you have any questions or comments, please send them
Bob van der Poel ** Wynndel, British Columbia, CANADA **
pypy-0.8.0: Translatable compiler/parser and some more speed
The PyPy development team has been busy working and we've now packaged
our latest improvements, completed work and new experiments as
version 0.8.0, our third public release.
The highlights of this third release of PyPy are:
- Translatable parser and AST compiler. PyPy now integrates its own
compiler based on Python own 'compiler' package but with a number
of fixes and code simplifications in order to get it translated
with the rest of PyPy. This makes using the translated pypy
interactively much more pleasant, as compilation is considerably
faster than in 0.7.0.
- Some Speed enhancements. Translated PyPy is now about 10 times
faster than 0.7 but still 10-20 times slower than
CPython on pystones and other benchmarks. At the same time,
language compliancy has been slightly increased compared to 0.7
which had already reached major CPython compliancy goals.
- Some experimental features are now translateable. Since 0.6.0, PyPy
shipped with an experimental Object Space (the part of PyPy
implementing Python object operations and manipulation) implementing
lazily computed objects, the "Thunk" object space. With 0.8.0 this
object space can also be translated preserving its feature
What is PyPy (about)?
PyPy is a MIT-licensed research-oriented reimplementation of
Python written in Python itself, flexible and easy to
experiment with. It translates itself to lower level
languages. Our goals are to target a large variety of
platforms, small and large, by providing a compilation toolsuite
that can produce custom Python versions. Platform, Memory and
Threading models are to become aspects of the translation
process - as opposed to encoding low level details into a
language implementation itself. Eventually, dynamic
optimization techniques - implemented as another translation
aspect - should become robust against language changes.
Note that PyPy is mainly a research and development project
and does not by itself focus on getting a production-ready
Python implementation although we do hope and expect it to
become a viable contender in that area sometime next year.
PyPy is partially funded as a research project under the
European Union's IST programme.
Where to start?
Getting started: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html
PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/
PyPy Homepage: http://codespeak.net/pypy/
The interpreter and object model implementations shipped with
the 0.8 version can run on their own and implement the core
language features of Python as of CPython 2.4. However, we still
do not recommend using PyPy for anything else than for education,
playing or research purposes.
Ongoing work and near term goals
At the last sprint in Paris we started exploring the new directions of
our work, in terms of extending and optimising PyPy further. We
started to scratch the surface of Just-In-Time compiler related work,
which we still expect will be the major source of our future speed
improvements and some successful amount of work has been done on the
support needed for stackless-like features.
This release also includes the snapshots in preliminary or embryonic
form of the following interesting but yet not completed sub projects:
- The OOtyper, a RTyper variation for higher-level backends
- A limited (PPC) assembler backend (this related to the JIT)
- some bits for a socket module
PyPy has been developed during approximately 16 coding sprints across
Europe and the US. It continues to be a very dynamically and
incrementally evolving project with many of these one-week workshops
PyPy has been a community effort from the start and it would
not have got that far without the coding and feedback support
from numerous people. Please feel free to give feedback and
contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html
the pypy team, (Armin Rigo, Samuele Pedroni,
Holger Krekel, Christian Tismer,
Carl Friedrich Bolz, Michael Hudson,
and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html)
PyPy development and activities happen as an open source project
and with the support of a consortium partially funded by a two
year European Union IST research grant. The full partners of that
Heinrich-Heine University (Germany), AB Strakt (Sweden)
merlinux GmbH (Germany), tismerysoft GmbH (Germany)
Logilab Paris (France), DFKI GmbH (Germany)
ChangeMaker (Sweden), Impara (Germany)