Oroboro is an approach to using Python as a test and
modeling language for Verilog. With it, Python generator
functions are used to model simulation threads in a
cooperative multitasking style. A simulation task in Python
can suspend its execution with a yield statement that lists
the reasons the task should be resumed. Typical reasons map
directly to VPI callback reasons. Oroboro does not implement
a scheduler of its own, rather, it relies on Verilog for all
event scheduling through the use of callback functions. A
short example illustrates some basic capabilities for
interacting with a Verilog simulation.
from oroboro import *
def watcher(sig):
print "Watching signal %s" % sig
while 1:
yield sigchange(sig), timeout(10)
if isinstance(currentreason(), sigchange):
print "New value for signal %s is %s" % (sig, sig.get())
if isinstance(currentreason(), timeout):
print "Timeout has elapsed. Wait again."
def main(systf):
s = signal("top.mysignal")
t = task(watcher, s)
yield timeout(0)
The example above illustrates a simple task that watches a
Verilog signal. The task 'watcher' loops indefinitely,
suspending its execution with a yield statement that lists
the reasons it should be resumed. Here, the task waits until
either the signal value changes, or a 10 simulation tick
timeout occurs ... whichever comes first. When the task
resumes, it uses the 'currentreason' function to determine
whether the first or second reason in the yield statement
was triggered. The task prints an informative message and
then loops.
A longer paper discussing Oroboro, source downloads and
examples can be found at:
http://apvm.sourceforge.net
libgmail -- Python binding for Google's Gmail service
<http://libgmail.sf.net/>
The `libgmail` project is a pure Python binding to provide access to
Google's Gmail web-mail service.
The library currently ships with a demonstration utility to archive
messages from a Gmail account into mbox files, suitable for importing
into a local email client.
Also includes a demonstration utility that acts as a SMTP proxy to
allow mail to be sent from any standard mail client that uses SMTP
(e.g. Mail.app, Mozilla etc).
License: GPL 2.0
Major changes since 0.0.5:
* Implemented SMTP proxy to enable Gmail to be send with a
standard mail client via (E)SMTP.
* Extended standard SMTP class to handle ESMTP EHLO & AUTH PLAIN commands.
* Utility function '_retrieveJavascript' to retrieve current version
of Gmail Javascript file. (By request.)
<p><a href="http://libgmail.sf.net/">libgmail 0.0.6</a> - The
`libgmail` project is a pure Python binding to provide access to
Google's Gmail web-mail service. (15-Jul-04)</p>
Hey folks,
Just a reminder that SciPy 04 is coming up. More information is here:
http://www.scipy.org/wikis/scipy04
About the Conference and Keynote Speaker
---------------------------------------------
The 1st annual *SciPy Conference* will be held this year at Caltech,
September 2-3, 2004. As some of you may know, we've experienced great
participation in two SciPy "Workshops" (with ~70 attendees in both 2002
and 2003) and this year we're graduating to a "conference." With the
prestige of a conference comes the responsibility of a keynote address.
This year, Jim Hugunin has answered the call and will be speaking to
kickoff the meeting on Thursday September 2nd. Jim is the creator of
Numeric Python, Jython, and co-designer of AspectJ. Jim is currently
working on IronPython--a fast implementation of Python for .NET and Mono.
Presenters
-----------
We still have room for a few more standard talks, and there is plenty of
room for lightning talks. Because of this, we are extending the abstract
deadline until July 23rd. Please send your abstract to
abstracts(a)scipy.org. Travis Oliphant is organizing the presentations
this year. (Thanks!) Once accepted, papers and/or presentation slides
are acceptable and are due by August 20, 2004.
Registration
-------------
Early registration ($100.00) has been extended to July 23rd. Follow the
links off of the main conference site:
http://www.scipy.org/wikis/scipy04
After July 23rd, registration will be $150.00. Registration includes
breakfast and lunch Thursday & Friday and a very nice dinner Thursday
night. Please register as soon as possible as it will help us in
planning for food, room sizes, etc.
Sprints
--------
As of now, we really haven't had much of a call for coding sprints for
the 3 days prior to SciPy 04. Below is the original announcement about
sprints. If you would like to suggest a topic and see if others are
interested, please send a message to the list. Otherwise, we'll forgo
the sprints session this year.
We're also planning three days of informal "Coding Sprints" prior to
the conference -- August 30 to September 1, 2004. Conference
registration is not required to participate in the sprints. Please
email the list, however, if you plan to attend. Topics for these
sprints will be determined via the mailing lists as well, so please
submit any suggestions for topics to the scipy-user list:
list signup: http://www.scipy.org/mailinglists/
list address: scipy-user(a)scipy.org
thanks,
eric
The newly-formed Zope/Python Users Group of DC announces our upcoming
meeting schedule:
Mo Jul 19: Zope -- presentation on Archetypes by Joel Burton
Th Aug 5: Python -- no topic yet
Mo Aug 16: Zope -- no topic yet
Th Sep 2: Python -- no topic yet
Mo Sep 20: Zope -- no topic yet
The hot topics that users at the first meeting were most interested in
include: Plone skinning, Zope/Plone performance, Python + XML, Text
processing with Python, and Zope development, so expect that we'll fill
in these topics ASAP with presentations like these.
Our meetings take place at 7pm in the large conference room of Porter
Novelli,a marketing/communications firm located in downtown DC at 1909 K
Street (right off the red and orange/blue Metro lines, and close to many
bus lines).
We'll be meeting on the first Thursday and third Monday of each month.
A full schedule of our meetings, talks, and plans are at our web site at
http://www.zpugdc.org. To receive announcements about upcoming meetings,
and to contribute to our group, please join our mailing list (send a
message with the *subject* 'subscribe' to zpugdc(a)lists.zpugdc.org, or
sign up at the site.)
If you have questions, you can reach us at info(a)zpugdc.org.
Thanks!
- j.
Joel Burton, for the Zope/Python Users Group of DC (www.zpugdc.org)
Hi!,
I'm pleased to announce the availability of PyTables 0.8.1.
PyTables is a hierarchical database package designed to efficiently
manage very large amounts of data. PyTables is built on top of the
HDF5 library and the numarray package. It features an object-oriented
interface that, combined with natural naming and C-code generated from
Pyrex sources, makes it a fast, yet extremely easy-to-use tool for
interactively saving and retrieving different kinds of datasets. It
also provides flexible indexed access on disk to anywhere in the data.
The primary purpose of this release is to incorporate updates to
related to the newly released numarray 1.0. I've taken the opportunity
to backport some improvements added in PyTables 0.9 (in alpha stage)
as well as to fix the known problems.
Improvements:
- The logic for computing the buffer sizes has been revamped. As a
consequence, the performance of writing/reading tables with large
row sizes has improved by a factor of ten or more, now exceeding 70
MB/s for writing and 130 MB/s for reading (using compression). See
http://sf.net/mailarchive/forum.php?thread_id=4963045&forum_id=13760
for more info.
- The maximum row size for tables has been raised to 512 KB
(before it was 8 KB, due to some internal limitations)
- Documentation has been improved in minor details. As a result of a
fix in the underlying documentation system (tbook), chapters start
now at odd pages, instead of even. So those of you who want to print
to double side probably will have better luck now when aligning
pages ;). Another one is that HTML documentation has improved its
look as well.
Bug Fixes:
- Indexing of Arrays with list or tuple flavors (#968131)
When retrieving single elements from an array with 'List' or
'Tuple' flavors, an error occurred. This has been
corrected and now you can retrieve fileh.root.array[2] without
problems for 'List' or 'Tuple' flavored (E, VL)Arrays.
- Iterators on Arrays with list or tuple flavors fail (#968132)
When using iterators with Array objects with 'List' or
'Tuple' flavors, an error occurred. This has been
corrected.
- Last Index (-1) of Arrays doesn't work (#968149)
When accessing to the last element in an Array using the notation
-1, an empty list (or tuple or array) is returned instead of the
proper value. This happened in general with all negative
indices. Fixed.
- Table.read(flavor="List") should return pure lists (#972534)
However, it used to return a pointer to numarray.records.Record
instances, as in:
>>> fileh.root.table.read(1,2,flavor="List")
[<numarray.records.Record instance at 0x4128352c>]
>>> fileh.root.table.read(1,3,flavor="List")
[<numarray.records.Record instance at 0x4128396c>,
<numarray.records.Record instance at 0x41283a8c>]
Now the next records are returned:
>>> fileh.root.table.read(1,2, flavor=List)
[(' ', 1, 1.0)]
>>> fileh.root.table.read(1,3, flavor=List)
[(' ', 1, 1.0),
(' ', 2, 2.0)]
In addition, when reading a single row of a table, a
numarray.records.Record pointer was returned:
>>> fileh.root.table[1]
<numarray.records.Record instance at 0x4128398c>
Now, it returns a tuple:
>>> fileh.root.table[1]
(' ', 1, 1.0)
Which I think is more consistent, and more Pythonic.
- Copy of leaves fails... (#973370)
Attempting to copy leaves (Table or Array with different flavors) on
top of themselves caused an internal error in PyTables. This has
been corrected by silently avoiding the copy and returning the
original Leaf as a result.
Minor changes:
- When assigning a value to a non-existing field in a table row, now a
KeyError is raised, instead of the AttributeError that was issued
before. I think this is more consistent with the type of error.
- Tests have been improved so as to pass the whole suite when compiled
in 64 bit mode on a Linux/PowerPC machine (namely a dual-G5 Powermac
running a 64-bit, 2.6.4 Linux kernel and the preview YDL
distribution for G5, with 64-bit GCC toolchain). Thanks to Ciro
Cattuto for testing and reporting the modifications that were
needed.
Where PyTables can be applied?
------------------------------
PyTables is not designed to work as a relational database competitor,
but rather as a teammate. If you want to work with large datasets of
multidimensional data (for example, for multidimensional analysis), or
just provide a categorized structure for some portions of your cluttered
RDBS, then give PyTables a try. It works well for storing data from data
acquisition systems (DAS), simulation software, network data monitoring
systems (for example, traffic measurements of IP packets on routers),
very large XML files, or for creating a centralized repository for system
logs, to name only a few possible uses.
What is a table?
----------------
A table is defined as a collection of records whose values are stored in
fixed-length fields. All records have the same structure and all values
in each field have the same data type. The terms "fixed-length" and
"strict data types" seem to be quite a strange requirement for a
language like Python that supports dynamic data types, but they serve a
useful function if the goal is to save very large quantities of data
(such as is generated by many scientific applications, for example) in
an efficient manner that reduces demand on CPU time and I/O resources.
What is HDF5?
-------------
For those people who know nothing about HDF5, it is a general purpose
library and file format for storing scientific data made at NCSA. HDF5
can store two primary objects: datasets and groups. A dataset is
essentially a multidimensional array of data elements, and a group is a
structure for organizing objects in an HDF5 file. Using these two basic
constructs, one can create and store almost any kind of scientific data
structure, such as images, arrays of vectors, and structured and
unstructured grids. You can also mix and match them in HDF5 files
according to your needs.
Platforms
---------
I'm using Linux (Intel 32-bit) as the main development platform, but
PyTables should be easy to compile/install on many other UNIX
machines. This package has also passed all the tests on a UltraSparc
platform with Solaris 7 and Solaris 8. It also compiles and passes all
the tests on a SGI Origin2000 with MIPS R12000 processors, with the
MIPSPro compiler and running IRIX 6.5. It also runs fine on Linux
64-bit platforms, like an AMD Opteron running SuSe Linux Enterprise
Server or PowerPC G5 with Linux 2.6.x in 64bit mode. It has also been
tested in MacOSX platforms (10.2 but should also work on newer
versions).
Regarding Windows platforms, PyTables has been tested with Windows
2000 and Windows XP (using the Microsoft Visual C compiler), but it
should also work with other flavors as well.
An example?
-----------
For online code examples, have a look at
http://pytables.sourceforge.net/html/tut/tutorial1-1.html
and, for newly introduced Variable Length Arrays:
http://pytables.sourceforge.net/html/tut/vlarray2.html
Web site
--------
Go to the PyTables web site for more details:
http://pytables.sourceforge.net/
Share your experience
---------------------
Let me know of any bugs, suggestions, gripes, kudos, etc. you may
have.
Cheers,
--
Francesc Alted
** Note: this is *not* relative to the current GTK+ 2.x-based PyGTK **
Hello there,
I'm releasing today version 0.6.12 of PyGTK, off the 0.6 branch,
which is the original PyGTK branch based on GTK+ 1.2.
This version includes a small number of bugfixes and two API additions
which have been incorporated during the last two years of stability.
Summary of changes:
Bugfixes
- Fixed GtkScrolledWindow's use of `has_attr'
- A fix for bug 96907: Crashes when calling emit() with less
parameters than expected.
- Check for non-existing directories in pygtk._get_available_versions
- Implement proper exception handling in the GladeXML constructor.
- Performance enhancement in bug 112395: Clean up __getattr__ and add
__eq__/__nonzero__ to GtkObject.
New API
- Wrapped GtkRadioButton.group()
- Implemented GtkCList.set_focus_row() to work around a GTK+ focus
bug in the GtkCList.
Download it from
ftp://ftp.gtk.org/pub/gtk/python/v1.2/pygtk-0.6.12.tar.gz
There is no accompanying gnome-python release. This tarball is
identical to the release candidate that was announced earlier. Thanks
for everyone that provided bug reports, comments and fixes for the
branch, including Jon Nelson, Steve McClure and Andrew Reid.
Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331
PyProtocols 0.9.3 release candidate 2 is now available for
download. Assuming there are no bugs reported in the next 3-4 weeks, it
will become the 0.9.3 final release in early August. (The 0.9.3rc2
revision fixes a bug in the '--without-speedups' version of 0.9.3rc1, as
reported by Matthew Scott.)
What is PyProtocols?
--------------------
PyProtocols is an extended implementation of PEP 246, adding a new
"declaration API" that lets you easily define your own interfaces and
adapters, and declare what adapters should be used to adapt what types,
objects, or interfaces. Using PyProtocols, you can easily make flexible
frameworks that you or other developers can extend without needing to
modify the base framework. PyProtocols interfaces can interoperate with
those of Twisted and Zope, or can be used entirely standalone.
PyProtocols may be used, modified, and distributed under the same terms and
conditions as Python or Zope.
What's new in version 0.9.3rc1? (Highlights)
--------------------------------------------
* Adapter factories can now accept just one argument, the way Twisted and
Zope adapters do.
* Interface and protocol objects can be called, as a shortcut for 'adapt()'
(as Zope and Twisted interfaces do)
* You can now more easily install PyProtocols without a C compiler, using
the '--without-speedups' option to 'setup.py' (see the README.txt file for
details.)
* Numerous other bug fixes and enhancements - see CHANGES.txt for details.
IMPORTANT: If you are upgrading from a previous version of PyProtocols,
please read UPGRADING.txt for important information. Certain rarely-used
features have been deprecated, and others have changed slightly. Most
users should not experience any problems (except perhaps for
DeprecationWarnings), but please be sure to verify this before you upgrade
any production code from 0.9.2 to 0.9.3.
PyProtocols Resources
---------------------
* Upgrading to PyProtocols 0.9.3 (and a look ahead to 1.0)
http://peak.telecommunity.com/protocol_api/UPGRADING.txt.html
* Detailed Changes for all releases:
http://peak.telecommunity.com/protocol_api/CHANGES.txt.html
* Release notes, installation instructions, and browsable API docs:
http://peak.telecommunity.com/protocol_api/
* Source and Binary Releases:
http://peak.telecommunity.com/dist/
* Reference Manual (HTML):
http://peak.telecommunity.com/protocol_ref/module-protocols.html
* Reference Manual (PDF):
http://peak.telecommunity.com/protocol_ref.pdf
* Browsable CVS Repository:
http://cvs.eby-sarna.com/PyProtocols/
libgmail -- Python binding for Google's Gmail service
<http://libgmail.sf.net/>
The `libgmail` project is a pure Python binding to provide access to
Google's Gmail web-mail service.
The library currently ships with one demonstration utility to archive
messages from a Gmail account into mbox files, suitable for importing
into a local email client.
License: GPL 2.0
Major changes since 0.0.4:
* Added functionality to enable message sending.
* Added command line example to send a message.
<p><a href="http://libgmail.sf.net/">libgmail 0.0.5</a> - The
`libgmail` project is a pure Python binding to provide access to
Google's Gmail web-mail service. (11-Jul-04)</p>
Python module for creating functions computing the Cyclic Redundancy Check
(CRC). Any generating polynomial producing 8, 16, 32, or 64 bit CRCs is
allowed. Generated functions can be used in Python or C/C++ source code can
be generated.
Visit the project home page at http://crcmod.sourceforge.net/