Issue2554

Running regrtests on Windows 10 I observed some failures that I don't observe on Linux:

test_calendar, test_codecencodings_tw, test_io, test_io_jy, test_strptime, test_time, test_univnewlines

fail especially on Windows for me, using Java 8 + current Jython trunk version.

A bit of triage for you of tests failing for me on Windows 10. They deserve a ticket each, but most already have one as noted:

#test___all__ # issue #2308: invalid to expect a pass?
test_classpathimporter # regression in test_bug1126, test_bug1239
test_codecencodings_tw # multibyte invalid characters?
test_io # issue #2563
test_io_jy # similar to issue #2563
test_java_integration # non-portable use of "/"
test_jython_initializer # issue #2313
test_marshal # issue #2559
test_platform # issue #2561
#test_select_new # not repeatable in isolation
#test_sort # issue #2399 - much "unexpected output": failure or not?
test_ssl # "Unable to create OpenSSL" (JAR missing?)or if -v given issue #2561 :(
test_univnewlines # issue #2563
test_zipimport_jy # issue #2318

You can use that text with regrtest -f <file containing that text>

I don't get the time and calendar failures: possibly non-English locale?

Hey Jeff, thanks for sorting this!

There is much more of such stuff to come with std-lib update; I get 35 additional failures then on linux. So I think it cannot go into 2.7.1 and I am going to setup a Jython fork with updated std-lib where we can sort things out and push improvements into Jython. At some sufficiently healthy state we can then do the actual std-lib update. (Will file a separate issue for that later)

I will take a look if #2563 can be fixed with some reasonable effort, given that it causes several fails.

#2561 is fixed (?) and pending for review.

Regarding date/time stuff I wanted to take a look at the several issues about that: #2504, #2524, #2285, #2503
E.g. #2524 contains a patch that can be eventually merged. I guess these issues somewhat depend on each other.

Regard test_io, test_io_jy and test_univnewlines as removed from the list; just fixed #2563.

I should have said I was testing Frank's recent soft 2.7.1rc1, not the dev tip. I realise there may have been progress since.

Have just been looking the these test_codecencodings_tw also fails on Linux we just don't see it because its excluded for some reason see line 1366 regrtest.py it appears a bit odd to me that it gets run on Windows as the other tests for these extended encodings are excluded for all see lines 1292-1296 regrtest.py

I'm not really for ignoring failing tests but it seem like moving test_codecencodings_tw to join the other codecencodings tests which fail on all platforms might be ok?

For note here are the fails on Windows with current master and PR61 which fixes test_marshal:

    'test_classpathimporter',
    'test_codecencodings_tw',
    'test_inspect', - Passes in isolation
    'test_java_integration',
    'test_java_visibility', - Passes in isolation
    'test_jython_initializer',
    'test_sort',
    'test_zipimport_jy',

test_codecencodings_tw passes on Java 7 for me, but fails on Java 8. (Seems to be a change of policy on adjacent undecodable characters.)

About a year and a half ago Adam Burke contributed (and I tidied up) a change that fixed regrtest so it did what it claimed, only running expected passing tests for each platform (given the -e flag), and revised the lists of what was expected.

"ant regrtest" effectively runs "regrtest -e", that is, we omit expected failures. It is desirable to have a passing regrtest so you can see what a proposed change breaks (e.g. in Travis), even before committing it. However, the known failures (and the skips in tests we run) need to be to us a list that we constantly try to shorten to only those tests not meaningful for Jython. And as we shorten it, update regrtest.py.

My observation of 2.7.1rc1:

    test_java_integration # non-portable use of "/"

cannot be reproduced in my development environment. What I see in test is:
======================================================================
ERROR: test_custom_proxymaker (__main__.SerializationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\hg\jython-int\Lib\test\test_java_integration.py", line 744, in test_custom_proxymaker
    subprocess.check_call(["jar", "cf", proxies_jar_path, "-C", tempdir, "org/"])
  File "C:\Jython\2.7.1rc1\Lib\subprocess.py", line 514, in check_call
    retcode = call(*popenargs, **kwargs)
  File "C:\Jython\2.7.1rc1\Lib\subprocess.py", line 501, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\Jython\2.7.1rc1\Lib\subprocess.py", line 856, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Jython\2.7.1rc1\Lib\subprocess.py", line 1360, in _execute_child
    raise OSError(errno.ENOENT, os.strerror(errno.ENOENT))
OSError: [Errno 2] No such file or directory

However, the OSError seems actually to be because the jar command is not on the path. The test environment only has the JRE. I'll see if I can add a clever skip.

@Jeff I agree with this, test_java_integration will fail if the call ToolProvider.getSystemJavaCompiler() returns null (line 646 test_java_integration). This will happen if JAVA_HOME does not point to a JDK install. Adding a test skip if this is the case seems like the best solution.

I have a pull request to fix the test_classpathimporter failure https://github.com/jythontools/jython/pull/66 and also one to fix the test_zipimport_jy failure https://github.com/jythontools/jython/pull/65

Accepted both PRs from James; set corresponding issues to pending so far.

I have a pull request to fix test_java_integration when you cant get a Java compiler it just skips the failing test. https://github.com/jythontools/jython/pull/68

Merged https://github.com/jythontools/jython/pull/68

I think this overall ticket could probably be closed. All of the failures originally identified have been fixed.

Currently I see test_inspect as the only failure on Windows 10 when run as part of the regrtest's but it passes in isolation. regrtest_memo.txt attached.

Given the latest comments, I'm going to call this "out of date" rather than fixed: many of the things in the original report are covered elsewhere by skps and issues, rather than fixed.