Search confguration/on result release #2019
Conversation
rrahn
force-pushed
the
search_confguration/on_result_release
branch
from
8dcff4b
to
41cdc10
Compare
I know, but I accidently rebased some stuff from master locally and so I decided to make a clean branch from the release branch. |
I'll grep for it and update all occurrences. |
rrahn
force-pushed
the
search_confguration/on_result_release
branch
from
41cdc10
to
205ecaa
Compare
Codecov Report
@@ Coverage Diff @@
## release-3.0.2 #2019 +/- ##
=================================================
- Coverage 97.90% 97.89% -0.01%
=================================================
Files 262 263 +1
Lines 9863 9879 +16
=================================================
+ Hits 9656 9671 +15
- Misses 207 208 +1
Continue to review full report at Codecov.
|
| @@ -92,6 +93,9 @@ struct search_traits | |||
| output_reference_id | | |||
| output_reference_begin_position | | |||
| output_index_cursor; | |||
|
|
|||
| //!\brief A flag indicating whether a user provided callback was given. | |||
| static constexpr bool is_one_way_execution = search_configuration_t::template exists<search_cfg::on_result>(); | |||
There was a problem hiding this comment.
I am confused with the naming. "Two-way execution" I first got to know when you introduced it in the context of executors/parallelization (or do I remember that wrongly?). Now you use one-way execution for a user defined callback? Can we maybe rather use something like has_user_defined_callback?
EDIT: I see below that you use it to differentiate between executors. Can you change the brief then? If the user provides a callback, we need to use a one_way_execution...
There was a problem hiding this comment.
This is the point. In the executor context two-way means that it returns something to the user he can wait for and one-way means it does not return anything but just executes it and the user needs to make sure the code is handled properly. But I see that the term might be confusing and I will rename it.
| * | ||
| * In the default case, a call to seqan3::search returns a lazy range over the results of the search. This lazy range | ||
| * has the advantage that the results are always in a deterministic order even if the search is executed in parallel. | ||
| * Sometimes, however, it might be challenging to provide a user defined callback. |
There was a problem hiding this comment.
| * Sometimes, however, it might be challenging to provide a user defined callback. | |
| * Sometimes, however, it might be preferred to provide a user defined callback. |
? Why should it be challenging
There was a problem hiding this comment.
Ask @eseiler 😏 I had demanding.
There was a problem hiding this comment.
demanding in this context means difficult; but obviously you meant preferred, I just didn't catch your meaning :)
There was a problem hiding this comment.
Ok, what I actually meant was desirable
The algorithms are initialsied during construction with the configuration object. This commit removes the superfluous copy of the configuration object and changes the initialisation of the policies accordingly.
This configuration element can be used to provide a user defined callback to the search algorithm.
Later when we configure the result type we need a way to avoid default instantiation of the configuration object due to the semiregularbox needed to store the callback. This version makes use of the get_or interface and using a dedicated empty search result type definition.
Enables the second execution path of the search when on_result was specified. The search becomes a void function and bulk_executes the algorithm with the given user callback.
rrahn
force-pushed
the
search_confguration/on_result_release
branch
from
714aaf3
to
473a8eb
Compare
Supersedes #2012
fixes seqan/product_backlog#169