My take on a Python module
Posted: 07 Aug 2014, 11:57https://github.com/djsmedes/thepyetribe
I've been working with these trackers for the better part of three months, and after a few different iterations, this is the best way I have come up with for communicating with it.
It uses new-style classes, i.e. inheriting from object, and Python's @property and @property.setter decorators to simplify access to the tracker's attributes.
It uses a HeartThread to send heartbeats. I specifically don't give the thread access to the socket, but instead pass in an anonymous lambda function that, when called, sends the heartbeat. Not terribly important in this case, but I think in general it's a good idea to compartmentalize, if only so that you are not tempted to write more complex and dangerous code.
It uses a ListenerThread to constantly receive data from the socket and put it into a Queue. We split on newlines so that each message the tracker sends is its own item in the Queue, even if they are sent so close together that they pop out of the same socket.recv call. This thread is also passed an anonymous lambda function, lambda: self.socket.recv(BUFSIZE), for reasons similar to the above.
It uses a ProcessorThread to take strings from the raw Queue, parse them into dicts, and put them into an appropriate "EyeTribeQueue" or write them to a file. The parsing is achieved in two stages: first, a string.replace call which turns the C error "-1.#IND" into "null" because Python's json module does not know what to do with that C error. If more things like this are observed, more processing will be done in this stage. The second stage is to call json.loads on the string. We then check a few keys in the dict for certain conditions, which determines whether we write the message to a file, put it in one of the EyeTribeQueues, or notify that certain conditions have changed (i.e. display index). Note that when in push mode, frame data will still have a request of "get," which I am not sure is accurately reflected on the documentation on this website. If that were to change, some changes would need to be made to the logic in this thread.
The EyeTribeQueue inherits from LifoQueue, but replaces the normal Queue.get() method with an error message. Instead, you use the new Queue.get_item(request [, values]) method, which will go through the Queue's underlying data structure (a list in this case, which is why we inherited from LifoQueue instead of just Queue) and pull out the message that has the specified request (and values if the request was "get").
There is only one place in the code where socket.send() is called, but multiple threads could conceivably all be trying to do this simultaneously, so we include a threading.Lock object there.
I would like to thank Edwin Dalmaijer for sharing his code at https://github.com/esdalmaijer/PyTribe. I got the idea of storing the most recent frame as a "current frame" object from him, and probably a lot of other things were inspired by his code as well.
Comments, questions, and critiques welcome!
Cheers,
Daniel Smedema
(MSchulte is not actually me, it's my boss, but he's the one with the account here)
I've been working with these trackers for the better part of three months, and after a few different iterations, this is the best way I have come up with for communicating with it.
It uses new-style classes, i.e. inheriting from object, and Python's @property and @property.setter decorators to simplify access to the tracker's attributes.
It uses a HeartThread to send heartbeats. I specifically don't give the thread access to the socket, but instead pass in an anonymous lambda function that, when called, sends the heartbeat. Not terribly important in this case, but I think in general it's a good idea to compartmentalize, if only so that you are not tempted to write more complex and dangerous code.
It uses a ListenerThread to constantly receive data from the socket and put it into a Queue. We split on newlines so that each message the tracker sends is its own item in the Queue, even if they are sent so close together that they pop out of the same socket.recv call. This thread is also passed an anonymous lambda function, lambda: self.socket.recv(BUFSIZE), for reasons similar to the above.
It uses a ProcessorThread to take strings from the raw Queue, parse them into dicts, and put them into an appropriate "EyeTribeQueue" or write them to a file. The parsing is achieved in two stages: first, a string.replace call which turns the C error "-1.#IND" into "null" because Python's json module does not know what to do with that C error. If more things like this are observed, more processing will be done in this stage. The second stage is to call json.loads on the string. We then check a few keys in the dict for certain conditions, which determines whether we write the message to a file, put it in one of the EyeTribeQueues, or notify that certain conditions have changed (i.e. display index). Note that when in push mode, frame data will still have a request of "get," which I am not sure is accurately reflected on the documentation on this website. If that were to change, some changes would need to be made to the logic in this thread.
The EyeTribeQueue inherits from LifoQueue, but replaces the normal Queue.get() method with an error message. Instead, you use the new Queue.get_item(request [, values]) method, which will go through the Queue's underlying data structure (a list in this case, which is why we inherited from LifoQueue instead of just Queue) and pull out the message that has the specified request (and values if the request was "get").
There is only one place in the code where socket.send() is called, but multiple threads could conceivably all be trying to do this simultaneously, so we include a threading.Lock object there.
I would like to thank Edwin Dalmaijer for sharing his code at https://github.com/esdalmaijer/PyTribe. I got the idea of storing the most recent frame as a "current frame" object from him, and probably a lot of other things were inspired by his code as well.
Comments, questions, and critiques welcome!
Cheers,
Daniel Smedema
(MSchulte is not actually me, it's my boss, but he's the one with the account here)
