futarisIRCcloud has quit [Quit: Connection closed for inactivity]
rohitksingh_work has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<rjo>
sb0: what kind of testing did it see?
<sb0>
rjo, all unittests pass
<sb0>
and according to Chris Ballance it works fine with "typical experiment patterns"
<rjo>
sb0: are'nt there other ways to preempt fall out and increase the chances that the tree keeps working? like merging the missing ~200 commits from master into sed and testing again. testing compilation on all targets, determine effect on resource usage?
<rjo>
given that kasli is waiting for the fixes to the forked bios, i'd worry that once those are eventually fixed, we are looking at issues from sed.
<whitequark>
oh, I haven't realized kasli is blocked on me, let me fix that at once
<rjo>
whitequark: what's the plan with that anyway? do we maintain both forks of the bios? making misoc depend on the rust/llvm stack is a pretty heavy IMHO.
<whitequark>
rjo: why do we need the C BIOS for ARTIQ at all?
<sb0>
we don't need it for artiq
<sb0>
he's talking about other uses for misoc
<whitequark>
right now afaik no one actually wants to use rust with misoc. this means that non-artiq hardware would use the c bios
<whitequark>
(no one except artiq)
<whitequark>
of course, ideally, there would be no c in misoc, but that means the lm32 question needs to be resolved.
<rjo>
ack. then we have to keep tracking and porting changes between the two.
<whitequark>
I suppose so, yes
<rjo>
anybody have experience with ftdi_eeprom in the last ~year?
<GitHub158>
[smoltcp] crawford commented on pull request #110 1b2794c: It seems odd that Instant and Duration behave differently with regard to millis() and secs(). I think this should just return millis or Instant should be changed to return the modulus. https://github.com/m-labs/smoltcp/pull/110#discussion_r159914043
<GitHub188>
[smoltcp] dlrobertson commented on pull request #110 1b2794c: Yup, same with the others. Looks like I forgot to update the getters when I moved from separate second and millisecond members to on millisecond member. https://github.com/m-labs/smoltcp/pull/110#discussion_r159916578
<GitHub37>
[smoltcp] dlrobertson commented on pull request #110 1b2794c: Yup, same with the others. Looks like I forgot to update the getters when I moved from separate second and millisecond members to one millisecond member.... https://github.com/m-labs/smoltcp/pull/110#discussion_r159916578
<GitHub22>
[smoltcp] dlrobertson commented on issue #110: After the update `secs` will return `self.millis / MILLIS_PER_SEC`, `millis` will return `self.millis % MILLIS_PER_SEC`, and `elapsed` will return `self.millis`. https://github.com/m-labs/smoltcp/pull/110#issuecomment-355600402
<GitHub151>
[artiq] whitequark commented on issue #874: Oh and please do try to reproduce #877; while it *probably* was caused by a known bug, it could have been caused by anything (unlike this issue) so the report would be useful, if any. https://github.com/m-labs/artiq/issues/874#issuecomment-355630378
felix_ has quit [Ping timeout: 255 seconds]
felix_ has joined #m-labs
<GitHub25>
[smoltcp] whitequark commented on issue #107: @dlrobertson Oops, I've missed the changes in this PR again. It looks like GitHub doesn't send email notifications on rebases... care to leave a comment in place of that? https://github.com/m-labs/smoltcp/pull/107#issuecomment-355639395
<GitHub181>
smoltcp/master 793227f Dan Robertson: Ensure ICMPv4 error replies comply with size requirements...
<GitHub107>
[smoltcp] whitequark commented on pull request #112 8484538: No, I don't think this is the right fix. It is discarding data arriving in the segment with FIN set, which is not necessary, and sending a challenge ACK, which is again not necessary because such an ACK will be sent once the currently missing segment will be received. https://github.com/m-labs/smoltcp/pull/112#discussion_r159959959
<GitHub128>
[smoltcp] whitequark closed pull request #112: Don't enter CLOSE-WAIT if FIN arrives before data (master...reordered-fin-keeps-open) https://github.com/m-labs/smoltcp/pull/112
<GitHub198>
smoltcp/master fcffa6a whitequark: Disregard TCP FIN flag if it arrives in a segment not at window start....
<GitHub114>
[smoltcp] whitequark closed issue #111: FIN within the window closes the connection but the sequence number indicates unseen data https://github.com/m-labs/smoltcp/issues/111
<travis-ci>
m-labs/smoltcp#566 (master - fcffa6a : whitequark): The build was broken.
<GitHub66>
[smoltcp] whitequark commented on pull request #110 1f780bf: On second thought, I think this should be an `i64`. Then we do not need `checked_sub` and `saturating_sub` at all! The zero instant would just be an arbitrary point in a (nearly) infinite timeline. https://github.com/m-labs/smoltcp/pull/110#discussion_r159981873
<GitHub123>
[smoltcp] whitequark commented on pull request #110 1f780bf: `Default` is semantically inapplicable. There are no default instants! Deriving `Default` for something else with an `Instant` in it is a logic error; it should use an `Option<Instant>` instead. https://github.com/m-labs/smoltcp/pull/110#discussion_r159981322
<GitHub126>
[smoltcp] whitequark commented on pull request #110 1f780bf: "an arbitrary point in time" → "the beginning of time", and the docstring for `Instant` itself should explain that the zero value of `Instant` is inherently arbitrary. https://github.com/m-labs/smoltcp/pull/110#discussion_r159982255
<GitHub69>
[smoltcp] whitequark commented on pull request #110 1f780bf: I am struggling to think of when this operation would have been semantically valid. It seems like a bug factory. Nevertheless, it is not needed as per above. https://github.com/m-labs/smoltcp/pull/110#discussion_r159981997