Open studywolf opened 11 years ago
I completely agree with decoupling from the simulation, and I think the idea about reading from log files in memory is definitely a way to go on that, although we do also still need the ability to go the other way around (for when we adjust input sliders).
If we wanted to get real fancy, we could do logging to a socket, and then it just might be feasible to use the same interactive visualizer for Nengo and for nef-thenao...... But that might be more trouble than it's worth.
Ah right, going the other way... Logging to a sockets sounds good, and might be one possible way to get a start at making simulations easy to run through other processes, or other machines (i.e., send the spikes of one population over the socket). But yeah, that kind of thing would be a bidirectional connection, just as the interactive viewer should be.
+1 (or more if I could)
Reading and writing state to sockets probably enforces good architectural decisions even if the socket code itself doesn't end up being used right away. Interaction with RL-glue and/or robotics middleware probably require similar design.
On Wed, Mar 13, 2013 at 2:55 PM, Trevor Bekolay notifications@github.comwrote:
Ah right, going the other way... Logging to a sockets sounds good, and might be one possible way to get a start at making simulations easy to run through other processes, or other machines (i.e., send the spikes of one population over the socket). But yeah, that kind of thing would be a bidirectional connection, just as the interactive viewer should be.
— Reply to this email directly or view it on GitHubhttps://github.com/ctn-waterloo/nef-py/issues/3#issuecomment-14861496 .
Question that hopefully someone knows the answer to: Python has socket interface code in the standard library, but a lot of recent success stories of programs that do concurrency through sockets use zero-mq. Is it worth introducing the zero-mq dependency to make socket programming easier / more robust?
It would be nice to decouple this from the simulation entirely, by having it read log files instead of directly running the simulation. If we implement logging directly to memory, then there should be no additional overhead in architecting things this way.
The real question is what graphical framework do we want to use for interactive mode in Python? My vote is to investigate guiqwt, which is what Spyke Viewer uses to plot data. Of course, it might be possible to just use Spyke Viewer directly, which would give us a ton of powerful analysis tools already written.