percyliang
commented
7 years ago Ok, that's fine. Maybe we should add these to our dataset generation process for consistency...
On Wed, Oct 19, 2016 at 1:54 AM, anushabala notifications@github.com wrote:
@anushabala commented on this pull request.
In src/basic/event.py https://github.com/stanfordnlp/game-dialogue/pull/15:
@@ -15,3 +15,19 @@ def from_dict(raw): return Event(raw['agent'], raw['time'], raw['action'], raw['data']) def to_dict(self): return {'agent': self.agent, 'time': self.time, 'action': self.action, 'data': self.data} +
- @staticmethod
- def MessageEvent(agent, data, time=None):
- return Event(agent, time, 'message', data) +
- @staticmethod
- def SelectionEvent(agent, data, time=None):
- return Event(agent, time, 'select', data) +
- @staticmethod
- def JoinEvent(agent, userid=None, time=None):
I'm just working on removing socketio completely and realized that we still need to keep these around, because now that we can no longer use the socketio functionality to send messages, we need to send messages like "your friend has joined the room" as events (when we were still using socketio we just emitted the messages)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stanfordnlp/game-dialogue/pull/15, or mute the thread https://github.com/notifications/unsubscribe-auth/AAakuJUqYgNtY8BmWLPKIr_BSc1U_KiZks5q1dq8gaJpZM4KVmED .
Code dump for all the website code. @hhexiy, this also includes the changes that you made to NeuralSession etc. (they were on the system branch, which I've been working off of, so those commits are here too).
Includes code to add HumanSessions that can be used with the Controller (this same setup can later be used for a command line chat interface). @percyliang, I've left out the multithreading as we discussed it for now, because sharing objects across processes turned out to be really complicated; specifically each Controller object contains a list of sessions, and since a list by itself isn't thread-safe, Python forks the list and duplicates the sessions in the list so that they can be used in the background process). This means that any updates we make (by calling send() on the sessions) don't actually reach the background process.. The workarounds for this look fairly complicated, so as of now, the Controller has a step() function that's called anytime the client sends information to the server (which is really the only time step() needs to be called anyway.)
@mihail911
I'm trying to get the website up on the cwc machine right now, but I'm getting a segmentation fault.. I'm trying to increase the stack size but not sure if that's the right solution.