Jeff King writes:
> And here it is for reference with the matching change in test-oidmap,
> and the adjustments necessary for the test scripts (from master, not
> from my earlier patch). I think I prefer the simpler "just sort it all"
> version I posted with the commit message.
Yeah, let's go wi
Jeff King writes:
> So regardless of the endian thing above, it probably does make sense for
> any hashmap iteration output to be sorted before comparing. That goes
> for t0011, too; it doesn't have this endian thing, but it looks to be
> relying on hash order that could change if we swapped out
Jeff King wrote:
> On Tue, Jul 30, 2019 at 09:59:17PM -0400, Todd Zullinger wrote:
>> At the risk of showing my complete lack of knowledge about
>> these tests, I was wondering if the order mattered for the
>> other tests in t0011 and t0016.
[...]
>> You've got a more comprehensive patch and a prop
On Wed, Jul 31, 2019 at 06:06:02AM +0200, René Scharfe wrote:
> Am 31.07.19 um 05:27 schrieb Jeff King:
> > One thing that makes it all a bit funky is that the "put" lines also
> > output the old value (which is what all those NULLs) are. And I think
> > that solves my "value3" puzzlement from ear
Am 31.07.19 um 05:27 schrieb Jeff King:
> One thing that makes it all a bit funky is that the "put" lines also
> output the old value (which is what all those NULLs) are. And I think
> that solves my "value3" puzzlement from earlier. It is not part of the
> iteration at all, but rather the result o
On Tue, Jul 30, 2019 at 11:27:35PM -0400, Jeff King wrote:
> That would perhaps be clearer if the "hashmap" tool actually did the
> sorting itself (so we'd sort _just_ the iteration, not the whole
> output). Something like this, though I'm on the fence about whether it
> is worth it:
> [...]
And
On Tue, Jul 30, 2019 at 09:59:17PM -0400, Todd Zullinger wrote:
> At the risk of showing my complete lack of knowledge about
> these tests, I was wondering if the order mattered for the
> other tests in t0011 and t0016. I had assumed it didn't and
> had something like this for testing (and a simi
Jeff King wrote:
> On Tue, Jul 30, 2019 at 08:59:33PM -0400, Jeff King wrote:
>
>>> OTOH, this is not just any hashmap, but an oidmap, and I could imagine
>>> that there might be use cases where it would be beneficial if the
>>> iteration order were to match the oid order (but don't know whether w
On Tue, Jul 30, 2019 at 09:23:36PM -0400, Jeff King wrote:
> test_expect_success 'iterate (case insensitive)' '
> -
> -test_hashmap "put key1 value1
> -put key2 value2
> -put fooBarFrotz value3
> -iterate" "NULL
> -NULL
> -NULL
> -fooBarFrotz value3
> -key2 value2
> -key1 value1" ignorecase
By t
On Tue, Jul 30, 2019 at 08:59:33PM -0400, Jeff King wrote:
> > OTOH, this is not just any hashmap, but an oidmap, and I could imagine
> > that there might be use cases where it would be beneficial if the
> > iteration order were to match the oid order (but don't know whether we
> > actually have s
On Tue, Jul 30, 2019 at 10:56:24PM +0200, SZEDER Gábor wrote:
> > Ah, of course. Our oid hashing is done by just picking off the first
> > bytes of the sha1, and it doesn't care about endianness (because these
> > are just internal-to-memory hashes).
>
> Yeah.
>
> > We _could_ reconcile that lik
On Tue, Jul 30, 2019 at 04:02:03PM -0400, Jeff King wrote:
> On Tue, Jul 30, 2019 at 03:49:38PM -0400, Todd Zullinger wrote:
>
> > > Subtest 6 had an ordering issue. We do not know whether
> > > the problem is the code or the test result not keeping up
> > > with the code changes.
> > >
> > > ---
Jeff King writes:
> @@ -116,19 +116,11 @@ unsigned int memihash_cont(unsigned int hash_seed,
> const void *buf, size_t len);
> * Converts a cryptographic hash (e.g. SHA-1) into an int-sized hash code
> * for use in hash tables. Cryptographic hashes are supposed to have
> * uniform distribu
On July 30, 2019 3:50 PM, Todd Zullinger wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; Christian Couder
> ; SZEDER Gábor ; Jeff
> King ; git@vger.kernel.org; git-
> packag...@googlegroups.com
> Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test
On July 30, 2019 3:45 PM, Jeff King wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org; git-
> packag...@googlegroups.com
> Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
>
> On Tue, Jul 30, 2019 at 01:08:37PM -0
On Tue, Jul 30, 2019 at 03:49:38PM -0400, Todd Zullinger wrote:
> > Subtest 6 had an ordering issue. We do not know whether
> > the problem is the code or the test result not keeping up
> > with the code changes.
> >
> > --- expect 2019-07-30 16:56:36 +
> > +++ actual 2019-07-30 16:5
Hi,
[added Christian, SZEDER, and Jeff to Cc as author and
helpers on the newly-added t0016-oidmap]
Randall S. Becker wrote:
> A preview of the situation with testing 2.23.0.rc0 on
> NonStop is not great. We have had some new failures right
> off the bat on our NonStop platforms. This is a previe
On Tue, Jul 30, 2019 at 01:08:37PM -0400, Randall S. Becker wrote:
> t0016: oidmap
>
> Subtest 6 had an ordering issue. We do not know whether the problem is the
> code or the test result not keeping up with the code changes.
> --- expect 2019-07-30 16:56:36 +
> +++ actual 2019-07-
"Randall S. Becker" writes:
> On July 30, 2019 1:32 PM, Junio C Hamano wrote:
>>
>> I wonder if a tool like sparse can help us catch a pattern that feeds
> errno to
>> "%d" format.
>> ...
> Seems reasonable. Better than trying to use strerror(), which previously
> (I'm not sure whether it was t
On July 30, 2019 1:32 PM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > t0066: dir-iterator
> >
> > Subtest 4 depends on a non-portable error code. ENOENT is not
> guaranteed ...
> > Subtest 5 also depends on a non-portable error code. ENOTDIR is not
gua...
>
> Yikes, and sorry. I'v
Hi, Junio and Randall
On Tue, Jul 30, 2019 at 2:31 PM Junio C Hamano wrote:
>
> "Randall S. Becker" writes:
>
> > t0066: dir-iterator
> >
> > Subtest 4 depends on a non-portable error code. ENOENT is not guaranteed ...
> > Subtest 5 also depends on a non-portable error code. ENOTDIR is not gua..
"Randall S. Becker" writes:
> t0066: dir-iterator
>
> Subtest 4 depends on a non-portable error code. ENOENT is not guaranteed ...
> Subtest 5 also depends on a non-portable error code. ENOTDIR is not gua...
Yikes, and sorry. I've become somewhat complacent after relying on
how good our other r
Hi All,
A preview of the situation with testing 2.23.0.rc0 on NonStop is not great. We
have had some new failures right off the bat on our NonStop platforms. This is
a preview of what we find within the first bit of testing. The tests run a long
time, so more to come.
t0016: oidmap
Subtest 6
23 matches
Mail list logo
