Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Mon, Jul 16, 2012 at 2:01 AM, Travis Oliphant tra...@continuum.iowrote: On Jul 15, 2012, at 7:08 AM, Ralf Gommers wrote: On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant tra...@continuum.iowrote: 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? For the SPARC issue, not really. For the datetime issue, I think it at least needs to be clear what the way forward is. If the issue isn't solvable without any changes to either the API or the compiler support, which may well be the case given the amount of effort that has gone into this already, we need a decision on what to do. It would also be a good idea to apply the distutils patch before the beta. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Mon, Jul 16, 2012 at 3:52 AM, Frédéric Bastien no...@nouiz.org 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
In article 1342393528.28368.3.ca...@esdceeprjpstudent1.mit.edu, Paul Natsuo Kishimoto m...@paul.kishimoto.name wrote: On Sat, 2012-07-14 at 17:45 -0500, 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. If you have a pull-request that is not yet applied and would like to discuss it for inclusion, the time to do it is now. Best, -Travis 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. My personal opinion is that the improvement is not sufficient to justify breaking backword compatibility. -- Russell ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Sun, Jul 15, 2012 at 12:45 AM, Travis Oliphant tra...@continuum.iowrote: 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 Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Jul 15, 2012 2: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 - #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. Ray Ralf ___ 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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Sun, Jul 15, 2012 at 5:33 PM, Thouis (Ray) Jones tho...@gmail.comwrote: On Jul 15, 2012 2: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 - #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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
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?) - #2076 Bus error for F order ndarray creation on SPARC Yes, this looks like a regression... Mark, any thoughts? These have patches available which should be reviewed: - #2150 Distutils should support Debian multi-arch fully This PR still needs tests and has unresolved comments, but is probably a blocker: https://github.com/numpy/numpy/pull/327 -N ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Sun, Jul 15, 2012 at 10:32 AM, Ralf Gommers
ralf.gomm...@googlemail.comwrote:
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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
Nathaniel Smith n...@pobox.com wrote: 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 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 Stefan Krah ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Sun, Jul 15, 2012 at 10:56 AM, David Cournapeau courn...@gmail.comwrote:
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:
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
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.har...@gmail.com wrote:
On Sun, Jul 15, 2012 at 10:56 AM, David Cournapeau courn...@gmail.comwrote:
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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Sat, 2012-07-14 at 17:45 -0500, 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. If you have a pull-request that is not yet applied and would like to discuss it for inclusion, the time to do it is now. Best, -Travis 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. Thanks, -- Paul Natsuo Kishimoto SM candidate, Technology Policy Program (2012) Research assistant, http://globalchange.mit.edu https://paul.kishimoto.name +1 617 302 6105 signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Jul 15, 2012, at 7:08 AM, Ralf Gommers 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 - #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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
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 tra...@continuum.io 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
This looked like an interesting one for sure. I can't look at the PR right now for some reason (Github gave me a 500 error). I know there were some comments, though. -Travis On Jul 15, 2012, at 9:52 PM, 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. Fred On Sun, Jul 15, 2012 at 10:40 PM, Travis Oliphant tra...@continuum.io 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 ___ 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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
A very small PR about documentation: https://github.com/numpy/numpy/pull/332 Fred On Sat, Jul 14, 2012 at 6:45 PM, 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. If you have a pull-request that is not yet applied and would like to discuss it for inclusion, the time to do it is now. Best, -Travis ___ 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
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
Hi, On Sat, Jul 14, 2012 at 3:45 PM, 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. If you have a pull-request that is not yet applied and would like to discuss it for inclusion, the time to do it is now. An appeal for (just submitted): https://github.com/numpy/numpy/pull/357 Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Code Freeze for NumPy 1.7
On Sat, Jul 14, 2012 at 7:02 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, On Sat, Jul 14, 2012 at 3:45 PM, 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. If you have a pull-request that is not yet applied and would like to discuss it for inclusion, the time to do it is now. An appeal for (just submitted): https://github.com/numpy/numpy/pull/357 Already committed. I think we should look over the current PR's to identify any others that should go in. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
