Commit 1b30b35a authored by SVN-Git Migration's avatar SVN-Git Migration

Imported Upstream version 2.1.9

parent ca5f2cb3
......@@ -10,3 +10,4 @@ conf
docs/source/api/generated
docs/gh-pages
setup.cfg
MANIFEST
......@@ -8,20 +8,22 @@ This package contains Python bindings for `ØMQ <http://www.zeromq.org>`_.
Versioning
==========
Current release of pyzmq is 2.1.7, and targets libzmq-2.1.7. For libzmq
Current release of pyzmq is 2.1.9, and targets libzmq-2.1.9. For libzmq
2.0.x, use pyzmq release 2.0.10.1 or the 2.0.x development branch.
PyZMQ versioning follows libzmq versioning. In general, your pyzmq version should be the same
as that of your libzmq, but due to the generally growing API of libzmq, your pyzmq should
*not* be newer than your libzmq. This is a strict restriction for pyzmq <= 2.1.0, but we
intend to support libzmq >= 2.1.0 for pyzmq 2.1.x.
intend to support libzmq >= 2.1.4 (the first 'stable' 2.1 release) for pyzmq 2.1.x.
ØMQ 3.0
-------
ØMQ 3.0 and 4.0
---------------
As of 2.1.7, we have experimental support for the 3.0 API of libzmq,
developed at https://github.com/zeromq/libzmq. No code to change, no flags to pass, just
build against libzmq 3 and it should work. The pyzmq API has not changed.
build pyzmq against libzmq 3 and it should work. The pyzmq API has not changed.
2.1.9 adds support for the changes in ØMQ-4.0 dev, at time of release.
Documentation
......@@ -45,11 +47,11 @@ install Cython version 0.13 or later.
Building and installation
=========================
Eggs
----
Eggs and MSIs
-------------
We have binary installers for various Pythons on OSX and (32b) Windows, so you should be able to
just ``easy_install pyzmq`` in many situations. These eggs *include libzmq-2.1.7*, so they should
We have binary installers for various Pythons on OSX and Windows, so you should be able to
just ``easy_install pyzmq`` in many situations. These eggs *include libzmq-2.1.9*, so they should
be the only thing you need to start using pyzmq, but we simply don't have the experience to know
when and where these installers will not work.
......@@ -61,18 +63,22 @@ Eggs are on PyPI, and we have them for 'current' Pythons, which are for OSX 10.6
* Python 2.6, 2.7, 3.2 (32b and 64b intel)
and win32:
and Windows (x86 and x64):
* Python 2.7, 3.2
We also have MSI installer packages in our `downloads
<http://github.com/zeromq/pyzmq/downloads>`_ section on GitHub.
Our build scripts are much improved as of 2.1.4, so if you would like to contribute 64b Windows
installers, or have any improvements on existing releases, they would be much appreciated.
Simply ``python setup.py bdist_msi`` or ``python setupegg.py bdist_egg`` *should* work, once you
have a 64b libzmq and Python. We simply don't have the VMs or time in which to do this
ourselves.
A Python 2.6/win64 MSI for 2.1.7 was provided by Craig Austin (craig DOT austin AT gmail DOT com)
Our build scripts are much improved as of 2.1.4, so if you would like to contribute better
Windows installers, or have any improvements on existing releases, they would be much
appreciated. Simply ``python setup.py bdist_msi`` or ``python setupegg.py bdist_egg`` *should*
work, once you have a libzmq and Python. We simply don't have the VMs or time in which to cover
all the bases ourselves. Sometimes libzmq.so/dll/dylib doesn't get included unless ``build``
is specified *also*, e.g. ``python setupegg.py build bdist_egg``, but this doesn't always
seem to be true.
General
-------
......@@ -92,7 +98,7 @@ The argument should be a directory containing a ``lib`` and a ``include`` direct
``libzmq`` and ``zmq.h`` respectively. For instance (on Windows), if you have downloaded pyzmq
and current libzmq into the same parent directory, this would be:
$ python setup.py configure --zmq=../zeromq-2.1.7
$ python setup.py configure --zmq=../zeromq-2.1.9
Second, run this command::
......@@ -120,6 +126,13 @@ Current testing indicates that running
successfully builds a working MSI installer, but we don't have enough Windows deployment
experience to know where that may fail.
Windows x64
***********
64b Windows builds have been successful (as of 2.1.7.1), using VC++ 2008 express, and the
Windows 7 SDK. VS2008 had to be patched as described `here
<http://www.cppblog.com/xcpp/archive/2009/09/09/vc2008express_64bit_win7sdk.html>`_, and
pyzmq was built following `these instructions <http://wiki.cython.org/64BitCythonExtensionsOnWindows>`_ on the Cython wiki.
Linux
-----
......@@ -132,6 +145,21 @@ you may need to do one of the following:
$ python setup.py build_ext --rpath=/opt/zeromq-dev/lib --inplace
Mac OSX
-------
The easiest way to install libzmq on OSX is with the wonderful `homebrew <http://mxcl.github.com/homebrew/>`_
package manager, via::
$ brew install zeromq
And to build a 32+64b intel fat binary, add ``--universal``::
$ brew install zeromq --universal
This will install libzmq in /usr/local, making pyzmq installable with pip, which doesn't
support our binary eggs.
Development
-----------
......@@ -174,15 +202,17 @@ Currently, we are using the following steps to release PyZMQ:
python setup.py sdist --formats=zip,gztar upload
* Upload the tarball and ``.zip`` file to github.
* Branch the release::
* Branch the release (do *not* push the branch)::
git checkout -b 2.1.7 master
git push origin 2.1.7
git checkout -b 2.1.9 master
* commit the changed ``version.pyx`` to the branch::
git add zmq/core/version.pyx && git commit -m "bump version to 2.1.9"
* Tag the release::
git tag -a -m "Tagging release 2.1.7" v2.1.7
git tag -a -m "Tagging release 2.1.9" v2.1.9
git push origin --tags
* Make sure the ``README.rst`` has an updated list of contributors.
......@@ -191,24 +221,43 @@ Currently, we are using the following steps to release PyZMQ:
Authors
=======
This project was started by and continues to be led by Brian E. Granger
(ellisonbg AT gmail DOT com).
This project was started and continues to be led by Brian E. Granger
(ellisonbg AT gmail DOT com). Min Ragan-Kelley (benjaminrk AT gmail DOT com)
is the primary developer of pyzmq at this time.
The following people have contributed to the project:
* Carlos Rocha (carlos DOT rocha AT gmail DOT com)
* Andrew Gwozdziewycz (git AT apgwoz DOT com)
* Fernando Perez (fernando DOT perez AT berkeley DOT edu)
* Nicholas Piel (nicholas AT nichol DOT as)
* Eugene Chernyshov (chernyshov DOT eugene AT gmail DOT com)
* Justin Riley (justin DOT t DOT riley AT gmail DOT com)
* Ivo Danihelka (ivo AT denihelka DOT net)
* Thomas Supra (tomspur AT fedoraproject DOT org)
* Douglas Creager (dcreager AT dcreager DOT net)
* Andrew Gwozdziewycz (git AT apgwoz DOT com)
* Baptiste Lepilleur (baptiste DOT lepilleur AT gmail DOT com)
* Brandon Craig Rhodes (brandon AT rhodesmill DOT org)
* Brandyn A. White (bwhite AT dappervision DOT com)
* Brian Granger (ellisonbg AT gmail DOT com)
* Carlos A. Rocha (carlos DOT rocha AT gmail DOT com)
* Daniel Lundin (dln AT spotify DOT com)
* Daniel Truemper (truemped AT googlemail DOT com)
* Erick Tryzelaar (erick DOT tryzelaar AT gmail DOT com)
* Erik Tollerud (erik DOT tollerud AT gmail DOT com)
* Fernando Perez (Fernando DOT Perez AT berkeley DOT edu)
* Ivo Danihelka (ivo AT danihelka DOT net)
* Justin Riley (justin DOT t DOT riley AT gmail DOT com)
* Min Ragan-Kelley (benjaminrk AT gmail DOT com)
* Nicholas Piël (nicholas AT nichol DOT as)
* Ondrej Certik (ondrej AT certik DOT cz)
* Paul Colomiets (paul AT colomiets DOT name)
* Scott Sadler (github AT mashi DOT org)
* spez (steve AT hipmunk DOT com)
* Stefan van der Walt (stefan AT sun DOT ac DOT za)
* Thomas Kluyver (takowl AT gmail DOT com)
* Baptiste Lepilleur (baptiste DOT lepilleur AT gmail DOT com)
* Daniel Truemper (truemped AT googlemail DOT com)
* Thomas Spura (tomspur AT fedoraproject DOT org)
* Zbigniew Jędrzejewski-Szmek (zbyszek AT in DOT waw DOT pl)
* hugo shi (hugoshi AT bleb2 DOT (none))
* spez (steve AT hipmunk DOT com)
as reported by::
git log --all --format='* %aN (%aE)' | sort -u | sed 's/@/ AT /1' | sed -e 's/\./ DOT /g'
with some adjustments.
......@@ -26,7 +26,9 @@ import sys
import os
import logging
import pickle
import platform
from distutils import ccompiler
from distutils.sysconfig import customize_compiler
from subprocess import Popen, PIPE
try:
......@@ -83,6 +85,7 @@ def detect_zmq(basedir, **compiler_attrs):
"""
cc = ccompiler.new_compiler()
customize_compiler(cc)
for name, val in compiler_attrs.items():
setattr(cc, name, val)
......@@ -96,8 +99,8 @@ r"""
#include <stdio.h>
#include "zmq.h"
int main(){
unsigned int major, minor, patch;
int main(void){
int major, minor, patch;
zmq_version(&major, &minor, &patch);
fprintf(stdout, "vers: %d.%d.%d\n", major, minor, patch);
return 0;
......@@ -105,15 +108,19 @@ int main(){
""")
finally:
f.close()
cpreargs = lpreargs = None
if sys.platform == 'darwin':
# allow for missing UB arch, since it will still work:
preargs = ['-undefined', 'dynamic_lookup']
else:
preargs = None
objs = cc.compile([cfile])
cc.link_executable(objs, efile, extra_preargs=preargs)
# use appropriate arch for comiler
if platform.architecture()[0]=='32bit':
cpreargs = ['-arch','i386']
lpreargs = ['-arch', 'i386', '-undefined', 'dynamic_lookup']
else:
# allow for missing UB arch, since it will still work:
lpreargs = ['-undefined', 'dynamic_lookup']
objs = cc.compile([cfile],extra_preargs=cpreargs)
cc.link_executable(objs, efile, extra_preargs=lpreargs)
result = Popen(efile, stdout=PIPE, stderr=PIPE)
so, se = result.communicate()
......
......@@ -545,4 +545,9 @@ text-align: right;
color: rgb(0,50,150);
background-color: ;
font-style: italic;
}
.versionadded {
font-style: italic;
background: #ffe;
}
\ No newline at end of file
.. PyZMQ changelog summary, started by Min Ragan-Kelley, 2011
.. _changelog:
================
Changes in PyZMQ
================
This is a coarse summary of changes in pyzmq versions. For a real changelog, consult the
`git log <https://github.com/zeromq/pyzmq/commits>`_
2.1.9 (dev)
===========
* added zmq.ssh tools for tunneling socket connections, copied from IPython
* Expanded sockopt support to cover changes in libzmq-4.0 dev.
* Fixed an issue that prevented :exc:`KeyboardInterrupts` from being catchable.
* Added attribute-access for set/getsockopt. Setting/Getting attributes of :class:`Sockets`
with the names of socket options is mapped to calls of set/getsockopt.
.. sourcecode:: python
s.hwm = 10
s.identity = b'whoda'
s.linger
# -1
* Terminating a :class:`~Context` closes the sockets it created, matching the behavior in
`czmq <http://czmq.zeromq.org/>`_.
* :class:`ThreadDevices` use :meth:`Context.instance` to create sockets, so they can use
inproc connections to sockets in other threads.
* fixed units error on :func:`zmq.select`, where the poll timeout was 1000 times longer
than expected.
* Add missing ``DEALER/ROUTER`` socket type names (currently aliases, to be replacements for ``XREP/XREQ``).
* base libzmq dependency raised to 2.1.4 (first stable release) from 2.1.0.
2.1.7.1
=======
* bdist for 64b Windows only. This fixed a type mismatch on the ``ZMQ_FD`` sockopt
that only affected that platform.
2.1.7
=====
* Added experimental support for libzmq-3.0 API
* Add :func:`zmq.eventloop.ioloop.install` for using pyzmq's IOLoop in a tornado
application.
2.1.4
=====
* First version with binary distribution support
* Added :meth:`~Context.instance()` method for using a single Context throughout an application
without passing references around.
......@@ -33,8 +33,6 @@ extensions = ['matplotlib.sphinxext.mathmpl',
'sphinx.ext.doctest',
'sphinx.ext.intersphinx',
'ipython_console_highlighting',
'inheritance_diagram',
'sphinxtogithub',
'numpydoc']
# Add any paths that contain templates here, relative to this directory.
......@@ -51,7 +49,7 @@ master_doc = 'index'
# General information about the project.
project = u'PyZMQ'
copyright = u"""2010, Brian E. Granger.
copyright = u"""2010-2011, Brian E. Granger & Min Ragan-Kelley.
ØMQ logo © iMatix Corportation, used under the Creative Commons Attribution-Share Alike 3.0 License.
Python logo ™ of the Python Software Foundation, used by Min RK with permission from the Foundation"""
......
......@@ -52,19 +52,19 @@ socket. For performance reasons, this :func:`.monitored_queue` function is writt
Cython, so the loop does not involve Python, and should have the same performance as the
basic ``QUEUE`` device.
One shortcoming of the ``QUEUE`` device is that it does not support having ``XREP``
sockets as both input and output. This is because ``XREP`` sockets, when they receive a
One shortcoming of the ``QUEUE`` device is that it does not support having ``ROUTER``
sockets as both input and output. This is because ``ROUTER`` sockets, when they receive a
message, prepend the ``IDENTITY`` of the socket that sent the message (for use in routing
the reply). The result is that the output socket will always try to route the incoming
message back to the original sender, which is presumably not the intended pattern. In
order for the queue to support an XREP-XREP connection, it must swap the first two parts
order for the queue to support a ROUTER-ROUTER connection, it must swap the first two parts
of the message in order to get the right message out the other side.
To invoke a monitored queue is similar to invoking a regular ØMQ device::
from zmq.devices.monitoredqueue import monitored_queue
ins = ctx.socket(zmq.XREP)
outs = ctx.socket(zmq.XREQ)
ins = ctx.socket(zmq.ROUTER)
outs = ctx.socket(zmq.DEALER)
mons = ctx.socket(zmq.PUB)
configure_sockets(ins,outs,mons)
monitored_queue(ins, outs, mons, in_prefix='in', out_prefix='out')
......
......@@ -12,40 +12,49 @@ PyZMQ Documentation
.. Note::
These docs are for pyzmq-|release|, but pyzmq has not made any significant changes to
itself since 2.0.10, so they should apply just fine there as well.
PyZMQ versioning follows zeromq, so your pyzmq version should match those of your
PyZMQ versioning follows zeromq, so your pyzmq version should match that of your
zeromq. The only changes at the pyzmq user's level are the addition of a few socket
types and socket options.
PyZMQ is the Python bindings for ØMQ_, written almost entirely in Cython_. This
documentation currently contains notes on some important aspects of developing PyZMQ and
an overview of what the ØMQ API looks like in Python. For information on how to use
ØMQ in general, see the excellent `ØMQ Manual`_.
.. Note::
As of PyZMQ 2.1.7, PyZMQ has experimental support for the libzmq-3.0 development version,
and has dropped support for the zeromq-2.0 series.
Please don't hesitate to report pyzmq issues to our tracker_ on GitHub.
:ref:`Summary of Changes in PyZMQ <changelog>`
Notes from developing PyZMQ
===========================
.. toctree::
:maxdepth: 2
pyversions.rst
unicode.rst
:maxdepth: 2
pyversions.rst
unicode.rst
Using PyZMQ
===========
.. toctree::
:maxdepth: 2
morethanbindings.rst
devices.rst
eventloop.rst
logging.rst
api/index.rst
:maxdepth: 2
morethanbindings.rst
serialization.rst
devices.rst
eventloop.rst
logging.rst
ssh.rst
api/index.rst
Indices and tables
==================
......
......@@ -10,6 +10,7 @@ Python's 'batteries included' philosophy, provides more than just Python methods
objects for calling into the ØMQ C++ library.
The Core as Bindings
--------------------
......@@ -30,6 +31,41 @@ efficiently writing C-extensions for Python. By separating out our objects into
extensions in Cython and call directly to ZeroMQ at the C-level without the penalty of
going through our Python objects.
Thread Safety
-------------
In ØMQ, Contexts are threadsafe objects, but Sockets are **not**. It is safe to use a
single Context (e.g. via :meth:`zmq.Context.instance`) in your entire multithreaded
application, but you should create sockets on a per-thread basis. If you share sockets
across threads, you are likely to encounter uncatchable c-level crashes of your
application unless you use judicious application of :py:class:`threading.Lock`, but this
approach is not recommended.
.. seealso::
ZeroMQ API `note on threadsafety <http://api.zeromq.org/2-1:zmq>`_
Socket Options as Attributes
****************************
.. versionadded:: 2.1.9
In 0MQ, socket options are set/retrieved with the :meth:`set/getsockopt` methods. With the
class-based approach in pyzmq, it would be logical to perform these operations with
simple attribute access, and this has been added in pyzmq 2.1.9. Simply assign to or
request a Socket attribute with the (case-insensitive) name of a sockopt, and it should
behave just as you would expect:
.. sourcecode:: python
s = ctx.socket(zmq.DEALER)
s.identity = b'dealer'
s.hwm = 10
s.events
# 0
s.fd
# 16
Core Extensions
---------------
......@@ -47,10 +83,16 @@ object over the wire after serializing with :mod:`json` and :mod:`pickle` respec
and any object sent via those methods can be reconstructed with the
:meth:`~.Socket.recv_json` and :meth:`~.Socket.recv_pyobj` methods. Unicode strings are
other objects that are not unambiguously sendable over the wire, so we include
:meth:`~.Socket.send_unicode` and :meth:`~.Socket.recv_unicode` that simply send via the
unambiguous utf-8 byte encoding. See :ref:`our Unicode discussion <unicode>` for more
information on the trials and tribulations of working with Unicode in a C extension while
supporting Python 2 and 3.
:meth:`~.Socket.send_unicode` and :meth:`~.Socket.recv_unicode` that simply send bytes
after encoding the message ('utf-8' is the default).
.. seealso::
* :ref:`Further information <serialization>` on serialization in pyzmq.
* :ref:`Our Unicode discussion <unicode>` for more information on the trials and
tribulations of working with Unicode in a C extension while supporting Python 2 and 3.
MessageTracker
**************
......@@ -97,6 +139,7 @@ included in PyZMQ itself:
background
* :ref:`zmq.eventloop <eventloop>` : The `Tornado`_ event loop, adapted for use
with ØMQ sockets.
* :ref:`zmq.ssh <ssh>` : Simple tools for tunneling zeromq connections via ssh.
.. _ØMQ: http://www.zeromq.org
.. _Tornado: https://github.com/facebook/tornado
\ No newline at end of file
.. _Tornado: https://github.com/facebook/tornado
.. PyZMQ serialization doc, by Min Ragan-Kelley, 2011
.. _serialization:
Serializing messages with PyZMQ
===============================
When sending messages over a network, you often need to marshall your data into bytes.
Builtin serialization
---------------------
PyZMQ is primarily bindings for libzmq, but we do provide three builtin serialization
methods for convenience, to help Python developers learn libzmq. Python has two primary
packages for serializing objects: :py:mod:`json` and :py:mod:`pickle`, so we provide
simple convenience methods for sending and receiving objects serialized with these
modules. A socket has the methods :meth:`~.Socket.send_json` and
:meth:`~.Socket.send_pyobj`, which correspond to sending an object over the wire after
serializing with json and pickle respectively, and any object sent via those
methods can be reconstructed with the :meth:`~.Socket.recv_json` and
:meth:`~.Socket.recv_pyobj` methods.
These methods designed for convenience, not for performance, so developers who do want
to emphasize performance should use their own serialized send/recv methods.
Using your own serialization with PyZMQ
---------------------------------------
In general, you will want to provide your own serialization that is optimized for your
application or library availability. This may include using your own preferred
serialization ([msgpack]_, [protobuf]_), or adding compression via [zlib]_ in the standard
library, or the super fast [blosc]_ library.
There are two simple models for implementing your own serialization: write a function
that takes the socket as an argument, or subclass Socket for use in your own apps.
For instance, pickles can often be reduced substantially in size by compressing the data.
The following will send *compressed* pickles over the wire:
.. sourcecode:: python
import zlib, cPickle as pickle
def send_zipped_pickle(socket, obj, flags=0, protocol=-1):
"""pickle an object, and zip the pickle before sending it"""
p = pickle.dumps(obj, protocol)
z = zlib.compress(p)
return socket.send(z, flags=flags)
def recv_zipped_pickle(socket, flags=0, protocol=-1):
"""inverse of send_zipped_pickle"""
z = socket.recv(flags)
p = zlib.uncompress(z)
return pickle.loads(p)
A common data structure in Python is the numpy array. PyZMQ supports sending
numpy arrays without copying any data, since they provide the Python buffer interface.
However just the buffer is not enough information to reconstruct the array on the
receiving side. Here is an example of a send/recv that allow non-copying
sends/recvs of numpy arrays including the dtype/shape data necessary for reconstructing
the array.
.. sourcecode:: python
import numpy
def send_array(socket, A, flags=0, copy=True, track=False):
"""send a numpy array with metadata"""
md = dict(
dtype = str(A.dtype),
shape = A.shape,
)
socket.send_json(md, flags|zmq.SNDMORE)
return socket.send(A, flags, copy=copy, track=track)
def recv_array(socket, flags=0, copy=True, track=False):
"""recv a numpy array"""
md = socket.recv_json(flags=flags)
msg = socket.recv(flags=flags, copy=copy, track=track)
buf = buffer(msg)
A = numpy.frombuffer(buf, dtype=md['dtype'])
return A.reshape(md['shape'])
.. [msgpack] Message Pack serialization library http://msgpack.org
.. [protobuf] Google Protocol Buffers http://code.google.com/p/protobuf
.. [zlib] Python stdlib module for zip compression: :py:mod:`zlib`
.. [blosc] Blosc: A blocking, shuffling and loss-less (and crazy-fast) compression library http://blosc.pytables.org/trac
.. PyZMQ ssh doc, by Min Ragan-Kelley, 2011
.. _ssh:
Tunneling PyZMQ Connections with SSH
====================================
.. versionadded:: 2.1.9
You may want to connect ØMQ sockets across machines, or untrusted networks. One common way
to do this is to tunnel the connection via SSH. IPython_ introduced some tools for
tunneling ØMQ connections over ssh in simple cases. These functions have been brought into
pyzmq as :mod:`zmq.ssh` under IPython's BSD license.
PyZMQ will use the shell ssh command via pexpect_ by default, but it also supports
using paramiko_ for tunnels, so it should also work on Windows.
An SSH tunnel has five basic components:
* server : the SSH server through which the tunnel will be created
* remote ip : the IP of the remote machine *as seen from the server*
(remote ip may be, but is not not generally the same machine as server).
* remote port : the port on the remote machine that you want to connect to.
* local ip : the interface on your local machine you want to use (default: 127.0.0.1)
* local port : the local port you want to forward to the remote port (default: high random)
So once you have established the tunnel, connections to ``localip:localport`` will actually
be connections to ``remoteip:remoteport``.
In most cases, you have a zeromq url for a remote machine, but you need to tunnel the
connection through an ssh server. This is
So if you would use this command from the same LAN as the remote machine:
.. sourcecode:: python
sock.connect("tcp://10.0.1.2:5555")
to make the same connection from another machine that is outside the network, but you have
ssh access to a machine ``server`` on the same LAN, you would simply do:
.. sourcecode:: python
from zmq import ssh
ssh.tunnel_connection(sock, "tcp://10.0.1.2:5555", "server")
Note that ``"server"`` can actually be a fully specified ``"user@server:port"`` ssh url.
Since this really just launches a shell command, all your ssh configuration of usernames,
aliases, keys, etc. will be respected. If necessary, :func:`tunnel_connection` does take
arguments for specific passwords, private keys (the ssh ``-i`` option), and non-default
choice of whether to use paramiko.
If you are on the same network as the machine, but it is only listening on localhost, you
can still connect by making the machine itself the server, and using loopback as the
remote ip:
.. sourcecode:: python
from zmq import ssh
ssh.tunnel_connection(sock, "tcp://127.0.0.1:5555", "10.0.1.2")
The :func:`tunnel_connection` function is a simple utility that forwards a random
localhost port to the real destination, and connects a socket to the new local url,
rather than the remote one that wouldn't actually work.
.. seealso::
A short discussion of ssh tunnels: http://www.revsys.com/writings/quicktips/ssh-tunnel.html
.. _IPython: http://ipython.org
.. _pexpect: http://www.noah.org/wiki/pexpect
.. _paramiko: http://www.lag.net/paramiko/
......@@ -241,10 +241,10 @@ class ApiDocWriter(object):
title = ':mod:`' + uri_short + '`'
ad += title + '\n' + self.rst_section_levels[2] * len(title)
if len(classes):
ad += '\nInheritance diagram for ``%s``:\n\n' % uri
ad += '.. inheritance-diagram:: %s \n' % uri
ad += ' :parts: 3\n'
# if len(classes):
# ad += '\nInheritance diagram for ``%s``:\n\n' % uri
# ad += '.. inheritance-diagram:: %s \n' % uri
# ad += ' :parts: 3\n'
ad += '\n.. automodule:: ' + uri + '\n'
ad += '\n.. currentmodule:: ' + uri + '\n'
......@@ -264,7 +264,6 @@ class ApiDocWriter(object):
# must NOT exclude from index to keep cross-refs working
ad += ' :members:\n' \
' :undoc-members:\n' \
' :show-inheritance:\n' \
' :inherited-members:\n' \
'\n'
# skip class.__init__()
......
This diff is collapsed.
......@@ -22,8 +22,10 @@ if [ ! -d gh-pages ]; then
cd ..
fi
echo "updating local gh-pages with html build"
rsync -va build/html/ gh-pages/ --delete --exclude .git || exit -1
rsync -va build/html/ gh-pages/ --delete --exclude .git --exclude .nojekyll || exit -1
cd gh-pages
touch .nojekyll
git add .nojekyll
git add .
git commit -a || exit -1
echo "pushing to remote gh-pages"
......
......@@ -37,10 +37,10 @@ def routine(context):
context = zmq.Context(1)
workers = context.socket(zmq.XREQ)
workers = context.socket(zmq.DEALER)
workers.bind("inproc://workers");
clients = context.socket(zmq.XREP)
clients = context.socket(zmq.DEALER)
clients.bind('tcp://127.0.0.1:5555')
for i in range(10):
......
......@@ -16,7 +16,7 @@ from zmq import devices
ctx = zmq.Context()
dev = devices.ThreadDevice(zmq.FORWARDER, zmq.SUB, zmq.XREQ)
dev = devices.ThreadDevice(zmq.FORWARDER, zmq.SUB, zmq.DEALER)
dev.setsockopt_in(zmq.SUBSCRIBE, "")
dev.connect_in('tcp://127.0.0.1:5555')