<GitHub49>
[smoltcp] whitequark commented on issue #11: I'm going to closing this PR because it seems like everything except the actual ARP cache iteration is already done, and iteration itself is something I would like to do quite differently. Feel free to open an issue requesting that. https://git.io/vdTMJ
<GitHub13>
[smoltcp] batonius commented on pull request #44 d6f204d: Apparently not, I've made it explicit. https://git.io/vdkeX
<GitHub18>
[smoltcp] batonius commented on pull request #44 d6f204d: Subnets have their own semantics, for example, 192.168.1.0/24 is exactly the same subnet as 192.168.1.255/24, this makes accepting a slice of subnets as interface addresses somewhat confusing. I've changed the documentation to better reflect the fact that CIRD != subnet, but I'd prefer to keep `Cidr` as the name. https://git.io/vdkv3
<GitHub165>
[smoltcp] batonius commented on pull request #44 d6f204d: I've rephrased it so the constructors check prefix_len and can fail now. https://git.io/vdkv8
<GitHub115>
[smoltcp] batonius commented on pull request #44 d6f204d: I was thinking about adding `contains_subnet` as well. https://git.io/vdkfl
<travis-ci>
batonius/smoltcp#88 (master - a7cdcd4 : whitequark): The build passed.
<GitHub161>
[smoltcp] whitequark commented on pull request #44 d6f204d: This is a really odd case, because so far every other data structure in `wire` has all fields `pub`. It's even in the module documentation. Thoughts? https://git.io/vdkJd
<travis-ci>
batonius/smoltcp#89 (default_route - f02bb34 : Egor Karavaev): The build was broken.
<GitHub51>
[smoltcp] batonius commented on pull request #44 59d883a: The idea was to prevent the creation of inconsistent values, instead of using `is_valid` method, since CIDRs have an invariant that needs to be enforced. https://git.io/vdkTq
mumptai has quit [Remote host closed the connection]
<sb0>
whitequark, do you have an idea about those errors:
<sb0>
Dwarf Error: Cannot find DIE at 0xa271 referenced from DIE at 0xe61a [in module /home/sb/ionpak/firmware/target/thumbv7em-none-eabihf/release/ionpak-firmware]
<sb0>
from gdb?
<sb0>
those kick in intermittently and are very annoying, it won't flash the board after that, and they happen on some compilations and not with others, even from the same source
<sb0>
oh I can just flash with openocd directly, maybe
<sb0>
and python-dateutil is in conda-forge, did you set that up as the doc tells you?
trxw has joined #m-labs
trxw has quit [Ping timeout: 260 seconds]
<jbqubit>
I had only dev branch installed. I can see from the instructions that dev is additive. "To use the development versions of ARTIQ, /also/ add the dev label." Consider emphasizing that both dev and main
<_florent_>
sb0: I'll retry installing artiq soon and will ask here if I need help
mumptai has joined #m-labs
<_florent_>
sb0: i just tried and got it working with the last instructions.
<jbqubit>
_florent_: are you using 64-bit Windows?
<whitequark>
mithro: hmmm, no idea, it was 2 years ago
<whitequark>
feel free to revert
<mithro>
whitequark: Do you understand that code at all? -- IE From what I can see only 116 bytes of the stack are used for saving registers later on, so I don't know why it needs 256?
<whitequark>
mithro: I can't remember a single thing about it anymore, no
<whitequark>
but it looks like my motivation was that
<whitequark>
maybe it's related to the red zone?
<mithro>
whitequark: I've heard references to this "red zone" what is it?
<whitequark>
mithro: so normally a function only accesses stack slots that are below SP
<whitequark>
erm
<whitequark>
above SP
<whitequark>
and it has to decrement SP in the prologue
<whitequark>
however, in some ABIs, leaf functions can access a certain number of bytes (usually 128) below SP without adjusting SP
<whitequark>
... yeah
<whitequark>
it was probably the red zone.
<whitequark>
let me recheck one thing
<travis-ci>
m-labs/rust-atomic_ring_buffer#6 (master - 4ac6645 : whitequark): The build was broken.