matplotlib-devel Mailing List for matplotlib

On 04/11/2011 11:19 AM, Darren Dale wrote:
> On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom<md...@st...> wrote:
>> (Hmm... git doesn't use its own issue tracker for tracking its own
>> issues... what does that say?<wink>)
>
> Brilliant, whatever they use allows uploading attachments.
They are using this: http://tenderapp.com/

On Mon, Apr 11, 2011 at 4:19 PM, Darren Dale <dsd...@gm...> wrote:
> On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom <md...@st...>
> wrote:
> > (Hmm... git doesn't use its own issue tracker for tracking its own
> > issues... what does that say? <wink>)
>
> Brilliant, whatever they use allows uploading attachments.
>
>
Maybe it would be made available for "Issues: Deep Space Nine", or do I have
to wait until "Voyager"?
Ben Root

On Mon, Apr 11, 2011 at 3:40 PM, Michael Droettboom <md...@st...> wrote:
> (Hmm... git doesn't use its own issue tracker for tracking its own
> issues... what does that say? <wink>)
Brilliant, whatever they use allows uploading attachments.

On 04/11/2011 03:51 PM, Eric Firing wrote:
> On 04/11/2011 07:24 AM, Darren Dale wrote:
> 
>> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<md...@st...> wrote:
>> 
>>> I couldn't find the old thread about Sourceforge bug tracker vs. the
>>> Github issue tracker, but maybe we should reevaluate based on the new
>>> Github issue tracker announced on Saturday:
>>>
>>> https://github.com/blog/831-issues-2-0-the-next-generation
>>>
>>> The integration with git commits (closing issues by mentioning them in
>>> the commit message) is particularly compelling.
>>> 
>> The new issue tracker is a really big improvement over the old github
>> tracker, and I prefer it to the one at sourceforge since it integrates
>> so nicely with github version control. The github tracker is still
>> missing some features that we may want to consider: prioritize issues,
>> add attachments, and perhaps report issues without opening a github
>> account.
>> 
> It is better, but to my eye, still not good.
>
> Prioritization can be handled via labels or milestones, but the lack of
> a simple, obvious attachment facility is a huge omission. As far as I
> know there is also no simple set of categories for closed status--maybe
> that would also be done with labels.
Labels could be used for that purpose -- but it would be "by 
convention", so I can imagine we'd forget to do that from time to time.
> (I'm not positive; I have not
> closed an item, and nothing happens when I click the "60 closed issues"
> tab, expecting to see the closed issues. Similarly, nothing happens
> when I click the "submitted" "updated", and "comments" buttons.
I see this too. And I think we're not the only ones -- there's a bug 
filed about it:
http://support.github.com/discussions/issues-issues/608-closed-tickets-do-not-show-up-in-the-list-firefox-3615
(Hmm... git doesn't use its own issue tracker for tracking its own 
issues... what does that say? <wink>)
> Maybe
> all these things are bugs that show up if one does not have Firefox 4 or
> Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all
> comments is a horrible design,
The Wikis on github support a handful of formatting languages, including 
reStructuredText (which is what my fingers know best) -- so they "have 
the technology" to do something else. But honestly, for short issue 
comments, I think plain text is the best choice.
> and all the more so in the absence of
> file up/download facility.
> 
They've got gist, of course, but it is neither easy or intuitive for 
casual use.
Mike
> It's being used; I think we are stuck with it. I have no objection to
> getting the migration over with, if you have the machinery to do it, Dale.
>
> Eric
>
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 04/11/2011 07:24 AM, Darren Dale wrote:
> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom<md...@st...> wrote:
>> I couldn't find the old thread about Sourceforge bug tracker vs. the
>> Github issue tracker, but maybe we should reevaluate based on the new
>> Github issue tracker announced on Saturday:
>>
>> https://github.com/blog/831-issues-2-0-the-next-generation
>>
>> The integration with git commits (closing issues by mentioning them in
>> the commit message) is particularly compelling.
>
> The new issue tracker is a really big improvement over the old github
> tracker, and I prefer it to the one at sourceforge since it integrates
> so nicely with github version control. The github tracker is still
> missing some features that we may want to consider: prioritize issues,
> add attachments, and perhaps report issues without opening a github
> account.
It is better, but to my eye, still not good.
Prioritization can be handled via labels or milestones, but the lack of 
a simple, obvious attachment facility is a huge omission. As far as I 
know there is also no simple set of categories for closed status--maybe 
that would also be done with labels. (I'm not positive; I have not 
closed an item, and nothing happens when I click the "60 closed issues" 
tab, expecting to see the closed issues. Similarly, nothing happens 
when I click the "submitted" "updated", and "comments" buttons. Maybe 
all these things are bugs that show up if one does not have Firefox 4 or 
Chrome?) The automatic, compulsory, irrevocable Markdown parsing of all 
comments is a horrible design, and all the more so in the absence of 
file up/download facility.
It's being used; I think we are stuck with it. I have no objection to 
getting the migration over with, if you have the machinery to do it, Dale.
Eric

On Mon, Apr 11, 2011 at 3:02 PM, Paul Ivanov <piv...@gm...> wrote:
> Darren Dale, on 2011年04月11日 13:24, wrote:
>> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <md...@st...> wrote:
>> > I couldn't find the old thread about Sourceforge bug tracker vs. the
>> > Github issue tracker, but maybe we should reevaluate based on the new
>> > Github issue tracker announced on Saturday:
>> >
>> > https://github.com/blog/831-issues-2-0-the-next-generation
>> >
>> > The integration with git commits (closing issues by mentioning them in
>> > the commit message) is particularly compelling.
>>
>> The new issue tracker is a really big improvement over the old github
>> tracker, and I prefer it to the one at sourceforge since it integrates
>> so nicely with github version control. The github tracker is still
>> missing some features that we may want to consider: prioritize issues,
>> add attachments, and perhaps report issues without opening a github
>> account.
>
> I'm fine either way - though moving to GitHub certainly makes
> sense as it has momentum - whereas SF.net has been stagnating and
> not getting any faster for quite some time now.
>
> My only concern / request is that we transfer and/or clean up
> (wholesale) the sf.net bug tracker before we move to GH. It'd be
> a disservice to our users if we just ignored or mass-closed those
> issues in the transition to GH.
I spent a weekend working on porting the issues to github.
https://github.com/ddale/mpl-issues contains an xml dump of the
sourceforge tracker, along with the script I used to parse the dump
file, filter it, and upload the issues to that repo. It could be
improved to add labels, assign to developers, assign milestones, once
github provides API access to issues-2.0.

Darren Dale, on 2011年04月11日 13:24, wrote:
> On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <md...@st...> wrote:
> > I couldn't find the old thread about Sourceforge bug tracker vs. the
> > Github issue tracker, but maybe we should reevaluate based on the new
> > Github issue tracker announced on Saturday:
> >
> > https://github.com/blog/831-issues-2-0-the-next-generation
> >
> > The integration with git commits (closing issues by mentioning them in
> > the commit message) is particularly compelling.
> 
> The new issue tracker is a really big improvement over the old github
> tracker, and I prefer it to the one at sourceforge since it integrates
> so nicely with github version control. The github tracker is still
> missing some features that we may want to consider: prioritize issues,
> add attachments, and perhaps report issues without opening a github
> account.
I'm fine either way - though moving to GitHub certainly makes
sense as it has momentum - whereas SF.net has been stagnating and
not getting any faster for quite some time now.
My only concern / request is that we transfer and/or clean up
(wholesale) the sf.net bug tracker before we move to GH. It'd be
a disservice to our users if we just ignored or mass-closed those
issues in the transition to GH.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

On Mon, Apr 11, 2011 at 12:13 PM, Michael Droettboom <md...@st...> wrote:
> I couldn't find the old thread about Sourceforge bug tracker vs. the
> Github issue tracker, but maybe we should reevaluate based on the new
> Github issue tracker announced on Saturday:
>
> https://github.com/blog/831-issues-2-0-the-next-generation
>
> The integration with git commits (closing issues by mentioning them in
> the commit message) is particularly compelling.
The new issue tracker is a really big improvement over the old github
tracker, and I prefer it to the one at sourceforge since it integrates
so nicely with github version control. The github tracker is still
missing some features that we may want to consider: prioritize issues,
add attachments, and perhaps report issues without opening a github
account.

I couldn't find the old thread about Sourceforge bug tracker vs. the 
Github issue tracker, but maybe we should reevaluate based on the new 
Github issue tracker announced on Saturday:
https://github.com/blog/831-issues-2-0-the-next-generation
The integration with git commits (closing issues by mentioning them in 
the commit message) is particularly compelling.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Ok, forwarding it to the matplotlib-devel list.
Best wishes,
Konrad (on behalf of our workgroup)
-------- Original Message --------
Subject: Source of inaccuracies in the matplotlib library
Date: Fri, 8 Apr 2011 18:12:47 +0200
From: Bartkowski, Konrad <k.b...@fz...><mailto:k.b...@fz...>
To: dd...@co...<mailto:dd...@co...> <dd...@co...><mailto:dd...@co...>, md...@st...<mailto:md...@st...> <md...@st...><mailto:md...@st...>, ef...@ha...<mailto:ef...@ha...> <ef...@ha...><mailto:ef...@ha...>, jdh...@ac...<mailto:jdh...@ac...> <jdh...@ac...><mailto:jdh...@ac...>, jd...@gm...<mailto:jd...@gm...> <jd...@gm...><mailto:jd...@gm...>
CC: Bartkowski, Konrad <k.b...@fz...><mailto:k.b...@fz...>, el...@in...<mailto:el...@in...> <el...@in...><mailto:el...@in...>, Matthias Bolten <bo...@ma...><mailto:bo...@ma...>, Grotendorst, Johannes <j.g...@fz...><mailto:j.g...@fz...>, Steffen, Bernhard <b.s...@fz...><mailto:b.s...@fz...>
Dear Matplotlib developers,
I am writing about the matplotlib library with the mpl_toolkits. First
of all let me emphasize how great software it is. Recently, in one of
our projects we were rendering big surfaces and encountered the
following problem:
http://www.mail-archive.com/mat...@li.../msg06869.html
It's not a bug (which all in all is a natural and unavoidable ingredient
of the software, and especially in such a big and complex system like
matplotlib would be fully natural), since the software does exactly the
projection mathematics that it is expected to do, but a source of the
inaccuracies, which is especially visible in the critical examples. For
the profit of the Python community we are sending You a proposition of a
modification of the surface plotting rendering system, in case You find
it interesting enough to include in the consecutive version of the
library. In the source code from the attachment we redesigned a little
bit the computation process – since the computations are especially
sensible to numerical errors, that are for example amplified while
norming or processing the quaterions in the various stages (for example
division over coordinate in the perspective projection). Therefore the
computational focus can be shifted from the Polygon collection to the
polygons itself. In the example from the above forum or the slightly
modified one, one can observe a big difference in the numerical
precision while the speed of the computations does not decrease (at
least visibly). While instead of the surfaces from the forum, the
following surfaces are rendered:
u = np.linspace(0, 2 * np.pi, 100)
v = np.linspace(0, np.pi, 100)
x = 10 * np.outer(np.cos(u), np.sin(v))
y = 10 * np.outer(np.sin(u), np.sin(v))
z = 10 * np.outer(np.ones(np.size(u)), np.cos(v))
ax.plot_surface(x, y, z, rstride=8, cstride=8, color='y', alpha=0.5)
shiftX=28
shiftY=28
X,Y=np.meshgrid(range(-20+shiftX,20+shiftX),range(-20+shiftY,20+shiftY))
Z=np.ones((X.shape[0], Y.shape[1]))
ax.plot_surface(X, Y, Z, color='r', rstride=10, cstride=10, alpha=1.0)
the issue is visible for example at the azimuth=40 , elevation=70 – with
those parameters the mentioned case is visible on the red surface, while
with elevation=68 not. Moreover, now also the stride is big (in the new
approach the influence of increasing stride on the numerical precision
grows).
So again let me use this opportunity to thank You for empowering the
Python community worldwide in a great, powerful scientific visualization
tool.
Best wishes,
Konrad Bartkowski
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Besuchen Sie uns auf unserem neuen Webauftritt unter www.fz-juelich.de

Hi,
I've submitted a pull request with backend changes that (should) let all 
currently supported versions of PyQt work along side PySide. I've 
tested with PyQt 4.8.3 and PySide 1.0.0.
I haven't bothered chasing down old versions of PyQt as they seem elusive.
Gerald.
On 29/03/2011 3:25 AM, bu...@gm... wrote:
> Looking forward, supporting the Python 3 compatible PyQt API is likely 
> the way to go.
>
> Le , Gerald Storer <gd...@mr...> a écrit :
> > On 28/03/2011 1:10 AM, Peter Butterworth wrote:
> >
> >
> > Wouldn't it be possible to use a single backend compatible with both
> >
> > PyQt and Pyside ?
> >
> >
> > The current Qt mpl backend uses the old PyQt slots/signals API which 
> PySide doesn't really support (there are some macros but they don't 
> work 100% the same). From a quick glance at the IPython 
> implementation it looks like they are using the new API which means 
> older versions (<4.5) of PyQt won't be supported. This might be ok, I 
> don't know.
> >
> > If it isn't then, there will need to be some try...excepts around 
> the place or separate back ends. If you ignore the PySide bugs I had 
> to work around I've only changed ~4 lines in the main backend.
> >
> >
> >
> > Pierre's formlayout is also using an obsolete method that isn't 
> present in PySide. I've opted to emulate it, but it would be best to 
> change the code to use the alternative method available in both PyQt 
> and PySide. formlayout also uses the old QString implementation of 
> PyQt, PySide only supports the new implementation where QString is 
> transparently convert to/from str/unicode. Setting QString = unicode 
> seems to work though.
> >
> >
> >
> > Gerald.
> >