Re: [matplotlib-devel] git migration this weekend

2011-02-27 Thread Jouni K . Seppänen 
Darren Dale  writes:

> On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing  wrote:
>> On 02/26/2011 10:54 AM, Darren Dale wrote:
>>
>> The submitter info is lost?
>> And when it was originally submitted?
>
> No, I can improve it so this information is included.

That's clearly in the xml file, except that I don't know if we can map
sourceforge userids to email addresses - that sounds like something that
spammers would want to do.

One thing that I think is missing in the xml file are the attachment
contents. There are filenames and some kind of ids that presumably can
be used to get the files via the sf bug pages, but this information only
occurs in the artifact_history subsection. To get the correct files
you'll have to first parse this to figure out that file 396374 was added
but then deleted and then file 396688 was added:



File Added
396688: 
set_verts_cleanup_2.patch
1293000689
notmuchtotell



File Deleted
396374: 
1293000467
notmuchtotell



File Added
396374: set_verts_cleanup.patch
1292605835
notmuchtotell



> I agree that the github interface is not great. The github devs seem
> to know that everybody complains about it.
>
> There are some good things about it though. Labels, the ability to
> link between an issue and the commits that resolve it, the ability for
> people to provide feedback on what issues are important to them.

Does anyone have experience with other trackers? bugs.python.org seems
to be using Roundup - any experiences with that?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

2011-02-27 Thread Darren Dale 
On Sun, Feb 27, 2011 at 7:46 AM, Jouni K. Seppänen  wrote:
> Darren Dale  writes:
>
>> On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing  wrote:
>>> On 02/26/2011 10:54 AM, Darren Dale wrote:
>>>
>>> The submitter info is lost?
>>> And when it was originally submitted?
>>
>> No, I can improve it so this information is included.
>
> That's clearly in the xml file, except that I don't know if we can map
> sourceforge userids to email addresses - that sounds like something that
> spammers would want to do.

I was thinking to just use the SourceForge IDs.

> One thing that I think is missing in the xml file are the attachment
> contents. There are filenames and some kind of ids that presumably can
> be used to get the files via the sf bug pages, but this information only
> occurs in the artifact_history subsection. To get the correct files
> you'll have to first parse this to figure out that file 396374 was added
> but then deleted and then file 396688 was added

That's a good idea. But given the limitations of attaching files to
issues at github, I thought it would be better to instead provide
enough context in the github issue (SourceForge messages and history)
so that if such files are needed, they could be retrieved from
SourceForge.

My thinking on issue tracking is similar to Fernando's. Github issues
integration with some of the other features of the site is really
nice, and makes the issue tracker much more a part of the development
process than was the case at sourceforge. But its a different
paradigm: patches are submitted as pull requests rather than
attachments in the issue tracker.

Here is another big change difference: tickets can be created at
sourceforge without a sourceforge account (hence the spam). At github,
you have to have an account to file a ticket.

>> I agree that the github interface is not great. The github devs seem
>> to know that everybody complains about it.
>>
>> There are some good things about it though. Labels, the ability to
>> link between an issue and the commits that resolve it, the ability for
>> people to provide feedback on what issues are important to them.
>
> Does anyone have experience with other trackers? bugs.python.org seems
> to be using Roundup - any experiences with that?

I have not worked with Roundup. I have a little experience with Trac
(meh), and with Launchpad (good integration with project management
features, which are lacking at github.) What I was thinking to achieve
by testing migration of the issues to github was not simply to get
away from sourceforge, but to benefit from the integration of
services. If we are not convinced that github issues provides
everything we need, I think we should provide feedback to the github
devs and stick with sourceforge for the time being.

Darren

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

2011-02-27 Thread John Hunter 
On Sun, Feb 27, 2011 at 1:06 AM, Eric Firing  wrote:

> That's a good point.  Until fairly recently, interactive behavior worked
> across backends only via ipython magic, so I think the non-interactive
> default had a solid historical rationale.  Now, however, we could
> probably make interactive mode the startup default for interactive
> backends without causing any problems.  I agree that this would be more
> intuitive and more familiar to people coming from matlab.

Probably right -- this was a design decision made early on when I did
not see a good way around the problem that the idle drawing across
backends now solves.  There will probably be some unintended
consequences of changing the default, but as long as we document it
prominently and provide a way for people to change the behavior to the
old wan in their rc, it is probably a good idea to make this change.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

2011-02-27 Thread Darren Dale 
On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale  wrote:
> If we are not convinced that github issues provides
> everything we need, I think we should provide feedback to the github
> devs and stick with sourceforge for the time being.

Here is a copy of a message I just sent to supp...@github.com. If you
have other specific concerns, please let me know, and I will pass them
along if I hear back from someone at github.:

Hello,

Thank you for all your great work on github.

I am one of the developers of the matplotlib project
(matplotlib.github.com). We recently converted our svn repositories to
git, and started hosting them at github. This weekend I worked on
testing migrating the issues from the sourceforge tracker (see
https://github.com/darrendale/mpl-issues), but we have some concerns
about the usability of the github issue tracker:

* Our project produces graphical output, so the ability to attach
files (like images and test scripts) to an issue is of critical
importance to our project.
* We would miss the ability to file tickets through the browser
without signing in to github.
* Having to repeatedly request "more" to see all the tickets is rather painful
* We would miss the ability to assign a ticket to a developer.
Creating a label for a developer is not seen to be enough. It would be
nice if we could actually assign a developer to an issue, and from
then on only the developer would receive emails concerning activity on
the issue, unless others requested notifications.
* It would be nice if people could register/unregister to receive
notifications when there is activity on a specific issue that affects
them.
* It would be nice to be able to mark issues as pending after they are
committed, and mark them as closed when publicly released, along with
the release version(s) which addressed the problem (this latter
feature would be brilliant if github had project management features)
* It would be nice to mark an issue as a duplicate, automatically
linking to the appropriate issue and registering the reporter for
updates on the open issue

I have made the case to the other devs that the benefits of github
issues integration with the rest of the site is compelling, but at the
end of the day, some of these features are too important to us to
migrate to github issues at this time.

Concerning the websites, in general I like the gh-pages and
myproject.github.com solutions. However, the matplotlib documentation
is generated from RestructuredText using Sphinx. The resulting html is
about 80 MB, and has a lot of graphics and examples. We would rather
not track changes to this generated content, since we already track
changes to the (much smaller) source: it takes up additional space and
takes a long time to upload to the server.

Finally, I was hoping that you might consider adding some project
management features to github. About a year ago, I migrated a project
(github.com/python-quantities) from Launchpad. I like github much
better, but miss some of Launchpad's project management features. For
instance, it would be nice if we could specify and schedule an
upcoming release at github (which could be used to integrate with
pending issue closures), and then once we create the corresponding tag
in git, github creates a new directory in an official releases
downloads area (perhaps along with .zip and .tgz files). Also, the
release graph at a projects main page at Launchpad was nice.

I hope this doesn't seem too critical, I just wanted to give some
constructive feedback. Thank you again for all you've done!

Best regards,
Darren Dale

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

2011-02-27 Thread Darren Dale 
On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale  wrote:
> If we are not convinced that github issues provides
> everything we need, I think we should provide feedback to the github
> devs and stick with sourceforge for the time being.

Having said that, depending on how the github devs respond, we might
want to give lighthouse (lighthouseapp.com) a look. It claims to
integrate with github, supports attachments, integrates with email,
would support separate trackers for the various matplotlib repos, and
it is apparently free for open-source projects:
http://matplotlib.lighthouseapp.com/projects/70830-matplotlib/overview
.

If you are interested in playing around with lighthouse and want
elevated privileges, send me (off list) the email address you used to
sign up at lighthouse. If it looks promising, we could see how well it
integrates with github.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

2011-02-27 Thread Benjamin Root 
On Sat, Feb 26, 2011 at 12:22 PM, Eric Firing  wrote:

> On 02/26/2011 04:51 AM, Darren Dale wrote:
> > On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen  wrote:
> >> On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
> >> [clip]
> >>> Yes.  The minimum version for this Python 3.x compatibility work is
> >>> Python 2.6.  Anything earlier is just insane ;)
> >>
> >> Out of curiosity: did you consider using a single source tree for Python
> >> 2.x and 3.x, rather than a separate branch; providing Python 3 support
> by
> >> running 2to3 on build stage and #ifdef's + compatibility headers in C
> >> code?
> >>
> >> This approach allowed Numpy to support Pythons down to 2.4 with little
> >> extra work, and requires manual Python 3 specific fixes only when
> >> something breaks (which does not seem to occur often in practice).
> >
> > At some point, it will make sense to discontinue support for
> > <=python-2.5 (maybe even 2.6). I have used numpy's 2to3 for my
> > quantities project (admittedly a *much* smaller project with *much*
> > smaller exposure), but recently dropped backwards compatibility and
> > now 2.6-3.2 are supported in a single branch without use of 2to3. I
> > prefer this approach, it seems to be working out without too much
> > trouble so far.
> >
> > Darren
> >
>
> Supporting earlier versions is nice--I work with many machines running
> 2.5, and keep mpl up to date on several of them, but thankfully I have
> nothing still stuck on 2.4--but for mpl, now that we have a pretty good
> 1.x version, I don't think it would be too hard on users if we made a
> last release supporting earlier pythons and then dropped support for
> them in subsequent releases.  It would not mean people with earlier
> pythons couldn't run mpl, it would just mean they would get no new
> improvements, and no new bug fixes unless someone stepped forward to
> maintain the old branch.
>
> Dropping 2.6 any time soon would be too drastic for my liking, though.
> It would require that any development work done on recent ubuntu
> systems, for example, would require first installing a non-default
> version of python.  So, I hope the py3k work can result in a 2.6-and-up
> codebase--is that the present goal?  Those of us developing on 2.6 will
> need to learn exactly how to avoid breaking 3.1 compatibility.
>
> Eric
>
>
I was just looking through some code and I realized that if we are now
willing (able?) to drop support for 2.4-2.5, then maybe we could benefit
from some updates to our coding practices?  For example, I would personally
love to see more use of conditional expressions (new in 2.5).

In addition, I wonder if we could possibly consider updating our policy
regarding function parameter handling?  In particular, I am referring to
this section of our coding guide:

In some cases, you may want to consume some keys in the local function, and
> let others pass through. You can pop the ones to be used locally and pass
> on the rest. For example, in 
> plot(),
> scalex and scaley are local arguments and the rest are passed on as
> Line2D()keyword
>  arguments:
>
> # in axes.py
> def plot(self, *args, **kwargs):
>
> scalex = kwargs.pop('scalex', True)
>
> scaley = kwargs.pop('scaley', True)
>
> if not self._hold: self.cla()
>
> lines = []
> for line in self._get_lines(*args, **kwargs):
>
> self.add_line(line)
> lines.append(line)
>
> Note: there is a use case when kwargs are meant to be used locally in the
> function (not passed on), but you still need the **kwargs idiom. That is
> when you want to use *args to allow variable numbers of non-keyword args.
> In this case, python will not allow you to use named keyword args after the
> *args usage, so you will be forced to use **kwargs. An example is
> matplotlib.contour.ContourLabeler.clabel():
>
# in contour.py
def clabel(self, *args, **kwargs):
fontsize = kwargs.get('fontsize', None)
inline = kwargs.get('inline', 1)
self.fmt = kwargs.get('fmt', '%1.3f')
colors = kwargs.get('colors', None)
if len(args) == 0:
levels = self.levels
indices = range(len(self.levels))
elif len(args) == 1:
...etc...

I know that this restriction is no longer the case in later versions of
python, but I can't seem to find out which version this restriction was
changed.

Are there other practices that we can now allow?

Ben Root
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Matplotlib-devel mailing

Re: [matplotlib-devel] What's the status of the py3k branch?

2011-02-27 Thread John Hunter 
On Sun, Feb 27, 2011 at 1:13 PM, Benjamin Root  wrote:
> I was just looking through some code and I realized that if we are now
> willing (able?) to drop support for 2.4-2.5, then maybe we could benefit
> from some updates to our coding practices?  For example, I would personally
> love to see more use of conditional expressions (new in 2.5).

We are only talking about the python 3 branch here.  The master branch
should remain 2.4 compliant until we merge the 3.x into master.
Before we do that, we'll probably want to do a 1.1 or 1.2 or
1.whatever release and maintenance branch so we have a python 2.4
which is as current as possible.

JDH

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

2011-02-27 Thread Benjamin Root 
On Sun, Feb 27, 2011 at 1:21 PM, John Hunter  wrote:

> On Sun, Feb 27, 2011 at 1:13 PM, Benjamin Root  wrote:
> > I was just looking through some code and I realized that if we are now
> > willing (able?) to drop support for 2.4-2.5, then maybe we could benefit
> > from some updates to our coding practices?  For example, I would
> personally
> > love to see more use of conditional expressions (new in 2.5).
>
> We are only talking about the python 3 branch here.  The master branch
> should remain 2.4 compliant until we merge the 3.x into master.
> Before we do that, we'll probably want to do a 1.1 or 1.2 or
> 1.whatever release and maintenance branch so we have a python 2.4
> which is as current as possible.
>
> JDH
>


Ah, that wasn't entirely clear.  Good to know before I started messing
things up.

Ben Root
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend

2011-02-27 Thread Darren Dale 
Hi Pierre,

Are you still maintaining the qt4 plot editor dialog? It doesn't
appear to be working properly: setting the marker and linestyle
options does not effect the plot (tested on Ubuntu Natty alpha, with
the v1.0.x branch on python-2.7 and PyQt4-4.8.3). I have a really hard
time following the code. Also, the dialog makes the qt4 backend
unusable with PyQt4's API v2, which does not provide a QString object.

Darren

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend

2011-02-27 Thread Darren Dale 
On Sun, Feb 27, 2011 at 3:27 PM, Darren Dale  wrote:
> Hi Pierre,
>
> Are you still maintaining the qt4 plot editor dialog? It doesn't
> appear to be working properly: setting the marker and linestyle
> options does not effect the plot (tested on Ubuntu Natty alpha, with
> the v1.0.x branch on python-2.7 and PyQt4-4.8.3).

Sorry, I think this was a mistake on my part...

> I have a really hard
> time following the code.

... but I do have a really hard time understanding the code.

> Also, the dialog makes the qt4 backend
> unusable with PyQt4's API v2, which does not provide a QString object.

This can be addressed with the following change, which I just

@@ -56,9 +56,9 @@ from PyQt4.QtGui import (QWidget, QLineEdit, QComboBox, QLabel
  QPixmap, QTabWidget, QApplication, QStackedWidget,
  QDateEdit, QDateTimeEdit, QFont, QFontComboBox,
  QFontDatabase, QGridLayout)
-from PyQt4.QtCore import (Qt, SIGNAL, SLOT, QSize, QString,
+from PyQt4.QtCore import (Qt, SIGNAL, SLOT, QObject, QSize,
   pyqtSignature, pyqtProperty)
import datetime


 class ColorButton(QPushButton):
@@ -102,7 +102,8 @@ def text_to_qcolor(text):
 Avoid warning from Qt when an invalid QColor is instantiated
 """
 color = QColor()
-if isinstance(text, QString):
+if isinstance(text, QObject):
+# actually a QString, which is not provided by the new PyQt4 API:
 text = str(text)
 if not isinstance(text, (unicode, str)):
 return color

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

2011-02-27 Thread Darren Dale 
On Sun, Feb 27, 2011 at 9:45 AM, Darren Dale  wrote:
> On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale  wrote:
>> If we are not convinced that github issues provides
>> everything we need, I think we should provide feedback to the github
>> devs and stick with sourceforge for the time being.
>
> Here is a copy of a message I just sent to supp...@github.com. If you
> have other specific concerns, please let me know, and I will pass them
> along if I hear back from someone at github.

Here is the exchange I had with one of github's support staff:

GH: Thank you very much for your feedback. We already work on improving issues.

DD: Thank you for your reply. Is it ok if I relay this information to
the other developers on my project?

GH: Yes, but let me just say that we never have an ETA and also I
can't confirm that you'll be completely satisfied with our
improvements.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel