<bb-m-labs>
build #2372 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2372 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<GitHub-m-labs>
artiq/master ad89c42 Florent Kermarrec: firmware/serwb: automatically adjust prbs test delay to prbs test cycles, increase prbs test cycles
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<bb-m-labs>
build #2373 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2373 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
ardavast has quit [Read error: Connection reset by peer]
<bb-m-labs>
build #2374 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2374 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
<bb-m-labs>
build #2376 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2376 blamelist: Florent Kermarrec <florent@enjoy-digital.fr>
mumptai has joined #m-labs
kaolpr1 has left #m-labs [#m-labs]
kaolpr has joined #m-labs
<sb0>
marmelada, right, you cannot have two "while True" loop in two branches of a parallel block
<sb0>
put the loop outside the parallel block
<marmelada>
when I did two long for loops it also didn't work
<sb0>
yes, you can't have very long sequences in branches of "parallel"
<sb0>
doing threads would be too slow
<sb0>
put the loop outside "with parallel"
<kaolpr>
hey, what's the easiest way to wait for a rising edge in ARTIQ? I mean sth like wait_for_re(timeout); ttl.pulse(1*us)
<sb0>
kaolpr, you have to implement yourself with rtio_output() and rtio_input_timestamp(). see the ttl driver for examples of using those functions.
<kaolpr>
sb0, ok, thanks!
<marmelada>
sb0: can I have two sequences of similar length?
<sb0>
marmelada, the problem is the length of the sequence
<GitHub-m-labs>
[artiq] philipkent commented on issue #1012: The `core_dds::dds_channel_count` argument was set to 3 in device_db (copy/pasted from the examples). I've increased it to 12, since we are using 12 dds cards but it still throws an IndexError. Is there documentation available for the new DDSGroupAD9914 class that gives a description of it's arguments such as `first_dds_bus_channel`? https://github.com/m-labs/
<GitHub-m-labs>
[artiq] philipkent commented on issue #1012: It looks like the issue was that the bus channel of the first dds bus changed from 50 to 27 in the latest gateware. Changing the bus_channel to 27 in device_db fixed the IndexError. https://github.com/m-labs/artiq/issues/1012#issuecomment-391802366
<GitHub151>
[smoltcp] whitequark commented on pull request #212 24fdd76: How about making an `Ipv6OptionIterator`? Note that I'm not hung on this, and would be OK merging as is, but if you want, this would be how I improve it. https://github.com/m-labs/smoltcp/pull/212#discussion_r190744497
<GitHub46>
[smoltcp] whitequark commented on issue #211: Do I understand it correctly that right now we handle any number of options just fine on no_std, but with this refactoring, we will be limited to something that is less than what RFC allows? This seems clearly bad to me. https://github.com/m-labs/smoltcp/issues/211#issuecomment-391881108
<travis-ci>
m-labs/smoltcp#969 (master - 908ef8d : Astro): The build passed.