03:28 <GitHub> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/207453efcd55e3d738e8f79b5a8fdd91d6ca4c1b

03:28 <GitHub> artiq/master 207453e Sebastien Bourdeauducq: rtio: add a missing case for collision reporting

03:58 <bb-m-labs> build #508 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/508

04:06 <bb-m-labs> build #453 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/453 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

04:06 <bb-m-labs> build #1447 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1447

06:00 <whitequark> https://twitter.com/scanlime/status/849713567511134208

07:32 <GitHub> [artiq] sbourdeauducq commented on issue #691: The master already has a log server, so the cleanest way to do this is to have the core device use it. But the core device does not know the master address and requiring the user to program it would be unfriendly. So I suppose that the master should have an asyncio task that establishes the connection to the core device, by looking up ``core`` in the device database. It should handle device database reload

07:33 <GitHub> [artiq] sbourdeauducq commented on issue #691: Maybe the protocol can be shared with the existing log server, only the connection establishment code would be changed. https://github.com/m-labs/artiq/issues/691#issuecomment-292092939

07:36 <GitHub> [artiq] sbourdeauducq commented on issue #691: https://github.com/m-labs/artiq/blob/master/artiq/protocols/logging.py https://github.com/m-labs/artiq/issues/691#issuecomment-292093536

07:38 <GitHub> [artiq] whitequark commented on issue #691: I don't understand what you mean by sharing, then. https://github.com/m-labs/artiq/issues/691#issuecomment-292093880

07:39 <GitHub> [artiq] sbourdeauducq commented on issue #691: The bytes on the socket can be the same, once the socket has been connected in some way (client connecting to master, or master connecting to core device). https://github.com/m-labs/artiq/issues/691#issuecomment-292094037

07:40 <GitHub> [artiq] sbourdeauducq commented on issue #691: And maybe the hacks in logging.py to inject messages into the master logging can be shared too. https://github.com/m-labs/artiq/issues/691#issuecomment-292094340

07:41 <GitHub> [artiq] whitequark commented on issue #691: I don't think we should share that. The core device doesn't have a logging server, it has a management socket. Also, the master should waste time doing this reformatting and not the core device. https://github.com/m-labs/artiq/issues/691#issuecomment-292094608

08:34 <GitHub> [artiq] sbourdeauducq pushed 4 new commits to master: https://github.com/m-labs/artiq/compare/207453efcd55...c2667debf82b

08:34 <GitHub> artiq/master 729e7b5 Sebastien Bourdeauducq: drtio: collision/replace fixes

08:34 <GitHub> artiq/master 83d87b5 Sebastien Bourdeauducq: drtio: remove outdated comment

08:34 <GitHub> artiq/master c0100eb Sebastien Bourdeauducq: rtio: fix indentation

08:34 <GitHub> [artiq] sbourdeauducq commented on issue #562: Remaining steps:... https://github.com/m-labs/artiq/issues/562#issuecomment-282458954

08:35 <sb0> _florent_, did you make progress with getting the transceivers to behave on the kc705?

08:36 <sb0> for drtio

08:55 <_florent_> sb0: not yet, I've been using a passive SFP cable that works fine @1.25Gbps. I have to finish the investigation on the electrical parameters.

09:05 <bb-m-labs> build #509 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/509

09:13 <bb-m-labs> build #454 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/454 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

09:14 <bb-m-labs> build #1448 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1448

09:56 <GitHub> [artiq] sbourdeauducq commented on issue #691: Fine.... https://github.com/m-labs/artiq/issues/691#issuecomment-292125970

09:58 <GitHub> [artiq] whitequark commented on issue #691: > If we want to be strict about the architecture, the log forwarding component should be a controller.... https://github.com/m-labs/artiq/issues/691#issuecomment-292126552

10:36 <GitHub> [artiq] jordens commented on issue #691: Tooling to properly sequence and control the startup of all the components (master/dashboard/run/ctlmgr...) would be great. For both use cases, GUI/master or CLI/run. Even if there would be some refactoring of components. https://github.com/m-labs/artiq/issues/691#issuecomment-292134786

11:13 <whitequark> sb0: let me check if I understand this right

11:13 <whitequark> a "controller" is just a binary that's ran in a separate process and managed by artiq_ctlmgr

11:13 <whitequark> and a controller exports an RPC interface

13:57 <sb0> whitequark, controllers do not need to export a RPC interface, though all current ones do

13:57 <sb0> whitequark, the core device logging controller would just print the logging messages. ctlmgr would take care of forwarding them to the master.

13:58 <sb0> well, the RPC interface is used for ping and termination

13:58 <sb0> so currently it is mandatory