ad. I'm really sorry for the confusion I'm causing. On the bright side, I
now understand the problem. Sorry, folks.
On Thu, Aug 17, 2017 at 5:14 AM Jean-Paul Calderone <
exar...@twistedmatrix.com> wrote:
> On Thu, Aug 17, 2017 at 1:35 AM, Kevin Conway
> wrote:
>
>&g
received?
On Wed, Aug 16, 2017 at 9:03 PM Kevin Conway
wrote:
> > There is no datagram endpoints API as yet, though (see #4471), only
> stream endpoints.
>
> I'm not sure I understand the distinction. Endpoints supports UDP which is
> a datagram based transport. From a
concept I'm your data
format then it should be handled there.
What am I not understanding about this particular use case?
On Wed, Aug 16, 2017, 16:25 Jean-Paul Calderone
wrote:
> On Wed, Aug 16, 2017 at 9:59 AM, Tristan Seligmann <
> mithra...@mithrandi.net> wrote:
>
>>
Maybe I misunderstand the issue, but I believe the Endpoints API solves for
this. https://twistedmatrix.com/documents/16.4.1/core/howto/endpoints.html
This abstracts the transport and allows you to focus on only interpreting
the bytes transmitted over that transport by defining a Protocol and a
Fa
> What are you referring to as a "coroutine" here? A generator?
Generator, yes, but used as a coroutine that both emits values and receives
them. The introduction of dedicated coroutines in Python 3.5 is something I
haven't updated my personal language for very well. Generator-coroutine is
the te
;re not using PyPy?
We're still on cPython. PyPy is something we've talked about before but
haven't invested much time into yet. I don't know to what extent PyPy might
change the performance characteristics of the project.
On Tue, Oct 18, 2016 at 7:50 PM Glyph Lefkowitz
> This is why twisted.python.context came to exist in the first place; I
always wanted to attach it to Deferred somehow
Well, it's not something we've announced yet through any official channel,
but we had to solve the context propagation problem at Atlassian to
instrument our services with tracea
> we can just look up until the first ':'; we just need to define a new
interface for a new syntax.
What do you think of adding a special argument for endpoint strings called
"wraps" or "pipe" that tells the parser to recombine the right-hand side
and send it back through the parser? For example:
> However, it’s worth highlighting that endpoints are inches away from
being a really powerful composable tool for saying “tunnel this protocol
over this other protocol”.
I'm not sure if this is the same concern as the OP. What you've described
is mixing the ideas of composing protocols and compos
I'm not opposed to a fresh syntax, but I do believe the current
implementation can be used for composition. The parser for endpoint strings
is simplistic, like Glyph points out, but there is nothing preventing it
from having nested endpoint definitions. We used the existing syntax when
writing the
> The reverse mechanism of sending twisted.logger's output to the
> standard library is of course handled by the
> twisted.logger.STDLibLogObserver (and similar in twisted legacy
> logging) but the documentation for this even suggests why this is a
> bad idea: 'Warning: specific logging configurati
Thanks, glyph, for the correction. Also, thanks for reminding me that I'm
still living in twisted's past...
On Sat, May 7, 2016, 17:33 Glyph wrote:
>
> On May 7, 2016, at 12:19 PM, Kevin Conway
> wrote:
>
> I'm still working through your code example and trying t
I'm still working through your code example and trying to get a better
grasp of what, exactly, you're trying to implement as far as client
behavior is concerned. In the meantime, it sounds, on the surface, like you
are trying to implement a form of the ReconnectingClientFactory:
http://twistedmatri
Hi Chris,
tl;dr: Returning a value from 'dataReceived', or any of its extensions such
as 'lineReceived' in the 'LineReceiver' Protocol subclass, triggers a
disconnect and uses the returned value as the 'reason'. A 'reason' must be
an Exception or t.p.Failure object as other values will trigger thi
14 matches
Mail list logo
