[Numpy-discussion] Boolean output for Object arrays with M

[Travis E. Oliphant]

Hi Chuck,

O.K.  I've finally caught up with you, I think (at least as far as the 
umath generators go). 

All TD(M,.)  lines should *not* have out='?'

The reasoning is that this specifies a ufunc type with object inputs and 
boolean array outputs where the function is a method of the object 
input.   However,  the output of a Python method is not going to be a 
C-boolean.  It will be an Object. 

Thus, I think that you are right and removing the out='?' from all 
TD(M,...) lines is the right thing to do.

-Travis

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Code generator bug and fix?

[Charles R Harris]

On Mon, Apr 21, 2008 at 9:09 PM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> >
> >
> > On Mon, Apr 21, 2008 at 8:53 PM, Charles R Harris
> > <[EMAIL PROTECTED] > wrote:
> >
> >
> >
> > On Mon, Apr 21, 2008 at 8:28 PM, Travis E. Oliphant
> > <[EMAIL PROTECTED] > wrote:
> >
> > Charles R Harris wrote:
> > > I've gotten my own python class with a logical_not method to
> > work
> > > correctly if I goto
> > numpy/core/code_generators/generate_umath.py and
> > > change
> > I need more context for this.   Why does the umath generator
> > matter for
> > your python class?
> > >
> > > 'logical_not' :
> > > Ufunc(1, 1, None,
> > >   'returns not x elementwise.',
> > >   TD(noobj, out='?'),
> > >   TD(M, f='logical_not', out='?'),
> > >   ),
> > >
> > > to
> > >
> > > 'logical_not' :
> > > Ufunc(1, 1, None,
> > >   'returns not x elementwise.',
> > >   TD(noobj, out='?'),
> > >   TD(M, f='logical_not'),
> > >   ),
> > >
> > Why is this an error?   Is the difference only removing the out
> > variable?  It's been a while since I reviewed this code, so
> > what does
> > removing the out variable do functionally (What is the
> > difference in the
> > ufunc that is generated)?
> >
> >
> > The way it is, it passes a boolean array to the PyUFunc_O_O_method
> > loop where the loop is expecting an object array. I checked the
> > step size to see this, and that's also how the generated signature
> > reads. Consequently, when the reference count is decremented bad
> > things happen. I suspect this hasn't been seen before because it
> > hadn't been tried. I wrote loop tests before cleaning up the loop
> > code and the bug turned up then.
> >
> > My guess is that here M means object called through non-Python
> > method (logical_not), and omitting out means the output type is
> > the same as the input. I suspect that '?' should do the same thing
> > and that there might be a bug in the function dispatcher or the
> > signature generator, but I'm not clear on that yet.
> >
> >
> > If out is omitted, the output types matches the input types. Here's
> > where the output types are generated:
> >
> > def finish_signature(self, nin, nout):
> > if self.in_ is None:
> > self.in_ = self.type * nin
> > assert len(self.in_) == nin
> > if self.out is None:
> > self.out = self.type * nout
> > assert len(self.out) == nout
> >
> > So that seems like the right thing to do. I still don't know what  '?'
> > means, though.
>
> Thanks Chuck,
>
> I get it now (I should have spent a minute looking at the code).  The
> '?' is the character code for "boolean"
>
> So, I think you are right about the bug.
>

I note that other logical operators, <, ==, do in fact return booleans when
operating on objects. So another fix is to write special case loops for
logical_{not, or, and, xor} that do the same. Perhaps a ticket for an
enhancement should be opened.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Code generator bug and fix?

[Charles R Harris]

On Mon, Apr 21, 2008 at 9:09 PM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> >
> >
> > On Mon, Apr 21, 2008 at 8:53 PM, Charles R Harris
> > <[EMAIL PROTECTED] > wrote:
> >
> >
> >
> > On Mon, Apr 21, 2008 at 8:28 PM, Travis E. Oliphant
> > <[EMAIL PROTECTED] > wrote:
> >
> > Charles R Harris wrote:
> > > I've gotten my own python class with a logical_not method to
> > work
> > > correctly if I goto
> > numpy/core/code_generators/generate_umath.py and
> > > change
> > I need more context for this.   Why does the umath generator
> > matter for
> > your python class?
> > >
> > > 'logical_not' :
> > > Ufunc(1, 1, None,
> > >   'returns not x elementwise.',
> > >   TD(noobj, out='?'),
> > >   TD(M, f='logical_not', out='?'),
> > >   ),
> > >
> > > to
> > >
> > > 'logical_not' :
> > > Ufunc(1, 1, None,
> > >   'returns not x elementwise.',
> > >   TD(noobj, out='?'),
> > >   TD(M, f='logical_not'),
> > >   ),
> > >
> > Why is this an error?   Is the difference only removing the out
> > variable?  It's been a while since I reviewed this code, so
> > what does
> > removing the out variable do functionally (What is the
> > difference in the
> > ufunc that is generated)?
> >
> >
> > The way it is, it passes a boolean array to the PyUFunc_O_O_method
> > loop where the loop is expecting an object array. I checked the
> > step size to see this, and that's also how the generated signature
> > reads. Consequently, when the reference count is decremented bad
> > things happen. I suspect this hasn't been seen before because it
> > hadn't been tried. I wrote loop tests before cleaning up the loop
> > code and the bug turned up then.
> >
> > My guess is that here M means object called through non-Python
> > method (logical_not), and omitting out means the output type is
> > the same as the input. I suspect that '?' should do the same thing
> > and that there might be a bug in the function dispatcher or the
> > signature generator, but I'm not clear on that yet.
> >
> >
> > If out is omitted, the output types matches the input types. Here's
> > where the output types are generated:
> >
> > def finish_signature(self, nin, nout):
> > if self.in_ is None:
> > self.in_ = self.type * nin
> > assert len(self.in_) == nin
> > if self.out is None:
> > self.out = self.type * nout
> > assert len(self.out) == nout
> >
> > So that seems like the right thing to do. I still don't know what  '?'
> > means, though.
>
> Thanks Chuck,
>
> I get it now (I should have spent a minute looking at the code).  The
> '?' is the character code for "boolean"
>
> So, I think you are right about the bug.
>

OK,

So I quess that everywhere I see TD(M... I should remove the "out='?' ".
Will do.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Code generator bug and fix?

[Travis E. Oliphant]

Charles R Harris wrote:
>
>
> On Mon, Apr 21, 2008 at 8:53 PM, Charles R Harris 
> <[EMAIL PROTECTED] > wrote:
>
>
>
> On Mon, Apr 21, 2008 at 8:28 PM, Travis E. Oliphant
> <[EMAIL PROTECTED] > wrote:
>
> Charles R Harris wrote:
> > I've gotten my own python class with a logical_not method to
> work
> > correctly if I goto
> numpy/core/code_generators/generate_umath.py and
> > change
> I need more context for this.   Why does the umath generator
> matter for
> your python class?
> >
> > 'logical_not' :
> > Ufunc(1, 1, None,
> >   'returns not x elementwise.',
> >   TD(noobj, out='?'),
> >   TD(M, f='logical_not', out='?'),
> >   ),
> >
> > to
> >
> > 'logical_not' :
> > Ufunc(1, 1, None,
> >   'returns not x elementwise.',
> >   TD(noobj, out='?'),
> >   TD(M, f='logical_not'),
> >   ),
> >
> Why is this an error?   Is the difference only removing the out
> variable?  It's been a while since I reviewed this code, so
> what does
> removing the out variable do functionally (What is the
> difference in the
> ufunc that is generated)?
>
>
> The way it is, it passes a boolean array to the PyUFunc_O_O_method
> loop where the loop is expecting an object array. I checked the
> step size to see this, and that's also how the generated signature
> reads. Consequently, when the reference count is decremented bad
> things happen. I suspect this hasn't been seen before because it
> hadn't been tried. I wrote loop tests before cleaning up the loop
> code and the bug turned up then.
>
> My guess is that here M means object called through non-Python
> method (logical_not), and omitting out means the output type is
> the same as the input. I suspect that '?' should do the same thing
> and that there might be a bug in the function dispatcher or the
> signature generator, but I'm not clear on that yet.
>
>
> If out is omitted, the output types matches the input types. Here's 
> where the output types are generated:
>
> def finish_signature(self, nin, nout):
> if self.in_ is None:
> self.in_ = self.type * nin
> assert len(self.in_) == nin
> if self.out is None:
> self.out = self.type * nout
> assert len(self.out) == nout
>
> So that seems like the right thing to do. I still don't know what  '?' 
> means, though.

Thanks Chuck,

I get it now (I should have spent a minute looking at the code).  The 
'?' is the character code for "boolean"

So, I think you are right about the bug.

-Travis


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Code generator bug and fix?

[Charles R Harris]

On Mon, Apr 21, 2008 at 8:53 PM, Charles R Harris <[EMAIL PROTECTED]>
wrote:

>
>
> On Mon, Apr 21, 2008 at 8:28 PM, Travis E. Oliphant <
> [EMAIL PROTECTED]> wrote:
>
> > Charles R Harris wrote:
> > > I've gotten my own python class with a logical_not method to work
> > > correctly if I goto numpy/core/code_generators/generate_umath.py and
> > > change
> > I need more context for this.   Why does the umath generator matter for
> > your python class?
> > >
> > > 'logical_not' :
> > > Ufunc(1, 1, None,
> > >   'returns not x elementwise.',
> > >   TD(noobj, out='?'),
> > >   TD(M, f='logical_not', out='?'),
> > >   ),
> > >
> > > to
> > >
> > > 'logical_not' :
> > > Ufunc(1, 1, None,
> > >   'returns not x elementwise.',
> > >   TD(noobj, out='?'),
> > >   TD(M, f='logical_not'),
> > >   ),
> > >
> > Why is this an error?   Is the difference only removing the out
> > variable?  It's been a while since I reviewed this code, so what does
> > removing the out variable do functionally (What is the difference in the
> > ufunc that is generated)?
> >
>
> The way it is, it passes a boolean array to the PyUFunc_O_O_method loop
> where the loop is expecting an object array. I checked the step size to see
> this, and that's also how the generated signature reads. Consequently, when
> the reference count is decremented bad things happen. I suspect this hasn't
> been seen before because it hadn't been tried. I wrote loop tests before
> cleaning up the loop code and the bug turned up then.
>
> My guess is that here M means object called through non-Python method
> (logical_not), and omitting out means the output type is the same as the
> input. I suspect that '?' should do the same thing and that there might be a
> bug in the function dispatcher or the signature generator, but I'm not clear
> on that yet.
>

If out is omitted, the output types matches the input types. Here's where
the output types are generated:

def finish_signature(self, nin, nout):
if self.in_ is None:
self.in_ = self.type * nin
assert len(self.in_) == nin
if self.out is None:
self.out = self.type * nout
assert len(self.out) == nout

So that seems like the right thing to do. I still don't know what  '?'
means, though.


Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Code generator bug and fix?

[Charles R Harris]

On Mon, Apr 21, 2008 at 8:28 PM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:

> Charles R Harris wrote:
> > I've gotten my own python class with a logical_not method to work
> > correctly if I goto numpy/core/code_generators/generate_umath.py and
> > change
> I need more context for this.   Why does the umath generator matter for
> your python class?
> >
> > 'logical_not' :
> > Ufunc(1, 1, None,
> >   'returns not x elementwise.',
> >   TD(noobj, out='?'),
> >   TD(M, f='logical_not', out='?'),
> >   ),
> >
> > to
> >
> > 'logical_not' :
> > Ufunc(1, 1, None,
> >   'returns not x elementwise.',
> >   TD(noobj, out='?'),
> >   TD(M, f='logical_not'),
> >   ),
> >
> Why is this an error?   Is the difference only removing the out
> variable?  It's been a while since I reviewed this code, so what does
> removing the out variable do functionally (What is the difference in the
> ufunc that is generated)?
>

The way it is, it passes a boolean array to the PyUFunc_O_O_method loop
where the loop is expecting an object array. I checked the step size to see
this, and that's also how the generated signature reads. Consequently, when
the reference count is decremented bad things happen. I suspect this hasn't
been seen before because it hadn't been tried. I wrote loop tests before
cleaning up the loop code and the bug turned up then.

My guess is that here M means object called through non-Python method
(logical_not), and omitting out means the output type is the same as the
input. I suspect that '?' should do the same thing and that there might be a
bug in the function dispatcher or the signature generator, but I'm not clear
on that yet.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Code generator bug and fix?

[Travis E. Oliphant]

Charles R Harris wrote:
> I've gotten my own python class with a logical_not method to work 
> correctly if I goto numpy/core/code_generators/generate_umath.py and 
> change
I need more context for this.   Why does the umath generator matter for 
your python class?
>
> 'logical_not' :
> Ufunc(1, 1, None,
>   'returns not x elementwise.',
>   TD(noobj, out='?'),
>   TD(M, f='logical_not', out='?'),
>   ),
>
> to
>
> 'logical_not' :
> Ufunc(1, 1, None,
>   'returns not x elementwise.',
>   TD(noobj, out='?'),
>   TD(M, f='logical_not'),
>   ),
>
Why is this an error?   Is the difference only removing the out 
variable?  It's been a while since I reviewed this code, so what does 
removing the out variable do functionally (What is the difference in the 
ufunc that is generated)?


-Travis


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Code generator bug and fix?

[Charles R Harris]

I've gotten my own python class with a logical_not method to work correctly
if I goto numpy/core/code_generators/generate_umath.py and change

'logical_not' :
Ufunc(1, 1, None,
  'returns not x elementwise.',
  TD(noobj, out='?'),
  TD(M, f='logical_not', out='?'),
  ),

to

'logical_not' :
Ufunc(1, 1, None,
  'returns not x elementwise.',
  TD(noobj, out='?'),
  TD(M, f='logical_not'),
  ),

There are a whole bunch of functions with this same error and before I start
changing them, I would like someone more familiar with this code to tell me
if I'm doing the right thing.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] ANN: EPD - Enthought Python Distribution released

[Travis Vaught]

Greetings,

Enthought is pleased to announce the release of the Enthought Python  
Distribution (EPD) version 2.5.2001.

http://www.enthought.com/epd

This release makes available both the RedHat 3.x (amd64) and Windows  
XP (x86) installers.  OS X, Ubuntu and more (modern) RHEL versions are  
coming soon(!).


About EPD
-
The Enthought Python Distribution is a "kitchen-sink-included"  
distribution of the Python Programming Language as well as over 60  
additional tools and libraries.  It includes NumPy, SciPy, IPython, 2D  
and 3D visualization, database adapters and a lot of other tools right  
out of the box.  Enthought is offering access to this bundle as a free  
service to academic and other non-profit organizations.  We also offer  
an annual fee-based subscription service for Commercial and  
Governmental users to download and update the software bundle.  
(Everyone may try it out for free.  Please see the License Information  
below.)


Included Software
-
A short list includes:
Python 2.5.2, NumPy, SciPy, Traits, Mayavi, Chaco, Kiva, Enable,  
Matplotlib, wxPython and VTK.

The complete list of software with version numbers is available here:
http://www.enthought.com/products/epdlibraries.php


License Information
---
EPD is a bundle of software, every piece of which is available  
separately for free under various open-source licenses.  Not-for- 
profit, private-sector access to the bundle and its updates is, and  
will remain, free under the terms of the Subscription Agreement (see 
http://www.enthought.com/products/epdlicense.php 
  ).  Commercial and Governmental users may try the bundle for free  
for 30 days.  After the trial period, users may purchase a one-year  
subscription to download and update the bundle.  Downloaded software  
obtained under the subscription agreement may be used by the  
subscriber in perpetuity.

This model should sound familiar, as our commercial offering is quite  
similar to the business model of a certain linux distributor.  More  
information is also available in the FAQ ( 
http://www.enthought.com/products/epdfaq.php 
  ).  For larger deployments, or those with special build or  
distribution needs, an Enterprise Subscription is also available.


Thanks
--
EPD is compelling because it solves a thorny packaging and  
distribution problem, but also because of the libraries which it  
includes.  The folks here at Enthought would like to thank the Python  
developer community and the wider community that authors and  
contributes to these included libraries.  We put these things to work  
every day and would be much less productive without them.  So, thanks!


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] powerpc yellow dog linux port of numpy

[Vincent Broman]

I succeeded in working around the other Yellow Dog Linux porting problem 
connected with the floating point exception calls. 
It turns out that a problematic #include  was protected
by a "#ifdef __OPTIMIZE__" so my preprocessing with "gcc -E" never saw its 
effect.
So, by avoiding optimization of umath, I was able to get a slower, but working 
copy 
of numpy compiled, which passed the numpy.test() suite.

The one-line patch avoiding my two compile problems 
adds to numpy/core/setup.py after line 270 the following line.

extra_compile_args = ["-fno-builtin -O0"]

I don't know enough to say whether the quoted args should be split().

I do want to find real fixes, though, not just bandaids.

In numpy/core/include/numpy/ndarrayobject.h is code which causes me one problem.

#if NPY_SIZEOF_LONGDOUBLE == NPY_SIZEOF_DOUBLE
typedef double npy_longdouble;
#define NPY_LONGDOUBLE_FMT "g"
#else
typedef long double npy_longdouble;
#define NPY_LONGDOUBLE_FMT "Lg"
#endif

I do not see why the size is critical. Couldn't we just use long double
for any compiler that supports long double? If the double and long double
have the same format, why do we prefer double?


My other assembler code problem is caused, when optimization is enabled,
by code using the following definition in /usr/include/bits/fenvinline.h,
which I do not understand, never having done ppc assembler.

--quote-
/* The weird 'i#*X' constraints on the following suppress a gcc
   warning when __excepts is not a constant.  Otherwise, they mean the
   same as just plain 'i'.  */

/* Inline definition for feraiseexcept.  */
# define feraiseexcept(__excepts) \
  ((__builtin_constant_p (__excepts) \
&& ((__excepts) & ((__excepts)-1) == 0 \
&& (__excepts) != FE_INVALID) \
   ? ((__excepts) != 0 \
  ? (__extension__ ({  __asm__ __volatile__ \
   ("mtfsb1 %s0" \
: : "i#*X"(__builtin_ffs (__excepts))); \
   0; })) \
  : 0) \
   : (feraiseexcept) (__excepts))
endquote---

This definition causes all the occurences in umathmodule.c of

feraiseexcept( FE_DIVBYZERO)

to make gcc complain of "inconsistent operand constraints in an  `asm'".
Is there anyone who can parse that hornet's nest of a definition?

Vincent Broman
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Summing indices of heterogeneous shapes

[Michael Hoffman]

In the following example I can sum up lists of column indices:

 >>> x = numpy.arange(30)
 >>> x.shape = (6, 5)
 >>> x
array([[ 0,  1,  2,  3,  4],
[ 5,  6,  7,  8,  9],
[10, 11, 12, 13, 14],
[15, 16, 17, 18, 19],
[20, 21, 22, 23, 24],
[25, 26, 27, 28, 29]])
 >>> cols = [[0, 1], [2, 3]]
 >>> x[:, cols].sum(2)
array([[ 1,  5],
[11, 15],
[21, 25],
[31, 35],
[41, 45],
[51, 55]])

Is there a way to do this if the shapes of the lists are heterogeneous? 
For example, what if I wanted to set cols = [[0, 1], [2, 3], [1, 2, 3]]? 
What's the best way to get a sensible result?

Thanks!
-- 
Michael Hoffman

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] API scan

[Charles R Harris]

On Sun, Apr 20, 2008 at 11:51 PM, Stéfan van der Walt <[EMAIL PROTECTED]>
wrote:

> Hi Charles
>
> On 21/04/2008, Charles R Harris <[EMAIL PROTECTED]> wrote:
> > I would like to scan generated files for API functions, but it seems
> that
> > the API scan runs on files in the numpy/core/src directory, not in the
> build
> > directory where the generated files end up. Is there an easy way to fix
> > this?
>
> Could you expand a bit?  Which tool are you using?
>

Perhaps I should describe what I want to do. In ufuncobject.c there are a
lot of generic loops that go into the ufunc API and I would like to generate
those loops using a template, so what I want is something like: generate
code from template, scan for UFUNC_API tags. At the moment these actions
occur in that order, but ufuncobject is not on the list of template files
and generated code is placed in the build directories and the code that is
scanned for tags is in the original source directory. I think the whole
process would be streamlined if *all* source files were treated as templates
with the output going into the build directory, and then all files in the
build directory were scanned for API tags. Alternatively, we could generate
the API files from a separate list. The latter actually makes sense to me
because the way it is now there is no central place to track the API except
by looking at the result of a build.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Speed of matrix multiplication

[Travis E. Oliphant]

Keith Goodman wrote:
> Why is a.T*b slower than M.dot(a.T, b)? Does it take longer to parse
> or something?
>   
The issue I think is that a is a Python class and so takes a bit longer 
to do all the things being done which includes:

1) running the Python __mul__ function
2) creating a new array (including running the __array_finalize__ Python 
function).

-Travis


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] OSX installer: please test

[Tony Theodore]

Christopher Burns  berkeley.edu> writes:

> 
> I've built a Universal Mac binary for numpy 1.1.0. 

Installed correctly on OSX 10.5.2, Intel Core 2 Duo and all tests passed.

Thanks,

Tony

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [numscons] 0.6.1 release: it build scipy, and on windows !

[David Cournapeau]

Pearu Peterson wrote:
> David Cournapeau wrote:
>
>   
>> - f2py has been almost entirely rewritten: it can now scan the 
>> 
> 
>   
>> module name automatically, and should be much more reliable.
>> 
>
> What do you mean by ^^^? ;)
>   

I did not touch f2py, don't worry :) I meant the scons tool f2py: tools 
are basically the interface between general tools (compilers, linkers, 
interface generetors like swig, etc...) and scons. Because f2py itself 
is meant to be used in distutils, which is command based, it was not 
trivial to adapt it to a tool like scons which is target based (that is 
handle dependencies through a DAG, like make).

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [numscons] 0.6.1 release: it build scipy, and on windows !

[Pearu Peterson]

David Cournapeau wrote:

> - f2py has been almost entirely rewritten: it can now scan the 

> module name automatically, and should be much more reliable.

What do you mean by ^^^? ;)

Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] f2py on windows cant find gfortran because split_quoted() removed from ccompiler.py

[Pearu Peterson]

Jarrod Millman wrote:

> Our version of split_quoted()  was added several years ago and should
> I think be submitted for inclusion upstream.  I know that distutils
> isn't exactly being maintained, but--Pearu--is it possible that we
> could get this upstream?

I looked into the distutils code again and remembered the following
circumstances:

The split_quoted hack that we have in numpy.distutils, was the
"minimal fix" of the path name handling issue - it basically adds
only two extra lines to the function body and works well.

However, the split_quoted hack is not the "right fix".
The "right fix" would require more substantial changes to distutils
(note that distutils Windows support was developed on a unix
platform and it looks like many issues were fixed for specific
usage cases).

Since the "minimal fix" did its job (consider it as a workaround
to distutils misbehavior) and the "right fix" would require
much more work as well as lots of effort to prove upstream about
the importance of required changes
(consider the current distutils development status and
the fact that the numpy.distutils expands distutils in a direction
that upstream might not be interested in because the current
issue is irrelevant for std distutils tasks), I was satisfied
with the "minimal fix" (as at the time there were more important
issues to be resolved).

I suggest to leave this issue for practical reasons: the workaround
works and the correct fix is to painful to work out. Let practicality 
beat purity in this case. I hope distutils will retire some day:)

Regards,
Pearu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [numscons] 0.6.1 release: it build scipy, and on windows !

[Matthieu Brucher]

Congratulations for this :)

Matthieu

2008/4/21, David Cournapeau <[EMAIL PROTECTED]>:
>
> Hi,
>
> I am pleased to announce the 0.6.1 release of numscons. You can get
> tarballs, eggs for python 2.4/2.5 and windows installers on launchpad:
>
> https://launchpad.net/numpy.scons.support/0.6/0.6.1
>
> I did not announce any release of numscons for some time, but this one
> is a significant milestone: it can build both numpy and scipy on linux,
> mac os X and windows (mingw only for now), and all tests pass on those
> three platforms (that is, all tests which pass on distutils build).
>
> Here is a full changelog since the last announced release:
> - Update the local copy of scons to 0.98. All internal modifications
> to scons needed for numscons are now integrated upstream, which means it
> is theoretically possible to use an external scons
> - f2py scons tool is now executed in its own process to avoid race
> issues with parallel builds. Concretely, this means building scipy with
> the --jobs options to use multi core should work.
> - f2py has been almost entirely rewritten: it can now scan the
> module name automatically, and should be much more reliable.
> - Msvc runtime issues are now fixed: the PythonExtension builder
> does not link the msvc runtime if its sources contain some fortran files
> - Added initial support for C++ flags customization
>
> cheers,
>
> David
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] [numscons] 0.6.1 release: it build scipy, and on windows !

[David Cournapeau]

Hi,

I am pleased to announce the 0.6.1 release of numscons. You can get 
tarballs, eggs for python 2.4/2.5 and windows installers on launchpad:

https://launchpad.net/numpy.scons.support/0.6/0.6.1

I did not announce any release of numscons for some time, but this one 
is a significant milestone: it can build both numpy and scipy on linux, 
mac os X and windows (mingw only for now), and all tests pass on those 
three platforms (that is, all tests which pass on distutils build).

Here is a full changelog since the last announced release:
- Update the local copy of scons to 0.98. All internal modifications 
to scons needed for numscons are now integrated upstream, which means it 
is theoretically possible to use an external scons
- f2py scons tool is now executed in its own process to avoid race 
issues with parallel builds. Concretely, this means building scipy with 
the --jobs options to use multi core should work.
- f2py has been almost entirely rewritten: it can now scan the 
module name automatically, and should be much more reliable.
- Msvc runtime issues are now fixed: the PythonExtension builder 
does not link the msvc runtime if its sources contain some fortran files
- Added initial support for C++ flags customization

cheers,

David
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion