<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #998: What I don't understand is why there is no sequence error with a single ``reset()``. The end of ``reset()`` calls ``set_mu`` 9 times without advancing the time line, which is more than the number of SED lanes, so there should be a sequence error already.... https://github.com/m-labs/artiq/issues/998#issuecomment-389723055
<GitHub38>
[smoltcp] barskern commented on issue #214: Yes will do. I normally do for my own projects I just wanted to keep history mostly intact when there are more people involved. Isn't it easier to review when there are multiple commits or should I just always squash so there is just one? https://github.com/m-labs/smoltcp/pull/214#issuecomment-389837124
<GitHub15>
[smoltcp] barskern commented on issue #214: Yes will do. I normally do for my own projects I just wanted to keep history mostly intact when there are more people involved. Isn't it easier to review when there are multiple commits or should I just always squash so there is just one commit per PR? https://github.com/m-labs/smoltcp/pull/214#issuecomment-389837124
<sb0>
whitequark, did you do anything that could have made test_host_to_device slower?
<sb0>
the underflow in the other test is also very large, 12µs ..
<sb0>
whitequark, "self.loop_clock_out.set(1*MHz)" results in soft-FP operations being executed. shouldn't the compiler inline functions and propagate constants?
<whitequark>
sb0: that's really odd
<whitequark>
I'll take a look
<whitequark>
as for test_host_to_device, no, I don't think so
<whitequark>
it should be trivial to figure out with the new profiler though
<sb0>
whitequark, on release-3 you clearly see it started failing after the llvm 6 update
<whitequark>
which one? clock_generator_loopback?
<sb0>
yes
<sb0>
also it would be good to avoid those llvm updates on release branches, to avoid problems like this
<whitequark>
well, it did fix another timing error