[PATCH] Windows testsuite fixes [1/4]

[Vincent Ladeuil]

>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:

    jam> Andrew Bennetts wrote:
    >> On Thu, Nov 30, 2006 at 04:26:25PM +0100, Vincent Ladeuil wrote:
    >> [...]
    >>> +            spurious = [errno.EPIPE,
    >>> +                        errno.ECONNRESET,
    >>> +                        10053, # Windows 'Software caused connection abort'
    >>> +                        ]
    >>> +            if (len(e.args) > 0) and (e.args[0] in spurious):
    >> 
    >> I would expect 10053 to be errno.ECONNABORTED.  If it is, use that instead.
    >> 
    >> Otherwise, I'd rather not unconditionally include a hard-coded platform-specific
    >> number in spurious, but instead guard it with:
    >> 
    >> if sys.platform == 'windows':
    >> spurious.append(10053) # Software caused connection abort.
    >> 
    >> The reason is that hypothetically, that errno might occur on another platform
    >> with a different meaning.

Yup. Good catch.

    jam> I think you have a good point. I don't know of other platforms that use
    jam> error codes >10000,

Me neither, but I agree with Andrew.

    jam> so I'm pretty sure it is windows specific. Though you
    jam> bring up that ECONNABORTED should probably be included
    jam> in that list.

Yup, will do that ASAP.

    >> 
    >> 
    >>> out, err = self.run_bzr('init', 'subdir2/nothere', retcode=3)
    >>> self.assertEqual('', out)
    >>> +        # Rely on bzr error message part only or we fail on
    >>> +        # non-english systems
    >>> self.assertContainsRe(err,
    >>> -            r'^bzr: ERROR: .*'
    >>> -            '\[Errno 2\] No such file or directory')
    >>> -        
    >>> +            r'^bzr: ERROR: No such file:.*')
    >>> +
    >> 
    >> Can we do the equivalent of setting LANG=C on windows to avoid this problem?
    >> run_bzr happens in-process, so perhaps it should do
    >> "locale.setlocale(locale.LC_ALL, 'C')" (with an appropriate cleanup to restore
    >> the locale to the previous state)?

    jam> Well, I have been unsuccessful in getting LANG=C to mean
    jam> anything on Windows. So I'm not sure how it determines
    jam> the locale and how to generate internationalized error
    jam> messages.

    jam> We have a good resource in Alexander, since his machine
    jam> uses a non-english Windows install.

    jam> It does seem like you can call 'setlocale'. But I wonder
    jam> if there is something that you could use when calling
    jam> out to another process. (We would like to use it when
    jam> spawning an external diff).

I'm all ears here.

I was bitten by the same kind of problem on another project where
perl was confused by Gtk setting the locales in a way I couldn't
understand. The only way I know of to change locale in windows is
by using *interactively* the international control panel
(whatever its name).

    >> 
    >> Your solution seems ok for this instance, but in general run_bzr should probably
    >> ensure the test bzr is run in a predictable way.
    >> 
    >> Otherwise, +1 from me.

Thanks. I'll take that into account and propose a better patch
next week.

If anybody have ideas to address the point above, please don't
hesitate :)

     Vincent