sb0 changed the topic of #m-labs to: https://m-labs.hk :: Logs http://irclog.whitequark.org/m-labs :: Due to spam bots, only registered users can talk. See: https://freenode.net/kb/answer/registration
<GitHub-m-labs> [artiq] jbqubit commented on issue #1173: Keeping phase alignment for different frequencies just ends up being annoying. ... https://github.com/m-labs/artiq/issues/1173#issuecomment-443383472
<GitHub-m-labs> [migen] whitequark pushed 3 new commits to master: https://github.com/m-labs/migen/compare/c05fc0c69e3c...f5005b5bbe87
<GitHub-m-labs> migen/master f0cd29f whitequark: genlib/fifo: add __all__.
<GitHub-m-labs> migen/master 29b4e65 whitequark: genlib/resetsync: add __all__.
<GitHub-m-labs> migen/master f5005b5 whitequark: fhdl: append lowered specials to the original fragment....
[X-Scale] has joined #m-labs
X-Scale has quit [Ping timeout: 250 seconds]
[X-Scale] is now known as X-Scale
<bb-m-labs> build #349 of migen is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/349 blamelist: whitequark <whitequark@whitequark.org>
<cr1901_modern> what was the mismatch in lower_specials?
<GitHub-m-labs> [migen] whitequark pushed 1 new commit to master: https://github.com/m-labs/migen/commit/01d90550b1f83792fd861074ab82956186a6acf9
<GitHub-m-labs> migen/master 01d9055 whitequark: fhdl: fix mismatch between _can_lower() and _lower_specials_step()....
[X-Scale] has joined #m-labs
<bb-m-labs> build #350 of migen is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/350 blamelist: whitequark <whitequark@whitequark.org>
X-Scale has quit [Ping timeout: 250 seconds]
[X-Scale] is now known as X-Scale
rohitksingh has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1203: > Changing this will require some refactoring, because `exec_module()` doesn't have any return statement.... https://github.com/m-labs/artiq/issues/1203#issuecomment-443412123
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1198: Putting that one in the try-except block is not sufficient, as ``sync_struct`` will also call ``__setitem__`` directly. https://github.com/m-labs/artiq/issues/1198#issuecomment-443412314
<GitHub-m-labs> [artiq] gkasprow commented on issue #1064: I think the only solution is to send it to Warsaw. https://github.com/m-labs/artiq/issues/1064#issuecomment-443413353
<kbeckmann> whitequark: thanks! that worked. I ran it with --port A before... any reason why B behaves differently?
<whitequark> kbeckmann: the PLL is attached to one of the pins on port B
<whitequark> like, it actually *replaces* the SB_IO block, sort of
<whitequark> it's quite disgusting, really
<whitequark> and it's deep in a datasheet so you don't even notice it...
<kbeckmann> haha ok. wow. thanks for figuring it out.
<whitequark> oh I knew that
<whitequark> I actually just wanted to use the PLL myself
<whitequark> btw, take a look at gateware.pll.
<whitequark> you don't need to use icepll anymore
<whitequark> this is built into glasgow now
<kbeckmann> oh, that's awesome!
<GitHub-m-labs> [artiq] hartytp commented on issue #1198: hmm...yes...so is the preferred solution to add some exception handling to `sync_struct`, which places informative info in the log when exceptions occur? https://github.com/m-labs/artiq/issues/1198#issuecomment-443414758
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to release-4: https://github.com/m-labs/artiq/compare/d6cc10b43c7d...6fdfd6103f46
<GitHub-m-labs> artiq/release-4 6fdfd61 Sebastien Bourdeauducq: ctlmgr: do not raise exceptions in Controllers.__setitem__. Closes #1198
<GitHub-m-labs> artiq/release-4 e3624ca Sebastien Bourdeauducq: test_loopback_gate_timing: print input timing for debugging
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1198: The methods that sync_struct calls should not raise exceptions; when they do it is because of internal program errors (which should be debugged the same way as other asyncio problems).... https://github.com/m-labs/artiq/issues/1198#issuecomment-443415226
<GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/dce4f036db75...fd00021a520d
<GitHub-m-labs> artiq/master 7f55376 Sebastien Bourdeauducq: test_loopback_gate_timing: print input timing for debugging
<GitHub-m-labs> artiq/master fd00021 Sebastien Bourdeauducq: ctlmgr: do not raise exceptions in Controllers.__setitem__. Closes #1198
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/c894fe028c5ae484e040f58d93b749fc29bdb58e
<GitHub-m-labs> artiq/release-3 c894fe0 Sebastien Bourdeauducq: ctlmgr: do not raise exceptions in Controllers.__setitem__. Closes #1198
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1202: You can remove the moninj core completely in that case; the firmware should handle this.... https://github.com/m-labs/artiq/issues/1202#issuecomment-443415414
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1201: I suppose this is because of the ``ret`` clock domain in ``adc_ser.py``; since all the modules in the hierarchy are anonymous or named the same, migen does not know how to rename them when there are multiple ones. https://github.com/m-labs/artiq/issues/1201#issuecomment-443415752
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1201: I suppose this is because of the ``ret`` clock domain in ``adc_ser.py``; since all the modules in the hierarchy are anonymous or named the same, migen does not know how to rename the ``ret`` domains when there are multiple ones. https://github.com/m-labs/artiq/issues/1201#issuecomment-443415752
<bb-m-labs> build #2102 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2102
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1181: @drewrisinger Can you remove the type annotations and fix the small merge conflict? https://github.com/m-labs/artiq/pull/1181#issuecomment-443416920
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1185: @drewrisinger Can you resolve the two small issues (remove overly verbose comment and use "switch" code pattern?)... https://github.com/m-labs/artiq/pull/1185#issuecomment-443417072
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1188: @drewrisinger To clarify my position: while i am opposed to using type annotations inside ARTIQ, merging this and having ``pc_rpc`` handle them for user code is totally fine. https://github.com/m-labs/artiq/pull/1188#issuecomment-443417232
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1203: see also https://github.com/m-labs/artiq/issues/652 https://github.com/m-labs/artiq/issues/1203#issuecomment-443417288
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1196: @drewrisinger Did you figure out better numbers and can you send a PR? https://github.com/m-labs/artiq/issues/1196#issuecomment-443417379
<bb-m-labs> build #2103 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2103
<bb-m-labs> build #961 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/961
<bb-m-labs> build #2733 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2733
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 250 seconds]
<bb-m-labs> build #2104 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2104
<GitHub-m-labs> [artiq] hartytp commented on issue #1198: @sbourdeauducq ack, thanks for fixing that.... https://github.com/m-labs/artiq/issues/1198#issuecomment-443420442
<bb-m-labs> build #2105 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2105
<bb-m-labs> build #962 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/962
<bb-m-labs> build #2734 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2734
cr1901_modern1 has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
<bb-m-labs> build #2106 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/2106 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #2735 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2735 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
futarisIRCcloud has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined #m-labs
Gurty has quit [Ping timeout: 246 seconds]
<sb0> whitequark: what should process_Builtin (llvm_ir_generator.py) return?
<sb0> whitequark: and what is tbaa_now doing?
<sb0> in general I don't see the tbaa stuff actually used anywhere
rohitksingh has quit [Ping timeout: 272 seconds]
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/7e14f3ca4ee9ef7c2e51b0337a9b41ce45d6053a
<GitHub-m-labs> artiq/master 7e14f3c Sebastien Bourdeauducq: compiler,gateware: atomic now stores
<GitHub-m-labs> [artiq] sbourdeauducq commented on commit 7e14f3c: @whitequark Can you review the LLVM part of this? Things that I'm unsure about are TBAA and what ``process_Builtin`` should return. https://github.com/m-labs/artiq/commit/7e14f3ca4ee9ef7c2e51b0337a9b41ce45d6053a#commitcomment-31524647
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #636: Done. ``test_pulse_rate`` results:... https://github.com/m-labs/artiq/issues/636#issuecomment-443458898
<GitHub-m-labs> [artiq] sbourdeauducq closed issue #950: sequence errors after kernel eviction/errors https://github.com/m-labs/artiq/issues/950
<GitHub-m-labs> [artiq] sbourdeauducq closed issue #636: improved register layout and tweaked event submission code https://github.com/m-labs/artiq/issues/636
<bb-m-labs> build #2736 of artiq is complete: Failure [failed lit_test] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2736 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<sb0> ah yes, of course conda is breaking again
<sb0> ffs
<sb0> bb-m-labs: force build artiq
<bb-m-labs> build forced [ETA 58m55s]
<bb-m-labs> I'll give a shout when the build finishes
<bb-m-labs> build #2737 of artiq is complete: Failure [failed lit_test] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2737
<sb0> bb-m-labs: force build artiq
<bb-m-labs> build forced [ETA 58m55s]
<bb-m-labs> I'll give a shout when the build finishes
<bb-m-labs> build #2738 of artiq is complete: Failure [failed conda_create] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2738
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/ad39c76a560bcbe077effad3c870e28a297dbc09
<GitHub-m-labs> artiq/master ad39c76 Sebastien Bourdeauducq: conda: fix llvmlite dependency
<bb-m-labs> build #2739 of artiq is complete: Failure [failed lit_test] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2739 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<whitequark> sb0: the tbaa stuff is only used inside of LLVM, it's not expected to be used inside of ARTIQ
<whitequark> sb0: regarding the return value of process_Builtin, it doesn't terribly matter here, since the return values of at_mu and delay_mu are never used
<whitequark> the requirement for having every process_* return something is outdated
<whitequark> it became impossible to do in the way it was intended after I added expansion of IR instructions to multiple LL instructions
<whitequark> and it can probably be removed now