| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
This persists the REPL history across program restarts.
The code should probably be cleaned up a bit more, the error handling in
this one is a bit all over the place. This is because we don't want to
make it a hard error in case the history cannot be saved.
|
|
With evtclib being on crates.io now (and generally, being available
publicly through git), there is no longer a need to have a copy of the
evtclib repository in this repository. The main reason was that evtclib
was private when I started it, so the easiest way to include it was
through a git submodule. That reason is no longer valid.
If we really *need* to use the git version, it is also better to just
point Cargo to the repository and let it deal with keeping the
repository up-to-date, rather than using git submodules.
This commit also updates Cargo.lock, so there is a bit of noise from
also adding ctrlc as a dependency.
|
|
This is not yet perfect, as it seems to still execute all queued threads
just to immediately exit them, so maybe we should try and see if we can
"clear" the rayon queue. But it's a good start, and the ctrlc crate
seems to work well for this job.
|
|
First of all, this allows : to be part of a word. This has been added
because the account names start with a colon, so -player :Dunje should
work.
Furthermore, the re-quoting now also quotes strings that contain a .+*,
as those are characters usually used in regular expressions. A command
line like
raidgrep -- -player "G.dric"
should work, so we either have to re-quote words with a dot, or allow
the dot to be part of a (lexical) word as well. For now, we're
re-quoting it, but if it turns out to be too troublesome, we might
change that.
|
|
This allows us to attach some additional metadata that is not found in
the PartialEvtc otherwise, such as the file name.
|
|
They are usually within minutes of each other, but this has two
advantages:
1. The output is consistent with the filename (and probably the file
creation date, if it has been preserved)
2. Due to 1., this means we can use the filename to get the timestamp
faster than parsing the file.
|
|
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).
|
|
Everybody calls bosses by different names (Soulless Horror vs Desmina,
Super Kodan Brothers, ...), so it might be good to have a list ready in
the help message.
Other names can still be used, but those are the end-user documented
ones now.
|
|
|
|
|
|
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).
|
|
Since our predicates start with -, this sounds like a good heuristic to
prevent something like "raidgrep -- -player" from silently succeeding
but not doing what the user had intended. In this case, we want the
parse error to show and not treat "-player" as a regex.
|
|
|
|
First, this commit adds a shortcut if only a single argument is given
that can be parsed as a regex. This is to retain the old behaviour of
"raidgrep NAME" just working, without needing to specify -player or
anything.
Secondly, this also re-wraps arguments with spaces (unless there's only
one argument in total). This means that the following should work:
raidgrep -- -player "Godric Gobbledygook"
instead of either
raidgrep -- '-player "Godric Gobbledygook"'
raidgrep -- -player '"Godric Gobbledygook"'
(notice the extra quotes).
|
|
|
|
Sadly, structopt always displays this, despite the documentation stating
that it should be hidden when the user uses -h (instead of --help). It
seems like this is a bug in clap, which might get fixed with clap 3.0.
|
|
This gives us a history, nicer editing capabilities and the possibility
to add completion in the future.
|
|
|
|
|
|
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.
|
|
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?
|
|
|
|
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.
|
|
|
