bci2000.org BBS

Hello,

I am wondering if anybody can report their experiences with setting up BCPy2000 with Python 2.7.3.

Let me preface this message by saying I have read through the other BBS threads on getting BCPy working without the FullMonty configuration (I was able to get FullMonty working right out of the box).

There are a few things that have been confusing to me at different stages of the compilation process. I am aiming for a Win32 build and am utilizing Windows 7 64-bit. I have made sure that my portable.bat is pointing to my Python27 directory.

1. Using MSVC++2008 (in 32-bit, Release mode) to build the "foundation" modules. I notice that many other libraries are required to execute PythonSource.exe etc, such as opencv_core220.dll and a few others. These libraries were not present in the FullMonty build. Am I compiling incorrectly, or is this to be expected?

2. I have read warnings about Python 2.7 causing problems with the 3rd party libraries related to visionegg and its dependencies -- however I am actually having difficulties even loading up PythonSource.exe which should only rely on the BCPy2000 framework. IPython 0.10 embedded terminal functionality is incompatible with Python 2.7.3; and EmbeddedPythonConsole.py from the framework has not been modified to work with IPython 0.13 (the latest version compatible with python 2.7). Has anybody tackled this issue?

If anybody has suggestions on safe practices to get this to work with Python 2.7, I'd really appreciate it. There are a few modules available on Python 2.7 that I'd like to use for visualization and analysis.

Thanks,
Ankit

Just last week I tried and failed to do exactly what you are doing.

I wrote up an e-mail to Jeremy Hill about it. I'm not an expert at any of this stuff, but maybe together we can find a solution. Here is the (trimmed) contents of the mail I sent him:

When using BCPy2000 + IPython 0.13 with pyreadline 1.7 or 2.0, IPython imports pyreadline which then imports all of its own modules. While doing so, it raises an error (pasted below). Importing pyreadline and the problematic modules from a regular IPython console works fine.

Code: Select all

Traceback (most recent call last):
  File "C:\Python27\lib\site-packages\BCPy2000\EmbeddedPythonConsole.py", line 227, in <module>
    ReplaceStreams()
  File "C:\Python27\lib\site-packages\BCPy2000\EmbeddedPythonConsole.py", line 105, in ReplaceStreams
    import pyreadline
  File "C:\Python27\lib\site-packages\pyreadline\__init__.py", line 11, in <module>
    from . import unicode_helper, logger, clipboard, lineeditor, modes, console
  File "C:\Python27\lib\site-packages\pyreadline\console\__init__.py", line 15, in <module>
    from .console import *
  File "C:\Python27\lib\site-packages\pyreadline\console\console.py", line 21, in <module>
    import pyreadline.unicode_helper as unicode_helper
AttributeError: 'module' object has no attribute 'unicode_helper'

Sometimes the last part of the error would look like this:

Code: Select all

File "C:\Python26\lib\site-packages\pyreadline\console\console.py", line 605, in <module>
  msvcrt = cdll.LoadLibrary(ctypes.util.find_msvcrt())
File "C:\Python26\Lib\ctypes\__init__.py", line 431, in LoadLibrary
  return self._dlltype(name)
File "C:\Python26\Lib\ctypes\__init__.py", line 353, in __init__
  self._handle = _dlopen(self._name, mode)
WindowsError: [Error 126] The specified module could not be found

When using pyreadline 1.5, IPython tries to access some pyreadline modules/attributes that do not exist, so pyreadline 1.5 + IPython 0.13 is a non-starter.

After going back to 2.6 with IPython 0.10.2 and pyreadline 1.5, I had trouble getting the right combination of VisionEgg and PyOpenGL.
According to this page http://bci2000.org/downloads/BCPy2000/Renderers.html , openGL/visionegg-independent renderers were considered. Is that dead?

I've attached some modifications that I made to EmbeddedPythonConsole.py while testing this out. I think I've found appropriate replacements for most of the old IPython attributes/calls, except for the ones near the bottom because I hadn't quite made it there. I tried to make the replacements as simple and obvious as possible at the expense of elegant code. Some replacements I just guessed at.

However, since the newer IPython gets rid of the need for some of the hacks you had to program in EmbeddedPythonConsole, I think a better approach might be to split the code a little higher-up. If you agree, how would you recommend doing that?

I attached that code here.

I didn't try recompiling BCPy2000 again. It might be necessary to link BCPy2000 with a different and newer library before compiling and that might be the reason for the pyreadline errors.

Some other links you might find useful:
http://www.lfd.uci.edu/~gohlke/pythonlibs/
http://wiki.ipython.org/Cookbook/Updati ... n_for_0.11

Thanks for the helpful code and comments.

In fact, I made similar changes to EmbeddedPythonConsole.Py for use with pyreadline 1.7.1 and IPython 0.13 to no avail. One suggestion for your code is to remove the closed parentheses () next to InteractiveShellEmbed in the Shell function. The shell function is called from Generic.py in _enable_shell() and only need the reference to the module rather then calling the actual InteractiveShellEmbed function. This got me through the runtime a bit further but I ended up with a blank Console (no errors) with no indication that IPython had successfully loaded etc.

It seems to me that the MS console that Bci2000 opens up in PythonSource.exe is not being attached with IPython through pyreadline. I've been reading up on it but have not found any useful tips.

One question I have is how did you manage to get debug feedback that pyreadline was incorrectly being loaded? As I mentioned my win console instances are not connecting to IPython so I have been relying on Errors that pop up in the bci2000 message box.


However, I was able to get full functionality (minus pyopengl and vision egg) using IPython 0.10.2 and Pyreadline 1.5 on win 7 64bit. The main change here is to update the IPython/external/path.py to the path.py from IPython 0.13. This bug is documented here: http://code.google.com/p/spyderlib/issues/detail?id=989



Ankit

I was finally able to get a basic instance of BCPy2000 running on Win 7 64-bit using Python 2.7.3.

I cannot claim that the included example batch files work (there are dependency issues external to the BCPy2000 framework with visionegg, opengl, etc. that have been reported elsewhere).
I tested using the basic BciSource.py, BciApplication.py, BciSignalProcessing.py.

Here is how I did it:
1. I am using BCPy2000-41450, IPython 0.13, pyreadline 2.0_dev1 for the embedded console work.
2. I fixed a minor bug in user "boulay"s modified \site-packages\BCPy2000\EmbeddedPythonConsole.py (the version I have attached here includes the fix).
3. Made a change to pyreadline\console\console.py (Line 606) => should become: The ctypes module included with Python 2.7.3 does not have a find_msvcrt() function. This is a temporary fix and I will file a bug with pyreadline developers.

akhambhati wrote: In fact, I made similar changes to EmbeddedPythonConsole.Py for use with pyreadline 1.7.1 and IPython 0.13 to no avail. One suggestion for your code is to remove the closed parentheses () next to InteractiveShellEmbed in the Shell function. The shell function is called from Generic.py in _enable_shell() and only need the reference to the module rather then calling the actual InteractiveShellEmbed function. This got me through the runtime a bit further but I ended up with a blank Console (no errors) with no indication that IPython had successfully loaded etc.

Thanks for the tip. I'll give it a try next week (Monday is a holiday here, so maybe Tuesday).

akhambhati wrote: One question I have is how did you manage to get debug feedback that pyreadline was incorrectly being loaded? As I mentioned my win console instances are not connecting to IPython so I have been relying on Errors that pop up in the bci2000 message box.

I encountered several different debug oddities. Sometimes I got coloured text (yay!), but sometimes I just got the escaped color codes intermixed with the text. Sometimes I just got plain B&W text. I can't remember the exact circumstances leading to each condition. I don't think, however, that I was ever without the console.

akhambhati wrote: However, I was able to get full functionality (minus pyopengl and vision egg) using IPython 0.10.2 and Pyreadline 1.5 on win 7 64bit. The main change here is to update the IPython/external/path.py to the path.py from IPython 0.13. This bug is documented here: http://code.google.com/p/spyderlib/issues/detail?id=989

Good find. Though I am also on Win7 x86-64, I have some hardware that only has a 32-bit dll that I wrote a ctypes wrapper for. I won't be joining you on getting 64-bit Python working. However, I don't think the problems you are encountering with pyopengl and vision egg are due to using 64-bit Python, but probably due to incompatible versions of the packages. I encounter similar problems in 32-bit Python (2.6.4, I think) unless I use the exact right versions of pyopengl and vision egg. In my previous post I linked to a page where the BCPy2000 developers (presumably Jez) mentioned that they are trying to get away from vision egg. This is probably a good idea because vision egg hasn't been updated in years. Maybe PsychoPy.visual would be a good alternative to VIsionEgg.

Thanks for your work on EmbeddedPythonConsole. Those two links of Chad's are particularly useful. I'm afraid I haven't been able to test your efforts yet (beyond confirming its backward-compatibility with Python 2.6 and IPython 0.10) since I have limited access to Win64 distributions and limited time for playing with new Python 2.7 installations. Please let me know how it goes. Sooner or later there will probably have to be an updated (probably Python-2.7-based) FullMonty.

Re: opencv dlls. These are used by Adam Wilson's WebcamLogger, which is an optional extension. It, will be linked into your SignalSource framework library (and hence in all source modules you build, including PythonSource) if you answer "yes" when CMake asks you whether you want that particular extension. If you say yes to extensions that require DLLs, then you need to carry those DLLs around with you. You'll find them somewhere in /src/extlib/opencv/lib

Re: renderers. There is now a reasonably fully-featured PygameRenderer, so-called because it requires pygame but not OpenGL or VisionEgg. To use it, you just say import PygameRenderer at the top of your BciApplication.py file. It's interchangeable with VisionEggRenderer in the sense that the most frequently-needed stimulus classes are abstracted, and available with renderer-agnostic names:
In VisionEggRenderer, these are just new names for standard VisionEgg classes, whereas in PygameRenderer they're new implementations with mostly-visionegg-compatible (but actually slightly more flexible and mutually consistent) programming interfaces.

The big downside to PygameRenderer is that it's CPU-intensive. It just seems to burn a lot of CPU cycles blitting things. How VisionEgg avoids this, I don't know (perhaps by taking advantage of hardware acceleration via OpenGL?) But I know that Andrew Straw (author of VisionEgg) spent many years optimizing timing performance and that the rest of us are unlikely to have time to reinvent all those wheels. Burdensome though such third-party dependencies are, I don't see a reasonable way to avoid them. If anyone's interested in improving the performance of the PygameRenderer, or in using it as a template for alternative renderers based on pyglet or Psychopy or whatever, then I'd be very grateful.