Age | Commit message (Collapse) | Author |
|
As it turns out, the padding bytes are not just padding, but for some
events they contain useful information. Therefore, we've adjusted the
parser to save those bytes (if available).
|
|
|
|
The reason why we "unwrap" the error so late is because we want to
recover from this error, which means the file pointer has to be at the
right position. Unwrapping early would leave the pointer in the middle
of an event, which is not what we want.
If we want to bullet-proof this, it might be good to read the whole
event first into a buffer, and then read from that buffer instead.
|
|
This is not defined by arcdps, but we'd have to adjust evtclib every
time a new statechange is introduced. This way, we stay
forward-compatible.
|
|
|
|
We can always do this conversion, because we can just throw away the
events field.
The other way around is not possible, as we need a file to parse the
events from.
|
|
|
|
|
|
|
|
The API guidelines for Rust state that readers should be taken by
value[1]. If the caller wants to re-use the reader, they have to borrow
it.
This patch adjusts the parsing functions to do just that.
[1]: https://rust-lang.github.io/api-guidelines/interoperability.html#generic-readerwriter-functions-take-r-read-and-w-write-by-value-c-rw-value
|
|
The .ok_or() method on Option is enough for those two occasions that we
don't need to activate the complete try_trait feature just for a very
small and questionable ergonomics gain. This also allows us to more
easily discern which data exactly was invalid, as the .ok_or() in
different places could take different error values.
This also allows evtclib to be used on stable now.
Some noise is introduced in the diff due to automatically re-formatting
the source.
|
|
thiserror seems to be the more modern approach that also works with the
new Error trait from std.
|
|
|
|
This comes with several changes:
First, the revision header field is now properly parsed and saved,
instead of just being hardcoded to zero. This is the first step in
allowing newer log files to be parsed. To accommodate this, the Header
struct has been extended with the "revision: u8" field.
To be able to parse both formats, the CbtEvent struct has been changed.
It is now the unification of both the new struct and the old struct, as
the changes are pretty minor and mostly concern the parsing itself. The
data types have been adjusted, and two fields have been added. Moving
fields around does not concern CbtEvent at all. If the struct diverges
more from this in the future, some splitting might be introduced, but
for now, the change is pretty transparent to other code.
During this process, the structs have lost their [repr(C]) property. It
was never used, as the structs were not directly involved in C FFI. It
has been a relic of the past from earlier iterations.
Finally, the parsing function has been changed from parse_event to
parse_event_rev0, with the addition of a parse_event_rev1. parse_events
now takes the event parsing function as an additional parameter, and
parse_file correctly choses the implementation based on the revision
number.
|
|
Somehow, new files (after ~2018-08-10) won't parse without this.
|
|
|
|
|
|
|
|
|