> I was thinking about this a little last week -- it would certainly be
> nice to abstract more of the "general parsing stuff".
We plan to put most of the parsing stuff into the stem.response
module, which txtorcon could use without touching any of the threading
stuff. For example...
https://gitw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Damian Johnson writes:
>> (If this type of mail isn't appropriate for tor-dev please let me
>> know...)
> On a side note, do you think that any txtorcon/stem work would be
> appropriate? They're both aiming to be a library that does largely
> the sa
> It seems to me that within the Tor community, for everything that's not
> the "tor core c code", there's a lot of duplication, duplicated code
> around or abbandoned projects.
We do have quite a few abandoned projects, though the core codebase
certainly isn't the only one that's actively maintai
On 6/1/12 8:45 PM, Damian Johnson wrote:
>> (If this type of mail isn't appropriate for tor-dev please let me
>> know...)
>
> It's perfectly appropriate - glad to hear about the improvements!
>
> On a side note, do you think that any txtorcon/stem work would be
> appropriate? They're both aiming
> (If this type of mail isn't appropriate for tor-dev please let me
> know...)
It's perfectly appropriate - glad to hear about the improvements!
On a side note, do you think that any txtorcon/stem work would be
appropriate? They're both aiming to be a library that does largely the
same things. Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have tagged txtorcon 0.2, which adds:
. incremental parsing;
. faster TorState startup;
. SAFECOOKIE support;
. several bug fixes;
. options to circuit_failure_rates.py example to make it actually-useful;
. include built documentation + sourc
