On Sun, Jul 15, 2012 at 5:42 PM, Charles R Harris <charlesr.har...@gmail.com> wrote: > > > On Sun, Jul 15, 2012 at 10:32 AM, Ralf Gommers <ralf.gomm...@googlemail.com> > wrote: >> >> >> >> On Sun, Jul 15, 2012 at 5:57 PM, Nathaniel Smith <n...@pobox.com> wrote: >>> >>> On Sun, Jul 15, 2012 at 1:08 PM, Ralf Gommers >>> <ralf.gomm...@googlemail.com> wrote: >>> > >>> > >>> > On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant <tra...@continuum.io> >>> > wrote: >>> >> >>> >> >>> >> Hey all, >>> >> >>> >> We are nearing a code-freeze for NumPy 1.7. Are there any >>> >> last-minute >>> >> changes people are wanting to push into NumPy 1.7? We should discuss >>> >> them >>> >> as soon as possible. >>> >> >>> >> I'm proposing a code-freeze at midnight UTC on July 18th (7:00pm CDT >>> >> on >>> >> July 17th). This will allow the creation of beta releases of NumPy >>> >> on the >>> >> 18th of July. This is a few days later than originally hoped for --- >>> >> largely >>> >> due to unexpected travel schedules of Ondrej and I, but it does give >>> >> people >>> >> a few more days to get patches in. Of course, we will be able to >>> >> apply >>> >> bug-fixes to the 1.7.x branch once the tag is made. >>> > >>> > >>> > What about the tickets still open for 1.7.0 >>> > (http://projects.scipy.org/numpy/report/3)? There are a few important >>> > ones >>> > left. >>> > >>> > These I would consider blockers: >>> > - #2108 Datetime failures with MinGW >>> >>> Is there a description anywhere of what the problem actually is here? >>> I looked at the ticket, which referred to a PR, and it's hard to work >>> out from the PR discussion what the actual remaining test failures are >>> -- and there definitely doesn't seem to be any description of the >>> underlying problem. (Something about working 64-bit time_t on windows >>> being difficult depending on the compiler used?) >> >> >> There's a lot more discussion on >> http://projects.scipy.org/numpy/ticket/1909 >> https://github.com/numpy/numpy/pull/156 >> https://github.com/numpy/numpy/pull/161. >> >> The issue is that for MinGW 3.x some _s / _t functions seem to be missing. >> And we don't yet support MinGW 4.x. >> >> Current issues can be seen from the last test log on our Windows XP >> buildbot (June 29, >> http://buildbot.scipy.org/builders/Windows_XP_x86/builds/1124/steps/shell_1/logs/stdio): >> >> ====================================================================== >> ERROR: test_datetime_arange (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> line 1351, in test_datetime_arange >> assert_raises(ValueError, np.arange, np.datetime64('today'), >> OSError: Failed to use '_localtime64_s' to convert to a local time >> >> ====================================================================== >> ERROR: test_datetime_y2038 (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> line 1706, in test_datetime_y2038 >> a = np.datetime64('2038-01-20T13:21:14') >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> ====================================================================== >> ERROR: test_pydatetime_creation (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> line 467, in test_pydatetime_creation >> a = np.array(['today', datetime.date.today()], dtype='M8[D]') >> OSError: Failed to use '_localtime64_s' to convert to a local time >> >> ====================================================================== >> ERROR: test_string_parser_variants (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> line 1054, in test_string_parser_variants >> assert_equal(np.array(['1980-02-29T01:02:03'], np.dtype('M8[s]')), >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> ====================================================================== >> ERROR: test_timedelta_scalar_construction_units >> (test_datetime.TestDateTime) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_datetime.py", >> line 287, in test_timedelta_scalar_construction_units >> assert_equal(np.datetime64('2010-03-12T17').dtype, >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> ====================================================================== >> ERROR: Failure: OSError (Failed to use '_gmtime64_s' to convert to a UTC >> time) >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "C:\Python26\lib\site-packages\nose\loader.py", line 382, in >> loadTestsFromName >> addr.filename, addr.module) >> File "C:\Python26\lib\site-packages\nose\importer.py", line 39, in >> importFromPath >> return self.importFromDir(dir_path, fqname) >> File "C:\Python26\lib\site-packages\nose\importer.py", line 86, in >> importFromDir >> mod = load_module(part_fqname, fh, filename, desc) >> File >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_multiarray.py", >> line 916, in <module> >> class TestArgmax(TestCase): >> File >> "C:\buildbot\numpy\b11\numpy-install\Lib\site-packages\numpy\core\tests\test_multiarray.py", >> line 938, in TestArgmax >> np.datetime64('1994-06-21T14:43:15'), >> OSError: Failed to use '_gmtime64_s' to convert to a UTC time >> >> > > I've wondered about the current status of MinGW 4.x, the mingw.org release > of GCC 4.7.0 was June 7. Looks like it is still 32 bits and breaks the ABI
The main issue with mingw 4.x is the dependency on mingw runtimes. With 3.x, it was possible to statically link everything, but not with 4.x. Distributing DLL outside numpy is not a good idea IMO, and I don't know how to share DLL across python extensions without putting them in the python installation (which does not sound like a good idea either). David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
