let's see whether this is enough on windows:
http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/258/steps/python_unittest/logs/stdio
test_attenuation (artiq.test.test_lda.TestLda) ... first connection attempt to ::1:3253[<class 'artiq.protocols.pc_rpc.AutoTarget'>] failed, retrying in the background
Traceback (most recent call last):
File "c:\slave64\artiq-win64-test\build\artiq\protocols\pc_rpc.py", line 301, in __init__
self.__coninit(firstcon_timeout)
File "c:\slave64\artiq-win64-test\build\artiq\protocols\pc_rpc.py", line 317, in __coninit
(self.__host, self.__port), timeout)
File "c:\slave64\miniconda\envs\buildbot-artiq-win64-test-258\lib\socket.py", line 711, in create_connection
raise err
File "c:\slave64\miniconda\envs\buildbot-artiq-win64-test-258\lib\socket.py", line 702, in create_connection
sock.connect(sa)
socket.timeout: timed out
* just returning `None` as dummy device (like ExamineDeviceMgr)
is not explicit enough, certainly hard to debug
* introducing a special flag for the `build` action does not
seem the right place
The core of the problem that 373578bc was attempting to solve is
that diagnostics sometimes should be chained; one way of chaining
is the loc.expanded_from feature, which handles macro-like expansion,
but another is providing context.
Before this commit, context was provided using an ad-hoc override
of a diagnostic engine, which did not work in cases where diagnostic
engine was not threaded through the call stack. This commit uses
the newly added pythonparser context feature to elegantly handle
the problem.
