<sb0>
rjo, whitequark: /var/lib/buildbot/.Xilinx/Xilinx.lic is a 30-day evaluation license that supports the new vivado. i'll change it to the non-expiring license that came with the new kc705 later
<sb0>
and the board pings now, nice
<sb0>
sometimes xilinx actually fix their bugs
<sb0>
bb-m-labs, force build artiq-pipistrello-nist_qc1
<bb-m-labs>
build forced [ETA 20m01s]
<bb-m-labs>
I'll give a shout when the build finishes
<GitHub96>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/vKOLR
<GitHub96>
artiq/master 375e821 Sebastien Bourdeauducq: test/ctlmgr: keep trying to ping on OSError...
<sb0>
hmm, maybe the OSError was for something more serious
<cr1901_modern>
sb0: Is it reproducible on other machines (just wondering)?
<sb0>
what, the OSError?
<cr1901_modern>
sb0: Yes. I'm assuming it's the same Windows one from yesterday?
<sb0>
yes
<sb0>
well, you can try running the test
<sb0>
the problem appeared when anaconda updated python from 3.5.1 to 3.5.2
<cr1901_modern>
I have an environment for python 3.5.1. Does artiq hard-depend on 3.5.2 now, or was that just conda woes?
<sb0>
2.0 does because I have removed the 3.5.1 monkey patches, but you should be able to reproduce it easily on release-1 that still supports 3.5.1
<cr1901_modern>
H/o two seconds... git woes
<cr1901_modern>
sb0: Okay what do you want me to test (everything's working fine now on my end. Only errors are missing nonessential modules)?
<sb0>
are you running python 3.5.2? as i said, this error popped up after the update
<cr1901_modern>
"but you should be able to reproduce it easily on release-1 that still supports 3.5.1". Sorry I misunderstood. Upgrading now.
<sb0>
sorry s/reproduce/run
FabM has joined #m-labs
<cr1901_modern>
sb0: Okay upgraded. No OSErrors yet. Only thing that seems different is that experiments aren't automatically loaded into the GUI when I open artiq_browser.
<sb0>
did you run the failing unittest?
<sb0>
the only thing that is affected by the problem is the unittest itself afaict, no user-visible parts
<cr1901_modern>
sb0: Same test fails, different error. Which probably means I screwed it up somehow.
<rjo>
cr1901_modern: the stuff after the return that you removed was just an unfinished sketch.
<cr1901_modern>
rjo: Well, it's a comprehensive test suite. Any objections if I keep it in/modify it to work on the WB core (before surgically removing the WB bus and replacing with CSR bus)?
<cr1901_modern>
In any case I think once the CSR core passes the same test suite as the wishbone version, we should be okay.
<GitHub166>
[artiq] whitequark pushed 1 new commit to master: https://git.io/vKOEW
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
kristianpaul has quit [Ping timeout: 258 seconds]
<cr1901_modern>
rjo: I'm a bit recognizing this, but why does the artiq spi driver write out all bits of data and THEN reads in the desired number of bits (i.e. in series, not parallel) even in full duplex mode?
<cr1901_modern>
I'm a bit late* recognizing this
<cr1901_modern>
In full duplex/4-wire mode, I would expect an SPI driver to be reading and writing at the same time.
<cr1901_modern>
Does ARTIQ only use three wire mode?
<cr1901_modern>
sb0: Ping as well ^. Perhaps you can answer this
<cr1901_modern>
rjo: Actually nevermind I think I got it; a write to the SPI driver will also do a read. So if for some reason you wanted to read out the data a slave sends while you're writing to the slave, just set the read_length register to 0, so no *extra* bits are shifted in.