| 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.
|
|
|
|
Only minor changes are needed.
|
|
|
|
|
|
|
|
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.
|
|
|
|
This is better than re-implementing these functions, especially for the
fight outcome as it is more accurate.
|
|
|
|
|
|
|
|
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 allows things like "2m 50s" but also "5m".
humantime would allow even more, but we need a regular expression to
catch them for lalrpop, so for now this are the only two supported
formats (together with "50s"). Considering the usual time of fights in
GW2, I doubt we'll need anything bigger than minutes.
|
|
Since we have this information now anyway, might as well include it.
We're using humantime here, as that produces the expected "xxm yys zzms"
output. The conversion shouldn't fail (the unwrap), as we should never
encounter negative fight durations.
|
|
It seems a bit iffy to use the local timestamp to compute the fight
duration:
First of all, the event timestamps have higher precision, being counted
in milliseconds rather than seconds.
Second, it is more reliable, as we always have a first and a last event,
whereas the LogStart and LogEnd may not exist.
Third, we may want to change how this value is calculated in the future
anyway, as some bosses have a bit of a pre-log before the fight actually
starts (arcdps starts the log when you get into combat, which might be
before the boss actually spawns, like on Ensolyss).
In either case, this function is probably a strong contender for being
implemented properly in evtclib.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
The --check flag will check the given file and set the exit status
accordingly.
|
|
|
|
|
|
|
|
|
|
We changed the descending prefix to be ~ earlier, so now we need to
adjust the tests as well.
|
|
|
|
Since - leads to structopt interpreting the component as the start of
another argument, we need to use a different one.
|
|
|
|
This does currently not work yet, as we cannot call .finish() on dyn
Aggregator. This needs to be adjusted.
However, this provides the basic infrastructure for producing sorted
output, including the required command line parsing.
|
|
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.
|
|
The easiest way to get this consistent is to implement PartialOrd & Ord
for Player. However, the implementation might not be 100% sound, as it
should be using the same fields as (Partial)Eq, but that would mean
either
1. Deriving PartialOrd/Ord, which is not possible because PlayerClass
does not implement it (which in turn would not make sense to order)
or
2. Implementing (Partial)Eq by hand instead of deriving it, which is not
the best either
I don't think it's an issue though, as we never put Players in any
position where it might get relevant (such as a HashMap/BTreeMap), and
we're only using it to sort them for the output.
|
|
|
|
Most users probably don't need the capitalization, and character names
always have a predefined capitalization anyway.
|
|
|
|
|
|
|
|
|
|
This causes issues with the player: prefix used in any() and all()
constructs, as player: will now be parsed as a word instead of the
proper token. For now, : is disallowed in words again until there is a
better solution.
|
|
Away with stringly typed stuff, we now have a proper way to save the
profession of a player without relying on a string. Theoretically, that
is better for memory consumption, as we now save only the identifier and
use fmt::Display and static strings, but that was not the main reason
for this change.
The main reason is that now we can programatically work with the
profession and elite spec, so that we can (for example) implement a
filter to filter players based on their class.
The word "class" has been chosen because it is a common synonym for the
profession/elite, and because this is neither a profession nor the elite
- it's a combination of both.
|
|
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 avoids unwrapping (and therefore panicing) when the path doens't
have a parent. It also avoids the explicit Into::into() calls.
|
