20:25 <GitHub15> [artiq] sbourdeauducq opened issue #650: support moninj without DDS https://git.io/vMmZz

20:31 <GitHub89> [artiq] sbourdeauducq opened issue #651: analyzer: support large data https://git.io/vMmZ9

20:35 <GitHub73> [artiq] sbourdeauducq commented on issue #644: Instead of having a separate mode, what about keeping the runtime (and satellite manager) responsive at all times to commands typed on the UART? This would be useful for running JESD tests as well. https://git.io/vMmne

20:36 <GitHub111> [artiq] whitequark commented on issue #644: Sure. https://git.io/vMmnL

20:39 <GitHub134> [artiq] sbourdeauducq commented on issue #644: It may not play nice with logs though (e.g. if a log message is emitted because a TCP connection is received while the user was in the middle of typing a command). I suppose that an interface like irssi (that requires terminal control codes) would be a mess, especially for Windows users... https://git.io/vMmnR

20:42 <GitHub197> [artiq] whitequark commented on issue #651: So a self-synchronizing variable-length encoding? Something like this:... https://git.io/vMmnH

20:42 <GitHub173> [artiq] whitequark commented on issue #651: So a self-synchronizing variable-length encoding? Something like this:... https://git.io/vMmnH

20:43 <GitHub37> [artiq] whitequark commented on issue #644: @sbourdeauducq does it have to be on serial specifically? If yes, we can make it modal: press Enter to suppress logs and enter commands, press ^D to return. https://git.io/vMmnb

20:44 <GitHub35> [artiq] whitequark commented on issue #644: @sbourdeauducq does it have to be on serial specifically? If yes, we can make it modal: press Enter to suppress logs and enter commands, press ^D to return. https://git.io/vMmnb

20:48 <GitHub11> [artiq] sbourdeauducq commented on issue #644: Serial is nice because it's robust and easily available. This "modal" design sounds like an acceptable compromise. https://git.io/vMmcs

20:53 <GitHub175> [artiq] jordens commented on issue #651: It would be nice if DMA (input and output), Analyzer, and DRTIO all three could use the same (or at least very similar) serialization formats.... https://git.io/vMmcS

20:57 <GitHub172> [artiq] sbourdeauducq commented on issue #651: There cannot be a lot in common, except for trivialities (e.g. the order of those few fields that are common), and more importantly for the way the variable length is communicated. https://git.io/vMmCq

21:15 <GitHub167> [artiq] whitequark commented on issue #651: So a self-synchronizing variable-length encoding? Something like this:... https://git.io/vMmnH

21:15 <GitHub114> [artiq] whitequark commented on issue #651: @jordens yes, `y`. https://git.io/vMmWa

21:18 <GitHub50> [artiq] sbourdeauducq commented on issue #651: And the analyzer is the only one that requires the variable length encoding to be self-synchronizing, so it's not clear that even that can be shared. https://git.io/vMmWH

21:18 <GitHub86> [artiq] sbourdeauducq commented on issue #651: And the analyzer is the only one that requires the variable length encoding to be self-synchronizing, so it's not clear that even that should be shared. https://git.io/vMmWH

21:28 <sb0> whitequark, do you know how I can get cargo to build libboard taking into account the rust-cfg contents?

21:29 <sb0> why does it get the correct rust options (e.g. for the CPU type) when building the runtime dependencies, but not the --cfg's?

21:31 <GitHub10> [artiq] whitequark commented on issue #651: Well, it is definitely less error-prone to have one variable-length encoder than two, on both sides. https://git.io/vMml1

21:31 <whitequark> sb0: actually, it doesn't

21:32 <whitequark> well, the CPU type, it does, because that's in the target triple. but e.g. addc, is disabled when building all but runtime/ksupport

21:32 <whitequark> I've been meaning to fix that

21:32 <whitequark> we should use xargo too and get rid of the annoying rust-core-or1k conda package

21:33 <whitequark> anyway, as for the cfgs, we should move that logic to build.rs. the current `cargo rustc` invocation in the makefile is a huge hack and it breaks down in multiple ways already.

21:33 <whitequark> I think I'll start fixing now

21:34 <GitHub178> [artiq] sbourdeauducq pushed 2 new commits to master: https://git.io/vMmlN

21:34 <GitHub178> artiq/master 417708a Sebastien Bourdeauducq: phaser: add note about DDS defines (#650)

21:34 <GitHub178> artiq/master eef3f50 Sebastien Bourdeauducq: firmware: fix compilation problems in ad9154 and ad9516

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

22:04 <GitHub72> [artiq] sbourdeauducq commented on issue #582: Really, let's use the mailing list for this. https://git.io/vMmB7

22:04 <GitHub170> [artiq] sbourdeauducq closed issue #582: plan ARTIQ users group meeting https://git.io/v17rt

22:19 <bb-m-labs> build #1191 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1191 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>