On Sun, Jul 15, 2012 at 5:33 PM, Thouis (Ray) Jones wrote:

On Jul 15, 2012 2:08 PM, "Ralf Gommers" wrote:

...

On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant

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 - #2076 Bus error for F order ndarray creation on SPARC

These have patches available which should be reviewed: - #2150 Distutils should support Debian multi-arch fully - #2179 Memmap children retain _mmap reference in all cases

This one was fixed in a recent PR of mine, but I can't find it right now (on phone). Njsmith committed the merge.

OK thanks, closed the ticket. Looks like it would be handy for you and Nathaniel to get admin rights on the tracker. Can you help with that, Pauli? Ralf

On Sun, Jul 15, 2012 at 5:57 PM, Nathaniel Smith wrote:

On Sun, Jul 15, 2012 at 1:08 PM, Ralf Gommers wrote:

...

On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant 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

...

...

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

...

...

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

them the 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/... ): ====================================================================== 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

On Sun, Jul 15, 2012 at 5:42 PM, Charles R Harris wrote:

On Sun, Jul 15, 2012 at 10:32 AM, Ralf Gommers wrote:

...

On Sun, Jul 15, 2012 at 5:57 PM, Nathaniel Smith wrote:

...

On Sun, Jul 15, 2012 at 1:08 PM, Ralf Gommers wrote:

...

On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant 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/...):

====================================================================== 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

Just added PR #359. The purpose is to allow the nditer object operand and iter flags to be set for a ufunc to provide better control over how an array is iterated over by a ufunc and how the ufunc uses the operands passed to it. One specific motivation for this is to be able to specify an input operand to a ufunc as being read/write instead of read only. For example, to allow your ufunc to write back to the first operand: PyObject *ufunc = PyUFunc_FromFuncAndData((PyUFuncGenericFunction*)func, data, types, 1, 2, 1, PyUFunc_None, "ufunc_name", "ufunc_doc", 0); /* override the default NPY_ITER_READONLY flag */ ((PyUFuncObject*)ufunc)->op_flags[0] = NPY_ITER_READWRITE; /* global iter flag that needs to be set for read/write flag to work */ ((PyUFuncObject*)ufunc)->iter_flags = NPY_ITER_REDUCE_OK; Thoughts? -Jay On Sun, Jul 15, 2012 at 12:10 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:

On Sun, Jul 15, 2012 at 10:56 AM, David Cournapeau wrote:

...

On Sun, Jul 15, 2012 at 5:42 PM, Charles R Harris wrote:

...

On Sun, Jul 15, 2012 at 10:32 AM, Ralf Gommers <

...

wrote:

...

On Sun, Jul 15, 2012 at 5:57 PM, Nathaniel Smith

wrote:

...

...

On Sun, Jul 15, 2012 at 1:08 PM, Ralf Gommers wrote:

...

On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant <

ralf.gommers@googlemail.com> travis@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/... ):

...

====================================================================== 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.orgrelease 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).

Have you looked at TDM http://tdm-gcc.tdragon.net/? A cursory look implies that the std/stdc++ libraries can be statically linked.

Chuck

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Stefan Krah writes: ...

I wonder if this might be a blocker: Python-3.3 will be released in August and I don't think the issue is fixed yet:

http://projects.scipy.org/numpy/ticket/2145

In case it helps, on a 64-bit Debian 6 machine where building with Python 3.1 and 3.2 seems fine, I think I see the same error as above. Here's the build log: https://jenkins.shiningpanda.com/scipy/job/NumPy-Debian6_x64-py33/7/consoleF... Chris

On Jul 15, 2012, at 7:08 AM, Ralf Gommers wrote:

On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant 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 - #2076 Bus error for F order ndarray creation on SPARC

These have patches available which should be reviewed: - #2150 Distutils should support Debian multi-arch fully - #2179 Memmap children retain _mmap reference in all cases

These blockers could certainly delay the rc1 release, but would they need to hold up the beta? -Travis

Hi, there is a PR that I think could be merged before the relase: https://github.com/numpy/numpy/pull/326 It is the addition of the inplace_increment function. It seam good, but I can't review it enough as it use many numpy internal that I never used or looked at. But the tests seam to cover all cases and it don't change current functions. So it should not have any side effect problems. This was a feature frequently requested. Fred On Sun, Jul 15, 2012 at 10:40 PM, Travis Oliphant wrote:

...

Bump for: https://github.com/numpy/numpy/pull/351

As requested by njsmith, I gave a more detailed explanation and asked the list for input at: http://www.mail-archive.com/numpy-discussion@scipy.org/msg38306.html

There was one qualified negative reply and nothing (yet) further. I'd appreciate if some other devs could weigh in.

I can see the point of your proposal, but I don't think we can just change the behavior of genfromtxt quite like this. I'm not an expert on the genfromtxt code, so I don't know if I exactly understand what is changing and what is staying the same.

...

From the look of the patch, it looks like you are changing the interpretation so that whereas headers used to be allowed in the "first-line" of the comment, they would no longer be allowed like that. I don't think we can do that, because it breaks code for someone without a path for change.

Now, we could add another keyword (headers=True, for example), that interpreted the first non-commented line as the header line. Something like that has a much higher chance of getting accepted from my perspective.

Best,

-Travis

...

Thanks, -- Paul Natsuo Kishimoto

SM candidate, Technology & Policy Program (2012) Research assistant, http://globalchange.mit.edu https://paul.kishimoto.name +1 617 302 6105 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

On Mon, Jul 16, 2012 at 3:52 AM, Frédéric Bastien wrote:

Hi,

there is a PR that I think could be merged before the relase:

https://github.com/numpy/numpy/pull/326

It is the addition of the inplace_increment function. It seam good, but I can't review it enough as it use many numpy internal that I never used or looked at. But the tests seam to cover all cases and it don't change current functions. So it should not have any side effect problems.

This was a feature frequently requested.

There are a number of unresolved issues with that patch still -- see the comment thread on the PR. -N