Mailman 3 December 2016 - Twisted

[Twisted-Python] New Supported Platforms - FreeBSD (2.7 & 3.5), Python 3.6 (Linux)
by Amber Hawkie Brown Dec. 26, 2016

Dec. 26, 2016

Hi everyone, I just migrated a few buildbots over to the 'supported' column. This includes Python 3.6 on Ubuntu 16.04 (compiled, not an official distro binary :) ) and FreeBSD 10.1 (Python 2.7 & 3.5). Twisted 16.7 passes on both of these, so you can consider them supported platforms for it. - Amber

2 1

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Dec. 25, 2016

Dec. 25, 2016

1 0

[Twisted-Python] twistd and loglevel question
by Jonathan Vanasco Dec. 22, 2016

Dec. 22, 2016

i couldn't find anything in docs/source, but just want to double-check... am i correct that there is nothing in `twistd` that will automatically set the (normal) python logging level based on args/env vars?

2 5

[Twisted-Python] ITransport.write after IProtocol.connectionLost -- no failure/exception?
by exvito here Dec. 20, 2016

Dec. 20, 2016

Dear all, The subject says most of it. While diagnosing a behavior on a somewhat large codebase, I found out something somewhat surprising -- see subject -- which is replicated with the minimal code example below. It is a LineReceiver client that: 1. Connects to 127.0.0.1:10000. 2. Sends a line of text. 3. Disconnects one second later. 4. Tries to send another line of text, one second after disconnection. I expected step 4 to fail somehow, given that Twisted promptly detected that the connection closed and IProtocol.connectionLost was called, as documented. Nevertheless, it does not fail. So the questions are: a) Why does it not fail? I'm sure there is a good reason for that, as most things do in Twisted. b) Does a protocol implementation, like the one in the example, really need to track connectionMade / connectionLost calls before going for self.transport.write? c) Can a protocol implementation, instead, depend on self.transport.connected for which I found no documentation? (I probably missed it, where is it?) Thanks in advance for enlightening me. :-) Regards, -- exvito # --[ cut here ]---------------------------------------------------- from twisted.internet import protocol, reactor, defer from twisted.protocols import basic class ClientAPI(basic.LineReceiver): def _log(self, msg): print('[connected=%r] %s' % (self.transport.connected, msg)) def _send(self, line): self.sendLine(line) self._log('sent: %r' % (line,)) def connectionMade(self): self._log('connection made') self._send('first line') reactor.callLater(1, lambda: self.transport.loseConnection()) def connectionLost(self, reason): self._log('connection lost') reactor.callLater(1, self.postConnectionLostCall) def postConnectionLostCall(self): self._send('post conn lost call - SHOULD FAIL') class ClientFactory(protocol.ClientFactory): protocol = ClientAPI def clientConnectionFailed(self, connector, reason): print 'connection failed -', reason reactor.stop() if __name__ == '__main__': factory = ClientFactory() reactor.connectTCP('127.0.0.1', 10000, factory) reactor.run()

4 6

[Twisted-Python] the right twisted base classes for my project
by elguavas Dec. 19, 2016

Dec. 19, 2016

hi all. i have a project with a networked aspect that i'm thinking of rewriting to use twisted. i'd like to ask for any input on the best twisted functions to base my rewrite on for my usage case, thanks. the project is a fairly simple "games room" that lets a small number of users (from 2 up to a handful, lets say 12 max) join to play simple 2d board games against each other. there is also a general chat among current players function. i originally wrote the networking code for this using python's stdlib asyncore and asynchat modules, implementing a basic rpc-like mechanism to allow clients and server to communicate via simple structured string "messages". i have to say if it was a only bit of a nightmare to code, it was a _lot_ of a nightmare to test and debug... anyway, so i'm rewriting the networking code and looking at twisted and i'd like to make sure i start off using the right parts of twisted for the job right from the beginning. the networking is based on having a server, that maintains central game state and coordinates it among the clients, and clients that connect to the sever to participate in games. the clients need to be able to call functions on the server. the server needs to be able to return data to the clients and also to call functions back on specific clients, or subsets of clients, or all clients. i've had a good look through the twisted docs and i'm thinking that perspective broker is what probably i need, likely along with its avatar functionality. is this a sensible way to go or am i overlooking something obvious? (oh, and a last questionlet would be: if that would be the right parts of twisted to use, what would that buy me above the other possibility i'm considering, which is rewiriting using python's new asyncio stuff?) tia for any replies, stephen.

2 2

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Dec. 18, 2016

Dec. 18, 2016

1 0

[Twisted-Python] buildbot certificate expiration
by Glyph Lefkowitz Dec. 13, 2016

Dec. 13, 2016

Buildbot's HTTPS certificate is expired. This suggests that its txacme auto-renewal has come unglued and fallen off. I'll probably poke at it later today but I figured I'd just send a note first in case someone else happened to know what was up... -glyph

1 0

[Twisted-Python] CI FYI
by Glyph Lefkowitz Dec. 12, 2016

Dec. 12, 2016

Hello Twisted maintainers, I realized today that not not everyone is aware of this quirk in our build infrastructure, and since it's a required step, y'all should probably know about it. Any PR that we merge should run not just on public CI (travis, appveyor, codecov) but also our own Buildbot infrastructure. Many of our supported platforms, particularly desktop Windows and OS X, do not have good support from multi-tenant CI vendors. This has always been true, but recently it became mechanically necessary because the OS X status from buildbot became a required status, which means that it appears in the "waiting" state even if no build has actually been started. No twisted PR will have a successful build unless some TM Labs member has done the following. Since our buildbots do not have adequate security to run totally untrusted code, only project members may submit builds to them. The way a project member submits such a build is they cause a ref to exist in the official Twisted repo's namespace. So, a necessary step in the code review process is to scan the diff to ensure that it's not malicious, and to then ensure that a branch exists in the https://github.com/twisted/twisted/ <https://github.com/twisted/twisted/> namespace pointing at the exact commit that you want buildbot builds to run tests for. (Don't worry: the buildbots are not fully secured, but neither do they contain particularly sensitive data. If you screw this check up, the main potentially bad consequence is to availability of the build fleet, not compromise of PyPI releases or anything like that. That said, if you screw up the security check in the full review and it lands on master, then some really bad stuff can happen...) The way to express this intent to Git is something like: $ git fetch origin "refs/pull/${PR_NUMBER}/head" $ git push origin FETCH_HEAD:"${TICKET_NUMBER}-branchname" I don't know of a way to do it through the github web UI but perhaps someone more knowledgeable could chime in. Thanks, -glyph

1 0

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com Dec. 11, 2016

Dec. 11, 2016

1 0

[Twisted-Python] Spurious commit/ticket links
by Jean-Paul Calderone Dec. 9, 2016

Dec. 9, 2016

Hi, In the last couple days I've noticed that there are a bunch of spurious changes being made to tickets in the issue tracker. These come from commit messages that reference a GitHub PR that happens to match a ticket number in trac. For example, https://twistedmatrix.com/trac/ticket/600#comment:11 I guess this doesn't really hurt anything ... except it's dumping a constant low level of garbage into the issue tracker and generating some annoying emails (that end up having nothing to do with what the subject suggests). Jean-Paul

2 16