bci2000.org BBS

Hi

I encountered issues on Windows 7. I think I managed to solve them, so here are some advices. I am referring to mixing C++ modules and Python modules, not the standalone BCPy2000 distribution (I haven't tried it).

II installed all python packages using the ZIP file with all the installers: http://bci2000.org/downloads/BCPy2000/d ... 100708.zip

1) I suggest to install manually all python installers, instead of using the script INSTALL_ALL.bat. Install them using the compatibility option.

I built BCI2000 from source (v3.0) with Visual C++ Express. From the bci2000/src/contrib/BCPy2000 folder, run Merge.bat which install Python*.exe in the bci2000/prog folder.

2) Go to bci2000/prog. Start Operator.exe. Then for each of the Python*.exe, right click it and choose troubleshoot compatibility, follow the wizard and save the settings.
If you don't do that, you'll get the following error:

Traceback (most recent call last):
File "C:\Python25\Lib\site-packages\BCPy2000\EmbeddedPythonConsole.py", line 4
4, in <module>
win32 = (platform.system().lower() == 'windows')
File "C:\Python25\lib\platform.py", line 1058, in system
return uname()[0]
File "C:\Python25\lib\platform.py", line 977, in uname
system,release,version = _syscmd_ver(system)
File "C:\Python25\lib\platform.py", line 401, in _syscmd_ver
pipe = popen(cmd)
File "C:\Python25\lib\platform.py", line 356, in popen
return popen(cmd,mode)
pywintypes.error: (2, 'CreateProcess', 'The system cannot find the file specified.')

It is then possible to use BCPy2000 modules properly.


Brice

Thanks for the feedback, Brice.

File "C:\Python25\lib\platform.py", line 356, in popen
return popen(cmd,mode)
pywintypes.error: (2, 'CreateProcess', 'The system cannot find the file specified.')

Presumably this a 64-bit issue rather than Windows 7 per se. That's pure, core Python functionality that's failing there.

I suggest to install manually all python installers, instead of using the script INSTALL_ALL.bat. Install them using the compatibility option.

I guess that old 2.5.4 msi installer only contains 32-bit code. Installing Python and the third-party packages from source may be the way to go for full 64-bit compatibility and best performance.

...or there's this:

http://downloads.activestate.com/Active ... ywin32.msi

...but who knows how well the other third-party packages will support this.

Unfortunately I have no opportunity to test 64-bit Windows right now. Your Mileage Will Almost Certainly Vary.

I was unable to find all of the dependencies/third-party packages required by BCPy2000http://bci2000.org/downloads/BCPy2000/P ... kages.html for Python2.5 in WIN64. However, I did find them allhttp://www.lfd.uci.edu/~gohlke/pythonlibs/ for Python2.6. The only problem with this was that I was unable to get BCPy2000 to recognize the Python2.6 dll. If the dll was in the path (in the same path or in the system path) it was not detected. When I specified the dll as a command-line option to the Python*.exe modules (e.g., --PythonSigDll=python26.dll) then it generated an error My reason for trying to go this route, instead of using BCPy2000 full-monty which works fine on its own, is because I couldn't get it to play with other source modules, one of them 64-bit. I thought a solution would be to use a 64-bit Python install instead of a 32-bit one but I was not successful as mentioned above.

I thought the above error is due to 64-bit Python dll and 32-bit BCPy2000. I thought a solution might be to compile BCPy2000 for 64-bit. While I was able to compile the Source and SignalProcessing modules, I could not compile the application module which is the most important. The modules that do compile complain about not finding the Python install when they are used in place of the full-monty. When I set the PYTHONHOME and IPYTHONDIR environment variables to use the 64-bit Python installation, then a different set of errors are generated that I don't fully understand. Anyway, I don't plan on spending any more time on this because my specific problem is solved.

Please update your BCI2000 source code to the latest version. You should now be able to compile the application module.

In principle Python-under-32-bit should be able to talk to other (non-Python) BCI2000 modules that are 64 bit. Modules talk to each other over a network protocol, so differences in architecture or even OS should not be critical at module boundaries. What you seem to have hit is a bug in the 20110710 release versions of Python*.exe that made them incompatible with some versions of other modules (where now "version" means version of the BCI2000 source itself).

I'll get a re-release of the Python binaries as soon as I can. Meanwhile, rebuilding either the 32-bit Python*.exe binaries from up-to-date sources, as Jürgen says, or possibly even rebuilding the other modules from up-to-date sources, should re-establish communication between everything and everything else, and allow you to use the 32-bit Full Monty again.

Getting everything working on 64-bit Python and python26 is, however, also a worthy goal. If you say (watch the case sensitivity of the bit before the "=" ) and python26.dll is on the system PATH, or if you say and you still get "failed to load..." then could it perhaps be a case of a 32-bit executable trying to load a 64-bit DLL?

jhill wrote:In principle Python-under-32-bit should be able to talk to other (non-Python) BCI2000 modules that are 64 bit. Modules talk to each other over a network protocol, so differences in architecture or even OS should not be critical at module boundaries. What you seem to have hit is a bug in the 20110710 release versions of Python*.exe that made them incompatible with some versions of other modules (where now "version" means version of the BCI2000 source itself).

I'll get a re-release of the Python binaries as soon as I can. Meanwhile, rebuilding either the 32-bit Python*.exe binaries from up-to-date sources, as Jürgen says, or possibly even rebuilding the other modules from up-to-date sources, should re-establish communication between everything and everything else, and allow you to use the 32-bit Full Monty again.

Admittedly I haven't tried to cross-compile anything in 32-bit. I guess I was running in to version-compatibility bugs while simultaneously running into 64-bit specific bugs and confounded the two.

jhill wrote: Getting everything working on 64-bit Python and python26 is, however, also a worthy goal. If you say

Code: Select all

start PythonSignalProcessing --PythonSigDLL=python26

(watch the case sensitivity of the bit before the "=" ) and python26.dll is on the system PATH, or if you say

Code: Select all

start PythonSignalProcessing --PythonSigDLL=C:\correct\absolute\path\to\python26.dll

and you still get "failed to load..." then could it perhaps be a case of a 32-bit executable trying to load a 64-bit DLL?

I think you are right, because I got these errors when I was using a 64-bit executable trying to load a 32-bit DLL or using a 32-bit executable trying to load a 64-bit DLL.
When I combined 64-bit executables with 64-bit Python then I received different errors entirely. They seemed to be related to IPython. I don't really have time to recreate the error though, sorry.