Ok, thanks for pointing out. But when I use the private function
enqeueTransfer() (made it public:)), I supply the transfer_id myself. So, I don’t use the heap allocated std::map.
Approved some PRs, I’m still not sure about the the StreamIterator one, but I think most of my hesitancy there is just because I’m a bit tired and I don’t like having to go back to
while (it reminds me of C ). I’ll probably like it more tomorrow (or maybe we just implement both Iterator and StreamingIterator?).
I also properly learned why rebasing your dev branch is a bad idea - I thought I could get away with that but I guess I didn’t, @alexander_huebener please double check the PRs, I may have messed something up and not noticed it.
Sorry all, I’ve been completely AWOL for the last month. I have a pretty tame finals season this year so I should be able to actually spend a bit of time over the next little while.
I went through, updated all the PRs (turns out unstable features are unstable and may have to be properly tracked, huh) and merged everything except for the CAN-FD PR. Still won’t merge that until it gets some proper testing (preferably on some real hardware) and also gets updated to the embedded-hal types.
Speaking of embedded-hal, looks like it’s going to release 1.0 soon, which also nicely includes the CAN types, which should mean we can update to them and use (hopefully) ecosystem-standard types for CAN.
Oh, I forgot. @pavel.kirienko can you remove uavcan.rs from TravisCI? AFAICT I’ve taken out all of the files but it’s still registering as a check step in github and making it impossible for anyone without admin to merge a PR.
Done (I think). Travis-CI was still listed as a required status check in GitHub branch protection rules, so I removed it from there.
May I suggest that we close all v0-related issues to clear the backlog?
That would be a good idea. I keep avoiding it because I keep thinking someone might go back to the v0 implementation some day but that’s definitely not happening at this point.