vaibhavreddys / scipy-sim Goto Github PK

What steps will reproduce the problem?
1. install scipy-sim on a host that does not have pygame installed
2. run 'python test_scipysim.py'

What is the expected output? What do you see instead?

Expect to see passing tests. Instead see 

ERROR: Parse the actors directory and create code group
...scipy-sim/simple_controller_vis/src/scipysim/actors/io/VideoSnapshot.py", 
line
20, in <module>
    import pygame
ImportError: No module named pygame


While I don't have a problem with some modules have external dependencies,
I don't think that those dependencies should be critical to allowing the
system to run.

The current version of the GUI assumes that there is only a single actor per 
file, and that the actor has a name similar to the file it is contained in. 
That seems a little restrictive, especially where we have multiple related 
actors (e.g. summers or integrators that are all just variations on a theme). 

Several actors treat events as mutable, modifying an input event to produce
an output event. This is a bad idea (both in general, and in particualr in
a multi-threaded context). Events should be immutable values once they are
constructed. All actors should be revised to treat them that way.

We should probably also consider moving from using dictionaries as events
to having an Event object of some kind. That would make construction
explicit, allow us to enforce immutability, and make it easier to add extra
information to events later if we want to.  

Purpose of code changes on this branch:
Need to decide whether multiple domains of computation are really feasible 
with one set of non-directed actors.

Need to address possible problems involved with always blocking on all input 
queues sequentially - works fine for synchronised signals, but will clearly 
cause the output to rely on the rate of the least frequent signal.

Please see my notes on lines 56-68 of summer.py for more musings.

What steps will reproduce the problem?
1. clone scipy-sim on a new host
2. execute 'python test_scipysim.py'

Expect to see successful test execution, but instead get IOError exceptions:

----
$ python test_scipysim.py 
........Exception in thread Thread-12:
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/threading.py",
line 525, in __bootstrap_inner
    self.run()
  File
"/Users/aim/Documents/Code/scipy-sim/simple_controller_vis/src/scipysim/actors/c
ore/actor.py",
line 94, in run
    self.process()
  File
"/Users/aim/Documents/Code/scipy-sim/simple_controller_vis/src/scipysim/actors/i
o/writer.py",
line 32, in process
    self.write_file()bb
  File
"/Users/aim/Documents/Code/scipy-sim/simple_controller_vis/src/scipysim/actors/i
o/writer.py",
line 47, in write_file
    numpy.save(self.filename, x)
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/n
umpy/lib/io.py",
line 236, in save
    fid = open(file, "wb")
IOError: [Errno 2] No such file or directory:
'/Users/brianthorne/temp/numpy_test_data.npy'
----

The problem appears to be hardcoded absolute filenames in
src/scipysim/actors/io/test_io.py. Specifically,
FileIOTests.test_file_read() includes the path
'/Users/brianthorne/temp/numpy_test_data.npy', and at the top level we have
the definition PATH_TO_THIS_FILE =
'/Volumes/Share/Dev/scipy-sim/simple_controller_vis/src/scipysim/actors/io/test_
io.py'.

What steps will reproduce the problem?
1. Run the trajectory.py example model
2. Wait

What is the expected output? 

  Expect to see both the velocity and displacement graphs plotted

What do you see instead?

  See velocity, but while the displacement window appears no data is plotted. 

Things seem to work ok if everything is plotted in one figure
(own_fig=False for both Plotter actors). 

I think that it's worth considering converting actor.py and the other core
classes of scipysim from using the threading library to using the
multiprocessing library
[http://docs.python.org/dev/library/multiprocessing.html]. Doing so seems
like it'd bring several advantages:

 1. It would allow us to avoid the performance problems associated with the
Global Interpreter Lock, which is likely to become a problem as we move to
larger models.

 2. It would put us in a position to take advantage of multicore systems,
which is nominally one of the benefits of using the "directorless" style
that we've adopted (and seems likely to be increasingly important in coming
years).

 3. It appears that it might resolve the threading problems that we
previously ran into with matplotlib, allowing us to implement real-time
plotting.

Since we already require Python >= 2.6 for other reasons I don't see any
problems with version compatibility. The only obvious drawback I can see at
this point is that the multiprocessing library apparently suffers from low
performance on Windows (which seems to have fairly heavyweight processes).
Perhaps we could consider having actors (and the display) revert to the
current threaded implementation when running on Windows.