On Fri, Aug 15, 2008 at 19:30, Christian Heimes [EMAIL PROTECTED] wrote:
Please also note that CPython uses a freelist of unused dict instances.
The default size of the dict free list is 80 elements. The allocation
and deallocation of dicts is cheap if you can stay below the threshold.
That's
On Fri, Aug 15, 2008 at 7:11 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Doesn't mingw use the MSVC library?
Yes, it does. But long double is both a compiler and library issue.
sizeof(long double) is defined by the compiler, and it is different
with mingw and visual studio ATM. I don't know
Looking at the code, but not testing it -- this looks fine to me. (I
wrote the original NPY_VERSION stuff and sent it to Travis, who modified
and included it.)
I have added a couple of extremely minor points to the code review tool
-- as much as a chance to play with the tool as to comment on
2008/8/16 Andrew Straw [EMAIL PROTECTED]:
Looking at the code, but not testing it -- this looks fine to me. (I
wrote the original NPY_VERSION stuff and sent it to Travis, who modified
and included it.)
I have added a couple of extremely minor points to the code review tool
-- as much as a
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force
all C code which uses numpy arrays to be recompiled? If you mean that
all your matplotlib/PIL/pyopengl/etc users are going to have to make a
co-ordinated upgrade, then this seems to be a grave mistake. Does
On Sat, Aug 16, 2008 at 04:34, Jon Wright [EMAIL PROTECTED] wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force
all C code which uses numpy arrays to be recompiled? If you mean that
all your matplotlib/PIL/pyopengl/etc users are going to have to make a
Robert Kern wrote:
On Sat, Aug 16, 2008 at 04:34, Jon Wright [EMAIL PROTECTED] wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force
all C code which uses numpy arrays to be recompiled? If you mean that
all your matplotlib/PIL/pyopengl/etc users are
On Sat, Aug 16, 2008 at 12:47 AM, David Cournapeau [EMAIL PROTECTED]wrote:
On Fri, Aug 15, 2008 at 7:11 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Doesn't mingw use the MSVC library?
Yes, it does. But long double is both a compiler and library issue.
sizeof(long double) is defined by
Hi,
Sat, 16 Aug 2008 03:25:11 +0200, Christian Heimes wrote:
David Cournapeau wrote:
The current trunk has 14 failures on windows (with mingw). 12 of them
are related to C99 (see ticket 869). Can the people involved in recent
changes to complex functions take a look at it ? I think this is
On Sat, Aug 16, 2008 at 12:47 AM, David Cournapeau [EMAIL PROTECTED]wrote:
On Fri, Aug 15, 2008 at 7:11 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Doesn't mingw use the MSVC library?
Yes, it does. But long double is both a compiler and library issue.
sizeof(long double) is defined by
Pauli Virtanen wrote:
To clarify this again: *no* features of C99 were used. The C99 specs were
only used as a guideline to what behavior we want of complex math
functions, and I wrote tests for this, and marked failing ones as skipped.
Got it.
However, it turned out that different tests
On Sat, Aug 16, 2008 at 3:43 AM, Robert Kern [EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 04:34, Jon Wright [EMAIL PROTECTED] wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force
all C code which uses numpy arrays to be recompiled? If you mean
On Sat, Aug 16, 2008 at 9:11 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
1) We could define the numpy longdouble type to be double, which makes us
compatible with MS and is effectively what numpy compiled with MSVC does
since MSVC long doubles are doubles. Perhaps this could be done by
Jon Wright wrote:
Travis, Stéfan,
I missed Travis mail previously. Are you *really* sure you want force
all C code which uses numpy arrays to be recompiled?
Re-compilation is necessary at some point. We have not required
recompilation for a long time now.Yes, it is a pain for
Charles R Harris wrote:
Yes. I don't think MS will support true long doubles any time soon
and this affects printing and the math functions. I'm not sure what
the best solution is, there are various possibilities.
1) We could define the numpy longdouble type to be double, which makes
us
On Sat, Aug 16, 2008 at 9:50 AM, Travis E. Oliphant
[EMAIL PROTECTED]wrote:
Charles R Harris wrote:
Yes. I don't think MS will support true long doubles any time soon
and this affects printing and the math functions. I'm not sure what
the best solution is, there are various
On Sat, Aug 16, 2008 at 11:15 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
That's my opinion also, I just thought that -DNOLONGDOUBLE was an easy way
to force that choice. David thinks that the function detection in the ufunc
module will be a problem.
Forget what I said, I think I used a
On Sat, Aug 16, 2008 at 12:15 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I was just going to look at that; it's nice to have the ticket mailing list
working again. Is there an easy way to force the SIZEOF_LONG_DOUBLE to 8 so
I can test this on linux?
Changing this line in
On Sat, Aug 16, 2008 at 10:47 AM, Travis E. Oliphant
[EMAIL PROTECTED] wrote:
Re-compilation is necessary at some point. We have not required
recompilation for a long time now.Yes, it is a pain for
distribution, but those who don't want to re-compile can point people to
1.1.1 which will
On Sat, Aug 16, 2008 at 11:24 AM, David Cournapeau [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 12:15 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I was just going to look at that; it's nice to have the ticket mailing
list
working again. Is there an easy way to force the
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time
during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for
this change? If it only means everyone recompiles, it is hard to see
what we, as users, are gaining by
On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright [EMAIL PROTECTED] wrote:
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time
during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for
this change? If it only means
On Sat, Aug 16, 2008 at 11:56 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright [EMAIL PROTECTED] wrote:
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time
during the 1.* cycle ?
Can someone help me to
On Sat, Aug 16, 2008 at 12:05 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:56 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:44 AM, Jon Wright [EMAIL PROTECTED] wrote:
David Cournapeau wrote:
Does that mean we will continue
On Sat, Aug 16, 2008 at 11:39 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:24 AM, David Cournapeau [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 12:15 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I was just going to look at that; it's nice to have the
On Sat, Aug 16, 2008 at 10:56 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Turns out that ipython needs to be recompiled also because of the newly
added version checking.
I'm sorry, can you clarify this? ipython has no C code at all, so I'm
not sure what you mean here.
Cheers,
f
On Sat, Aug 16, 2008 at 1:26 PM, Fernando Perez [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 10:56 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
Turns out that ipython needs to be recompiled also because of the newly
added version checking.
I'm sorry, can you clarify this? ipython
On Sat, Aug 16, 2008 at 12:44 PM, Jon Wright [EMAIL PROTECTED] wrote:
David Cournapeau wrote:
Does that mean we will continue breaking the ABI from time to time
during the 1.* cycle ?
Can someone help me to understand me what is the compelling reason for
this change? If it only means
On Sat, Aug 16, 2008 at 2:07 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
There is seems to be a problem in defining the functions called for the
different types.
I don't know enough about this part of the code to be sure about the
whole function calls stack, but I would guess this is not
On Sat, Aug 16, 2008 at 1:07 PM, Charles R Harris [EMAIL PROTECTED]
wrote:
On Sat, Aug 16, 2008 at 11:39 AM, Charles R Harris
[EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:24 AM, David Cournapeau [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 12:15 PM, Charles R Harris
[EMAIL
On Sat, Aug 16, 2008 at 2:46 PM, David Cournapeau [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 2:07 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
There is seems to be a problem in defining the functions called for the
different types.
I don't know enough about this part of the code
Robert Kern wrote:
FWIW, neither PIL nor PyOpenGL have C code which uses numpy arrays, so
they are entirely unaffected.
OK, so here are some projects which might notice a 1.2 installation, in
as much as they turn up on a google code search for:
#include numpy/arrayobject.h -scipy
Hello,
I'm pleased to announce that ETS 3.0.0 has just been tagged and
released! Source distributions have been pushed to PyPi and over the
next couple hours, Win32 and OSX binaries will also be uploaded to PyPi.
This means you can install ETS, assuming you have the prereq software
installed, via
On Sat, Aug 16, 2008 at 3:02 PM, Charles R Harris [EMAIL PROTECTED]
wrote:
On Sat, Aug 16, 2008 at 2:46 PM, David Cournapeau [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 2:07 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
There is seems to be a problem in defining the functions
On Sat, Aug 16, 2008 at 5:18 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
could have expl replaced by exp. But there are likely other problems that
will need fixing.
I think this is red-herring. Does it really make sense to force
configuring long double as double if the C runtime and
On Sat, Aug 16, 2008 at 5:46 PM, David Cournapeau [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 5:18 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
could have expl replaced by exp. But there are likely other problems that
will need fixing.
I think this is red-herring. Does it really
On Sat, Aug 16, 2008 at 3:02 PM, Jon Wright [EMAIL PROTECTED] wrote:
snip
Try to look 12 months into the future and ask yourselves if it was
really a good idea to break the ABI.
I'm slowly coming to the conviction that there should be no C-ABI changes in
1.2. And maybe not in 1.3 either,
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I'm slowly coming to the conviction that there should be no C-ABI changes in
1.2.
It does not make sense to revert those changes anymore, but we keep
having those discussions, and I still don't understand whether there
Hi all,
[ please keep all replies to this only on the numpy list. I'm cc'ing
the scipy ones to make others aware of the topic, but do NOT reply on
those lists so we can have an organized thread for future reference]
In the Python-dev mailing lists, there were recently two threads
regarding the
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau [EMAIL PROTECTED] wrote:
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I'm slowly coming to the conviction that there should be no C-ABI changes in
1.2.
It does not make sense to revert those changes anymore,
On Sat, Aug 16, 2008 at 11:03 PM, Fernando Perez [EMAIL PROTECTED]wrote:
Hi all,
[ please keep all replies to this only on the numpy list. I'm cc'ing
the scipy ones to make others aware of the topic, but do NOT reply on
those lists so we can have an organized thread for future reference]
On Sat, Aug 16, 2008 at 10:22 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
Geez, some of those folks in those threads are downright rude.
Python-dev is nowhere nearly as civil as these lists, which I consider
to be an asset of ours which we should always strive to protect. In
this list even
On Sat, Aug 16, 2008 at 11:21 PM, David Cournapeau [EMAIL PROTECTED]wrote:
On Sat, Aug 16, 2008 at 11:59 PM, David Cournapeau [EMAIL PROTECTED]
wrote:
On Sat, Aug 16, 2008 at 11:16 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I'm slowly coming to the conviction that there should be no
43 matches
Mail list logo
