06:35 <GitHub> [artiq] sbourdeauducq commented on issue #707: If we're going to mess with versioneer, we can also keep the current tags and make it recognize only those that consist in a version number. https://github.com/m-labs/artiq/issues/707#issuecomment-292767443

06:40 <GitHub> [artiq] sbourdeauducq commented on issue #707: @jordens Also, a pragmatic solution is to use tags for versions only, and put other commit IDs elsewhere, e.g. in the wiki. https://github.com/m-labs/artiq/issues/707#issuecomment-292767635

07:16 <GitHub> [artiq] sbourdeauducq commented on issue #707: Versioneer seems a bit tedious to fix anyway, they've had a corresponding issue open for more than a year. https://github.com/warner/python-versioneer/issues/110 https://github.com/m-labs/artiq/issues/707#issuecomment-292769116

11:27 <rjo> whitequark: how can i iterate over the bytes of a binary string in artiq-python? or better, how can i iterate over them as 16 bit uints?

15:13 <GitHub> [artiq] jordens opened issue #708: ksupport crash https://github.com/m-labs/artiq/issues/708

15:13 <GitHub> [artiq] jordens force-pushed pdq2 from 9f94202 to 20652ce: https://github.com/m-labs/artiq/commits/pdq2

15:13 <GitHub> artiq/pdq2 b9c61ae Robert Jordens: pdq2: crc/frame register accessors

15:13 <GitHub> artiq/pdq2 1ce1b7c Robert Jordens: doc: pdq2 spi backend

15:13 <GitHub> artiq/pdq2 aebbaa3 Robert Jordens: pdq2: config writes

15:27 <GitHub> [artiq] whitequark commented on issue #708: > exception 6 at PC 0x40840490, EA 0x4084406c... https://github.com/m-labs/artiq/issues/708#issuecomment-292792681

15:30 <whitequark> rjo: hm, good question

15:30 <whitequark> I don't think strings or bytes objects are currently iterable in ARTIQ Python

15:30 <whitequark> and I think only the latter should be

15:35 <rjo> whitequark: agreed.

16:02 <GitHub> [artiq] jordens commented on issue #708: i remember you (or someone) reporting that same thing (unaligned access with aligned address reported) a few months ago. what was the issue back then? https://github.com/m-labs/artiq/issues/708#issuecomment-292794635

16:21 <sb0> rjo, did you find out what was going on with rtio?

16:25 <GitHub> [artiq] jordens opened issue #709: compilation slowness and errors for integer arrays https://github.com/m-labs/artiq/issues/709

16:49 <GitHub> [artiq] klickverbot commented on issue #709: A shot in the dark without even looking at the IR: Does the compiler use `[10240 x i32]` internally somewhere as a value type, for example when passing parameters, or to `load` from and store into another pointer? We had similar issues in LDC a while back; `[a x b]` is rather deeply ingrained as meaning "a collection of registers" in LLVM, and loading to then store to another pointer, as mentioned before, wi

17:26 <sb0> whitequark, artiq_compile from the conda 3.x package fails with "OSError: libtinfo.so.5: cannot open shared object file: No such file or directory"

17:26 <sb0> artiq 2.2 works fine

17:28 <sb0> I have libtinfo.so.6 on my system, symlinking to so.5 seems to solve the issue

17:30 <sb0> whitequark, why is print() still not a regular RPC?

17:30 <sb0> I can artiq_compile things that use it ...

17:33 <GitHub> [artiq] sbourdeauducq opened issue #710: artiq_compile of kernel using print() should error out https://github.com/m-labs/artiq/issues/710

17:42 <GitHub> [artiq] sbourdeauducq commented on issue #691: Let's go with the controller+ctlmgr solution. A simple session program that starts master/ctlmgr/dashboard should be relatively straightforward; instead of messing with ``fork()`` or other problematic functions, the session program could capture the master stdout for a message that indicates readiness. https://github.com/m-labs/artiq/issues/691#issuecomment-292800455

18:37 <GitHub> [artiq] whitequark commented on issue #709: No and no and no, it uses that just for the global. The slowness comes from the type inferencer, which has to unify ten thousands of type variables. It is actually already taking an optimized path. https://github.com/m-labs/artiq/issues/709#issuecomment-292803687

18:40 <GitHub> [artiq] whitequark commented on issue #708: I have no recollection of that. https://github.com/m-labs/artiq/issues/708#issuecomment-292803891

18:43 <whitequark> sb0: because print() is used in unit tests for the compiler

18:43 <whitequark> and in integration tests, where the same code is run on host python and artiq python

18:44 <whitequark> regarding libtinfo: I have no idea, can you strace it?

18:44 <whitequark> oh wait

18:44 <whitequark> I know, it's a dependency of libedit, which is a dependency of llvm (I think)

19:25 <rjo> sb0: the time problem was an inconvenient and unexpected side effect of not having any serdes ttl. in effect: device_db wrong.