The S3 2010 Paper deadline was moved forward by two weeks, and is now
August 13, 2010.
*** Workshop on Self-sustaining Systems (S3) 2010 ***
September 27-28, 2010
The University of Tokyo, Japan
http://www.hpi.uni-potsdam.de/swa/s3/s3-10/
In cooperation with ACM SIGPLAN
=== Call for papers ===
The Workshop on Self-sustaining Systems (S3) is a forum for discussion
of topics relating to computer systems and languages that are able to
bootstrap, implement, modify, and maintain themselves. One property of
these systems is that their implementation is based on small but
powerful abstractions; examples include (amongst others)
Squeak/Smalltalk, COLA, Klein/Self, PyPy/Python, Rubinius/Ruby, and
Lisp. Such systems are the engines of their own replacement, giving
researchers and developers great power to experiment with, and explore
future directions from within, their own small language kernels.
S3 will be take place September 27-28, 2010 at The University of Tokyo,
Japan. It is an exciting opportunity for researchers and practitioners
interested in self-sustaining systems to meet and share their knowledge,
experience, and ideas for future research and development.
--- Submissions and proceedings ---
S3 invites submissions of high-quality papers reporting original
research, or describing innovative contributions to, or experience with,
self-sustaining systems, their implementation, and their application.
Papers that depart significantly from established ideas and practices
are particularly welcome.
Submissions must not have been published previously and must not be
under review for any another refereed event or publication. The program
committee will evaluate each contributed paper based on its relevance,
significance, clarity, and originality. Revised papers will be published
as post-proceedings in the ACM Digital Library.
Papers should be submitted electronically via EasyChair at
http://www.easychair.org/conferences/?conf=s32010 in PDF format.
Submissions must be written in English (the official language of the
workshop) and must not exceed 10 pages. They should use the ACM SIGPLAN
10 point format, templates for which are available at
http://www.acm.org/sigs/sigplan/authorInformation.htm.
--- Venue ---
The University of Tokyo, Komaba Campus, Japan
--- Important dates ---
Submission of papers: *EXTENDED* August 13, 2010
Author notification: August 27, 2010
Early registration: September 3, 2010
Revised papers: September 10, 2010
S3 workshop: September 27-28, 2010
Final papers for ACM-DL post-proceedings: October 15, 2010
--- Invited talks ---
Yukihiro Matsumoto: "From Lisp to Ruby to Rubinius"
Takashi Ikegami: "Sustainable Autonomy and Designing Mind Time"
--- Chairs ---
Robert Hirschfeld (Hasso-Plattner-Institut Potsdam, Germany)
hirschfeld(a)hpi.uni-potsdam.de
Hidehiko Masuhara (The University of Tokyo, Japan)
masuhara(a)graco.c.u-tokyo.ac.jp
Kim Rose (Viewpoints Research Institute, USA)
kim.rose(a)vpri.org
--- Program committee ---
Carl Friedrich Bolz, University of Duesseldorf, Germany
Johan Brichau, Universite Catholique de Louvain, Belgium
Shigeru Chiba, Tokyo Institute of Technology, Japan
Brian Demsky, University of California, Irvine, USA
Marcus Denker, INRIA Lille, France
Richard P. Gabriel, IBM Research, USA
Michael Haupt, Hasso-Plattner-Institut, Germany
Robert Hirschfeld, Hasso-Plattner-Institut, Germany (co-chair)
Atsushi Igarashi, University of Kyoto, Japan
David Lorenz, The Open University, Israel
Hidehiko Masuhara, University of Tokyo, Japan (co-chair)
Eliot Miranda, Teleplace, USA
Ian Piumarta, Viewpoints Research Institute, USA
Martin Rinard, MIT, USA
Antero Taivalsaari, Nokia, Finland
David Ungar, IBM, USA
_______________________________________________
fonc mailing list
fonc(a)vpri.org
http://vpri.org/mailman/listinfo/fonc
Hi,
just did a two test tool releases, one for tox and one for py.test.
The tox-0.8 release provides fixes and workarounds, see changelog below.
The py-1.3.3 release mainly provides fixes for terminal output.
best & thanks to the respective feedbackers/helpers,
holger
What is tox?
----------------------
Tox is a generic test runner, creating virtualenv environments
on the fly and executing your test tool of choice. It works
conveniently from a developer's terminal as well as from
a Continous Integration Server. See
http://codespeak.net/tox
What is py.test?
----------------------
py.test is an easy-to-learn testing tool with many plugins
and features for integration and functional tests in Python. See
http://pytest.org
for more info.
CHANGES tox-0.8
-----------------
- work around a virtualenv limitation which crashes if
PYTHONDONTWRITEBYTECODE is set.
- run pip/easy installs from the environment log directory, avoids
naming clashes between env names and dependencies (thanks ronny)
- require a more recent version of py lib
- refactor and refine config detection to work from a single file
and to detect the case where a python installation overwrote
an old one and resulted in a new executable. This invalidates
the existing virtualenvironment now.
- change all internal source to strip trailing whitespaces
Changes py-1.3.3
----------------------
- fix issue113: assertion representation problem with triple-quoted strings
(and possibly other cases)
- make conftest loading detect that a conftest file with the same
content was already loaded, avoids surprises in nested directory structures
which can be produced e.g. by Hudson. It probably removes the need to use
--confcutdir in most cases.
- fix terminal coloring for win32
(thanks Michael Foord for reporting)
- fix weirdness: make terminal width detection work on stdout instead of stdin
(thanks Armin Ronacher for reporting)
- remove trailing whitespace in all py/text distribution files
I just released execnet-1.0.8, see the Changelog for details, below.
What is execnet?
---------------------
execnet is a small pure python library that manages distributed code execution
across Python versions and host boundaries. It provides a self-bootstrapping
share-nothing model with channels to send/receive data messages. It also
helps with managing a cluster of (local or remote) processes and comes
with tons of examples and API docs:
http://codespeak.net/execnet
green version of execnet
--------------------------------
For those interested i hacked up a green version of execnet
which is API-compatible (and less stable) than the "main"
version. It requires the eventlet library and is thus not fully
self-bootstrapping (you need to install eventlet on all remote nodes
you want to execute code on). There is no release but you can peruse
http://code.google.com/p/execnet-green/source/checkout
and "python setup.py develop" to play with it. It will never spawn
any operating system threads. Rather remote_exec() will spawn
greenlets/micro-threads of which you can easily have a few thousand.
It probably only is stable enough for simple scenarios at this point.
best,
holger
Changelog 1.0.8 (compared to 1.0.7):
- new ``gateway.remote_exec(func, **kwargs)`` style fo executing
a pure function with parameters. The function on the remote
side also needs to accept a ``channel`` which allows it to
communicate back and forth. Thanks to Ronny Pfannschmidt
for implementing it with special kudos to Maciej Fijalkowski
for writing a "pure-function" checker so that on Python2.6
onwards non-pure functions will be rejected.
- enhance rsyncing to also sync permissions (stat().st_mode)
of directories and files.
(should also resolve http://bitbucket.org/hpk42/py-trunk/issue/68/)
- fix rsyncing of symlinks, thanks to Charles Solar
(should also resolve http://bitbucket.org/hpk42/py-trunk/issue/70/)
- update internal usage of apipkg to 1.0b6
- remote_exec(module) now makes sure that the linecache is updated
before reading and sending the source. thanks Ronny, Matt.
- removed all trailing whitespace from source files
I'm pleased to announce the release of version 2.0 of the bitstring
module.
What is it?
-----------
bitstring helps to make creating, manipulating and deconstructing
binary
data as easy as possible. It allows arbitrary (and very large) bit
patterns
to be used without worrying about bit shifting and masking operations.
The comprehensive API covers packing, reading, searching, replacing
and
slicing as well as bit setting and checking, a host of different
binary
interpretations and all the standard bit-wise operators.
The module is pure Python and is available for Python 2.6 and later,
including Python 3.
What's new in version 2?
------------------------
The main change is a more powerful and streamlined API. Too much to go
into
here (see the release notes), but here are some simple examples:
>>> s = BitString('0x000001b3') # create a 32-bit bitstring from hexadecimal
>>> s += 'uint:12=352, uint:12=288' # append two 12-bit integers
>>> s += bitstring.pack('<2f, 0b1, <h', 0.1, 3.7, 44) # pack more values
>>> s.unpack('hex:32, 2*uint:12, <2f, bool, <h') # unpack it all
['0x000001b3', 352, 288, 0.10000000149011612, 3.700000047683716, True,
44]
>>> s.tobytes() # convert to bytes
b'\x00\x00\x01\xb3\x16\x01 \xcd\xcc\xcc=\xcd\xccl@\x96\x00\x00'
>>> t = s[32:41]. # slicing
>>> t.bin # the binary interpretation
'0b000101100'
>>> list(t.findall('0b10')) # finding bit patterns
[3, 6]
Where can I find out more?
--------------------------
The project's homepage is at http://python-bitstring.googlecode.com/
Documentation is hosted at http://packages.python.org/bitstring/
Release note for all versions: http://code.google.com/p/python-bitstring/wiki/ReleaseNotes
--
Thanks,
Scott Griffiths
Hi all,
I'm happy to announce the release of Lupa 0.10.
http://pypi.python.org/pypi/lupa/0.10
What is Lupa?
--------------
Lupa integrates the LuaJIT2 runtime [1] into CPython. It is a rewrite of
LunaticPython in Cython.
Features
---------
* separate Lua runtime states through a LuaRuntime class
* frees the GIL and supports threading in separate runtimes when
calling into Lua
* Python compatible coroutine wrapper for Lua coroutines
* proper encoding and decoding of strings (configurable per runtime,
UTF-8 by default)
* supports Python 2.x and 3.x, potentially starting with Python 2.3
(currently untested)
* written for LuaJIT2, as opposed to the Lua interpreter (tested with
LuaJIT 2.0.0-beta4)
* easy to hack on and extend as it is written in Cython, not C
This release features much faster locking of the LuaRuntime instance,
especially in the single threaded case. It uses the FastRLock class that I
posted as a Python Cookbook recipe [2]. Lupa 0.10 also fixes several issues
in error handling cases when calling back into Python from Lua. Updating is
recommended.
Examples
---------
>>> from lupa import LuaRuntime
>>> lua = LuaRuntime()
>>> lua.eval('1+1')
2
>>> lua_func = lua.eval('function(f, n) return f(n) end')
>>> def py_add1(n): return n+1
>>> lua_func(py_add1, 2)
3
>>> lua_code = '''\
... function(N)
... for i=0,N do
... coroutine.yield( i%2 )
... end
... end
... '''
>>> lua = LuaRuntime()
>>> f = lua.eval(lua_code)
>>> gen = f.coroutine(4)
>>> list(enumerate(gen))
[(0, 0), (1, 1), (2, 0), (3, 1), (4, 0)]
Why use it?
------------
It complements Python very well. Lua is a language as dynamic as
Python, but LuaJIT compiles it to very fast machine code, sometimes
faster than many other compiled languages [3]. The language runtime is
extremely small and carefully designed for embedding. The complete
binary module of Lupa, including a statically linked LuaJIT2 runtime,
is only some 500KB on a 64 bit machine.
However, Lua code is harder to write than Python code as the language
lacks most of the batteries that Python includes. Writing large
programs in Lua is rather futile, but it provides a perfect backup
language when raw speed is more important than simplicity.
Lupa is a very fast and thin wrapper around LuaJIT. It makes it easy
to write dynamic Lua code that accompanies dynamic Python code by
switching between the two languages at runtime, based on the tradeoff
between simplicity and speed.
[1] LuaJIT2: http://luajit.org/
[2]
http://code.activestate.com/recipes/577336-fast-re-entrant-optimistic-lock-…
[3] http://shootout.alioth.debian.org/u64/performance.php?test=mandelbrot
Hi everybody,
We just released version 0.6 of tipfy, a small framework made for
Google App Engine. These are the most important achievements in this
release:
* Added support for single-file apps, which are much like we see in
App Engine's webapp. Example of a single-file app:
http://www.tipfy.org/paste/view/648817
* This also makes unit testing easier in several situations. App and
URLs can be defined and executed in a single function. Example of a
redirect test:
http://www.tipfy.org/paste/view/685812
* We no longer use thread locals and removed all global variables from
the core and extensions (deprecated since the 0.5.x series).
More about tipfy:
* Website: http://www.tipfy.org/
* Extensions repository: http://www.tipfy.org/wiki/extensions/
* Discussion group: http://groups.google.com/group/tipfy
regards,
rodrigo moraes
Hi All,
When: Wed 11th Aug, 19:00
Where: The Science Gallery, Pearse Street.
What:
Distributed profiling using Redis (Michael Twomey)
-------------------------------------------------------------------------
Mick moved his Redis talk from PyCon Ireland main tracks, so he decided to
give a talk one of our regular meetups.
Redis is a shared data structure server which offers an interesting
opportunity to collect distributed profiling data from multiple Python
processes. The Python cProfile module can be used to profile individual
function calls. Combine the profiler and Redis together and you get a
distributed application profiling collection service.
Community building & PyCon & Python (Kevin Gill)
---------------------------------------------------------------------------
"What do you want from Python?" -- Some background on what this is about,
and building on the successful openspaces sessions from PyCon Ireland 2010.
Pub TBD on the day (as always). :-)
More details:
http://www.python.ie/meetup/2010/aug_2010_talks__the_science_gallery/
All are welcome and it's free.
Cheers,
/// Vicky
~~~~~~~~~~~~~~~~~~~~~~~~~
~~ http://irishbornchinese.com ~~
~~ http://www.python.ie ~~
~~~~~~~~~~~~~~~~~~~~~~~~~
Hi all,
I'm happy to announce the release of Sphinx 1.0, a new feature-laden
release of the Sphinx documentation tool.
What is it?
===========
Sphinx is a tool that makes it easy to create intelligent and beautiful
documentation for Python projects (or other documents consisting of
multiple reStructuredText source files).
Website: http://sphinx.pocoo.org/
What's new in 1.0 (very short version)?
=======================================
Lots of stuff; most important of all domains support (see blog post at
http://pythonic.pocoo.org/2009/9/12/new-in-sphinx-1-0-domains), new HTML
themes, new output formats (manpage, epub).
The full list is at <http://sphinx.pocoo.org/latest/changes.html>.
cheers,
Georg
Hi all,
I'm happy to announce the release of Lupa 0.9.
http://pypi.python.org/pypi/lupa/0.9
What is Lupa?
--------------
Lupa integrates the LuaJIT2 runtime [1] into CPython. It is a rewrite of
LunaticPython in Cython with a couple of additional features.
The major new feature in this release is coroutine support for Lua
functions that follows the Python coroutine protocol (next/send).
Examples
---------
>>> from lupa import LuaRuntime
>>> lua = LuaRuntime()
>>> lua.eval('1+1')
2
>>> lua_func = lua.eval('function(f, n) return f(n) end')
>>> def py_add1(n): return n+1
>>> lua_func(py_add1, 2)
3
>>> lua_func = lua.eval('''
... function(N)
... for i=0,N do coroutine.yield(i%2) end
... end
... ''')
>>> co = lua_func.coroutine(3)
>>> list(co)
[0,1,0,1]
Why use it?
------------
It complements Python very well. Lua is a language as dynamic as
Python, but LuaJIT compiles it to very fast machine code, sometimes
faster than many other compiled languages [2]. The language runtime is
extremely small, has a small memory footprint and is carefully designed for
embedding. The complete binary module of Lupa, including a statically
linked LuaJIT2 runtime, is only some 500KB on a 64 bit machine.
However, Lua code is harder to write than Python code as the language
lacks most of the batteries that Python includes. Writing large
programs in Lua is rather futile, but it provides a perfect backup
language when raw speed is more important than simplicity.
Lupa is a very fast and thin wrapper around LuaJIT. It makes it easy
to write dynamic Lua code that accompanies dynamic Python code by
switching between the two languages at runtime, based on the tradeoff
between simplicity and speed.
[1] LuaJIT2: http://luajit.org/
[2] http://shootout.alioth.debian.org/u64/performance.php?test=mandelbrot