<dlrobertson>
whitequark: approved 207... If there are some rules you'd like me to follow for reviewing stuff or if m-labs has some standard, just let me know
<GitHub45>
[smoltcp] whitequark commented on issue #207: @dlrobertson Thank you for reviewing this! I am very happy with how the code turned out, and even more so that I have been freed to do something else :D https://github.com/m-labs/smoltcp/pull/207#issuecomment-388673898
<whitequark>
dlrobertson: nope everything is great
<GitHub76>
[smoltcp] m-labs-homu closed pull request #207: Add support for IPv6 gateway, and use it to make examples IPv6-capable (master...ipv6-gateway) https://github.com/m-labs/smoltcp/pull/207
<whitequark>
sb0: <artiq>/coredevice/ad9914.py:228:13-228:39: error: cannot assign to constant attribute 'continuous_phase_comp' of class 'artiq.coredevice.ad9914.AD9914'
<whitequark>
self.continuous_phase_comp = pow
mumptai has joined #m-labs
<GitHub176>
[smoltcp] barskern commented on issue #104: I resolved this problem, and I have now refined the test to detect a fast retransmit. Further I'm thinking about how to store the number of duplicated ACK's received. For a testing it I am planning on defining it as a field on the `TcpSocket` struct, however I think that this will unnessecary clutter an already huge struct. I haven't refined my ideas yet, but I was thinkin
<GitHub-m-labs>
artiq/master 09617c9 whitequark: firmware: migrate session_proto to new libio.
<GitHub-m-labs>
artiq/master e9c88e3 whitequark: firmware: migrate moninj_proto to new libio.
<GitHub-m-labs>
artiq/master e292c8a whitequark: firmware: migrate mgmt_proto to new libio.
<sb0>
unification error exception
<whitequark>
git log --grep=unif
<whitequark>
I just remember that I fixed something
<sb0>
whitequark, that doesn't turn up anything relevant
rohitksingh has joined #m-labs
<whitequark>
ok I'll take a look
<sb0>
whitequark, sent you some details on signal. he might be using 3.0 and not 3.6, which could explain the problem.
<sb0>
that's with the ad9914.py from master
<GitHub-m-labs>
[artiq] jordens commented on issue #983: AFAICT this is currently only an inconvenience. Fixing it would involve breaking earlier 3.x or adding an epoch to the openocd version (and use that in 4.x). https://github.com/m-labs/artiq/issues/983#issuecomment-388865770
<GitHub-m-labs>
[artiq] jordens commented on issue #983: AFAICT this is currently only an inconvenience. Fixing it would involve breaking earlier 3.x (removing the old openocds and fixing 3.x+1) or adding an epoch to the openocd version (and depend on that in 4.x). https://github.com/m-labs/artiq/issues/983#issuecomment-388865770
<GitHub-m-labs>
[artiq] jordens commented on issue #1003: Yes. The analogous issue (unsynchronized state) exists in a lot of other places as well. E.g. Sampler PGIA, Zotino LEDs, or if you changed some of the Urukul DDS settings (PLL N) manually. In this case you'll either have to explicitly set the attenuator register to the "expected" value (somewhat fragile), or load the value (that'll cost time). https://github.com/m-l
<GitHub-m-labs>
[artiq] hartytp commented on issue #1003: > Yes. The analogous issue (unsynchronized state) exists in a lot of other places as well. E.g. Sampler PGIA, Zotino LEDs, or if you changed some of the Urukul DDS settings (PLL N) manually. In this case you'll either have to explicitly set the attenuator register to the "expected" value (somewhat fragile), or load the value (that'll cost time).... https://github.co
<GitHub-m-labs>
[artiq] jordens commented on issue #1003: Yes. The analogous issue (unsynchronized state) exists in a lot of other places as well. E.g. Sampler PGIA, ~Zotino LEDs~, or if you changed some of the Urukul DDS settings (PLL N) manually. In this case you'll either have to explicitly set the attenuator register to the "expected" value (somewhat fragile), or load the value (that'll cost time). https://github.com/m
<GitHub-m-labs>
[artiq] jordens commented on issue #1003: Probably the best would be to documented throughout (`get_att_mu()` and every affected `set...()`) and offer overrides for those state defaults through the device DB. Also should be documented in best practices for coredevice drivers. https://github.com/m-labs/artiq/issues/1003#issuecomment-388871684
<GitHub-m-labs>
[artiq] ljstephenson commented on issue #1003: I agree that documentation is the way forward - loading the value into the register (if you mean via `get_att_mu`) isn't possible without affecting the output, and even if corrected immediately afterwards that would be highly undesirable behaviour! https://github.com/m-labs/artiq/issues/1003#issuecomment-388875460
rohitksingh has quit [Quit: Leaving.]
<travis-ci>
ProgVal/smoltcp#5 (naive-routes - 7f2f159 : Valentin Lorentz): The build has errored.
<GitHub129>
[smoltcp] ProgVal commented on issue #211: It works to create a `NdiscOptions` or a `NdiscOptionsRepr` from scratch, but not with `NdiscOptionsRepr::parse`, because we need another slice, and I don't know where to get it from https://github.com/m-labs/smoltcp/issues/211#issuecomment-388912803
<GitHub80>
[smoltcp] dlrobertson commented on issue #211: I'm a bit skeptical about this. Not saying it can't be done, but it could get a bit hairy once you get to parsing all of the available options, there could be a reasonable performance hit, and there are some options that just don't make sense with a given message (e.g. see the Valid Options of a Message Format https://tools.ietf.org/html/rfc4861#section-4.1). Perhaps a go
<GitHub197>
[smoltcp] dlrobertson commented on issue #211: I'm a bit skeptical about this. Not saying it can't be done, but it could get a bit hairy once you get to parsing all of the available options, there could be a reasonable performance hit, and there are some options that just don't make sense with a given message (e.g. see the Valid Options of a Message Format https://tools.ietf.org/html/rfc4861#section-4.1). Perhaps a
<GitHub165>
[smoltcp] dlrobertson commented on issue #211: The real downside with flattening the options into the `NdiscRepr` like we currently do is `) it causes us to only know the options included in the `Repr` and 2) we keep duplicates. E.g. a Router Advertisement with two Prefix Information options will only result in a `Repr` with one Prefix Information option. https://github.com/m-labs/smoltcp/issues/211#issuecomment
<GitHub177>
[smoltcp] dlrobertson commented on issue #211: The real downside with flattening the options into the `NdiscRepr` like we currently do is 1) it causes us to only know the options included in the `Repr` and 2) we keep duplicates. E.g. a Router Advertisement with two Prefix Information options will only result in a `Repr` with one Prefix Information option. https://github.com/m-labs/smoltcp/issues/211#issuecomment
<GitHub163>
[smoltcp] dlrobertson commented on issue #211: The real downside with flattening the options into the `NdiscRepr` like we currently do is 1) it causes us to only know the options included in the `Repr` and 2) we can't keep duplicates. E.g. a Router Advertisement with two Prefix Information options will only result in a `Repr` with one Prefix Information option. https://github.com/m-labs/smoltcp/issues/211#issuec