Re: [Numpy-discussion] [Numpy-svn] aada93: ENH: Add 'subok' parameter to PyArray_NewLikeArray...
On Tue, Mar 15, 2011 at 7:22 PM, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/numpy/numpy Commit: aada93306acfb4e2eb816faf32652edf8825cf45 https://github.com/numpy/numpy/commit/aada93306acfb4e2eb816faf32652edf8825cf45 Author: Mark Wiebe mwwi...@gmail.com Date: 2011-03-15 (Tue, 15 Mar 2011) Changed paths: M doc/source/reference/c-api.array.rst M numpy/add_newdocs.py M numpy/core/numeric.py M numpy/core/src/multiarray/convert.c M numpy/core/src/multiarray/ctors.c M numpy/core/src/multiarray/multiarraymodule.c M numpy/core/src/umath/ufunc_object.c M numpy/core/tests/test_numeric.py Log Message: --- ENH: Add 'subok' parameter to PyArray_NewLikeArray, np.empty_like, np.zeros_like, and np.ones_like This way, the sub-type can be avoided if necessary. This helps mitigate, but doesn't fix, ticket #1753, by allowing b = np.empty_like(a, subok=False). I'm really not in a position to comment on the depths of the numpy API, but my understanding of np.any_like( ... ) was that it would create always normal ndarrays just taking shape and dtype from the given array. So what should the interpretation of subok be ? Can you elaborate ... ? Thanks, Sebastian Haase ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] aada93: ENH: Add 'subok' parameter to PyArray_NewLikeArray...
On Tue, Mar 15, 2011 at 3:25 PM, Sebastian Haase seb.ha...@gmail.com wrote: On Tue, Mar 15, 2011 at 7:22 PM, nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/numpy/numpy Commit: aada93306acfb4e2eb816faf32652edf8825cf45 https://github.com/numpy/numpy/commit/aada93306acfb4e2eb816faf32652edf8825cf45 Author: Mark Wiebe mwwi...@gmail.com Date: 2011-03-15 (Tue, 15 Mar 2011) Changed paths: M doc/source/reference/c-api.array.rst M numpy/add_newdocs.py M numpy/core/numeric.py M numpy/core/src/multiarray/convert.c M numpy/core/src/multiarray/ctors.c M numpy/core/src/multiarray/multiarraymodule.c M numpy/core/src/umath/ufunc_object.c M numpy/core/tests/test_numeric.py Log Message: --- ENH: Add 'subok' parameter to PyArray_NewLikeArray, np.empty_like, np.zeros_like, and np.ones_like This way, the sub-type can be avoided if necessary. This helps mitigate, but doesn't fix, ticket #1753, by allowing b = np.empty_like(a, subok=False). I'm really not in a position to comment on the depths of the numpy API, but my understanding of np.any_like( ... ) was that it would create always normal ndarrays just taking shape and dtype from the given array. So what should the interpretation of subok be ? Can you elaborate ... ? Thanks, Sebastian Haase ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion I know that things like numpy.ma and pandas are directly impacted by this change-- in NumPy 1.6 many API functions cannot be used on subclasses because they discard any additional information you wish to be passed on (like the mask in a masked array, for example). ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] aada93: ENH: Add 'subok' parameter to PyArray_NewLikeArray...
On Tue, Mar 15, 2011 at 12:25 PM, Sebastian Haase seb.ha...@gmail.comwrote: snip Log Message: --- ENH: Add 'subok' parameter to PyArray_NewLikeArray, np.empty_like, np.zeros_like, and np.ones_like This way, the sub-type can be avoided if necessary. This helps mitigate, but doesn't fix, ticket #1753, by allowing b = np.empty_like(a, subok=False). I'm really not in a position to comment on the depths of the numpy API, but my understanding of np.any_like( ... ) was that it would create always normal ndarrays just taking shape and dtype from the given array. So what should the interpretation of subok be ? Can you elaborate ... ? You're understanding is half-right. There was previously an inconsistency, where zeros_like and empty_like did what you expect, while ones_like kept the subtype, see this ticket: http://projects.scipy.org/numpy/ticket/929. Because ones_like is a ufunc, switching it to behave like the others did is much harder than going the other way, and intuitively I would expect *_like to produce a matrix when given a matrix, so I fixed it to preserve the subtype. This patch extends the functions to allow for a choice between the previous two behaviors. The parameter subok is exactly like subok in the array constructor, the name was chosen for consistency. -Mark ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy SVN frozen; move to Git
On Thu, Sep 16, 2010 at 1:58 AM, Pauli Virtanen p...@iki.fi wrote: Numpy SVN repository is now frozen, and does not accept new commits. Future development should end up in the Git repository: http://github.com/numpy/numpy Joining my voice to the collective thank you, I figured I'd pass along something I stumbled upon just now as I was reading on github's new (massively improved) pull requests; a nice description of branch management using git for a real-world scenario with release/development branches, etc: http://nvie.com/posts/a-successful-git-branching-model/ None of it is a new idea, but it's very nicely and concisely explained. Regards, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy SVN frozen; move to Git
On Sat, Sep 18, 2010 at 4:02 AM, Fernando Perez fperez@gmail.comwrote: On Thu, Sep 16, 2010 at 1:58 AM, Pauli Virtanen p...@iki.fi wrote: Numpy SVN repository is now frozen, and does not accept new commits. Future development should end up in the Git repository: http://github.com/numpy/numpy Joining my voice to the collective thank you, I figured I'd pass along something I stumbled upon just now as I was reading on github's new (massively improved) pull requests; a nice description of branch management using git for a real-world scenario with release/development branches, etc: http://nvie.com/posts/a-successful-git-branching-model/ None of it is a new idea, but it's very nicely and concisely explained. But the vim post was the best thing at the site ;) I've now got pathogen and snipmate in my .vim folder. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy SVN frozen; move to Git
Dear all, Numpy SVN repository is now frozen, and does not accept new commits. Future development should end up in the Git repository: http://github.com/numpy/numpy The next things on the TODO list: - Update any links that point to http://svn.scipy.org/svn/numpy or talk about SVN. E.g. numpy.org needs updating. - Put up documentation on how to contribute to Numpy via Git. Gitwash-generated stuff could be added to the Numpy docs. - Decide if the `numpy-svn` email list is still needed. Github has RSS feeds for the repositories (but it can also send email to the list, if we want to keep the list alive). - Core devs: create accounts on github.com and ask for push permissions to the numpy repository. Or, just push your changes to your personal forks, and send pull requests -- I'm sure we have enough people to handle it also this way. - Trac integration -- our bug DB will still stay at projects.scipy.org but other Trac functionality can maybe be integrated. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy SVN frozen; move to Git
On Thu, Sep 16, 2010 at 10:58 AM, Pauli Virtanen p...@iki.fi wrote: Numpy SVN repository is now frozen, and does not accept new commits. Future development should end up in the Git repository: http://github.com/numpy/numpy Beautiful! It now takes mere seconds to clone NumPy (compared to several minutes from SVN). Thanks so much to yourself and David Cournapeau for making this happen. Regards Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy SVN frozen; move to Git
Thu, 16 Sep 2010 08:58:46 +, Pauli Virtanen wrote: The next things on the TODO list: - Update any links that point to http://svn.scipy.org/svn/numpy or talk about SVN. E.g. numpy.org needs updating. - Put up documentation on how to contribute to Numpy via Git. Gitwash-generated stuff could be added to the Numpy docs. - Decide if the `numpy-svn` email list is still needed. Github has RSS feeds for the repositories (but it can also send email to the list, if we want to keep the list alive). - Core devs: create accounts on github.com and ask for push permissions to the numpy repository. Or, just push your changes to your personal forks, and send pull requests -- I'm sure we have enough people to handle it also this way. - Trac integration -- our bug DB will still stay at projects.scipy.org but other Trac functionality can maybe be integrated. And a few more: - Buildbot and buildslaves. Maybe easiest by using Github's SVN interface? http://github.com/blog/626-announcing-svn-support - Doc editor etc. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy SVN frozen; move to Git
On 09/16/2010 10:30 PM, Pauli Virtanen wrote: Thu, 16 Sep 2010 08:58:46 +, Pauli Virtanen wrote: The next things on the TODO list: - Update any links that point to http://svn.scipy.org/svn/numpy or talk about SVN. E.g. numpy.org needs updating. - Put up documentation on how to contribute to Numpy via Git. Gitwash-generated stuff could be added to the Numpy docs. - Decide if the `numpy-svn` email list is still needed. Github has RSS feeds for the repositories (but it can also send email to the list, if we want to keep the list alive). - Core devs: create accounts on github.com and ask for push permissions to the numpy repository. Or, just push your changes to your personal forks, and send pull requests -- I'm sure we have enough people to handle it also this way. - Trac integration -- our bug DB will still stay at projects.scipy.org but other Trac functionality can maybe be integrated. And a few more: - Buildbot and buildslaves. Maybe easiest by using Github's SVN interface? http://github.com/blog/626-announcing-svn-support That's what I was thinking too - but it seems that the svn support is somewhat flaky. I keep getting svn: REPORT of '/cournape/numpy.git/!svn/vcc/default': 200 OK (http://svn.github.com). May be due to some network configuration, I don't know. Would be good if someone else could check, cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy SVN frozen; move to Git
On Thu, Sep 16, 2010 at 7:21 PM, David da...@silveregg.co.jp wrote: On 09/16/2010 10:30 PM, Pauli Virtanen wrote: Thu, 16 Sep 2010 08:58:46 +, Pauli Virtanen wrote: The next things on the TODO list: - Update any links that point to http://svn.scipy.org/svn/numpy or talk about SVN. E.g. numpy.org needs updating. - Put up documentation on how to contribute to Numpy via Git. Gitwash-generated stuff could be added to the Numpy docs. - Decide if the `numpy-svn` email list is still needed. Github has RSS feeds for the repositories (but it can also send email to the list, if we want to keep the list alive). - Core devs: create accounts on github.com and ask for push permissions to the numpy repository. Or, just push your changes to your personal forks, and send pull requests -- I'm sure we have enough people to handle it also this way. - Trac integration -- our bug DB will still stay at projects.scipy.org but other Trac functionality can maybe be integrated. And a few more: - Buildbot and buildslaves. Maybe easiest by using Github's SVN interface? http://github.com/blog/626-announcing-svn-support That's what I was thinking too - but it seems that the svn support is somewhat flaky. I keep getting svn: REPORT of '/cournape/numpy.git/!svn/vcc/default': 200 OK (http://svn.github.com). May be due to some network configuration, I don't know. Would be good if someone else could check, IIRC, Stefan said that the newer version of the buildbot software works with GIT. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy svn down
At the moment... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy svn down
Sat, 17 Jul 2010 16:06:40 -0600, Charles R Harris wrote: At the moment... Chuck Worksforme at the moment. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy svn down
On Sat, Jul 17, 2010 at 17:06, Charles R Harris charlesr.har...@gmail.com wrote: At the moment... Chuck I can svn up at the moment. -- 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-svn] r8413 - trunk/numpy/lib - Author: oliphant - Add percentile function.
On Thu, Jul 8, 2010 at 12:27 PM, Sebastian Haase seb.ha...@gmail.com wrote: isn't this related to http://projects.scipy.org/numpy/ticket/626 percentile() and clamp() which was set to invalid -Sebastian The new percentile function has an axis input. I like that. scipy.stats.scoreatpercentile always works along axis 0. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r8457 - trunk
2010/6/6 Stéfan van der Walt ste...@sun.ac.za I guess this changeset is up for discussion, but I'd be very glad if we could track the .gitignore. This makes life a lot easier for everybody using git-svn. Do you really want to see all the various files that I want to ignore? It bothered me that when I edited .gitignore it would need to get committed, possibly stepping on other peoples pet version. That said, there are other options in git for ignoring files and maybe we can decide on a policy for splitting the work between them. snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r8457 - trunk
I guess this changeset is up for discussion, but I'd be very glad if we could track the .gitignore. This makes life a lot easier for everybody using git-svn. Cheers Stéfan On 6 June 2010 20:43, numpy-...@scipy.org wrote: Author: charris Date: 2010-06-06 22:43:07 -0500 (Sun, 06 Jun 2010) New Revision: 8457 Removed: trunk/.gitignore Log: Don't track .gitignore file. Deleted: trunk/.gitignore === --- trunk/.gitignore 2010-06-05 15:02:50 UTC (rev 8456) +++ trunk/.gitignore 2010-06-07 03:43:07 UTC (rev 8457) @@ -1,13 +0,0 @@ -*.pyc -*.so -*~ -\#* -__* - -build -/dist -/numpy.egg-inf -/numpy/version.py - -/tools/win32build/misc/msvcrt90/msvcr90.def -/doc/source/reference/generated ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r8457 - trunk
On 06/07/2010 02:36 PM, Stéfan van der Walt wrote: I guess this changeset is up for discussion, but I'd be very glad if we could track the .gitignore. I don't think we should. It is easy to set it up by yourself, and it may hide things that some people may want to see - different people may want to hide different things. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
2009/10/8 Charles R Harris charlesr.har...@gmail.com: code generator problem and doesn't call for a jump in major version. We hope ;) I think David's hack, which looks to have been committed by Stefan, should fix things up. I accidentally committed some of David's patches, but I reverted them back out. I think David's idea of generating an API from dictionary is much cleaner. We can work on implementing that today. Cheers Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
Stéfan van der Walt wrote: We can work on implementing that today. I am working on it ATM - it is taking me longer than expected, though. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Oct 7, 2009, at 9:51 PM, David Cournapeau wrote: On Thu, Oct 8, 2009 at 11:39 AM, Travis Oliphant oliph...@enthought.com wrote: I apologize for the mis communication that has occurred here. No problem I did not understand that there was a desire to keep ABI compatibility with NumPy 1.3 when NumPy 1.4 was released.The datetime merge was made under that presumption. I had assumed that people would be fine with recompilation of extension modules that depend on the NumPy C-API.There are several things that needed to be done to merge in new fundamental data-types. Why don't we call the next release NumPy 2.0 if that helps things? Personally, I'd prefer that over hacks to keep ABI compatibility. Keeping ABI compatibility by itself is not an hack - the current workaround is an hack, but that's only because the current way of doing things in code generator is a bit ugly, and I did not want to spend too much time on it. It is purely an implementation issue, the fundamental idea is straightforward. If you want a cleaner solution, I can work on it. I think the hour or so that it would take is worth it compared to breaking many people's code. If that's all it would take, then definitely go for it.I'm not sure breaking people's code is the right image, though. It's more like forcing people to upgrade to take advantage of new features. Improvements to the encapsulation of the numpy C-API are definitely welcome. They have come a long way from their beginnings in Numeric already due to the efforts of you and David Cooke (and I'm sure others I'm not as aware of). The problem I have with spending time on it though is that there is still more implementation work to finish on the datetime functionality to complete the NEP implementation. Naturally, I'd like to see those improvements made first. But, time-spent is usually a function of how much time it takes to get-in to the code, so I won't try to distract you if you have a clear idea about how to proceed. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Thu, Oct 8, 2009 at 8:55 PM, Travis Oliphant oliph...@enthought.com wrote: On Oct 7, 2009, at 9:51 PM, David Cournapeau wrote: On Thu, Oct 8, 2009 at 11:39 AM, Travis Oliphant oliph...@enthought.com wrote: I apologize for the mis communication that has occurred here. No problem I did not understand that there was a desire to keep ABI compatibility with NumPy 1.3 when NumPy 1.4 was released. The datetime merge was made under that presumption. I had assumed that people would be fine with recompilation of extension modules that depend on the NumPy C-API. There are several things that needed to be done to merge in new fundamental data-types. Why don't we call the next release NumPy 2.0 if that helps things? Personally, I'd prefer that over hacks to keep ABI compatibility. Keeping ABI compatibility by itself is not an hack - the current workaround is an hack, but that's only because the current way of doing things in code generator is a bit ugly, and I did not want to spend too much time on it. It is purely an implementation issue, the fundamental idea is straightforward. If you want a cleaner solution, I can work on it. I think the hour or so that it would take is worth it compared to breaking many people's code. If that's all it would take, then definitely go for it. I'm not sure breaking people's code is the right image, though. It's more like forcing people to upgrade to take advantage of new features. We got several people complaining about segfaults and the like - granted, those could have been avoided by updating the ABI accordingly. The problem I have with spending time on it though is that there is still more implementation work to finish on the datetime functionality to complete the NEP implementation. Naturally, I'd like to see those improvements made first. But, time-spent is usually a function of how much time it takes to get-in to the code, so I won't try to distract you if you have a clear idea about how to proceed. I am applying my changes as we speak - it took me much more time than I wished because I tried hard to make sure the ABI was not changed. But at least, the current scheme should be much more robust: the ordering is fixed at one single place, and there are a few checks which ensure we don't screw things up (by putting 'holes' in the api array, or by using twice the same index). cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris charlesr.har...@gmail.com wrote: Looks like a clue ;) Ok, I fixed it here: http://github.com/cournape/numpy/tree/fix_abi But that's an ugly hack. I think we should consider rewriting how we generate the API: instead of automatically growing the API array of fptr, we should explicitly mark which function name has which index, and hardcode it. It would help quite a bit to avoid changing the ABI unvoluntary. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris charlesr.har...@gmail.com wrote: Looks like a clue ;) Ok, I fixed it here: http://github.com/cournape/numpy/tree/fix_abi But that's an ugly hack. I think we should consider rewriting how we generate the API: instead of automatically growing the API array of fptr, we should explicitly mark which function name has which index, and hardcode it. It would help quite a bit to avoid changing the ABI unvoluntary. I'm thinking the safest thing to do is to move the new type to the end of the list. I'm not sure what all the ramifications are for compatibility to having it stuck in the middle like that, does it change the type numbers for all the types after? I wonder what the type numbers are internally? No doubt putting it at the end makes the logic for casting more difficult, but that is something that needs fixing anyway. Question - if the new type is simply removed from the list does anything break? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris charlesr.har...@gmail.com wrote: Looks like a clue ;) Ok, I fixed it here: http://github.com/cournape/numpy/tree/fix_abi But that's an ugly hack. I think we should consider rewriting how we generate the API: instead of automatically growing the API array of fptr, we should explicitly mark which function name has which index, and hardcode it. It would help quite a bit to avoid changing the ABI unvoluntary. I'm thinking the safest thing to do is to move the new type to the end of the list. That's what the above branch does. I'm not sure what all the ramifications are for compatibility to having it stuck in the middle like that, does it change the type numbers for all the types after? Yes, there is no space left between the types declarations and the first functions. Currently, I just put things at the end manually, but that's really error prone. I am a bit lazy to fix this for real (I was thinking about using a python dict with hardcoded indexes as an entry instead of the current .txt files, but this requires several changes in the code generator, which is already not the greatest code to begin with). David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris charlesr.har...@gmail.com wrote: Looks like a clue ;) Ok, I fixed it here: http://github.com/cournape/numpy/tree/fix_abi But that's an ugly hack. I think we should consider rewriting how we generate the API: instead of automatically growing the API array of fptr, we should explicitly mark which function name has which index, and hardcode it. It would help quite a bit to avoid changing the ABI unvoluntary. I'm thinking the safest thing to do is to move the new type to the end of the list. That's what the above branch does. I'm not sure what all the ramifications are for compatibility to having it stuck in the middle like that, does it change the type numbers for all the types after? Yes, there is no space left between the types declarations and the first functions. Currently, I just put things at the end manually, but that's really error prone. I am a bit lazy to fix this for real (I was thinking about using a python dict with hardcoded indexes as an entry instead of the current .txt files, but this requires several changes in the code generator, which is already not the greatest code to begin with). What I'm concerned about is that, IIRC, types in the c-code can be referenced by their index in a list of types and that internal mechanism might be exposed to the outside somewhere. That is, what has happened to the order of the enumerated types? If that has changed, and if external code references a type by a hard-wired number, then there is a problem that goes beyond the code generator. The safe(r) thing to do in that case is add the new type to the end of the enumerated types and fix the promotion code so it doesn't try to rely on a linear order. I expect Robert can give the fastest answer to that question. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris charlesr.har...@gmail.comwrote: On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau courn...@gmail.comwrote: On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris charlesr.har...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris charlesr.har...@gmail.com wrote: Looks like a clue ;) Ok, I fixed it here: http://github.com/cournape/numpy/tree/fix_abi But that's an ugly hack. I think we should consider rewriting how we generate the API: instead of automatically growing the API array of fptr, we should explicitly mark which function name has which index, and hardcode it. It would help quite a bit to avoid changing the ABI unvoluntary. I'm thinking the safest thing to do is to move the new type to the end of the list. That's what the above branch does. I'm not sure what all the ramifications are for compatibility to having it stuck in the middle like that, does it change the type numbers for all the types after? Yes, there is no space left between the types declarations and the first functions. Currently, I just put things at the end manually, but that's really error prone. I am a bit lazy to fix this for real (I was thinking about using a python dict with hardcoded indexes as an entry instead of the current .txt files, but this requires several changes in the code generator, which is already not the greatest code to begin with). What I'm concerned about is that, IIRC, types in the c-code can be referenced by their index in a list of types and that internal mechanism might be exposed to the outside somewhere. That is, what has happened to the order of the enumerated types? If that has changed, and if external code references a type by a hard-wired number, then there is a problem that goes beyond the code generator. The safe(r) thing to do in that case is add the new type to the end of the enumerated types and fix the promotion code so it doesn't try to rely on a linear order. Here, for instance: The various character codes indicating certain types are also part of an enumerated list. References to type characters (should they be needed at all) should always use these enumerations. The form of them is NPY NAMELTR where NAME So those macros will generate a hard-coded number at compile time, and number that might have changed with the addition of the new types. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 7:07 AM, Charles R Harris
charlesr.har...@gmail.comwrote:
On Wed, Oct 7, 2009 at 6:59 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Oct 7, 2009 at 6:37 AM, David Cournapeau courn...@gmail.comwrote:
On Wed, Oct 7, 2009 at 9:31 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Wed, Oct 7, 2009 at 2:06 AM, David Cournapeau courn...@gmail.com
wrote:
On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris
charlesr.har...@gmail.com wrote:
Looks like a clue ;)
Ok, I fixed it here:
http://github.com/cournape/numpy/tree/fix_abi
But that's an ugly hack. I think we should consider rewriting how we
generate the API: instead of automatically growing the API array of
fptr, we should explicitly mark which function name has which index,
and hardcode it. It would help quite a bit to avoid changing the ABI
unvoluntary.
I'm thinking the safest thing to do is to move the new type to the end
of
the list.
That's what the above branch does.
I'm not sure what all the ramifications are for compatibility to
having it stuck in the middle like that, does it change the type
numbers for
all the types after?
Yes, there is no space left between the types declarations and the
first functions. Currently, I just put things at the end manually, but
that's really error prone.
I am a bit lazy to fix this for real (I was thinking about using a
python dict with hardcoded indexes as an entry instead of the current
.txt files, but this requires several changes in the code generator,
which is already not the greatest code to begin with).
What I'm concerned about is that, IIRC, types in the c-code can be
referenced by their index in a list of types and that internal mechanism
might be exposed to the outside somewhere. That is, what has happened to the
order of the enumerated types? If that has changed, and if external code
references a type by a hard-wired number, then there is a problem that goes
beyond the code generator. The safe(r) thing to do in that case is add the
new type to the end of the enumerated types and fix the promotion code so it
doesn't try to rely on a linear order.
Here, for instance:
The various character codes indicating certain types are also part of an
enumerated
list. References to type characters (should they be needed at all) should
always use
these enumerations. The form of them is NPY NAMELTR where NAME
So those macros will generate a hard-coded number at compile time, and
number that might have changed with the addition of the new types.
Nevermind, it looks like the new type number is at the end as it should be.
In [22]: typecodes
Out[22]:
{'All': '?bhilqpBHILQPfdgFDGSUVOMm',
'AllFloat': 'fdgFDG',
'AllInteger': 'bBhHiIlLqQpP',
'Character': 'c',
'Complex': 'FDG',
'Datetime': 'Mm',
'Float': 'fdg',
'Integer': 'bhilqp',
'UnsignedInteger': 'BHILQP'}
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Oct 7, 2009, at 3:06 AM, David Cournapeau wrote: On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris charlesr.har...@gmail.com wrote: Looks like a clue ;) Ok, I fixed it here: http://github.com/cournape/numpy/tree/fix_abi But that's an ugly hack. I think we should consider rewriting how we generate the API: instead of automatically growing the API array of fptr, we should explicitly mark which function name has which index, and hardcode it. It would help quite a bit to avoid changing the ABI unvoluntary. I apologize for the mis communication that has occurred here. I did not understand that there was a desire to keep ABI compatibility with NumPy 1.3 when NumPy 1.4 was released.The datetime merge was made under that presumption. I had assumed that people would be fine with recompilation of extension modules that depend on the NumPy C-API.There are several things that needed to be done to merge in new fundamental data-types. Why don't we call the next release NumPy 2.0 if that helps things? Personally, I'd prefer that over hacks to keep ABI compatibility. It feels like we are working very hard to track ABI issues that can also be handled with dependency checking and good package management. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Thu, Oct 8, 2009 at 11:39 AM, Travis Oliphant oliph...@enthought.com wrote: I apologize for the mis communication that has occurred here. No problem I did not understand that there was a desire to keep ABI compatibility with NumPy 1.3 when NumPy 1.4 was released. The datetime merge was made under that presumption. I had assumed that people would be fine with recompilation of extension modules that depend on the NumPy C-API. There are several things that needed to be done to merge in new fundamental data-types. Why don't we call the next release NumPy 2.0 if that helps things? Personally, I'd prefer that over hacks to keep ABI compatibility. Keeping ABI compatibility by itself is not an hack - the current workaround is an hack, but that's only because the current way of doing things in code generator is a bit ugly, and I did not want to spend too much time on it. It is purely an implementation issue, the fundamental idea is straightforward. If you want a cleaner solution, I can work on it. I think the hour or so that it would take is worth it compared to breaking many people's code. It feels like we are working very hard to track ABI issues that can also be handled with dependency checking and good package management. I think ABI issues are mostly orthogonal to versioning - generally, versions are related to API changes (API changes is what should drive ABI changes, at least for projects like numpy). I would prefer passing to numpy 2.0 when we really need to break ABI and API - at that point, I think we should also think hard about changing our structures and all to make them more robust to those changes (using pimp-like strategies in particular). David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 21:55, David Cournapeau courn...@gmail.com wrote: On Thu, Oct 8, 2009 at 11:51 AM, David Cournapeau courn...@gmail.com wrote: I would prefer passing to numpy 2.0 when we really need to break ABI and API - at that point, I think we should also think hard about changing our structures and all to make them more robust to those changes (using pimp-like strategies in particular). Sorry, I mean pimple, not pimp (makes you wonder what goes in my head): Indeed! (And it's pimpl.) :-) -- 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 SVN broken
On 10/7/2009 10:57 PM, Robert Kern wrote: it's pimpl OK: http://en.wikipedia.org/wiki/Opaque_pointer Thanks, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 8:39 PM, Travis Oliphant oliph...@enthought.comwrote: On Oct 7, 2009, at 3:06 AM, David Cournapeau wrote: On Wed, Oct 7, 2009 at 2:31 AM, Charles R Harris charlesr.har...@gmail.com wrote: Looks like a clue ;) Ok, I fixed it here: http://github.com/cournape/numpy/tree/fix_abi But that's an ugly hack. I think we should consider rewriting how we generate the API: instead of automatically growing the API array of fptr, we should explicitly mark which function name has which index, and hardcode it. It would help quite a bit to avoid changing the ABI unvoluntary. I apologize for the mis communication that has occurred here. I did not understand that there was a desire to keep ABI compatibility with NumPy 1.3 when NumPy 1.4 was released.The datetime merge was made under that presumption. I had assumed that people would be fine with recompilation of extension modules that depend on the NumPy C-API.There are several things that needed to be done to merge in new fundamental data-types. Why don't we call the next release NumPy 2.0 if that helps things? Personally, I'd prefer that over hacks to keep ABI compatibility. It feels like we are working very hard to track ABI issues that can also be handled with dependency checking and good package management. I was that the code generator shifted the API order because it was inserting the new types after the old types but before the other API functions. It's a code generator problem and doesn't call for a jump in major version. We hope ;) I think David's hack, which looks to have been committed by Stefan, should fix things up. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
2009/10/6 Stéfan van der Walt ste...@sun.ac.za Hi all, The current SVN HEAD of NumPy is broken and should not be used. Extensions compiled against this version may (will) segfault. Travis, if you could have a look at the side-effects caused by r7050, that would be great. I meant to figure out what was wrong, but seeing that this is a 3000 line patch, I'm not confident I can find the problem easily. Regards Stéfan P.S. The new functionality is great, but I don't think we're going to be able to convince David to release without documenting and testing those changes to the C API. ___ Seeing as the next release process is probably going to start next month and we want things to settle out, it might be advisable delay any intrusive patches to the release after and subject them to review and discussion first. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
2009/10/6 Charles R Harris charlesr.har...@gmail.com:
2009/10/6 Stéfan van der Walt ste...@sun.ac.za
Hi all,
The current SVN HEAD of NumPy is broken and should not be used.
Extensions compiled against this version may (will) segfault.
Can you be more specific? I haven't had any problems running current svn
with scipy.
Both David and I had segfaults when running scipy compiled off
the latest numpy. An example from Kiva:
Program received signal SIGSEGV, Segmentation fault.
PyArray_INCREF (mp=0x42)
at build/scons/numpy/core/src/multiarray/refcount.c:103
103 if (!PyDataType_REFCHK(mp-descr)) {
(gdb) bt
#0 PyArray_INCREF (mp=0x42)
at build/scons/numpy/core/src/multiarray/refcount.c:103
#1 0x00985f67 in agg::pixel_map_as_unowned_array (pix_map=...)
at
build/src.linux-i686-2.6/enthought/kiva/agg/src/x11/plat_support_wrap.cpp:2909
#2 0x0098795f in _wrap_pixel_map_as_unowned_array (args=0xb7ed032c)
at
build/src.linux-i686-2.6/enthought/kiva/agg/src/x11/plat_support_wrap.cpp:3341
Via bisection, the source of the problem has been localised to the
merge of the datetime branch.
Cheers
Stéfan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Tue, Oct 6, 2009 at 10:50 AM, David Cournapeau courn...@gmail.comwrote: On Wed, Oct 7, 2009 at 1:36 AM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/10/6 Stéfan van der Walt ste...@sun.ac.za Hi all, The current SVN HEAD of NumPy is broken and should not be used. Extensions compiled against this version may (will) segfault. Can you be more specific? I haven't had any problems running current svn with scipy. The version itself is fine, but the ABI has been changed in an incompatible way: if you have an extension built against say numpy 1.2.1, and then use a numpy built from sources after the datetime merge, it will segfault right away. It does so for scipy and several custom extensions. The abi breakage was found to be the datetime merge. Ah... That's a fine kettle of fish. Any idea what ABI calls are causing the problem? Maybe the dtype change wasn't made in a compatible way. IIRC, something was added to the dtype? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Wed, Oct 7, 2009 at 2:04 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Oct 6, 2009 at 10:50 AM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 7, 2009 at 1:36 AM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/10/6 Stéfan van der Walt ste...@sun.ac.za Hi all, The current SVN HEAD of NumPy is broken and should not be used. Extensions compiled against this version may (will) segfault. Can you be more specific? I haven't had any problems running current svn with scipy. The version itself is fine, but the ABI has been changed in an incompatible way: if you have an extension built against say numpy 1.2.1, and then use a numpy built from sources after the datetime merge, it will segfault right away. It does so for scipy and several custom extensions. The abi breakage was found to be the datetime merge. Ah... That's a fine kettle of fish. Any idea what ABI calls are causing the problem? Maybe the dtype change wasn't made in a compatible way. IIRC, something was added to the dtype? Yes, but that should not cause trouble. Adding members to structure should be fine. I quickly look at the diff, and some changes in the code generators look suspicious, e.g.: types = ['Generic','Number','Integer','SignedInteger','UnsignedInteger', - 'Inexact', + 'Inexact', 'TimeInteger', 'Floating', 'ComplexFloating', 'Flexible', 'Character', 'Byte','Short','Int', 'Long', 'LongLong', 'UByte', 'UShort', 'UInt', 'ULong', 'ULongLong', 'Float', 'Double', 'LongDouble', 'CFloat', 'CDouble', 'CLongDouble', 'Object', 'String', 'Unicode', - 'Void'] + 'Void', 'Datetime', 'Timedelta'] As the list is used to initialize some values from the API function pointer array, inserts should be avoided. You can see the consequence on the generated files, e.g. part of __multiarray_api.h diff between datetimemerge and just before: #define PyFloatingArrType_Type (*(PyTypeObject *)PyArray_API[16]) #define PyComplexFloatingArrType_Type (*(PyTypeObject *)PyArray_API[17]) #define PyFlexibleArrType_Type (*(PyTypeObject *)PyArray_API[18]) #define PyCharacterArrType_Type (*(PyTypeObject *)PyArray_API[19]) #define PyByteArrType_Type (*(PyTypeObject *)PyArray_API[20]) #define PyShortArrType_Type (*(PyTypeObject *)PyArray_API[21]) #define PyIntArrType_Type (*(PyTypeObject *)PyArray_API[22]) #define PyLongArrType_Type (*(PyTypeObject *)PyArray_API[23]) #define PyLongLongArrType_Type (*(PyTypeObject *)PyArray_API[24]) #define PyUByteArrType_Type (*(PyTypeObject *)PyArray_API[25]) #define PyUShortArrType_Type (*(PyTypeObject *)PyArray_API[26]) #define PyUIntArrType_Type (*(PyTypeObject *)PyArray_API[27]) #define PyULongArrType_Type (*(PyTypeObject *)PyArray_API[28]) #define PyULongLongArrType_Type (*(PyTypeObject *)PyArray_API[29]) #define PyFloatArrType_Type (*(PyTypeObject *)PyArray_API[30]) #define PyDoubleArrType_Type (*(PyTypeObject *)PyArray_API[31]) #define PyLongDoubleArrType_Type (*(PyTypeObject *)PyArray_API[32]) #define PyCFloatArrType_Type (*(PyTypeObject *)PyArray_API[33]) #define PyCDoubleArrType_Type (*(PyTypeObject *)PyArray_API[34]) #define PyCLongDoubleArrType_Type (*(PyTypeObject *)PyArray_API[35]) #define PyObjectArrType_Type (*(PyTypeObject *)PyArray_API[36]) #define PyStringArrType_Type (*(PyTypeObject *)PyArray_API[37]) #define PyUnicodeArrType_Type (*(PyTypeObject *)PyArray_API[38]) #define PyVoidArrType_Type (*(PyTypeObject *)PyArray_API[39]) --- #define PyTimeIntegerArrType_Type (*(PyTypeObject *)PyArray_API[16]) #define PyFloatingArrType_Type (*(PyTypeObject *)PyArray_API[17]) #define PyComplexFloatingArrType_Type (*(PyTypeObject *)PyArray_API[18]) #define PyFlexibleArrType_Type (*(PyTypeObject *)PyArray_API[19]) #define PyCharacterArrType_Type (*(PyTypeObject *)PyArray_API[20]) #define PyByteArrType_Type (*(PyTypeObject *)PyArray_API[21]) #define PyShortArrType_Type (*(PyTypeObject *)PyArray_API[22]) #define PyIntArrType_Type (*(PyTypeObject *)PyArray_API[23]) #define PyLongArrType_Type (*(PyTypeObject *)PyArray_API[24]) #define PyLongLongArrType_Type (*(PyTypeObject *)PyArray_API[25]) #define PyUByteArrType_Type (*(PyTypeObject *)PyArray_API[26]) #define PyUShortArrType_Type (*(PyTypeObject *)PyArray_API[27]) #define PyUIntArrType_Type (*(PyTypeObject *)PyArray_API[28]) #define PyULongArrType_Type (*(PyTypeObject *)PyArray_API[29]) #define PyULongLongArrType_Type (*(PyTypeObject *)PyArray_API[30]) #define PyFloatArrType_Type (*(PyTypeObject *)PyArray_API[31]) #define PyDoubleArrType_Type (*(PyTypeObject *)PyArray_API[32]) #define PyLongDoubleArrType_Type (*(PyTypeObject *)PyArray_API[33]) #define PyCFloatArrType_Type (*(PyTypeObject *)PyArray_API[34]) #define PyCDoubleArrType_Type (*(PyTypeObject *)PyArray_API[35]) #define PyCLongDoubleArrType_Type (*(PyTypeObject *)PyArray_API[36]) #define PyObjectArrType_Type (*(PyTypeObject *)PyArray_API[37])
Re: [Numpy-discussion] NumPy SVN broken
On 6-Oct-09, at 12:50 PM, David Cournapeau wrote: The version itself is fine, but the ABI has been changed in an incompatible way: if you have an extension built against say numpy 1.2.1, and then use a numpy built from sources after the datetime merge, it will segfault right away. It does so for scipy and several custom extensions. The abi breakage was found to be the datetime merge. I experienced something similar recently with both ETS and pytables. Good to know finally what was going on. :) David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN broken
On Tue, Oct 6, 2009 at 11:14 AM, David Cournapeau courn...@gmail.comwrote: On Wed, Oct 7, 2009 at 2:04 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, Oct 6, 2009 at 10:50 AM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 7, 2009 at 1:36 AM, Charles R Harris charlesr.har...@gmail.com wrote: 2009/10/6 Stéfan van der Walt ste...@sun.ac.za Hi all, The current SVN HEAD of NumPy is broken and should not be used. Extensions compiled against this version may (will) segfault. Can you be more specific? I haven't had any problems running current svn with scipy. The version itself is fine, but the ABI has been changed in an incompatible way: if you have an extension built against say numpy 1.2.1, and then use a numpy built from sources after the datetime merge, it will segfault right away. It does so for scipy and several custom extensions. The abi breakage was found to be the datetime merge. Ah... That's a fine kettle of fish. Any idea what ABI calls are causing the problem? Maybe the dtype change wasn't made in a compatible way. IIRC, something was added to the dtype? Yes, but that should not cause trouble. Adding members to structure should be fine. I quickly look at the diff, and some changes in the code generators look suspicious, e.g.: types = ['Generic','Number','Integer','SignedInteger','UnsignedInteger', - 'Inexact', + 'Inexact', 'TimeInteger', 'Floating', 'ComplexFloating', 'Flexible', 'Character', 'Byte','Short','Int', 'Long', 'LongLong', 'UByte', 'UShort', 'UInt', 'ULong', 'ULongLong', 'Float', 'Double', 'LongDouble', 'CFloat', 'CDouble', 'CLongDouble', 'Object', 'String', 'Unicode', - 'Void'] + 'Void', 'Datetime', 'Timedelta'] As the list is used to initialize some values from the API function pointer array, inserts should be avoided. You can see the consequence on the generated files, e.g. part of __multiarray_api.h diff between datetimemerge and just before: Looks like a clue ;) snip Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy-svn mails
Hi, Is anyone getting mails of the SVN commits? I've gotten 1 spam message from that list, but no commits. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-svn mails
On Fri, Mar 6, 2009 at 8:28 AM, Ryan May rma...@gmail.com wrote: Hi, Is anyone getting mails of the SVN commits? I've gotten 1 spam message from that list, but no commits. Ryan I'm not seeing them either...Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-svn mails
On Mar 6, 2009, at 12:46 PM, Charles R Harris wrote: On Fri, Mar 6, 2009 at 8:28 AM, Ryan May rma...@gmail.com wrote: Hi, Is anyone getting mails of the SVN commits? I've gotten 1 spam message from that list, but no commits. Ryan I'm not seeing them either...Chuck Hey guys, I'm working on this problem now. You might see a spurious email here or there, and I will let everyone know on both scipy and numpy lists when they are going again. In the interim, please use Trac to look at checkins: http://projects.scipy.org/numpy/log/ http://projects.scipy.org/scipy/log/ Thanks for your patience, Peter ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] NumPy SVN?
Is commit to NumPy SVN still turned off? How do I get a working SVN again? -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN?
Travis E. Oliphant wrote: Is commit to NumPy SVN still turned off? How do I get a working SVN again? It is on - I could commit a few things 1-2 hours ago. If you still get an administrative error message (repo is read only ...), it means you are on the old repo. cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN?
On Mar 4, 2009, at 8:37 AM, David Cournapeau wrote: Travis E. Oliphant wrote: Is commit to NumPy SVN still turned off? How do I get a working SVN again? It is on - I could commit a few things 1-2 hours ago. If you still get an administrative error message (repo is read only ...), it means you are on the old repo. cheers, David Yeah, this is an Enthought-internal IT issue, which I will fix this morning as soon as I get in to the office. -Peter ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN?
On Thu, Mar 5, 2009 at 12:06 AM, Scott Sinclair scott.sinclair...@gmail.com wrote: I had to do a fresh checkout from http://svn.scipy.org/svn/numpy/ (note changed URL). I did not know we could access svn from scipy.org. I have alway used svn.scipy.org - in which case you don't need to do anything to go to the new repo. It should be transparent. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN?
David Cournapeau wrote: On Thu, Mar 5, 2009 at 12:06 AM, Scott Sinclair scott.sinclair...@gmail.com wrote: I had to do a fresh checkout from http://svn.scipy.org/svn/numpy/ (note changed URL). I did not know we could access svn from scipy.org. I have alway used svn.scipy.org - in which case you don't need to do anything to go to the new repo. It should be transparent. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion See links at: http://www.scipy.org/Download ''' Bleeding-edge repository access (See also the Developer Zone.) NumPy svn co http://scipy.org/svn/numpy/trunk numpy SciPy svn co http://scipy.org/svn/scipy/trunk scipy ''' But the Developer Zone page (http://www.scipy.org/Developer_Zone) refers to the other eg for numpy: http://svn.scipy.org/svn/numpy/trunk/ Bruce ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy SVN?
On Thu, Mar 5, 2009 at 1:33 AM, Bruce Southey bsout...@gmail.com wrote: David Cournapeau wrote: On Thu, Mar 5, 2009 at 12:06 AM, Scott Sinclair scott.sinclair...@gmail.com wrote: I had to do a fresh checkout from http://svn.scipy.org/svn/numpy/ (note changed URL). I did not know we could access svn from scipy.org. I have alway used svn.scipy.org - in which case you don't need to do anything to go to the new repo. It should be transparent. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion See links at: http://www.scipy.org/Download ''' Bleeding-edge repository access (See also the Developer Zone.) NumPy svn co http://scipy.org/svn/numpy/trunk numpy SciPy svn co http://scipy.org/svn/scipy/trunk scipy ''' Damn wiki, I wanted to fix that, but it was already fixed. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
Hi Pearu 2008/5/20 Pearu Peterson [EMAIL PROTECTED]: CC: numpy-discussion because of other reactions on the subject. On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. On the other hand, the patch does not affect numpy users who do not use f2py, in any way. So, it is not important for numpy users, in general. Many f2py users currently get their version via NumPy, I assume. Hmm, I also thought that the trunk is open for development, even though r5198 is only fixing a bug (and I do not plan to develop f2py in numpy further, just fix bugs and maintain it). If the release process is going to take for weeks and is locking the trunk, may be the release candidates should live in a separate branch? If the patch a) Fixes an important bug and b) has unit tests to ensure it does what it is supposed to then I'd be +1 for applying. It looks like there are some tests included; to which degree do they cover the bugfix, and do we have tests to make sure that f2py still functions correctly? I'd like to make sure I understood Jarrod's message from earlier this week: 1) Release candidate branch is tagged -- development continues on trunk 2) Release candidate is tested 3) Bug-fixes are back-ported to the release candidate as necessary 4) Release is made Another version I've seen starts with: 1) Release candidate branch is tagged -- no one touches trunk except for bug-fixes Which is it? I want to know where the docstring changes should go. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
Pearu Peterson wrote: So I beg to be flexible with f2py related commits for now. Why not creating a branch for the those changes, and applying only critical bug fixes to the trunk ? cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
David Cournapeau wrote: Pearu Peterson wrote: So I beg to be flexible with f2py related commits for now. Why not creating a branch for the those changes, and applying only critical bug fixes to the trunk ? How do you define a critical bug? Critical to whom? f2py changes are never critical to numpy users who do not use f2py. I have stated before that I am not developing numpy.f2py any further. This also means that any changes to f2py should be essentially bug fixes. Creating a branch for bug fixes is a waste of time, imho. If somebody is willing to maintain the branch, that is, periodically sync the branch with the trunk and vice-versa, then I don't mind. Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
Pearu Peterson wrote: f2py changes are never critical to numpy users who do not use f2py. No, but they are to scipy users if f2py cannot build scipy. I have stated before that I am not developing numpy.f2py any further. This also means that any changes to f2py should be essentially bug fixes. Creating a branch for bug fixes is a waste of time, imho. I was speaking about creating a branch for the unit tests changes you were talking about, that is things which could potentially break a lot of configurations. Is the new f2py available for users ? If yes, you should tell f2py users to use this, and just do not care at all about numpy.f2py anymore, except for critical bugs. Maintaining two versions of the same software is always a PITA, so if you don't want to spend time on it, just focus on the new f2py (as long as numpy.f2py can build scipy, of course). cheers, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Tue, May 20, 2008 12:03 pm, David Cournapeau wrote: Pearu Peterson wrote: f2py changes are never critical to numpy users who do not use f2py. No, but they are to scipy users if f2py cannot build scipy. Well, I know pretty well what f2py features scipy uses and what could break scipy build. So, don't worry about that. I have stated before that I am not developing numpy.f2py any further. This also means that any changes to f2py should be essentially bug fixes. Creating a branch for bug fixes is a waste of time, imho. I was speaking about creating a branch for the unit tests changes you were talking about, that is things which could potentially break a lot of configurations. A branch for the unit tests changes is of course reasonable. Is the new f2py available for users ? If yes,.. No, it is far from being usable now. The numpy.f2py and g3 f2py are completely different software. The changeset was fixing a bug in numpy.f2py, it has nothing to do with g3 f2py. amazing-how-paranoiac-is-todays-numpy/scipy-development'ly yours, Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Mon, May 19, 2008 at 10:29 PM, Pearu Peterson [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. I have been struggling to try and get a stable release out since February and every time I think that the release is almost ready some piece of code changes that requires me to delay. While overall the code has continuously improved over this period, I think it is time to get these improvements to our users. That said, I am willing to leave this change on the trunk, but please refrain from making any more changes until we release 1.1.0. I know it can be frustrating, but, I believe, this is the first time I have asked the community to not make commits to the trunk since I started handling releases almost a year ago. The freeze has only been in effect since Saturday and will last less than one week in total. I would have preferred if you could have made this change during any one of the other 51 weeks of the year. Hmm, I also thought that the trunk is open for development, even though r5198 is only fixing a bug (and I do not plan to develop f2py in numpy further, just fix bugs and maintain it). If the release process is going to take for weeks and is locking the trunk, may be the release candidates should live in a separate branch? Sorry for the confusion, I had asked that everyone be extremely conservative and careful about any commits you make to the trunk until we officially release 1.1.0, which is still pretty much the rule of thumb. I have been keeping the 1.1.0 milestone page up-to-date with regard to my planned release date; but I should have highlighted the date in my email. The main reason that this is happening on the trunk is that about two weeks ago I created a 1.1.x branch, but I didn't think all the bug-fixes for the 1.1.0 release were being made to the branch and the branch and the trunk got out of synch enough that it was difficult for me to merge the fixes in the trunk into the branch, so I deleted the branch and declared the trunk to again be where 1.1.x development occurred. I fully intend to release 1.1.0 by the end of the week. I also intend to create a 1.1.x maintenance branch at that point, so the trunk will be open for 1.2 development. As long as you are only going to be adding bug-fixes to numpy.f2py, I think that you should be able to use the trunk for this purpose once I create the 1.1.x branch. Thanks, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Tue, May 20, 2008 at 1:00 AM, Pearu Peterson [EMAIL PROTECTED] wrote: How do you define a critical bug? Critical to whom? I know that the definition of a critical bug is somewhat ill-defined, but I think that a long existing and unreported bug probably wouldn't fall into the category of critical bug. -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
On Tue, May 20, 2008 1:36 pm, Jarrod Millman wrote: On Mon, May 19, 2008 at 10:29 PM, Pearu Peterson [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. I have been struggling to try and get a stable release out since February and every time I think that the release is almost ready some piece of code changes that requires me to delay. While overall the code has continuously improved over this period, I think it is time to get these improvements to our users. That said, I am willing to leave this change on the trunk, but please refrain from making any more changes until we release 1.1.0. I know it can be frustrating, but, I believe, this is the first time I have asked the community to not make commits to the trunk since I started handling releases almost a year ago. The freeze has only been in effect since Saturday and will last less than one week in total. I would have preferred if you could have made this change during any one of the other 51 weeks of the year. Please, go ahead. I'll not commit non-critical changes until the trunk is open again. Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-svn] r5198 - trunk/numpy/f2py
CC: numpy-discussion because of other reactions on the subject. On Tue, May 20, 2008 1:26 am, Robert Kern wrote: Is this an important bugfix? If not, can you hold off until 1.1.0 is released? The patch fixes a long existing and unreported bug in f2py - I think the bug was introduced when Python defined min and max functions. I learned about the bug when reading a manuscript about f2py. Such bugs should not end up in a paper demonstrating f2py inability to process certain features as it would have not been designed to do so. So, I'd consider the bugfix important. On the other hand, the patch does not affect numpy users who do not use f2py, in any way. So, it is not important for numpy users, in general. Hmm, I also thought that the trunk is open for development, even though r5198 is only fixing a bug (and I do not plan to develop f2py in numpy further, just fix bugs and maintain it). If the release process is going to take for weeks and is locking the trunk, may be the release candidates should live in a separate branch? Pearu ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
