ctn-archive / nengo_theano

ABANDONED; see https://github.com/nengo/nengo instead
MIT License
3 stars 3 forks source link

Interactive mode visualizer #3

Open studywolf opened 11 years ago

tbekolay commented 11 years ago

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.

tcstewar commented 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.

tbekolay commented 11 years ago

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.

jaberg commented 11 years ago

+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 .

tbekolay commented 11 years ago

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?