Ensuring tests pass on gccgo

[Gustavo Niemeyer]

I wasn't suggesting that slices should be sorted in tests, but rather that
the real APIs define the ordering for elements stored and returned. This is
useful for humans too.

Either way, just a suggestion.

gustavo @ http://niemeyer.net
On May 22, 2014 5:49 PM, "Nate Finch" <nate.finch at canonical.com> wrote:

> Although using DeepEquals on sorted lists does make for
> easier-to-understand test failure messages, the burden on the developer to
> sort the slices when they write the test doesn't seem worth it to me.  We
> write tests a lot more often than we need to debug failing tests.  If it
> was just slices of strings, then sorting is easy enough, but for other
> random types, you now have to figure out how to sort the types in a fully
> deterministic way, which can be difficult and error prone for large
> structs, especially as those structs change.
>
> It's much easier and less error prone to say "just use jc.SameContents".
> On May 22, 2014 10:42 AM, "Gustavo Niemeyer" <
> gustavo.niemeyer at canonical.com> wrote:
>
>> I apologize. After reading one of the review entries using
>> SameContents, I see I've misunderstood what the problem is about. The
>> v1 and v2 in your example is a slice, not a map, which means the test
>> is comparing slices of undefined order. This is certainly bogus and
>> needs addressing in the code itself, irrespective of any map-related
>> issues.
>>
>> What I generally do in those cases is to define the ordering of the
>> slice. Besides enabling DeepEquals, it also makes the visual
>> comparison more pleasant.
>>
>>
>>
>> On Thu, May 22, 2014 at 11:34 AM, Gustavo Niemeyer
>> <gustavo.niemeyer at canonical.com> wrote:
>> > On Wed, May 21, 2014 at 10:43 PM, Ian Booth <ian.booth at canonical.com>
>> wrote:
>> >> We are working to make all juju-core unit tests pass using gccgo. In
>> case you
>> >> didn't already know, there's a common issue which has caused a lot of
>> the
>> >> failures to date. Here's a quick heads up on how to deal with it.
>> >>
>> >> golang-go and gcc-go have different map implementations which results
>> in
>> >> ordering differences, affecting things like range etc (simplistically
>> put,
>> >> gcc-go's map ordering is random whereas currently golang-go is somewhat
>> >> deterministic).
>> >
>> > This is changing in the main compiler as well, in Go 1.3:
>> >
>> >     http://tip.golang.org/doc/go1.3#map
>> >
>> > So it'll become even less deterministic there as well.
>> >
>> >> Now of course, maps are unordered but what we sometimes do in
>> >> the code is to use a map to hold some data (maybe to eliminate
>> duplicates) and
>> >> then expose that data via a slice or array. If we then do a
>> c.Assert(v1,
>> >> gc.DeepEquals, v2), it will fail on gcc-go, since the order of items
>> in the 2
>> >> slices is different, even though the values are the same.
>> >
>> > If that's really the case, it's definitely a bug in gccgo. gocheck's
>> > DeepEquals is implemented in terms of reflect.DeepEqual, which should
>> > not care about the map order. In the standard library of the main
>> > compiler, it clearly does not:
>> >
>> >         for _, k := range v1.MapKeys() {
>> >                 if !deepValueEqual(v1.MapIndex(k), v2.MapIndex(k),
>> > visited, depth+1) {
>> >                         return false
>> >                 }
>> >         }
>> >
>> > So gocheck's DeepEquals is fine for such map tests, assuming no bugs
>> > in the underlying implementation.
>> >
>> >
>> > gustavo @ http://niemeyer.net
>>
>>
>>
>> --
>> gustavo @ http://niemeyer.net
>>
>> --
>> Juju-dev mailing list
>> Juju-dev at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140522/d574209f/attachment.html>