raidgrep/src/filters, branch v1.0.2 Guild Wars 2/arcdps evtc log searching tool fix BossFilter::filter_early 2020-04-29T14:18:02+00:00 Daniel kingdread@gmx.de 2020-04-29T14:18:02+00:00 f956baf7e6b77e48e3f845459560f1f8fb77eb7c 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. 
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.
update evtclib to 0.2.0 2020-04-29T13:49:24+00:00 Daniel kingdread@gmx.de 2020-04-29T13:49:24+00:00 16019515dffe4dd790adc72ed8a8ece8fc54c260 






use free functions instead of Filter::new
2020-04-25T11:19:42+00:00

Daniel
kingdread@gmx.de

2020-04-25T11:14:30+00:00

5dbea93266c3a30dac5ec6f5a7915d73a440f573

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).





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).







better error outputs
2020-04-21T11:59:28+00:00

Daniel
kingdread@gmx.de

2020-04-21T11:59:28+00:00

185a5b2f802f9d05c3eb40f807c0488f168c6661












make filters Debug
2020-04-18T13:10:59+00:00

Daniel
kingdread@gmx.de

2020-04-18T13:10:59+00:00

7030224fd2a97b3551fdd47c43249e3a42341238

It's nice if you can print out the filter tree for debugging, so we're
requireing filters to be Debug now.





It's nice if you can print out the filter tree for debugging, so we're
requireing filters to be Debug now.







split off player filters and log filters
2020-04-17T13:18:20+00:00

Daniel
kingdread@gmx.de

2020-04-17T13:18:20+00:00

ba491c8a5f6c8c2fa86b12dacf9d80f92da9168a

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, ...>).





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, ...>).