Thanks Andrew!
Business hours, Eastern Standard Time (- 5 hrs GMT).
Dave
On Jun 15, 2011, at 8:08 PM, Andrew Bennetts wrote:
> David Shein wrote:
>>Hey Twisted Developers,
>>
>>I'm looking to get a half dozen devs who will commit to being
>> on the
>>Twisted IRC channel next Wed an
David Shein wrote:
>Hey Twisted Developers,
>
>I'm looking to get a half dozen devs who will commit to being on the
>Twisted IRC channel next Wed and Thurs during biz hours to answer noobish
Business hours in which timezone?
-Andrew.
___
On 15 Jun 2011, at 22:19, Glyph Lefkowitz wrote:
> On Jun 15, 2011, at 1:03 PM, Orestis Markou wrote:
>
>> But, for most of the one-shot cases it seems that a ClientCreator (or an
>> endpoint) would serve the same purpose, no?
>
> I am not sure that I understand your message. ClientFactory wi
On 08:24 pm, gl...@twistedmatrix.com wrote:
>On Jun 15, 2011, at 4:08 PM, exar...@twistedmatrix.com wrote:
>>>However, I should note that with the advent of endpoints,
>>>ClientFactory
>>>is no longer necessary. Connection failure is communicated on an
>>>endpoint via the Deferred from connect()
On Jun 15, 2011, at 4:08 PM, exar...@twistedmatrix.com wrote:
>> However, I should note that with the advent of endpoints, ClientFactory
>> is no longer necessary. Connection failure is communicated on an
>> endpoint via the Deferred from connect() errbacking, so there's no need
>> for the ext
Hey Twisted Developers,
I'm looking to get a half dozen devs who will commit to being on the
Twisted IRC channel next Wed and Thurs during biz hours to answer
noobish queries from CS faculty working in an OS environment for the
first time. One group will be working on Twisted bug tickets. A
On 07:19 pm, gl...@twistedmatrix.com wrote:
>On Jun 15, 2011, at 1:03 PM, Orestis Markou wrote:
>>But, for most of the one-shot cases it seems that a ClientCreator (or
>>an endpoint) would serve the same purpose, no?
>
>I am not sure that I understand your message. ClientFactory will be
>re-used
On Jun 15, 2011, at 1:03 PM, Orestis Markou wrote:
> But, for most of the one-shot cases it seems that a ClientCreator (or an
> endpoint) would serve the same purpose, no?
I am not sure that I understand your message. ClientFactory will be re-used if
you re-use it; it won't be re-used if you d
Hello,
I've gotten to the point in my tutorial that I'm giving out examples of writing
clients. Example:
class HTTPGETProtocol(protocol.Protocol):
def connectionMade(self):
self.buffer = []
self.transport.write('GET %s HTTP/1.0\r\n' % self.factory.path)
self.transport
On 05:52 am, an...@iki.fi wrote:
On Tue, Jun 14, 2011 at 9:01 PM, wrote:
We'd be happy to have such a feature officially supported. �Would you
like to work on a patch that adds a tested, documented hook for
selecting the source port?
Perhaps I could work on such a patch. I would be thankful
On Tue, Jun 14, 2011 at 07:37:50PM -0400, Glyph Lefkowitz wrote:
> This is the most important point to take away, and I agree with it. As much
> as
> possible, code should interact with endpoints as parameters. If you need to
> pass something around, pass the endpoint or the service itself, not
On Tue, Jun 14, 2011 at 06:37:45PM -, exar...@twistedmatrix.com wrote:
> To be clear, though, it sounds like you're defining GPS_PORT in a .py
> file, and that's more or less what I was speaking against. :) Instead,
> I would define GPS_PORT as either SerialEndpoint(reactor, "/dev/ttyS2",
>
12 matches
Mail list logo
