Re: [Numpy-discussion] Issue Tracking
On Mon, Apr 30, 2012 at 10:14 PM, Travis Oliphant tra...@continuum.iowrote: The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. There is a group where I work that purchased the enterprise version of github. But they still use trac. I think Ralf's opinion should count for a fair amount here, since the tracker is important for releases and backports. Having a good connection between commits and tickets is also very helpful, although sticking with github might be better there. The issue tracker isn't really intended as social media and I find the notifications from trac sufficient. Chuck I think Ralf and your opinion on this is *huge*. It seems that Issue tracking is at the heart of social media activity, though, because you need people to submit issues and you need people to respond to those issues in a timely way.And it is ideal if the dialogue that might ensue pursuant to that activity is discoverable via search and linking. But the issue tracking problem really is dividable into separate work flows: 1) The submission of the issue (here things like ease-of-entry and attaching files is critical) Yes, trac does allow attachments, but numpy trac locks up pretty often and I don't see why I should be locked out from submitting a comment just because someone else has made a comment while I've been typing. That said, trac does seem more responsive lately (thanks Pauli). I also don't find the trac interface attractive to look at, but it works. I could live without attachments, but they can be handy for scripts that demonstrate bugs and so on. As for fixes, I think we want to encourage pull requests rather than attached patches, but it might take a while before everyone is comfortable with that procedure. 2) The dialogue around the issue (developer comments on it and any discussion that ensues) I find the trac email notifications pretty good in that regard, although it would be nice to have everything in one place. The main issue I have, actually, is that github won't send me everything. I want to see every posted comment and every commit show up in the mail, including my own comments. The RSS feeds seem better for those notifications, but I have two feeds from github and they don't show the same things. Maybe we need to put together a tracking workflow document to supplement the git workflow document. I'd also like to see bug fix commits go in and automatically notify the tracker with an @#666 or some such. I don't know if that sort of thing is possible with the github tracker or the github hooks. 3) Developer management of issues This is where Ralf comes in as I don't regard myself as that familiar with trac. The problem in choosing a new system is that one needs to actually use it for some serious work to properly evaluate it. But we don't have the time to do that, so we ask. And then everyone has their own favorite, perhaps because it is the only one they have used. What impressed me was that Ralf seems to have actually used several different systems. Now, it is also true that these three things don't have to all intersect. It is very possible to have different systems manage different parts. What I find less than optimal these days is having github as the web-site for pull requests and discussions around them and a poorly-performing trac for issue tracking and milestone management and a few wiki pages. Can we at least agree to have all the wiki pages and web-site managed by github? For issue tracking, I'm very anxious for your and Ralf's opinion because of the effort you have spent using Trac over the years. It makes sense to move the wiki and web site. I hardly ever look at the developer Wiki anyway and might be more tempted to do so if it were up on github. It would also be good if those things could be managed in one place. As is, the permissions for managing things are split up and it isn't always clear who has the magic key. Another developer I asked at LLNL, just said why don't you use bugzilla? The simplest solution would be to use github, the question is whether the convenience and possibility of future improvements outweigh the better functionality of a dedicated system. In making that decision I think Ralf's opinion should carry the most weight since my experience in using trac for releases and such is much more limited than his. It might also be good to check on the ability of the different systems to export the data in some sensible format in case we change our minds. I suppose worker time and money are also part of the equation. If it looks like the github solution is cheaper and easier to manage, that in itself could be a
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 12:16 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Apr 30, 2012 at 10:14 PM, Travis Oliphant tra...@continuum.iowrote: The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. There is a group where I work that purchased the enterprise version of github. But they still use trac. I think Ralf's opinion should count for a fair amount here, since the tracker is important for releases and backports. Having a good connection between commits and tickets is also very helpful, although sticking with github might be better there. The issue tracker isn't really intended as social media and I find the notifications from trac sufficient. Chuck I think Ralf and your opinion on this is *huge*. It seems that Issue tracking is at the heart of social media activity, though, because you need people to submit issues and you need people to respond to those issues in a timely way.And it is ideal if the dialogue that might ensue pursuant to that activity is discoverable via search and linking. But the issue tracking problem really is dividable into separate work flows: 1) The submission of the issue (here things like ease-of-entry and attaching files is critical) Yes, trac does allow attachments, but numpy trac locks up pretty often and I don't see why I should be locked out from submitting a comment just because someone else has made a comment while I've been typing. That said, trac does seem more responsive lately (thanks Pauli). I also don't find the trac interface attractive to look at, but it works. I could live without attachments, but they can be handy for scripts that demonstrate bugs and so on. As for fixes, I think we want to encourage pull requests rather than attached patches, but it might take a while before everyone is comfortable with that procedure. 2) The dialogue around the issue (developer comments on it and any discussion that ensues) I find the trac email notifications pretty good in that regard, although it would be nice to have everything in one place. The main issue I have, actually, is that github won't send me everything. I want to see every posted comment and every commit show up in the mail, including my own comments. The RSS feeds seem better for those notifications, but I have two feeds from github and they don't show the same things. Maybe we need to put together a tracking workflow document to supplement the git workflow document. I'd also like to see bug fix commits go in and automatically notify the tracker with an @#666 or some such. I don't know if that sort of thing is possible with the github tracker or the github hooks. 3) Developer management of issues This is where Ralf comes in as I don't regard myself as that familiar with trac. The problem in choosing a new system is that one needs to actually use it for some serious work to properly evaluate it. But we don't have the time to do that, so we ask. And then everyone has their own favorite, perhaps because it is the only one they have used. What impressed me was that Ralf seems to have actually used several different systems. Now, it is also true that these three things don't have to all intersect. It is very possible to have different systems manage different parts. What I find less than optimal these days is having github as the web-site for pull requests and discussions around them and a poorly-performing trac for issue tracking and milestone management and a few wiki pages. Can we at least agree to have all the wiki pages and web-site managed by github? For issue tracking, I'm very anxious for your and Ralf's opinion because of the effort you have spent using Trac over the years. It makes sense to move the wiki and web site. I hardly ever look at the developer Wiki anyway and might be more tempted to do so if it were up on github. It would also be good if those things could be managed in one place. As is, the permissions for managing things are split up and it isn't always clear who has the magic key. Another developer I asked at LLNL, just said why don't you use bugzilla? The simplest solution would be to use github, the question is whether the convenience and possibility of future improvements outweigh the better functionality of a dedicated system. In making that decision I think Ralf's opinion should carry the most weight since my experience in using trac for releases and such is much more limited than his. It might also be good to check on the ability of the different systems to export the data in some sensible format in case we change our minds. I suppose worker time and
Re: [Numpy-discussion] Issue Tracking
On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries, so maybe this isn't insurmountable. yes, you can build your own queries.This seems like an area where github
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries, so maybe this isn't insurmountable. yes, you can build your own queries.This
Re: [Numpy-discussion] Continuous Integration
Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012: If you have particular reasons why we should choose a particular CI service, please speak up and let your voice be heard. There is still time to make a difference in what we are setting up. Hi all, What about buildbot? (http://trac.buildbot.net/) I'm using it currently, and like it because is GPL 2, configuration files are powerful Python scripts, and development team is active and dynamic. Best, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
01.05.2012 08:52, Travis Oliphant kirjoitti: [clip] 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. I'm not so sure this works for binary data. At least for Scipy, one sometimes needs to submit also data files. The needs here are probably somewhat different from IPython which can probably live with small text snippets, for which gists do work. The problem with using an external services I see is guaranteeing that the file still is there when you go looking for it (three years after the fact --- shouldn't happen in principle, but it does :). Dropbox I think is not good for this --- people will delete their stuff. I'm not sure about other attachment services. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.2 release - backports and MSVC testing help
Hello, with my Debian hat one I'd surely like to give it a go - do you have any plan to release a tarball for a RC (given the implication of numpy on the distro, I can't test anything else)? what do you expect to be the release date for 1.6.2? I asked this to understand the impact, due to the upcoming Debian freeze (June, still not clear if beginning or end). Cheers, Sandri On Mon, Apr 30, 2012 at 22:16, Ralf Gommers ralf.gomm...@googlemail.com wrote: Hi all, Charles has done a great job of backporting a lot of bug fixes to 1.6.2, see PRs 260, 261, 262 and 263. For those who are interested, please have a look at those PRs to see and comment on what's proposed to go into 1.6.2. I also have a request for help with testing: can someone who uses MSVC test (preferably with a 2.x and a 3.x version)? I have a branch with all four PRs merged at https://github.com/rgommers/numpy/tree/bports Thanks, Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test failures - which dependencies am I missing?
Hi Chris, Try sudo apt-get build-dep python-numpy to install the dependencies for building NumPy. I believe it will install all of the optional dependencies as well. HTH, Keith ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Continuous Integration
01.05.2012 11:14, David Froger kirjoitti: Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012: If you have particular reasons why we should choose a particular CI service, please speak up and let your voice be heard. There is still time to make a difference in what we are setting up. Hi all, What about buildbot? (http://trac.buildbot.net/) I'm using it currently, and like it because is GPL 2, configuration files are powerful Python scripts, and development team is active and dynamic. We're currently using it: http://buildbot.scipy.org Although, it hasn't been building automatically for some time now. It has the following shortcomings: - Apparently, for one master instance, only one project. - Last time I looked, Git integration was poor. Maybe this has improved since... Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Continuous Integration
Hi, On Tue, May 1, 2012 at 9:56 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 11:14, David Froger kirjoitti: Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012: If you have particular reasons why we should choose a particular CI service, please speak up and let your voice be heard. There is still time to make a difference in what we are setting up. Hi all, What about buildbot? (http://trac.buildbot.net/) I'm using it currently, and like it because is GPL 2, configuration files are powerful Python scripts, and development team is active and dynamic. We're currently using it: http://buildbot.scipy.org Although, it hasn't been building automatically for some time now. It has the following shortcomings: - Apparently, for one master instance, only one project. We're building 4 github projects with one buildbot process, and one master.cfg script, but maybe that's not what you meant? http://nipy.bic.berkeley.edu/builders - Last time I looked, Git integration was poor. Maybe this has improved since... Our projects use git pollers polling github repos. We did run into random occasional builds stalling at the git update step, but I believe that has been fixed with the latest release. Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.2 release - backports and MSVC testing help
On Mon, Apr 30, 2012 at 2:16 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: Hi all, Charles has done a great job of backporting a lot of bug fixes to 1.6.2, see PRs 260, 261, 262 and 263. For those who are interested, please have a look at those PRs to see and comment on what's proposed to go into 1.6.2. I also have a request for help with testing: can someone who uses MSVC test (preferably with a 2.x and a 3.x version)? I have a branch with all four PRs merged at https://github.com/rgommers/numpy/tree/bports Works for me on OSX 10.6, no errors. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python3, genfromtxt and unicode
On Fri, Apr 27, 2012 at 8:17 PM, Antony Lee antony@berkeley.edu wrote:
With bytes fields, genfromtxt(dtype=None) sets the sizes of the fields to
the largest number of chars (npyio.py line 1596), but it doesn't do the
same for unicode fields, which is a pity. See example below.
I tried to change npyio.py around line 1600 to add that but it didn't
work; from my limited understanding the problem comes earlier, in the way
StringBuilder is defined(?).
Antony Lee
import io, numpy as np
s = io.BytesIO()
s.write(babc 1\ndef 2)
s.seek(0)
t = np.genfromtxt(s, dtype=None) # (or converters={0: bytes})
print(t, t.dtype) # - [(b'a', 1) (b'b', 2)] [('f0', '|S1'), ('f1', 'i8')]
s.seek(0)
t = np.genfromtxt(s, dtype=None, converters={0: lambda s:
s.decode(utf-8)})
print(t, t.dtype) # - [('', 1) ('', 2)] [('f0', 'U0'), ('f1', 'i8')]
Could you open a ticket for this?
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.2 release - backports and MSVC testing help
On Tue, May 1, 2012 at 20:24, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Tue, May 1, 2012 at 5:27 PM, Sandro Tosi matrixh...@gmail.com wrote: Hello, with my Debian hat one I'd surely like to give it a go - do you have any plan to release a tarball for a RC (given the implication of numpy on the distro, I can't test anything else)? what do you expect to be the release date for 1.6.2? I asked this to understand the impact, due to the upcoming Debian freeze (June, still not clear if beginning or end). We certainly have the Debian freeze date in the back of our heads. I'm I can only say Thank you! :) aiming for an RC sometime this week and a release two weeks after that. Awesome, I'll be waiting for the RC to prepare the upload, directly to our main archive. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Python3, genfromtxt and unicode
Sure, I will. Right now my solution is to use genfromtxt once with bytes
and auto-dtype detection, then modify the resulting dtype, replacing bytes
with unicodes, and use that new dtypes for a second round of genfromtxt. A
bit awkward but that gets the job done.
Antony Lee
2012/5/1 Charles R Harris charlesr.har...@gmail.com
On Fri, Apr 27, 2012 at 8:17 PM, Antony Lee antony@berkeley.eduwrote:
With bytes fields, genfromtxt(dtype=None) sets the sizes of the fields to
the largest number of chars (npyio.py line 1596), but it doesn't do the
same for unicode fields, which is a pity. See example below.
I tried to change npyio.py around line 1600 to add that but it didn't
work; from my limited understanding the problem comes earlier, in the way
StringBuilder is defined(?).
Antony Lee
import io, numpy as np
s = io.BytesIO()
s.write(babc 1\ndef 2)
s.seek(0)
t = np.genfromtxt(s, dtype=None) # (or converters={0: bytes})
print(t, t.dtype) # - [(b'a', 1) (b'b', 2)] [('f0', '|S1'), ('f1',
'i8')]
s.seek(0)
t = np.genfromtxt(s, dtype=None, converters={0: lambda s:
s.decode(utf-8)})
print(t, t.dtype) # - [('', 1) ('', 2)] [('f0', 'U0'), ('f1', 'i8')]
Could you open a ticket for this?
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
[Numpy-discussion] Is NumpyDotNet (aka numpy-refactor) likely to be merged into the mainline?
With a little work, I think numpy/scipy could be very useful to those of us who have to program on .NET for one reason or another, but 64-bit is currently not supported (at least, not as released). I'm considering working out 64-bit support, but it appears to me like the numpy-refactor repository isn't on a path to merging with the mainline, and is likely to bit-rot (if it hasn't already). Is anyone working on this, or is NumpyDotNet 'resting' at the moment, so to speak? Its sort of pointless to work on a dead-end branch ;-) thanks! -seth ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.comwrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries,
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 1:34 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can
Re: [Numpy-discussion] Issue Tracking
Hi folks, sorry for not jumping in before, swamped with deadlines... On Mon, Apr 30, 2012 at 8:14 PM, Jason Grout jason-s...@creativetrax.com wrote: I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project I think your summary is all very valid, and mostly we've just learned to live with some of its limitations and hacked around some of them. Now, one thing that the hyper-simplistic github tracker has made me think is about the value of over-sophisticated tools, which sometimes can become an end in and of themselves... Because the tracker is so absurdly simple, you just can't spend much time playing with it and may spend more time coding on the project itself. But having said that, I still think GHI (short for github issues) has *real* issues that are true limitations, and I keep hoping they'll improve (though it's starting to look more like unreasonable hope, as time goes by). 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I don't think it takes too much time in practice, but it's indeed a poor man's substitute for the google system. And for certain things, like priority, you *really* want a proper way of saying 'show me all issues of priority X or higher', which you can't do with labels. 2. The disjointed relationship between pull requests and issues. They This is the one that pisses me off the most. It's a real, constant drag to not be able to label issues and see those labels. I can't fathom why on Earth GH hasn't added this, and what bizarre thought process could possibly have led to PRs being implemented alongside issues and yet, being hobbled by deliberately *hiding* their labels. It feels almost as a misfeature written out of spite against the users. I fume every time I try to prioritize work on open PRs and have to do it via post-it notes on the wall because GH decided to *hide* the labels for PRs from me. Argh... 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. This one doesn't actually bother me in practice at all. Gist works perfectly for text snippets, and since they're version-controlled, it's even better than static attachments. And for images, a simple imgur upload (many screenshot programs even upload for you) along with  provides even better results: the images are inlined in the discussion. See for example: https://github.com/ipython/ipython/issues/1443 So here, I actually *prefer* gist+image urls to an attachment system. Arguably the externally hosted images could be lost if that server goes down, so it would perhaps be better to have them hosted at GH itself. They might consider that (or simply allowing gists to take binary uploads). 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries, so maybe this isn't insurmountable. Yes, this is doable with a little elbow grease. 5. Stylistically, the webpage is not very dense on information. I get frustrated when trying to see the issues because they only come 25 at a time, and never grouped into any sort of groupings, and there are only 3 options for sorting issues. Compare the very nice, dense layout of Google Code issues or bitbucket. Google Code issues also lets you cross-tabulate the issues so you can quickly triage them. Compare also the pretty comprehensive options for sorting and grouping things in trac. Agreed. Not a big deal breaker for us, but perhaps we're just living in blissful ignorance of what we're missing :) 6. Side-by-side diffs are nice to have, and I believe bitbucket and google code both have them. Of course, this isn't a deal-breaker because you can always pull the branch down, but it would be nice to have, and there's not really a way we can put it into the github tracker ourselves. I guess they could add a markdown extension that displays a .diff url as a real diff... That said, it is nice to have code and dev conversations happening in one place. There are great things about github issues, of course. But I'm not so sure, for me, that they outweigh some of the administrative issues listed above. This is the real deal. In the end, we've learned to live with some of the GHI limitations and grumble under our breath about others, but there's genuine
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 2:17 PM, Charles R Harris charlesr.har...@gmail.comwrote: On Tue, May 1, 2012 at 1:34 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries.
Re: [Numpy-discussion] Issue Tracking
On 5/1/12 3:19 PM, Fernando Perez wrote: But if you do decide to go with GHI, it should be based on what the system is like*today*, not on the hope that it will get better. About a month ago they broke label filtering by turning multi-label filters into an OR operation, which effectively rendered the labels completely useless. Despite reporting it multiple times via their support tracker AND speaking in person at someone from GH, it still took well over a month or two to fix. For something so simple and so essential, I consider that to be atrociously bad response. So don't go for GHI on the hope it will get a lot better soon, b/c their recent record doesn't support a hopeful viewpoint. This example indicates that basing your decision on what it is like *today* may not be valid either. You'd hope that they won't do something really silly, but you can't change it if they do, and you can't just keep running the old version of issues to avoid problems since you don't have control over that either. Anyway, like everyone else has said, Ralf, Pauli, et. al. are really the ones to vote in this. Given Fernando's responses, I realize why GHI still works for us---our small project has me and 2-4 students, and we all pretty much meet each week to triage issues together, and there are only about 40 open issues. It's a simple enough project that we need *something*, but we don't need to spend our time setting up complicated infrastructure. I do wish we could use Google Code issues with Github pull requests, though :). Thanks, Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.2 release - backports and MSVC testing help
On 4/30/2012 1:16 PM, Ralf Gommers wrote: Hi all, Charles has done a great job of backporting a lot of bug fixes to 1.6.2, see PRs 260, 261, 262 and 263. For those who are interested, please have a look at those PRs to see and comment on what's proposed to go into 1.6.2. I also have a request for help with testing: can someone who uses MSVC test (preferably with a 2.x and a 3.x version)? I have a branch with all four PRs merged at https://github.com/rgommers/numpy/tree/bports Thanks, Ralf Any chance pull requests 188 and 227 could make it into numpy 1.6.2? https://github.com/numpy/numpy/pull/188 https://github.com/numpy/numpy/pull/227 Thank you, Christoph ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.2 release - backports and MSVC testing help
On Tue, May 1, 2012 at 3:09 PM, Christoph Gohlke cgoh...@uci.edu wrote: On 4/30/2012 1:16 PM, Ralf Gommers wrote: Hi all, Charles has done a great job of backporting a lot of bug fixes to 1.6.2, see PRs 260, 261, 262 and 263. For those who are interested, please have a look at those PRs to see and comment on what's proposed to go into 1.6.2. I also have a request for help with testing: can someone who uses MSVC test (preferably with a 2.x and a 3.x version)? I have a branch with all four PRs merged at https://github.com/rgommers/numpy/tree/bports Thanks, Ralf Any chance pull requests 188 and 227 could make it into numpy 1.6.2? https://github.com/numpy/numpy/pull/188 Looks easy to do. https://github.com/numpy/numpy/pull/227 This one is isolated to random. I'll put up another PR for the backport. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 1:36 PM, Jason Grout jason-s...@creativetrax.com wrote:
This example indicates that basing your decision on what it is like
*today* may not be valid either. You'd hope that they won't do
Very true ;)
Anyway, like everyone else has said, Ralf, Pauli, et. al. are really the
ones to vote in this. Given Fernando's responses, I realize why GHI
still works for us---our small project has me and 2-4 students, and we
all pretty much meet each week to triage issues together, and there are
only about 40 open issues. It's a simple enough project that we need
I just reread my reply with a full stomach, and I wanted to add
something, because I think it may appear a bit too negative. *In
practice*, the system does work very fluidly, and other than the
no-labels-on-PRs, it just gets out of your way. Being able to simply
type #NN in any comment or git commit ('closes #NN') and get
everything auto-linked, closed if needed, etc., has major value in
practice, and shouldn't be underestimated.
Using two separate tools adds real friction to the everyday workflow,
and if GH has taught me one thing, it's that the very fluid workflow
they enable leads to massive productivity improvements. For IPython,
the change from Launchpad/bzr to GH/git has been truly night and day
in terms of productivity. We process a volume of code today that
would be unthinkable before, and I think a big part of that is that
the tools simply get out of our way and let us just work.
So, as much as I do complain about real problems with GHI, I also
think it's important to evaluate carefully the cost of a dual-system
solution. Sometimes the lesser tool you know how to use is better
than the fancier one that creates friction. Put another way: no
matter how fancy your new $400 racket is, you'll never beat Pete
Sampras on a tennis court even if he's using a wood board to play :)
Cheers,
f
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
Thanks Ralf, I agree that Pauli and David have a lot of say in what we do. Thanks for reminding.We will wait to hear from them. If together you three feel like we should set up a separate Redmine instance than we can do that and just pay special attention with the Github integration and links in the right places to make sure the conversations stay connected. I just wanted to point out some of the benefits of Github that I've noticed. I can see pros and cons for both. Thanks for reminding me of the issue that users can't assign lables --- that must be done by a maintainer. That might be a benefit though, providing some control over how labels get assigned. Thanks, -Travis On May 1, 2012, at 2:34 PM, Ralf Gommers wrote: On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.io wrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So
Re: [Numpy-discussion] Issue Tracking
01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] The main problem with Github (besides the issues/PRs thing and no attachments, which I can live with) is that to make it work we'll have to religiously label everything. And because users aren't allowed to attach labels, it will require a larger time investment from maintainers. Are we okay with that? If everyone else is and we can distribute this task, it's fine with me. I think this is probably not a very big deal, as long as there is a way of seeing the inbox of unlabeled bugs, and as long as the tracker sends mail about new bugs. The rate at which tickets are reported to us is at the moment not too that big. Triaging them will probably boil down to a five minutes of brainless work every second week, or so. David has been investigating bug trackers long before me, and Pauli has done most of the work administering Trac as far as I know, so I'd like to at least hear their preferences too before we make a decision. Then I hope we can move this along quickly, because any choice will be a huge improvement over the current situation. One big plus with Github compared to Redmine et al. is that someone else (TM) hosts it. One thing less to think about. Apart from the attachments issue, I don't have very big quibbles with the GH issue tracker. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.2 release - backports and MSVC testing help
On Tue, May 1, 2012 at 3:09 PM, Christoph Gohlke cgoh...@uci.edu wrote: On 4/30/2012 1:16 PM, Ralf Gommers wrote: Hi all, Charles has done a great job of backporting a lot of bug fixes to 1.6.2, see PRs 260, 261, 262 and 263. For those who are interested, please have a look at those PRs to see and comment on what's proposed to go into 1.6.2. I also have a request for help with testing: can someone who uses MSVC test (preferably with a 2.x and a 3.x version)? I have a branch with all four PRs merged at https://github.com/rgommers/numpy/tree/bports Thanks, Ralf Any chance pull requests 188 and 227 could make it into numpy 1.6.2? https://github.com/numpy/numpy/pull/188 Added to PR 260. The relevant routines had been rewritten prior to the patch and the variable changed. I think I got this right, but you should test it. https://github.com/numpy/numpy/pull/227 Is up as PR 265. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Continuous Integration
Pauli Virtanen pav at iki.fi writes: 01.05.2012 11:14, David Froger kirjoitti: Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012: If you have particular reasons why we should choose a particular CI service, please speak up and let your voice be heard. There is still time to make a difference in what we are setting up. Hi all, What about buildbot? (http://trac.buildbot.net/) I'm using it currently, and like it because is GPL 2, configuration files are powerful Python scripts, and development team is active and dynamic. We're currently using it: http://buildbot.scipy.org Although, it hasn't been building automatically for some time now. I've been working on setting up a new buildbot for NumPy. Unfortunately, I don't have much time to work on it, so it's slow going! Right now I am still at the stage of getting NumPy to pass all its tests on the machines I'm using as test slaves. After that, I plan to transfer existing slaves to the new setup, and then maybe ask for new volunteer slave machines (if people think the buildbot setup is useful). One nice feature of the new buildbot setup is that it can build and test a pull request, reporting the results back via a comment on the pull request. It has the following shortcomings: - Apparently, for one master instance, only one project. As others have said, this is no longer true. - Last time I looked, Git integration was poor. Maybe this has improved since... Again, as others have said, I think this has been improved since last time you looked. Buildbot can receive github notifications or can poll a repository periodically. On the other hand, I've also been trying ShiningPanda (https:// jenkins.shiningpanda.com/scipy/) because I like the idea of a hosted CI solution. Again, though, I haven't yet got all the tests to pass on ShiningPanda's default Debian 6 setup (and again, that's because of a lack of time). So, I'm working on Buildbot and ShiningPanda from the community side, but am always ready to step aside if someone else has time :) Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Continuous Integration
So, I'm working on Buildbot and ShiningPanda from the community side, but am always ready to step aside if someone else has time :) Keep it up. Your input and feedback is invaluable. Plus, in this kind of situation, the more the merrier. There are a lot of different agents to test on. -Travis Chris ___ 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] Test failures - which dependencies am I missing?
Keith Hughitt keith.hughitt at gmail.com writes: Hi Chris, Try sudo apt-get build-dep python-numpy to install the dependencies for building NumPy. I believe it will install all of the optional dependencies as well. Thanks for that, but I'd already tried it and found the same failures. However, I also found that on my version of Ubuntu (10.04 LTS), which includes NumPy 1.3.0, running numpy.test(verbose=3) yielded the following: nose.config: INFO: Excluding tests matching ['f2py_ext','f2py_f90_ext','gen_ext', 'pyrex_ext', 'swig_ext', 'array_from_pyobj'] I'm not sure where this nose config comes from, but at least someone else knows about some of these failures; presumably they are not important. My next step was going to be searching some mailing lists/contacting the packager... Thanks, Chris ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Continuous Integration
Hi, On Tue, May 1, 2012 at 3:22 PM, Chris Ball ceb...@gmail.com wrote: Pauli Virtanen pav at iki.fi writes: 01.05.2012 11:14, David Froger kirjoitti: Excerpts from Travis Oliphant's message of mar. mai 01 01:39:26 +0200 2012: If you have particular reasons why we should choose a particular CI service, please speak up and let your voice be heard. There is still time to make a difference in what we are setting up. Hi all, What about buildbot? (http://trac.buildbot.net/) I'm using it currently, and like it because is GPL 2, configuration files are powerful Python scripts, and development team is active and dynamic. We're currently using it: http://buildbot.scipy.org Although, it hasn't been building automatically for some time now. I've been working on setting up a new buildbot for NumPy. Unfortunately, I don't have much time to work on it, so it's slow going! Right now I am still at the stage of getting NumPy to pass all its tests on the machines I'm using as test slaves. After that, I plan to transfer existing slaves to the new setup, and then maybe ask for new volunteer slave machines (if people think the buildbot setup is useful). One nice feature of the new buildbot setup is that it can build and test a pull request, reporting the results back via a comment on the pull request. It has the following shortcomings: - Apparently, for one master instance, only one project. As others have said, this is no longer true. - Last time I looked, Git integration was poor. Maybe this has improved since... Again, as others have said, I think this has been improved since last time you looked. Buildbot can receive github notifications or can poll a repository periodically. On the other hand, I've also been trying ShiningPanda (https:// jenkins.shiningpanda.com/scipy/) because I like the idea of a hosted CI solution. Again, though, I haven't yet got all the tests to pass on ShiningPanda's default Debian 6 setup (and again, that's because of a lack of time). The advantage of having some minimal server as master for buildbot is that you can very easily add slaves on which you can trigger builds and get back build logs automatically. As I understand ShiningPanda (never used it, just talked to Fernando), you can push your own build reports up to a ShiningPanda instance, but I hear it's not so easy to trigger builds and upload reports from external slaves. By the way, in case it's interesting, here is our master.cfg for the nipy buildbot; not very pretty, but fairly easy to add a new slave and a new builder: https://github.com/nipy/nibotmi/blob/master/master.cfg and back-of-envelope procedures to set it up: https://github.com/nipy/nibotmi/blob/master/install.rst In particular see 'setting up a buildslave' at the end. Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Building NumPy for Python on specified directory
Hi all, I'm now installing Python 2.7.3 and NumPy 1.6.1 on clean-installed CentOS 6.2. At first, I installed Python as below: ./configure --prefix=/usr/local --enable-shared make make install vi /etc/ld.so.conf #add /usr/local/lib /sbin/ldconfig and successfully installed NumPy. But if I install Python as below: ./configure --prefix=/usr/local/python-273 --enable-shared make make install vi /etc/ld.so.conf #add /usr/local/python-273/lib /sbin/ldconfig then setup.py build dumped these errors: compile options: '-Inumpy/core/include -Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/local/python-273/include/python2.7 -Ibuild/src.linux-x86_64-2.7/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.7/numpy/core/src/umath -c' gcc: build/src.linux-x86_64-2.7/numpy/core/src/_sortmodule.c gcc -pthread -shared build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/numpy/core/src/_sortmodule.o -L. -Lbuild/temp.linux-x86_64-2.7 -lnpymath -lm -lpython2.7 -o build/lib.linux-x86_64-2.7/numpy/core/_sort.so /usr/bin/ld: cannot find -lpython2.7 collect2: ld returned 1 exit status /usr/bin/ld: cannot find -lpython2.7 collect2: ld returned 1 exit status error: Command gcc -pthread -shared build/temp.linux-x86_64-2.7/build/src.linux-x86_64-2.7/numpy/core/src/_sortmodule.o -L. -Lbuild/temp.linux-x86_64-2.7 -lnpymath -lm -lpython2.7 -o build/lib.linux-x86_64-2.7/numpy/core/_sort.so failed with exit status 1 How could I build NumPy for Python on specified directory? ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 7:48 PM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... much better now If I were still going through tickets in scipy, I would prefer this view http://projects.scipy.org/scipy/query?status=applystatus=needs_decisionstatus=needs_infostatus=needs_reviewstatus=needs_workstatus=newstatus=reopenedcomponent=scipy.statsorder=status to something like this https://github.com/ipython/ipython/issues?direction=desclabels=windowspage=1sort=createdstate=open I never figured out how to effectively search in github, while with trac, I could always immediately reply to a question with the relevant link, or check the history instead of relying on memory. Josef Pauli ___ 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] Issue Tracking
On Tue, May 1, 2012 at 6:18 PM, josef.p...@gmail.com wrote: On Tue, May 1, 2012 at 7:48 PM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... much better now If I were still going through tickets in scipy, I would prefer this view http://projects.scipy.org/scipy/query?status=applystatus=needs_decisionstatus=needs_infostatus=needs_reviewstatus=needs_workstatus=newstatus=reopenedcomponent=scipy.statsorder=status to something like this https://github.com/ipython/ipython/issues?direction=desclabels=windowspage=1sort=createdstate=open I never figured out how to effectively search in github, while with trac, I could always immediately reply to a question with the relevant link, or check the history instead of relying on memory. I would agree that a good search facility is essential, and not keyword/tag based. I've found some trac tickets with google on occasion, although not by initial intent. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Test failures - which dependencies am I missing?
On Tue, May 1, 2012 at 5:20 PM, Chris Ball ceb...@gmail.com wrote: Keith Hughitt keith.hughitt at gmail.com writes: Hi Chris, Try sudo apt-get build-dep python-numpy to install the dependencies for building NumPy. I believe it will install all of the optional dependencies as well. Thanks for that, but I'd already tried it and found the same failures. However, I also found that on my version of Ubuntu (10.04 LTS), which includes NumPy 1.3.0, running numpy.test(verbose=3) yielded the following: nose.config: INFO: Excluding tests matching ['f2py_ext','f2py_f90_ext','gen_ext', 'pyrex_ext', 'swig_ext', 'array_from_pyobj'] Doesn't Debian separate f2py from numpy? Also, long running tests are skipped unless you specify 'full' as the test argument. Also, I don't recall if the f2py tests were actually installed in 1.3, I think that came later around 1.6. I'm not sure where this nose config comes from, but at least someone else knows about some of these failures; presumably they are not important. My next step was going to be searching some mailing lists/contacting the packager... Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 5:24 PM, Charles R Harris charlesr.har...@gmail.com wrote: I would agree that a good search facility is essential, and not keyword/tag based. Github issues does have full-text search, and up until now I haven't really had too many problems with it. No sophisticated filtering or anything, but basic search with the option to see open/closed/all issues seems to work OK. Josef I'm curious, which problems have you had with it? Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 8:29 PM, Fernando Perez fperez@gmail.com wrote: On Tue, May 1, 2012 at 5:24 PM, Charles R Harris charlesr.har...@gmail.com wrote: I would agree that a good search facility is essential, and not keyword/tag based. Github issues does have full-text search, and up until now I haven't really had too many problems with it. No sophisticated filtering or anything, but basic search with the option to see open/closed/all issues seems to work OK. Josef I'm curious, which problems have you had with it? maybe searching issues and pull requests is ok. The problem is that in statsmodels we did a lot of commits without pull requests, and I'm not very good searching in git either. (I don't remember which change I looked for but I got lost for half an hour searching for a change with git and github until I had to ask Skipper, who found it immediately.) What I was used to is integrated search without extra work, like this http://projects.scipy.org/scipy/search?q=mannwhitney and I had pretty much all the discussion to the history of a function. scipy.stats is easy too search because the function names are good search terms. scipy pull request don't have a search facility, as far as I was able to figure out, because the issues are not enabled, so I cannot check how good it would be. Josef Cheers, f ___ 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] Issue Tracking
On Tue, May 1, 2012 at 6:04 PM, josef.p...@gmail.com wrote: maybe searching issues and pull requests is ok. The problem is that in statsmodels we did a lot of commits without pull requests, and I'm not very good searching in git either. (I don't remember which change I looked for but I got lost for half an hour searching for a change with git and github until I had to ask Skipper, who found it immediately.) What I was used to is integrated search without extra work, like this http://projects.scipy.org/scipy/search?q=mannwhitney and I had pretty much all the discussion to the history of a function. Ah, I see: the point was really the ability to search into the commit history directly through the web UI. Indeed, I'd never thought of that b/c I simply use the git machinery at the command-line for everything. But I can see how that Trac search box, with the ability to selectively tick on/off searching into commits, bugs, etc, could be very useful. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On 5/1/12 7:24 PM, Charles R Harris wrote: I would agree that a good search facility is essential, and not keyword/tag based. I've found some trac tickets with google on occasion, although not by initial intent. I use google to search the sage trac these days, using a shortcut to limit search results to the Sage trac site. To do this in Chrome, go to Preferences, then Basics, then Manage Search Engines. Down at the bottom, I fill in the three fields for a new search engine: Name: trac Keyword: t URL: http://www.google.com/#q=site:trac.sagemath.org+%s Then whenever I want to search trac, I just type t (t space) in the URL bar of Chrome, then type whatever I'm searching for. Google almost always pulls up the right ticket in the top few hits. And it's way faster than the trac search. Thanks, Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... That's amazing - not only does it not give errors anymore, it's also an order of magnitude faster. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
