| Age | Commit message (Collapse) | Author |
|---|
|
This gives us a history, nicer editing capabilities and the possibility
to add completion in the future.
|
|
|
|
If we don't allow the higher-tier on the left side, we cannot chain
multiple or/and on the same level. Since or is associative, we shouldn't
expect the user to write (... or (... or ...)) and instead provide the
flattened version as well.
|
|
Otherwise they'd get tokenized as word and we couldn't build
conjunctions/disjunctions.
|
|
|
|
This method is not perfect yet, because
1. The items are not documented as they were before
2. You need to separate the args with --, otherwise Clap tries to parse
them as optional flags
This should be fixed (especially the documentation part) before merging
into master.
|
|
|
|
|
|
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, ...>).
|
|
|
|
This is the groundwork for introducing more complex filter queries like
`find` has. Filters can be arbitrarily combined with and/or/not and
support an "early filter" mode.
So far, the filters have been translated pretty mechanically to match
the current command line arguments, so now new syntax has been
introduced.
The NameFilter is not yet in its final version. The goal is to support
something like PlayerAll/PlayerExists and have a PlayerFilter that works
on single players instead of the complete log, but that might introduce
some code duplication as we then need a PlayerFilterAnd, PlayerFilterOr,
...
Some digging has to be done into whether we can reduce that duplication
without devolving into madness or resorting to macros. Maybe some
type-level generic hackery could be done? Maybe an enum instead of
dynamic traits should be used, at least for the base functions?
|
|
It's kinda silly to have new() be generic when all it does is box the
objects anyway. It only makes code harder to write, as we cannot unify
the types to call Pipeline::new(), and instead we have to rely on
calling Pipeline::new() in the branches themselves.
It's not the biggest issue when we only have different formats, but at
some point we might want to add different aggregators as well (like a
sorting one or a counting one), so it would be bad if we suddenly had to
add all those branches.
This fix changes that, and we can build the pipeline piecewise by
having a Box<dyn Format> around, allowing us to combine it freely with
any Box<dyn Aggregator>.
|
|
|
|
This also does away with the scary unsafe{} blocks just to set/get the
DEBUG flag.
|
|
|
|
Filtering based on guilds is slow, as it will have to retrieve every
guild name from the GW2 API, and it has to parse every log file instead
of bailing early.
Therefore, guilds are not searched by default, and have to be
explicitely turned on with --guilds.
In addition, this means that raidgrep will now need network access when
--guilds is passed, which was not the case before.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A lot of time is spent parsing the actual log events, especially when
they are zipped, as they have to be decompressed first. This results in
huge run-time hits, especially for files where we could determine very
early if we actually need it.
For example, player names are saved in the header, which can be examined
very quickly. If we can determine at that stage that a log file will not
appear in the result set, we don't need to parse all the log events.
This patch relies on the partial parsing support of evtclib to do
exactly that. It parses only the header with the player names, and only
if there's a match, it will proceed to parse the events and do more
filtering.
In the future, we can extend this even more, for example we can also
check the boss ID that way, since we can also access that in the header.
On the downside, we now have the zip handling logic replicated in
raidgrep, as we want a "common" interface to extract the actual data
stream. But this logic could be pushed back to evtclib after polishing
it a bit. There are some problems with Rust's borrow checking though,
which is why it looks a bit convoluted.
|
|
|
|
|
|
|
|
|
|
This gives a common interface for command line flags which take multiple
values, possibly with negation.
This might come in useful if we add filtering by boss, e.g. "--boss
!deimos" to ignore all deimos logs.
|
|
|
|
|
|
|
|
|
|
This accepts timestamps in the following formats:
* Human-readable, like "15d", taken relative to the current time.
* rfc3339-like "2018-03-14 13:13:00"
More formats might be added in the future.
|
|
|
|
|
|
The previous method was nice because it "just worked" for most of the
bosses, but with the introduction of W6 shenanigans (CA being a gadget,
and Largos Twins being two bosses), the method was a bit unreliable.
Now, the encounter ID that is saved by ArcDPS is used, and a predefined
list of encounter names is consulted, which makes this work better for
most bosses and allows us to change the name when appropriate
(Nightmare Oratuss -> Siax)
|
|
The way the parallel iterator splits the items, we get results from
different bosses intermixed. The expected way to do it would be to
search all logs related to a single boss first, before moving on, which
is not what rayon did. Additionally, it forced us to collect the list of
files into a vector first, before we could start the actual search.
Using the scoped pool directly solves both of these problems, but the
error handling suffered a bit, as we now use unwrap instead of returning
a Result from the closure. But since we handle individual items, and
might not want to stop just because a single item was faulty, this
behaviour might be better.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
