| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Some of these unwraps are fine to stay, mostly those that deal with
locks - in this case, crashing the program if something goes wrong is
probably fine.
However, we also had a lot of other places where we panic'd on errors,
even though we really shouldn't have. For example, an invalid zip file
would bring down the whole scanner. In this case, we now use proper
Result<>s and we log the error.
Some places stay with unwrap() for now, mainly the code that is rare and
obvious when it goes wrong - such as an overflow in input values. It
could be made nicer, but it is not a priority for now.
Some unwraps() have been changed to expect() to signal why they
shouldn't fail.
|
|
|
|
There's a good chance that this will be evtclib 0.5, so we want to adapt
our API usage (mainly replacing evtclib::Boss with evtclib::Encounter).
The naming is a bit all over the place now, as we sometimes refer to
bosses and sometimes to encounters, but I hope to make a sensible
decision at *some point* about what we're actually doing here.
|
|
|
|
|
|
It makes sense to unify this implementation to avoid code duplication
and bugs that might be hidden. -after and -before can stay for now, as
shortcuts for -time < and -time >, the same way we have other shortcuts
as well.
|
|
|
|
|
|
|
|
|
|
This enables filters such as
-time > 2020-01-01
-time < 2020-02-03
...
for time and duration, and later possibly also for more things (such as
a COUNT(...) construct).
This work tries to integrate them into the existing filter system as
seamless as possible, by providing a Comparator which implements
LogFilter.
The "type checking" is done at parse time, so nonsensical comparisons
like -time > 12s flat out give a parse error. This however might be
changed to a more dynamic system with run-time type checking, in which
case we could do away with the type parameter on Producer and simply
work with a generic Value. The comparator would then return an error if
two non-identical types would be compared.
Note that the system does not support arithmetic expressions, only
simple comparisons to constant values.
|
|
With the addition of our own parser, we no longer need the FromStr
implementation for SearchField. Furthermore, it is now only used in
player::NameFilter, so the definition has been moved there. The import
in the grammar was unused as well, so it has been removed.
|
|
|
|
|
|
|
|
Rust doesn't necessarily need this, but it's good formatting to include
it anyway.
|
|
With the file name heuristic for -before and -after in place, we might
want a way for the user to disable it. For now, we simply do this by
providing a new set of predicates without the filter.
In the future, we might have a --disable-heuristics switch to disable
the heuristics, in case we ever add more.
|
|
This allows the date-based filters to work much faster.
|
|
This allows us to attach some additional metadata that is not found in
the PartialEvtc otherwise, such as the file name.
|
|
As it turns out, the "local timestamp" as advertised by arcdps is a bit
misleading, because the timestamp is still in UTC. The "local" refers to
the fact that it can lag behind the server timestamp a bit (but usually
they seem to be within +-1 of each other), not that the timestamp is in
the local timezone.
This makes date handling a bit harder for raidgrep, but thanks to
chrono, not by much. The idea is that we simply deal with Utc pretty
much everywhere, except at the user boundary. This means that
1. Input timestamps for -before and -after are converted to Utc right
after input
2. When outputting, we convert to a local timestamp first
This makes the output consistent with the filenames now (and the "wall
time" that the player saw).
|
|
If the boss is unknown, we exclude the log - that is how
BossFilter::filter operates, and it is probably what the user wants if
they specify a -boss filter. However, in filter_early, the default for
unknown bosses was to return Inclusion::Include, which is not consistent
with filter. That lead to some logs being included, parsed and then
thrown away again.
This change makes the behaviour for unknown bosses between filter_early
and filter consistent, and therefore speeds up the search if -boss is
used.
|
|
|
|
Having a ::new on each of the filter types was a bit weird, especially
because we returned Box<dyn ...> instead of Self (and clippy rightfully
complained). With this patch, we now have a bunch of normal functions,
and we don't show to the outside how a filter is actually implemented
(or what struct is behind it).
|
|
|
|
It's nice if you can print out the filter tree for debugging, so we're
requireing filters to be Debug now.
|
|
As it turns out, we can easily re-use the existing Filter machinery to
generalize over LogFilters (which operate on LogResults) and
PlayerFilters (which operate on Players).
The feature trait_aliases is not strictly needed but makes the function
signatures a bit nicer and easier to read, and it reduces the chances of
an error (e.g. by using Filter<&PartialEvtc, ...>).
|
