Mailman 3 September 2003 - SciPy-Dev

Debian packages of scipy and f2py
by José Fonseca 03 Oct '03

03 Oct '03

I've make Debian packages of scipy and f2py. They are available from my apt-get repository at: http://jrfonseca.dyndns.org/debian/ I referred to Joe Reinhardt's packages http://people.debian.org/~jmr/ but have done these packages from scratch. These come for all python versions in debian unstable (2.1, 2.2 and 2.3). I've run the standard tests successfully but I'd appreciate that problems with these packages to be reported to me [privately] as I'd like to have these on Debian proper at some time. One tricky issue I'd like to address with the scipy and f2py maintainers is the the scipy_distutils. Both scipy and f2py attempt to install to /usr/lib/python*/site-packages/scipy_distutils and at least on Debian this is not admissible so the packages conflict with each other and are mutually exclusive. This is particularly even more annoying for me, since for building scipy f2py is needed, so I need to install and uninstall them as a maniac. Is there any solution that allow both these packages to happily co-exist in a tree without overlapping? Enjoy, José Fonseca PS: Please CC'me on any reply as I'm not subscribed to all these lists.

3 3

Testing scipy-dev
by Joe Cooper 30 Sep '03

30 Sep '03

Just a test of the mailing list, after a Mailman upgrade. Please ignore. Thanks.

1 0

Scheduled release
by Travis Oliphant 26 Sep '03

26 Sep '03

The release of scipy is coming along, but I think we need to postpone the release until Tuesday as I have found some bugs in special that need addressing. Comments? -Travis Oliphant

2 2

Broken .py files in current CVS
by bhoel＠web.de 26 Sep '03

26 Sep '03

Hello, Trying to install the latest CVS version of SciPy I get byte-compiling /usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.swig.py to graphics_context.swig.pyc File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.swig.py", line 1 %pythoncode { ^ SyntaxError: invalid syntax byte-compiling /usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.py to graphics_context.pyc File "/usr/local/lib/python2.3/site-packages/kiva/agg/graphics_context.py", line 1 %pythoncode { ^ SyntaxError: invalid syntax byte-compiling /usr/local/lib/python2.3/site-packages/scipy/io/array_import.py to array_import.pyc Is there some cruft left from some kind of code generator? Regards Berthold -- bhoel(a)web.de / http://starship.python.net/crew/bhoel/ It is unlawful to use this email address for unsolicited ads (USC Title 47 Sec.227). I will assess a US$500 charge for reviewing and deleting each unsolicited ad.

3 2

failure importing real from Numeric in io.array_import
by eric jones 25 Sep '03

25 Sep '03

Just got the following on one of our internal tests when using the CVS of SciPy: Traceback (most recent call last): File "C:\wrk\proava\trunk\prototype\tests\test_depth_time.py", line 102, in ch eck_single_input data = read_depth_data() File "C:\wrk\proava\trunk\prototype\tests\test_depth_time.py", line 10, in rea d_depth_data data = io.read_array(os.path.join(d,'z2t_input_z_vp.txt'), File "C:\Python23\Lib\site-packages\scipy_base\ppimport.py", line 226, in __ge tattr__ module = self._ppimport_importer() File "C:\Python23\Lib\site-packages\scipy_base\ppimport.py", line 194, in _ppi mport_importer raise PPImportError,\ PPImportError: Traceback (most recent call last): File "C:\Python23\Lib\site-packages\scipy_base\ppimport.py", line 204, in _ppi mport_importer module = __import__(name,None,None,['*']) File "C:\Python23\lib\site-packages\scipy\io\__init__.py", line 11, in ? from array_import import * File "C:\Python23\Lib\site-packages\scipy\io\array_import.py", line 13, in ? from Numeric import array, take, concatenate, Float, asarray, real, imag ImportError: cannot import name real Changing this to from scipy_base import real, imag fixed the problems. I'm using Numeric 23.1. Should I be using the Numeric CVS, or should we change the import statement? thanks, eric

2 1

Formal Review Process
by Robert Kern 24 Sep '03

24 Sep '03

At both SciPy conferences, Eric emphasized the need for a peer-review process for potential contributions to SciPy. I recalled that the Boost community established a formal review process for contributions to their set of libraries, and it seems to work well for them. I got bored of writing a history paper, so I looked at their process and wrote up a proposal for SciPy (liberally using parts of the Boost documents where noted). Please comment on, add to, delete from, and otherwise contribute to the following proposal. You can email me personally as well as respond to the list. As he announced at SciPy '03, Chad Netzer has a wavelets module he would like to submit. If we can hammer out some consensus (enough for a test run at least), then Chad can be our first sacrif^Wclient. I am sure he is as thrilled to learn of this possibility as I am to raise it. The text is included below. HTML and text versions can also be found in the following URLs: http://www.ugcs.caltech.edu/~kern/scipy-review.html http://www.ugcs.caltech.edu/~kern/scipy-review.txt A Proposal for a SciPy Module Submission Review Process ======================================================= :Author: Robert Kern (parts by the Boost_ group and others__) :Version: 0.0 :Date: 2003-09-20 The following proposal is inspired by (and indeed partly outright lifted from) the `Boost Formal Review Process`_ and `Submission Process`_. It is written using ReStructuredText_. .. _Boost: http://www.boost.org __ Acknowledgements_ .. _Boost Formal Review Process: http://www.boost.org/more/formal_review_process.htm .. _Submission Process: http://www.boost.org/more/submission_process.htm .. _ReStructuredText : http://docutils.sourceforge.net Rationale --------- 1. The SciPy package requires a peer-review process to examine new module submissions. The expertise of the CVS maintainer is limited, and the number of fields for which one could write a SciPy module is large. 2. A formal procedure for the review process makes it easier for newcomers to know exactly what they have to do to get their contribution into SciPy. Furthermore, a formal procedure makes it easier for Enthought to parcel out the work to non-Enthought people and even to transition SciPy to a wholly community-driven project if that ever becomes a goal. 3. The Boost project had a similar problem, found a solution that worked for them, and wrote it up all pretty, so why not steal it? [XXX - or something to this effect] Organization ------------ Mailing List ~~~~~~~~~~~~ Discussion of libraries under formal review shall take place on scipy-dev(a)scipy.org . Actual reviews of a candidate module (see section `Reviews`_) during its formal review period should begin their Subject header with [REVIEW - <name of module>] for the convenience of the Review Manager. Reviewers who do not wish to subscribe to scipy-dev(a)scipy.org may use the GMane_ WWW_ and Usenet_ interfaces to the mailing list. The WWW_ interface does not allow posting. [XXX - to be honest, I don't know if the Usenet_ one allows posting for this list, either.] .. _GMane: http://www.gmane.org .. _WWW: http://news.gmane.org/gmane.comp.python.scientific.devel .. _Usenet: nntp://news.gmane.org/gmane.comp.python.scientific.devel Review Wizard ~~~~~~~~~~~~~ (The Review Wizard/Manager sections are only slightly changed from `Boost Formal Review Process`_.) The Review Wizard: * Maintains a list of review manager volunteers. * When a formal review is requested for a module: - Assigns a review manager and suggests a schedule. - Finalizes the schedule, once the review manager verifies the module is actually ready for review. - Resolves schedule slips or other issues with review managers and submitters. * Maintains a schedule of both past and pending reviews. * Resolves questions from review managers and module submitters, who sometimes want a third opinion on questions such as "Should we extend the review period because ...?" * Monitors the general review process, and makes minor adjustments as needed, or queries the list about possible major adjustments. .. _Boost Formal Review Process: http://www.boost.org/more/formal_review_process.htm Review Manager ~~~~~~~~~~~~~~ The Review Manager: * Checks the submission to make sure it really is complete enough to warrant formal review. If necessary, work with the submitter to verify the code compiles and runs correctly on several platforms. * Finalizes the schedule with the Review Wizard and the submitter. * Posts a notice of the review schedule on the appropriate mailing list(s). - The notice should include a brief description of the module and what it does, to let readers know if the module is one they are interested in reviewing. - If the module is known to fail on certain platforms, please mention them in the review notice so reviewers on those platforms won't waste time diagnosing known problems (or alternatively, will test and try to resolve the failures). * Inspects the SciPy package for modules which may interact with the new submission. These potential interactions should be pointed out in the review announcement, and the author(s) of these modules should be privately notified and urged to participate in the review. * Urges people to do reviews if they aren't forthcoming. * Follows review discussions regarding the modules, moderating or answering questions as needed. * Decides if there is consensus to accept the modules, and if there are any conditions attached. * Posts a message to the appropriate mailing lists informing people of the review results. In other words, it is the Review Manager's responsibility to make sure the review process works smoothly. The Process for a Module Submitter ---------------------------------- Determine Interest ~~~~~~~~~~~~~~~~~~ Post a message to scipy-dev(a)scipy.org to see if there is interest in your module. Describe what your module does and perhaps include a small snippet of code that shows how one uses it. Preliminary Submission ~~~~~~~~~~~~~~~~~~~~~~ Put your (possibly unfinished) module on a website and post its location to scipy-dev(a)scipy.org . Contact the maintainers of www.scipy.org for a Zope account if you need web space for your module. Submissions should follow the Code Submission Guidelines [XXX - this should point to something useful. For now, look at the `Code Formatting Guidelines`_ and the `Testing Guidelines`_.] .. _Code Formatting Guidelines: http://www.scipy.org/site_content/tutorials/formatting_guidelines .. _Testing Guidelines: http://www.scipy.org/site_content/tutorials/testing_guidelines Refinement ~~~~~~~~~~ Discuss the module in scipy-dev(a)scipy.org . Fix bugs; add functionality; change the interface; write docs/unit tests; do whatever comes out of the discussion as necessary or beneficial to including the module in SciPy. Update the preliminary submission until it is ready for formal submission. Submission for Review ~~~~~~~~~~~~~~~~~~~~~ Package your module submission in a ZIP file or gzipped tar file such that it can be unpacked in the scipy CVS directory [XXX - what if you need to patch the setup.py file or scipy_distutils files? Diff file?]. Contact the Review Wizard. He will assign a Review Manager and create a www.scipy.org Zope account for you. Place your submission in [XXX] on the www.scipy.org website. The Review Manager will kick off the reviews on scipy-dev(a)scipy.org . Reviews ------- (Again, taken from `Boost Formal Review Process`_). Reviews may be submitted to either the list as a whole or the Review Manager privately. Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the module. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the unit-test coverage? * What is your evaluation of the potential usefulness of the module? * Did you try to use the module? On what platform? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? Are you knowledgeable about the programming techniques used? [E.g. perhaps you know nothing about what the underlying FORTRAN code does, but you are an expert in wrapping code with f2py. Both areas of knowledge are useful for a review.] And finally, every review should answer this question: * Do you think the module should be accepted into the SciPy package? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. The module should be stable during the review period (making exception for serious bug fixes). Modifications suggested during review and accepted by the submitter should be noted on the mailing list so reviewers can make an informed decision. At the end of the review period, the Review Manager will make the final decision to accept or reject the module for inclusion into SciPy. He will post this result to the mailing list along with a rationale and any suggestions or conditions that must be met before the module can be included (or resubmitted for review, as the case may be). Acknowledgements ---------------- I would like to thank the Boost community for their well thought-out review process and the words describing said process. [XXX - Eric, please check if this is OK with them] Eric Jones, [XXX - Your Names Here] provided helpful comments and contributions to this document. [XXX - Kern's Notes] -------------------- The Review Wizard/Manager roles will probably be taken by Enthought people or their designees at least at the start, mostly because they would have to do similar tasks without a formal review process, so who else would volunteer? Note the XXX's. They need content or answers. Boost adds the libraries up for review into a CVS sandbox. We may want to do the same. The process as a whole feels a bit heavyweight to me, but there are some benefits that flow from that. Some nips and tucks couldn't hurt, though. -- Robert Kern kern(a)caltech.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

5 4

extract and where
by eric jones 21 Sep '03

21 Sep '03

extract has the following signature: >>> help(extract) Help on function extract in module __main__: extract(arr, mask) 1D array of those elements of ravel(arr) where ravel(mask) is true. This is backward from most of the Numeric routines where the condition (mask) array comes first (where, compress, and maybe others). Any objections to reversing these? Also, the one argument form of where() included in numarray would be useful to have in SciPy while we are still relying on Numeric. Should we wait until after 0.2, or go ahead and add this? From the numarray docs: Starting with numarray-0.6, where supports a one parameter form that is equivalent to nonzero but reads better: >>> where(arange(10) % 2) (array([1, 3, 5, 7, 9]),) # indices where expression is true < the following would have to use take() instead of indexing while we are still relying on Numeric> Like nonzero, the one parameter form of where can be used to do array indexing: >>> a = arange(10,20) >>> a[ where( a % 2 ) ] array([11, 13, 15, 17, 19]) Note that for array indices which are boolean arrays, using where is not necessary but is still OK: >>> a[(a % 2) != 0] array([11, 13, 15, 17, 19]) >>> a[where((a%2) != 0)] array([11, 13, 15, 17, 19]) eric

1 0

SciPy 0.2 release
by Travis Oliphant 21 Sep '03

21 Sep '03

We are going to release SciPy 0.2 next week (Thursday 1:00pm Central Time). Please report any remaining outstanding issues that must be resolved before we tag the CVS tree with the release number. SciPy will still undergo improvements so SciPy 0.3 does not have to be far behind. Thanks for all of your reports so far. -Travis Oliphant

1 0

Fortran code in scipy_base
by Pearu Peterson 21 Sep '03

21 Sep '03

Hi, On Fri, 19 Sep 2003 travo(a)scipy.org wrote: > Update of /home/cvsroot/world/scipy_core/scipy_base > In directory scipy.org:/tmp/cvs-serv7557/scipy_core/scipy_base > > Modified Files: > function_base.py polynomial.py setup_scipy_base.py > Added Files: > futil.f > Log Message: > Added fortran utility functions to scipy_base as part of f2py demo. Adding Fortran codes to scipy_core contradicts with its design idea. Namely, the modules from scipy_core were factored from the earlier scipy package in order to resolve packaging issues of scipy and f2py2e -- see scipy/PACKAGERS.txt. The solution was that scipy_core f2py2e scipy should be installed strictly in the given order, so, scipy_core may contain only pure Python or C extension modules. So, could futil.f be moved to somewhere under scipy? Pearu

2 1

Re: [Scipy-cvs] world/scipy setup.py,1.10,1.11
by Pearu Peterson 18 Sep '03

18 Sep '03

On Wed, 17 Sep 2003 martin(a)scipy.org wrote: > Index: setup.py > =================================================================== > RCS file: /home/cvsroot/world/scipy/setup.py,v > retrieving revision 1.10 > retrieving revision 1.11 > diff -C2 -d -r1.10 -r1.11 > *** setup.py 15 Sep 2003 14:06:42 -0000 1.10 > --- setup.py 17 Sep 2003 20:21:29 -0000 1.11 > *************** > *** 50,54 **** > scipy_packages = standard_packages > scipy_packages += graphics_packages > ! #scipy_packages += chaco_packages > > #--------------- > --- 50,54 ---- > scipy_packages = standard_packages > scipy_packages += graphics_packages > ! scipy_packages += chaco_packages Hmm, why is this uncommented? Now chaco and friends are installed in two locations: both in site-packages/ and site-packages/scipy/. > #--------------- > *************** > *** 60,64 **** > > # enable building chaco here by uncommenting the following line: > ! #separate_packages += chaco_packages > > #------------------------------- > --- 60,64 ---- > > # enable building chaco here by uncommenting the following line: > ! separate_packages += chaco_packages I thought we agreed on disabling chaco build under scipy because of gcc 2.95 bugs showing up on chaco C++ codes. Pearu

1 0