03:09 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #986: @whitequark Please fix this in release-3 as well. https://github.com/m-labs/artiq/issues/986#issuecomment-386850331

03:15 <GitHub-m-labs> [artiq] sbourdeauducq pushed 2 new commits to release-3: https://github.com/m-labs/artiq/compare/0faf781d5ff8...a4fd9ad3e1f5

03:15 <GitHub-m-labs> artiq/release-3 a4fd9ad whitequark: Unbreak 9dc7efef.

03:15 <GitHub-m-labs> artiq/release-3 88134db whitequark: compiler: transparently handle Windows newlines in RunTool.

03:55 <bb-m-labs> build #1482 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1482

04:05 <bb-m-labs> build #861 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/861

04:08 <bb-m-labs> build #2308 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2308

13:50 <dlrobertson> Hey guys! The rust community seems to be lacking a network stack that supports 802.3 and 802.15.4 support. As such, I've been thinking about adding support for them to smoltcp

13:51 <dlrobertson> However, I think the development required to add them to smoltcp will be quite heavy and it would be difficult with the current workflow as a non m-labs employee

13:51 <dlrobertson> I have a few ideas of how to work around that and would like to get some feedback from the m-labs crew

13:52 <dlrobertson> 1) move smoltcp::wire to a new crate smolwire (maybe cargo workspaces could work here) and continue to do the Interface dev in another repo/crate.

13:53 <dlrobertson> once something reasonable is implemented and tested, then start to attempt to update and merge stuff from the new crate to smoltcp::iface

14:21 <whitequark> dlrobertson: is your concern the review roundtrip time on smoltcp::wire?

14:21 <whitequark> I don't think it has anything to do with being an m-labs employee or not

14:22 <whitequark> I generally give commit bit to anyone whose code is good enough but so far all PRs required many, many rounds of change before they became even close to acceptable

14:22 <whitequark> which concerns me

14:31 <GitHub-m-labs> [artiq] whitequark pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/9589decd542406fea15fb340a02506fc7c4ffa60

14:31 <GitHub-m-labs> artiq/release-3 9589dec whitequark: Update log_buffer....

14:31 <GitHub-m-labs> [artiq] whitequark commented on issue #986: Ah sorry, didn't notice the milestone. https://github.com/m-labs/artiq/issues/986#issuecomment-386883579

14:31 <GitHub-m-labs> [artiq] whitequark closed issue #986: corelog chokes coredevice https://github.com/m-labs/artiq/issues/986

14:32 <whitequark> rjo: btw I am interested in feedback on the profiler

14:32 <whitequark> dlrobertson: in general, if you submit e.g. 802.15.4 and 802.3 support in *small* pull requests, I can try to commit to getting them merged within one week

14:32 <whitequark> but I am having serious trouble with really large PRs that also need many changes.

14:52 <bb-m-labs> build #1483 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1483 blamelist: whitequark <whitequark@whitequark.org>

14:52 <bb-m-labs> build #2309 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2309 blamelist: whitequark <whitequark@whitequark.org>

14:55 <sb0> whitequark, ^ yep, it's not that simple

14:55 <whitequark> hm? it compiled locally

14:55 <sb0> because you have a newer rustc than what is used for release-3

14:55 <whitequark> ah right, needs a rust update too

14:55 <sb0> will that break anything?

14:56 <whitequark> I don't recall fixing anything when upgrading from 1.23 to 1.25

14:56 <whitequark> so, no

14:57 <sb0> llvm, llvmlite, various conda dependencies?

14:57 <whitequark> in principle we can just upgrade rustc

14:57 <whitequark> but it seems safer to upgrade llvm and llvmlite too, since that configuration has already been tested

15:05 <GitHub-m-labs> [artiq] whitequark pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/9c6978be8405b9d7b7372a26e38a74e074d543c3

15:05 <GitHub-m-labs> artiq/release-3 9c6978b whitequark: Update LLVM to 6.0.0 and Rust to 1.25.0.

15:06 <whitequark> sb0: is release-3 in effect a "long term support" branch?

15:08 <sb0> yes

15:10 <whitequark> then we probably should commit to master with that in mind

15:10 <sb0> how does this impact master?

15:11 <whitequark> if we're going to backport a lot of changes they should be made easy to backport

15:16 <whitequark> sb0: ok, I will now start looking at SDRAM-less satman

15:16 <whitequark> but first I'm going to add remoting support to migen builds

15:17 <whitequark> you can't just archive and upload everything because migen uses absolute paths to verilog files...

15:39 <bb-m-labs> build #1484 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1484

15:43 <bb-m-labs> build #2310 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2310 blamelist: whitequark <whitequark@whitequark.org>

16:48 <dlrobertson> whitequark: yeah, my concern is just the size of everything

16:49 <dlrobertson> i don't see a good way to make them small PRs

16:50 <dlrobertson> I also kind of like the idea of being able to experiment with it without merging dev code into production code

16:51 <cr1901_modern> whitequark: We talked about using relative paths for v files a few months ago. I'm not sure what you're trying to do, but just in case, I'll link this: https://irclog.whitequark.org/m-labs/2017-11-22#1511322875-1511323135;

16:51 <dlrobertson> So that reasoning behind starting with a separate branch or fork

16:51 <cr1901_modern> (i.e. this is the reason we decided against it- maybe this issue doesn't apply to you)

16:52 <dlrobertson> also if there are consistent problems with my code please let me know

16:54 <dlrobertson> I think adding 802.15.3 and 802.3 support to smoltcp will be very large because we'll have to break out all of the packet processing out of the ethernet interface and make it generic

16:55 <dlrobertson> > but so far all PRs required many, many rounds of change before they became even close to acceptable

16:56 <dlrobertson> what in specific are you referring to? this is concerning to me. If there are consistent problems with my code, please let me know