On 11/09/2018 12:57 PM, Eric Blake wrote:
> On 9/27/18 12:23 PM, John Snow wrote:
>>
>>
>> On 09/26/2018 11:11 PM, Eric Blake wrote:
>>> We need an accurate count of the number of bits set in a bitmap
>>> after a merge. In particular, since the merge operation short-circuits
>>> a merge from an
On 9/27/18 12:23 PM, John Snow wrote:
On 09/26/2018 11:11 PM, Eric Blake wrote:
We need an accurate count of the number of bits set in a bitmap
after a merge. In particular, since the merge operation short-circuits
a merge from an empty source, if you have bitmaps A, B, and C where
B started e
On 09/26/2018 11:11 PM, Eric Blake wrote:
> We need an accurate count of the number of bits set in a bitmap
> after a merge. In particular, since the merge operation short-circuits
> a merge from an empty source, if you have bitmaps A, B, and C where
> B started empty, then merge C into B, and B
27.09.2018 06:11, Eric Blake wrote:
We need an accurate count of the number of bits set in a bitmap
after a merge. In particular, since the merge operation short-circuits
a merge from an empty source, if you have bitmaps A, B, and C where
B started empty, then merge C into B, and B into A, an ina
We need an accurate count of the number of bits set in a bitmap
after a merge. In particular, since the merge operation short-circuits
a merge from an empty source, if you have bitmaps A, B, and C where
B started empty, then merge C into B, and B into A, an inaccurate
count meant that A did not get
