[Twisted-Python] txtorcon v0.9.2

2014-04-24 Thread meejah

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I am happy to announce that txtorcon v0.9.2 is now available.

This release adds a few minor bug-fixes and a few API
enhancements. Full details:

 * add on_disconnect callback for TorControlProtocol (no more monkey-patching 
Protocol API)
 * add age() method to Circuit
 * add time_created property to Circuit
 * don't incorrectly listen for NEWDESC events in TorState
 * add .flags dict to track flags in Circuit, Stream
 * build_circuit() can now take hex IDs (as well as Router instances)
 * add unique_name property to Router (returns the hex id, unless Named then 
return name)
 * add location property to Router
 * TorState.close_circuit now takes either a Circuit ID or Circuit instance
 * TorState.close_stream now takes either a Stream ID or Stream instance
 * support both GeoIP API versions
 * more test-coverage
 * small patch from enriquefynn improving tor binary locating
 * strip OK lines in TorControlProtocol 
(https://github.com/meejah/txtorcon/issues/8)
 * use TERM not KILL when Tor launch times out 
(https://github.com/meejah/txtorcon/pull/68) from hellais
 * Unit-test coverage now at 98%

sha256 sums for the distribution files:

93e934f83e3fc6fcf40e76f7c9c28459af04205fb912d384aaacb7ac5269bb8f  
dist/txtorcon-0.9.2-py2-none-any.whl
fe90743cdc453002ad046aa6556b611b4e85b813ff92865769d3d27712c2ca47  
dist/txtorcon-0.9.2.tar.gz

There are also signatures on github and txtorcon.readthedocs.org
You may download from github or the hidden service:

   https://github.com/meejah/txtorcon/releases/tag/v0.9.2
   
https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2-py2-none-any.whl
   
https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2-py2-none-any.whl.asc
   
https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2.tar.gz
   
https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2.tar.gz.asc

   http://timaq4ygg2iegci7.onion/txtorcon-0.9.2.tar.gz
   http://timaq4ygg2iegci7.onion/txtorcon-0.9.2.tar.gz.asc

Source code:

   https://github.com/meejah/txtorcon/archive/v0.9.2.tar.gz

Thanks,
meejah
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJTWVf5AAoJEMJgKAMSgGmn07kIAKSwjBck76dyN1lWJj0fRl/f
BevLpnp+rb+ge5hBAeKfsVTYciDBZeSo8/fE44wTNh5Qj9HEhFopVC4WF61rIFU+
4IkpnFvfmVEd8Iu1vqQ/hFmP1jrvT8T+nTbaTGkcoCSPI+GyXkbxLqcl0Fncq51M
M0OIRphyWA7EK3YoZ2Q1BOEIwsN0pwERYUhU0CGS45L7OZmyw86RXTMBZpBnNXrD
5VjQdpx8fvrV2iCRXi/k/e2Jy/xqs8o0I2+o9M6WrBiGCs5S9YbjsAKzRb7dsaBZ
RlRAdKUjyzkquPl4K8E5ocDToB1hIGvqCSp7s11a5rq5T/jUiDMYrjkxIXH1Yg4=
=W7+f
-END PGP SIGNATURE-


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] txtorcon v0.9.2

2014-04-24 Thread Laurens Van Houtven
Thank you for all your work on this project :)


On Thu, Apr 24, 2014 at 2:27 PM, meejah mee...@meejah.ca wrote:


 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I am happy to announce that txtorcon v0.9.2 is now available.

 This release adds a few minor bug-fixes and a few API
 enhancements. Full details:

  * add on_disconnect callback for TorControlProtocol (no more
 monkey-patching Protocol API)
  * add age() method to Circuit
  * add time_created property to Circuit
  * don't incorrectly listen for NEWDESC events in TorState
  * add .flags dict to track flags in Circuit, Stream
  * build_circuit() can now take hex IDs (as well as Router instances)
  * add unique_name property to Router (returns the hex id, unless Named
 then return name)
  * add location property to Router
  * TorState.close_circuit now takes either a Circuit ID or Circuit instance
  * TorState.close_stream now takes either a Stream ID or Stream instance
  * support both GeoIP API versions
  * more test-coverage
  * small patch from enriquefynn improving tor binary locating
  * strip OK lines in TorControlProtocol (
 https://github.com/meejah/txtorcon/issues/8)
  * use TERM not KILL when Tor launch times out (
 https://github.com/meejah/txtorcon/pull/68) from hellais
  * Unit-test coverage now at 98%

 sha256 sums for the distribution files:

 93e934f83e3fc6fcf40e76f7c9c28459af04205fb912d384aaacb7ac5269bb8f
  dist/txtorcon-0.9.2-py2-none-any.whl
 fe90743cdc453002ad046aa6556b611b4e85b813ff92865769d3d27712c2ca47
  dist/txtorcon-0.9.2.tar.gz

 There are also signatures on github and txtorcon.readthedocs.org
 You may download from github or the hidden service:

https://github.com/meejah/txtorcon/releases/tag/v0.9.2

 https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2-py2-none-any.whl

 https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2-py2-none-any.whl.asc

 https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2.tar.gz

 https://github.com/meejah/txtorcon/releases/download/v0.9.2/txtorcon-0.9.2.tar.gz.asc

http://timaq4ygg2iegci7.onion/txtorcon-0.9.2.tar.gz
http://timaq4ygg2iegci7.onion/txtorcon-0.9.2.tar.gz.asc

 Source code:

https://github.com/meejah/txtorcon/archive/v0.9.2.tar.gz

 Thanks,
 meejah
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iQEcBAEBAgAGBQJTWVf5AAoJEMJgKAMSgGmn07kIAKSwjBck76dyN1lWJj0fRl/f
 BevLpnp+rb+ge5hBAeKfsVTYciDBZeSo8/fE44wTNh5Qj9HEhFopVC4WF61rIFU+
 4IkpnFvfmVEd8Iu1vqQ/hFmP1jrvT8T+nTbaTGkcoCSPI+GyXkbxLqcl0Fncq51M
 M0OIRphyWA7EK3YoZ2Q1BOEIwsN0pwERYUhU0CGS45L7OZmyw86RXTMBZpBnNXrD
 5VjQdpx8fvrV2iCRXi/k/e2Jy/xqs8o0I2+o9M6WrBiGCs5S9YbjsAKzRb7dsaBZ
 RlRAdKUjyzkquPl4K8E5ocDToB1hIGvqCSp7s11a5rq5T/jUiDMYrjkxIXH1Yg4=
 =W7+f
 -END PGP SIGNATURE-


 ___
 Twisted-Python mailing list
 Twisted-Python@twistedmatrix.com
 http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] txtorcon v0.9.2

2014-04-24 Thread Glyph Lefkowitz

On Apr 24, 2014, at 12:27 PM, meejah mee...@meejah.ca wrote:

 I am happy to announce that txtorcon v0.9.2 is now available.

Sadly I still don't know a whole ton about Tor, but this looks really 
full-featured!  Thanks for sharing the release with us.

I particularly liked:

 no more monkey-patching Protocol API

and

 Unit-test coverage now at 98%


;-).

-glyph

smime.p7s
Description: S/MIME cryptographic signature
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


[Twisted-Python] Synchronous @inlineCallback interpreter

2014-04-24 Thread Clayton Daley
I have a modular application that communicates over RPC connections (with
both sync and async server/clients available).  I want to migrate some of
the modules over to Twisted. Currently, all modules inherit important
utility functions from a parent class.  On paper, I now need two versions
of this parent class (synchronous  asynchronous) to be inherited by
modules of the respective types.

I'm looking for ways to maximize the common code between the two versions
of the parent object. One that comes to mind (motivating the subject of
this post) would be to write a synchronous interpreter for @inlineCallback
calls.  For example, here's a synchronous factory function from the parent
class (already partly reconfigured to be friendly to my idea):

@classmethod
def from_id(cls, id):
doc = db.get_document(id) # blocking db call
self = cls._new_document(doc) # synchronous initialization stuff
self.__init__() # module init code is custom and may block
return self

I imagine rewriting this to the following:

@classmethod
@inlineCallbacks
def from_id(cls, id):
doc = yield db.get_document(id) # blocking/async db call
self = cls._new_document(doc) # always synchronous
yield self.__init__() # blocking/async call
returnValue(self)

Assuming the db connector and init function are appropriate to the
environment, my gut reaction is that this could (when combined with a
synchronous implementation of the decorator) run correctly in both places.
I've read that the @inlineCallback code is complicated so I figured I'd run
the idea by the experts before diving down that rabbit hole. Does anyone
see any obvious pitfall? I'm happy to do the legwork to try and build it,
but I'd also welcome any pointers from your (no doubt extensive) experience
writing the twisted version.

Thanks in advance!

Clayton Daley
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] Synchronous @inlineCallback interpreter

2014-04-24 Thread pierre

Le 2014-04-25 01:45, Clayton Daley a écrit :

I imagine rewriting this to the following:

    @classmethod
    @inlineCallbacks
    def from_id(cls, id):
        doc = yield db.get_document(id) # blocking/async db call

        self = cls._new_document(doc) # always synchronous
         yield self.__init__() # blocking/async call
        returnValue(self)

places. I've read that the @inlineCallback code is complicated so I
figured I'd run the idea by the experts before diving down that rabbit
hole.


I am no expert, but the code for inlineCallbacks looks pretty
straightforward, except some special cases handled down the way.


Does anyone see any obvious pitfall? I'm happy to do the legwork
to try and build it, but I'd also welcome any pointers from your (no
doubt extensive) experience writing the twisted version.


I would mostly argue about a semantic problem. inlineCallbacks help
asynchronous code *look* like synchronous code thanks to the sequential
writing. It is however essentially asynchronous and does return a
Deferred.

I do not see any immediate technical pitfall here. I would however be
very careful and double think my design if I were to use Deferred
objects as part of a blocking process.

kaiyou.

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] Synchronous @inlineCallback interpreter

2014-04-24 Thread Clayton Daley
[apologize in advance if this creates threading issues as I picked digests
when I signed up not realizing it would make it difficult to reply to
threads]

Sorry I wasn't more clear.  My thought is to write a version that uses the
same @inlineCallback name and supports the same syntax (to eliminate the
need to rewrite code).  However, I don't mean the synchronous version to
actually use deferreds at all.  All I want the synchronous version to do is
ignore the yields (likely by sending the output right back in after the
block clears)... and treat the returnValue() as a return.

That way code written in the @inlineCallback syntax can be used by a
synchronous or asynchronous consumer.

Clayton Daley


On Thu, Apr 24, 2014 at 8:14 PM, pierre at jaury.eu wrote:


Le 2014-04-25 01:45, Clayton Daley a écrit :
* I imagine rewriting this to the following:
* * @classmethod
** @inlineCallbacks
** def from_id(cls, id):
** doc = yield db.get_document(id) # blocking/async db call
* * self = cls._new_document(doc) # always synchronous
**  yield self.__init__() # blocking/async call
** returnValue(self)
* * places. I've read that the @inlineCallback code is complicated so I
** figured I'd run the idea by the experts before diving down that rabbit
** hole.
*
I am no expert, but the code for inlineCallbacks looks pretty
straightforward, except some special cases handled down the way.

* Does anyone see any obvious pitfall? I'm happy to do the legwork
** to try and build it, but I'd also welcome any pointers from your (no
** doubt extensive) experience writing the twisted version.
*
I would mostly argue about a semantic problem. inlineCallbacks help
asynchronous code *look* like synchronous code thanks to the sequential
writing. It is however essentially asynchronous and does return a
Deferred.

I do not see any immediate technical pitfall here. I would however be
very careful and double think my design if I were to use Deferred
objects as part of a blocking process.

kaiyou.


On Thu, Apr 24, 2014 at 7:45 PM, Clayton Daley clayton.da...@gmail.comwrote:

 I have a modular application that communicates over RPC connections (with
 both sync and async server/clients available).  I want to migrate some of
 the modules over to Twisted. Currently, all modules inherit important
 utility functions from a parent class.  On paper, I now need two versions
 of this parent class (synchronous  asynchronous) to be inherited by
 modules of the respective types.

 I'm looking for ways to maximize the common code between the two versions
 of the parent object. One that comes to mind (motivating the subject of
 this post) would be to write a synchronous interpreter for @inlineCallback
 calls.  For example, here's a synchronous factory function from the parent
 class (already partly reconfigured to be friendly to my idea):

 @classmethod
 def from_id(cls, id):
 doc = db.get_document(id) # blocking db call
 self = cls._new_document(doc) # synchronous initialization stuff
 self.__init__() # module init code is custom and may block
 return self

 I imagine rewriting this to the following:

 @classmethod
 @inlineCallbacks
 def from_id(cls, id):
 doc = yield db.get_document(id) # blocking/async db call
 self = cls._new_document(doc) # always synchronous
 yield self.__init__() # blocking/async call
 returnValue(self)

 Assuming the db connector and init function are appropriate to the
 environment, my gut reaction is that this could (when combined with a
 synchronous implementation of the decorator) run correctly in both places.
 I've read that the @inlineCallback code is complicated so I figured I'd run
 the idea by the experts before diving down that rabbit hole. Does anyone
 see any obvious pitfall? I'm happy to do the legwork to try and build it,
 but I'd also welcome any pointers from your (no doubt extensive) experience
 writing the twisted version.

 Thanks in advance!

 Clayton Daley

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] Synchronous @inlineCallback interpreter

2014-04-24 Thread exarkun

On 24 Apr, 11:45 pm, clayton.da...@gmail.com wrote:
I have a modular application that communicates over RPC connections 
(with
both sync and async server/clients available).  I want to migrate some 
of

the modules over to Twisted. Currently, all modules inherit important
utility functions from a parent class.  On paper, I now need two 
versions

of this parent class (synchronous  asynchronous) to be inherited by
modules of the respective types.


You might find that replacing the subclassing with composition helps 
simplify the code re-use problem.


You may also be interested in https://github.com/radix/synchronous- 
deferred


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python