New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented segmented find_end and find_first_of for partitioned vector #2793

Open
wants to merge 38 commits into
from

Conversation

4 participants
@ajaivgeorge
Contributor

ajaivgeorge commented Aug 1, 2017

PR #2792 should be merged before this.

Tasks completed as part of GSoC project (See: #1338) -

  • Implemented segmented find_end and associated function object
  • Implemented segmented find_first_of and associated function object.
  • Using a custom return type called find_return
  • Almost all test cases pass for both for Localities = 1 to 11 Threads = 4 for both algorithms.

Pending work -

  • Overlapping prefix or suffix test case fails for parallel version of the algorithms. To reproduce run find_end test with localities = 7 or find_first_of test with localities = 4. Example if sequence is 1111 and vector is 11 | 1111 | 1111 both find_end and find_first of gives erroneous outputs due to the need for returning multiple partial sequences from each segment.

  • Need to reverse the iteration of segments in sequential find_end (send to sit instead of sit to send). This will result in better performance and handle a lot of possible errors.

ajaivgeorge added some commits Jul 5, 2017

Sequential Segmented find end partially complete.
Current error is related to serialization. Need to implement
algorithm result helpers.
Added return type helpers in dispatch and segmented dispatch, changed…
… sequence argument from iterators to std::vector
@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 1, 2017

Contributor

@hkasier and @mcopik Please have a look.

Contributor

ajaivgeorge commented Aug 1, 2017

@hkasier and @mcopik Please have a look.

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 1, 2017

Contributor

@hkaiser The general approach for both algorithms is to return three different pieces of information from each segment:

  • is there a full match of the subsequence
  • is there a partial suffix match at the beginning of the segment
  • is there a partial prefix match at the end of the segment

A post-processing merges results from segments by looking for match spanning multiple segments. This algorithm is much more complex than the parallel non-segmented implementation, where a thread can find a match spanning multiple partitions by simply taking a look at data in the next partition. Such approach would be very inefficient in a segmented algorithm.

@ajaivgeorge I think there should be a comment giving a brief overview of the algorithm. Now it might be quite hard to understand what is happening there.

Contributor

mcopik commented Aug 1, 2017

@hkaiser The general approach for both algorithms is to return three different pieces of information from each segment:

  • is there a full match of the subsequence
  • is there a partial suffix match at the beginning of the segment
  • is there a partial prefix match at the end of the segment

A post-processing merges results from segments by looking for match spanning multiple segments. This algorithm is much more complex than the parallel non-segmented implementation, where a thread can find a match spanning multiple partitions by simply taking a look at data in the next partition. Such approach would be very inefficient in a segmented algorithm.

@ajaivgeorge I think there should be a comment giving a brief overview of the algorithm. Now it might be quite hard to understand what is happening there.

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 1, 2017

Contributor

@ajaivgeorge As I said in our conversations, I think the best course of action for the corner case of multiple, overlapping prefix/suffix matches is to return a range of matches instead of a single position. I don't see a simpler solution.

Contributor

mcopik commented Aug 1, 2017

@ajaivgeorge As I said in our conversations, I think the best course of action for the corner case of multiple, overlapping prefix/suffix matches is to return a range of matches instead of a single position. I don't see a simpler solution.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 1, 2017

Member

@mcopik, ok - thanks. The biggest problem will be to create a representative set of tests, however.

Member

hkaiser commented Aug 1, 2017

@mcopik, ok - thanks. The biggest problem will be to create a representative set of tests, however.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 1, 2017

Member

@ajaivgeorge, @mcopik: another question - does your algorithm properly handle matching subsequences spanning more than 2 partitions?

Member

hkaiser commented Aug 1, 2017

@ajaivgeorge, @mcopik: another question - does your algorithm properly handle matching subsequences spanning more than 2 partitions?

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 1, 2017

Contributor

@hkaiser we have discussed the case of a subsequence spanning multiple segments and Ajai has worked on this. I think that's the purpose of a nested while loop in dataflow following the parallel execution on segments.

@ajaivgeorge perhaps the code there requires few small comments, I'm hardly following it with name variable names.

Contributor

mcopik commented Aug 1, 2017

@hkaiser we have discussed the case of a subsequence spanning multiple segments and Ajai has worked on this. I think that's the purpose of a nested while loop in dataflow following the parallel execution on segments.

@ajaivgeorge perhaps the code there requires few small comments, I'm hardly following it with name variable names.

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 2, 2017

Contributor

I will add more comments to all the 4 segmented_find_end/first_of functions and the function objects.

Contributor

ajaivgeorge commented Aug 2, 2017

I will add more comments to all the 4 segmented_find_end/first_of functions and the function objects.

ajaivgeorge added some commits Aug 2, 2017

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 2, 2017

Contributor

@hkaiser , I am checking find_end and find_first_of for multiple sequences in the test for Localities = 1 to 9 and 11. (10 fails because of the segmentation of vector of size 64 gives an assert error at the last segment). This should catch most of the possible cases. I am sure I am missing quite a few test cases and I will add them as I find them. And yes, the algorithm does work with spanning sequence and I have added a test case for it (It spans more than 2 segments at localities = 7,8). Right now I am fixing the overlapping prefix error.

Contributor

ajaivgeorge commented Aug 2, 2017

@hkaiser , I am checking find_end and find_first_of for multiple sequences in the test for Localities = 1 to 9 and 11. (10 fails because of the segmentation of vector of size 64 gives an assert error at the last segment). This should catch most of the possible cases. I am sure I am missing quite a few test cases and I will add them as I find them. And yes, the algorithm does work with spanning sequence and I have added a test case for it (It spans more than 2 segments at localities = 7,8). Right now I am fixing the overlapping prefix error.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 2, 2017

Member

10 fails because of the segmentation of vector of size 64 gives an assert error at the last segment

Could you create a small reproducing test case and submit a ticket describing the issues you're having, please?

Member

hkaiser commented Aug 2, 2017

10 fails because of the segmentation of vector of size 64 gives an assert error at the last segment

Could you create a small reproducing test case and submit a ticket describing the issues you're having, please?

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 4, 2017

Contributor

@hkaiser After an update with the hpx/master, there is no assert error. The test still fails for localities=10 and works for all other localities(tested till localities = 13). This is probably specific to my find_end/first_of implementation, I wasn't able to recreate the error with transform/for_each/reduce/or the scans.

Contributor

ajaivgeorge commented Aug 4, 2017

@hkaiser After an update with the hpx/master, there is no assert error. The test still fails for localities=10 and works for all other localities(tested till localities = 13). This is probably specific to my find_end/first_of implementation, I wasn't able to recreate the error with transform/for_each/reduce/or the scans.

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 4, 2017

Contributor

@hkaiser There is an issue with find_end having different return types in a sequential and parallel implementation. Unfortunately, the detail::algorithm structure does not allow this. The question is: is it worth refactoring this dispatch class if the difference is maybe one or two integers more in parallel version?

@ajaivgeorge, how large is the difference in return types? Is it only difference naming in parallel or do you have to return empty bytes in a sequential execution?

Contributor

mcopik commented Aug 4, 2017

@hkaiser There is an issue with find_end having different return types in a sequential and parallel implementation. Unfortunately, the detail::algorithm structure does not allow this. The question is: is it worth refactoring this dispatch class if the difference is maybe one or two integers more in parallel version?

@ajaivgeorge, how large is the difference in return types? Is it only difference naming in parallel or do you have to return empty bytes in a sequential execution?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 4, 2017

Member

@mcopik What are the different required return types?

Member

hkaiser commented Aug 4, 2017

@mcopik What are the different required return types?

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 4, 2017

Member

@ajaivgeorge How can I reproduce the problem with 10 localities?

Member

hkaiser commented Aug 4, 2017

@ajaivgeorge How can I reproduce the problem with 10 localities?

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 4, 2017

Contributor

@mcopik I need only two more size_t types to store the cursor of the last overlapping prefix/suffix found. These would be 0 in the sequential.

@hkaiser The position of the iterator ie (std::distance(first, return)) comes out to be -1 when localities = 10 for the test case in L119 and L122 in the find_end unit test (similarly in find_first_of). I am trying to figure out how and why this can happen. To reproduce the error just run that test case with localities=10 threads=4. The test case works for localities=7,8,9,11,12,13, and in all these cases the sequence is spanning more than 2 segments.

Contributor

ajaivgeorge commented Aug 4, 2017

@mcopik I need only two more size_t types to store the cursor of the last overlapping prefix/suffix found. These would be 0 in the sequential.

@hkaiser The position of the iterator ie (std::distance(first, return)) comes out to be -1 when localities = 10 for the test case in L119 and L122 in the find_end unit test (similarly in find_first_of). I am trying to figure out how and why this can happen. To reproduce the error just run that test case with localities=10 threads=4. The test case works for localities=7,8,9,11,12,13, and in all these cases the sequence is spanning more than 2 segments.

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 7, 2017

Contributor

@hkaiser If I understand correctly, parallel version should return a structure with two more variables. @ajaivgeorge, am I right?

Contributor

mcopik commented Aug 7, 2017

@hkaiser If I understand correctly, parallel version should return a structure with two more variables. @ajaivgeorge, am I right?

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 7, 2017

Contributor

@mcopik Yes, parallel version should return a structure with two more variables.

Also, i have been working on this (overlapping prefixes and suffixes) in the segmented_find_end2. Haven't had much luck here. There are way too many cases. For example when searching for {123123123123} in {..123|123123123123123123123|123...}. What should the middle segment return? There are 3 overlapping prefixes and suffixes each with a stride of 3. How should the inner while loop work in this case?

I am also working on the segmented_find_end3 branch which contains the reversed sequential find_end implementation. This is almost done.

Contributor

ajaivgeorge commented Aug 7, 2017

@mcopik Yes, parallel version should return a structure with two more variables.

Also, i have been working on this (overlapping prefixes and suffixes) in the segmented_find_end2. Haven't had much luck here. There are way too many cases. For example when searching for {123123123123} in {..123|123123123123123123123|123...}. What should the middle segment return? There are 3 overlapping prefixes and suffixes each with a stride of 3. How should the inner while loop work in this case?

I am also working on the segmented_find_end3 branch which contains the reversed sequential find_end implementation. This is almost done.

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 7, 2017

Contributor

@ajaivgeorge The question is if it will be enough to encode the information about multiple prefixes by using two integers: begin and stride. I think the answer to this question is positive since repeating blocks in the subsequence have to have the same length. Only the last match can be shorter. But the algorithm is getting more and more complex, you're right about that.

Contributor

mcopik commented Aug 7, 2017

@ajaivgeorge The question is if it will be enough to encode the information about multiple prefixes by using two integers: begin and stride. I think the answer to this question is positive since repeating blocks in the subsequence have to have the same length. Only the last match can be shorter. But the algorithm is getting more and more complex, you're right about that.

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 7, 2017

Contributor

ajaivgeorge I think these observations hold for any subsequence. I haven't verified it carefully, so there might be a mistake somewhere there. What do you think?

I don't think that one could have multiple matches when the subsequence is not of a form X ... X Y, where Y is a prefix of X.

  • if a first prefix match Y is found, then the second match consists of blocks X and Y, where len(X) >= len(Y). You can use that information to start looking for a second match by looking at the subsequence itself, not at the segment data. Finding the second match for Y in the subsequence gives you X (everything before the match), which has to be representable as: Y Y', where Y' may be empty; otherwise the subsequence X Y ... would not validate the first match. If the subsequence can be represented as Y Y' Y ..., then you can use the length of X to verify the existence of a second match in the segment without explicitly looking for it. Simply loop at given positions and check if the segment contains X before Y.
  • later, each match has to be of form X ... X Y which makes the lookup trivial.
Contributor

mcopik commented Aug 7, 2017

ajaivgeorge I think these observations hold for any subsequence. I haven't verified it carefully, so there might be a mistake somewhere there. What do you think?

I don't think that one could have multiple matches when the subsequence is not of a form X ... X Y, where Y is a prefix of X.

  • if a first prefix match Y is found, then the second match consists of blocks X and Y, where len(X) >= len(Y). You can use that information to start looking for a second match by looking at the subsequence itself, not at the segment data. Finding the second match for Y in the subsequence gives you X (everything before the match), which has to be representable as: Y Y', where Y' may be empty; otherwise the subsequence X Y ... would not validate the first match. If the subsequence can be represented as Y Y' Y ..., then you can use the length of X to verify the existence of a second match in the segment without explicitly looking for it. Simply loop at given positions and check if the segment contains X before Y.
  • later, each match has to be of form X ... X Y which makes the lookup trivial.

@hkaiser hkaiser added this to Work in progress in Standard Algorithms Aug 8, 2017

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 8, 2017

Contributor

@mcopik, So the current prefix finding method would be modified like this -

  1. Search for Y ie the first prefix.
  2. Search for YY'Y (ie XY)
  3. Search for number of consecutive X's
  4. Return the cursor (sequence position) of the last element of Y, the size of X, the number of X's found and the segment position (iterator) of the start of Y or of XXXX..Y (Any one of them is needed for the final return)
    Similarly suffix has to be found with 3 returns - in UVVVV where V is U'U, I have to return the first element of U, size of V and the number of V's. Segment position is not needed for suffix.

Finally for matching -

  1. If number of X's = 0 in prefix use current method.
  2. Otherwise compare last_position of prefix Y with the (i*size of V) + first_position of suffix U where i ranges from 0 to number of V's. Decrement last_position of Y by size of X in a loop for number of X's and repeat the above comparison. (There has to be some optimisation that I am missing - the above method leads to number of X's * number of V's comparisons)
  3. find_first_of would be similar except instead of starting at last_position of Y, we start at last_position of Y - number of X * size of X. So that preference is given to starting sequence.

One more issue is more than 2 segment spanning overlapping sequences. For example when searching for {123123123123} in {...123123|123123|123123...}. I am trying to figure out ways to integrate all of the above with this kind of case.

The total number of returns needed is 6 size_ts + 2 iterators (If complete sequence found in segment that needs another iterator)

Contributor

ajaivgeorge commented Aug 8, 2017

@mcopik, So the current prefix finding method would be modified like this -

  1. Search for Y ie the first prefix.
  2. Search for YY'Y (ie XY)
  3. Search for number of consecutive X's
  4. Return the cursor (sequence position) of the last element of Y, the size of X, the number of X's found and the segment position (iterator) of the start of Y or of XXXX..Y (Any one of them is needed for the final return)
    Similarly suffix has to be found with 3 returns - in UVVVV where V is U'U, I have to return the first element of U, size of V and the number of V's. Segment position is not needed for suffix.

Finally for matching -

  1. If number of X's = 0 in prefix use current method.
  2. Otherwise compare last_position of prefix Y with the (i*size of V) + first_position of suffix U where i ranges from 0 to number of V's. Decrement last_position of Y by size of X in a loop for number of X's and repeat the above comparison. (There has to be some optimisation that I am missing - the above method leads to number of X's * number of V's comparisons)
  3. find_first_of would be similar except instead of starting at last_position of Y, we start at last_position of Y - number of X * size of X. So that preference is given to starting sequence.

One more issue is more than 2 segment spanning overlapping sequences. For example when searching for {123123123123} in {...123123|123123|123123...}. I am trying to figure out ways to integrate all of the above with this kind of case.

The total number of returns needed is 6 size_ts + 2 iterators (If complete sequence found in segment that needs another iterator)

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 8, 2017

Member

@ajaivgeorge Sorry if I misunderstood things, but why has the segmented algorithm to be different from the non-segmented one? In the end we have to return one match (the first one) only. The tricky part is if one of the segments ends in a partial match in which case we need to retry the adjacent segment checking whether it starts with the remainder of the partial match, etc.

Member

hkaiser commented Aug 8, 2017

@ajaivgeorge Sorry if I misunderstood things, but why has the segmented algorithm to be different from the non-segmented one? In the end we have to return one match (the first one) only. The tricky part is if one of the segments ends in a partial match in which case we need to retry the adjacent segment checking whether it starts with the remainder of the partial match, etc.

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 8, 2017

Contributor

@hkaiser We're trying to solve this problem by a two-step lookup: a local partial lookup on each segment and a global accumulation of local results. For the second step, one needs the information about prefix and suffix matches in the segment. The non-segmented algorithm is allowed to read data in another partition because it is located in the same global memory of a locality. The segmented one could do the same, but that would require dispatching work between localities and the dispatched function has to know on which locality is the next segment located. Furthermore, it might lead to a sequential chain of calls when the subsequence spans multiple segments. There, you actually might need to know the full segment distribution across localities.

Do you think that a nested dispatch would result in a solution with lower latency? Or did you have another solution on your mind?

Contributor

mcopik commented Aug 8, 2017

@hkaiser We're trying to solve this problem by a two-step lookup: a local partial lookup on each segment and a global accumulation of local results. For the second step, one needs the information about prefix and suffix matches in the segment. The non-segmented algorithm is allowed to read data in another partition because it is located in the same global memory of a locality. The segmented one could do the same, but that would require dispatching work between localities and the dispatched function has to know on which locality is the next segment located. Furthermore, it might lead to a sequential chain of calls when the subsequence spans multiple segments. There, you actually might need to know the full segment distribution across localities.

Do you think that a nested dispatch would result in a solution with lower latency? Or did you have another solution on your mind?

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 8, 2017

Contributor

@hkaiser - The algorithm for both find_end and find_first_of as implemented now does work very similar to the non segmented version ie it looks for a complete match in the segment (using the same algorithm as non segmented) and also keeps track of suffix of sequence at beginning and prefix of sequence at the end of the segment. This is done in such a way that the case of a sequence spanning more than 2 segments is also handled. This is working as shown by the test cases for almost all the test cases.

The above complications are for the parallel version of the algorithms in the very specific case of overlapping prefixes or suffixes in a segment. This is what Marcin's algorithm is trying to solve.

Contributor

ajaivgeorge commented Aug 8, 2017

@hkaiser - The algorithm for both find_end and find_first_of as implemented now does work very similar to the non segmented version ie it looks for a complete match in the segment (using the same algorithm as non segmented) and also keeps track of suffix of sequence at beginning and prefix of sequence at the end of the segment. This is done in such a way that the case of a sequence spanning more than 2 segments is also handled. This is working as shown by the test cases for almost all the test cases.

The above complications are for the parallel version of the algorithms in the very specific case of overlapping prefixes or suffixes in a segment. This is what Marcin's algorithm is trying to solve.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 12, 2017

Member

What's the status of this? Could we get an update, please?

Member

hkaiser commented Aug 12, 2017

What's the status of this? Could we get an update, please?

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Aug 12, 2017

Contributor

@hkaiser, I am still working on the overlapping prefix fix. That involves a complete change in the algorithm for just that particular fix.

@mcopik. I am also working on the other algorithms I had sent in an email. Please confirm if those are alright instead of sort and merge. Also can you confirm if the description I gave of your proposed method (5 comments above) is the right one?

Contributor

ajaivgeorge commented Aug 12, 2017

@hkaiser, I am still working on the overlapping prefix fix. That involves a complete change in the algorithm for just that particular fix.

@mcopik. I am also working on the other algorithms I had sent in an email. Please confirm if those are alright instead of sort and merge. Also can you confirm if the description I gave of your proposed method (5 comments above) is the right one?

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Aug 15, 2017

Contributor

@ajaivgeorge I think the description is fine. I think that with these update you could find first/last match for subsequences spanning multiple segments, even for all corner cases.

Contributor

mcopik commented Aug 15, 2017

@ajaivgeorge I think the description is fine. I think that with these update you could find first/last match for subsequences spanning multiple segments, even for all corner cases.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Aug 15, 2017

Member

@ajaivgeorge Please resolve the conflicts with master, we can't merge otherwise.

Member

hkaiser commented Aug 15, 2017

@ajaivgeorge Please resolve the conflicts with master, we can't merge otherwise.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Sep 5, 2017

Member

Now that GSoC is formally over - what is the state of this PR?

Member

hkaiser commented Sep 5, 2017

Now that GSoC is formally over - what is the state of this PR?

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Sep 6, 2017

Contributor

@ajaivgeorge How far are you from fixing the problem with overlapping prefixes?

Contributor

mcopik commented Sep 6, 2017

@ajaivgeorge How far are you from fixing the problem with overlapping prefixes?

@ajaivgeorge

This comment has been minimized.

Show comment
Hide comment
@ajaivgeorge

ajaivgeorge Sep 7, 2017

Contributor

@mcopik I have started working on it on another branch but it is nowhere near ready. I have exams next week, so this will be delayed further.

@hkaiser In the meantime, both find_end and find_first_of work well for all the cases except the case that I have described above. I think this PR should be merged as is. I can add a comment above the algorithm describing the failing case (if so, where algorithms/find.hpp or segmented_algorithms/find.hpp?)

The changes required to handle that particular case will introduce a lot of additional complexity and would probably slow down the algorithm in general. In a future PR after that algorithm is ready, I will add performance tests for both and then we can have a discussion on what changes are required.

Contributor

ajaivgeorge commented Sep 7, 2017

@mcopik I have started working on it on another branch but it is nowhere near ready. I have exams next week, so this will be delayed further.

@hkaiser In the meantime, both find_end and find_first_of work well for all the cases except the case that I have described above. I think this PR should be merged as is. I can add a comment above the algorithm describing the failing case (if so, where algorithms/find.hpp or segmented_algorithms/find.hpp?)

The changes required to handle that particular case will introduce a lot of additional complexity and would probably slow down the algorithm in general. In a future PR after that algorithm is ready, I will add performance tests for both and then we can have a discussion on what changes are required.

@hkaiser

This comment has been minimized.

Show comment
Hide comment
@hkaiser

hkaiser Jan 26, 2018

Member

@ajaivgeorge, @mcopik what will happen to this PR? Should we abandon it? How much work is left to get this into the main branch?

Member

hkaiser commented Jan 26, 2018

@ajaivgeorge, @mcopik what will happen to this PR? Should we abandon it? How much work is left to get this into the main branch?

@mcopik

This comment has been minimized.

Show comment
Hide comment
@mcopik

mcopik Jan 29, 2018

Contributor

@hkaiser find_first_of doesn't handle all corner cases correctly. @ajaivgeorge do you have time to finish this PR?

Contributor

mcopik commented Jan 29, 2018

@hkaiser find_first_of doesn't handle all corner cases correctly. @ajaivgeorge do you have time to finish this PR?

@msimberg msimberg removed this from the 1.1.0 milestone Mar 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment