| 1 |
On Fri, Dec 09, 2005 at 08:07:47AM +0900, Jason Stubbs wrote: |
| 2 |
> On Friday 09 December 2005 04:03, Zac Medico wrote: |
| 3 |
> > Jason Stubbs wrote: |
| 4 |
> > > On Thursday 08 December 2005 16:44, Zac Medico wrote: |
| 5 |
> > >>The middle hunk fixes a problem with block atoms that do not match any |
| 6 |
> > >>packages. Previously, these atoms would not make it into the okay_atoms |
| 7 |
> > >> set which caused unresolved dependencies. |
| 8 |
> > > |
| 9 |
> > > Are you sure about this? |
| 10 |
> > |
| 11 |
> > Well, I'm pretty sure. You're analysis seems to be perfectly correct except |
| 12 |
> > for 2 points that you haven't accounted for: |
| 13 |
> > |
| 14 |
> > 1) The atom.key != child.key optimization prevents the atom.match(child) ^ |
| 15 |
> > atom.blocks bit from working in the case that my patch handles (block atom |
| 16 |
> > that does not match any package). |
| 17 |
> > |
| 18 |
> > 2) Without the atom.key != child.key optimization, the original algorithm |
| 19 |
> > would bail out early, before all packages have been checked. We need to |
| 20 |
> > ensure that the atom does not block _any_ of the packages before we add it |
| 21 |
> > to okay_atoms, otherwise, we risk choosing the wrong atomset/combination. |
| 22 |
> > Note that checking all the packages _does_ introduce a performance penalty |
| 23 |
> > for block atoms. |
| 24 |
> |
| 25 |
> Damn optimizations. :| |
| 26 |
> |
| 27 |
> Both points are correct. |
| 28 |
So... you going to shove this into svn? :) |
| 29 |
~harring |
Archives