Stefan Sperling wrote on Wed, 18 Nov 2009 at 15:30 +0100: > On Wed, Nov 18, 2009 at 04:16:19PM +0200, Daniel Shahaf wrote: > > Stefan Sperling wrote on Wed, 18 Nov 2009 at 15:08 +0100: > > > On Wed, Nov 18, 2009 at 03:24:10PM +0200, Daniel Shahaf wrote: > > > > In this case, how about losing the "GROUP BY hunk" from the sort? i.e., > > > > > > > > BIG_LIST = [] > > > > for each hunk: > > > > for each candidate in hunk: > > > > compute a score for candidate > > > > BIG_LIST.append(candidate) > > > > # based on line offset, endifs, whatever > > > > > > > > sort BIG_LIST by score > > > > for each candidate in BIG_LIST: > > > > if candidate->hunk.state not in ['applied', 'rejected']: > > > > # try to apply candidate->hunk at candidate->offset > > > > > > What does to "try to apply" mean? > > > > > > > Maybe it just means "set hunk.state to 'applied'"; I forgot what other > > checks (apart from the applied/rejected check) had to be done before we > > decided "Yes, I decided to apply the hunk at <this> candidate". > > But making that decision is the entire point of the two sorts and the > iteration that follows them, which you meant to replace with the above? > > Maybe we need to take a step back: > What do you want to achieve by losing the "GROUP BY hunk" from the sort? >
You explained the rationale for your order-of-iteration as "consider the best offsets first". I think the BIG_LIST pseudocode I suggested above is a different way to realize this rationale. That pseudocode still inspects each hunk's candidates in order from best to worst (same as in your proposal), but it may consider one hunk's second- or third-best candidates before another hunk's first-best candidate. Daniel (thinking aloud) > Stefan >
