d_n|a has quit [Read error: Connection reset by peer]
d_n|a has joined #m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
mauz555 has joined #m-labs
rohitksingh has joined #m-labs
m4ssi has joined #m-labs
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
rohitksingh has quit [Ping timeout: 268 seconds]
mauz555 has quit [Remote host closed the connection]
mauz555 has joined #m-labs
mauz555 has quit [Ping timeout: 264 seconds]
rohitksingh has joined #m-labs
hartytp has joined #m-labs
<hartytp>
sb0: I'm finishing up testing on switching now
<hartytp>
I'm really impressed
<hartytp>
nothing to fault so far (apart from docs needing beefing up)
<hartytp>
nice job!
<hartytp>
before signig off on it, I'd like to try running an experiment on it. Can you rebase to current master so I can do that (e.g. I'll need the new urukul driver to do anything with it)
<hartytp>
sb0: there are a few other things that have changed. I can cherry pick, but it's a bit of a pain. In any case, we should merge switching soon, so will need to rebase anyway...
<sb0>
hartytp: try new. i want to merge that one instead (and it should be mergeable automatically...)
<sb0>
in general I get a bit paranoid about merges, since there have been a few annoying bugs stemming from improperly done merges, so I try to reduce the amount of merges
<sb0>
as long as you don't interrupt kernels, there shouldn't be issues with the new branch right now
<hartytp>
ideally I'd like to test out switching in an actual experiment before signing off on it since that often picks up bugs that don't show up in simple test setups
<sb0>
as soon as possible. depends on llvm issues, mostly.
<hartytp>
but to run an experiment on it, I need something that's compatible with other code, which requires more or less parity with master
<hartytp>
okay, well, I can wait a week, maybe two if that helps. after that I really want to sign off on it
rohitksingh has quit [Ping timeout: 240 seconds]
<hartytp>
what's the timeline for the SDRAM issue?
<sb0>
hartytp: just use new. or merge it yourself.
<sb0>
_florent_: ^
<hartytp>
sb0: how confident are you that new won't raise other unexpected issues? It would be nice to test out one modification at a time
<hartytp>
basically, I'd consider merging the changes into master to be part of the contract. I expect to sign off on it promptly after that is done, assuming a check test on my experiment doesn't turn up anything unexpected
<sb0>
hartytp: the contract is for switching, not functional combinations of whatever artiq commits you want. the deliverable is the switching branch, and then switching125 since you insisted on a merge already.
<hartytp>
So long as it's merged into master, I'm happy
<hartytp>
(IIRC there were two components of the contract, a switching component and an integration with Kasli component. even if mergin into master isn't covered with the first of those, I would have expected it to be covered by the latter)
<sb0>
it will get merged eventually, but your requests for various commit combinations/merges create extra work
<_florent_>
hartytp, sb0: sorry i was busy, i will look at kasli SDRAM on next Monday/Tuesday
<hartytp>
_florent_ ack
rohitksingh has joined #m-labs
<hartytp>
sb0: understood. But, having the changes merged with master before I sign off on them doesn't seem unreasonable (otherwise, what's the point of an integration contract?). If you want to put that off a bit, that's fine. But, testing one major change at a time does seem sensible to make bug tracking easier
hartytp has quit [Quit: Page closed]
<sb0>
hartytp: it is integrated with kasli in the switching, switching125, and new branches.
<bb-m-labs>
build #2678 of artiq is complete: Exception [exception python_unittest_2 board_unlock_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2678 blamelist: Robert J?rdens <rj@quartiq.de>
<bb-m-labs>
build forced [ETA 1h05m36s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
bb-m-labs: force build --props=package=artiq-board,artiq_target=kasli,artiq_variant=opticlock artiq-board
<bb-m-labs>
build forced [ETA 16m47s]
<bb-m-labs>
I'll give a shout when the build finishes
<bb-m-labs>
build #2680 of artiq is complete: Exception [exception python_unittest_2 board_unlock_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2680 blamelist: Robert J?rdens <rj@quartiq.de>
<bb-m-labs>
build #2681 of artiq is complete: Exception [exception python_unittest_2 board_unlock_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2681 blamelist: Robert J?rdens <rj@quartiq.de>