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
X-Scale has joined #m-labs
sb0 has quit [Quit: Leaving]
X-Scale has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
<whitequark>
edef: that link 500's
<whitequark>
sb0: we've discussed smoltcp already. which other things?
<whitequark>
and no, I did not look into TCP slowness with Windows at all
<GitHub177>
[artiq] whitequark commented on issue #865: These log messages mean that the runtime is processing packets slower than they arrive, sometimes by quite large chunks. This most likely means that the runtime was busy doing something else. https://github.com/m-labs/artiq/issues/865#issuecomment-350169048
<GitHub37>
[smoltcp] whitequark commented on pull request #89 12743c1: This shouldn't be a module-level macro, you can define macros within functions (and they get access to variables inside functions, too). https://github.com/m-labs/smoltcp/pull/89#discussion_r155707844
<GitHub63>
[smoltcp] whitequark commented on pull request #89 12743c1: Let's rename the function to `hop_limit` (since that's what it *in practice* always did for IPv4 anyway), and explain it in the comment. This should probably go in a separate commit than the rest of the changes. https://github.com/m-labs/smoltcp/pull/89#discussion_r155707912
<GitHub112>
[smoltcp] whitequark commented on pull request #89 12743c1: I'd prefer if you used the field explicitly in `check_len`, because otherwise it is not obvious that `check_len` doesn't contain an out-of-bounds access. https://github.com/m-labs/smoltcp/pull/89#discussion_r155708462
<GitHub134>
[artiq] sbourdeauducq commented on issue #849: Not much, it's a XC7A15T. Just satman (drive si5324, process drtio aux packets), no smoltcp or anything particularly big or complex.... https://github.com/m-labs/artiq/issues/849#issuecomment-350196194
<GitHub51>
artiq/master 3cf5cef whitequark: artiq_pcap: still grab the file if the command fails.
<sb0>
whitequark, rust compiler stuff
<sb0>
you mentioned it last time. just go through the various dependencies and look at what is not a release...
sb0 has quit [Quit: Leaving]
<whitequark>
ah. but libcompiler_builtins is tied to the compiler nightly.
<whitequark>
and or1k support is broken in upstream libfringe, and I don't know why because someone else rewrote all my code and I no longer know how it works *shrug*
<whitequark>
this is why git dependencies are convenient, you always know exactly what you get...
<edef>
whitequark: and, I'd like to fix or1k support in libfringe but I'm not sure how to get myself an or1k dev env
X-Scale has joined #m-labs
<GitHub198>
[artiq] gkasprow commented on issue #854: OK, I have a design that implements some Ethernet core that sends requests once a few seconds. I see them using WireShark. There is a chipscope instance connected to GMII output, before GMII - RGMII converter. On the Rx side I use RGMII-GMII logic and chipscope connected to it.... https://github.com/m-labs/artiq/issues/854#issuecomment-350319658
<GitHub16>
[artiq] gkasprow commented on issue #854: OK, I have a design that implements some Ethernet core that sends requests once a few seconds. I see them using WireShark. There is a chipscope instance connected to GMII output, before GMII - RGMII converter. On the Rx side I use RGMII-GMII logic and chipscope connected to it.... https://github.com/m-labs/artiq/issues/854#issuecomment-350319658
<GitHub3>
[artiq] gkasprow commented on issue #854: OK, I have a design that implements some Ethernet core that sends requests once a few seconds. I see them using WireShark. There is a chipscope instance connected to GMII output, before GMII - RGMII converter. On the Rx side I use RGMII-GMII logic and chipscope connected to it.... https://github.com/m-labs/artiq/issues/854#issuecomment-350319658