test installation about eeg-expy

[Elisabeth-github]

Hello, thank you for your efforts on this interesting project. I encounter the installation issue mentioned in the attached file. Thanks in advance for your help.
elisabeth_2020-12-02.txt

[adaley222]

I received what might be a related error to Elisabeth. We both have the error:

No module named 'numpy.distutils._msvccompiler' in numpy.distutils;

My problem seems to be a problem with the wheels for pywinhook, scikit-learn, tables, and numexpr.

The pywinhook error reads:

error: command 'swig.exe' failed: None

For scikit-learn the error reads:

error: could not create 'build\bdist.win-amd64\wheel\.\sklearn\datasets\tests\data\openml\292\api-v1-json-data-list-data_name-australian-limit-2-data_version-1-status-deactivated.json.gz': No such file or directory

The issues with tables and numexpr seems to be numpy related (no module named numpy), which may be related to the failed pywinhook or scikit-learn installs. However, my build for the numpy wheel appears to have been successful.

I'm using Windows 10 Home Version 10.0.18363 Build 18363. I've built a fresh conda env as suggested in the docs. I'm running the commands from a conda prompt.

A txt file with the error is attached as well.

adaley_error_eegnotebooks.txt

[verakye]

what Python version are you using?
I also encountered the numpy issue with Python 3.9. Switching to Python 3.7 solved the problem for me.

For newbs like me:
I changed it like this in the consol's installation process (Link to the installation process description I am refering: https://neurotechx.github.io/eeg-notebooks/getting_started/installation.html):
conda create -n "eegnb" python=3.7

I kept the rest of the installation steps as described in the documentation (only using eegnb instead of eeg-notebooks):

conda activae "eegnb"
conda install git
conda install pip

Subsequently using the following did the rest of the installation (make sure you are inside the eeg-notbook folder):
pip install -e .

[adaley222]

Ahh, yes I had been using 3.9, but was able to successfully install with 3.7. Apologies, should have mentioned that.

I also tried with 3.8 to see how it went, which solved the issues with numpy/numexpr/scikit-learn, but still ran into the pywinhook error.

[JohnGriffiths]

Thanks for this - @verakye gave the correct answer: need to set python version to 3.7 when creating the conda env.

Have added this to the instructions.

[ErikBjare]

#32 fixes the pywinhook-related build issues for Python 3.7-3.8 by using prebuilt wheels.

[ErikBjare]

@JohnGriffiths I'm not sure where you updated the instructions, but I made a PR with the same change: #51

I also expanded #32 to also fix issues with Python 3.8 (and 3.9, on Linux at least)

[rmib200]

Hey! Great effort on this amazing project. I encountered an issue while running the experiments. I tried running the n170 and p300 with a ganglion board but when running the [experiment].present() line of code for presenting the experiment, nothing happens. Except that the screen is frozen, 2 black windows appears and only when I stop the kernel from the jupyter notebook the black windows can be closed. I'm using Win10 and python 3.7.9.
The only warning I get is this:
d:\ProgramData\Anaconda3\envs\eeg-notebooks\lib\site-packages\pyglet\media\codecs\wmf.py:838: UserWarning: [WinError -2147417850] No se puede cambiar el modo de subproceso después de establecerlo
warnings.warn(str(err))

[oreHGA]

Hi @rmib200 , out of curiosity, do you have a single display or multiple external monitors connected to your machine?

I think I may have encountered a similar issue when my laptop was connected to 2 external displays. Switching to running on just my laptop (1 display) fixed it for me - (although I used a different BCI headset).

[rmib200]

@oreHGA I tried with a single display (I use 2, but disconnected the second to do a test) and it was worse because I could no longer stop the kernel. The whole screen was unresponsible. What headset where you using? Besides, I tried eeg notebooks before, around dicember 2020 and it worked fine (with 2 screens, the one in my laptop was showing the stimuli), until I updated my python to 3.9 and had a lot of problems. I resinstaled eegnb with a 3.7 version now but I got this issue.

[oreHGA]

I use the Neurosity Notion 2. I can try to re-run the experiment locally sometime this week to see if I can reproduce your issue on the on a fresh install with a similar env. setup.

cc’ing @JohnGriffiths (or anyone who can test with a ganglion board) to see if it’s a known issue

[rmib200]

@oreHGA By the way, I just tried removing the env altogether, reinstalling it and got the same result. I also tried with my muse S, and still blank screen.

[rmib200]

@oreHGA I think I might have found a way around. I reorganized my screens so the 2nd screen is now the default screen and my laptop is the secondary. I was able to run the experiment with both my devices.
I got this messages:
d:\programdata\anaconda3\envs\eeg-notebooks\lib\site-packages\pyglet\image\codecs\wic.py:289: UserWarning: [WinError -2147417850] No se puede cambiar el modo de subproceso después de establecerlo
warnings.warn(str(err))
10.0256 WARNING User requested fullscreen with size [1600 900], but screen is actually [1366, 768]. Using actual size
11.2558 WARNING User requested fullscreen with size [1600 900], but screen is actually [1366, 768]. Using actual size
starting background recording process
will save to file: C:\Users\Win10/.eegnb\data\visual_n170\local\museS\subject0001\session001\recording_2021-01-25-16.23.46.csv

[JohnGriffiths]

I'm not sure about behaviour with 2 screens, this is untested as far as I'm aware.

In any case the stim presentation issues you are having should be unrelated to the EEG system.

You can test this behaviour more directly by just calling the stim presentation without an EEG stream

from eegnb.experiments.visual_n170 import n170
n170.present(duration=10)

Regarding screen freezing etc.: psychopy disables pretty much all controls when presenting. It takes over. Hitting escape should cancel, but that doesn't always work in my experience. In windows if you do things like double click and press random keys during a presentation that can cause python to crash. In any case when you're testing things you should set short durations, e.g. 10 seconds above, so that if you get an apparent freeze that lasts for a long time you know it isn't because it's just waiting until the end of a 2 or 5 min block run.

Not sure how helpful this is but maybe it is.

Interested to know about this 2-screen behaviour actually.

[tmorshed]

closing as is being implemented in #263