Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Tue, May 25, 2010 at 9:22 PM, Travis Oliphant oliph...@enthought.comwrote: On May 25, 2010, at 4:49 PM, David Goldsmith wrote: Travis: do you already have a place on the NumPy Development Wikihttp://wiki.numpy.org/where you're (b)logging your design decisions? Seems like a good way for concerned parties to monitor your choices in more or less real time and thus provide comment in a timely fashion. This is a great idea of course and we will definitely post progess there. Thanks; specific URL please, when available; plus, prominently feature (a link to) the location on the Development Wiki home page, at the very least (i.e., if not also on the NumPy home page). So far, the code has been reviewed, I.e., the existing code, yes? and several functions identified for re-factoring. Please enumerate on the Wiki Refactoring Log (name tentative - I don't care what we call it, just so long as it exists, its purpose is clear, and we all know where it is). This is taking place in a github branch of numpy called numpy refactor. This = the actual creation/modification of code, yes? DG -Travis DG On Tue, May 25, 2010 at 2:19 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 25, 2010 at 2:54 PM, Travis Oliphant oliph...@enthought.comwrote: On May 25, 2010, at 2:50 PM, Charles R Harris wrote: On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant oliph...@enthought.com wrote: Hi everyone, There has been some talk about re-factoring NumPy to separate out the Python C-API layer and make NumPy closer to a C-library. I know there are a few different ideas about what this means, and also that people are very busy. I also know there is a NumPy 2.0 release that is in the works. I'm excited to let everyone know that we (at Enthought) have been able to find resources (about 3 man months) to work on this re-factoring project and Scott and Jason (both very experienced C and Python programmers) are actively pursuing it.My hope is that NumPy 2.0 will contain this re-factoring (which should be finished just after SciPy 2010 --- where I'm going to organize a Sprint on NumPy which will include at least date-time improvements and re-factoring work). While we have specific goals for the re-factoring, we want this activity to be fully integrated with the NumPy community and Scott and Jason want to interact with the community as much as feasible as they suggest re-factoring changes (though they both have more experience with phone-conversations to resolve concerns than email chains and so some patience from everybody will be appreciated). Because Jason and Scott are new to this mailing list (but not new to NumPy), I wanted to introduce them so they would feel more comfortable posting questions and people would have some context as to what they were trying to do. Scott and Jason are both very proficient and skilled programmers and I have full confidence in their abilities. That said, we very much want the input of as many people as possible as we pursue the goal of grouping together more tightly the Python C-API interface layer to NumPy. I will be involved in some of the discussions, but am currently on a different project which has tight schedules and so I will only be able to provide limited mailing-list visibility. I think 2.0 would be a bit early for this. Is there any reason it couldn't be done in 2.1? What is the planned policy with regards to the visible interface for extensions? It would also be nice to have a rough idea of how the resulting code would be layered, i.e., what is the design for this re-factoring. Simply having a design would be a major step forward. The problem with doing it in 2.1 is that this re-factoring will require extensions to be re-built. The visible interface to extensions will not change, but there will likely be ABI incompatibility.It seems prudent to do this in NumPy 2.0. Perhaps we can also put in place the ABI-protecting indirection approaches that David C. was suggesting earlier. Some aspects of the design are still being fleshed out, but the basic idea is to separate out a core library that is as independent of the Python C-API as possible.There will likely be at least some dependency on the Python C-API (reference counting and error handling and possibly others) which any interface would have to provide in a very simple Python.h -- equivalent, for example. Our purpose is to allow NumPy to be integrated with other languages or other frameworks systems without explicitly relying on CPython.There are a lot of questions as to how this will work, and so much of that is being worked out. Part of the reason for this mail is to help ensure that as much of this discussion as possible takes place in public. Sounds good, but what if it doesn't get finished in a few months? I think we should get 2.0.0 out pronto, ideally it would already have been
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
I'm a potential user of the C-API and therefore I'm very interested in the outcome. In the previous discussion (http://comments.gmane.org/gmane.comp.python.numeric.general/37409) many different views on what the new C-API should be were expressed. Naturally, I wonder if the new C-API will be useful for my purposes. So, I'm not so excited about a refactoring log where only the progress is reported. I fear that some (potentially minor) design decisions would render the new C-API useless for me. So my question is: Does this refactoring log also include something like a Numpy Enhancement Proposal? Something that can be discussed beforehand? I.e., will there be a detailed description (i.e. code examples) what the goal of the refactoring is? If there is any interest, I could provide some simple test examples in C that would explain what I'd like to be able to do with the new C-API. Sebastian On Wed, May 26, 2010 at 8:21 AM, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, May 25, 2010 at 9:22 PM, Travis Oliphant oliph...@enthought.com wrote: On May 25, 2010, at 4:49 PM, David Goldsmith wrote: Travis: do you already have a place on the NumPy Development Wiki where you're (b)logging your design decisions? Seems like a good way for concerned parties to monitor your choices in more or less real time and thus provide comment in a timely fashion. This is a great idea of course and we will definitely post progess there. Thanks; specific URL please, when available; plus, prominently feature (a link to) the location on the Development Wiki home page, at the very least (i.e., if not also on the NumPy home page). So far, the code has been reviewed, I.e., the existing code, yes? and several functions identified for re-factoring. Please enumerate on the Wiki Refactoring Log (name tentative - I don't care what we call it, just so long as it exists, its purpose is clear, and we all know where it is). This is taking place in a github branch of numpy called numpy refactor. This = the actual creation/modification of code, yes? DG -Travis DG On Tue, May 25, 2010 at 2:19 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 25, 2010 at 2:54 PM, Travis Oliphant oliph...@enthought.com wrote: On May 25, 2010, at 2:50 PM, Charles R Harris wrote: On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant oliph...@enthought.com wrote: Hi everyone, There has been some talk about re-factoring NumPy to separate out the Python C-API layer and make NumPy closer to a C-library. I know there are a few different ideas about what this means, and also that people are very busy. I also know there is a NumPy 2.0 release that is in the works. I'm excited to let everyone know that we (at Enthought) have been able to find resources (about 3 man months) to work on this re-factoring project and Scott and Jason (both very experienced C and Python programmers) are actively pursuing it. My hope is that NumPy 2.0 will contain this re-factoring (which should be finished just after SciPy 2010 --- where I'm going to organize a Sprint on NumPy which will include at least date-time improvements and re-factoring work). While we have specific goals for the re-factoring, we want this activity to be fully integrated with the NumPy community and Scott and Jason want to interact with the community as much as feasible as they suggest re-factoring changes (though they both have more experience with phone-conversations to resolve concerns than email chains and so some patience from everybody will be appreciated). Because Jason and Scott are new to this mailing list (but not new to NumPy), I wanted to introduce them so they would feel more comfortable posting questions and people would have some context as to what they were trying to do. Scott and Jason are both very proficient and skilled programmers and I have full confidence in their abilities. That said, we very much want the input of as many people as possible as we pursue the goal of grouping together more tightly the Python C-API interface layer to NumPy. I will be involved in some of the discussions, but am currently on a different project which has tight schedules and so I will only be able to provide limited mailing-list visibility. I think 2.0 would be a bit early for this. Is there any reason it couldn't be done in 2.1? What is the planned policy with regards to the visible interface for extensions? It would also be nice to have a rough idea of how the resulting code would be layered, i.e., what is the design for this re-factoring. Simply having a design would be a major step forward. The problem with doing it in 2.1 is that this re-factoring will require extensions to be re-built. The visible interface to extensions will not change, but there will likely be ABI incompatibility. It seems prudent to do this in NumPy 2.0. Perhaps we can also put in place the ABI-protecting
Re: [Numpy-discussion] Extending documentation to c code
Wed, 26 May 2010 06:57:27 +0900, David Cournapeau wrote: [clip: doxygen] It is yet another format to use inside C sources (I don't think doxygen supports rest), and I would rather have something that is similar, ideally integrated into sphinx. It also generates rather ugly doc by default, Anyway, we can probably nevertheless just agree on a readable plain-text/ rst format, and then just use doxygen to generate the docs, as a band-aid. http://github.com/pv/numpycdoc -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
Wed, 26 May 2010 10:50:19 +0200, Sebastian Walter wrote: I'm a potential user of the C-API and therefore I'm very interested in the outcome. In the previous discussion (http://comments.gmane.org/gmane.comp.python.numeric.general/37409) many different views on what the new C-API should be were expressed. I believe the aim of the refactor is to *not* change the C-API at all, but separate it internally from the routines that do the heavy lifting. Externally, Numpy would still look the same, but be more easy to maintain. The routines that do the heavy lifting could then be good for reuse and be more easy to maintain, but I think how and where they would be exposed hasn't been discussed so far... -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 12:31 PM, Pauli Virtanen p...@iki.fi wrote: Wed, 26 May 2010 10:50:19 +0200, Sebastian Walter wrote: I'm a potential user of the C-API and therefore I'm very interested in the outcome. In the previous discussion (http://comments.gmane.org/gmane.comp.python.numeric.general/37409) many different views on what the new C-API should be were expressed. I believe the aim of the refactor is to *not* change the C-API at all, but separate it internally from the routines that do the heavy lifting. Externally, Numpy would still look the same, but be more easy to maintain. Sorry for the confusion. By C-API I meant a C-API that would be independent of the CPython API. The routines that do the heavy lifting could then be good for reuse and be more easy to maintain, but I think how and where they would be exposed hasn't been discussed so far... I had the impression that the goal is not only to have code that is easier to maintain but to give developers the possibility to use numpy functionality (broadcasting, ufuncs, ...) within C code without having to use CPython API (refcounts, construction of PyObjects etc.). -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Reading and writing binary data to/from file objects
Hi, I want to read binary data from a file using fromfile. This works as long as I use a file name as argument to fromfile. With a file object the data is wrong! Consider the following example: from numpy import * fname='file.bin' fname2='file2.bin' a = arange(1, 30) print type(a[0]) print \noriginal data print a # write to file name a.tofile(fname) # write to file object f = open(fname2, 'w') a.tofile(f) f.close() print \nWritten to file name, read from file name b = fromfile(fname, dtype=int32) print b print \nWritten to file name, read from file object f = open(fname, 'r') b = fromfile(f, dtype=int32) f.close() print b print \nWritten to file object, read from file name b = fromfile(fname2, dtype=int32) print b print \nWritten to file object, read from file object f = open(fname2, 'r') b = fromfile(f, dtype=int32) f.close() print b This prints: type 'numpy.int32' original data [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29] Written to file name, read from file name [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29] Written to file name, read from file object [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 0 0 0 0] Written to file object, read from file name [ 123456789 2573 2816 3072 3328 3584 3840 4096 4352 4608 4864 5120 5376 5632 5888 6144 6400 6656 6912 7168 7424] Written to file object, read from file object [ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 0 0 0 0] Size of 'file.bin' (written to file name) is 116 Bytes, size of 'file2.bin' (written to file object) is 117 Bytes! So the only correct data is when writing to a file name and reading from a file name. All other variants yield wrong data! This happens with Numpy 1.4.1 with Python 2.6 under Windows XP. For comparison I only have a 1.1.0 Numpy with Python 2.5 under Linux Debian where in all cases I get the same, correct arrays! Am I doing something substantially wrong or is this a bug? Christoph ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reading and writing binary data to/from file objects
ke, 2010-05-26 kello 14:07 +0200, Christoph Bersch kirjoitti: f = open(fname2, 'w') [clip] Am I doing something substantially wrong or is this a bug? You are opening files in text mode. Use mode 'wb' instead. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Reading and writing binary data to/from file objects
Pauli Virtanen schrieb: ke, 2010-05-26 kello 14:07 +0200, Christoph Bersch kirjoitti: f = open(fname2, 'w') [clip] Am I doing something substantially wrong or is this a bug? You are opening files in text mode. Use mode 'wb' instead. That was it, thank you! Linux does not seem to care about binary or text mode. As I develop under Linux I was a bit puzzled by the different behaviour on Windows. Christoph ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __eq__ with str and object
On Tue, May 25, 2010 at 2:21 PM, Michael Droettboom md...@stsci.edu wrote: Seems like a bug to me. Certain branches in _array_richcompare return False to fail rather than Py_NotImplemented, which means the string-understanding comparison fallbacks don't run. Attached is a (simple) patch that resolves this bug, and doesn't seem to cause any of the unit tests to fail. Does this make sense to someone with a better understanding of the rich comparison code than I? Mike On 05/25/2010 12:54 PM, Keith Goodman wrote: a1 = np.array(['a', 'b'], dtype=object) a2 = np.array(['a', 'b']) a1 == a2 array([ True, True], dtype=bool) # Looks good a2 == a1 False # Should I have expected this? Could you open a ticket for this and mark it for review? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Extending documentation to c code
On Wed, May 26, 2010 at 2:59 AM, Pauli Virtanen p...@iki.fi wrote: Wed, 26 May 2010 06:57:27 +0900, David Cournapeau wrote: [clip: doxygen] It is yet another format to use inside C sources (I don't think doxygen supports rest), and I would rather have something that is similar, ideally integrated into sphinx. It also generates rather ugly doc by default, Anyway, we can probably nevertheless just agree on a readable plain-text/ rst format, and then just use doxygen to generate the docs, as a band-aid. http://github.com/pv/numpycdoc Neat. I didn't quite see the how how you connected the rst documentation and doxygen. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] __eq__ with str and object
On Wed, May 26, 2010 at 6:11 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 25, 2010 at 2:21 PM, Michael Droettboom md...@stsci.edu wrote: Seems like a bug to me. Certain branches in _array_richcompare return False to fail rather than Py_NotImplemented, which means the string-understanding comparison fallbacks don't run. Attached is a (simple) patch that resolves this bug, and doesn't seem to cause any of the unit tests to fail. Does this make sense to someone with a better understanding of the rich comparison code than I? Mike On 05/25/2010 12:54 PM, Keith Goodman wrote: a1 = np.array(['a', 'b'], dtype=object) a2 = np.array(['a', 'b']) a1 == a2 array([ True, True], dtype=bool) # Looks good a2 == a1 False # Should I have expected this? Could you open a ticket for this and mark it for review? Here's the ticket: http://projects.scipy.org/numpy/ticket/1491 Mike, could you attach your fix? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Help Convolution with binaural filters(HRTFs)
Hi, i try to implement a real-time convolution module refreshed by head listener location (angle from a reference point).The result of the convolution by binaural flters(HRTFs) allows me to spatialize a monophonic wavfile. I got trouble with this as long as my convolution doesnt seem to work properly: np.convolve() doesnt convolve the entire entry signal -trouble with extracting numpyarrays from the audio wav. filters and monophonic entry -trouble then with encaspulating the resulting array in a proper wav file...it is not read by audacity Do you have any idea of how this could work or do you have any implementation of stereo filtering by impulse response to submit me Thank you very much Arthur de Conihout ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FW: Numpy python build
On Wed, May 26, 2010 at 11:25 AM, Padma TAN ta...@gis.a-star.edu.sg wrote:
Hi,
Can I just install numpy and scipy without ATLAS? And what does this means
gnu: no Fortran 90 compiler found?
Yes you can install without ATLAS. And BLAS and LAPACK were found so you
should be fine. Did you have an actual problem or are you asking out of
curiosity?
Numpy does not contain any Fortran code, Scipy does. But that warning
doesn't mean you have a problem - a number of compilers are checked and the
first one that's found is used.
Please also have a look at the RHEL section on
http://www.scipy.org/Installing_SciPy/Linux.
Cheers,
Ralf
Im installing on RHEL
Thanks in advance!
[r...@giswk002 numpy-1.3.0]# python setup.py build
Running from numpy source directory.
non-existing path in 'numpy/distutils': 'site.cfg'
F2PY Version 2
blas_opt_info:
blas_mkl_info:
libraries mkl,vml,guide not found in /usr/local/Python-2.6.2/lib
libraries mkl,vml,guide not found in /usr/local/lib
libraries mkl,vml,guide not found in /usr/lib
NOT AVAILABLE
atlas_blas_threads_info:
Setting PTATLAS=ATLAS
libraries ptf77blas,ptcblas,atlas not found in /usr/local/Python-2.6.2/lib
libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib
libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2
libraries ptf77blas,ptcblas,atlas not found in /usr/lib
NOT AVAILABLE
atlas_blas_info:
libraries f77blas,cblas,atlas not found in /usr/local/Python-2.6.2/lib
libraries f77blas,cblas,atlas not found in /usr/local/lib
libraries f77blas,cblas,atlas not found in /usr/lib/sse2
libraries f77blas,cblas,atlas not found in /usr/lib
NOT AVAILABLE
/usr/local/numpy-1.3.0/numpy/distutils/system_info.py:1383: UserWarning:
Atlas (http://math-atlas.sourceforge.net/) libraries not found.
Directories to search for the libraries can be specified in the
numpy/distutils/site.cfg file (section [atlas]) or by setting
the ATLAS environment variable.
warnings.warn(AtlasNotFoundError.__doc__)
blas_info:
libraries blas not found in /usr/local/Python-2.6.2/lib
libraries blas not found in /usr/local/lib
FOUND:
libraries = ['blas']
library_dirs = ['/usr/lib']
language = f77
FOUND:
libraries = ['blas']
library_dirs = ['/usr/lib']
define_macros = [('NO_ATLAS_INFO', 1)]
language = f77
lapack_opt_info:
lapack_mkl_info:
mkl_info:
libraries mkl,vml,guide not found in /usr/local/Python-2.6.2/lib
libraries mkl,vml,guide not found in /usr/local/lib
libraries mkl,vml,guide not found in /usr/lib
NOT AVAILABLE
NOT AVAILABLE
atlas_threads_info:
Setting PTATLAS=ATLAS
libraries ptf77blas,ptcblas,atlas not found in /usr/local/Python-2.6.2/lib
libraries lapack_atlas not found in /usr/local/Python-2.6.2/lib
libraries ptf77blas,ptcblas,atlas not found in /usr/local/lib
libraries lapack_atlas not found in /usr/local/lib
libraries ptf77blas,ptcblas,atlas not found in /usr/lib/sse2
libraries lapack_atlas not found in /usr/lib/sse2
libraries ptf77blas,ptcblas,atlas not found in /usr/lib
libraries lapack_atlas not found in /usr/lib
numpy.distutils.system_info.atlas_threads_info
NOT AVAILABLE
atlas_info:
libraries f77blas,cblas,atlas not found in /usr/local/Python-2.6.2/lib
libraries lapack_atlas not found in /usr/local/Python-2.6.2/lib
libraries f77blas,cblas,atlas not found in /usr/local/lib
libraries lapack_atlas not found in /usr/local/lib
libraries f77blas,cblas,atlas not found in /usr/lib/sse2
libraries lapack_atlas not found in /usr/lib/sse2
libraries f77blas,cblas,atlas not found in /usr/lib
libraries lapack_atlas not found in /usr/lib
numpy.distutils.system_info.atlas_info
NOT AVAILABLE
/usr/local/numpy-1.3.0/numpy/distutils/system_info.py:1290: UserWarning:
Atlas (http://math-atlas.sourceforge.net/) libraries not found.
Directories to search for the libraries can be specified in the
numpy/distutils/site.cfg file (section [atlas]) or by setting
the ATLAS environment variable.
warnings.warn(AtlasNotFoundError.__doc__)
lapack_info:
libraries lapack not found in /usr/local/Python-2.6.2/lib
libraries lapack not found in /usr/local/lib
FOUND:
libraries = ['lapack']
library_dirs = ['/usr/lib']
language = f77
FOUND:
libraries = ['lapack', 'blas']
library_dirs = ['/usr/lib']
define_macros = [('NO_ATLAS_INFO', 1)]
language = f77
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_src
building py_modules sources
building library npymath sources
building extension numpy.core._sort sources
adding 'build/src.linux-i686-2.6/numpy/core/include/numpy/config.h' to
sources.
adding 'build/src.linux-i686-2.6/numpy/core/include/numpy/numpyconfig.h'
to sources.
Re: [Numpy-discussion] Bug in nanmin called with unsigned integers
On May 25, 2010, at 10:57 PM, Charles R Harris wrote: On Tue, May 25, 2010 at 8:21 PM, Tony S Yu tsy...@gmail.com wrote: I got bit again by this bug with unsigned integers. (My original changes got overwritten when I updated from svn and, unfortunately, merged conflicts without actually looking over the changes.) In any case, I thought it'd be a good time to bump the issue (with patch). Cheers, -Tony PS: Just for context, this issue comes up when displaying images with Chaco (which converts images to unsigned integer arrays and calls nanmin). Fixed in r8445. Please add some tests. I'm not totally sure what's appropriate to test, so I just added a simple test to the comments for the ticket. On a side note, I noticed that all the nan-ops degenerate to their non-nan-ops counterparts (i.e. nanmin -- min) when called with integer dtypes. Below is a diff where that's made a little more obvious by returning early for integer dtypes. Cheers, -Tony Index: numpy/lib/function_base.py === --- numpy/lib/function_base.py (revision 8445) +++ numpy/lib/function_base.py (working copy) @@ -1295,15 +1295,15 @@ y = array(a, subok=True) -mask = isnan(a) # We only need to take care of NaN's in floating point arrays -if not np.issubdtype(y.dtype, np.integer): -# y[mask] = fill -# We can't use fancy indexing here as it'll mess w/ MaskedArrays -# Instead, let's fill the array directly... -np.putmask(y, mask, fill) - +if np.issubdtype(y.dtype, np.integer): +return op(y, axis=axis) +mask = isnan(a) +# y[mask] = fill +# We can't use fancy indexing here as it'll mess w/ MaskedArrays +# Instead, let's fill the array directly... +np.putmask(y, mask, fill) res = op(y, axis=axis) mask_all_along_axis = mask.all(axis=axis) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Extending documentation to c code
Wed, 26 May 2010 07:15:08 -0600, Charles R Harris wrote: On Wed, May 26, 2010 at 2:59 AM, Pauli Virtanen p...@iki.fi wrote: Wed, 26 May 2010 06:57:27 +0900, David Cournapeau wrote: [clip: doxygen] It is yet another format to use inside C sources (I don't think doxygen supports rest), and I would rather have something that is similar, ideally integrated into sphinx. It also generates rather ugly doc by default, Anyway, we can probably nevertheless just agree on a readable plain-text/ rst format, and then just use doxygen to generate the docs, as a band-aid. http://github.com/pv/numpycdoc Neat. I didn't quite see the how how you connected the rst documentation and doxygen. I didn't :) But I just did: doing this it was actually a 10 min job since Doxygen accepts HTML -- now it parses the comments as RST and renders it properly as HTML in the Doxygen output. Of course getting links etc. to work would require more effort, but that's left as an exercise for someone else to finish. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy and the Google App Engine
Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. I would like to ask your help in changing this perception. The quickest and easiest thing you can do would be to add your me too to this feature request (item #190) on the support site: http://code.google.com/p/googleappengine/issues/detail?id=190 If this issue is important to you could also consider raising this issue in the related Google Group: http://groups.google.com/group/google-appengine Letting Google know how you will use numpy would be helpful. If you or your institution would be willing to pay for service if you could deploy cloud applications that required numpy would be helpful to let them know as well. Finally, if you run into any App Engine developers (Guido included) let them know that you would like to see numpy added. Thank you for your time and consideration. Chris -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Patch] Fix memmap pickling
On Mon, May 24, 2010 at 3:37 PM, Gael Varoquaux gael.varoqu...@normalesup.org wrote: On Mon, May 24, 2010 at 03:33:09PM -0700, Brent Pedersen wrote: On Mon, May 24, 2010 at 3:25 PM, Gael Varoquaux gael.varoqu...@normalesup.org wrote: Memmapped arrays don't pickle right. I know that to get them to really pickle and restore identically, we would need some effort. However, in the current status, pickling and restoring a memmapped array leads to tracebacks that seem like they could be avoided. I am attaching a patch with a test that shows the problem, and a fix. Should I create a ticket, or is this light-enough to be applied immediatly? also check this: http://projects.scipy.org/numpy/ticket/1452 still needs work. Does look good. Is there an ETA for your patch to be applied? Right now this bug is making code crash when memmapped arrays are used (eg multiprocessing), so a hot fix can be useful, without removing any merit to your work that addresses the underlying problem. Cheers, Gaël ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion gael, not sure about ETA of application. i think the main remaining problem (other than more tests) is py3 support--as charris points out in the ticket. i have a start which shadows numpy's __getitem__, but havent fixed all the bugs--and not sure that's a good idea. my original patch was quite simple as well, but once it starts supporting all versions and more edge cases ... ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy and the Google App Engine
Christopher Hanley wrote: Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. Something to keep in mind: It's rather trivial to write code to intentionally crash the Python interpreter using pure Python code and NumPy (or overwrite data in it, run custom assembly code...in short, NumPy is a big gaping security hole in this context). This obviously can't go on in the AppEngine. So this probably involves a considerable amount of work in the NumPy source code base as well, it's not simply about verifying. -- Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] numpy and the Google App Engine
On Wed, May 26, 2010 at 12:54 PM, Robert Kern robert.k...@gmail.com wrote: On Wed, May 26, 2010 at 12:19, Christopher Hanley chan...@stsci.edu wrote: Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Not really. It is not intended for such purposes. It is intended for the easy deployment and horizontal scaling of web applications. Each individual request is very short; it is limited to 10 seconds of CPU time. While numpy would be useful for scientific web applications (not least because it would help you keep to that 10 second limit when doing things like simple image processing or summary statistics or whatever), it is not a source of CPU cycles. Services like Amazon EC2 or Rackspace Cloud are much closer to what you want. PiCloud provides an even nicer interface for you: http://www.picloud.com/ In my conversations with the developers they indicated that it could be used for both. However, either use case would be useful for scientific computing. Disclosure: Enthought partners with PiCloud to provide most EPD libraries. I can't say I'm disinterested in promoting it, but it *is* a really powerful product that *does* provide CPU cycles for scientific computing with an interface much more suited to it than GAE. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. I would like to ask your help in changing this perception. The quickest and easiest thing you can do would be to add your me too to this feature request (item #190) on the support site: http://code.google.com/p/googleappengine/issues/detail?id=190 My understanding is that they hate me too comments. They ask that you star the issue instead. I would be happy to see any support either starring or me too comments. Their comments to me was that they saw no interest. In my opinion any indication of interest would be a positive. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy and the Google App Engine
On Wed, May 26, 2010 at 12:49 PM, Dag Sverre Seljebotn da...@student.matnat.uio.no wrote: Christopher Hanley wrote: Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. Something to keep in mind: It's rather trivial to write code to intentionally crash the Python interpreter using pure Python code and NumPy (or overwrite data in it, run custom assembly code...in short, NumPy is a big gaping security hole in this context). This obviously can't go on in the AppEngine. So this probably involves a considerable amount of work in the NumPy source code base as well, it's not simply about verifying. Agreed. Perhaps the recently discussed rework of the C internals will better allow a security audit of numpy. At that point perhaps the numpy community could more easily work with Google to fix security problems. -- Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] numpy and the Google App Engine
On Wed, May 26, 2010 at 12:19, Christopher Hanley chan...@stsci.edu wrote: Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Not really. It is not intended for such purposes. It is intended for the easy deployment and horizontal scaling of web applications. Each individual request is very short; it is limited to 10 seconds of CPU time. While numpy would be useful for scientific web applications (not least because it would help you keep to that 10 second limit when doing things like simple image processing or summary statistics or whatever), it is not a source of CPU cycles. Services like Amazon EC2 or Rackspace Cloud are much closer to what you want. PiCloud provides an even nicer interface for you: http://www.picloud.com/ Disclosure: Enthought partners with PiCloud to provide most EPD libraries. I can't say I'm disinterested in promoting it, but it *is* a really powerful product that *does* provide CPU cycles for scientific computing with an interface much more suited to it than GAE. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. I would like to ask your help in changing this perception. The quickest and easiest thing you can do would be to add your me too to this feature request (item #190) on the support site: http://code.google.com/p/googleappengine/issues/detail?id=190 My understanding is that they hate me too comments. They ask that you star the issue instead. -- 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy and the Google App Engine
On Wed, May 26, 2010 at 10:37 AM, Christopher Hanley chan...@stsci.eduwrote: On Wed, May 26, 2010 at 12:49 PM, Dag Sverre Seljebotn da...@student.matnat.uio.no wrote: Christopher Hanley wrote: Greetings, Google provides a product called App Engine. The description from their site follows, Google App Engine enables you to build and host web apps on the same systems that power Google applications. App Engine offers fast development and deployment; simple administration, with no need to worry about hardware, patches or backups; and effortless scalability. You can deploy applications written in either Python or JAVA. There are free and paid versions of the service. The Google App Engine would appear to be a powerful source of CPU cycles for scientific computing. Unfortunately this is currently not the case because numpy is not one of the supported libraries. The Python App Engine allows only the installation of user supplied pure Python code. I have recently returned from attending the Google I/O conference in San Francisco. While there I inquired into the possibility of getting numpy added. The basic response was that there doesn't appear to be much interest from the community given the amount of work it would take to vet and add numpy. Something to keep in mind: It's rather trivial to write code to intentionally crash the Python interpreter using pure Python code and NumPy (or overwrite data in it, run custom assembly code...in short, NumPy is a big gaping security hole in this context). This obviously can't go on in the AppEngine. So this probably involves a considerable amount of work in the NumPy source code base as well, it's not simply about verifying. Agreed. Perhaps the recently discussed rework of the C internals will better allow a security audit of numpy. My guess is that when the fur begins to fly, submitted tickets will receive more attention, i.e., if you really want to see this done...file a ticket. (IMO, it's *never* wasted effort to do this: the worst that can happen is that some - recorded - person will close it as will not do, and if for some unforeseeable reason they're unwilling to include an explanation as to why, well, you'll know where they live, so to speak.) DG At that point perhaps the numpy community could more easily work with Google to fix security problems. -- Dag Sverre ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Christopher Hanley Senior Systems Software Engineer Space Telescope Science Institute 3700 San Martin Drive Baltimore MD, 21218 (410) 338-4338 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Mathematician: noun, someone who disavows certainty when their uncertainty set is non-empty, even if that set has measure zero. Hope: noun, that delusive spirit which escaped Pandora's jar and, with her lies, prevents mankind from committing a general suicide. (As interpreted by Robert Graves) ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
2010/5/25 Stéfan van der Walt ste...@sun.ac.za: Awesome! Since github now supports SVN interaction, and all the core devs use Git, now might be a good time to move the entire numpy source tree? It will certainly make it easier to merge the refactor changes! I would love to move numpy to github as well. Almost everything I work on is there now and I am really enjoying using git and the github infrastructure is really nice. This is obviously a separate issue and one that shouldn't deflect the discussion on the proposed refactoring. But given how many of the developers are using git-svn and that you can use an svn client with github, it might be worth having a quick discussion about this in the near future. For instance, I wonder how many of the developer's prefer using git at this point. Also it would be interesting to hear from any of the developer's who would be opposed to git. A few year's ago this was a hot topic for discussion, but it may be that this isn't very controversial at this point. Jarrod ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 1:03 PM, Jarrod Millman mill...@berkeley.eduwrote: 2010/5/25 Stéfan van der Walt ste...@sun.ac.za: Awesome! Since github now supports SVN interaction, and all the core devs use Git, now might be a good time to move the entire numpy source tree? It will certainly make it easier to merge the refactor changes! I would love to move numpy to github as well. Almost everything I work on is there now and I am really enjoying using git and the github infrastructure is really nice. This is obviously a separate issue and one that shouldn't deflect the discussion on the proposed refactoring. But given how many of the developers are using git-svn and that you can use an svn client with github, it might be worth having a quick discussion about this in the near future. For instance, I wonder how many of the developer's prefer using git at this point. Also it would be interesting to hear from any of the developer's who would be opposed to git. A few year's ago this was a hot topic for discussion, but it may be that this isn't very controversial at this point. I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. However, It needs user testing. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Bug in frompyfunc starting at 10000 elements?
And in 2.0.0.dev8437. More hints: Assume has shape (N, Da) and b has shape (N, Db) * There is a problem wben N = 1, Db=1 and Da 1. * There is no problem when N = 1, Da=1 and Db 1. * The first row is OK, but for all others, there is one error per row, appearing in first column, then last column, first, etc. Happy debugging ! David H. On Fri, May 21, 2010 at 9:22 PM, David Warde-Farley d...@cs.toronto.edu wrote: Confirmed in NumPy 1.4.1, Py 2.6.5. David On Fri, 21 May 2010, James Bergstra wrote: Hi all, I'm wondering if this is a bug... Something strange happens with my ufunc as soon as I use 1 elements. As the test shows, the ufunc computes the correct result for either the first or last elements, but both at the same time is no good. Turns out I'm only running numpy 1.3.0 with Python 2.6.4... could someone with a more recent installation maybe check to see if this has been fixed? Thanks, def test_ufunc(): np = numpy rng = np.random.RandomState(2342) a = rng.randn(1, 2) b = rng.randn(1, 1) f = lambda x,y:x*y ufunc = np.frompyfunc(lambda *x:numpy.prod(x), 2, 1) def g(x,y): return np.asarray(ufunc(x,y), dtype='float64') assert numpy.allclose(f(a[:-1],b[:-1]), g(a[:-1],b[:-1])) # PASS assert numpy.allclose(f(a[1:],b[1:]), g(a[1:],b[1:])) # PASS assert numpy.allclose(f(a,b), g(a,b)) # FAIL -- http://www-etud.iro.umontreal.ca/~bergstrj ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 1:54 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, May 26, 2010 at 1:03 PM, Jarrod Millman mill...@berkeley.eduwrote: 2010/5/25 Stéfan van der Walt ste...@sun.ac.za: Awesome! Since github now supports SVN interaction, and all the core devs use Git, now might be a good time to move the entire numpy source tree? It will certainly make it easier to merge the refactor changes! I would love to move numpy to github as well. Almost everything I work on is there now and I am really enjoying using git and the github infrastructure is really nice. This is obviously a separate issue and one that shouldn't deflect the discussion on the proposed refactoring. But given how many of the developers are using git-svn and that you can use an svn client with github, it might be worth having a quick discussion about this in the near future. For instance, I wonder how many of the developer's prefer using git at this point. Also it would be interesting to hear from any of the developer's who would be opposed to git. A few year's ago this was a hot topic for discussion, but it may be that this isn't very controversial at this point. I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. However, It needs user testing. A newish git windows client I hadn't heard of before is gitextensionshttp://code.google.com/p/gitextensions/ . Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Thu, May 27, 2010 at 4:54 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, May 26, 2010 at 1:03 PM, Jarrod Millman mill...@berkeley.edu wrote: 2010/5/25 Stéfan van der Walt ste...@sun.ac.za: Awesome! Since github now supports SVN interaction, and all the core devs use Git, now might be a good time to move the entire numpy source tree? It will certainly make it easier to merge the refactor changes! I would love to move numpy to github as well. Almost everything I work on is there now and I am really enjoying using git and the github infrastructure is really nice. This is obviously a separate issue and one that shouldn't deflect the discussion on the proposed refactoring. But given how many of the developers are using git-svn and that you can use an svn client with github, it might be worth having a quick discussion about this in the near future. For instance, I wonder how many of the developer's prefer using git at this point. Also it would be interesting to hear from any of the developer's who would be opposed to git. A few year's ago this was a hot topic for discussion, but it may be that this isn't very controversial at this point. I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. However, It needs user testing. As I mentioned in a previous post, there is smartgit, which is free for personal use, and is a graphical UI (does *not* depend on the mingw port of git, uses the reimplementation of git jgit in java used in google for android I believe). gitextensions is just a GUI around the mingw tools, and as such is less reliable. github also supports smart http for people behind proxies (although I don't know about the authentification issues if any). Trac and buildbot could use a svn mirror as provided by github for the time being, although there seems to be an issue with the numpy repo ATM (maybe my fault: http://support.github.com/discussions/repos/3155-svn-checkout-error-200-ok-error) David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] curious about how people would feel about moving to github
Hello, I changed the subject line for this thread, since I didn't want to hijack another thread. Anyway, I am not proposing that we actually decide whether to move to git and github now, but I am just curious how people would feel. We had a conversation about this a few years ago and it was quite contentious at the time. Since then, I believe a number of us have started using git and github for most of our work. And there are a number of developers using git-svn to develop numpy now. So I was curious to get a feeling for what people would think about it, if we moved to git. (I don't want to rehash the arguments for the move.) Anyway, Chuck listed the main concerns we had previously when we discussed moving from svn to git. See the discussion below. Are there any other concerns? Am I right in thinking that most of the developers would prefer git at this point? Or are there still a number of developers who would prefer using svn still? On Wed, May 26, 2010 at 12:54 PM, Charles R Harris charlesr.har...@gmail.com wrote: I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. I was under the impression that there were a number of decent git clients for Windows now, but I don't know anyone who develops on Windows. Are there any NumPy developers who use Windows who could check out the current situation? Pulling from github with an svn client works very well, so buildbot could continue working as is: http://github.com/blog/626-announcing-svn-support And if it turns out the Windows clients are still not good enough, we could look into the recently add svn write support to github: http://github.com/blog/644-subversion-write-support No need for us to make any changes immediately. I am just curious how people would feel about it at this point. Jarrod ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On May 26, 2010, at 3:50 AM, Sebastian Walter wrote: I'm a potential user of the C-API and therefore I'm very interested in the outcome. In the previous discussion (http://comments.gmane.org/gmane.comp.python.numeric.general/37409) many different views on what the new C-API should be were expressed. Naturally, I wonder if the new C-API will be useful for my purposes. So, I'm not so excited about a refactoring log where only the progress is reported. I fear that some (potentially minor) design decisions would render the new C-API useless for me. So my question is: Does this refactoring log also include something like a Numpy Enhancement Proposal? Something that can be discussed beforehand? I.e., will there be a detailed description (i.e. code examples) what the goal of the refactoring is? If there is any interest, I could provide some simple test examples in C that would explain what I'd like to be able to do with the new C-API. Our team would love to see this if possible. -Travis Sebastian On Wed, May 26, 2010 at 8:21 AM, David Goldsmith d.l.goldsm...@gmail.com wrote: On Tue, May 25, 2010 at 9:22 PM, Travis Oliphant oliph...@enthought.com wrote: On May 25, 2010, at 4:49 PM, David Goldsmith wrote: Travis: do you already have a place on the NumPy Development Wiki where you're (b)logging your design decisions? Seems like a good way for concerned parties to monitor your choices in more or less real time and thus provide comment in a timely fashion. This is a great idea of course and we will definitely post progess there. Thanks; specific URL please, when available; plus, prominently feature (a link to) the location on the Development Wiki home page, at the very least (i.e., if not also on the NumPy home page). So far, the code has been reviewed, I.e., the existing code, yes? and several functions identified for re-factoring. Please enumerate on the Wiki Refactoring Log (name tentative - I don't care what we call it, just so long as it exists, its purpose is clear, and we all know where it is). This is taking place in a github branch of numpy called numpy refactor. This = the actual creation/modification of code, yes? DG -Travis DG On Tue, May 25, 2010 at 2:19 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 25, 2010 at 2:54 PM, Travis Oliphant oliph...@enthought.com wrote: On May 25, 2010, at 2:50 PM, Charles R Harris wrote: On Tue, May 25, 2010 at 1:37 PM, Travis Oliphant oliph...@enthought.com wrote: Hi everyone, There has been some talk about re-factoring NumPy to separate out the Python C-API layer and make NumPy closer to a C-library. I know there are a few different ideas about what this means, and also that people are very busy. I also know there is a NumPy 2.0 release that is in the works. I'm excited to let everyone know that we (at Enthought) have been able to find resources (about 3 man months) to work on this re- factoring project and Scott and Jason (both very experienced C and Python programmers) are actively pursuing it.My hope is that NumPy 2.0 will contain this re-factoring (which should be finished just after SciPy 2010 --- where I'm going to organize a Sprint on NumPy which will include at least date-time improvements and re-factoring work). While we have specific goals for the re-factoring, we want this activity to be fully integrated with the NumPy community and Scott and Jason want to interact with the community as much as feasible as they suggest re-factoring changes (though they both have more experience with phone-conversations to resolve concerns than email chains and so some patience from everybody will be appreciated). Because Jason and Scott are new to this mailing list (but not new to NumPy), I wanted to introduce them so they would feel more comfortable posting questions and people would have some context as to what they were trying to do. Scott and Jason are both very proficient and skilled programmers and I have full confidence in their abilities. That said, we very much want the input of as many people as possible as we pursue the goal of grouping together more tightly the Python C-API interface layer to NumPy. I will be involved in some of the discussions, but am currently on a different project which has tight schedules and so I will only be able to provide limited mailing-list visibility. I think 2.0 would be a bit early for this. Is there any reason it couldn't be done in 2.1? What is the planned policy with regards to the visible interface for extensions? It would also be nice to have a rough idea of how the resulting code would be layered, i.e., what is the design for this re-factoring. Simply having a design would be a major step forward. The problem with doing it in 2.1 is that this re-factoring will
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On May 26, 2010, at 5:31 AM, Pauli Virtanen wrote: Wed, 26 May 2010 10:50:19 +0200, Sebastian Walter wrote: I'm a potential user of the C-API and therefore I'm very interested in the outcome. In the previous discussion (http://comments.gmane.org/gmane.comp.python.numeric.general/37409) many different views on what the new C-API should be were expressed. I believe the aim of the refactor is to *not* change the C-API at all, but separate it internally from the routines that do the heavy lifting. Externally, Numpy would still look the same, but be more easy to maintain. The routines that do the heavy lifting could then be good for reuse and be more easy to maintain, but I think how and where they would be exposed hasn't been discussed so far... This is correct. In our plans, the current NumPy C-API would not change. Clearly there will be another potential API that could be used by other systems, but exactly what this is should be discussed and decided upon over time. I don't think our goals for the re-factoring depends on how this is done exactly. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On May 26, 2010, at 6:40 AM, Sebastian Walter wrote: On Wed, May 26, 2010 at 12:31 PM, Pauli Virtanen p...@iki.fi wrote: Wed, 26 May 2010 10:50:19 +0200, Sebastian Walter wrote: I'm a potential user of the C-API and therefore I'm very interested in the outcome. In the previous discussion (http://comments.gmane.org/gmane.comp.python.numeric.general/ 37409) many different views on what the new C-API should be were expressed. I believe the aim of the refactor is to *not* change the C-API at all, but separate it internally from the routines that do the heavy lifting. Externally, Numpy would still look the same, but be more easy to maintain. Sorry for the confusion. By C-API I meant a C-API that would be independent of the CPython API. The routines that do the heavy lifting could then be good for reuse and be more easy to maintain, but I think how and where they would be exposed hasn't been discussed so far... I had the impression that the goal is not only to have code that is easier to maintain but to give developers the possibility to use numpy functionality (broadcasting, ufuncs, ...) within C code without having to use CPython API (refcounts, construction of PyObjects etc.). This is partially correct. There may be a need to have some stub implementation of some aspects of the Python C-API (probably at least reference counting and exception handling for now). We don't need to work all of this out initially. I think getting the separation done in the next several weeks will spawn conversations and ideas that may take several months to work out the new C-level-only API. That interface API is important in the short term, but also one that could change over the next several months. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On May 26, 2010, at 5:47 PM, Jarrod Millman wrote: Hello, I changed the subject line for this thread, since I didn't want to hijack another thread. Anyway, I am not proposing that we actually decide whether to move to git and github now, but I am just curious how people would feel. We had a conversation about this a few years ago and it was quite contentious at the time. Since then, I believe a number of us have started using git and github for most of our work. And there are a number of developers using git-svn to develop numpy now. So I was curious to get a feeling for what people would think about it, if we moved to git. (I don't want to rehash the arguments for the move.) I think we are ready for such a move.Someone should think about the implications, though (with Trac integration, check-in mailings, etc.) and make sure we get something we all like. Somebody probably has thought through all of these things already, though. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 4:12 PM, Travis Oliphant oliph...@enthought.com wrote: I think we are ready for such a move. Someone should think about the implications, though (with Trac integration, check-in mailings, etc.) and make sure we get something we all like. Somebody probably has thought through all of these things already, though. Cool. At this point, I am just testing the water. If enough people seem to be OK with the idea in general, I can spend some time looking into the details more closely. Before we make an actual decision, it would be worth turning this into an actual NEP and then asking people to review it. Jarrod ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
Hi, I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. However, It needs user testing. For windows - I think honestly this is now not a serious barrier to using git. I've installed msysgit on 4 or 5 machines recently, and it has been very smooth - as well as providing a nice bash shell. I think it would be a huge reduction in the barrier to contributing to numpy if we could change to git. Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On 26 May 2010 16:12, Travis Oliphant oliph...@enthought.com wrote: I changed the subject line for this thread, since I didn't want to hijack another thread. Anyway, I am not proposing that we actually decide whether to move to git and github now, but I am just curious how people would feel. We had a conversation about this a few years ago and it was quite contentious at the time. Since then, I believe a number of us have started using git and github for most of our work. And there are a number of developers using git-svn to develop numpy now. So I was curious to get a feeling for what people would think about it, if we moved to git. (I don't want to rehash the arguments for the move.) I think we are ready for such a move. Someone should think about the implications, though (with Trac integration, check-in mailings, etc.) and make sure we get something we all like. Somebody probably has thought through all of these things already, though. Awesome, if there's enough interest I'll help Jarrod out on the NEP. I've been looking at GitHub's Trac integration, and it seems that we should be able to have the same level of integration with the bugtracker as we currently do. Their plugin is available here: http://github.com/davglass/github-trac/ The SVN-checkout functionality should take care of the build bot. As a bonus, we no longer have to administrate user accounts. Converting the SVN repo to Git should pose no problem. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] zeros_like and friends shouldn't use ndarray.__new__(type(a), ...)
Ping? On 5/13/2010 6:34 PM, Jim Porter wrote: Ok, let's try sending this message again, since it looks like I can't send from gmane... (See discussion on python-list at http://permalink.gmane.org/gmane.comp.python.general/661328 for context) numpy.zeros_like contains the following code: def zeros_like(a): if isinstance(a, ndarray): res = ndarray.__new__(type(a), a.shape, a.dtype, order=a.flags.fnc) res.fill(0) return res ... This is a problem because basetype.__new__(subtype, ...) raises an exception when subtype is defined from C (specifically, when Py_TPFLAGS_HEAPTYPE is not set). There's a check in Objects/typeobject.c in tp_new_wrapper that disallows this (you can grep for is not safe to find there the exception is raised). The end result is that it's impossible to use zeros_like, ones_like or empty_like with ndarray subtypes defined in C. While I'm still not sure why Python needs this check in general, Robert Kern pointed out that the problem can be fixed pretty easily in NumPy by changing zeros_like and friends to something like this (with some modifications from me): def zeros_like(a): if isinstance(a, ndarray): res = numpy.zeros(a.shape, a.dtype, order=a.flags.fnc) res = res.view(type(a)) res.__array_finalize__(a) return res ... - Jim ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 7:44 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. However, It needs user testing. For windows - I think honestly this is now not a serious barrier to using git. I've installed msysgit on 4 or 5 machines recently, and it has been very smooth - as well as providing a nice bash shell. there is no such thing as a nice bash shell for a windows user. I have no idea how to use one. Josef I think it would be a huge reduction in the barrier to contributing to numpy if we could change to git. Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
Hi, there is no such thing as a nice bash shell for a windows user. I have no idea how to use one. It is a nice bash shell. You may not want a nice bash shell ;) I can't imagine you'd object to one though. It's just a useful place to type git commands, with file / directory path autocompletion, git branch autocompletion and so on. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 7:25 PM, josef.p...@gmail.com wrote: On Wed, May 26, 2010 at 7:44 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. However, It needs user testing. For windows - I think honestly this is now not a serious barrier to using git. I've installed msysgit on 4 or 5 machines recently, and it has been very smooth - as well as providing a nice bash shell. there is no such thing as a nice bash shell for a windows user. I have no idea how to use one. Heh. Can you to try the svn interface to github using your favorite svn ap. I suppose we need to set up a test account there. Is it possible to have a multiple user git account on github, or is it all push and merge? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 7:34 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, there is no such thing as a nice bash shell for a windows user. I have no idea how to use one. It is a nice bash shell. You may not want a nice bash shell ;) I can't imagine you'd object to one though. It's just a useful place to type git commands, with file / directory path autocompletion, git branch autocompletion and so on. Any shell on windows is a pain, if only because of the spaces in the filenames. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
2010/5/26 Stéfan van der Walt ste...@sun.ac.za: On 26 May 2010 16:12, Travis Oliphant oliph...@enthought.com wrote: I changed the subject line for this thread, since I didn't want to hijack another thread. Anyway, I am not proposing that we actually decide whether to move to git and github now, but I am just curious how people would feel. We had a conversation about this a few years ago and it was quite contentious at the time. Since then, I believe a number of us have started using git and github for most of our work. And there are a number of developers using git-svn to develop numpy now. So I was curious to get a feeling for what people would think about it, if we moved to git. (I don't want to rehash the arguments for the move.) I think we are ready for such a move. Someone should think about the implications, though (with Trac integration, check-in mailings, etc.) and make sure we get something we all like. Somebody probably has thought through all of these things already, though. Awesome, if there's enough interest I'll help Jarrod out on the NEP. I've been looking at GitHub's Trac integration, and it seems that we should be able to have the same level of integration with the bugtracker as we currently do. Their plugin is available here: http://github.com/davglass/github-trac/ The SVN-checkout functionality should take care of the build bot. As a bonus, we no longer have to administrate user accounts. Converting the SVN repo to Git should pose no problem. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion You are all probably aware of this, but I just wanted it said. I do understand the advantage of being able to pull from someone's Python 3 branch (like scipy) as well as some of the more experimental side like the proposed refactoring. All that I ask is that there is one official place to do 'git clone' or 'git pull' from a single official branch. I do not think that it is good to tell users to pull from different branches especially if these branches have conflicts. It also provides a common foundation to troubleshoot problems (of course you don't see it because you don't have that branch...). Yet I do understand that any release candidate can be pulled from any tree (as happens with the Linux kernel) and that this should be more of guide than a fixed rule. Bruce ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 8:37 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, May 26, 2010 at 7:34 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, there is no such thing as a nice bash shell for a windows user. I have no idea how to use one. It is a nice bash shell. You may not want a nice bash shell ;) I can't imagine you'd object to one though. It's just a useful place to type git commands, with file / directory path autocompletion, git branch autocompletion and so on. Any shell on windows is a pain, if only because of the spaces in the filenames. Why? Can't you just escape the spaces with backslashes... oh, nevermind... Ben Root Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Thu, May 27, 2010 at 10:37 AM, Bruce Southey bsout...@gmail.com wrote: 2010/5/26 Stéfan van der Walt ste...@sun.ac.za: On 26 May 2010 16:12, Travis Oliphant oliph...@enthought.com wrote: I changed the subject line for this thread, since I didn't want to hijack another thread. Anyway, I am not proposing that we actually decide whether to move to git and github now, but I am just curious how people would feel. We had a conversation about this a few years ago and it was quite contentious at the time. Since then, I believe a number of us have started using git and github for most of our work. And there are a number of developers using git-svn to develop numpy now. So I was curious to get a feeling for what people would think about it, if we moved to git. (I don't want to rehash the arguments for the move.) I think we are ready for such a move. Someone should think about the implications, though (with Trac integration, check-in mailings, etc.) and make sure we get something we all like. Somebody probably has thought through all of these things already, though. Awesome, if there's enough interest I'll help Jarrod out on the NEP. I've been looking at GitHub's Trac integration, and it seems that we should be able to have the same level of integration with the bugtracker as we currently do. Their plugin is available here: http://github.com/davglass/github-trac/ The SVN-checkout functionality should take care of the build bot. As a bonus, we no longer have to administrate user accounts. Converting the SVN repo to Git should pose no problem. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion You are all probably aware of this, but I just wanted it said. I do understand the advantage of being able to pull from someone's Python 3 branch (like scipy) as well as some of the more experimental side like the proposed refactoring. There could (and should) be a github repo on scipy.org. This would be used as the reference. Something that needs being discussed on is how people will work together - going to fulltime git means a change in how to interact compared to git-svn (no more rebase to make changes visible, etc...). I am wondering whether we should follow the pull model - maybe through a gateway, I am not sure: http://www.selenic.com/pipermail/mercurial/2008-July/020116.html It also provides a common foundation to troubleshoot problems (of course you don't see it because you don't have that branch...). Yet I do understand that any release candidate can be pulled from any tree (as happens with the Linux kernel) and that this should be more of guide than a fixed rule. The whole point of DVCS is that it is trivial to set up an official repo where the releases are done from, without preventing people to work as they see fit. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
Hi Jarrod, I'm in favour of the switch, though I don't use Windows. I find git far more convenient to use than SVN; I've been using git-svn, and in spite of the headaches it's caused me I still prefer it to raw SVN. It seems to me that git's flexibility in how people collaborate means we can do a certain amount of figuring out after the switch. My experience with a small project has been that anyone who wants to make major changes just clones the repository on github and makes the changes; then we email the main author to ask him to pull particular branches into the main repo. It works well enough. Anne On 26 May 2010 19:47, Jarrod Millman mill...@berkeley.edu wrote: Hello, I changed the subject line for this thread, since I didn't want to hijack another thread. Anyway, I am not proposing that we actually decide whether to move to git and github now, but I am just curious how people would feel. We had a conversation about this a few years ago and it was quite contentious at the time. Since then, I believe a number of us have started using git and github for most of our work. And there are a number of developers using git-svn to develop numpy now. So I was curious to get a feeling for what people would think about it, if we moved to git. (I don't want to rehash the arguments for the move.) Anyway, Chuck listed the main concerns we had previously when we discussed moving from svn to git. See the discussion below. Are there any other concerns? Am I right in thinking that most of the developers would prefer git at this point? Or are there still a number of developers who would prefer using svn still? On Wed, May 26, 2010 at 12:54 PM, Charles R Harris charlesr.har...@gmail.com wrote: I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. I was under the impression that there were a number of decent git clients for Windows now, but I don't know anyone who develops on Windows. Are there any NumPy developers who use Windows who could check out the current situation? Pulling from github with an svn client works very well, so buildbot could continue working as is: http://github.com/blog/626-announcing-svn-support And if it turns out the Windows clients are still not good enough, we could look into the recently add svn write support to github: http://github.com/blog/644-subversion-write-support No need for us to make any changes immediately. I am just curious how people would feel about it at this point. Jarrod ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
I wouldn't call myself a developer, but I have been wanting to contribute recently. I learned source control with svn, so I am much more comfortable with it. My one attempt at using git for a personal project ended in failure. Then I discovered this guide, Git-SVN Crash Course: http://git.or.cz/course/svn.html I hope this would be useful to other subversioners like me who might be hesistant to switch to git. Ben Root On Wed, May 26, 2010 at 5:47 PM, Jarrod Millman mill...@berkeley.eduwrote: Hello, I changed the subject line for this thread, since I didn't want to hijack another thread. Anyway, I am not proposing that we actually decide whether to move to git and github now, but I am just curious how people would feel. We had a conversation about this a few years ago and it was quite contentious at the time. Since then, I believe a number of us have started using git and github for most of our work. And there are a number of developers using git-svn to develop numpy now. So I was curious to get a feeling for what people would think about it, if we moved to git. (I don't want to rehash the arguments for the move.) Anyway, Chuck listed the main concerns we had previously when we discussed moving from svn to git. See the discussion below. Are there any other concerns? Am I right in thinking that most of the developers would prefer git at this point? Or are there still a number of developers who would prefer using svn still? On Wed, May 26, 2010 at 12:54 PM, Charles R Harris charlesr.har...@gmail.com wrote: I think the main problem has been windows compatibility. Git is best from the command line whereas the windows command line is an afterthought. Another box that needs a check-mark is the buildbot. If svn clients are supported then it may be that neither of those are going to be a problem. I was under the impression that there were a number of decent git clients for Windows now, but I don't know anyone who develops on Windows. Are there any NumPy developers who use Windows who could check out the current situation? Pulling from github with an svn client works very well, so buildbot could continue working as is: http://github.com/blog/626-announcing-svn-support And if it turns out the Windows clients are still not good enough, we could look into the recently add svn write support to github: http://github.com/blog/644-subversion-write-support No need for us to make any changes immediately. I am just curious how people would feel about it at this point. Jarrod ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 9:37 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, May 26, 2010 at 7:34 PM, Matthew Brett matthew.br...@gmail.com wrote: Hi, there is no such thing as a nice bash shell for a windows user. I have no idea how to use one. It is a nice bash shell. You may not want a nice bash shell ;) I can't imagine you'd object to one though. It's just a useful place to type git commands, with file / directory path autocompletion, git branch autocompletion and so on. Any shell on windows is a pain, if only because of the spaces in the filenames. When I'm using git, or bzr or svn I use the windows shell which I'm very familiar with ,and allows standard copy-paste and has quotes. But since, I think, there are no numpy developers on Windows, and I'm the only one for scipy, and occasional commits I can do with anything, I won't argue this time. Josef Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
Hi, Any shell on windows is a pain, if only because of the spaces in the filenames. When I'm using git, or bzr or svn I use the windows shell which I'm very familiar with ,and allows standard copy-paste and has quotes. But since, I think, there are no numpy developers on Windows, and I'm the only one for scipy, and occasional commits I can do with anything, I won't argue this time. I've been testing quite a bit on windows recently, and I used to use windows all the time. I've found msysgit to be pretty good. I personally have always hated the windows shell, but you can use msysgit from the windows shell if you prefer... If you're OK with bzr or svn from the windows command line, I am sure git will pose no major problems. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
Hi, It seems to me that git's flexibility in how people collaborate means we can do a certain amount of figuring out after the switch. This is very well said and true to our recent experience with nipy and ipython: http://github.com/ipython/ipython http://github.com/nipy/nipy My experience with a small project has been that anyone who wants to make major changes just clones the repository on github and makes the changes; then we email the main author to ask him to pull particular branches into the main repo. It works well enough. That's the model we've gone for in nipy and ipython too. We wrote it up in a workflow doc project. Here are the example docs giving the git workflow for ipython: https://cirl.berkeley.edu/mb312/gitwash/ and in particular: https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 6:35 PM, Charles R Harris charlesr.har...@gmail.com wrote: Heh. Can you to try the svn interface to github using your favorite svn ap. I suppose we need to set up a test account there. Is it possible to have a multiple user git account on github, or is it all push and merge? Yes, that is possible. Currently it is not officially allowed according to their terms of service, but they are planning to enable that and have granted exceptions to their current policy in a few instances (that I am familiar with). But this is a detail that we can easily address in a NEP, if there seems to be interest (which there currently seems to be). So for now just keep sending emails with issues you want addressed in any actual proposal for this transition. Let's move this discussion to the git thread and use the thread for the discussion related directly to the subject line. Thanks, -- Jarrod Millman Helen Wills Neuroscience Institute 10 Giannini Hall, UC Berkeley http://cirl.berkeley.edu/ ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 8:08 PM, Matthew Brett matthew.br...@gmail.com wrote: That's the model we've gone for in nipy and ipython too. We wrote it up in a workflow doc project. Here are the example docs giving the git workflow for ipython: https://cirl.berkeley.edu/mb312/gitwash/ and in particular: https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html I would highly recommend using this workflow. Ideally, we should use the same git workflow for all the scipy-related projects. That way developers can switch between projects without having to switch workflows. The model that Matthew and Fernando developed for nipy and ipython seem like a very reasonable place to start. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] How to distinguish between number and string dypes
How do I determine if an array's (or column in a structured array) dtype is a number or a string. I see how to determine the actual dtype but all I want to know is if it is a string or a number. *Vincent Davis 720-301-3003 * vinc...@vincentdavis.net my blog http://vincentdavis.net | LinkedInhttp://www.linkedin.com/in/vincentdavis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Introduction to Scott, Jason, and (possibly) others from Enthought
On Wed, May 26, 2010 at 7:47 PM, Benjamin Root ben.r...@ou.edu wrote: On Wed, May 26, 2010 at 8:37 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, May 26, 2010 at 7:34 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, there is no such thing as a nice bash shell for a windows user. I have no idea how to use one. It is a nice bash shell. You may not want a nice bash shell ;) I can't imagine you'd object to one though. It's just a useful place to type git commands, with file / directory path autocompletion, git branch autocompletion and so on. Any shell on windows is a pain, if only because of the spaces in the filenames. Why? Can't you just escape the spaces with backslashes... oh, nevermind... Sure, no doubt the experience would cleanse my soul. But flagellation would be less painful. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 9:49 PM, Jarrod Millman mill...@berkeley.eduwrote: On Wed, May 26, 2010 at 8:08 PM, Matthew Brett matthew.br...@gmail.com wrote: That's the model we've gone for in nipy and ipython too. We wrote it up in a workflow doc project. Here are the example docs giving the git workflow for ipython: https://cirl.berkeley.edu/mb312/gitwash/ and in particular: https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html I would highly recommend using this workflow. Ideally, we should use the same git workflow for all the scipy-related projects. That way developers can switch between projects without having to switch workflows. The model that Matthew and Fernando developed for nipy and ipython seem like a very reasonable place to start. __ I wouldn't. Who is going to be the gate keeper and pull the stuff? No vacations for him/her, on 24 hour call, yes? They might as well run a dairy. And do we really want all pull requests cross-posted to the list? Linus works full time as gatekeeper for Linux and gets paid for the effort. I think a central repository model would work better for us. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 7:38 PM, Benjamin Root ben.r...@ou.edu wrote: I wouldn't call myself a developer, but I have been wanting to contribute recently. I learned source control with svn, so I am much more comfortable with it. My one attempt at using git for a personal project ended in failure. Then I discovered this guide, Git-SVN Crash Course: http://git.or.cz/course/svn.html I hope this would be useful to other subversioners like me who might be hesistant to switch to git. Thanks for the link. If we move to git, we will also develop a suggested workflow and post it online so that anyone should be able to just cut-and-paste the git commands. As Matthew mentioned both ipython and nipy have adopted the same workflow: https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html The idea of the above document is not to teach people how to use git in general, but just for the specific way git is used in the development workflow for nipy and ipython. If you have some time to look at the ipython/nipy workflow, it would be useful to know how helpful you think a document like this would be for SVNers switching to git. If you have any other suggestions for what the NEP should include, please let us know. Thanks, Jarrod PS. I am glad to hear that you are interested in contributing to NumPy development. If you are looking for a good place to start, you may want to consider helping with the 2010 summer documentation marathon or submitting a patch to address an open ticket. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On 27 May 2010 01:22, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, May 26, 2010 at 9:49 PM, Jarrod Millman mill...@berkeley.edu wrote: On Wed, May 26, 2010 at 8:08 PM, Matthew Brett matthew.br...@gmail.com wrote: That's the model we've gone for in nipy and ipython too. We wrote it up in a workflow doc project. Here are the example docs giving the git workflow for ipython: https://cirl.berkeley.edu/mb312/gitwash/ and in particular: https://cirl.berkeley.edu/mb312/gitwash/development_workflow.html I would highly recommend using this workflow. Ideally, we should use the same git workflow for all the scipy-related projects. That way developers can switch between projects without having to switch workflows. The model that Matthew and Fernando developed for nipy and ipython seem like a very reasonable place to start. __ I wouldn't. Who is going to be the gate keeper and pull the stuff? No vacations for him/her, on 24 hour call, yes? They might as well run a dairy. And do we really want all pull requests cross-posted to the list? Linus works full time as gatekeeper for Linux and gets paid for the effort. I think a central repository model would work better for us. I don't think this is as big a problem as it sounds. If the gatekeeper takes a week-long vacation, so what? People keep working on their changes independently and they can get merged when the gatekeeper gets around to it. If they want to accelerate the ultimate merging they can pull the central repository into their own and resolve all conflicts, so that the pull into the central repository goes smoothly. If the gatekeeper's away and the users want to swap patches, well, they just pull from each other's public git repositories. Anne Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
Hi, Linux has Linus, ipython has Fernando, nipy has... well, I'm sure it is somebody. Numpy and Scipy no longer have a central figure and I like it that way. There is no reason that DVCS has to inevitably lead to a central authority. I think I was trying to say that the way it looks as if it will be - before you try it - is very different from the way it actually is when you get there. Anne put the idea very well - but I still think it is very hard to understand, without trying it, just how liberating the workflow is from anxieties about central authorities and so on.You can just get on with what you want to do, talk with or merge from whoever you want, and the whole development process becomes much more fluid and productive. And I know that sounds chaotic but - it just works. Really really well. See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On 27 May 2010 01:55, Matthew Brett matthew.br...@gmail.com wrote: Hi, Linux has Linus, ipython has Fernando, nipy has... well, I'm sure it is somebody. Numpy and Scipy no longer have a central figure and I like it that way. There is no reason that DVCS has to inevitably lead to a central authority. I think I was trying to say that the way it looks as if it will be - before you try it - is very different from the way it actually is when you get there. Anne put the idea very well - but I still think it is very hard to understand, without trying it, just how liberating the workflow is from anxieties about central authorities and so on. You can just get on with what you want to do, talk with or merge from whoever you want, and the whole development process becomes much more fluid and productive. And I know that sounds chaotic but - it just works. Really really well. One way to think of it is that there is no main line of development. The only time the central repository needs to pull from the others is when a release is being prepared. As it stands we do have a single release manager, though it's not necessarily the same for each version. So if we wanted, they could just go and pull and merge the repositories of everyone who's made a useful change, then release the results. Of course, this will be vastly easier if all those other people have already merged each other's results (into different branches if appropriate). But just like now, it's the release manager's decision which changes end up in the next version. This is not the only way to do git development; it's the only one I have experience with, so I can't speak for the effectiveness of others. But I have no doubt that we can find some way that works, and I don't think we necessarily need to decide what that is any time soon. Anne See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 11:06 PM, Anne Archibald aarch...@physics.mcgill.ca wrote: On 27 May 2010 01:55, Matthew Brett matthew.br...@gmail.com wrote: Hi, Linux has Linus, ipython has Fernando, nipy has... well, I'm sure it is somebody. Numpy and Scipy no longer have a central figure and I like it that way. There is no reason that DVCS has to inevitably lead to a central authority. I think I was trying to say that the way it looks as if it will be - before you try it - is very different from the way it actually is when you get there. Anne put the idea very well - but I still think it is very hard to understand, without trying it, just how liberating the workflow is from anxieties about central authorities and so on.You can just get on with what you want to do, talk with or merge from whoever you want, and the whole development process becomes much more fluid and productive. And I know that sounds chaotic but - it just works. Really really well. One way to think of it is that there is no main line of development. The only time the central repository needs to pull from the others is when a release is being prepared. As it stands we do have a single release manager, though it's not necessarily the same for each version. So if we wanted, they could just go and pull and merge the repositories of everyone who's made a useful change, then release the results. Of course, this will be vastly easier if all those other people have already merged each other's results (into different branches if appropriate). But just like now, it's the release manager's decision which changes end up in the next version. No, at this point we don't have a release manager, we haven't since 1.2. We have people who do the builds and put them up on sourceforge, but they aren't release managers, they don't decide what is in the release or organise the effort. We haven't had a central figure since Travis got a real job ;) And now David has a real job too. I'm just pointing out that that projects like Linux and IPython have central figures because the originators are still active in the development. Let me put it this way, right now, who would you choose to pull the changes and release the official version? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On 05/27/2010 02:16 PM, Charles R Harris wrote: On Wed, May 26, 2010 at 11:06 PM, Anne Archibald aarch...@physics.mcgill.ca mailto:aarch...@physics.mcgill.ca wrote: On 27 May 2010 01:55, Matthew Brett matthew.br...@gmail.com mailto:matthew.br...@gmail.com wrote: Hi, Linux has Linus, ipython has Fernando, nipy has... well, I'm sure it is somebody. Numpy and Scipy no longer have a central figure and I like it that way. There is no reason that DVCS has to inevitably lead to a central authority. I think I was trying to say that the way it looks as if it will be - before you try it - is very different from the way it actually is when you get there. Anne put the idea very well - but I still think it is very hard to understand, without trying it, just how liberating the workflow is from anxieties about central authorities and so on. You can just get on with what you want to do, talk with or merge from whoever you want, and the whole development process becomes much more fluid and productive. And I know that sounds chaotic but - it just works. Really really well. One way to think of it is that there is no main line of development. The only time the central repository needs to pull from the others is when a release is being prepared. As it stands we do have a single release manager, though it's not necessarily the same for each version. So if we wanted, they could just go and pull and merge the repositories of everyone who's made a useful change, then release the results. Of course, this will be vastly easier if all those other people have already merged each other's results (into different branches if appropriate). But just like now, it's the release manager's decision which changes end up in the next version. No, at this point we don't have a release manager, we haven't since 1.2. We have people who do the builds and put them up on sourceforge, but they aren't release managers, they don't decide what is in the release or organise the effort. We haven't had a central figure since Travis got a real job ;) And now David has a real job too. I'm just pointing out that that projects like Linux and IPython have central figures because the originators are still active in the development. Let me put it this way, right now, who would you choose to pull the changes and release the official version? Ralf is the release manager, and for deciding what goes into the release, we do just as we do now. For small changes which do not warrant discussion, they would be handled through pull requests in github at first, but we can improve after that (for example having an automatic gatekeeper which only pulls something that would at least compile and pass the test on a linux machine). David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
Hi, No, at this point we don't have a release manager, we haven't since 1.2. We have people who do the builds and put them up on sourceforge, but they aren't release managers, they don't decide what is in the release or organise the effort. We haven't had a central figure since Travis got a real job ;) And now David has a real job too. I'm just pointing out that that projects like Linux and IPython have central figures because the originators are still active in the development. Let me put it this way, right now, who would you choose to pull the changes and release the official version? OK - for nipy - we have - I think - 5 people who can commit into the main repository. Any one of those 5 people can review someone's work, and commit into the main repository.My guess is - with numpy - there would be some number of people with the same permissions - I imagine you among them. But the rule is - No-one commits into the main repo without someone reviewing and agreeing the work Any trusted person can review. But the point is: No development in the main repo. Merges only. Why? Let's flip your question the other way round. You are saying - I want to continue (as for SVN) to develop in the main repo. But the main repo is where everyone merges from. That means that a) It makes it much harder for anyone to review your changes because they are mixed up in a lot of other changes and b) You force everyone following numpy to adopt your changes In practice - that means that you make it harder for others by making them follow your line of development when they may not want to - until it's ready. I guess you'd agree that code review is essential to good code quality - both for improving code - and for teaching. It encourages new developers because they know their work will be checked. It helps developers learn the coding guidelines and to share good practice. It helps the developers have a broad knowledge of the code base. With SVN / central repo development - that's really hard - because all the development lines get mixed up as people work in different places. With git / DVCS - it suddenly becomes absolutely natural. I think that's why people like Joel Spolsy say stuff like 'This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.' : http://www.joelonsoftware.com/items/2010/03/17.html Please - try it - see - I am absolutely sure you'll love it after a very short time... Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 11:28 PM, David da...@silveregg.co.jp wrote: On 05/27/2010 02:16 PM, Charles R Harris wrote: On Wed, May 26, 2010 at 11:06 PM, Anne Archibald aarch...@physics.mcgill.ca mailto:aarch...@physics.mcgill.ca wrote: On 27 May 2010 01:55, Matthew Brett matthew.br...@gmail.com mailto:matthew.br...@gmail.com wrote: Hi, Linux has Linus, ipython has Fernando, nipy has... well, I'm sure it is somebody. Numpy and Scipy no longer have a central figure and I like it that way. There is no reason that DVCS has to inevitably lead to a central authority. I think I was trying to say that the way it looks as if it will be - before you try it - is very different from the way it actually is when you get there. Anne put the idea very well - but I still think it is very hard to understand, without trying it, just how liberating the workflow is from anxieties about central authorities and so on. You can just get on with what you want to do, talk with or merge from whoever you want, and the whole development process becomes much more fluid and productive. And I know that sounds chaotic but - it just works. Really really well. One way to think of it is that there is no main line of development. The only time the central repository needs to pull from the others is when a release is being prepared. As it stands we do have a single release manager, though it's not necessarily the same for each version. So if we wanted, they could just go and pull and merge the repositories of everyone who's made a useful change, then release the results. Of course, this will be vastly easier if all those other people have already merged each other's results (into different branches if appropriate). But just like now, it's the release manager's decision which changes end up in the next version. No, at this point we don't have a release manager, we haven't since 1.2. We have people who do the builds and put them up on sourceforge, but they aren't release managers, they don't decide what is in the release or organise the effort. We haven't had a central figure since Travis got a real job ;) And now David has a real job too. I'm just pointing out that that projects like Linux and IPython have central figures because the originators are still active in the development. Let me put it this way, right now, who would you choose to pull the changes and release the official version? Ralf is the release manager, and for deciding what goes into the release, we do just as we do now. For small changes which do not warrant discussion, they would be handled through pull requests in github at first, but we can improve after that (for example having an automatic gatekeeper which only pulls something that would at least compile and pass the test on a linux machine). So you are saying that Ralf has to manage all the pull requests? Have you asked Ralf about that? An automatic gatekeeper is pretty much a central repository, as I was suggesting. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On 05/27/2010 02:34 PM, Charles R Harris wrote: An automatic gatekeeper is pretty much a central repository, as I was suggesting. I don't understand how centraly repository comes into this discussion - nobody has been arguing against it. The question is whether we would continue to push individual commits to it directly (push), or we should present branches to a gatekeeper. I would suggest that you look on how people do it in projects using git, there are countless ressources on how to do it, and it has worked very well for pretty much every project. I can't see how numpy would be so different that it would require something different, especially without having tried it first. If the pull model really fails, then we can always change. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 11:34 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, No, at this point we don't have a release manager, we haven't since 1.2. We have people who do the builds and put them up on sourceforge, but they aren't release managers, they don't decide what is in the release or organise the effort. We haven't had a central figure since Travis got a real job ;) And now David has a real job too. I'm just pointing out that that projects like Linux and IPython have central figures because the originators are still active in the development. Let me put it this way, right now, who would you choose to pull the changes and release the official version? OK - for nipy - we have - I think - 5 people who can commit into the main repository. Any one of those 5 people can review someone's work, and commit into the main repository.My guess is - with numpy - there would be some number of people with the same permissions - I imagine you among them. But the rule is - No-one commits into the main repo without someone reviewing and agreeing the work Any trusted person can review. But the point is: No development in the main repo. Merges only. Why? Let's flip your question the other way round. You are saying - I want to continue (as for SVN) to develop in the main repo. No, I am saying we need at least five people who can commit to the main repo. That is the central repository model. But the main repo is where everyone merges from. That means that a) It makes it much harder for anyone to review your changes because they are mixed up in a lot of other changes and b) You force everyone following numpy to adopt your changes In practice - that means that you make it harder for others by making them follow your line of development when they may not want to - until it's ready. Review is fine, and it would be nice if more people were reviewing code. At the moment I think it is just Pauli, Stefan, and myself. I guess you'd agree that code review is essential to good code quality - both for improving code - and for teaching. It encourages new developers because they know their work will be checked. It helps developers learn the coding guidelines and to share good practice. It helps the developers have a broad knowledge of the code base. With SVN / central repo development - that's really hard - because all the development lines get mixed up as people work in different places. But a repo that five folks can commit to *is* a central repository, by definition. DVCS and central repository are orthogonal concepts. With git / DVCS - it suddenly becomes absolutely natural. I think that's why people like Joel Spolsy say stuff like 'This is possibly the biggest advance in software development technology in the ten years I’ve been writing articles here.' : http://www.joelonsoftware.com/items/2010/03/17.html Please - try it - see - I am absolutely sure you'll love it after a very short time... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
Hi, No, I am saying we need at least five people who can commit to the main repo. That is the central repository model. Excellent - yes - that's reasonable. Then if you also agree to this: No development in the main repo. Merges only. then we're all in full agreement. Review is fine, and it would be nice if more people were reviewing code. At the moment I think it is just Pauli, Stefan, and myself. Right - and that is partly because it so much harder to do review with the model that we have at the moment, and partly because we don't yet have the tradition in numpy of review. I think - honestly - if we're going to be able to encourage and train new developers - we'll have to get on that as soon as we can... See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] curious about how people would feel about moving to github
On Wed, May 26, 2010 at 11:55 PM, Matthew Brett matthew.br...@gmail.comwrote: Hi, No, I am saying we need at least five people who can commit to the main repo. That is the central repository model. Excellent - yes - that's reasonable. Then if you also agree to this: No development in the main repo. Merges only. then we're all in full agreement. Review is fine, and it would be nice if more people were reviewing code. At the moment I think it is just Pauli, Stefan, and myself. Right - and that is partly because it so much harder to do review with the model that we have at the moment, and partly because we don't yet have the tradition in numpy of review. I think - honestly - if we're going to be able to encourage and train new developers - we'll have to get on that as soon as we can... See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
