sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
<GitHub-m-labs>
[artiq] jordens commented on issue #936: Lets try to figure out aravis. I suspect it will work fine. Will build and install the Debian package and then we can give the gobject stuff a spin.... https://github.com/m-labs/artiq/issues/936#issuecomment-375829228
<sb0>
whitequark, SMA?
<sb0>
it should go to DAC_CLK_P and you should also change the clock switch. did you do that?
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #969: There should be an entry in RELEASE_NOTES about the rename to ``ad53xx`` and methods that have changed - written for users of the old driver that need to switch to the new. https://github.com/m-labs/artiq/pull/969#issuecomment-375842820
<GitHub43>
[smoltcp] whitequark commented on issue #180: Thanks for the PR! This looks good to me, but can you extract the packet definitions into `wire/ndisc.rs`, as discussed before? They would still be defined for the same structure, I think `use super::icmpv6::*;` should do the trick visibility wise. https://github.com/m-labs/smoltcp/pull/180#issuecomment-375843852
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<GitHub118>
[smoltcp] whitequark commented on pull request #178 8c745c8: I also think this function should do an early return if the address being considered is not a multicast address. This will save us the map traversal. https://github.com/m-labs/smoltcp/pull/178#discussion_r176899245
<GitHub171>
[smoltcp] batonius commented on issue #63: Looks good to me. Right now `dhcpd` is implemented on top of `std::net::UdpSocket`, so being able to use it with the state machine directly would be great. https://github.com/m-labs/smoltcp/issues/63#issuecomment-375854794
<GitHub-m-labs>
[artiq] hartytp commented on pull request #969 a7dd3e7: I take your point, but we currently use mu for all units even freq phi and amp for dds. So this is just being consistent (which is the least confusing thing to do imo). https://github.com/m-labs/artiq/pull/969#discussion_r176904034
<GitHub-m-labs>
[artiq] hartytp commented on pull request #969 a7dd3e7: True that works, but it seems a but heavyweight for me unless there is a concrete use case for it - I'm not aware of one. My approach is to start simple and add that kind of feature when a need is expressed.... https://github.com/m-labs/artiq/pull/969#discussion_r176904067
<GitHub-m-labs>
[artiq] hartytp commented on pull request #969 a7dd3e7: Assuming no major objections, would you mind finishing this off from here? This is now all working on the hw and I'd like to prioritize analogy tests on Zotino. https://github.com/m-labs/artiq/pull/969#discussion_r176906059
<GitHub-m-labs>
[artiq] hartytp commented on pull request #969 a7dd3e7: @sbourdeauducq thinking about this more: using this without ldac is probably a rare use case, so let's not clutter up the driver with it if we can avoid it. What about having a general dummy ttl that the device manager can provide for this kind of case? https://github.com/m-labs/artiq/pull/969#discussion_r176906595
kmehall has quit [Quit: No Ping reply in 180 seconds.]
kmehall has joined #m-labs
<GitHub-m-labs>
[artiq] jordens commented on issue #969: In general commit messages should be as concise and readable as possible. That means including the area where the work was done. "fix core device addr." is not decipherable. And if at all possible, that commit and the change it reverts should not appear in the history.... https://github.com/m-labs/artiq/pull/969#issuecomment-375884729
<GitHub-m-labs>
[artiq] jordens commented on pull request #969 a7dd3e7: IMO `mu` is ok for an opaque quantity of machine units independent of what the quantity describes if the corresponding SI unit is always clear from the context and it's not used as a variable name (`mu` itself is not ok, but `voltage_{to_}_mu` is fine). https://github.com/m-labs/artiq/pull/969#discussion_r176908120
<GitHub157>
[smoltcp] astro commented on pull request #178 8c745c8: I thought otherwise, because in `Repr` we're no longer dealing with the `max_resp_time` code but with a proper `Duration`. I'll rename it back if you don't agree that that's a significant difference between the two. https://github.com/m-labs/smoltcp/pull/178#discussion_r176916745
<GitHub24>
[smoltcp] astro commented on pull request #178 8c745c8: I don't like the semantics of TTL=255, that is: reporting group membership to every group listener across routers. I'm not seeing it in the wild either.... https://github.com/m-labs/smoltcp/pull/178#discussion_r176921447
<GitHub11>
[smoltcp] whitequark commented on pull request #178 8c745c8: The *concept* is the same (maximum response time), the *units* are different (floating point in i8 vs Duration). You could call it `max_resp_time_fp` and `max_resp_time_duration` but that's annoyingly long. https://github.com/m-labs/smoltcp/pull/178#discussion_r176921686
<GitHub97>
[smoltcp] astro commented on pull request #178 8c745c8: I thought otherwise, because in `Repr` we're no longer dealing with the `max_resp_time` code but with a proper `Duration`. I'll rename it back if you don't agree that this is a significant difference between the two. https://github.com/m-labs/smoltcp/pull/178#discussion_r176916745
<GitHub141>
[smoltcp] astro commented on pull request #178 8c745c8: I thought otherwise, because in `Repr` we're no longer dealing with the `max_resp_time` code from `Packet` but with a proper `Duration`. I'll rename it back if you don't agree that this is a significant difference between the two. https://github.com/m-labs/smoltcp/pull/178#discussion_r176916745
<GitHub39>
[smoltcp] astro commented on pull request #178 8c745c8: I disagree, because in `Repr` we're no longer dealing with the `max_resp_time` code from `Packet` but with a proper `Duration`. I'll rename it back if you don't agree that this is a significant difference between the two. https://github.com/m-labs/smoltcp/pull/178#discussion_r176916745