Using Brian starts several Visual Studio Terminals when run in Spyder

[fabian.p...@googlemail.com]

Hello,

I have a rather strange problem. I've recently set up a new Windows 10 PC and installed Anaonda and the recent version of Visual Studio. When I try to run Python (3) Scripts including brian from Spyder everytime brian compiles code a visual studio terminal window pops up and gets destroyed shortly after. This is irritating and kind of annoying and I never had this problem on another machine. Does anyone know why this happens?

I don't get any error messages by the way.

[Marcel Stimberg]

Hi,

a few questions so that we can try to pin this down:
* Are you using the latest Brian release (i.e. version 2.2.2.1) or
another version?
* Which exact Python version are you using? Which version of setuptools?
* Are the scripts using the default code generation, or do you use the
C++ standalone mode (via set_device('cpp_standalone'))?
* Do you only observe this from within Spyder or does it also happen
when you run the same script from outside of Spyder with "python
scriptname.py"? Note that if it gets triggered by compilation, maybe add
a "clear_cache('cython')" to the start of the script so that it has to
compile the code again.

Best,
  Marcel

[fabian.p...@googlemail.com]

Hi,

Thank you for your help. Sure I'll try to give you some details

* Are you using the latest Brian release (i.e. version 2.2.2.1) or
another version?

I'm using 2.2.2.1

* Which exact Python version are you using? Which version of setuptools?

 

I'm using Python 3.7.4 and setuptools 42.0.2

* Are the scripts using the default code generation, or do you use the
C++ standalone mode (via set_device('cpp_standalone'))?

I'm using the default code generation

* Do you only observe this from within Spyder or does it also happen
when you run the same script from outside of Spyder with "python
scriptname.py"? Note that if it gets triggered by compilation, maybe add
a "clear_cache('cython')" to the start of the script so that it has to
compile the code again.

Trying it in a console did not produce this problem. However "clear_cache('cython')"gives the following error:

The cache directory for target 'cython' contains the file 'C:\...\.cython\brian_extensions\desktop.ini' of an unexpected type and will therefore not be removed. Delete files in 'C:\...\.cython\brian_extensions' manually

Deleting the files did not change the situation nor did it result in a different error message.

Best.

Fabian

[Marcel Stimberg]

Hi Fabian,

thanks for the details, I can reproduce the issue now.

This seems to be an issue introduced with Spyder 3 (see
https://github.com/spyder-ide/spyder/issues/3529) and apparently has to
do with the way the ipython console is integrated. They have fixed the
issue for external process calls that use the subprocess module, but in
our case the code will be compiled with Python's standard distutils
mechanism which internally uses the function os.spawnv. We could "monkey
patch" this function to avoid the problem, but I am hesitant to do this
automatically in Brian. This would change a very low-level function in
Python itself, which could potentially introduce new problems. We could
potentially make it optional via a preference, or require an explicit
function call by the user, though. I'll open an issue on github to
discuss this further.

Until then, I see two workarounds:

1. Instead of executing the script in the integrated ipython console,
you switch the run configuration to "Execute in an external system terminal"

2. You do the monkey patching of os.spawnv yourself in a snippet that
you execute at the beginning of your simulation. On my machine the
following works, but it might not be the best/most robust way of doing it:

# Monkey patch spawnv
import os
_orig_spawnv = os.spawnv
def _patched_spawnv(*args, **kwds):
    if args[0] != os.P_WAIT:
        return _orig_spawnv(*args, **kwds)
    import subprocess
    ret_val = subprocess.call(" ".join(args[2][:]),
                              creationflags=0x08000000, # CREATE_NO_WINDOW
                              stdout=subprocess.DEVNULL,
                              stderr=subprocess.DEVNULL,
                              shell=True)
    return ret_val

os.spawnv = _patched_spawnv


Best,

  Marcel

[fabian.p...@googlemail.com]

Thank you for your help Marcel.

Both methods you proposed, work for me without further problems. So I'll keep using these workarounds for now.

All the best,

Fabian