From Norbert.Nemec.list at gmx.de  Sat Sep  1 05:35:12 2007
From: Norbert.Nemec.list at gmx.de (Norbert Nemec)
Date: Sat, 01 Sep 2007 11:35:12 +0200
Subject: [SciPy-dev] 0.6.x branch created
In-Reply-To: <85b5c3130708301624m1367cea3m8b9ad3620c78e09d@mail.gmail.com>
References: <c7009a550708291900l592488c6hb5d5a481d0488b5e@mail.gmail.com>	<db6b5ecc0708301124r2586aef2v5c51d8c36db0345c@mail.gmail.com>
	<85b5c3130708301624m1367cea3m8b9ad3620c78e09d@mail.gmail.com>
Message-ID: <46D93250.6000408@gmx.de>

Ondrej Certik wrote:
>> This hasn't happened again, so I mention it just in case anyone else
>> sees the problem (perhaps a test with random data that happened not to
>> converge?)
>>     
>
> I think there shouldn't be any random data in the tests, for exactly
> the reason above, that you will not able to reproduce the bug anyway.
>   

To be exact: whereever pseudo-random data is used, it should be seeded
deterministically.
(I'm pretty sure that true random data is not used anyway)



From ondrej at certik.cz  Sat Sep  1 12:59:19 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Sat, 1 Sep 2007 18:59:19 +0200
Subject: [SciPy-dev] Documentation to SciPy
In-Reply-To: <c7009a550708251944m641440acv880c7b9b7278b33b@mail.gmail.com>
References: <85b5c3130708221748g1ff51243rfb23ca73032eacee@mail.gmail.com>
	<c7009a550708251944m641440acv880c7b9b7278b33b@mail.gmail.com>
Message-ID: <85b5c3130709010959p39a39906ycd2c9c6ea7a6567f@mail.gmail.com>

> I like the direction you are going with the Documentation page.  I
> completely agree that we need to move toward simplification and
> streamlining the documentation.  Please go ahead, update it, and make
> your new Documentation page the official one.  I added a TOC to the
> page, which doesn't look particularly attractive.  It would be great
> if you could tidy up what I did.

I didn't find a way how to make the contents nice at the moment, so I
deleted it (it can of course be put back at any time).

>
> If you are willing to do it, I would like to ask you to become the
> official maintainer of this page.  I think that this page should be
> aimed at the new user.  This means that when someone comes to it for
> the first time they shouldn't be overwhelmed with information.  It
> should also be easy to find everything you need.  Obviously, this
> trade-off will involve careful consideration.

I think it's quite polished already. If I find time, I'll try to make
it even simpler.

How is the new release going? In the meantime, I updated the Debian
package to 0.5.2.1 and it should be finally working.

Ondrej


From nwagner at iam.uni-stuttgart.de  Wed Sep  5 13:17:05 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Wed, 05 Sep 2007 19:17:05 +0200
Subject: [SciPy-dev] NameError: global name 'sp' is not defined in r3302
Message-ID: <web-88897480@uni-stuttgart.de>

Hi all,

A name error was introduced with the recent changes.

======================================================================
ERROR: check_get_submatrix 
(scipy.tests.test_sparse.test_csr)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sparse/tests/test_sparse.py", 
line 645, in check_get_submatrix
     a = sp.csr_matrix( array([[1,2,3],[1,2,3],[0,2,0]]) )
NameError: global name 'sp' is not defined
  
Cheers,
          Nils


From wnbell at gmail.com  Wed Sep  5 13:38:06 2007
From: wnbell at gmail.com (Nathan Bell)
Date: Wed, 5 Sep 2007 12:38:06 -0500
Subject: [SciPy-dev] NameError: global name 'sp' is not defined in r3302
In-Reply-To: <web-88897480@uni-stuttgart.de>
References: <web-88897480@uni-stuttgart.de>
Message-ID: <d05265cb0709051038m7b7eb21ep7c81af33958a06b0@mail.gmail.com>

On 9/5/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Hi all,
>
> A name error was introduced with the recent changes.

Thanks for the report.  It's been fixed in r3303

-- 
Nathan Bell wnbell at gmail.com


From ryanlists at gmail.com  Wed Sep  5 22:52:43 2007
From: ryanlists at gmail.com (Ryan Krauss)
Date: Wed, 5 Sep 2007 21:52:43 -0500
Subject: [SciPy-dev] numpy.float64*poly1d = array
Message-ID: <c5b438120709051952v3f114ad3v7c50fcd4f477734b@mail.gmail.com>

I filed a ticket for this and I guess it is technically a numpy
problem, but I am curious about it.  One line recreates the problem
for me:

numpy.float64(10.0)*poly1d([1,-1])

returns
array([ 10., -10.])

I went in and added a little debugging print statement to the __mul__
and __rmul__ methods of poly1d, and neither is called when the
numpy.float64 instance is on the left.

poly1d([1,-1])*numpy.float64(10.0)
calls __mul__ and works fine.

10.0*poly1d([1,-1])
calls __rmul__ and works fine.

I got myself in this situation by multiplying a poly1d by a constant
taken from an array, which is a numpy.float64 instance.

This seems to indicate that
numpy.float64(10.0)*poly1d([1,-1])

is handled entirely by the float64 __mul__ method without calling
__rmul__ of poly1d.  Does that seem possible?  I think that is what is
happening because my cheesy
print('in rmul')  statement isn't triggered.

Thanks,

Ryan


From openopt at ukr.net  Thu Sep  6 14:00:35 2007
From: openopt at ukr.net (dmitrey)
Date: Thu, 06 Sep 2007 21:00:35 +0300
Subject: [SciPy-dev] openopt (prelimenary) announce
Message-ID: <46E04043.80805@ukr.net>

Hi all,
here's a message that I intend to publish in Python and scipy-user mail lists, some changes were made by Alan Isaac.
If you don't mind I want to publish it before in scipy-dev mail-list, maybe you would like to propose some changes.
Regards, D.


Announcing: OpenOpt (a SciPy scikit)
====================================

OpenOpt is new open source optimization framework, provided as a SciPy scikit.

Goal: provide an essential open source alternative to TomOpt TOMLAB <http://tomopt.com/tomlab/> (optimization framework for MATLAB) and related commercial optimization frameworks and solvers.

key features are: a unified calling interface for all solvers,
a variety of pure Python solvers, graphic output <http://openopt.blogspot.com/2007/09/examples-of-openopt-graphics-output.html> and connections to 
numerous external solvers.

Example::

    from scikits.openopt import NLP
    p = NLP(lambda x: (x-1)**2, 4)
    r = p.solve('ralg')

In this example,
the objective function is (x-1)2,
the start point is x0=4,
and 'ralg' specifies the name of solver involved.


See much more detailed example here 
<URL:http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nlp_ALGENCAN.py> 


License
-------

OpenOpt itself is released under the BSD license.  It provides connections to various solvers, which may have licenses (first of all we are interested in connecting opensource ones).

In contrast to SciPy, the related scikits may host any OSI-approved licensed code.  OpenOpt provides several solvers (ralg, lincher, ShorEllipsoid), and provides connections to still more.  (For the latter, it provides URLs for download.)  Our own solvers are 100% Python with a single dependency: NumPy, so no problems with installation Fortran or C code will be encountered.


Solvers available for now
--------------------------

Non-linear problems (NLP)
~~~~~~~~~~~~~~~~~~~~~~~~~

- ALGENCAN <http://www.ime.usp.br/%7Eegbirgin/tango/py.php> 
  (GPL)
- lincher (BSD) (all types of constraints and 1st derivatives),
- ralg (BSD) (currently unconstrained only)
- scipy_tnc and scipy_lbfgsb (box-bounded, requires scipy 
  installed, BSD)

Non-smooth problems (NSP)
~~~~~~~~~~~~~~~~~~~~~~~~~

- ralg (BSD) (for medium-scaled problems with nVars = 1...1000)
- ShorEllipsoid (BSD)
  (for small-scale problems with nVars = 1..10, requires r0)
(both are unconstrained for now).


Linear problems (LP)
~~~~~~~~~~~~~~~~~~~~

- lp_solve <http://sourceforge.net/projects/lpsolve> (LGPL)
- glpk <http://www.gnu.org/software/glpk/> (GPL)
- CVXOPT <http://www.ee.ucla.edu/%7Evandenbe/cvxopt/> (GPL) 
  (currently glpk requires CVXOPT installed)


Mixed-integer problems (MILP)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- lp_solve <http://sourceforge.net/projects/lpsolve> 


Quadratic problems (QP)
~~~~~~~~~~~~~~~~~~~~~~~
- CVXOPT <http://www.ee.ucla.edu/%7Evandenbe/cvxopt/> (GPL) 
  (please note - NLP lincher solver requires QP solver, and 
  the only one for now is CVXOPT one)

Here you can look at examples for NLP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nlp_1.py>, 
NSP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nsp_1.py>, 
QP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/qp_1.py>, 
LP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/lp_1.py>, 
MILP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/milp_1.py> 
usage 


GenericOpt
==========

Of related interest is GenericOpt, a package that is 
connected to OpenOpt but is also available as separate 
module "optimizers".  The primary author is Matthieu 
Brucher.  GenericOpt allows users who want detailed control 
to construct their own solvers by choosing among a variety 
of algorithm components (currently, most choices are among 
step and line-search algorithms.)

Usage: see Matthieu's tutorial 
<URL:https://projects.scipy.org/scipy/scikits/wiki/Optimization/tutorial>.  

Limitation: currently GenericOpt provides only unconstrained solvers. 

Acknowledgements
================

The OpenOpt project was sponsored by Google throught the GSoC program (Google Summer of Code). Most of code was written by GSoC student Dmitrey Kroshko (Optimization Department, Cybernetics Institute, Ukrainian Science Academy, and the dept staff suggestions were very useful) under the mentoring of SciPy developers Alan G Isaac and Jarrod Milman. 

Appeal
======

scikits.openopt development is intended to continue but to keep it intensive OpenOpt requires a new sponsor (since google Summer of Code 2007 program is finished), since in Ukraine interest in the use of Python for scientific programming is lagging. Ideas or leads are very welcome.



From matthieu.brucher at gmail.com  Thu Sep  6 14:41:15 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 6 Sep 2007 20:41:15 +0200
Subject: [SciPy-dev] openopt (prelimenary) announce
In-Reply-To: <46E04043.80805@ukr.net>
References: <46E04043.80805@ukr.net>
Message-ID: <e76aa17f0709061141y4c088b12pcc191fa0da3c5c80@mail.gmail.com>

Hi,

Excellent preliminary announce, but this can be confusing :

The OpenOpt project was sponsored by Google throught the GSoC program
> (Google Summer of Code). Most of code was written by GSoC student Dmitrey
> Kroshko (Optimization Department, Cybernetics Institute, Ukrainian Science
> Academy, and the dept staff suggestions were very useful) under the
> mentoring of SciPy developers Alan G Isaac and Jarrod Milman.


I don't know exactly how much you wrote (in terms of number of caracters),
but I don't think that "most of the code" is the right locution. You can
perhaps write that it was written by both of us ?

Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070906/3987563b/attachment.html>

From aisaac at american.edu  Thu Sep  6 14:55:33 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 6 Sep 2007 14:55:33 -0400
Subject: [SciPy-dev] openopt (prelimenary) announce
In-Reply-To: <e76aa17f0709061141y4c088b12pcc191fa0da3c5c80@mail.gmail.com>
References: <46E04043.80805@ukr.net><e76aa17f0709061141y4c088b12pcc191fa0da3c5c80@mail.gmail.com>
Message-ID: <Mahogany-0.67.0-1312-20070906-145533.00@american.edu>

On Thu, 6 Sep 2007, Matthieu Brucher apparently wrote:
> I don't know exactly how much you wrote (in terms of 
> number of caracters), but I don't think that "most of the 
> code" is the right locution. You can perhaps write that it 
> was written by both of us ? 

I think Dmitrey makes a conceptual distinction
between the OpenOpt framework and the optimizers
it relies on. Your project he referred to here as 
GenericOpt. (Your name?) I think this distinction
captures well where the two of you put your main efforts?
I realize now that I made that distinction as well, so I did 
not "stumble" where you did in reading it.  This in fact may 
be a bit confusing, so a proper rephrasing is needed.  Sorry 
for missing that.

Cheers,
Alan Isaac





From openopt at ukr.net  Thu Sep  6 16:18:18 2007
From: openopt at ukr.net (dmitrey)
Date: Thu, 06 Sep 2007 23:18:18 +0300
Subject: [SciPy-dev] openopt (prelimenary) announce
In-Reply-To: <Mahogany-0.67.0-1312-20070906-145533.00@american.edu>
References: <46E04043.80805@ukr.net><e76aa17f0709061141y4c088b12pcc191fa0da3c5c80@mail.gmail.com>
	<Mahogany-0.67.0-1312-20070906-145533.00@american.edu>
Message-ID: <46E0608A.9070008@ukr.net>

Alan G Isaac wrote:
> On Thu, 6 Sep 2007, Matthieu Brucher apparently wrote:
>   
>> I don't know exactly how much you wrote (in terms of 
>> number of caracters), but I don't think that "most of the 
>> code" is the right locution. You can perhaps write that it 
>> was written by both of us ? 
>>     
>
> I think Dmitrey makes a conceptual distinction
> between the OpenOpt framework and the optimizers
> it relies on. Your project he referred to here as 
> GenericOpt. (Your name?) I think this distinction
> captures well where the two of you put your main efforts?
> I realize now that I made that distinction as well, so I did 
> not "stumble" where you did in reading it.  This in fact may 
> be a bit confusing, so a proper rephrasing is needed.  Sorry 
> for missing that.
>
> Cheers,
> Alan Isaac
>
>   
so, despite I insisted optimizers remain also as separate package, the 
idea of merging optimizers(/GenericOpt) to openopt, as I suppose from 
the very beginning, wasn't the best one, partially because they serves 
different goals and different motivations.

Maybe we should handle these packages separately (providing connection, 
of course)?
Then we could make 2 announcements: one of openopt release and one of 
optimizers/GenericOpt.

As another solution, we could announce in one message 2 scikit modules - 
OpenOpt and GenericOpt (or optimizers), where GenericOpt is supplied 
with connection to OpenOpt. Also, afaik, it's possible to implement in 
setuptools automatic download of GenericOpt while installing openopt (in 
any way, I don't mind if Matthieu want to continue host a part or all 
his code in /solvers/GenericOpt and /solvers/optimizers directories as 
it is now).

The problem of "openopt" word is not 100% mine - the problem is that I 
discussed the term with our dept, and they were quite agree to provide 
quite good maintain to "our openopt project" (at least with their 
advices), but what should I say them that now, when they will ask like 
"what? we discussed to be single author and now we are just one of lots, 
with undefined exactly rights - for name ("What?! Our OpenOpt is no 
longer our?!" - would it be scipy-owned, I could so-so silently avoid 
the (one of biggest) question, but real humans is much more big 
problem), for sponsor's income sharing (if it will be), etc, so each 
time we intend to do something we should discuss (and maybe even more - 
take agree) from foreign language speaker(s)? nope, we are not 
interested anymore..." :(

As for names, we could (as one of possible solutions) don't mention them 
at all.

Regards, D.
P.S. Maybe Alan or someone else will remind me once again - scipy team 
decided to get all rights of the GSoC code to itself, and all those my 
words that I had wrote to my mentors doesn't matter. Ok, I don't mind, 
you really have the right, the only thing I would say is that I hadn't 
know it from the very beginning (it's very unlikely that I would cease 
openopt development because of this, but at least I would reorganize 
some openopt tasks priorities, that would simplify openopt maintenance 
by someone else, should I cease maintenance because of my dept's demand 
to switch to other projects and/or other reasons).
As someone from scipy dev team said like "GSoC project is just a way to 
deter is a student appropriate for work in a team" (so it sounds like 
they don't care very much about results obtained and who is their 
owner), and, as
 http://code.google.com/support/bin/answer.py?answer=60327&topic=10728
says, the situation is unclear - and very bad if the question arises in 
a middle or end of program (as for me I think it's not my or mentors 
failure - it's a serious GSOC drawback that should be fixed, the 
question must be discussed between student and organization from the 
very beginning, maybe even when organization only appeared in GSoC 
members list it should inform who will be copyholder of student's code).

Ok, I think I said all my thoughts about the problem, if Matthieu and/or 
mentors team will find my suggestions inappropriate, let mentors (and/or 
scipy dev team, and/or Python GSoC 2007 administrator JamesTauber 
<http://wiki.python.org/moin/JamesTauber> - as you wish) decide which 
text to publish (as code owners you even could do it by yourself if you 
want to (announce your openopt), I don't mind, or you could send final 
text to me to publish).

Regards, D.


From aisaac at american.edu  Thu Sep  6 17:50:28 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 6 Sep 2007 17:50:28 -0400
Subject: [SciPy-dev] draft announcement
Message-ID: <Mahogany-0.67.0-1312-20070906-175028.00@american.edu>

Hoping Dmitrey and Matthieu (and others) like this ...
Alan Isaac


OpenOpt and GenericOpt
======================

OpenOpt and GenericOpt are 100% Python
with a single dependency: NumPy.

OpenOpt
-------

OpenOpt is new open source optimization framework.
OpenOpt is released under the BSD license.

The primary author and current maintainer of
OpenOpt is Dmitrey Kroshko.
(Optimization Department, Cybernetics Institute, Ukrainian Science Academy)

OpenOpt goal: provide an open source alternative
to TomOpt TOMLAB (optimization framework for MATLAB)
and related optimization frameworks.  Currently OpenOpt
offers connections to a variety of open source solvers,
primarily for unconstrained optimization. (See below.)

OpenOpt provides provides connections a vraity of solvers,
including those in GenericOpt, which are included.
(Users will need to download other solvers;
we provide URLs for download.)


GenericOpt
----------

GenericOpt is a toolkit for building specialized optimizers.
GenericOpt is released under the BSD license.

The primary author and current maintainer of GenericOpt is Matthieu Brucher.

GenericOpt goal: provide an open source, extensible
toolit for "component-wise" construction of specialized
optimizers.  GenericOpt allows users who want detailed control to construct
their own solvers by choosing among a variety of algorithm components
(currently, most choices are among step and line-search algorithms.)

Usage: see Matthieu's tutorial 
<URL:https://projects.scipy.org/scipy/scikits/wiki/Optimization/tutorial>.  

Limitation: currently GenericOpt provides only unconstrained solvers. 

SciKits
-------

The SciPy project is developing a collection of open source packages for
scientific computing which are allowed to have more dependencies and
more varied licenses than those allowed for SciPy proper.
In contrast to SciPy, the related scikits may host any 
OSI-approved licensed code.

OpenOpt and GenericOpt are available together as a
SciPy scikit.  However, neither depends on the other.


OpenOpt Details
---------------

Key feature: a unified calling interface for all solvers,
a variety of pure Python solvers, and connections to 
numerous external solvers.

Example::

    from scikits.openopt import NLP
    p = NLP(lambda x: (x-1)**2, 4)
    r = p.solve('ralg')

In this example,
the objective function is (x-1)^2,
the start point is x0=4,
and 'ralg' specifies the name of solver involved.

See much more detailed example here 
<URL:http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nlp_ALGENCAN.py> 




OpenOpt Connected External Solvers
----------------------------------

Non-linear problems (NLP)
~~~~~~~~~~~~~~~~~~~~~~~~~

- ALGENCAN <http://www.ime.usp.br/%7Eegbirgin/tango/py.php> 
  (GPL)
- lincher (BSD) (all types of constraints and 1st derivatives),
- ralg (BSD) (currently unconstrained only)
- scipy_tnc and scipy_lbfgsb (box-bounded, requires scipy 
  installed, BSD)

Non-smooth problems (NSP)
~~~~~~~~~~~~~~~~~~~~~~~~~

- ralg (BSD)
- ShorEllipsoid (BSD)
  (for small-scale problems with nVars = 1..10, former for 
  medium-scaled problems with nVars = 1...1000, requires r0)
  
Both are unconstrained for now.


Linear problems (LP)
~~~~~~~~~~~~~~~~~~~~

- lp_solve <http://sourceforge.net/projects/lpsolve> (LGPL)
- glpk <http://www.gnu.org/software/glpk/> (GPL)
- CVXOPT <http://www.ee.ucla.edu/%7Evandenbe/cvxopt/> (GPL) 
  (currently glpk requires CVXOPT installed)


Mixed-integer problems (MILP)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

- lp_solve <http://sourceforge.net/projects/lpsolve> 


Quadratic problems (QP)
~~~~~~~~~~~~~~~~~~~~~~~
- CVXOPT <http://www.ee.ucla.edu/%7Evandenbe/cvxopt/> (GPL) 
  (please note - NLP lincher solver requires QP solver, and 
  the only one for now is CVXOPT one)

Here you can look at examples for NLP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nlp_1.py>, 
NSP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/nsp_1.py>, 
QP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/qp_1.py>, 
LP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/lp_1.py>, 
MILP 
<http://projects.scipy.org/scipy/scikits/browser/trunk/openopt/scikits/openopt/examples/milp_1.py> 
usage 


Acknowledgements
================

Development of OpenOpt was supported by Google through the 
Google Summer of Code (GSoC) program, with Alan G. Isaac
as mentor.  Additonal mentorship was provided by Jarrod Milman. 
Debts to the SciPy community are many.


Appeal
======

The primary author and current maintainer of OpenOpt is Dmitrey Kroshko.  The
primary author and current maintainer of GenericOpt is Matthieu Brucher.
OpenOpt would profit from additiona intensive development, but this will
require a sponsor.  The use of Python for scientific programming is only
nascent in the Ukraine, so really an outside sponsor is needed.  Ideas or leads
are very welcome.









From aisaac at american.edu  Thu Sep  6 17:50:30 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 6 Sep 2007 17:50:30 -0400
Subject: [SciPy-dev] openopt (prelimenary) announce
In-Reply-To: <46E0608A.9070008@ukr.net>
References: <46E04043.80805@ukr.net><e76aa17f0709061141y4c088b12pcc191fa0da3c5c80@mail.gmail.com>
	<Mahogany-0.67.0-1312-20070906-145533.00@american.edu><46E0608A.9070008@ukr.net>
Message-ID: <Mahogany-0.67.0-1312-20070906-175030.00@american.edu>

On Thu, 06 Sep 2007, dmitrey apparently wrote:
> so, despite I insisted optimizers remain also as separate 
> package, the idea of merging optimizers(/GenericOpt) to 
> openopt, as I suppose from the very beginning, wasn't the 
> best one, partially because they serves different goals 
> and different motivations. 

On the contrary, I think this was a very good decision.
OpenOpt gains pure Python solvers, and GenericOpt gets
extensive use, testing, and code contributions.

> we could make 2 announcements: one of openopt release and 
> one of optimizers/GenericOpt. 

Since they share a location, a joint announcement seems
appropriate.  I'll post one to this list, and you and 
Matthieu can react.

> in any way, I don't mind if Matthieu want to continue host 
> a part or all his code in /solvers/GenericOpt and 
> /solvers/optimizers directories as it is now). 

That is good. But in any case, such decisions are to be made
by the SciPy development *community*, hopefully on
a consensus basis.

I'm not going to respond in detail to the other message
parts, other than to say I do not really see any problem
**except** for the problem about ensuring that expectations
between mentors and students are aligned when the GSoC
projects *begin*.  I learned a lot about that this summer:
it is easy for people to assume they share a common
understanding when in fact there are some very fundamental
differences in expectations.

I guess I would add my opinion that the most important thing 
is the BSD license, not who holds the copyright.  However to 
correct an impression you seem to have: as far as I am 
aware, neither Jarrod nor I ever suggested that you give up 
your copyright.  We simply insisted that you treat your GSoC 
project as what it was: an opportunity to participate in and 
contribute to SciPy **community**, under the BSD license, 
while interacting with a group of developers from whom you 
can learn a great deal.  To participate in a **community** 
is to treat many decisions as **joint** as to accept and 
indeed welcome the contributions of others to improving the 
scikits code base, including the parts you have been most 
involved in.

Cheers,
Alan Isaac





From matthieu.brucher at gmail.com  Thu Sep  6 17:59:55 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Thu, 6 Sep 2007 23:59:55 +0200
Subject: [SciPy-dev] openopt (prelimenary) announce
In-Reply-To: <Mahogany-0.67.0-1312-20070906-175030.00@american.edu>
References: <46E04043.80805@ukr.net>
	<e76aa17f0709061141y4c088b12pcc191fa0da3c5c80@mail.gmail.com>
	<Mahogany-0.67.0-1312-20070906-145533.00@american.edu>
	<46E0608A.9070008@ukr.net>
	<Mahogany-0.67.0-1312-20070906-175030.00@american.edu>
Message-ID: <e76aa17f0709061459t779f3c4du10b17c497326b503@mail.gmail.com>

2007/9/6, Alan G Isaac <aisaac at american.edu>:
>
> On Thu, 06 Sep 2007, dmitrey apparently wrote:
> > so, despite I insisted optimizers remain also as separate
> > package, the idea of merging optimizers(/GenericOpt) to
> > openopt, as I suppose from the very beginning, wasn't the
> > best one, partially because they serves different goals
> > and different motivations.
>
> On the contrary, I think this was a very good decision.
> OpenOpt gains pure Python solvers,



I will soon completely connect the generic optimizers to the framework
Dmitrey uses for his optimizers


and GenericOpt gets
> extensive use, testing, and code contributions.



I think we both wait for this :)

Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070906/19e2e7b2/attachment.html>

From openopt at ukr.net  Fri Sep  7 03:21:41 2007
From: openopt at ukr.net (dmitrey)
Date: Fri, 07 Sep 2007 10:21:41 +0300
Subject: [SciPy-dev] openopt (prelimenary) announce
In-Reply-To: <46E0608A.9070008@ukr.net>
References: <46E04043.80805@ukr.net><e76aa17f0709061141y4c088b12pcc191fa0da3c5c80@mail.gmail.com>	<Mahogany-0.67.0-1312-20070906-145533.00@american.edu>
	<46E0608A.9070008@ukr.net>
Message-ID: <46E0FC05.4020707@ukr.net>

dmitrey wrote:
> The problem of "openopt" word is not 100% mine
Sorry, I don't mean "the problem is not mine but is yours as well", 
like, it seems, were read by some people,
I meant "This problem had raised because of my dept, hence I share this 
one with my dept", really.

So, today I answered to Alan's letter more precisely of that one and I 
hope we'll find appropriate solution.

As for "Acknowledgements" section, I didn't write it at all (I mentioned 
mentors in other part of letter, because I'm not experienced in English 
language and style of creating such letters), it was Alan who add that 
one and move part of text about mentors there.

Also, I think, if the section will exist (and/or if we decide to publish 
names in the announcement), then Nils Wagner should be mentioned there.

Regards, D.



From ondrej at certik.cz  Sat Sep  8 06:54:24 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Sat, 8 Sep 2007 12:54:24 +0200
Subject: [SciPy-dev] new release
Message-ID: <85b5c3130709080354h40d34659xcb709d1c60af1ee4@mail.gmail.com>

Hi,

are there any problems with the new release? I thought it was planned
a week ago, but suddenly it was quiet on the mailinglist about it. If
there are still things to fix, let's do a sprint, fix problems and
release. Jarrod? :)

Ondrej


From millman at berkeley.edu  Sat Sep  8 12:46:18 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Sat, 8 Sep 2007 11:46:18 -0500
Subject: [SciPy-dev] new release
In-Reply-To: <85b5c3130709080354h40d34659xcb709d1c60af1ee4@mail.gmail.com>
References: <85b5c3130709080354h40d34659xcb709d1c60af1ee4@mail.gmail.com>
Message-ID: <c7009a550709080946u45bd1cf4h173feff9ae6f0998@mail.gmail.com>

Sorry for that.  I am busy doing some work in Dallas.  I will be
flying back on Sunday night and should be able to finalize the release
this coming week.  There is nothing holding up the release other than
I didn't get it out before I left for Dallas.  I have a few small
things that I want to do before the release, but it won't take long.
I just have to do it.

Jarrod

On 9/8/07, Ondrej Certik <ondrej at certik.cz> wrote:
> Hi,
>
> are there any problems with the new release? I thought it was planned
> a week ago, but suddenly it was quiet on the mailinglist about it. If
> there are still things to fix, let's do a sprint, fix problems and
> release. Jarrod? :)
>
> Ondrej
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>


-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From nwagner at iam.uni-stuttgart.de  Sun Sep  9 13:15:41 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sun, 09 Sep 2007 19:15:41 +0200
Subject: [SciPy-dev] Usage of enabled_packages.txt with recent svn
Message-ID: <web-89046631@uni-stuttgart.de>

Hi all,

I have created a file "enabled_packages.txt" in the
directory scipy/scipy/sandbox. Now I can't build
scipy from svn.

     config = setup_module.configuration(*args)
   File "scipy/sandbox/setup.py", line 24, in 
configuration
     config.add_subpackage(p)
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/distutils/misc_util.py", 
line 835, in add_subpackage
     caller_level = 2)
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/distutils/misc_util.py", 
line 818, in get_subpackage
     caller_level = caller_level + 1)
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/distutils/misc_util.py", 
line 765, in _get_configuration_from_setup_py

     config = setup_module.configuration(*args)
   File "scipy/sandbox/arpack/setup.py", line 9, in 
configuration
     lapack_opt = get_info('lapack_opt')
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/distutils/system_info.py", 
line 256, in get_info
     return cl().get_info(notfound_action)
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/distutils/system_info.py", 
line 424, in get_info
     return copy.deepcopy(res)
   File "/usr/lib64/python2.5/copy.py", line 162, in 
deepcopy
     y = copier(x, memo)
   File "/usr/lib64/python2.5/copy.py", line 254, in 
_deepcopy_dict
     y[deepcopy(key, memo)] = deepcopy(value, memo)
   File "/usr/lib64/python2.5/copy.py", line 162, in 
deepcopy
     y = copier(x, memo)
   File "/usr/lib64/python2.5/copy.py", line 227, in 
_deepcopy_list
     y.append(deepcopy(a, memo))
   File "/usr/lib64/python2.5/copy.py", line 192, in 
deepcopy
     _keep_alive(x, memo) # Make sure x lives at least as 
long as d
   File "/usr/lib64/python2.5/copy.py", line 271, in 
_keep_alive
     memo[id(memo)].append(x)
RuntimeError: maximum recursion depth exceeded in cmp


Nils



From cimrman3 at ntc.zcu.cz  Mon Sep 10 04:02:07 2007
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Mon, 10 Sep 2007 10:02:07 +0200
Subject: [SciPy-dev] sparse matrix indexing (__getitem__ or not?)
Message-ID: <46E4F9FF.7080900@ntc.zcu.cz>

Hi,

I have added a function to fill in the gap in the CSR matrix indexing
capabilities into sparsetools. It extracts a submatrix (makes a new
matrix) using row and column slices. For the moment it has been made
accessible by adding a new method get_submatrix( self, slice0, slice1 )
to csr_matrix class - the method returns a new matrix and not a view, as
indexing via [] (__getitem__()) currently does. Note that it could be
easily extended for general indexing by index arrays.

It is not possible for a sparse matrix to return a view of a general
submatrix, therefore I would like to discuss here which of the following
two possibilities suit the other sparse matrix users better:

1. __getitem__() returns views only, other submatrix extraction
functionality is accessed via another method (e.g. get_submatrix()).
This case is compatible with the behaviour of dense arrays, but IMHO a
bit clumsy.

2. __getitem__() returns views or new matrices as necessary (properly
documented for each sparse matrix kind). This case differs in behaviour
from the dense arrays but, pragmatically, I like this case more.

As a side-note, even if the second item gets implemented, I see a niche
for the get_submatrix() method - it could have additional arguments
specifying for example that it should return a dense array instead of
the sparse one.

r.



From cimrman3 at ntc.zcu.cz  Mon Sep 10 04:07:17 2007
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Mon, 10 Sep 2007 10:07:17 +0200
Subject: [SciPy-dev] _cs_matrix._matvec()
Message-ID: <46E4FB35.1090401@ntc.zcu.cz>

hi again,

looking at _cs_matrix class in sparse.py, I noticed
    def _matvec(self, other, fn):
        if isdense(other):
            # This check is too harsh -- it prevents a column vector from
            # being created on-the-fly like dense matrix objects can.
            #if len(other) != self.shape[1]:
            #    raise ValueError, "dimension mismatch"
            oth = numpy.ravel(other)
            y = fn(self.shape[0], self.shape[1], \
                   self.indptr, self.indices, self.data, oth)
            if isinstance(other, matrix):
                y = asmatrix(y)
            if other.ndim == 2 and other.shape[1] == 1:
                # If 'other' was an (nx1) column vector, transpose the
result
                # to obtain an (mx1) column vector.
                y = y.T
            return y

I do not see a reason for the commenting out of the lines
            #if len(other) != self.shape[1]:
            #    raise ValueError, "dimension mismatch"
as the function silently passes with wrong input.

Could anybody explain this? I would uncomment the lines, but maybe there
is a reason...

r.



From nwagner at iam.uni-stuttgart.de  Tue Sep 11 12:47:58 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 11 Sep 2007 18:47:58 +0200
Subject: [SciPy-dev] sandbox package arpack
Message-ID: <web-89182735@uni-stuttgart.de>

Hi all,

The sandbox package *arpack* has no entry in setup.py 
(from svn). Is this a bug ?

Nils
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python
Size: 2735 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070911/61ee0206/attachment.py>

From robert.kern at gmail.com  Tue Sep 11 12:56:51 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 11 Sep 2007 11:56:51 -0500
Subject: [SciPy-dev] sandbox package arpack
In-Reply-To: <web-89182735@uni-stuttgart.de>
References: <web-89182735@uni-stuttgart.de>
Message-ID: <46E6C8D3.3050605@gmail.com>

Nils Wagner wrote:
> Hi all,
> 
> The sandbox package *arpack* has no entry in setup.py (from svn). Is
> this a bug ?

No. Use an enabled_packages.txt file.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From nwagner at iam.uni-stuttgart.de  Tue Sep 11 14:35:43 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 11 Sep 2007 20:35:43 +0200
Subject: [SciPy-dev] FAIL: test_imresize
Message-ID: <web-89186888@uni-stuttgart.de>

Hi all,

Can someone reproduce the following failures with latest 
svn
versions of numpy/scipy ?

scipy.test(1) yields

======================================================================
FAIL: test_imresize 
(scipy.misc.tests.test_pilutil.test_pilutil)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/misc/tests/test_pilutil.py", 
line 18, in test_imresize
     assert_equal(im1.shape,(11,22))
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", 
line 137, in assert_equal
     assert_equal(len(actual),len(desired),err_msg,verbose)
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/testing/utils.py", 
line 145, in assert_equal
     assert desired == actual, msg
AssertionError:
Items are not equal:
  ACTUAL: 0
  DESIRED: 2

======================================================================
FAIL: testip_fromimage 
(scipy.misc.tests.test_pilutil.test_pilutil)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/testing/parametric.py", 
line 67, in exec_test
     test(*args)
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/misc/tests/test_pilutil.py", 
line 29, in tst_fromimage
     assert img.min() >= imin
AssertionError

======================================================================
FAIL: testip_fromimage 
(scipy.misc.tests.test_pilutil.test_pilutil)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/testing/parametric.py", 
line 67, in exec_test
     test(*args)
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/misc/tests/test_pilutil.py", 
line 29, in tst_fromimage
     assert img.min() >= imin
AssertionError

======================================================================
FAIL: testip_fromimage 
(scipy.misc.tests.test_pilutil.test_pilutil)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/numpy/testing/parametric.py", 
line 67, in exec_test
     test(*args)
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/misc/tests/test_pilutil.py", 
line 29, in tst_fromimage
     assert img.min() >= imin
AssertionError


Nils


From nwagner at iam.uni-stuttgart.de  Tue Sep 11 14:53:22 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Tue, 11 Sep 2007 20:53:22 +0200
Subject: [SciPy-dev] sandbox package arpack
In-Reply-To: <46E6C8D3.3050605@gmail.com>
References: <web-89182735@uni-stuttgart.de>
 <46E6C8D3.3050605@gmail.com>
Message-ID: <web-89187420@uni-stuttgart.de>

On Tue, 11 Sep 2007 11:56:51 -0500
  Robert Kern <robert.kern at gmail.com> wrote:
> Nils Wagner wrote:
>> Hi all,
>> 
>> The sandbox package *arpack* has no entry in setup.py 
>>(from svn). Is
>> this a bug ?
> 
> No. Use an enabled_packages.txt file.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an 
>enigma, a harmless enigma
> that is made terrible by our own mad attempt to 
>interpret it as though it had
> an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

  
Hi Robert,

Thank you ! Now it works for me. I have removed an
empty line at the end of enabled_packages.txt.

BTW, when I import the sandbox package multigrid I get
Python 2.5 (r25:51908, May 25 2007, 16:11:33)
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from scipy.sandbox import multigrid
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/__init__.py", 
line 5, in <module>
     from multilevel import *
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/multilevel.py", 
line 11, in <module>
     from coarsen import sa_interpolation,rs_interpolation
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/coarsen.py", 
line 6, in <module>
     from utils import diag_sparse,infinity_norm
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/utils.py", 
line 3, in <module>
     import numpy,scipy,scipy.sparse,scipy.weave
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/weave/__init__.py", 
line 9, in <module>
     from blitz_tools import blitz
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/weave/blitz_tools.py", 
line 7, in <module>
     import converters
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/weave/converters.py", 
line 39, in <module>
     default.append(numpy_scalar_spec.numpy_complex_scalar_converter())
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/weave/c_spec.py", 
line 74, in __init__
     self.init_info()
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/weave/numpy_scalar_spec.py", 
line 19, in init_info
     self.matching_types = [numpy.complex128, 
numpy.complex192,
AttributeError: 'module' object has no attribute 
'complex192'

Nils


From wnbell at gmail.com  Tue Sep 11 15:43:50 2007
From: wnbell at gmail.com (Nathan Bell)
Date: Tue, 11 Sep 2007 14:43:50 -0500
Subject: [SciPy-dev] sandbox package arpack
In-Reply-To: <web-89187420@uni-stuttgart.de>
References: <web-89182735@uni-stuttgart.de> <46E6C8D3.3050605@gmail.com>
	<web-89187420@uni-stuttgart.de>
Message-ID: <d05265cb0709111243q21838d64xc393de38268a9007@mail.gmail.com>

On 9/11/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Thank you ! Now it works for me. I have removed an
> empty line at the end of enabled_packages.txt.
>
> BTW, when I import the sandbox package multigrid I get

I don't need weave for the multigrid package anymore, so I'll remove
the import.  The multigrid package is still fairly new, so it may be a
little rough around the edges :)

-- 
Nathan Bell wnbell at gmail.com


From eric at enthought.com  Tue Sep 11 16:11:30 2007
From: eric at enthought.com (eric jones)
Date: Tue, 11 Sep 2007 15:11:30 -0500
Subject: [SciPy-dev] sandbox package arpack
In-Reply-To: <web-89187420@uni-stuttgart.de>
References: <web-89182735@uni-stuttgart.de> <46E6C8D3.3050605@gmail.com>
	<web-89187420@uni-stuttgart.de>
Message-ID: <46E6F672.6050403@enthought.com>

Mea cupla.  It looks like all the types are not available on all 
machines.  Travis O. just explained how to do this the "right way."  
Working on the fix now.

eric

> "/usr/local/lib64/python2.5/site-packages/scipy/weave/numpy_scalar_spec.py", 
> line 19, in init_info
>      self.matching_types = [numpy.complex128, 
> numpy.complex192,
> AttributeError: 'module' object has no attribute 
> 'complex192'
>
> Nils
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
>   



From openopt at ukr.net  Wed Sep 12 09:06:02 2007
From: openopt at ukr.net (dmitrey)
Date: Wed, 12 Sep 2007 16:06:02 +0300
Subject: [SciPy-dev] don't you mind to add openopt and genericopt to webpage
 "Topical software"?
Message-ID: <46E7E43A.4070201@ukr.net>

hi all,
don't you mind to add scikits.openopt and genericopt to Topical software?
If you don't, I shall add just no more than ~3-4 lines to the page about 
scikits.openopt, and I guess the same Matthieu will do.
If you think that one or both of the modules are not ready to join the 
webpage enough for now, please answer the message to prevent changing 
the page.
Regards, D.




From james at NBN.ac.za  Wed Sep 12 10:47:02 2007
From: james at NBN.ac.za (James Dominy)
Date: Wed, 12 Sep 2007 16:47:02 +0200
Subject: [SciPy-dev] First alpha release of PySUNDIALS
Message-ID: <46E7FBE6.3090509@nbn.ac.za>

Hi Everyone,

The first alpha release of PySUNDIALS (a python package providing python bindings for SUNDIALS) has been released. It's not a
SciPy module, but is likely to be of interest to many on this list.

It is considered alpha, as it has yet to undergo extensive testing. CVODE, CVODES, KINSOL, and IDA have a complete set of
bindings. Work has begun on the examples provided with SUNDIALS to compare against the results of their C counterparts, and of
course to weed out any blatant bugs in the python modules.

It is available on SourceForge at http://www.sourceforge.net/projects/pysundails for anyone who is interested in giving it a
test run. Bug reports and feature requests can be submitted through SourceForge too.

Enjoy!
James

P.S. If anyone feels like giving me a hand translating the comments in the C code to python doc-strings, let me know...


From openopt at ukr.net  Wed Sep 12 11:15:19 2007
From: openopt at ukr.net (dmitrey)
Date: Wed, 12 Sep 2007 18:15:19 +0300
Subject: [SciPy-dev] problems with login/register in scikits page
Message-ID: <46E80287.2010908@ukr.net>

hi all,
once again I can't neither login with any my accounts I ever done in 
scikits page nor register. It prompts to enter login and password from 
scipy page, but despite I can login to that one with name DmitreyKroshko 
and password <mypassw> it didn't help to login to scikits page in the 
prompt window, it appears again and again. If I press cancel, I get


  Authorization Required

This server could not verify that you are authorized to access the 
document requested. Either you supplied the wrong credentials (e.g., bad 
password), or your browser doesn't understand how to supply the 
credentials required.

------------------------------------------------------------------------
Apache/2.0.54 (Fedora) Server at scipy.org Port 80



Please fin the issues ASAP.
http://scipy.org/scipy/scikits/login
http://scipy.org/scipy/scikits/register

If it's essential, I use Mozilla Firefox, Ubuntu.
I have removed cookies but the problem remains.

Regards, D.


From jstrunk at enthought.com  Wed Sep 12 11:30:01 2007
From: jstrunk at enthought.com (Jeff Strunk)
Date: Wed, 12 Sep 2007 10:30:01 -0500
Subject: [SciPy-dev] problems with login/register in scikits page
In-Reply-To: <46E80287.2010908@ukr.net>
References: <46E80287.2010908@ukr.net>
Message-ID: <200709121030.01694.jstrunk@enthought.com>

Trac, moin, and subversion all use different authentication. I did notice that 
the scikits trac was using its own htdigest file again, so I changed it back 
to using the scipy trac's htdigest file. Please let me know if you can't log 
in to the scikits trac with your scipy trac login information. Your username 
in trac is dmitrey.kroshko .

Jeff

On Wednesday 12 September 2007 10:15 am, dmitrey wrote:
> hi all,
> once again I can't neither login with any my accounts I ever done in
> scikits page nor register. It prompts to enter login and password from
> scipy page, but despite I can login to that one with name DmitreyKroshko
> and password <mypassw> it didn't help to login to scikits page in the
> prompt window, it appears again and again. If I press cancel, I get
>
>
>   Authorization Required
>
> This server could not verify that you are authorized to access the
> document requested. Either you supplied the wrong credentials (e.g., bad
> password), or your browser doesn't understand how to supply the
> credentials required.
>
> ------------------------------------------------------------------------
> Apache/2.0.54 (Fedora) Server at scipy.org Port 80
>
>
>
> Please fin the issues ASAP.
> http://scipy.org/scipy/scikits/login
> http://scipy.org/scipy/scikits/register
>
> If it's essential, I use Mozilla Firefox, Ubuntu.
> I have removed cookies but the problem remains.
>
> Regards, D.



From travis at enthought.com  Wed Sep 12 12:05:15 2007
From: travis at enthought.com (Travis Vaught)
Date: Wed, 12 Sep 2007 11:05:15 -0500
Subject: [SciPy-dev] ANN: Reminder - Texas Python Regional Unconference
Message-ID: <E2CF8912-7F1D-4AEA-AEF3-7AB6B395D6C2@enthought.com>

Greetings,

Just a reminder for those in the area...

http://pycamp.python.org/Texas/HomePage

The Unconference is to be held this weekend (Saturday and Sunday,  
September 15, 16) at the Texas Learning & Computing Center at the  
University of Houston main campus.

It's free.  Sign up by adding your name to the wiki page.

Travis




From robert.kern at gmail.com  Wed Sep 12 13:12:37 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 12 Sep 2007 12:12:37 -0500
Subject: [SciPy-dev] don't you mind to add openopt and genericopt to
 webpage "Topical software"?
In-Reply-To: <46E7E43A.4070201@ukr.net>
References: <46E7E43A.4070201@ukr.net>
Message-ID: <46E81E05.3060301@gmail.com>

dmitrey wrote:
> hi all,
> don't you mind to add scikits.openopt and genericopt to Topical software?
> If you don't, I shall add just no more than ~3-4 lines to the page about 
> scikits.openopt, and I guess the same Matthieu will do.
> If you think that one or both of the modules are not ready to join the 
> webpage enough for now, please answer the message to prevent changing 
> the page.

Please do add them. Thanks!

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From openopt at ukr.net  Thu Sep 13 05:26:04 2007
From: openopt at ukr.net (dmitrey)
Date: Thu, 13 Sep 2007 12:26:04 +0300
Subject: [SciPy-dev] scikits-related changes to scipy.org website
Message-ID: <46E9022C.8080603@ukr.net>

Hi all,

1st, for scikits developers:
I add mention about openopt module to http://scipy.org/Topical_Software, 
also, a chapter "SciKits" to http://scipy.org/Cookbook (and a single 
line about my module there).
Wouldn't you add your own ones, if you think they are ready enough for now?
Or maybe someone from scipy dev team think it's not a good idea? Then 
please inform me, I'll remove all inappropriate changes.

2nd: http://scipy.org/SciPy_packages page -> "Optimization" link points 
to nowhere.
don't you mind me to create the page and add some lines here about 
scipy.optimize (at major) and scikits.openopt (2-3 lines)?

Regards, D.




From aisaac at american.edu  Thu Sep 13 08:44:35 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 13 Sep 2007 08:44:35 -0400
Subject: [SciPy-dev] scikits-related changes to scipy.org website
In-Reply-To: <46E9022C.8080603@ukr.net>
References: <46E9022C.8080603@ukr.net>
Message-ID: <Mahogany-0.67.0-272-20070913-084435.00@american.edu>

On Thu, 13 Sep 2007, dmitrey apparently wrote:
> 2nd: http://scipy.org/SciPy_packages page -> "Optimization" link points 
> to nowhere. 
> don't you mind me to create the page and add some lines here about 
> scipy.optimize (at major) and scikits.openopt (2-3 lines)? 

I suggest three sections:
1. Optimization resources in SciPy
2. Optimization resources in SciKits
3. Other SciPy related optimization resources

Certainly your offer to add documentation will
improve the current situation.

Cheers,
Alan Isaac





From openopt at ukr.net  Fri Sep 14 06:21:26 2007
From: openopt at ukr.net (dmitrey)
Date: Fri, 14 Sep 2007 13:21:26 +0300
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate" button
Message-ID: <46EA60A6.9050002@ukr.net>

hi all,
don't you think scipy mainpage lacks visits counter and "donate" button?
I tried to implement former in preview mode for some hours, but I have 
obtained some difficulties (with javascript as well as with html code 
samples from those free sites like webstat.net, easy-poll.com, 
sitemeter.com, btw latter works ok in my TRAC page, but only html, not 
javascript; note that javascript version allows to see where people are 
come from (I mean from which URLs, their countries may be shown via 
ordinary html version)).
As for the latter, it could be assigned from donate.net page, however, 
their prices probably may not be considered as cheap, see below (this is 
from letter, there are lots of words about non-profit organization etc 
in their site but anywhere you'll see prices in their website, despite 
the org by itself is commercial).
On the other hand, I guess scipy website developers could implement 
something like that by themselves.

Regards, D.


here are two programs offered to implement the Donation Selector. 

1. One program is designed for organizations just starting out with e-philanthropy, and is more cost effective for processing fewer transactions

$200.00 launch fee, then
$2.50 technology fee per donation plus
3.3% credit card banking fee. 
There is a $15.00 chargeback fee should a donor revoke the charge through the credit card company, we will only charge this if they become onerous or exceed 10% of the transactions you make with our system. This program carries no minimum monthly charge, and carries no annual fees.  A Direct Funding account, with daily transfer of funds, will require a one time set-up fee of $400.00.

2. Our next program is designed for those organizations with an established e-philanthropy program, who expect a steady flow of transactions throughout the year.

$200.00 launch fee, then
$29.95 minimum monthly fee to cover the first 20 transactions, hosting and technical support. 
$1.50 technology fee per donation after the first twenty transactions plus 
3.3% credit card banking fee. 
A $15.00 chargeback fee can also apply, but this program carries no other additional fees.  But again, to set up a Direct Funding account for you, with fees.  For a Direct Funding account, with daily transfer of funds, as opposed to the standard monthly transfer funds program - we charge a one time set-up fee of $400.00.

The selector-template can typically be created on the same business day you sign the contract.  We then arrange a support session to train the primary users on the system. Templates can be customized to the look and feel of your site. In general there are 3 levels utilized to customize the look and feel. We will need to bid separately for any specific project, but the following can be used as a guide to our pricing to customize the pages.

$400.00 in programming will provide for custom background colors and one static banner either on the top or side of the window.

$800.00 in programming will provide for custom colors and live banners on top or along side of the window.

$1200.00 will provide enough programming for custom colors, 2 live banners, or implementation of Custom Style Sheets.

Email campaigns are set up for a one-time fee of $400.00.Each blast is $50.00 to insert new text, and to blast up to 10,000 email addresses. Additional email address are billed at $1.00/ thousand emails.

Network Fundraising Campaigns can be launched for between $2500.00 to have email blasts and a donation selector.

Please let me know if you have any questions. I'd be happy to set up a  phone meeting to go over your specific needs and plans for your  program.  Thanks so much. 

Sincerely,

Eric Miller 
www.donate.net
866-874-0444 x201 
404-874-7421 x201 




From robert.kern at gmail.com  Fri Sep 14 11:57:43 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 14 Sep 2007 10:57:43 -0500
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate"
 button
In-Reply-To: <46EA60A6.9050002@ukr.net>
References: <46EA60A6.9050002@ukr.net>
Message-ID: <46EAAF77.3060208@gmail.com>

dmitrey wrote:
> hi all,
> don't you think scipy mainpage lacks visits counter and "donate" button?

Not really. We (Enthought) host the server, so we have all of the logs we need
to track visits. As for a donation button, where would the money go?

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From openopt at ukr.net  Fri Sep 14 13:18:21 2007
From: openopt at ukr.net (dmitrey)
Date: Fri, 14 Sep 2007 20:18:21 +0300
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate"
 button
In-Reply-To: <46EAAF77.3060208@gmail.com>
References: <46EA60A6.9050002@ukr.net> <46EAAF77.3060208@gmail.com>
Message-ID: <46EAC25D.3050108@ukr.net>

Robert Kern wrote:
> dmitrey wrote:
>   
>> hi all,
>> don't you think scipy mainpage lacks visits counter and "donate" button?
>>     
>
> Not really. We (Enthought) host the server, so we have all of the logs we need
> to track visits.
It would be interesting for all users, not only Enthought workers
>  As for a donation button, where would the money go?
>   
It's 100% your decision.

Regards, D.




From robert.kern at gmail.com  Fri Sep 14 13:29:23 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 14 Sep 2007 12:29:23 -0500
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate"
 button
In-Reply-To: <46EAC25D.3050108@ukr.net>
References: <46EA60A6.9050002@ukr.net> <46EAAF77.3060208@gmail.com>
	<46EAC25D.3050108@ukr.net>
Message-ID: <46EAC4F3.6070207@gmail.com>

dmitrey wrote:
> Robert Kern wrote:
>> dmitrey wrote:
>>   
>>> hi all,
>>> don't you think scipy mainpage lacks visits counter and "donate" button?
>>>     
>> Not really. We (Enthought) host the server, so we have all of the logs we need
>> to track visits.
> It would be interesting for all users, not only Enthought workers

Yes, of course. The point is that we don't have to stick a counter anywhere to
get this information; just ask us, and we'll try to get the numbers.

>>  As for a donation button, where would the money go?
>>   
> It's 100% your decision.

No, it isn't. While I talk a lot, I am not the scipy project, nor is Enthought.
Donation buttons work well for projects driven by a single developer, one small
company, or a larger foundation. When there is a group of developers who don't
have organizational ties outside of the project, it's really unclear what
purpose the money serves. Usually, the donations are too little to do much
except partially pay for web hosting, and Enthought is already taking care of
that. They're not going to be enough to support development.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From openopt at ukr.net  Fri Sep 14 15:05:24 2007
From: openopt at ukr.net (dmitrey)
Date: Fri, 14 Sep 2007 22:05:24 +0300
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate"
 button
In-Reply-To: <46EAC4F3.6070207@gmail.com>
References: <46EA60A6.9050002@ukr.net>
	<46EAAF77.3060208@gmail.com>	<46EAC25D.3050108@ukr.net>
	<46EAC4F3.6070207@gmail.com>
Message-ID: <46EADB74.8090106@ukr.net>

Robert Kern wrote:
> dmitrey wrote:
>   
>> Robert Kern wrote:
>>     
>>> dmitrey wrote:
>>>   
>>>       
>>>> hi all,
>>>> don't you think scipy mainpage lacks visits counter and "donate" button?
>>>>     
>>>>         
>>> Not really. We (Enthought) host the server, so we have all of the logs we need
>>> to track visits.
>>>       
>> It would be interesting for all users, not only Enthought workers
>>     
>
> Yes, of course. The point is that we don't have to stick a counter anywhere to
> get this information; just ask us, and we'll try to get the numbers.
>   
I'm searching ukrainian foundations to obtain some money support for 
openopt development, and they want to know how much spreadered is that 
free software product that applier proposes to develop (I intend to 
contact them as one of scipy/scikits developers to enhance scikits 
optimization module). It's impossible to obtain number of downloads, 
because lots of users use getting from svn, and they will not waste 
their time to find and contact to someone w.r.t. the numbers, moreover, 
they couldn't trust the answer. But the number of page visiting per day 
may say something to them.
>>>  As for a donation button, where would the money go?
>>>   
>>>       
>> It's 100% your decision.
>>     
> No, it isn't. While I talk a lot, I am not the scipy project, nor is Enthought.
> Donation buttons work well for projects driven by a single developer, one small
> company, or a larger foundation. When there is a group of developers who don't
> have organizational ties outside of the project, it's really unclear what
> purpose the money serves. Usually, the donations are too little to do much
> except partially pay for web hosting, and Enthought is already taking care of
> that. They're not going to be enough to support development.
>   
Ok, then it's scipy owner(s) decision - implement the button or not and 
howto spend money. But I think that scipy is much more spreadered than a 
common scientific project, and maybe money would be helpful to enhance 
the one and keep it up-to-date vs MATLAB and/or other concurrents. In 
anyway, the button could be removed in any time.
Regards, D.



From millman at berkeley.edu  Fri Sep 14 15:29:59 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Fri, 14 Sep 2007 12:29:59 -0700
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate"
	button
In-Reply-To: <46EADB74.8090106@ukr.net>
References: <46EA60A6.9050002@ukr.net> <46EAAF77.3060208@gmail.com>
	<46EAC25D.3050108@ukr.net> <46EAC4F3.6070207@gmail.com>
	<46EADB74.8090106@ukr.net>
Message-ID: <c7009a550709141229m5d0c85c2o2665c9946f11c77c@mail.gmail.com>

Hey Dmitrey,

Thanks for the suggestions about the website.  For now, I will try to
get you some page view statistics for your grant application.  We are
in the process of cleaning up the scipy server to make it more
responsive and easier to administer.  Until we get that finished, I
would prefer to temporarily halt the addition of new features to the
site.

As soon as we make some progress on cleaning things up, we will be
able to start investigating the best way to gather and make public web
metrics as well as other nice features.  For federally-funded US
grants, having more extensive web metrics is very useful as well.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From openopt at ukr.net  Fri Sep 14 16:10:09 2007
From: openopt at ukr.net (dmitrey)
Date: Fri, 14 Sep 2007 23:10:09 +0300
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate"
 button
In-Reply-To: <c7009a550709141229m5d0c85c2o2665c9946f11c77c@mail.gmail.com>
References: <46EA60A6.9050002@ukr.net>
	<46EAAF77.3060208@gmail.com>	<46EAC25D.3050108@ukr.net>
	<46EAC4F3.6070207@gmail.com>	<46EADB74.8090106@ukr.net>
	<c7009a550709141229m5d0c85c2o2665c9946f11c77c@mail.gmail.com>
Message-ID: <46EAEAA1.5070302@ukr.net>

Jarrod Millman wrote:
> Hey Dmitrey,
>
> Thanks for the suggestions about the website.  For now, I will try to
> get you some page view statistics for your grant application.  
Thank you, but let me remember you once again - one of Ukrainian 
mentality features is "noone should be trusted too much", and 
unfortunately, they can't care less about the statistics you mentioned 
if I will send them the one in letter. So everyone can say "my research 
is very, very important, I see my site visits is 1000 per day" and no 
other proves. Would it be web-counter, they would take it a little bit 
more seriously, despite it may be wrong as well - AFAIK there is 
software for automatic counters increasing, also, as I read in related 
websites that provide counters, they even propose to start from any 
number, and visits from the webpage author(s) by themselves can be taken 
into count.
> We are
> in the process of cleaning up the scipy server to make it more
> responsive and easier to administer.  Until we get that finished, I
> would prefer to temporarily halt the addition of new features to the
> site.
>
> As soon as we make some progress on cleaning things up, we will be
> able to start investigating the best way to gather and make public web
> metrics as well as other nice features.  
Maybe, it would be nice to fix current webpages instead of modifying 
them and provide in new scipy site link to "old scipy site", as well as 
migrate those pages that are ok - up-to-date, have no deadlinks, etc?

> For federally-funded US
> grants, having more extensive web metrics is very useful as well.
>   
If you know anyone US grant org that accepts applications from 
ukrainians w/o going to US - then please inform me, it would increase my 
chances. I suspect that these ones here are too low - I get only one 
suitable org (that accepts general scientific issues) via web search; 
and it's very unlikely I'll pass the one successfully, because there too 
many scientific projects here and too small finance support for them is 
provided - almost all are humanitarian-related.

Regards, D.



From aisaac at american.edu  Fri Sep 14 16:26:29 2007
From: aisaac at american.edu (Alan Isaac)
Date: Fri, 14 Sep 2007 16:26:29 -0400
Subject: [SciPy-dev] Forwarded message: RE: Algorithm License requested
Message-ID: <Mahogany-0.67.0-2472-20070914-162629.00@CASC64043305.american.edu>

I no longer remember the person who expressed interest in 
this, but here we go.
http://www.netlib.org/toms/733

Cheers,
Alan Isaac



------ Forwarded message ------
From: Deborah Cotton <cotton at hq.acm.org>
Date: Fri, 14 Sep 2007 12:35:55 -0500
Subject: RE: Algorithm License requested
To: aisaac at american.edu

Prof. Issac,

In that case, then because the author consents to [the ACM] releasing
the code currently archived at http://www.netlib.org/toms/733 under the
BSD license, the ACM hereby releases this code under the BSD license.

Regards,

Deborah Cotton, Copyright & Permissions
ACM Publications
2 Penn Plaza, Suite 701**
New York, NY 10121-0701
permissions at acm.org
212.869.7440 ext. 652
Fax. 212.869.0481

** As of Aug. 25, 2006

-----Original Message-----
From: aisaac at american.edu [mailto:aisaac at american.edu]
Sent: Thursday, September 13, 2007 11:31 AM
To: Deborah Cotton
Subject: Re: Algorithm License requested

On Tue, 11 Sep 2007, Deborah Cotton apparently wrote:
> I am advised that you have already been in contact with 
> the author, and that he has consented to your use.  In 
> that case, ACM has no objection, provided the original 
> source citation is included and the article DOI from the 
> ACM Digital Library is evident along with the netlib link. 
> The DOI is http://doi.acm.org/10.1145/192115.192124. 

Dear Ms. Cotton,

Thank you very much for your reply.
Unfortunately, in this day and age,
it is a bit too indirect to constitute
a full answer to my question.

I need you to say explicitly the following:

        If the author consents to the ACM
        releasing the code currently archived at
        http://www.netlib.org/toms/733
        under the BSD license,
        the ACM hereby releases this code under
        the BSD license.

Since the author already does agree to this,
that will be all I need.  This is not reassignment
of copyright: ACM continues to hold the copyright.

The BSD license is a standard open source license.
http://www.opensource.org/licenses/bsd-license.php
As you can see from this link, the license includes
a specification of the copyright owner: that will
still be the ACM.

I am trying to get this code into SciPy, an open source
project used by myself and my students.
http://www.scipy.org/
The BSD license is used for all code in SciPy.

I assume you know this, but just to be clear:
as copyright holder, the ACM will of course
retain the right to issue this code under other
licenses in the future, should it wish to.

Thank you,
Alan Isaac
Associate Professor of Economics
American University
-------- End of message -------




From millman at berkeley.edu  Fri Sep 14 16:49:36 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Fri, 14 Sep 2007 13:49:36 -0700
Subject: [SciPy-dev] I am about to tag SciPy 0.6.0
Message-ID: <c7009a550709141349v7c64f20ft28d04849f5d86a57@mail.gmail.com>

Hey everyone,

Sorry again for not taking care of this sooner.  But I am finally
ready to create a 0.6.0 tag from the 0.6.x branch.

I noticed one final issue with odr on 64bit machines; but it looks
like this has been a problem for sometime:
http://projects.scipy.org/scipy/scipy/ticket/357

Unless someone tells me that they can fix this in the next few hours,
I will go ahead and create the tag.  If need be we can release a 0.6.1
bugfix release later.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From robert.kern at gmail.com  Fri Sep 14 17:55:44 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 14 Sep 2007 16:55:44 -0500
Subject: [SciPy-dev] I am about to tag SciPy 0.6.0
In-Reply-To: <c7009a550709141349v7c64f20ft28d04849f5d86a57@mail.gmail.com>
References: <c7009a550709141349v7c64f20ft28d04849f5d86a57@mail.gmail.com>
Message-ID: <46EB0360.4090006@gmail.com>

Jarrod Millman wrote:
> Hey everyone,
> 
> Sorry again for not taking care of this sooner.  But I am finally
> ready to create a 0.6.0 tag from the 0.6.x branch.
> 
> I noticed one final issue with odr on 64bit machines; but it looks
> like this has been a problem for sometime:
> http://projects.scipy.org/scipy/scipy/ticket/357
> 
> Unless someone tells me that they can fix this in the next few hours,
> I will go ahead and create the tag.  If need be we can release a 0.6.1
> bugfix release later.

I don't see the "IndexError" failures. The others will take some time to track
down. I don't know why the functions would converge to slightly (but
significantly) different values.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From robfalck at gmail.com  Fri Sep 14 19:02:13 2007
From: robfalck at gmail.com (Rob Falck)
Date: Fri, 14 Sep 2007 19:02:13 -0400
Subject: [SciPy-dev] Forwarded message: RE: Algorithm License requested
In-Reply-To: <Mahogany-0.67.0-2472-20070914-162629.00@CASC64043305.american.edu>
References: <Mahogany-0.67.0-2472-20070914-162629.00@CASC64043305.american.edu>
Message-ID: <ccb1b5850709141602v1b4df176vf294778e3e2b3ecb@mail.gmail.com>

Well that's good news.  I have a decent wrapper for SLSQP implemented,
although I still need to implement constraint gradient passing.  I'm pretty
new to Scipy development.  Would this be better left in scipy.optimize or
openopt?

On 9/14/07, Alan Isaac <aisaac at american.edu> wrote:
>
> I no longer remember the person who expressed interest in
> this, but here we go.
> http://www.netlib.org/toms/733
>
> Cheers,
> Alan Isaac
>
>
>
> ------ Forwarded message ------
> From: Deborah Cotton <cotton at hq.acm.org>
> Date: Fri, 14 Sep 2007 12:35:55 -0500
> Subject: RE: Algorithm License requested
> To: aisaac at american.edu
>
> Prof. Issac,
>
> In that case, then because the author consents to [the ACM] releasing
> the code currently archived at http://www.netlib.org/toms/733 under the
> BSD license, the ACM hereby releases this code under the BSD license.
>
> Regards,
>
> Deborah Cotton, Copyright & Permissions
> ACM Publications
> 2 Penn Plaza, Suite 701**
> New York, NY 10121-0701
> permissions at acm.org
> 212.869.7440 ext. 652
> Fax. 212.869.0481
>
> ** As of Aug. 25, 2006
>
> -----Original Message-----
> From: aisaac at american.edu [mailto:aisaac at american.edu]
> Sent: Thursday, September 13, 2007 11:31 AM
> To: Deborah Cotton
> Subject: Re: Algorithm License requested
>
> On Tue, 11 Sep 2007, Deborah Cotton apparently wrote:
> > I am advised that you have already been in contact with
> > the author, and that he has consented to your use.  In
> > that case, ACM has no objection, provided the original
> > source citation is included and the article DOI from the
> > ACM Digital Library is evident along with the netlib link.
> > The DOI is http://doi.acm.org/10.1145/192115.192124.
>
> Dear Ms. Cotton,
>
> Thank you very much for your reply.
> Unfortunately, in this day and age,
> it is a bit too indirect to constitute
> a full answer to my question.
>
> I need you to say explicitly the following:
>
>         If the author consents to the ACM
>         releasing the code currently archived at
>         http://www.netlib.org/toms/733
>         under the BSD license,
>         the ACM hereby releases this code under
>         the BSD license.
>
> Since the author already does agree to this,
> that will be all I need.  This is not reassignment
> of copyright: ACM continues to hold the copyright.
>
> The BSD license is a standard open source license.
> http://www.opensource.org/licenses/bsd-license.php
> As you can see from this link, the license includes
> a specification of the copyright owner: that will
> still be the ACM.
>
> I am trying to get this code into SciPy, an open source
> project used by myself and my students.
> http://www.scipy.org/
> The BSD license is used for all code in SciPy.
>
> I assume you know this, but just to be clear:
> as copyright holder, the ACM will of course
> retain the right to issue this code under other
> licenses in the future, should it wish to.
>
> Thank you,
> Alan Isaac
> Associate Professor of Economics
> American University
> -------- End of message -------
>
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
- Rob Falck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070914/0fee749e/attachment.html>

From aisaac at american.edu  Fri Sep 14 19:10:32 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Fri, 14 Sep 2007 19:10:32 -0400
Subject: [SciPy-dev] Forwarded message: RE: Algorithm License requested
In-Reply-To: <ccb1b5850709141602v1b4df176vf294778e3e2b3ecb@mail.gmail.com>
References: <Mahogany-0.67.0-2472-20070914-162629.00@CASC64043305.american.edu><ccb1b5850709141602v1b4df176vf294778e3e2b3ecb@mail.gmail.com>
Message-ID: <Mahogany-0.67.0-1264-20070914-191032.00@american.edu>

On Fri, 14 Sep 2007, Rob Falck apparently wrote:
> Well that's good news.  I have a decent wrapper for SLSQP 
> implemented, although I still need to implement constraint 
> gradient passing.  I'm pretty new to Scipy development.  
> Would this be better left in scipy.optimize or openopt? 

Unless some other opinion is expressed, can you please 
discuss with Dmitrey how best to move this into OpenOpt?

Cheers,
Alan Isaac





From millman at berkeley.edu  Fri Sep 14 20:11:02 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Fri, 14 Sep 2007 17:11:02 -0700
Subject: [SciPy-dev] new tagged release (SciPy 0.6.0)
Message-ID: <c7009a550709141711x184c13f4s850e9cb0ac261430@mail.gmail.com>

Hey everyone,

I have tagged the SciPy 0.6.0 release.  You can get it here:
http://svn.scipy.org/svn/scipy/tags/0.6.0

I will be getting packages from the packagers over the next few days.
Once I have the binary packages, I will make an official announcement
(including updating the websites and sending out emails).

The announcement that I have now is:
-------------------------------------
I'm pleased to announce the release of SciPy 0.6.0.  SciPy is package of tools
for science and engineering for Python. It includes modules for statistics,
optimization, integration, linear algebra, Fourier transforms, signal and image
processing, ODE solvers, and more.

This release brings many bugfixes and speed improvements.  It is recommend
that all user's upgrade.

Major changes since 0.5.2.1:

 * cluster
     - cleaned up kmeans code and added a kmeans2 function
        that adds several initialization methods
 * fftpack
     - fft speedups for complex data
     - major overhaul of fft source code for easier maintenance
 * interpolate
     - add Lagrange interpolating polynomial
     - fix interp1d so that it works for higher order splines
 * io
     - read and write basic .wav files
 * linalg
     - add Cholesky decomposition and solution of banded
        linear systems with Hermitian or symmetric matrices
     - add RQ decomposition
 * ndimage
     - port to NumPy API
     - fix byteswapping problem in rotate
     - better support for 64-bit platforms
 * optimize
     - a lot of bugfixes and modernization
 * signal
     - add complex Morlet wavelet
 * sparse
     - significant performance improvements

Thank you to everybody who contributed to the recent release.

Enjoy,

-------------------------------------

Please let me know if you think I am missing anything important.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From ondrej at certik.cz  Fri Sep 14 21:21:54 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Sat, 15 Sep 2007 03:21:54 +0200
Subject: [SciPy-dev] new tagged release (SciPy 0.6.0)
In-Reply-To: <c7009a550709141711x184c13f4s850e9cb0ac261430@mail.gmail.com>
References: <c7009a550709141711x184c13f4s850e9cb0ac261430@mail.gmail.com>
Message-ID: <85b5c3130709141821r7cb7b416lf37de9e59d01887@mail.gmail.com>

> I have tagged the SciPy 0.6.0 release.  You can get it here:
> http://svn.scipy.org/svn/scipy/tags/0.6.0
>
> I will be getting packages from the packagers over the next few days.
> Once I have the binary packages, I will make an official announcement
> (including updating the websites and sending out emails).

Awesome. For the Debian package, I need you to release the official
tar.gz. Once you do it, I'll let the new version to be uploaded to
Debian.

>      - better support for 64-bit platforms
>  * optimize
>      - a lot of bugfixes and modernization

- nonlinear solvers module added

http://svn.scipy.org/svn/scipy/tags/0.6.0/scipy/optimize/nonlin.py


Ondrej


From jh at physics.ucf.edu  Fri Sep 14 22:36:55 2007
From: jh at physics.ucf.edu (Joe Harrington)
Date: Fri, 14 Sep 2007 22:36:55 -0400
Subject: [SciPy-dev] scipy mainpage lacks visits counter and "donate"
	button
Message-ID: <1189823815.22774.530.camel@glup.physics.ucf.edu>

Two thoughts:

First, while it's not a good gauge of the size of a project, once can
pretty much track growth rate by two means: downloads vs. time, and
email messages on the combined mailing lists vs. time.  The assumption
is that each is subject to an inflation/deflation factor that is roughly
constant.  The real growth rate might be higher because as a project
gets popular a larger fraction of users isn't linked into the host
community, but that just lends credence that the reported rates are at
least as high as quoted.  For example, after numpy 1.0 came out, there
was a big jump in the number of messages, which has sustained itself
since that time.

Second, I've been thinking of donations for a while, actually.  I can
think of a number of ways to spend small chunks of money to support
documentation and packaging, our two areas of greatest need, and others:

- support sending outreach ambassadors to conferences
- pay technical writing majors as summer students to write some good docs
- pay a student for a summer to build native installers for a few popular
    platforms and get them included in the mainstream of those distros
- support the conference
- seed an endowment

So, I'd propose:

Put up a microgrants page and a donate button; rig it to some mechanism
(Paypal+bank account?) that collects and stores money.  Put up a plot of
the pot vs. time so people can watch it grow and see the effect of their
donation ("that jump is mine").  The drops would be linked to the
results of each microgrant.

Put up some initial proposal ideas like those above, and solicit more.

Declare that when the pot reaches $11k, we'll make 2 microgrants of $5k
each, put $1k toward endowment, and set a goal of raising that sum by
April 30 for summer projects.

When the pot reaches $10k, start winnowing the proposals down by
community vote to 5.  Pick 3 community leaders who will choose 2 from
among those 5 after a phone interview with each proposer, listening to
community input, and a telecon with each other.  (I'm open to other
mechanisms, but remember that they must deal with Uncle Sam, provide
some accountability and fairness, and prevent hijacking of the pot by
outsiders).

The recipients would do a 1-page web-page report to the community when
they were done.  Those and the successful proposals would be permanent
exhibits on the microgrants page.  That would show donors what gets done
with their money, and might result in more donations.  It would also
help to build our community.  Maybe some of the tasks would get taken up
by volunteers.  Others might attract direct funding from someone with
leftover money in a research grant that uses SciPy.

Rinse, repeat.  Grow the endowment by taking $1k for every 2 microgrants
from the donated money, plus directed gifts.  Once it's large enough to
support 2 microgrants a year, it will contribute its interest above
inflation to the microgrants pot, and grow only by directed gifts.

If we're lucky and get some real money, we can consider supporting
programmers as well.  The reason not to do that right away is that we
need some way to juice our doc and package efforts.  On the other hand,
I don't object to putting up a directed-programming donation pot,
either.  While Enthough graciously uses some of its profit to pay its
people to work on development, others, like Travis O., are on their own,
at least much of the time.

We do need to do a couple of things to make this fly.  Initially, we'd
need a bank account, a few trustees, a basic charter, and some web work.
These are not difficult to do.  In the longer run, we'd want 501c3
status (which also makes it more likely that someone will remember us in
their will, and no I am not kidding, I've seen little community orgs get
big bucks this way).  The easiest way to do this is to associate with a
larger organization that takes smaller groups like ours under their
umbrella and feeds directed donations back to us.  This approach might
require changing our program somewhat to fit their model.  Finally, we
could also set up to sell "gear" to benefit the program.

I will pledge $300 if the idea flies.  

--jh--




From nwagner at iam.uni-stuttgart.de  Sat Sep 15 03:19:46 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 15 Sep 2007 09:19:46 +0200
Subject: [SciPy-dev] I am about to tag SciPy 0.6.0
In-Reply-To: <46EB0360.4090006@gmail.com>
References: <c7009a550709141349v7c64f20ft28d04849f5d86a57@mail.gmail.com>
	<46EB0360.4090006@gmail.com>
Message-ID: <web-89340648@uni-stuttgart.de>

On Fri, 14 Sep 2007 16:55:44 -0500
  Robert Kern <robert.kern at gmail.com> wrote:
> Jarrod Millman wrote:
>> Hey everyone,
>> 
>> Sorry again for not taking care of this sooner.  But I 
>>am finally
>> ready to create a 0.6.0 tag from the 0.6.x branch.
>> 
>> I noticed one final issue with odr on 64bit machines; 
>>but it looks
>> like this has been a problem for sometime:
>> http://projects.scipy.org/scipy/scipy/ticket/357
>> 
>> Unless someone tells me that they can fix this in the 
>>next few hours,
>> I will go ahead and create the tag.  If need be we can 
>>release a 0.6.1
>> bugfix release later.
> 
> I don't see the "IndexError" failures. The others will 
>take some time to track
> down. I don't know why the functions would converge to 
>slightly (but
> significantly) different values.
> 
> -- 
> Robert Kern
> 
> "I have come to believe that the whole world is an 
>enigma, a harmless enigma
> that is made terrible by our own mad attempt to 
>interpret it as though it had
> an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev

  

IIRC the IndexError problem was fixed by Pearu.

Nils


From jh at physics.ucf.edu  Sat Sep 15 14:44:37 2007
From: jh at physics.ucf.edu (Joe Harrington)
Date: Sat, 15 Sep 2007 14:44:37 -0400
Subject: [SciPy-dev] new tagged release (SciPy 0.6.0)
Message-ID: <1189881877.22774.559.camel@glup.physics.ucf.edu>

2 minor grammar fixes in proposed 0.6.0 announcement:

SciPy is package of -> 
SciPy is a package of

It is recommend that all user's upgrade. ->
It is recommended that all users upgrade.

Or better,

We recommend that all users upgrade.

Actually, that is a very strong recommendation that can have difficult
consequences for some.  The "everyone upgrade" recommendation should
only be given in cases where critical/security bugs are fixed.  I'd say
instead:

Users affected by the issues below should upgrade immediately, and
others should upgrade at their convenience.

--jh--




From david at ar.media.kyoto-u.ac.jp  Sun Sep 16 03:56:22 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sun, 16 Sep 2007 16:56:22 +0900
Subject: [SciPy-dev] new tagged release (SciPy 0.6.0)
In-Reply-To: <c7009a550709141711x184c13f4s850e9cb0ac261430@mail.gmail.com>
References: <c7009a550709141711x184c13f4s850e9cb0ac261430@mail.gmail.com>
Message-ID: <46ECE1A6.7010404@ar.media.kyoto-u.ac.jp>

Jarrod Millman wrote:
> Hey everyone,
>
> I have tagged the SciPy 0.6.0 release.  You can get it here:
> http://svn.scipy.org/svn/scipy/tags/0.6.0
>
> I will be getting packages from the packagers over the next few days.
> Once I have the binary packages, I will make an official announcement
> (including updating the websites and sending out emails).
>   
Ok, I am just a bit confused about what a tag is: is it just a snapshot 
of one revision ? So for the ashigabou repository, should I use the 
sources from there, or does a tag "tracks" change ?

cheers,

David


From millman at berkeley.edu  Sun Sep 16 04:26:33 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Sun, 16 Sep 2007 01:26:33 -0700
Subject: [SciPy-dev] new tagged release (SciPy 0.6.0)
In-Reply-To: <46ECE1A6.7010404@ar.media.kyoto-u.ac.jp>
References: <c7009a550709141711x184c13f4s850e9cb0ac261430@mail.gmail.com>
	<46ECE1A6.7010404@ar.media.kyoto-u.ac.jp>
Message-ID: <c7009a550709160126o86b8973h351464937f15d368@mail.gmail.com>

On 9/16/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Ok, I am just a bit confused about what a tag is: is it just a snapshot
> of one revision ? So for the ashigabou repository, should I use the
> sources from there, or does a tag "tracks" change ?

A tag is basically another name for a release.  The idea is that
development takes place on the trunk.  Once we are getting ready for a
release, I create a release branch.  In this case, I made a 0.6.x
release branch.  Only important bug-fixes should be made to the 0.6.x
release branch.  Once we are ready to make a release, I tag (or label)
the release.  In this case, I tagged the release 0.6.0.  The 0.6.0 tag
is a static snapshot and should not be modified.  So if it turns out
that there are some important bugs that we would like to fix in the
0.6.x release series, we would apply them to the 0.6.x release branch.
 Once we are ready for another stable release in the 0.6.x series, I
would create another tag from the 0.6.x release branch.  Continuing
with the example, I would tag this release 0.6.1.

I have started to document the process here:
http://projects.scipy.org/scipy/scipy/wiki/MakingReleases

Hope this helps,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From millman at berkeley.edu  Sun Sep 16 06:36:56 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Sun, 16 Sep 2007 03:36:56 -0700
Subject: [SciPy-dev] new tagged release (SciPy 0.6.0)
In-Reply-To: <1189881877.22774.559.camel@glup.physics.ucf.edu>
References: <1189881877.22774.559.camel@glup.physics.ucf.edu>
Message-ID: <c7009a550709160336v1b95a5e2reefd72324663ce06@mail.gmail.com>

Thanks to Ondrej and Joe for helping with the release announcement for
0.6.0, which can be found here:
http://scipy.org/scipy/scipy/milestone/0.6

I decided to just take out the statement regarding upgrading to the
new release.  It is probably better to only mention upgrading if there
is a serious security or data corruption issue.

Cheers,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From openopt at ukr.net  Mon Sep 17 15:56:34 2007
From: openopt at ukr.net (dmitrey)
Date: Mon, 17 Sep 2007 22:56:34 +0300
Subject: [SciPy-dev] Forwarded message: RE: Algorithm License requested
In-Reply-To: <Mahogany-0.67.0-1264-20070914-191032.00@american.edu>
References: <Mahogany-0.67.0-2472-20070914-162629.00@CASC64043305.american.edu><ccb1b5850709141602v1b4df176vf294778e3e2b3ecb@mail.gmail.com>
	<Mahogany-0.67.0-1264-20070914-191032.00@american.edu>
Message-ID: <46EEDBF2.9080000@ukr.net>

Alan G Isaac wrote:
> On Fri, 14 Sep 2007, Rob Falck apparently wrote:
>   
>> Well that's good news.  I have a decent wrapper for SLSQP 
>> implemented, although I still need to implement constraint 
>> gradient passing.  I'm pretty new to Scipy development.  
>> Would this be better left in scipy.optimize or openopt? 
>>     
>
> Unless some other opinion is expressed, can you please 
> discuss with Dmitrey how best to move this into OpenOpt?
>
> Cheers,
> Alan Isaac
>   
Noone contacted me yet, but I have some things to explain.
1st, should the func be connected to openopt, then it should have same 
to TOMLAB syntax, that is very complicated:
http://tomopt.com/docs/OC_QUICKGUIDE.pdf
So it will require too much time for me (as well as learning OC 
problems, I'm not familiar with the ones, however, I know here are some 
people in Ukraine researching the ones).
2nd, OC problems are much more complicated then finite-dimensional ones 
(like ordinary NLP, LP, QP etc are), and solving of the ones usually 
requires much more cputime (and func calls), hance objective funcs 
written in Python will require much more time to calculate argmin, and I 
guess that's why Python was not used widely for solving OCPs.
3rd, I have too small time that I can devote to openopt development for 
now, and I'm busy with enhancing my lincher  (I hope to make some issues 
from the one to my dissertation, time left is too short) and some other 
problems.
So I can't implement the thing at least in nearest future.
Maybe someone wants to connect that one to scipy.optimize, since it has 
BSD license?
Regards, D.



From robfalck at gmail.com  Mon Sep 17 17:51:29 2007
From: robfalck at gmail.com (Rob Falck)
Date: Mon, 17 Sep 2007 17:51:29 -0400
Subject: [SciPy-dev] Forwarded message: RE: Algorithm License requested
In-Reply-To: <46EEDBF2.9080000@ukr.net>
References: <Mahogany-0.67.0-2472-20070914-162629.00@CASC64043305.american.edu>
	<ccb1b5850709141602v1b4df176vf294778e3e2b3ecb@mail.gmail.com>
	<Mahogany-0.67.0-1264-20070914-191032.00@american.edu>
	<46EEDBF2.9080000@ukr.net>
Message-ID: <ccb1b5850709171451r24077890k93dd1863e7182a17@mail.gmail.com>

I've been a bit busy and haven't had time to complete my implementation of
the SLSQP python wrapper.  That said, what I currently have was designed to
mesh with other optimizers in scipy.optimize, so it sounds like I'll work to
implement in in scipy.optimize when I have some time to do so.

On 9/17/07, dmitrey <openopt at ukr.net> wrote:
>
> Alan G Isaac wrote:
> > On Fri, 14 Sep 2007, Rob Falck apparently wrote:
> >
> >> Well that's good news.  I have a decent wrapper for SLSQP
> >> implemented, although I still need to implement constraint
> >> gradient passing.  I'm pretty new to Scipy development.
> >> Would this be better left in scipy.optimize or openopt?
> >>
> >
> > Unless some other opinion is expressed, can you please
> > discuss with Dmitrey how best to move this into OpenOpt?
> >
> > Cheers,
> > Alan Isaac
> >
> Noone contacted me yet, but I have some things to explain.
> 1st, should the func be connected to openopt, then it should have same
> to TOMLAB syntax, that is very complicated:
> http://tomopt.com/docs/OC_QUICKGUIDE.pdf
> So it will require too much time for me (as well as learning OC
> problems, I'm not familiar with the ones, however, I know here are some
> people in Ukraine researching the ones).
> 2nd, OC problems are much more complicated then finite-dimensional ones
> (like ordinary NLP, LP, QP etc are), and solving of the ones usually
> requires much more cputime (and func calls), hance objective funcs
> written in Python will require much more time to calculate argmin, and I
> guess that's why Python was not used widely for solving OCPs.
> 3rd, I have too small time that I can devote to openopt development for
> now, and I'm busy with enhancing my lincher  (I hope to make some issues
> from the one to my dissertation, time left is too short) and some other
> problems.
> So I can't implement the thing at least in nearest future.
> Maybe someone wants to connect that one to scipy.optimize, since it has
> BSD license?
> Regards, D.
>
>


-- 
- Rob Falck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070917/5751a901/attachment.html>

From aisaac at american.edu  Wed Sep 19 17:35:03 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Wed, 19 Sep 2007 17:35:03 -0400
Subject: [SciPy-dev] scipy.stats.t.cdf crashes under Win 2000
Message-ID: <Mahogany-0.67.0-1604-20070919-173503.00@american.edu>

Is anyone else seeing Python interpreter crashes
using scipy.stats.t.cdf?

Thank you,
Alan Isaac






From aisaac at american.edu  Wed Sep 19 19:22:58 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Wed, 19 Sep 2007 19:22:58 -0400
Subject: [SciPy-dev] [SciPy-user] scipy.stats.t.cdf crashes under Win
	2000
In-Reply-To: <Mahogany-0.67.0-1604-20070919-173503.00@american.edu>
References: <Mahogany-0.67.0-1604-20070919-173503.00@american.edu>
Message-ID: <Mahogany-0.67.0-1604-20070919-192258.00@american.edu>

On Wed, 19 Sep 2007, Alan G Isaac apparently wrote:
> Is anyone else seeing Python interpreter crashes 
> using scipy.stats.t.cdf? 

OK, I've traced the problem to
scipy.special.stdtr
but I do not know how to go further.
Can anyone help?

Thank you,
Alan Isaac






From ondrej at certik.cz  Wed Sep 19 19:26:14 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 20 Sep 2007 01:26:14 +0200
Subject: [SciPy-dev] [SciPy-user] scipy.stats.t.cdf crashes under Win
	2000
In-Reply-To: <Mahogany-0.67.0-1604-20070919-192258.00@american.edu>
References: <Mahogany-0.67.0-1604-20070919-173503.00@american.edu>
	<Mahogany-0.67.0-1604-20070919-192258.00@american.edu>
Message-ID: <85b5c3130709191626q15249066i6fcba78a97c0df7e@mail.gmail.com>

> OK, I've traced the problem to
> scipy.special.stdtr
> but I do not know how to go further.
> Can anyone help?

Could you please provide more information, like the exact steps to
crash the interpreter, starting with running the command "python"?

Ondrej

P.S. I don't use windows, so I cannot help much, but maybe someone
using windows can help you.


From aisaac at american.edu  Thu Sep 20 11:08:03 2007
From: aisaac at american.edu (Alan G Isaac)
Date: Thu, 20 Sep 2007 11:08:03 -0400
Subject: [SciPy-dev] TableIO
Message-ID: <Mahogany-0.67.0-952-20070920-110803.00@american.edu>

A **long** time ago someone expressed the wish that TableIO 
could be part of SciPy and was told that it was license 
incompatible.  I looked at TableIO
http://php.iupui.edu/~mmiller3/python/
and had the same wish, so I wrote Mike Miller.
Well time passes, and he has written back, saying he would 
be happy to release TableIO under a SciPy compatible 
license.

So: how best to proceed?

What I think would be truly great is if he were to maintain 
TableIO in the SciPy repository, so that SciPy always had 
the latest version?  Is this the right way to thing about 
this?  What is the best response to this opportunity?

Cheers,
Alan Isaac




From ondrej at certik.cz  Thu Sep 20 11:58:13 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Thu, 20 Sep 2007 17:58:13 +0200
Subject: [SciPy-dev] TableIO
In-Reply-To: <Mahogany-0.67.0-952-20070920-110803.00@american.edu>
References: <Mahogany-0.67.0-952-20070920-110803.00@american.edu>
Message-ID: <85b5c3130709200858o2d1ae3b0j88c0c785bc483f00@mail.gmail.com>

> So: how best to proceed?
>
> What I think would be truly great is if he were to maintain
> TableIO in the SciPy repository, so that SciPy always had
> the latest version?  Is this the right way to thing about
> this?  What is the best response to this opportunity?

I think it depends if he is still developing it, or (as I think) not
any more. If the latter, then I think it should become a regular part
of scipy, maintained in the scipy svn, that way it can be easily
assured that everything works with the latest numpy/scipy release.

Ondrej


From millman at berkeley.edu  Thu Sep 20 18:22:21 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Thu, 20 Sep 2007 15:22:21 -0700
Subject: [SciPy-dev] SciPy 0.6.0 release
Message-ID: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>

I'm pleased to announce the release of SciPy 0.6.0. SciPy is a package
of tools for science and engineering for Python. It includes modules
for statistics, optimization, integration, linear algebra, Fourier
transforms, signal and image processing, ODE solvers, and more.

This release brings many bugfixes and speed improvements.

Major changes since 0.5.2.1:

    * cluster
          o cleaned up kmeans code and added a kmeans2 function
             that adds several initialization methods
    * fftpack
          o fft speedups for complex data
          o major overhaul of fft source code for easier maintenance
    * interpolate
          o add Lagrange interpolating polynomial
          o fix interp1d so that it works for higher order splines
    * io
          o read and write basic .wav files
    * linalg
          o add Cholesky decomposition and solution of banded linear
             systems with Hermitian or symmetric matrices
          o add RQ decomposition
    * ndimage
          o port to NumPy API
          o fix byteswapping problem in rotate
          o better support for 64-bit platforms
    * optimize
          o nonlinear solvers module added
          o a lot of bugfixes and modernization
    * signal
          o add complex Morlet wavelet
    * sparse
          o significant performance improvements

Thank you to everybody who contributed to the recent release.

Enjoy,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From david at ar.media.kyoto-u.ac.jp  Fri Sep 21 00:11:02 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 21 Sep 2007 13:11:02 +0900
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
Message-ID: <46F34456.5020406@ar.media.kyoto-u.ac.jp>

Jarrod Millman wrote:
> I'm pleased to announce the release of SciPy 0.6.0. SciPy is a package
> of tools for science and engineering for Python. It includes modules
> for statistics, optimization, integration, linear algebra, Fourier
> transforms, signal and image processing, ODE solvers, and more.
>
> This release brings many bugfixes and speed improvements.
>
> Major changes since 0.5.2.1:
>
>     * cluster
>           o cleaned up kmeans code and added a kmeans2 function
>              that adds several initialization methods
>     * fftpack
>           o fft speedups for complex data
>           o major overhaul of fft source code for easier maintenance
>     * interpolate
>           o add Lagrange interpolating polynomial
>           o fix interp1d so that it works for higher order splines
>     * io
>           o read and write basic .wav files
>     * linalg
>           o add Cholesky decomposition and solution of banded linear
>              systems with Hermitian or symmetric matrices
>           o add RQ decomposition
>     * ndimage
>           o port to NumPy API
>           o fix byteswapping problem in rotate
>           o better support for 64-bit platforms
>     * optimize
>           o nonlinear solvers module added
>           o a lot of bugfixes and modernization
>     * signal
>           o add complex Morlet wavelet
>     * sparse
>           o significant performance improvements
>
> Thank you to everybody who contributed to the recent release.
>
> Enjoy,
>
>   
Except some last minute surprise, scipy 0.6 as well as numpy 1.0.3.1 
rpms should be available for FC 5-6-7 and opensuse 10.2 on the 
repository ashigabou in a few hours,

http://download.opensuse.org/repositories/home:/ashigabou/

cheers,

David



From millman at berkeley.edu  Fri Sep 21 02:35:24 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Thu, 20 Sep 2007 23:35:24 -0700
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <46F34456.5020406@ar.media.kyoto-u.ac.jp>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
	<46F34456.5020406@ar.media.kyoto-u.ac.jp>
Message-ID: <c7009a550709202335h3608fea5r18738562c7f5325a@mail.gmail.com>

On 9/20/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Except some last minute surprise, scipy 0.6 as well as numpy 1.0.3.1
> rpms should be available for FC 5-6-7 and opensuse 10.2 on the
> repository ashigabou in a few hours,

Excellent.  Ondrej also said he would get a Debian package out in the
next few days.  It is really great how fast you are getting new Linux
packages built.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From david at ar.media.kyoto-u.ac.jp  Fri Sep 21 02:36:00 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 21 Sep 2007 15:36:00 +0900
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <c7009a550709202335h3608fea5r18738562c7f5325a@mail.gmail.com>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>	<46F34456.5020406@ar.media.kyoto-u.ac.jp>
	<c7009a550709202335h3608fea5r18738562c7f5325a@mail.gmail.com>
Message-ID: <46F36650.40002@ar.media.kyoto-u.ac.jp>

Jarrod Millman wrote:
> On 9/20/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
>   
>> Except some last minute surprise, scipy 0.6 as well as numpy 1.0.3.1
>> rpms should be available for FC 5-6-7 and opensuse 10.2 on the
>> repository ashigabou in a few hours,
>>     
>
> Excellent.  Ondrej also said he would get a Debian package out in the
> next few days.  It is really great how fast you are getting new Linux
> packages built.
>   
Well, it is just a matter of changing a version string, so the congrats 
should go to the team which built the open suse system and made it 
available for free :)

David


From openopt at ukr.net  Fri Sep 21 03:22:02 2007
From: openopt at ukr.net (dmitrey)
Date: Fri, 21 Sep 2007 10:22:02 +0300
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
Message-ID: <46F3711A.1000102@ukr.net>

Is any time schedule for scikits release(s) already known?
Regards, D.

Jarrod Millman wrote:
> I'm pleased to announce the release of SciPy 0.6.0. SciPy is a package
> of tools for science and engineering for Python. It includes modules
> for statistics, optimization, integration, linear algebra, Fourier
> transforms, signal and image processing, ODE solvers, and more.
>
> This release brings many bugfixes and speed improvements.
>
> Major changes since 0.5.2.1:
>
>     * cluster
>           o cleaned up kmeans code and added a kmeans2 function
>              that adds several initialization methods
>     * fftpack
>           o fft speedups for complex data
>           o major overhaul of fft source code for easier maintenance
>     * interpolate
>           o add Lagrange interpolating polynomial
>           o fix interp1d so that it works for higher order splines
>     * io
>           o read and write basic .wav files
>     * linalg
>           o add Cholesky decomposition and solution of banded linear
>              systems with Hermitian or symmetric matrices
>           o add RQ decomposition
>     * ndimage
>           o port to NumPy API
>           o fix byteswapping problem in rotate
>           o better support for 64-bit platforms
>     * optimize
>           o nonlinear solvers module added
>           o a lot of bugfixes and modernization
>     * signal
>           o add complex Morlet wavelet
>     * sparse
>           o significant performance improvements
>
> Thank you to everybody who contributed to the recent release.
>
> Enjoy,
>
>   



From robert.kern at gmail.com  Fri Sep 21 03:27:56 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Fri, 21 Sep 2007 02:27:56 -0500
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <46F3711A.1000102@ukr.net>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
	<46F3711A.1000102@ukr.net>
Message-ID: <46F3727C.1070204@gmail.com>

dmitrey wrote:
> Is any time schedule for scikits release(s) already known?

There will be no release of a single, unified scikits package. Each scikits
package is a separate project. You may release your package any time you think
it is ready. I don't know about the other projects.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From david at ar.media.kyoto-u.ac.jp  Fri Sep 21 03:39:08 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 21 Sep 2007 16:39:08 +0900
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <46F3727C.1070204@gmail.com>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>	<46F3711A.1000102@ukr.net>
	<46F3727C.1070204@gmail.com>
Message-ID: <46F3751C.2030202@ar.media.kyoto-u.ac.jp>

Robert Kern wrote:
> dmitrey wrote:
>   
>> Is any time schedule for scikits release(s) already known?
>>     
>
> There will be no release of a single, unified scikits package. Each scikits
> package is a separate project. You may release your package any time you think
> it is ready. I don't know about the other projects.
>
>   
One thing which would be useful is for each admin of one scikits to be 
able to release a tarball ? Is there any kind of tools to do it in a 
semi automatic way ?

cheers,

David


From ryan2057 at gmx.de  Fri Sep 21 03:38:43 2007
From: ryan2057 at gmx.de (J. K.)
Date: Fri, 21 Sep 2007 09:38:43 +0200
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <c7009a550709202335h3608fea5r18738562c7f5325a@mail.gmail.com>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>	<46F34456.5020406@ar.media.kyoto-u.ac.jp>
	<c7009a550709202335h3608fea5r18738562c7f5325a@mail.gmail.com>
Message-ID: <fcvsg2$6ei$1@sea.gmane.org>

Jarrod Millman schrieb:
> On 9/20/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
>> Except some last minute surprise, scipy 0.6 as well as numpy 1.0.3.1
>> rpms should be available for FC 5-6-7 and opensuse 10.2 on the
>> repository ashigabou in a few hours,
> 
> Excellent.  Ondrej also said he would get a Debian package out in the
> next few days.  It is really great how fast you are getting new Linux
> packages built.
> 
> Thanks,
> 

The update speed for SciPy for Linux was actually one of the reasons I
now run a Linux system at work.
Jack Kinch



From millman at berkeley.edu  Fri Sep 21 04:08:09 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Fri, 21 Sep 2007 01:08:09 -0700
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <46F3751C.2030202@ar.media.kyoto-u.ac.jp>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
	<46F3711A.1000102@ukr.net> <46F3727C.1070204@gmail.com>
	<46F3751C.2030202@ar.media.kyoto-u.ac.jp>
Message-ID: <c7009a550709210108m3eaebccfva360084e500d1fa9@mail.gmail.com>

On 9/21/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> One thing which would be useful is for each admin of one scikits to be
> able to release a tarball ? Is there any kind of tools to do it in a
> semi automatic way ?

It is fairly easy to make tarballs:
  svn co http://svn.scipy.org/svn/scikits/trunk/learn learn
  cd learn
  python setup.py sdist
You could then write a little script that would do this and upload
(via scp, perhaps) the file to a server somewhere.

You probably know this, so where you asking something else?

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From matthieu.brucher at gmail.com  Fri Sep 21 09:33:29 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Fri, 21 Sep 2007 15:33:29 +0200
Subject: [SciPy-dev] SciPy 0.6.0 release
In-Reply-To: <46F3751C.2030202@ar.media.kyoto-u.ac.jp>
References: <c7009a550709201522t4e512544md28cbca59347d20e@mail.gmail.com>
	<46F3711A.1000102@ukr.net> <46F3727C.1070204@gmail.com>
	<46F3751C.2030202@ar.media.kyoto-u.ac.jp>
Message-ID: <e76aa17f0709210633q41de6a51v31d32bf95d1bc051@mail.gmail.com>

>
> One thing which would be useful is for each admin of one scikits to be
> able to release a tarball ? Is there any kind of tools to do it in a
> semi automatic way ?



The trac can create a zip file (although its name is not the best that could
be found) from a subdirectory, it can help for a starter ?

Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070921/4e8e0574/attachment.html>

From millman at berkeley.edu  Sat Sep 22 04:31:42 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Sat, 22 Sep 2007 01:31:42 -0700
Subject: [SciPy-dev] New scipy 0.6.0 uploads
Message-ID: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>

There is a new scipy-0.6.0.tar.gz on the sourceforge page, which
contains the missing scipy/linalg/src/fblaswrap_veclib_c.c.  There is
also now a scipy-0.6.0-py2.4-win32.egg and scipy-0.6.0-py2.5-win32.egg.

Enjoy,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From jswhit at fastmail.fm  Sat Sep 22 10:37:31 2007
From: jswhit at fastmail.fm (Jeff Whitaker)
Date: Sat, 22 Sep 2007 08:37:31 -0600
Subject: [SciPy-dev] sandbox
Message-ID: <46F528AB.5080300@fastmail.fm>


How do I import the sandbox packages?  With 0.6.0 I get

 >>> import scipy.sandbox
 >>> dir(scipy.sandbox)
['__builtins__', '__doc__', '__file__', '__name__', '__path__']


even though

[jsw at Macintosh:/Users/jsw] ls -l 
/sw/lib/python2.5/site-packages/scipy/sandbox/
total 16
-rw-r--r--   1 root admin    0 Sep 22 08:28 __init__.py
-rw-r--r--   1 root admin  144 Sep 22 08:04 __init__.pyc
-rw-r--r--   1 root admin  121 Sep 22 08:27 __init__.py~
drwxr-xr-x   9 root admin  306 Sep 22 08:22 buildgrid
drwxr-xr-x  16 root admin  544 Sep 22 08:22 cdavid
drwxr-xr-x  10 root admin  340 Sep 22 08:22 constants
drwxr-xr-x  13 root admin  442 Sep 22 08:22 delaunay
drwxr-xr-x  13 root admin  442 Sep 22 08:22 exmplpackage
drwxr-xr-x  12 root admin  408 Sep 22 08:22 fdfpack
drwxr-xr-x  39 root admin 1326 Sep 22 08:22 models
drwxr-xr-x  22 root admin  748 Sep 22 08:22 multigrid
drwxr-xr-x   6 root admin  204 Sep 22 08:22 netcdf
drwxr-xr-x  16 root admin  544 Sep 22 08:22 numexpr
drwxr-xr-x  26 root admin  884 Sep 22 08:22 pyem
drwxr-xr-x  11 root admin  374 Sep 22 08:22 rbf
drwxr-xr-x  10 root admin  340 Sep 22 08:22 rkern
-rw-r--r--   1 root admin 2719 Sep 22 07:47 setup.py
-rw-r--r--   1 root admin 1500 Sep 22 08:04 setup.pyc
drwxr-xr-x  14 root admin  476 Sep 22 08:22 spline
drwxr-xr-x  24 root admin  816 Sep 22 08:22 svm
drwxr-xr-x 114 root admin 3876 Sep 22 08:22 xplt

-Jeff


-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328



From nwagner at iam.uni-stuttgart.de  Sat Sep 22 11:06:28 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Sat, 22 Sep 2007 17:06:28 +0200
Subject: [SciPy-dev] sandbox
In-Reply-To: <46F528AB.5080300@fastmail.fm>
References: <46F528AB.5080300@fastmail.fm>
Message-ID: <web-89675025@uni-stuttgart.de>

On Sat, 22 Sep 2007 08:37:31 -0600
  Jeff Whitaker <jswhit at fastmail.fm> wrote:
> 
> How do I import the sandbox packages?  With 0.6.0 I get
> 
> >>> import scipy.sandbox
> >>> dir(scipy.sandbox)
> ['__builtins__', '__doc__', '__file__', '__name__', 
>'__path__']
> 
> 
> even though
> 
> [jsw at Macintosh:/Users/jsw] ls -l 
> /sw/lib/python2.5/site-packages/scipy/sandbox/
> total 16
> -rw-r--r--   1 root admin    0 Sep 22 08:28 __init__.py
> -rw-r--r--   1 root admin  144 Sep 22 08:04 __init__.pyc
> -rw-r--r--   1 root admin  121 Sep 22 08:27 __init__.py~
> drwxr-xr-x   9 root admin  306 Sep 22 08:22 buildgrid
> drwxr-xr-x  16 root admin  544 Sep 22 08:22 cdavid
> drwxr-xr-x  10 root admin  340 Sep 22 08:22 constants
> drwxr-xr-x  13 root admin  442 Sep 22 08:22 delaunay
> drwxr-xr-x  13 root admin  442 Sep 22 08:22 exmplpackage
> drwxr-xr-x  12 root admin  408 Sep 22 08:22 fdfpack
> drwxr-xr-x  39 root admin 1326 Sep 22 08:22 models
> drwxr-xr-x  22 root admin  748 Sep 22 08:22 multigrid
> drwxr-xr-x   6 root admin  204 Sep 22 08:22 netcdf
> drwxr-xr-x  16 root admin  544 Sep 22 08:22 numexpr
> drwxr-xr-x  26 root admin  884 Sep 22 08:22 pyem
> drwxr-xr-x  11 root admin  374 Sep 22 08:22 rbf
> drwxr-xr-x  10 root admin  340 Sep 22 08:22 rkern
> -rw-r--r--   1 root admin 2719 Sep 22 07:47 setup.py
> -rw-r--r--   1 root admin 1500 Sep 22 08:04 setup.pyc
> drwxr-xr-x  14 root admin  476 Sep 22 08:22 spline
> drwxr-xr-x  24 root admin  816 Sep 22 08:22 svm
> drwxr-xr-x 114 root admin 3876 Sep 22 08:22 xplt
> 
> -Jeff
> 
> 
> -- 
> Jeffrey S. Whitaker         Phone : (303)497-6313
> NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
> 325 Broadway                Boulder, CO, USA 80305-3328
> 
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev


You have to enable them first.
Create a file enabled_packages.txt in your
directory scipy/scipy/sandbox with appropriate
entries
e.g.

arpack
lobpcg
timeseries
multigrid


If you have rebuild scipy you can import them with

from scipy.sandbox import arpack


Cheers,
  
Nils


From jswhit at fastmail.fm  Sat Sep 22 11:34:01 2007
From: jswhit at fastmail.fm (Jeff Whitaker)
Date: Sat, 22 Sep 2007 09:34:01 -0600
Subject: [SciPy-dev] sandbox
In-Reply-To: <web-89675025@uni-stuttgart.de>
References: <46F528AB.5080300@fastmail.fm> <web-89675025@uni-stuttgart.de>
Message-ID: <46F535E9.2060200@fastmail.fm>

Nils Wagner wrote:
> On Sat, 22 Sep 2007 08:37:31 -0600
>   Jeff Whitaker <jswhit at fastmail.fm> wrote:
>   
>> How do I import the sandbox packages?  With 0.6.0 I get
>>
>>     
>>>>> import scipy.sandbox
>>>>> dir(scipy.sandbox)
>>>>>           
>> ['__builtins__', '__doc__', '__file__', '__name__', 
>> '__path__']
>>
>>
>> even though
>>
>> [jsw at Macintosh:/Users/jsw] ls -l 
>> /sw/lib/python2.5/site-packages/scipy/sandbox/
>> total 16
>> -rw-r--r--   1 root admin    0 Sep 22 08:28 __init__.py
>> -rw-r--r--   1 root admin  144 Sep 22 08:04 __init__.pyc
>> -rw-r--r--   1 root admin  121 Sep 22 08:27 __init__.py~
>> drwxr-xr-x   9 root admin  306 Sep 22 08:22 buildgrid
>> drwxr-xr-x  16 root admin  544 Sep 22 08:22 cdavid
>> drwxr-xr-x  10 root admin  340 Sep 22 08:22 constants
>> drwxr-xr-x  13 root admin  442 Sep 22 08:22 delaunay
>> drwxr-xr-x  13 root admin  442 Sep 22 08:22 exmplpackage
>> drwxr-xr-x  12 root admin  408 Sep 22 08:22 fdfpack
>> drwxr-xr-x  39 root admin 1326 Sep 22 08:22 models
>> drwxr-xr-x  22 root admin  748 Sep 22 08:22 multigrid
>> drwxr-xr-x   6 root admin  204 Sep 22 08:22 netcdf
>> drwxr-xr-x  16 root admin  544 Sep 22 08:22 numexpr
>> drwxr-xr-x  26 root admin  884 Sep 22 08:22 pyem
>> drwxr-xr-x  11 root admin  374 Sep 22 08:22 rbf
>> drwxr-xr-x  10 root admin  340 Sep 22 08:22 rkern
>> -rw-r--r--   1 root admin 2719 Sep 22 07:47 setup.py
>> -rw-r--r--   1 root admin 1500 Sep 22 08:04 setup.pyc
>> drwxr-xr-x  14 root admin  476 Sep 22 08:22 spline
>> drwxr-xr-x  24 root admin  816 Sep 22 08:22 svm
>> drwxr-xr-x 114 root admin 3876 Sep 22 08:22 xplt
>>
>> -Jeff
>>
>>
>> -- 
>> Jeffrey S. Whitaker         Phone : (303)497-6313
>> NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
>> 325 Broadway                Boulder, CO, USA 80305-3328
>>
>> _______________________________________________
>> Scipy-dev mailing list
>> Scipy-dev at scipy.org
>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>     
>
>
> You have to enable them first.
> Create a file enabled_packages.txt in your
> directory scipy/scipy/sandbox with appropriate
> entries
> e.g.
>
> arpack
> lobpcg
> timeseries
> multigrid
>
>
> If you have rebuild scipy you can import them with
>
> from scipy.sandbox import arpack
>
>
> Cheers,
>   
> Nils
>   

Nils:  I did this, and the packages were built and installed.  I just 
can't import them.  My scipy.sandbox __init__.py file is empty, is yours?

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328



From matthieu.brucher at gmail.com  Sat Sep 22 11:42:56 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Sat, 22 Sep 2007 17:42:56 +0200
Subject: [SciPy-dev] sandbox
In-Reply-To: <46F535E9.2060200@fastmail.fm>
References: <46F528AB.5080300@fastmail.fm> <web-89675025@uni-stuttgart.de>
	<46F535E9.2060200@fastmail.fm>
Message-ID: <e76aa17f0709220842u4abfe172q35d0f670b254e24a@mail.gmail.com>

Did you try

import scipy.sandbox.something as something ?

Matthieu

2007/9/22, Jeff Whitaker <jswhit at fastmail.fm>:
>
> Nils Wagner wrote:
> > On Sat, 22 Sep 2007 08:37:31 -0600
> >   Jeff Whitaker <jswhit at fastmail.fm> wrote:
> >
> >> How do I import the sandbox packages?  With 0.6.0 I get
> >>
> >>
> >>>>> import scipy.sandbox
> >>>>> dir(scipy.sandbox)
> >>>>>
> >> ['__builtins__', '__doc__', '__file__', '__name__',
> >> '__path__']
> >>
> >>
> >> even though
> >>
> >> [jsw at Macintosh:/Users/jsw] ls -l
> >> /sw/lib/python2.5/site-packages/scipy/sandbox/
> >> total 16
> >> -rw-r--r--   1 root admin    0 Sep 22 08:28 __init__.py
> >> -rw-r--r--   1 root admin  144 Sep 22 08:04 __init__.pyc
> >> -rw-r--r--   1 root admin  121 Sep 22 08:27 __init__.py~
> >> drwxr-xr-x   9 root admin  306 Sep 22 08:22 buildgrid
> >> drwxr-xr-x  16 root admin  544 Sep 22 08:22 cdavid
> >> drwxr-xr-x  10 root admin  340 Sep 22 08:22 constants
> >> drwxr-xr-x  13 root admin  442 Sep 22 08:22 delaunay
> >> drwxr-xr-x  13 root admin  442 Sep 22 08:22 exmplpackage
> >> drwxr-xr-x  12 root admin  408 Sep 22 08:22 fdfpack
> >> drwxr-xr-x  39 root admin 1326 Sep 22 08:22 models
> >> drwxr-xr-x  22 root admin  748 Sep 22 08:22 multigrid
> >> drwxr-xr-x   6 root admin  204 Sep 22 08:22 netcdf
> >> drwxr-xr-x  16 root admin  544 Sep 22 08:22 numexpr
> >> drwxr-xr-x  26 root admin  884 Sep 22 08:22 pyem
> >> drwxr-xr-x  11 root admin  374 Sep 22 08:22 rbf
> >> drwxr-xr-x  10 root admin  340 Sep 22 08:22 rkern
> >> -rw-r--r--   1 root admin 2719 Sep 22 07:47 setup.py
> >> -rw-r--r--   1 root admin 1500 Sep 22 08:04 setup.pyc
> >> drwxr-xr-x  14 root admin  476 Sep 22 08:22 spline
> >> drwxr-xr-x  24 root admin  816 Sep 22 08:22 svm
> >> drwxr-xr-x 114 root admin 3876 Sep 22 08:22 xplt
> >>
> >> -Jeff
> >>
> >>
> >> --
> >> Jeffrey S. Whitaker         Phone : (303)497-6313
> >> NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
> >> 325 Broadway                Boulder, CO, USA 80305-3328
> >>
> >> _______________________________________________
> >> Scipy-dev mailing list
> >> Scipy-dev at scipy.org
> >> http://projects.scipy.org/mailman/listinfo/scipy-dev
> >>
> >
> >
> > You have to enable them first.
> > Create a file enabled_packages.txt in your
> > directory scipy/scipy/sandbox with appropriate
> > entries
> > e.g.
> >
> > arpack
> > lobpcg
> > timeseries
> > multigrid
> >
> >
> > If you have rebuild scipy you can import them with
> >
> > from scipy.sandbox import arpack
> >
> >
> > Cheers,
> >
> > Nils
> >
>
> Nils:  I did this, and the packages were built and installed.  I just
> can't import them.  My scipy.sandbox __init__.py file is empty, is yours?
>
> -Jeff
>
> --
> Jeffrey S. Whitaker         Phone : (303)497-6313
> NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
> 325 Broadway                Boulder, CO, USA 80305-3328
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070922/5638f595/attachment.html>

From jswhit at fastmail.fm  Sat Sep 22 11:56:30 2007
From: jswhit at fastmail.fm (Jeff Whitaker)
Date: Sat, 22 Sep 2007 09:56:30 -0600
Subject: [SciPy-dev] sandbox
In-Reply-To: <web-89675847@uni-stuttgart.de>
References: <46F528AB.5080300@fastmail.fm> <web-89675025@uni-stuttgart.de>
	<46F535E9.2060200@fastmail.fm> <web-89675847@uni-stuttgart.de>
Message-ID: <46F53B2E.3000204@fastmail.fm>

Nils Wagner wrote:
> On Sat, 22 Sep 2007 09:34:01 -0600
>  Jeff Whitaker <jswhit at fastmail.fm> wrote:
>> Nils Wagner wrote:
>>> On Sat, 22 Sep 2007 08:37:31 -0600
>>>   Jeff Whitaker <jswhit at fastmail.fm> wrote:
>>>  
>>>> How do I import the sandbox packages?  With 0.6.0 I get
>>>>
>>>>    
>>>>>>> import scipy.sandbox
>>>>>>> dir(scipy.sandbox)
>>>>>>>           
>>>> ['__builtins__', '__doc__', '__file__', '__name__', '__path__']
>>>>
>>>>
>>>> even though
>>>>
>>>> [jsw at Macintosh:/Users/jsw] ls -l 
>>>> /sw/lib/python2.5/site-packages/scipy/sandbox/
>>>> total 16
>>>> -rw-r--r--   1 root admin    0 Sep 22 08:28 __init__.py
>>>> -rw-r--r--   1 root admin  144 Sep 22 08:04 __init__.pyc
>>>> -rw-r--r--   1 root admin  121 Sep 22 08:27 __init__.py~
>>>> drwxr-xr-x   9 root admin  306 Sep 22 08:22 buildgrid
>>>> drwxr-xr-x  16 root admin  544 Sep 22 08:22 cdavid
>>>> drwxr-xr-x  10 root admin  340 Sep 22 08:22 constants
>>>> drwxr-xr-x  13 root admin  442 Sep 22 08:22 delaunay
>>>> drwxr-xr-x  13 root admin  442 Sep 22 08:22 exmplpackage
>>>> drwxr-xr-x  12 root admin  408 Sep 22 08:22 fdfpack
>>>> drwxr-xr-x  39 root admin 1326 Sep 22 08:22 models
>>>> drwxr-xr-x  22 root admin  748 Sep 22 08:22 multigrid
>>>> drwxr-xr-x   6 root admin  204 Sep 22 08:22 netcdf
>>>> drwxr-xr-x  16 root admin  544 Sep 22 08:22 numexpr
>>>> drwxr-xr-x  26 root admin  884 Sep 22 08:22 pyem
>>>> drwxr-xr-x  11 root admin  374 Sep 22 08:22 rbf
>>>> drwxr-xr-x  10 root admin  340 Sep 22 08:22 rkern
>>>> -rw-r--r--   1 root admin 2719 Sep 22 07:47 setup.py
>>>> -rw-r--r--   1 root admin 1500 Sep 22 08:04 setup.pyc
>>>> drwxr-xr-x  14 root admin  476 Sep 22 08:22 spline
>>>> drwxr-xr-x  24 root admin  816 Sep 22 08:22 svm
>>>> drwxr-xr-x 114 root admin 3876 Sep 22 08:22 xplt
>>>>
>>>> -Jeff
>>>>
>>>>
>>>> -- 
>>>> Jeffrey S. Whitaker         Phone : (303)497-6313
>>>> NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
>>>> 325 Broadway                Boulder, CO, USA 80305-3328
>>>>
>>>> _______________________________________________
>>>> Scipy-dev mailing list
>>>> Scipy-dev at scipy.org
>>>> http://projects.scipy.org/mailman/listinfo/scipy-dev
>>>>     
>>>
>>>
>>> You have to enable them first.
>>> Create a file enabled_packages.txt in your
>>> directory scipy/scipy/sandbox with appropriate
>>> entries
>>> e.g.
>>>
>>> arpack
>>> lobpcg
>>> timeseries
>>> multigrid
>>>
>>>
>>> If you have rebuild scipy you can import them with
>>>
>>> from scipy.sandbox import arpack
>>>
>>>
>>> Cheers,
>>>   Nils
>>>   
>>
>> Nils:  I did this, and the packages were built and installed.  I just 
>> can't import them.  My scipy.sandbox __init__.py file is empty, is 
>> yours?
>>
>> -Jeff
>>
>> -- 
>> Jeffrey S. Whitaker         Phone : (303)497-6313
>> NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
>> 325 Broadway                Boulder, CO, USA 80305-3328
>>
> ls -l
> total 28
> drwxr-xr-x 3 root root 4096 2007-09-21 16:42 arpack
> -rw-r--r-- 1 root root    0 2007-09-01 13:01 __init__.py
> -rw-r--r-- 1 root root  153 2007-09-11 20:00 __init__.pyc
> drwxr-xr-x 3 root root 4096 2007-09-11 20:52 lobpcg
> drwxr-xr-x 3 root root 4096 2007-09-21 16:42 multigrid
> -rw-r--r-- 1 root root 2735 2007-09-01 13:01 setup.py
> -rw-r--r-- 1 root root 1094 2007-09-11 20:00 setup.pyc
> drwxr-xr-x 3 root root 4096 2007-09-21 16:42 timeseries
> nwagner at noname:/usr/local/lib64/python2.5/site-packages/scipy/sandbox>
>
>  
> Did you try from scipy.sandbox import multigrid ?
>
> Nils

Nils:

Ah, yes that works.  I was trying

from scipy.sandbox import netcdf

which doesn't work (although all the rest apparently do). So it must be 
a problem just with the netcdf package.

Thanks for the help

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328



From millman at berkeley.edu  Sun Sep 23 10:01:46 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Sun, 23 Sep 2007 07:01:46 -0700
Subject: [SciPy-dev] scipy.misc.limits deprecated
Message-ID: <c7009a550709230701v522e3e1em10f055e698356eb2@mail.gmail.com>

Hello,

As of r3362, scipy.misc.limits is officially deprecated:
  http://projects.scipy.org/scipy/scipy/changeset/3362

If you need to work with the machine limits, please use numpy.finfo instead:
  http://scipy.org/scipy/numpy/browser/trunk/numpy/lib/getlimits.py

For example,
  from numpy import finfo, single
  single_epsilon = finfo(single).eps

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From ondrej at certik.cz  Sun Sep 23 13:09:23 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Sun, 23 Sep 2007 19:09:23 +0200
Subject: [SciPy-dev] New scipy 0.6.0 uploads
In-Reply-To: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>
References: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>
Message-ID: <85b5c3130709231009y52ff9d21sfc417df3b2f37e22@mail.gmail.com>

On 9/22/07, Jarrod Millman <millman at berkeley.edu> wrote:
> There is a new scipy-0.6.0.tar.gz on the sourceforge page, which
> contains the missing scipy/linalg/src/fblaswrap_veclib_c.c.  There is
> also now a scipy-0.6.0-py2.4-win32.egg and scipy-0.6.0-py2.5-win32.egg.

The new scipy-0.6.0 package is now in Debian, in incoming packages:

http://incoming.debian.org/python-scipy_0.6.0-1_i386.deb

and it will hit the archives (unstable) tomorrow. You can download it
by hand using the link above, if you want it today.

Ondrej


From millman at berkeley.edu  Sun Sep 23 17:14:42 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Sun, 23 Sep 2007 14:14:42 -0700
Subject: [SciPy-dev] New scipy 0.6.0 uploads
In-Reply-To: <85b5c3130709231009y52ff9d21sfc417df3b2f37e22@mail.gmail.com>
References: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>
	<85b5c3130709231009y52ff9d21sfc417df3b2f37e22@mail.gmail.com>
Message-ID: <c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>

On 9/23/07, Ondrej Certik <ondrej at certik.cz> wrote:
> The new scipy-0.6.0 package is now in Debian, in incoming packages:
>
> http://incoming.debian.org/python-scipy_0.6.0-1_i386.deb

Thanks Ondrej.  I have decided to follow your excellent example and am
going to see if I can help the Fedora packagers.  I just sent an email
to Debarshi 'Rishi' Ray, a Fedora packager, asking if I could help get
a scipy-0.6.0 rpm released.  If anyone knows who currently maintains
the official Fedora packages, please let me know.

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From charlesr.harris at gmail.com  Sun Sep 23 18:16:37 2007
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 23 Sep 2007 16:16:37 -0600
Subject: [SciPy-dev] New scipy 0.6.0 uploads
In-Reply-To: <c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>
References: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>
	<85b5c3130709231009y52ff9d21sfc417df3b2f37e22@mail.gmail.com>
	<c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>
Message-ID: <e06186140709231516x7713c340wf9f88fb8c330fa47@mail.gmail.com>

On 9/23/07, Jarrod Millman <millman at berkeley.edu> wrote:
>
> On 9/23/07, Ondrej Certik <ondrej at certik.cz> wrote:
> > The new scipy-0.6.0 package is now in Debian, in incoming packages:
> >
> > http://incoming.debian.org/python-scipy_0.6.0-1_i386.deb
>
> Thanks Ondrej.  I have decided to follow your excellent example and am
> going to see if I can help the Fedora packagers.  I just sent an email
> to Debarshi 'Rishi' Ray, a Fedora packager, asking if I could help get
> a scipy-0.6.0 rpm released.  If anyone knows who currently maintains
> the official Fedora packages, please let me know.


You might check with the Fedora Atlas guy too. I filed a bug on the  package
as it failed to run properly on some 64 bit machines but I haven't seen any
activity there.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070923/30fbf2c3/attachment.html>

From ondrej at certik.cz  Sun Sep 23 18:49:48 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 24 Sep 2007 00:49:48 +0200
Subject: [SciPy-dev] New scipy 0.6.0 uploads
In-Reply-To: <c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>
References: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>
	<85b5c3130709231009y52ff9d21sfc417df3b2f37e22@mail.gmail.com>
	<c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>
Message-ID: <85b5c3130709231549i52ed5168of7a4264aa3dad225@mail.gmail.com>

> Thanks Ondrej.  I have decided to follow your excellent example and am
> going to see if I can help the Fedora packagers.  I just sent an email
> to Debarshi 'Rishi' Ray, a Fedora packager, asking if I could help get
> a scipy-0.6.0 rpm released.  If anyone knows who currently maintains
> the official Fedora packages, please let me know.

Yes, that's a nice idea. I always have in mind this graph:

http://www.desktoplinux.com/news/NS8454912761.html

which says, that if we cover Ubuntu+Debian+Fedora, we already have 53%
of desktop users and if we could cover Suse as well, it gives 74%, so
that's most of the users.

In Debian it's already in archives (you can watch how it is being
compiled on all architectures in there):

http://packages.debian.org/sid/python-scipy

In Ubuntu:

https://launchpad.net/ubuntu/+source/python-scipy/+publishinghistory

I am not sure how it works, but I think the gutsy is freezed already,
so the new version of scipy will not make it into it, but when they
release gutsy, it should get synchronized, I'll try to get in touch
with the Ubuntu maintainers.

Ondrej


From ondrej at certik.cz  Sun Sep 23 18:51:29 2007
From: ondrej at certik.cz (Ondrej Certik)
Date: Mon, 24 Sep 2007 00:51:29 +0200
Subject: [SciPy-dev] New scipy 0.6.0 uploads
In-Reply-To: <c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>
References: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>
	<85b5c3130709231009y52ff9d21sfc417df3b2f37e22@mail.gmail.com>
	<c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>
Message-ID: <85b5c3130709231551ned0b00bv1483d7123af8952c@mail.gmail.com>

> Thanks Ondrej.  I have decided to follow your excellent example and am
> going to see if I can help the Fedora packagers.  I just sent an email
> to Debarshi 'Rishi' Ray, a Fedora packager, asking if I could help get
> a scipy-0.6.0 rpm released.  If anyone knows who currently maintains
> the official Fedora packages, please let me know.

Yes, that's a nice idea. I always have in mind this graph:

http://www.desktoplinux.com/news/NS8454912761.html

which says, that if we cover Ubuntu+Debian+Fedora, we already have 53%
of desktop users and if we could cover Suse as well, it gives 74%, so
that's most of the users.

In Debian it's already in archives (you can watch how it is being
compiled on all architectures in there):

http://packages.debian.org/sid/python-scipy

In Ubuntu:

https://launchpad.net/ubuntu/+source/python-scipy/+publishinghistory

I am not sure how it works, but I think the gutsy is freezed already,
so the new version of scipy will not make it into it, but when they
release gutsy, it should get synchronized, I'll try to get in touch
with the Ubuntu maintainers.

Ondrej


From dmitrey.kroshko at scipy.org  Mon Sep 24 12:01:51 2007
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Mon, 24 Sep 2007 19:01:51 +0300
Subject: [SciPy-dev] SciPy 0.6.0 release
Message-ID: <46F7DF6F.5030907@scipy.org>

Matthieu Brucher wrote:
>
> The trac can create a zip file (although its name is not the best that 
> could be found) from a subdirectory, it can help for a starter ?
>
> Matthieu
So how it can be done?
I can't get anything related  - neither via web search "zip trac" nor 
"zip" in http://trac.edgewall.org
Regards, D.



From strawman at astraw.com  Mon Sep 24 19:03:14 2007
From: strawman at astraw.com (Andrew Straw)
Date: Mon, 24 Sep 2007 16:03:14 -0700
Subject: [SciPy-dev] New scipy 0.6.0 uploads
In-Reply-To: <85b5c3130709231549i52ed5168of7a4264aa3dad225@mail.gmail.com>
References: <c7009a550709220131t4a225b4etad27db9c45e58a89@mail.gmail.com>	<85b5c3130709231009y52ff9d21sfc417df3b2f37e22@mail.gmail.com>	<c7009a550709231414k26b60deama0e0cfa56436c6c5@mail.gmail.com>
	<85b5c3130709231549i52ed5168of7a4264aa3dad225@mail.gmail.com>
Message-ID: <46F84232.9030103@astraw.com>

I have uploaded (an Ubuntu Gutsy version) of the Debian package of
scipy-0.6.0 to

http://ppa.launchpad.net/astraw/ubuntu/pool/universe/p/python-scipy/

>From that link, you can directly download the .debs for i386 and amd64
in addition to the source package.

I have published this using Ubuntu's "Personal Package Archive", which
is pretty nifty if you're already used to building Debian source packages.

Ondrej Certik wrote:
>> Thanks Ondrej.  I have decided to follow your excellent example and am
>> going to see if I can help the Fedora packagers.  I just sent an email
>> to Debarshi 'Rishi' Ray, a Fedora packager, asking if I could help get
>> a scipy-0.6.0 rpm released.  If anyone knows who currently maintains
>> the official Fedora packages, please let me know.
> 
> Yes, that's a nice idea. I always have in mind this graph:
> 
> http://www.desktoplinux.com/news/NS8454912761.html
> 
> which says, that if we cover Ubuntu+Debian+Fedora, we already have 53%
> of desktop users and if we could cover Suse as well, it gives 74%, so
> that's most of the users.
> 
> In Debian it's already in archives (you can watch how it is being
> compiled on all architectures in there):
> 
> http://packages.debian.org/sid/python-scipy
> 
> In Ubuntu:
> 
> https://launchpad.net/ubuntu/+source/python-scipy/+publishinghistory
> 
> I am not sure how it works, but I think the gutsy is freezed already,
> so the new version of scipy will not make it into it, but when they
> release gutsy, it should get synchronized, I'll try to get in touch
> with the Ubuntu maintainers.




From dmitrey.kroshko at scipy.org  Tue Sep 25 03:17:53 2007
From: dmitrey.kroshko at scipy.org (dmitrey)
Date: Tue, 25 Sep 2007 10:17:53 +0300
Subject: [SciPy-dev] problems with
	numpy.setuptools("single_version_externally_managed")
Message-ID: <46F8B621.3030809@scipy.org>

hi all,

If I use in setup.py:

import setuptools
from numpy.distutils.system_info import system_info, NotFoundError, 
dict_append, so_ext

I successfully install (OpenOpt) but Nils and I get the warning (with 
latest numpy)
********************************************************
WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!

distutils has been imported before numpy.distutils
and now numpy.distutils cannot apply all of its
customizations to distutils effectively.

To avoid this warning, make sure that numpy.distutils
is imported *before* distutils.
********************************************************
(BTW note that distutils is not setuptools)

If I use vise versa, as it is recommended:
from numpy.distutils.system_info import system_info, NotFoundError, 
dict_append, so_ext
import setuptools
Then I get:

$ sudo python setup.py install

running install
running build
running config_cc
unifing config_cc, config, build_clib, build_ext, build commands 
--compiler options
running config_fc
unifing config_fc, config, build_clib, build_ext, build commands 
--fcompiler options
running build_py
running install_lib
Traceback (most recent call last):
  File "setup.py", line 93, in <module>
    'Topic :: Scientific/Engineering']
  File "/usr/lib/python2.5/site-packages/numpy/distutils/core.py", line 
176, in setup
    return old_setup(**new_attr)
  File "distutils/core.py", line 151, in setup
  File "distutils/dist.py", line 974, in run_commands
  File "distutils/dist.py", line 994, in run_command
  File 
"/usr/lib/python2.5/site-packages/numpy/distutils/command/install.py", 
line 16, in run
    r = old_install.run(self)
  File "distutils/command/install.py", line 510, in run
  File "/usr/lib/python2.5/cmd.py", line 333, in run_command
    del help[cmd]
  File "distutils/dist.py", line 994, in run_command
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
line 21, in run
    outfiles = self.install()
  File "distutils/command/install_lib.py", line 116, in install
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
line 47, in copy_tree
    exclude = self.get_exclusions()
  File 
"/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
line 30, in get_exclusions
    if (nsp and self.get_finalized_command('install')
  File "/usr/lib/python2.5/cmd.py", line 112, in __getattr__
    import readline
AttributeError: single_version_externally_managed

Do you know what does it means and how it could be fixed?
Best regards, D.



From pearu at cens.ioc.ee  Tue Sep 25 03:30:40 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 25 Sep 2007 09:30:40 +0200
Subject: [SciPy-dev] problems
	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <46F8B621.3030809@scipy.org>
References: <46F8B621.3030809@scipy.org>
Message-ID: <46F8B920.6090201@cens.ioc.ee>


dmitrey wrote:
> hi all,
> 
> If I use in setup.py:
> 
> import setuptools
> from numpy.distutils.system_info import system_info, NotFoundError, 
> dict_append, so_ext
> 
> I successfully install (OpenOpt) but Nils and I get the warning (with 
> latest numpy)
> ********************************************************
> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
> 
> distutils has been imported before numpy.distutils
> and now numpy.distutils cannot apply all of its
> customizations to distutils effectively.
> 
> To avoid this warning, make sure that numpy.distutils
> is imported *before* distutils.
> ********************************************************
> (BTW note that distutils is not setuptools)

setuptools probably then imports distutils as the above warning
is triggered using the following condition:

   'distutils' in sys.modules

> If I use vise versa, as it is recommended:
> from numpy.distutils.system_info import system_info, NotFoundError, 
> dict_append, so_ext
> import setuptools
> Then I get:
> 
> $ sudo python setup.py install
> 
> running install
> running build
> running config_cc
> unifing config_cc, config, build_clib, build_ext, build commands 
> --compiler options
> running config_fc
> unifing config_fc, config, build_clib, build_ext, build commands 
> --fcompiler options
> running build_py
> running install_lib
> Traceback (most recent call last):
>   File "setup.py", line 93, in <module>
>     'Topic :: Scientific/Engineering']
>   File "/usr/lib/python2.5/site-packages/numpy/distutils/core.py", line 
> 176, in setup
>     return old_setup(**new_attr)
>   File "distutils/core.py", line 151, in setup
>   File "distutils/dist.py", line 974, in run_commands
>   File "distutils/dist.py", line 994, in run_command
>   File 
> "/usr/lib/python2.5/site-packages/numpy/distutils/command/install.py", 
> line 16, in run
>     r = old_install.run(self)
>   File "distutils/command/install.py", line 510, in run
>   File "/usr/lib/python2.5/cmd.py", line 333, in run_command
>     del help[cmd]
>   File "distutils/dist.py", line 994, in run_command
>   File 
> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
> line 21, in run
>     outfiles = self.install()
>   File "distutils/command/install_lib.py", line 116, in install
>   File 
> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
> line 47, in copy_tree
>     exclude = self.get_exclusions()
>   File 
> "/usr/lib/python2.5/site-packages/setuptools/command/install_lib.py", 
> line 30, in get_exclusions
>     if (nsp and self.get_finalized_command('install')
>   File "/usr/lib/python2.5/cmd.py", line 112, in __getattr__
>     import readline
> AttributeError: single_version_externally_managed
> 
> Do you know what does it means and how it could be fixed?

I don't know much of setuptools but may guess is that setuptools
overwrites some distutils functions/methods like numpy.distutils
does. Does setuptools say anything about the order of importing
distutils and setuptools? If not then I would call this setuptools
bug.

On systems that do not use spaces in path names the order of
importing distutils or numpy.distutils is not that important
(but in some cases importing numpy.distutils first is important).
However, for windows support the import order is crusial
(numpy.distutils fixes the paths with spaces properly).

We could make the above warning windows specific but only if
there are fundamental reasons for not fixing setuptools.

Pearu


From cookedm at physics.mcmaster.ca  Tue Sep 25 10:57:36 2007
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Tue, 25 Sep 2007 10:57:36 -0400
Subject: [SciPy-dev] problems with
	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <46F8B621.3030809@scipy.org> (dmitrey's message of "Tue,
	25 Sep 2007 10:17:53 +0300")
References: <46F8B621.3030809@scipy.org>
Message-ID: <m2wsue4wtb.fsf@saturn.dmc>

dmitrey <dmitrey.kroshko at scipy.org> writes:

> hi all,
>
> If I use in setup.py:
>
> import setuptools
> from numpy.distutils.system_info import system_info, NotFoundError, 
> dict_append, so_ext
>
> I successfully install (OpenOpt) but Nils and I get the warning (with 
> latest numpy)
> ********************************************************
> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>
> distutils has been imported before numpy.distutils
> and now numpy.distutils cannot apply all of its
> customizations to distutils effectively.
>
> To avoid this warning, make sure that numpy.distutils
> is imported *before* distutils.
> ********************************************************
> (BTW note that distutils is not setuptools)

This is because of a recent change by Pearu. This is the right way to
do it with setuptools.

Pearu: I'm going to back your change out. For one thing, this is now
broken:

$ python setupegg.py bdist_egg
Running from numpy source directory.
********************************************************
WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
[etc.]


I *think* (and I'll fix any bugs that don't correspond to this ;-)
that importing numpy.distutils after distutils is ok, as long as
you're not doing anything 'odd'. Basically, distutils isn't very
robust, so it's quite hard to tell what's a bad way to mix things.
But, we *do* explicitly support setuptools if it has been imported
first.

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca


From pearu at cens.ioc.ee  Tue Sep 25 11:22:33 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 25 Sep 2007 18:22:33 +0300 (EEST)
Subject: [SciPy-dev] problems with
 numpy.setuptools("single_version_externally_managed")
In-Reply-To: <m2wsue4wtb.fsf@saturn.dmc>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
Message-ID: <51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>

On Tue, September 25, 2007 5:57 pm, David M. Cooke wrote:

>> I successfully install (OpenOpt) but Nils and I get the warning (with
>> latest numpy)
>> ********************************************************
>> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>>
>> distutils has been imported before numpy.distutils
>> and now numpy.distutils cannot apply all of its
>> customizations to distutils effectively.
>>
>> To avoid this warning, make sure that numpy.distutils
>> is imported *before* distutils.
>> ********************************************************
>> (BTW note that distutils is not setuptools)
>
> This is because of a recent change by Pearu. This is the right way to
> do it with setuptools.
>
> Pearu: I'm going to back your change out. For one thing, this is now
> broken:
>
> $ python setupegg.py bdist_egg
> Running from numpy source directory.
> ********************************************************
> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
> [etc.]


This is a warning message. It does not break code.


> I *think* (and I'll fix any bugs that don't correspond to this ;-)
> that importing numpy.distutils after distutils is ok, as long as
> you're not doing anything 'odd'.

I am just trying to ensure that numpy/scipy build on all
platforms we can support. The questions is which one is
more important: to support setuptools or to make the build
work on more platforms? In the given case Windows with MS Visual
compiler.

> Basically, distutils isn't very
> robust, so it's quite hard to tell what's a bad way to mix things.
> But, we *do* explicitly support setuptools if it has been imported
> first.

Ok, then we have a problem. Details follow below.

The problem with importing distutils before numpy.distutils
is in redefining distutils.ccompiler.gen_lib_options function.

This function needs to apply our quote_args to library_dirs and
runtime_library_dirs because distutils _nt_quote_args has a bug
of not checking if directory lists have already been quoted.

So, if distutils is imported before numpy.distutils then

  distutils.ccompiler.gen_lib_options = <our gen_lib_options>

is not effective as distutils/msvccompiler.py does

  from distutils.ccompiler import gen_lib_options

so that the code in msvccompiler.py would still use the old
distutils gen_lib_options function.

Pearu



From cookedm at physics.mcmaster.ca  Tue Sep 25 11:43:58 2007
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Tue, 25 Sep 2007 11:43:58 -0400
Subject: [SciPy-dev] problems with
	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee> (Pearu
	Peterson's message of "Tue, 25 Sep 2007 18:22:33 +0300 (EEST)")
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
Message-ID: <m2sl524uo1.fsf@saturn.dmc>

"Pearu Peterson" <pearu at cens.ioc.ee> writes:
> On Tue, September 25, 2007 5:57 pm, David M. Cooke wrote:
>>
>> $ python setupegg.py bdist_egg
>> Running from numpy source directory.
>> ********************************************************
>> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>> [etc.]
>
>
> This is a warning message. It does not break code.

When a supported method of building throws up a huge warning, I
consider that broken ;-)

>> I *think* (and I'll fix any bugs that don't correspond to this ;-)
>> that importing numpy.distutils after distutils is ok, as long as
>> you're not doing anything 'odd'.
>
> I am just trying to ensure that numpy/scipy build on all
> platforms we can support. The questions is which one is
> more important: to support setuptools or to make the build
> work on more platforms? In the given case Windows with MS Visual
> compiler.
>
> Ok, then we have a problem. Details follow below.
>
> So, if distutils is imported before numpy.distutils then
>
>   distutils.ccompiler.gen_lib_options = <our gen_lib_options>
>
> is not effective as distutils/msvccompiler.py does
>
>   from distutils.ccompiler import gen_lib_options
>
> so that the code in msvccompiler.py would still use the old
> distutils gen_lib_options function.

Fixed that for you. See r4134.

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca


From pearu at cens.ioc.ee  Tue Sep 25 11:51:15 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 25 Sep 2007 18:51:15 +0300 (EEST)
Subject: [SciPy-dev] problems with
 numpy.setuptools("single_version_externally_managed")
In-Reply-To: <m2sl524uo1.fsf@saturn.dmc>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
Message-ID: <55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>

On Tue, September 25, 2007 6:43 pm, David M. Cooke wrote:
>
> Fixed that for you. See r4134.

Right. It does not apply to msvccompiler.py though;)

Pearu



From cookedm at physics.mcmaster.ca  Tue Sep 25 11:57:59 2007
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Tue, 25 Sep 2007 11:57:59 -0400
Subject: [SciPy-dev] problems
	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>
Message-ID: <20070925155759.GA16728@arbutus.physics.mcmaster.ca>

On Tue, Sep 25, 2007 at 06:51:15PM +0300, Pearu Peterson wrote:
> On Tue, September 25, 2007 6:43 pm, David M. Cooke wrote:
> >
> > Fixed that for you. See r4134.
> 
> Right. It does not apply to msvccompiler.py though;)

Oops. Missed that :-) Even thought I tested it, although now I see
that my testing was wrong.

-- 
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke                      http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca


From pearu at cens.ioc.ee  Tue Sep 25 15:19:26 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Tue, 25 Sep 2007 22:19:26 +0300 (EEST)
Subject: [SciPy-dev] problems
 with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <20070925155759.GA16728@arbutus.physics.mcmaster.ca>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>
	<20070925155759.GA16728@arbutus.physics.mcmaster.ca>
Message-ID: <53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>

On Tue, September 25, 2007 6:57 pm, David M. Cooke wrote:
> On Tue, Sep 25, 2007 at 06:51:15PM +0300, Pearu Peterson wrote:
>> On Tue, September 25, 2007 6:43 pm, David M. Cooke wrote:
>> >
>> > Fixed that for you. See r4134.

Though, I am not sure if this is a proper fix.

Importing, say, distutils.msvccompiler may trigger
messages that may be completely irrelevant.
E.g. in my linux box:

>>> from distutils import log
>>> log.set_verbosity(4)
>>> import distutils.msvccompiler
Warning: Can't read registry to find the necessary compiler setting
Make sure that Python modules _winreg, win32api or win32con are installed.

I think distutils.*compiler modules are not designed to be
imported unless specifically requested via --compiler flag.
Though only importing distutils.msvccompiler has side effect.
A seemingly easy fix would be to use the fix by checking os.name
and sys.platform but if one is using mingw32 compiler under windows,
the given warnings would be still wrong.

But we'll see if this will be an issue in future..

Pearu



From david at ar.media.kyoto-u.ac.jp  Tue Sep 25 22:30:58 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 26 Sep 2007 11:30:58 +0900
Subject: [SciPy-dev] problems
	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>
References: <46F8B621.3030809@scipy.org>
	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>	<20070925155759.GA16728@arbutus.physics.mcmaster.ca>
	<53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>
Message-ID: <46F9C462.8080807@ar.media.kyoto-u.ac.jp>

Pearu Peterson wrote:
> O
>
> I think distutils.*compiler modules are not designed to be
> imported unless specifically requested via --compiler flag.
> Though only importing distutils.msvccompiler has side effect.
My impression is that distutils.msvccompiler is quite different from all 
the other ones, right ? It does not have the same attributes, etc... 
This fact is explicitely mentioned in distutils (msvccompiler.py):

# Just set this so CCompiler's constructor doesn't barf.  We currently
# don't use the 'set_executables()' bureaucracy provided by CCompiler,
# as it really isn't necessary for this sort of single-compiler class.
# Would be nice to have a consistent interface with UnixCCompiler,
# though, so it's worth thinking about.

> A seemingly easy fix would be to use the fix by checking os.name
> and sys.platform but if one is using mingw32 compiler under windows,
> the given warnings would be still wrong.
>
Would it be possible to implement our own msvccompiler instead ?

cheers,

David


From pearu at cens.ioc.ee  Wed Sep 26 02:44:46 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 26 Sep 2007 08:44:46 +0200
Subject: [SciPy-dev]
	problems	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <46F9C462.8080807@ar.media.kyoto-u.ac.jp>
References: <46F8B621.3030809@scipy.org>	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>	<20070925155759.GA16728@arbutus.physics.mcmaster.ca>	<53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>
	<46F9C462.8080807@ar.media.kyoto-u.ac.jp>
Message-ID: <46F9FFDE.1070207@cens.ioc.ee>



David Cournapeau wrote:
> Pearu Peterson wrote:
>> O
>>
>> I think distutils.*compiler modules are not designed to be
>> imported unless specifically requested via --compiler flag.
>> Though only importing distutils.msvccompiler has side effect.
> My impression is that distutils.msvccompiler is quite different from all 
> the other ones, right ? It does not have the same attributes, etc... 
> This fact is explicitely mentioned in distutils (msvccompiler.py):
> 
> # Just set this so CCompiler's constructor doesn't barf.  We currently
> # don't use the 'set_executables()' bureaucracy provided by CCompiler,
> # as it really isn't necessary for this sort of single-compiler class.
> # Would be nice to have a consistent interface with UnixCCompiler,
> # though, so it's worth thinking about.
> 
>> A seemingly easy fix would be to use the fix by checking os.name
>> and sys.platform but if one is using mingw32 compiler under windows,
>> the given warnings would be still wrong.
>>
> Would it be possible to implement our own msvccompiler instead ?

Actually, there exist a simple and proper fix (as usual;):

numpy ccompiler.py should check if distutils.msvccompiler is
imported (via sys.modules). If it is, then set

   distutils.msvccompiler.gen_lib_options = <our gen_lib_options>

And if it is not, then do nothing. Note that when
distutils.msvccompiler is imported then it will pick
up the correct gen_lib_options from distutils.ccompiler
which has been already enhanced by numpy.distutils.

Pearu


From david at ar.media.kyoto-u.ac.jp  Wed Sep 26 03:00:31 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 26 Sep 2007 16:00:31 +0900
Subject: [SciPy-dev]
	problems	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <46F9FFDE.1070207@cens.ioc.ee>
References: <46F8B621.3030809@scipy.org>	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>	<20070925155759.GA16728@arbutus.physics.mcmaster.ca>	<53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>	<46F9C462.8080807@ar.media.kyoto-u.ac.jp>
	<46F9FFDE.1070207@cens.ioc.ee>
Message-ID: <46FA038F.3090106@ar.media.kyoto-u.ac.jp>

Pearu Peterson wrote:
>
> Actually, there exist a simple and proper fix (as usual;):
>
> numpy ccompiler.py should check if distutils.msvccompiler is
> imported (via sys.modules). If it is, then set
>
>    distutils.msvccompiler.gen_lib_options = <our gen_lib_options>
>
>   
But is this the only case where setuptools and numpy.distutils rewrite 
some classes ? I am just a bit afraid that modifying runtime objects 
both in numpy.distutils and setuptools will cause other problems in the 
near future (my impression is that it is safe to assume setuptools will 
become part of the standard library in python at some point, and we will 
have to cope with it).

cheers,

David


From pearu at cens.ioc.ee  Wed Sep 26 03:23:46 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 26 Sep 2007 09:23:46 +0200
Subject: [SciPy-dev]
	problems	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <46FA038F.3090106@ar.media.kyoto-u.ac.jp>
References: <46F8B621.3030809@scipy.org>	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>	<20070925155759.GA16728@arbutus.physics.mcmaster.ca>	<53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>	<46F9C462.8080807@ar.media.kyoto-u.ac.jp>	<46F9FFDE.1070207@cens.ioc.ee>
	<46FA038F.3090106@ar.media.kyoto-u.ac.jp>
Message-ID: <46FA0902.7050003@cens.ioc.ee>



David Cournapeau wrote:
> Pearu Peterson wrote:
>> Actually, there exist a simple and proper fix (as usual;):
>>
>> numpy ccompiler.py should check if distutils.msvccompiler is
>> imported (via sys.modules). If it is, then set
>>
>>    distutils.msvccompiler.gen_lib_options = <our gen_lib_options>
>>
>>   
> But is this the only case where setuptools and numpy.distutils rewrite 
> some classes ?

No. gen_lib_options is a function. And numpy.distutils rewrites
several methods in distutils classes. I don't know what setuptools does.

> I am just a bit afraid that modifying runtime objects 
> both in numpy.distutils and setuptools will cause other problems in the 
> near future 

There will be problems for sure and we are fixing them gradually as they
appear - that is a normal process.
Since we as stuck to distutils then we don't have alternatives to
these kind of fixes.

 > (my impression is that it is safe to assume setuptools will
> become part of the standard library in python at some point, and we will 
> have to cope with it).

Note that we are currently supporting python versions starting from 2.3.
I don't know if setuptools is a part of python 2.6 already but
even then we need to keep distutils support until we drop support
for python 2.5. I bet this will not happen in the coming 5 years
at least.

Pearu


From david at ar.media.kyoto-u.ac.jp  Wed Sep 26 04:08:10 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Wed, 26 Sep 2007 17:08:10 +0900
Subject: [SciPy-dev]
	problems	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <46FA0902.7050003@cens.ioc.ee>
References: <46F8B621.3030809@scipy.org>	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>	<20070925155759.GA16728@arbutus.physics.mcmaster.ca>	<53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>	<46F9C462.8080807@ar.media.kyoto-u.ac.jp>	<46F9FFDE.1070207@cens.ioc.ee>	<46FA038F.3090106@ar.media.kyoto-u.ac.jp>
	<46FA0902.7050003@cens.ioc.ee>
Message-ID: <46FA136A.5060904@ar.media.kyoto-u.ac.jp>

Pearu Peterson wrote:
>> I am just a bit afraid that modifying runtime objects 
>> both in numpy.distutils and setuptools will cause other problems in the 
>> near future 
>>     
>
> There will be problems for sure and we are fixing them gradually as they
> appear - that is a normal process.
> Since we as stuck to distutils then we don't have alternatives to
> these kind of fixes.
>   
Isn't it possible to use a subclass instead of modifying the existing one ?
>  > (my impression is that it is safe to assume setuptools will
>   
>> become part of the standard library in python at some point, and we will 
>> have to cope with it).
>>     
>
> Note that we are currently supporting python versions starting from 2.3.
> I don't know if setuptools is a part of python 2.6 already but
> even then we need to keep distutils support until we drop support
> for python 2.5. I bet this will not happen in the coming 5 years
> at least.
>   
Sure, I've never implied to use setuptools only or to stop depending on 
distutils, just that it may be better to avoid modifying distutils on 
the fly when possible to avoid friction with setuptools as much as possible.

cheers,

David


From pearu at cens.ioc.ee  Wed Sep 26 04:29:45 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Wed, 26 Sep 2007 10:29:45 +0200
Subject: [SciPy-dev]
	problems	with	numpy.setuptools("single_version_externally_managed")
In-Reply-To: <46FA136A.5060904@ar.media.kyoto-u.ac.jp>
References: <46F8B621.3030809@scipy.org>	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<55489.85.166.14.172.1190735475.squirrel@cens.ioc.ee>	<20070925155759.GA16728@arbutus.physics.mcmaster.ca>	<53952.85.166.14.172.1190747966.squirrel@cens.ioc.ee>	<46F9C462.8080807@ar.media.kyoto-u.ac.jp>	<46F9FFDE.1070207@cens.ioc.ee>	<46FA038F.3090106@ar.media.kyoto-u.ac.jp>	<46FA0902.7050003@cens.ioc.ee>
	<46FA136A.5060904@ar.media.kyoto-u.ac.jp>
Message-ID: <46FA1879.7000307@cens.ioc.ee>



David Cournapeau wrote:
> Pearu Peterson wrote:
>>> I am just a bit afraid that modifying runtime objects 
>>> both in numpy.distutils and setuptools will cause other problems in the 
>>> near future 
>>>     
>> There will be problems for sure and we are fixing them gradually as they
>> appear - that is a normal process.
>> Since we as stuck to distutils then we don't have alternatives to
>> these kind of fixes.
>>   
> Isn't it possible to use a subclass instead of modifying the existing one ?

It is possible. But in the given case it's not reasonable. Either we 
have few lines of code or we have lots of code replication that needs to
be maintained.

>>  > (my impression is that it is safe to assume setuptools will
>>   
>>> become part of the standard library in python at some point, and we will 
>>> have to cope with it).
>>>     
>> Note that we are currently supporting python versions starting from 2.3.
>> I don't know if setuptools is a part of python 2.6 already but
>> even then we need to keep distutils support until we drop support
>> for python 2.5. I bet this will not happen in the coming 5 years
>> at least.
>>   
> Sure, I've never implied to use setuptools only or to stop depending on 
> distutils, just that it may be better to avoid modifying distutils on 
> the fly when possible to avoid friction with setuptools as much as possible.

I agree on saying that modifying packages on the fly is always hackish 
and should be discoraged. I disagree on prefering setuptools over
distutils for practical reasons. If both setuptools and numpy.distutils
overwrite the same functionality in distutils then these overwrites
should be syncronized.  i guess we need to support building scipy/numpy 
with both sets of tools: setuptools and numpy.distutils.

Pearu


From loredo at astro.cornell.edu  Wed Sep 26 13:52:16 2007
From: loredo at astro.cornell.edu (Tom Loredo)
Date: Wed, 26 Sep 2007 13:52:16 -0400
Subject: [SciPy-dev] SciPy SELinux and import bugs?
Message-ID: <1190829136.46fa9c50acdb8@astrosun2.astro.cornell.edu>


Hi folks-

I've just "upgraded" to RHEL 5 and am going through the chore of
installing a ton of software that I previously used under Fedora,
including Python/NumPy/SciPy.

I've gotten numpy-1.0.3.1 installed (with atlas & fftw) and it passes
all tests.  But with scipy-0.6.0, scipy.test(1,1) gives me an
"Illegal instruction" error, and crashes out of Python.  The first
such error was an SELinux violation due to a text relocation
requirement in _fftpack.so (whatever that means!).  I executed
the "chcon" context change command SELinux suggested as a workaround.
But scipy.test(1,1) still crashes with "Illegal instruction" at
apparently the same place, though now without raising an SELinux
violation (at least, not one that appears in the SELinux troubleshooter).

At this point I thought I'd give the current SVN SciPy (r3369) a try.
It installs fine, but I get an error on import:

>>> import scipy
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.5/site-packages/scipy/__init__.py", line 63, in <module>
    pkgload(verbose=SCIPY_IMPORT_VERBOSE,postpone=True)
  File "/usr/local/lib/python2.5/site-packages/numpy/_import_tools.py", line 177, in __call__
    self._init_info_modules(packages or None)
  File "/usr/local/lib/python2.5/site-packages/numpy/_import_tools.py", line 100, in _init_info_modules
    self._init_info_modules(getattr(info_module,'depends',[]))
  File "/usr/local/lib/python2.5/site-packages/numpy/_import_tools.py", line 72, in _init_info_modules
    exec 'import %s.info as info' % (package_name)
  File "<string>", line 1, in <module>
  File "/home/inference/loredo/python/scripts/special.py", line 97, in <module>
    def factrl(n, ntop=0, prev=N.ones((33),N.Float)):
AttributeError: 'module' object has no attribute 'Float'

It is finding an old script of mine that happens to be named "special"
that I haven't used and thus haven't upgraded from Numeric to NumPy.
But that's beside the point---I think it must be a bug that SciPy's
import mechanism is finding it.

Any suggestions for dealing with either issue (Illegal instruction
with 0.6.0, or the import issue for r3369) would be appreciated!

-Tom Loredo

PS:  Regarding the text relocation issue in _fftpack.so, SELinux 
points to this web page for hints on how to fix it:

http://people.redhat.com/drepper/selinux-mem.html


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


From ollinger at wisc.edu  Wed Sep 26 14:11:20 2007
From: ollinger at wisc.edu (John Ollinger)
Date: Wed, 26 Sep 2007 13:11:20 -0500
Subject: [SciPy-dev] SciPy SELinux and import bugs?
In-Reply-To: <1190829136.46fa9c50acdb8@astrosun2.astro.cornell.edu>
References: <1190829136.46fa9c50acdb8@astrosun2.astro.cornell.edu>
Message-ID: <5b9ba9310709261111u5e3df62q1f44b561c5ae8202@mail.gmail.com>

Hi,

I ran into the same problem.  You will have to change the context on every
shared library in the distribution.  You can either disable this secure
linux feature or use the chcon command.  I realize that the syntax of the
command is obvious, but here is the alias I use anyway.

function selinux_chcon() { find $* -name "*.so*" -exec chcon -t
texrel_shlib_t \{\} \;  ;}

John

On 9/26/07, Tom Loredo <loredo at astro.cornell.edu> wrote:
>
>
> Hi folks-
>
> I've just "upgraded" to RHEL 5 and am going through the chore of
> installing a ton of software that I previously used under Fedora,
> including Python/NumPy/SciPy.
>
> I've gotten numpy-1.0.3.1 installed (with atlas & fftw) and it passes
> all tests.  But with scipy-0.6.0, scipy.test(1,1) gives me an
> "Illegal instruction" error, and crashes out of Python.  The first
> such error was an SELinux violation due to a text relocation
> requirement in _fftpack.so (whatever that means!).  I executed
> the "chcon" context change command SELinux suggested as a workaround.
> But scipy.test(1,1) still crashes with "Illegal instruction" at
> apparently the same place, though now without raising an SELinux
> violation (at least, not one that appears in the SELinux troubleshooter).
>
> At this point I thought I'd give the current SVN SciPy (r3369) a try.
> It installs fine, but I get an error on import:
>
> >>> import scipy
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "/usr/local/lib/python2.5/site-packages/scipy/__init__.py", line
> 63, in <module>
>     pkgload(verbose=SCIPY_IMPORT_VERBOSE,postpone=True)
>   File "/usr/local/lib/python2.5/site-packages/numpy/_import_tools.py",
> line 177, in __call__
>     self._init_info_modules(packages or None)
>   File "/usr/local/lib/python2.5/site-packages/numpy/_import_tools.py",
> line 100, in _init_info_modules
>     self._init_info_modules(getattr(info_module,'depends',[]))
>   File "/usr/local/lib/python2.5/site-packages/numpy/_import_tools.py",
> line 72, in _init_info_modules
>     exec 'import %s.info as info' % (package_name)
>   File "<string>", line 1, in <module>
>   File "/home/inference/loredo/python/scripts/special.py", line 97, in
> <module>
>     def factrl(n, ntop=0, prev=N.ones((33),N.Float)):
> AttributeError: 'module' object has no attribute 'Float'
>
> It is finding an old script of mine that happens to be named "special"
> that I haven't used and thus haven't upgraded from Numeric to NumPy.
> But that's beside the point---I think it must be a bug that SciPy's
> import mechanism is finding it.
>
> Any suggestions for dealing with either issue (Illegal instruction
> with 0.6.0, or the import issue for r3369) would be appreciated!
>
> -Tom Loredo
>
> PS:  Regarding the text relocation issue in _fftpack.so, SELinux
> points to this web page for hints on how to fix it:
>
> http://people.redhat.com/drepper/selinux-mem.html
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>



-- 
John Ollinger
University of Wisconsin
Waisman Center, T233
1500 Highland Ave
Madison, WI 53711
http://brainimaging.waisman.wisc.edu/~jjo/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070926/f4b2b112/attachment.html>

From loredo at astro.cornell.edu  Wed Sep 26 16:06:49 2007
From: loredo at astro.cornell.edu (Tom Loredo)
Date: Wed, 26 Sep 2007 16:06:49 -0400
Subject: [SciPy-dev] Illegal instruction in ndimage test
Message-ID: <1190837209.46fabbd97850a@astrosun2.astro.cornell.edu>


Hi folks-

My thanks to John Ollinger for the global context change to address
SELinux issues.  But it turns out that wasn't the cause of the
"Illegal instruction" crash I was getting, as far as I can tell.
The SELinux warning appears before scipy.test(1,1) crashes, and
the crash continues to happen at the same place even after the
context change (and even if I turn off text relocation protection
in SELinux).

Running scipy.test(1,10) helps pin down what's crashing:

[snip]
gaussian filter 6 ... ok
gaussian gradient magnitude filter 1 ... ok
gaussian gradient magnitude filter 2 ... ok
gaussian laplace filter 1 ... ok
gaussian laplace filter 2 ... ok
generation of a binary structure 1 ... ok
generation of a binary structure 2 ... ok
generation of a binary structure 3 ... ok
generation of a binary structure 4 ... ok
generic filter 1Illegal instruction

Hunting around, I found the offending test in ndimage/tests.  If
I rename this directory (so the tests are skipped), the tests
proceed without crashing.

I'd appreciate any advice on how to diagnose this problem (I don't
use ndimage), or how to provide sufficient info on Trac to
guide a bug fix if this is a bug.

-Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


From loredo at astro.cornell.edu  Wed Sep 26 16:22:48 2007
From: loredo at astro.cornell.edu (Tom Loredo)
Date: Wed, 26 Sep 2007 16:22:48 -0400
Subject: [SciPy-dev] Cannot import flapack, but it's there
Message-ID: <1190838168.46fabf9842c4c@astrosun2.astro.cornell.edu>


Hi again-

This is with RHEL 5, Python 2.5.1, gcc 4.2.1, numpy 1.0.3.1,
atlas 3.7.37.

I've installed scipy 0.6.0.  As noted in another post, an ndimage
test causes a crash, so I've diabled it and continued.  Now
scipy.test(1,10) raises an import error:

test1 (scipy.special.tests.test_spfun_stats.test_multigammaln) ... ok
test_ararg (scipy.special.tests.test_spfun_stats.test_multigammaln) ... ok
test_bararg (scipy.special.tests.test_spfun_stats.test_multigammaln) ... ok

======================================================================
ERROR: check_integer (scipy.io.tests.test_array_import.test_read_array)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/scipy/io/tests/test_array_import.py", line 55, in check_integer
    from scipy import stats
  File "/usr/local/lib/python2.5/site-packages/scipy/stats/__init__.py", line 7, in <module>
    from stats import *
  File "/usr/local/lib/python2.5/site-packages/scipy/stats/stats.py", line 192, in <module>
    import scipy.linalg as linalg
  File "/usr/local/lib/python2.5/site-packages/scipy/linalg/__init__.py", line 8, in <module>
    from basic import *
  File "/usr/local/lib/python2.5/site-packages/scipy/linalg/basic.py", line 17, in <module>
    from lapack import get_lapack_funcs
  File "/usr/local/lib/python2.5/site-packages/scipy/linalg/lapack.py", line 17, in <module>
    from scipy.linalg import flapack
ImportError: cannot import name flapack

----------------------------------------------------------------------
Ran 787 tests in 5.310s

FAILED (errors=1)

But if I go into site-packages/scipy/linalg, start python and
try "import flapack" there is no error (there is indeed an
flapack.so file there).

A colleague trying an independent install of scipy 0.6.0 on a
FC4 machine also has the tests fail at this point, though in
her case she also gets "undefined symbol: isamax_".  This makes
me wonder if there may be a bug underlying this.

Any help on diagnosing/fixing would be appreciated!

-Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


From millman at berkeley.edu  Wed Sep 26 17:09:08 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Wed, 26 Sep 2007 14:09:08 -0700
Subject: [SciPy-dev] Cannot import flapack, but it's there
In-Reply-To: <1190838168.46fabf9842c4c@astrosun2.astro.cornell.edu>
References: <1190838168.46fabf9842c4c@astrosun2.astro.cornell.edu>
Message-ID: <c7009a550709261409s41543ebau3d37f7aff6272987@mail.gmail.com>

Hey Tom,

Could you try deleting the scipy directory and then re-installing it?
rm -rf /usr/local/lib/python2.5/site-packages/scipy

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From loredo at astro.cornell.edu  Wed Sep 26 18:12:11 2007
From: loredo at astro.cornell.edu (Tom Loredo)
Date: Wed, 26 Sep 2007 18:12:11 -0400
Subject: [SciPy-dev] Cannot import flapack, but it's there
Message-ID: <1190844731.46fad93bcb91c@astrosun2.astro.cornell.edu>


Hi Jarrod-

Thanks for the suggestion:

> Could you try deleting the scipy directory and then re-installing it?
> rm -rf /usr/local/lib/python2.5/site-packages/scipy

I also deleted the scipy-0.6.0-py2.5.egg-info that gets automatically
created (presumably by setuptools).

No change---the Illegal instruction crash from the ndimage test, and
if I disable that, the flapack ImportError.

-Tom


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


From stefan at sun.ac.za  Wed Sep 26 18:11:07 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 27 Sep 2007 00:11:07 +0200
Subject: [SciPy-dev] Illegal instruction in ndimage test
In-Reply-To: <1190837209.46fabbd97850a@astrosun2.astro.cornell.edu>
References: <1190837209.46fabbd97850a@astrosun2.astro.cornell.edu>
Message-ID: <20070926221107.GH32704@mentat.za.net>

On Wed, Sep 26, 2007 at 04:06:49PM -0400, Tom Loredo wrote:
> 
> Hi folks-
> 
> My thanks to John Ollinger for the global context change to address
> SELinux issues.  But it turns out that wasn't the cause of the
> "Illegal instruction" crash I was getting, as far as I can tell.
> The SELinux warning appears before scipy.test(1,1) crashes, and
> the crash continues to happen at the same place even after the
> context change (and even if I turn off text relocation protection
> in SELinux).
> 
> Running scipy.test(1,10) helps pin down what's crashing:
> 
> [snip]
> gaussian filter 6 ... ok
> gaussian gradient magnitude filter 1 ... ok
> gaussian gradient magnitude filter 2 ... ok
> gaussian laplace filter 1 ... ok
> gaussian laplace filter 2 ... ok
> generation of a binary structure 1 ... ok
> generation of a binary structure 2 ... ok
> generation of a binary structure 3 ... ok
> generation of a binary structure 4 ... ok
> generic filter 1Illegal instruction
> 
> Hunting around, I found the offending test in ndimage/tests.  If
> I rename this directory (so the tests are skipped), the tests
> proceed without crashing.

This looks like

http://projects.scipy.org/scipy/scipy/ticket/404

I'd be grateful if you can help me narrow it down.

Cheers
St?fan


From loredo at astro.cornell.edu  Thu Sep 27 14:11:04 2007
From: loredo at astro.cornell.edu (Tom Loredo)
Date: Thu, 27 Sep 2007 14:11:04 -0400
Subject: [SciPy-dev] Strange scipy.test crashes on OS X/Intel
Message-ID: <1190916664.46fbf238ee178@astrosun2.astro.cornell.edu>


Hi folks-

With the problems I've been having with scipy-0.6.0 on RHEL 5, and my
colleague with it on FC4, I experimented with it on my OS X machines.

MacBook (Intel), OS 10.4, Python 2.5.1, numpy 1.0.3.1:

Running scipy.test() the 1st time completed 1719 tests and reported 5
failures:

FAIL: check_cosine_weighted_infinite (scipy.integrate.tests.test_quadpack.test_quad)
FAIL: check_sine_weighted_finite (scipy.integrate.tests.test_quadpack.test_quad)
FAIL: check_sine_weighted_infinite (scipy.integrate.tests.test_quadpack.test_quad)
FAIL: check_dot (scipy.lib.tests.test_blas.test_fblas1_simple)
FAIL: check_x_stride (scipy.lib.blas.tests.test_fblas.test_cgemv)

I ran it again (in the same Python invocation) and got 4 of the 5 failures
(all but check_x_stride).

I ran it a third time, and it crashed with a seg fault:

    Found 42 tests for scipy.lib.lapack
    Found 41 tests for scipy.linalg.basic
  <module 'scipy.linalg.fblas' from  
  '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/linalg/fblas.so'>
  Segmentation fault

The seg fault was 100% repeatable:  Every time I ran scipy.test() a 3rd
time, I got the same seg fault.

I deleted all scipy stuff from site-packages, and tried this again with
scipy 0.5.2.1.  Different tests failed.  I got bus errors or seg faults,
but inconsistently, after 3-5 runs of scipy.test(), and at different
places in the tests (but typically soon after the tests started, i.e.,
after just a few "..." lines).

I removed scipy stuff, and reinstalled 0.6.0.  This time I could run
scipy.test() 9 times before getting a bus error on the 10th run.
Subsequent Python invocations led to bus errors or seg faults sooner
and sooner, until the original behavior was duplicated:  seg fault
on the 3rd run of scipy.test(), always here:

    Found 41 tests for scipy.linalg.basic
  <module 'scipy.linalg.fblas' from  
  '/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/scipy/linalg/fblas.so'>
  Segmentation fault

Subsequently, I always get the same crash on the 3rd run of scipy.test().


I tried similar tests on my G4 (PPC) desktop, OS 10.4, same numpy, but with an
older Python (2.4.4) and scipy 0.5.2.1.  I ran scipy.test() a dozen times
with no problems apart from the 3 failures and 9 errors I've always gotten.


I realize this is inconclusive, as the problem could be with Python 2.5.1 or
gfortran or scipy, but I wanted to report it.  It seems a notable coincidence
that linalg seems involved in the crashes, since it is also giving me problems
on RHEL 5, and my colleague on FC4.

If there is anything further I can do to help diagnose these issues, please
advise.

Thanks,
Tom



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/


From robert.kern at gmail.com  Thu Sep 27 14:24:25 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 27 Sep 2007 13:24:25 -0500
Subject: [SciPy-dev] Strange scipy.test crashes on OS X/Intel
In-Reply-To: <1190916664.46fbf238ee178@astrosun2.astro.cornell.edu>
References: <1190916664.46fbf238ee178@astrosun2.astro.cornell.edu>
Message-ID: <46FBF559.4060302@gmail.com>

Tom Loredo wrote:

> If there is anything further I can do to help diagnose these issues, please
> advise.

Can you run it in gdb and give us the backtrace?

$ gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
libraries .. done

(gdb) run -c "import scipy; scipy.test(10,10)"
Starting program: /usr/local/bin/python -c "import scipy; scipy.test()"
Reading symbols for shared libraries . done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe01010 in __dyld__dyld_start ()
(gdb) c
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
...


Then use the "bt" command after the segfault happens to get the backtrace.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From perry at stsci.edu  Thu Sep 27 17:40:50 2007
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 27 Sep 2007 17:40:50 -0400
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <m2sl524uo1.fsf@saturn.dmc>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
Message-ID: <FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>


On Sep 25, 2007, at 11:43 AM, David M. Cooke wrote:

> "Pearu Peterson" <pearu at cens.ioc.ee> writes:
>> On Tue, September 25, 2007 5:57 pm, David M. Cooke wrote:
>>>
>>> $ python setupegg.py bdist_egg
>>> Running from numpy source directory.
>>> ********************************************************
>>> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>>> [etc.]
>>
>>
>> This is a warning message. It does not break code.
>
> When a supported method of building throws up a huge warning, I
> consider that broken ;-)

Let me echo this. I'm not sure what all the recent discussion on the  
fixes has left this particular issue but I think there needs to be  
some way to deal with this (either a way to suppress the message or  
handle things differently). This kind of warning is not going to be  
helpful to those that download software that uses numpy. They won't  
know what it means and won't know what to do about it.

Perry Greenfield


From david at ar.media.kyoto-u.ac.jp  Thu Sep 27 22:34:54 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 28 Sep 2007 11:34:54 +0900
Subject: [SciPy-dev] Strange scipy.test crashes on OS X/Intel
In-Reply-To: <46FBF559.4060302@gmail.com>
References: <1190916664.46fbf238ee178@astrosun2.astro.cornell.edu>
	<46FBF559.4060302@gmail.com>
Message-ID: <46FC684E.6090308@ar.media.kyoto-u.ac.jp>

Robert Kern wrote:
> Tom Loredo wrote:
>
>   
>> If there is anything further I can do to help diagnose these issues, please
>> advise.
>>     
>
> Can you run it in gdb and give us the backtrace?
>
> $ gdb python
> GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:50:43 GMT 2006)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-apple-darwin"...Reading symbols for shared
> libraries .. done
>
> (gdb) run -c "import scipy; scipy.test(10,10)"
> Starting program: /usr/local/bin/python -c "import scipy; scipy.test()"
> Reading symbols for shared libraries . done
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x8fe01010 in __dyld__dyld_start ()
> (gdb) c
> Continuing.
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> ...
>
>
> Then use the "bt" command after the segfault happens to get the backtrace.
>
>   
I don't think there is a need for gdb, the error is again in the 
check_dot: the dot function when using apple vecLib framework does not 
work. I tried to fix it in scipy.linalg, but the code is duplicated in 
scipy.lib, and I didn't make the modification there.

My understanding, but Pearu should confirm this since I am not involved 
at all with this code, is that scipy.lib is a refactoring of the core of 
scipy.linalg; as such, maybe the module can be disabled at the test 
level ? scipy.lib is not used anywhere else in scipy, and people should 
use scipy.linalg, no ? This is a mere suggestion, maybe someone else has 
a better idea ?

cheers,

David


From david at ar.media.kyoto-u.ac.jp  Thu Sep 27 22:59:16 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Fri, 28 Sep 2007 11:59:16 +0900
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
References: <46F8B621.3030809@scipy.org>
	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>
	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
Message-ID: <46FC6E04.6010302@ar.media.kyoto-u.ac.jp>

Perry Greenfield wrote:
> On Sep 25, 2007, at 11:43 AM, David M. Cooke wrote:
>
>   
>> "Pearu Peterson" <pearu at cens.ioc.ee> writes:
>>     
>>> On Tue, September 25, 2007 5:57 pm, David M. Cooke wrote:
>>>       
>>>> $ python setupegg.py bdist_egg
>>>> Running from numpy source directory.
>>>> ********************************************************
>>>> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>>>> [etc.]
>>>>         
>>> This is a warning message. It does not break code.
>>>       
>> When a supported method of building throws up a huge warning, I
>> consider that broken ;-)
>>     
>
> Let me echo this. I'm not sure what all the recent discussion on the  
> fixes has left this particular issue but I think there needs to be  
> some way to deal with this (either a way to suppress the message or  
> handle things differently). This kind of warning is not going to be  
> helpful to those that download software that uses numpy. They won't  
> know what it means and won't know what to do about it.
>   
While I agree with you, AFAIK, this appears only in svn. If you download 
from svn, you are accepting the higher possibility of something being 
broken, in my opinion.

David


From robert.kern at gmail.com  Thu Sep 27 23:19:53 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 27 Sep 2007 22:19:53 -0500
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <46FC6E04.6010302@ar.media.kyoto-u.ac.jp>
References: <46F8B621.3030809@scipy.org>	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp>
Message-ID: <46FC72D9.5030207@gmail.com>

David Cournapeau wrote:
> Perry Greenfield wrote:
>> On Sep 25, 2007, at 11:43 AM, David M. Cooke wrote:
>>
>>   
>>> "Pearu Peterson" <pearu at cens.ioc.ee> writes:
>>>     
>>>> On Tue, September 25, 2007 5:57 pm, David M. Cooke wrote:
>>>>       
>>>>> $ python setupegg.py bdist_egg
>>>>> Running from numpy source directory.
>>>>> ********************************************************
>>>>> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>>>>> [etc.]
>>>>>         
>>>> This is a warning message. It does not break code.
>>>>       
>>> When a supported method of building throws up a huge warning, I
>>> consider that broken ;-)
>>>     
>> Let me echo this. I'm not sure what all the recent discussion on the  
>> fixes has left this particular issue but I think there needs to be  
>> some way to deal with this (either a way to suppress the message or  
>> handle things differently). This kind of warning is not going to be  
>> helpful to those that download software that uses numpy. They won't  
>> know what it means and won't know what to do about it.
>>   
> While I agree with you, AFAIK, this appears only in svn. If you download 
> from svn, you are accepting the higher possibility of something being 
> broken, in my opinion.

Well yes, but eventually we will cut a release. If we don't think the warning
should be in the release, we should remove it from SVN.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco


From pearu at cens.ioc.ee  Fri Sep 28 03:26:53 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Fri, 28 Sep 2007 09:26:53 +0200
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <46FC72D9.5030207@gmail.com>
References: <46F8B621.3030809@scipy.org>	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp>
	<46FC72D9.5030207@gmail.com>
Message-ID: <46FCACBD.4080802@cens.ioc.ee>


Robert Kern wrote:
> David Cournapeau wrote:
>> Perry Greenfield wrote:
>>> On Sep 25, 2007, at 11:43 AM, David M. Cooke wrote:
>>>
>>>   
>>>> "Pearu Peterson" <pearu at cens.ioc.ee> writes:
>>>>     
>>>>> On Tue, September 25, 2007 5:57 pm, David M. Cooke wrote:
>>>>>       
>>>>>> $ python setupegg.py bdist_egg
>>>>>> Running from numpy source directory.
>>>>>> ********************************************************
>>>>>> WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!WARNING!
>>>>>> [etc.]
>>>>>>         
>>>>> This is a warning message. It does not break code.
>>>>>       
>>>> When a supported method of building throws up a huge warning, I
>>>> consider that broken ;-)
>>>>     
>>> Let me echo this. I'm not sure what all the recent discussion on the  
>>> fixes has left this particular issue but I think there needs to be  
>>> some way to deal with this (either a way to suppress the message or  
>>> handle things differently). This kind of warning is not going to be  
>>> helpful to those that download software that uses numpy. They won't  
>>> know what it means and won't know what to do about it.
>>>   
>> While I agree with you, AFAIK, this appears only in svn. If you download 
>> from svn, you are accepting the higher possibility of something being 
>> broken, in my opinion.
> 
> Well yes, but eventually we will cut a release. If we don't think the warning
> should be in the release, we should remove it from SVN.

I think issuing such warnings is useful for developers as
quite often one writes a code into a big system without being
able to test the code with all practical corner cases.
numpy.distutils is an example.

So, this kind of a warning is like a mild assertion failure
that should draw other developers attention that the code
might do (or not do) something that is different what they
have assumed. But the code will still run. If nobody will see
the warning, then the new code is (may be) safe. If other developers
see the warning then that means that they should work together
to remove the cause of possible issues from the start.

Given issue is a prefect example of this kind of situation
that captures possible problems in the development state
rather than from users feedback that may have very long
time span.

I think we should practice this kind of warnings more often.

When making a release, such warnings should be disabled
(read: removed when the issue is resolved).

Pearu


From nwagner at iam.uni-stuttgart.de  Fri Sep 28 13:06:45 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 28 Sep 2007 19:06:45 +0200
Subject: [SciPy-dev] Sandbox package multigrid
Message-ID: <web-89980295@uni-stuttgart.de>

Nathan,

Please can you add the missing file "torus.mtx.gz".
Thanks in advance.

Cheers,
            Nils



python -i 
/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/test_coarsen.py
   Found 8/8 tests for __main__
...E....
======================================================================
ERROR: check_sample_data 
(__main__.test_sa_constant_interpolation)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/test_coarsen.py", 
line 153, in check_sample_data
     A = read_matrix(filename)
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/examples.py", 
line 8, in read_matrix
     fid = gzip.open(filename)
   File "/usr/lib64/python2.5/gzip.py", line 49, in open
     return GzipFile(filename, mode, compresslevel)
   File "/usr/lib64/python2.5/gzip.py", line 95, in 
__init__
     fileobj = self.myfileobj = __builtin__.open(filename, 
mode or 'rb')
IOError: [Errno 2] No such file or directory: 
'sample_data/torus.mtx.gz'

----------------------------------------------------------------------
Ran 8 tests in 8.699s

FAILED (errors=1)

status
  


From stefan at sun.ac.za  Fri Sep 28 16:40:54 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Fri, 28 Sep 2007 22:40:54 +0200
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <46FCACBD.4080802@cens.ioc.ee>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp>
	<46FC72D9.5030207@gmail.com> <46FCACBD.4080802@cens.ioc.ee>
Message-ID: <20070928204053.GC32704@mentat.za.net>

On Fri, Sep 28, 2007 at 09:26:53AM +0200, Pearu Peterson wrote:
> > should be in the release, we should remove it from SVN.
> 
> I think issuing such warnings is useful for developers as
> quite often one writes a code into a big system without being
> able to test the code with all practical corner cases.
> numpy.distutils is an example.
> 
> So, this kind of a warning is like a mild assertion failure
> that should draw other developers attention that the code
> might do (or not do) something that is different what they
> have assumed. But the code will still run. If nobody will see
> the warning, then the new code is (may be) safe. If other developers
> see the warning then that means that they should work together
> to remove the cause of possible issues from the start.
> 
> Given issue is a prefect example of this kind of situation
> that captures possible problems in the development state
> rather than from users feedback that may have very long
> time span.
> 
> I think we should practice this kind of warnings more often.
> 
> When making a release, such warnings should be disabled
> (read: removed when the issue is resolved).

I would prefer if numpy were *always* in a release-ready state.  Why
can't we instrument tests for distutils?  If the code is so confusing
that we can't test it (or "practical corner cases"), should we be
using it as a core ingredient in the first place?

David's idea of using scons to build everything sounds more appealing
by the day.  Distutils can still do the packaging, but at least we
would have a modularised, testable, no-hassles build environment.

St?fan


From wnbell at gmail.com  Fri Sep 28 17:01:36 2007
From: wnbell at gmail.com (Nathan Bell)
Date: Fri, 28 Sep 2007 16:01:36 -0500
Subject: [SciPy-dev] Sandbox package multigrid
In-Reply-To: <web-89980295@uni-stuttgart.de>
References: <web-89980295@uni-stuttgart.de>
Message-ID: <d05265cb0709281401y4073f1a2hf14cdd10a8c6198a@mail.gmail.com>

On 9/28/07, Nils Wagner <nwagner at iam.uni-stuttgart.de> wrote:
> Nathan,
>
> Please can you add the missing file "torus.mtx.gz".
> Thanks in advance.

It should work now, I've disabled the test cases that rely on other files.

-- 
Nathan Bell wnbell at gmail.com


From pearu at cens.ioc.ee  Fri Sep 28 17:15:23 2007
From: pearu at cens.ioc.ee (Pearu Peterson)
Date: Sat, 29 Sep 2007 00:15:23 +0300 (EEST)
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <20070928204053.GC32704@mentat.za.net>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp> <46FC72D9.5030207@gmail.com>
	<46FCACBD.4080802@cens.ioc.ee> <20070928204053.GC32704@mentat.za.net>
Message-ID: <54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>

On Fri, September 28, 2007 11:40 pm, Stefan van der Walt wrote:
>
> I would prefer if numpy were *always* in a release-ready state.

Most of the time it actually is.

> Why can't we instrument tests for distutils?  If the code is so confusing
> that we can't test it (or "practical corner cases"), should we be
> using it as a core ingredient in the first place?

The code is not so confusing - it has well-defined (though undocumented)
structure that can be extended after one gets an idea how things
work in distutils.

The variety of different compilers and platforms makes developing
distutils difficult. I guess none of the developers who dare to
touch distutils have access to all platforms and compilers that
we are trying to support. This fact will not change after switching
to some other tool such as scons.

We actually have tests for distutils - see buildbot.scipy.org.

> David's idea of using scons to build everything sounds more appealing
> by the day.  Distutils can still do the packaging, but at least we
> would have a modularised, testable, no-hassles build environment.

You obviously have little idea what does it mean to replace
numpy.distutils with some other building tool;) Let this to be
a challenge to work this out for anyone.

Pearu



From nwagner at iam.uni-stuttgart.de  Fri Sep 28 17:17:46 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 28 Sep 2007 23:17:46 +0200
Subject: [SciPy-dev] multigrid
Message-ID: <web-89986498@uni-stuttgart.de>

Hi Nathan,

Thank you very much for your prompt reply.
test_coarsen.py works fine for me with latest svn

python -i 
/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/test_coarsen.py
   Found 7/7 tests for __main__
.......
----------------------------------------------------------------------
Ran 7 tests in 8.015s

OK
>>>

but

python -i 
/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/examples.py
All Available Examples Are Listed Below

torus.mtx.gz
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/examples.py", 
line 25, in <module>
     print repr(read_matrix(filename))
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/examples.py", 
line 8, in read_matrix
     fid = gzip.open(filename)
   File "/usr/lib64/python2.5/gzip.py", line 49, in open
     return GzipFile(filename, mode, compresslevel)
   File "/usr/lib64/python2.5/gzip.py", line 95, in 
__init__
     fileobj = self.myfileobj = __builtin__.open(filename, 
mode or 'rb')
IOError: [Errno 2] No such file or directory: 
'sample_data/torus.mtx.gz'
  

Best wishes

                 Nils


From david at ar.media.kyoto-u.ac.jp  Fri Sep 28 23:49:53 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 29 Sep 2007 12:49:53 +0900
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <20070928204053.GC32704@mentat.za.net>
References: <46F8B621.3030809@scipy.org>
	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp>	<46FC72D9.5030207@gmail.com>
	<46FCACBD.4080802@cens.ioc.ee>
	<20070928204053.GC32704@mentat.za.net>
Message-ID: <46FDCB61.60808@ar.media.kyoto-u.ac.jp>

Stefan van der Walt wrote:
> On Fri, Sep 28, 2007 at 09:26:53AM +0200, Pearu Peterson wrote:
>>> should be in the release, we should remove it from SVN.
>> I think issuing such warnings is useful for developers as
>> quite often one writes a code into a big system without being
>> able to test the code with all practical corner cases.
>> numpy.distutils is an example.
>>
>> So, this kind of a warning is like a mild assertion failure
>> that should draw other developers attention that the code
>> might do (or not do) something that is different what they
>> have assumed. But the code will still run. If nobody will see
>> the warning, then the new code is (may be) safe. If other developers
>> see the warning then that means that they should work together
>> to remove the cause of possible issues from the start.
>>
>> Given issue is a prefect example of this kind of situation
>> that captures possible problems in the development state
>> rather than from users feedback that may have very long
>> time span.
>>
>> I think we should practice this kind of warnings more often.
>>
>> When making a release, such warnings should be disabled
>> (read: removed when the issue is resolved).
>
> I would prefer if numpy were *always* in a release-ready state.  Why
> can't we instrument tests for distutils?  If the code is so confusing
> that we can't test it (or "practical corner cases"), should we be
> using it as a core ingredient in the first place?
I think part of this issue is related to the source control system we 
are using. My impression is that with the current system, having always 
something at least buildable in the trunk and usable is preferable; with 
a better source constrol system, we would not have such a problem, or at 
least would make the problem less pervasive (we would not need to work 
directly in the trunk so often).

Now, concerning the build tool itself: testing build tools is inherently 
difficult; This is similar to why cross compilation is inherently 
difficult: the platform to build the build tool and the platform to test 
it are different. Replacing "everything" with scons (or any other tool) 
is non trivial, and will take some time. I think it worths it, because 
IMHO, distutils has fundamental design flaw wrt our needs in numpy/scipy 
(see my answer to Pearu in the same thread).


David


From david at ar.media.kyoto-u.ac.jp  Sat Sep 29 00:43:27 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sat, 29 Sep 2007 13:43:27 +0900
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>
References: <46F8B621.3030809@scipy.org>
	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp>
	<46FC72D9.5030207@gmail.com>	<46FCACBD.4080802@cens.ioc.ee>
	<20070928204053.GC32704@mentat.za.net>
	<54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>
Message-ID: <46FDD7EF.4050300@ar.media.kyoto-u.ac.jp>

Pearu Peterson wrote:
> On Fri, September 28, 2007 11:40 pm, Stefan van der Walt wrote:
>> I would prefer if numpy were *always* in a release-ready state.
>
> Most of the time it actually is.
>
>> Why can't we instrument tests for distutils?  If the code is so confusing
>> that we can't test it (or "practical corner cases"), should we be
>> using it as a core ingredient in the first place?
>
> The code is not so confusing - it has well-defined (though undocumented)
> structure that can be extended after one gets an idea how things
> work in distutils.
>
Before I start to make my points, and because I feel this discussion is 
heating a bit, let me say that I never intend to criticize any numpy's 
developers work/code. I understand that distutils is complicated to 
extend, that numpy's needs go far beyond the usual needs of python 
package, and I really think that numpy.distutils has already achieved 
quite a lot. All other impressions are surely du to the fact that 
English is not my native language :)

Now, although I certainly do not have as much experience as you with 
distutils, I have used autotools for non trivial projects, I have used 
scons as well, and I have some experience with complicated gnu make 
based projects (eg my numpy.gar script which can builds numpy and all 
its dependencies in different configuration/compilers on linux/unix). 
This is not to say I am knowledgeable, but at least I think I am aware 
of the difficulties of a cross platform build system.

> The variety of different compilers and platforms makes developing
> distutils difficult. I guess none of the developers who dare to
> touch distutils have access to all platforms and compilers that
> we are trying to support. This fact will not change after switching
> to some other tool such as scons.
That's where I think we fundamentally disagree. I for one think 
distutils (here I mean the official, python.distutils, and only to build 
C/Fortran extensions; I will never talk about any other capabilities of 
distutils) is fundamentally flawed wrt to several key points, and I am 
not even talking about its implementation. Since you are much more 
familiar with distutils than me, I would really appreciate being told wrong:
     1 - the way it tries to detect the platform capability. When you 
try to adapt to a platform in a build tool, you have at least two 
possibilities: either you hardcode every new platform, or you try to get 
the information from the platform. Distutils does the former, autoconf 
does the latter. For me, there is absolutely no question which one is 
better in this respect. This alone explains a lot of distutils fragility 
IMHO. For example, numpy.distutils define the "f2c" library for each new 
tool, but autoconf (more explicitely, the autoconf macro 
AC_F77_LIBRARY_LDFLAGS) finds it automatically from compiler output.  
This is a fundamental point, maybe the only most important one.
    2 - numpy.distutils is difficult to extend. This, I think we all 
agree. This is also significant, because it means that when 
numpy.distutils fails, only a few people can change the situation. This 
should not be the case. If the problem is one compiler flag, it should 
not require anyone's involvement but the ones who experience the problem.
    3 - Customizing compilation options: this is extremely difficult 
right now, and this again by design.
    4 - Detecting libraries is extremely difficult: the first time I 
used system_info, it was totally wrong, and I had to modify it for each 
new platform. This is not good: I needed more time to make it right than 
I ever did for autotools based projects of mine, which really says a lot 
in my book.
    5 - By design, scons does not depend on the environment. That is, it 
does NOT use PATH information, LD_LIBRARY_FLAGS, etc... which again 
makes it much more reliable. Of course, you can add command line 
arguments for configuration, but by default, nothing will stab you in 
the back.

Now, you would rightly argue that doing all this in scons/whatever would 
take a lot of time just to replicate distutils, and you would be right. 
But I think it would require *less* time than implementing the things 
stated eg in http://projects.scipy.org/scipy/numpy/wiki/DistutilsRevamp.

But I don't ask you to take my word on it: I am more than willing to 
code a prototype of what I have in mind. But then, I need to know what 
is required for a prototype, to make a plan of what needs to be implemented:
    - Is a prototype required to support all platforms supported now ?
    - Is a prototype which can build numpy on Mac OS X/Linux/Win32 
enough (keeping in mind that the key point is that adding new platforms 
would be much easier once the prototype is done). In which configuration ?
    - If required, I could try to make it possible to have two top setup 
scripts, one which uses the current distutils, one which use the 
scons-based one.

As said earlier, I have started hacking on a numpy branch which, right now:
    - implements a scons command
    - a support library, which enables to build/run ctypes extensions 
working on many platforms (all the one I managed to use on the buildbot)
    - a support library to find libraries and headers in standard 
location on all supported platforms by scons (of which numpy.distutils 
is a subset AFAIK), and can be customized using site.cfg.

One problem I did not foresee is how difficult it is to be sure that 
scons uses exactly the same tools than distutils (because distutils has 
no common api to get things such as compiler, compiler path, etc...); 
that's why contrary to what I thought first, using scons to build all 
the compiled extension may actually be easier than making them coexist, 
because scons and distutils have fundamentally different ways of looking 
for tools.

To start building numpy itself with it would require more work (mostly 
tests for fortran / C abi), but with the help of people willing to help, 
I don't see major problems on this side, since scons provide a framework 
for autoconf-like testing. Also, this will certainly use some facilities 
of numpy.distutils (basically, for a first prototype, scons would mostly 
replace system_info.py, command/build_clib.py, command/build_ext.py).

Does it sound like an acceptable plan to you ?

David


From stefan at sun.ac.za  Sat Sep 29 08:56:43 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Sat, 29 Sep 2007 14:56:43 +0200
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp>
	<46FC72D9.5030207@gmail.com> <46FCACBD.4080802@cens.ioc.ee>
	<20070928204053.GC32704@mentat.za.net>
	<54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>
Message-ID: <20070929125643.GF32704@mentat.za.net>

Hi Pearu

On Sat, Sep 29, 2007 at 12:15:23AM +0300, Pearu Peterson wrote:
> > Why can't we instrument tests for distutils?  If the code is so confusing
> > that we can't test it (or "practical corner cases"), should we be
> > using it as a core ingredient in the first place?
> 
> The code is not so confusing - it has well-defined (though undocumented)
> structure that can be extended after one gets an idea how things
> work in distutils.
> 
> The variety of different compilers and platforms makes developing
> distutils difficult. I guess none of the developers who dare to
> touch distutils have access to all platforms and compilers that
> we are trying to support. This fact will not change after switching
> to some other tool such as scons.
> 
> We actually have tests for distutils - see buildbot.scipy.org.

I should have distinguished between numpy.distutils and distutils in
my previous code.  I think numpy.distutils does as well as can be
expected based on (python) distutils.  If we were to design a build
system from the ground up, it would probably look very different.

> > David's idea of using scons to build everything sounds more appealing
> > by the day.  Distutils can still do the packaging, but at least we
> > would have a modularised, testable, no-hassles build environment.
> 
> You obviously have little idea what does it mean to replace
> numpy.distutils with some other building tool;) Let this to be
> a challenge to work this out for anyone.

Would the effort be worth it in the end, if it allows more developers
to extend the build system (without worrying about the distutils
police at night)?

Maybe you're right: they say a person should be careful what you ask
for, lest it come true :)

Cheers
St?fan


From matthew.brett at gmail.com  Sat Sep 29 12:36:33 2007
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 29 Sep 2007 12:36:33 -0400
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <46FDD7EF.4050300@ar.media.kyoto-u.ac.jp>
References: <46F8B621.3030809@scipy.org>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp> <46FC72D9.5030207@gmail.com>
	<46FCACBD.4080802@cens.ioc.ee> <20070928204053.GC32704@mentat.za.net>
	<54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>
	<46FDD7EF.4050300@ar.media.kyoto-u.ac.jp>
Message-ID: <1e2af89e0709290936l6b2d8743sa180bbafef757b82@mail.gmail.com>

Hi,

> But I don't ask you to take my word on it: I am more than willing to
> code a prototype of what I have in mind. But then, I need to know what
> is required for a prototype, to make a plan of what needs to be implemented:

Thanks - this is an excellent mail, and makes the points very clearly.
 I think you are absolutely correct in saying a) we might be able to
make things much easier with scons and b) the only way we can decide
this is trying it.  So, the prototype is key here, and thank you for
persisting with this, it seems to me a very important effort which
will at very least clarify where we want to go in the future,

Matthew


From cookedm at physics.mcmaster.ca  Sat Sep 29 18:50:01 2007
From: cookedm at physics.mcmaster.ca (David M. Cooke)
Date: Sat, 29 Sep 2007 18:50:01 -0400
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <46FDD7EF.4050300@ar.media.kyoto-u.ac.jp> (David Cournapeau's
	message of "Sat, 29 Sep 2007 13:43:27 +0900")
References: <46F8B621.3030809@scipy.org> <m2wsue4wtb.fsf@saturn.dmc>
	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>
	<m2sl524uo1.fsf@saturn.dmc>
	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>
	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp> <46FC72D9.5030207@gmail.com>
	<46FCACBD.4080802@cens.ioc.ee> <20070928204053.GC32704@mentat.za.net>
	<54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>
	<46FDD7EF.4050300@ar.media.kyoto-u.ac.jp>
Message-ID: <m2odflcciu.fsf@saturn.dmc>

David Cournapeau <david at ar.media.kyoto-u.ac.jp> writes:

> Pearu Peterson wrote:
>> On Fri, September 28, 2007 11:40 pm, Stefan van der Walt wrote:
>>> I would prefer if numpy were *always* in a release-ready state.
>>
>> Most of the time it actually is.
>>
>>> Why can't we instrument tests for distutils?  If the code is so confusing
>>> that we can't test it (or "practical corner cases"), should we be
>>> using it as a core ingredient in the first place?
>>
>> The code is not so confusing - it has well-defined (though undocumented)
>> structure that can be extended after one gets an idea how things
>> work in distutils.
>>
> Before I start to make my points, and because I feel this discussion is 
> heating a bit, let me say that I never intend to criticize any numpy's 
> developers work/code. I understand that distutils is complicated to 
> extend, that numpy's needs go far beyond the usual needs of python 
> package, and I really think that numpy.distutils has already achieved 
> quite a lot. All other impressions are surely du to the fact that 
> English is not my native language :)
>
> Now, although I certainly do not have as much experience as you with 
> distutils, I have used autotools for non trivial projects, I have used 
> scons as well, and I have some experience with complicated gnu make 
> based projects (eg my numpy.gar script which can builds numpy and all 
> its dependencies in different configuration/compilers on linux/unix). 
> This is not to say I am knowledgeable, but at least I think I am aware 
> of the difficulties of a cross platform build system.
>
>> The variety of different compilers and platforms makes developing
>> distutils difficult. I guess none of the developers who dare to
>> touch distutils have access to all platforms and compilers that
>> we are trying to support. This fact will not change after switching
>> to some other tool such as scons.

> That's where I think we fundamentally disagree. I for one think 
> distutils (here I mean the official, python.distutils, and only to build 
> C/Fortran extensions; I will never talk about any other capabilities of 
> distutils) is fundamentally flawed wrt to several key points, and I am 
> not even talking about its implementation. Since you are much more 
> familiar with distutils than me, I would really appreciate being told wrong:

>      1 - the way it tries to detect the platform capability. When you 
> try to adapt to a platform in a build tool, you have at least two 
> possibilities: either you hardcode every new platform, or you try to get 
> the information from the platform. Distutils does the former, autoconf 
> does the latter. For me, there is absolutely no question which one is 
> better in this respect. This alone explains a lot of distutils fragility 
> IMHO. For example, numpy.distutils define the "f2c" library for each new 
> tool, but autoconf (more explicitely, the autoconf macro 
> AC_F77_LIBRARY_LDFLAGS) finds it automatically from compiler output.  
> This is a fundamental point, maybe the only most important one.

When you mention the 'f2c' library, you mean the Fortran intrinsic and
runtime libraries? We try to use the Fortran compiler for linking, so
knowing those tends not to be needed.

For comparision, we've got 2348 lines of source in
numpy/distutils/fcompiler/, and fortran.m4 included with autoconf is
1234 lines. However, fortran.m4 mostly only deals with finding a Fortran
compiler, finding flags for the libraries mentioned above, and name
mangling (and nothing about optimisation flags). SCons also does its
own handling of individual tools in much the same way as
numpy.distutils (with, again, no optimisations).

Now, one design point that I think distutils gets wrong is to use
lists for describing compiler options: the description of a compiler
(or any of the command line tools used) should be an object, that
'knows' how to turn, say, a .c file into a .o file (something like
scons' Builders, I think). We have some tools where the pattern
EXECUTABLE_NAME + SOME_OPTIONS + file.c + MORE_OPTIONS + file.o +
EVEN_MORE_OPTIONS doesn't work (most notably, linking shared libraries
on AIX must be handled specially). The CCompiler and FCompiler classes
are too high-level for this, as they contain knowledge about multiple
tools.

>     2 - numpy.distutils is difficult to extend. This, I think we all 
> agree. This is also significant, because it means that when 
> numpy.distutils fails, only a few people can change the situation. This 
> should not be the case. If the problem is one compiler flag, it should 
> not require anyone's involvement but the ones who experience the problem.

Fiddling compiler options shouldn't be too hard, espicially for the
Fortran compilers; it's usually pretty obvious where to fiddle for
those. But other things (C compilers, linking), I agree, could be
easier.

>     3 - Customizing compilation options: this is extremely difficult 
> right now, and this again by design.

My comment about using objects to represent tools applies here;
creating a custom tool object should be easy.

>     4 - Detecting libraries is extremely difficult: the first time I 
> used system_info, it was totally wrong, and I had to modify it for each 
> new platform. This is not good: I needed more time to make it right than 
> I ever did for autotools based projects of mine, which really says a lot 
> in my book.

Could you detail your problems? system_info.py needs to be cleaned up
(removal of repeative code, for instance) and finding libraries
standardised (for instance, there should always be an environment
variable and/or distutils key for things system_info wants to find,
that will override system_info).

>     5 - By design, scons does not depend on the environment. That is, it 
> does NOT use PATH information, LD_LIBRARY_FLAGS, etc... which again 
> makes it much more reliable. Of course, you can add command line 
> arguments for configuration, but by default, nothing will stab you in 
> the back.

Blech, I hate the fact that scons doesn't respect my PATH. That means
the compiler it may find is not necessarily the one that I would find
at my command line. Makes bugs more obscure. Other variables (from my
environment) that *should* be used as-is and not second-guessed by a
build tool are things like TMPDIR, TMP, LANG, and PKG_CONFIG_PATH. Any
variables like PATH or PKG_CONFIG_PATH are probably set for a reason.

> Now, you would rightly argue that doing all this in scons/whatever would 
> take a lot of time just to replicate distutils, and you would be right. 
> But I think it would require *less* time than implementing the things 
> stated eg in
> http://projects.scipy.org/scipy/numpy/wiki/DistutilsRevamp.

Not if I steal stuff from scons ;-)

(Or, for that matter, if I actually *had* any time to hack on it,
which I don't right now.)

Speaking of which, if the scons developers would make their code an
actual Python package (for one thing, install it by default in
site-packages/, and try to keep interfaces constantish), I would
support using scons modules in numpy.distutils. From the looks of it,
it's nicely laid out, with a good set of abstractions. Instead,
they've set it up so that scons must be in control, through SConstruct
files. Those have always had a faux-python feel to them for me: there
are names injected into them (i.e. Environment) that don't come from
an import statement, and the sharing of variables between SConscript
files using the Export function is quite unpythonic.

> But I don't ask you to take my word on it: I am more than willing to 
> code a prototype of what I have in mind. But then, I need to know what 
> is required for a prototype, to make a plan of what needs to be implemented:
>     - Is a prototype required to support all platforms supported now ?
>     - Is a prototype which can build numpy on Mac OS X/Linux/Win32 
> enough (keeping in mind that the key point is that adding new platforms 
> would be much easier once the prototype is done). In which configuration ?

Those are the big three. If it builds on those, we're probably 80% of
the way there.

Of course, it's the other 20% that'll take 80% of the work, as usual.

>     - If required, I could try to make it possible to have two top setup 
> scripts, one which uses the current distutils, one which use the 
> scons-based one.
>
> As said earlier, I have started hacking on a numpy branch which, right now:
>     - implements a scons command
>     - a support library, which enables to build/run ctypes extensions 
> working on many platforms (all the one I managed to use on the buildbot)
>     - a support library to find libraries and headers in standard 
> location on all supported platforms by scons (of which numpy.distutils 
> is a subset AFAIK), and can be customized using site.cfg.
>
> One problem I did not foresee is how difficult it is to be sure that 
> scons uses exactly the same tools than distutils (because distutils has 
> no common api to get things such as compiler, compiler path, etc...); 
> that's why contrary to what I thought first, using scons to build all 
> the compiled extension may actually be easier than making them coexist, 
> because scons and distutils have fundamentally different ways of looking 
> for tools.

We can see what we can do to make it easier to get at those
properties. For instance, it would be possible to separate the Fortran
compiler detection/option-setting more from the distutils parts.

> To start building numpy itself with it would require more work (mostly 
> tests for fortran / C abi), but with the help of people willing to help, 
> I don't see major problems on this side, since scons provide a framework 
> for autoconf-like testing. Also, this will certainly use some facilities 
> of numpy.distutils (basically, for a first prototype, scons would mostly 
> replace system_info.py, command/build_clib.py, command/build_ext.py).

If you have the time, I think it's worth a try. Unfortunately, I don't
have much time to contribute to it.

Basically, my opinion is not to replace numpy.distutils with scons
(for the simple reason of interacting nicely with distutils). However,
I'm not opposed to chucking parts of numpy.distutils and replacing
them with scons-like concepts.

-- 
|>|\/|<
/------------------------------------------------------------------\
|David M. Cooke              http://arbutus.physics.mcmaster.ca/dmc/
|cookedm at physics.mcmaster.ca


From david at ar.media.kyoto-u.ac.jp  Sun Sep 30 01:10:57 2007
From: david at ar.media.kyoto-u.ac.jp (David Cournapeau)
Date: Sun, 30 Sep 2007 14:10:57 +0900
Subject: [SciPy-dev] problems with numpy.setuptools...
In-Reply-To: <m2odflcciu.fsf@saturn.dmc>
References: <46F8B621.3030809@scipy.org>
	<m2wsue4wtb.fsf@saturn.dmc>	<51127.85.166.14.172.1190733753.squirrel@cens.ioc.ee>	<m2sl524uo1.fsf@saturn.dmc>	<FA93172C-0239-41E5-A621-18B31DFE088F@stsci.edu>	<46FC6E04.6010302@ar.media.kyoto-u.ac.jp>
	<46FC72D9.5030207@gmail.com>	<46FCACBD.4080802@cens.ioc.ee>
	<20070928204053.GC32704@mentat.za.net>	<54497.85.166.14.172.1191014123.squirrel@cens.ioc.ee>	<46FDD7EF.4050300@ar.media.kyoto-u.ac.jp>
	<m2odflcciu.fsf@saturn.dmc>
Message-ID: <46FF2FE1.7020705@ar.media.kyoto-u.ac.jp>

David M. Cooke wrote:
>
>
> When you mention the 'f2c' library, you mean the Fortran intrinsic and
> runtime libraries? We try to use the Fortran compiler for linking, so
> knowing those tends not to be needed.
But what if we want to use C++ code in the future ? Then you have no 
choice but using the C++ compiler. But more to the point, this was an 
example. All AC_F77_* macro (or AC_C_*, etc...) are much, much more 
solid than distutils. And this is by design.
>
> For comparision, we've got 2348 lines of source in
> numpy/distutils/fcompiler/, and fortran.m4 included with autoconf is
> 1234 lines. 
To make it clear: I was not talking about using autoconf (which for once 
does not work on windows), but about the concept that almost everybody 
agrees autoconf is good at, that is working on a new platform not 
foreseen by the developer. And this is due to a fundamentally different 
way to look for platform capabilities.

We have a huge advantage compared to autoconf: python vs m4 + shell. 
Most of the lines in fortran.m4 are difficult because autoconf has to 
deal with weird shells, antic platform bugs, and because of m4 and its 
antic quoting rules.
> However, fortran.m4 mostly only deals with finding a Fortran
> compiler, finding flags for the libraries mentioned above, and name
> mangling (and nothing about optimisation flags). SCons also does its
> own handling of individual tools in much the same way as
> numpy.distutils (with, again, no optimisations).
What do you mean by no optimizations ? Dealing with facilities provided 
by scons and dealing with capabilities are two different things, IMHO, 
because I trust scons enough to work on what is supported. But for 
example, when distutils is looking for something, it is always 
hardcoded: looking for a library ? Distutils looks for a file, autoconf 
is looking for something usable by the linker. This makes a huge 
difference concerning the robustness (and the maintenance).
>
> Now, one design point that I think distutils gets wrong is to use
> lists for describing compiler options: the description of a compiler
> (or any of the command line tools used) should be an object, that
> 'knows' how to turn, say, a .c file into a .o file (something like
> scons' Builders, I think). We have some tools where the pattern
> EXECUTABLE_NAME + SOME_OPTIONS + file.c + MORE_OPTIONS + file.o +
> EVEN_MORE_OPTIONS doesn't work (most notably, linking shared libraries
> on AIX must be handled specially). The CCompiler and FCompiler classes
> are too high-level for this, as they contain knowledge about multiple
> tools.
This is something that scons seems to make right.
>
> Fiddling compiler options shouldn't be too hard, espicially for the
> Fortran compilers; it's usually pretty obvious where to fiddle for
> those. But other things (C compilers, linking), I agree, could be
> easier.
The point is, did it ever happen that somebody who had a problem with a 
compiler flag solved it by himself ?

>
> Could you detail your problems? system_info.py needs to be cleaned up
> (removal of repeative code, for instance) and finding libraries
> standardised (for instance, there should always be an environment
> variable and/or distutils key for things system_info wants to find,
> that will override system_info).
system_info is looking for files, which is not the right way in my 
opinion. For example, in audiolab, my system_info subclass is 70 lines 
(http://projects.scipy.org/scipy/scikits/browser/trunk/audiolab/setup.py), 
all this to find one library ! In scons  (or autoconf, or any other 
build tool I know), this is one line. Maybe I am doing things wrong, the 
code started when I knew nothing about python and just copied what I 
found in system_info.py, dunno. But the code in system_info does not 
seem to imply this is simple or robust.

This is really striking for me: I have no problem with complicated code, 
if it matches the complexity of the task it is trying to solve. But to 
me, distutils makes anything trivial complicated (again, just talking 
about the things related to compiled code).
>
> Blech, I hate the fact that scons doesn't respect my PATH. That means
> the compiler it may find is not necessarily the one that I would find
> at my command line. Makes bugs more obscure.
I fundamentally disagree on this one. But anyway, we don't even need to 
agree, since you can easily import the variables you want. So we can 
make this an option (which has always been my intention anyway), but by 
default, not importing anything is more robust for deployment, no ? 
People who have non standard tools or tools in non standard locations 
are the ones who should make the effort, not the contrary IMHO.
>
> Not if I steal stuff from scons ;-)
I doubt you can "steal" things from scons, for the very reason you 
described.
>
> (Or, for that matter, if I actually *had* any time to hack on it,
> which I don't right now.)
>
> Speaking of which, if the scons developers would make their code an
> actual Python package (for one thing, install it by default in
> site-packages/, and try to keep interfaces constantish), I would
> support using scons modules in numpy.distutils. From the looks of it,
> it's nicely laid out, with a good set of abstractions. Instead,
> they've set it up so that scons must be in control, through SConstruct
> files. 
I think this is partly due to the fact that scons support any python 
starting from 1.5.2, and partly to the fact that scons is not imperative 
(in fact, this is one key difference with waf AFAIK). But scons has a 
package scons-local, which can be used as a drop in (in fact, that's 
what I did in numpy.scons branch: in theory, we could make our 
modification there), which somewhat alleviates the problem.
> Those have always had a faux-python feel to them for me: there
> are names injected into them (i.e. Environment) that don't come from
> an import statement, and the sharing of variables between SConscript
> files using the Export function is quite unpythonic.
I would agree in theory, but compared to python distutils, which one do 
you think people can understand more easily ? For once, distutils (the 
one from python) adds many members attributes at runtime, in many 
functions (not just __init__); this combined to the fact that it is 
mostly not commented + not documented + not maintained (nobody to ask 
this, nothing on the internet), makes it harder for me to understand 
than I ever did with the autotools, which are not known for their user 
friendliness.
>
> Those are the big three. If it builds on those, we're probably 80% of
> the way there.
>
> Of course, it's the other 20% that'll take 80% of the work, as usual.
I agree that making the 20 % will take the most time (anybody with at 
least some experience with cross platform building would, I guess). But 
I think this will be much easier than with distutils.
>
> We can see what we can do to make it easier to get at those
> properties. For instance, it would be possible to separate the Fortran
> compiler detection/option-setting more from the distutils parts.
For example, one thing which caused me problems is to get the name of 
the compiler: for unix compiler, just using the member compiler[0] gives 
me the executable, from which I have a dict to convert to scons names. 
But MVSCCompiler does not have such a member; and to find the path of 
the executable, *sometimes*, you need to call initialize (which of 
course is not documented). This is not just unpythonic, this is just 
really bad code; what's the point to have a base class for compiler if 
this does not even have a common way to get the compiler name ?
>
>> To start building numpy itself with it would require more work (mostly 
>> tests for fortran / C abi), but with the help of people willing to help, 
>> I don't see major problems on this side, since scons provide a framework 
>> for autoconf-like testing. Also, this will certainly use some facilities 
>> of numpy.distutils (basically, for a first prototype, scons would mostly 
>> replace system_info.py, command/build_clib.py, command/build_ext.py).
>
> If you have the time, I think it's worth a try. Unfortunately, I don't
> have much time to contribute to it.
>
> Basically, my opinion is not to replace numpy.distutils with scons
> (for the simple reason of interacting nicely with distutils).
Again, never had the intention to totally replace distutils: distutils 
would still drive the whole build. Ideally, if it works out, I intend to 
replace the build_ext and build_clib commands; it would still works by 
calling setup.py build, it would still put everything in build, and 
install using --prefix, etc... This would be totally transparent to the 
user (except maybe for setting compiler at command line, and even, this 
may be doable to stay 100% backward compatible at this level). You can 
take a look at openalea, who did the exact same thing:

http://openalea.gforge.inria.fr/wiki/doku.php

Everything else seems to work quite well in distutils, no ?

cheers,

David



From matthieu.brucher at gmail.com  Sun Sep 30 16:07:05 2007
From: matthieu.brucher at gmail.com (Matthieu Brucher)
Date: Sun, 30 Sep 2007 22:07:05 +0200
Subject: [SciPy-dev] Nifti support
Message-ID: <e76aa17f0709301307m6bc6d839g9023a240226a237f@mail.gmail.com>

Hi,

I saw that nifti file support was currently in the pipeline. If the license
issue is solved, I can provide you a nifticlib.i file that is compatible
with C89 compilers (the converted file needs a C99 compiler, so compiling it
with MSVC is not possible), as I've done this for my hobbies some weeks ago.

Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20070930/0e5b1691/attachment.html>

From millman at berkeley.edu  Sun Sep 30 19:14:24 2007
From: millman at berkeley.edu (Jarrod Millman)
Date: Sun, 30 Sep 2007 16:14:24 -0700
Subject: [SciPy-dev] Nifti support
In-Reply-To: <e76aa17f0709301307m6bc6d839g9023a240226a237f@mail.gmail.com>
References: <e76aa17f0709301307m6bc6d839g9023a240226a237f@mail.gmail.com>
Message-ID: <c7009a550709301614o57e56de2n3915b02327e3219@mail.gmail.com>

On 9/30/07, Matthieu Brucher <matthieu.brucher at gmail.com> wrote:
> I saw that nifti file support was currently in the pipeline. If the license
> issue is solved, I can provide you a nifticlib.i file that is compatible
> with C89 compilers (the converted file needs a C99 compiler, so compiling it
> with MSVC is not possible), as I've done this for my hobbies some weeks ago.

Hey Matthieu,

The pynifti license issue has been resolved.  Michael Hanke, the
author, has released his software under an MIT license:
http://sourceforge.net/project/shownotes.php?group_id=126549&release_id=543252

Early this week, Chris Burns and I will check this code into the SciPy
repository.  Once we do, it would be great if you could either
integrate your nifticlib.i into the codebase or just send us your
code.

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/


From nwagner at iam.uni-stuttgart.de  Fri Sep 28 12:54:52 2007
From: nwagner at iam.uni-stuttgart.de (Nils Wagner)
Date: Fri, 28 Sep 2007 18:54:52 +0200
Subject: [SciPy-dev] Sandbox package Multigrid
Message-ID: <web-89979935@uni-stuttgart.de>

Nathan,

Please can you add the missing file "torus.mtx.gz".
Thanks in advance.

Cheers,
            Nils



python -i 
/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/test_coarsen.py
   Found 8/8 tests for __main__
...E....
======================================================================
ERROR: check_sample_data 
(__main__.test_sa_constant_interpolation)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/test_coarsen.py", 
line 153, in check_sample_data
     A = read_matrix(filename)
   File 
"/usr/local/lib64/python2.5/site-packages/scipy/sandbox/multigrid/tests/examples.py", 
line 8, in read_matrix
     fid = gzip.open(filename)
   File "/usr/lib64/python2.5/gzip.py", line 49, in open
     return GzipFile(filename, mode, compresslevel)
   File "/usr/lib64/python2.5/gzip.py", line 95, in 
__init__
     fileobj = self.myfileobj = __builtin__.open(filename, 
mode or 'rb')
IOError: [Errno 2] No such file or directory: 
'sample_data/torus.mtx.gz'

----------------------------------------------------------------------
Ran 8 tests in 8.699s

FAILED (errors=1)