more tolerant NoSeek

[BKSalman]

I use serialport with the Box<dyn SerialPort> thing that it gives to read from the serial port, but it doesn't implement Seek, so I tried using NoSeek but it was a bit annoying and quite limited.

so I did this:

let mut reader = BufReader::new(serial_port);
loop {
    match reader.fill_buf() {
        Ok(mut incoming) => {
            let mut cursor = Cursor::new(incoming);
            match Event::read(&mut cursor) {
                Ok(event) => {
                    // go it :)
                    read += std::mem::size_of_val(&event);
                }
                Err(e) => {
                    // didn't get it :(

                    // advance by 1
                    read += 1;
                }
            }
            reader.consume(read);
            read = 0;
        }
        Err(e) => {
            // failed to fill buffer
            break;
        }
    }
}

is this bad? or decent enough to use?

[kitlith]

Looks like you have a different issue than what "NoSeek" is trying to solve, where you don't know where your data structure starts in your stream (or you're compensating for missing bytes, etc) in which case, yeah, you need to buffer it so you can seek around and try again.

One thing to note is that the size in memory of a binrw struct is not always the same as the number of bytes read from the stream. Unfortunately, we don't have an easy way to get the latter at the moment, but since you're using a cursor, you can extract it from the current cursor position.

If the issue is initial stream synchronization, (I.e. you're looking at a stream of events and don't know whether you're at the start or not) you could do something similar to your current code, and then switch to a NoSeek based implementation once you're synchronized. Wouldn't handle dropped/extra bytes though, if that's the issue you're having.

[BKSalman]

Looks like you have a different issue than what "NoSeek" is trying to solve, where you don't know where your data structure starts in your stream (or you're compensating for missing bytes, etc)

Yes, basically

One thing to note is that the size in memory of a binrw struct is not always the same as the number of bytes read from the stream. Unfortunately, we don't have an easy way to get the latter at the moment, but since you're using a cursor, you can extract it from the current cursor position.

Oh yeah that's a good point, completely forgot about that, thank you

If the issue is initial stream synchronization, (I.e. you're looking at a stream of events and don't know whether you're at the start or not) you could do something similar to your current code, and then switch to a NoSeek based implementation once you're synchronized. Wouldn't handle dropped/extra bytes though, if that's the issue you're having.

It's less of a stream and more of data comes in when something happens (therefore called an event), but not sure if it would make it better to deal with it like a stream or something (or if that's possible even)

Thank you for the reply :)