[matplotlib-devel] Memory leak using savefig with MacOSX backend?
I'm looping over several files (about 1000) to produce a vector field
plot for each data file I have. Doing this with the MacOSX backend
appears to chew memory. My guess as to the source of the problem is
the 'savefig' function (or possibly the way the MacOSX backend handles
the saving of plots).
I opened Activity Monitor to watch the usage of memory increase. Below
is code that recreates the problem.
[start]
import matplotlib
matplotlib.use('macosx')
matplotlib.rc('font',**{'family':'serif','serif':['Computer Modern
Roman']})
matplotlib.rc('text', usetex=True)
from pylab import *
i = 0
x = []
y = []
v1 = []
v2 = []
while(True):
f = open("%dresults.dat"%i,"r")
for line in f:
x.append(float(line.split()[0]))
y.append(float(line.split()[1]))
v1.append(float(line.split()[2]))
v2.append(float(line.split()[3]))
f.close()
hold(False)
figure(1)
quiver(x, y, v1, v2, color='b', units='width', scale=1.0)
xlabel('$x$')
ylabel('$y$')
grid(True)
print i
savefig('graph-%05d.pdf'%i)
close(1)
x = []
y = []
v1 = []
v2 = []
i = i + 1
[end]
Regards,
--Damon
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Exploring
Hi,
I'm interested in fiddling around with the matplotlib source. Let's say we set
up various things:
from matplotlib.figure import Figure()
from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(1, 1, 1)
fig.savefig('asd.pdf', bbox_inches='tight')
I would like to know what exactly happens when bbox_inches='tight' is passed to
savefig(). I've been searching in the figure.py source and nowhere can I see
the bbox_inches='tight' keyword being tested for in the savefig() method.
Having said that, all of the kwargs do get passed on to the
canvas.print_figure() method, so I looked in the backend_pdf.py file but
couldn't find a print_figure() method. Could someone point me in the right
direction?
Regards,
-- Damon
--
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.mcdoug...@warwick.ac.uk
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Exploring
Hmm, it seems as though tick labels get clipped on the top and on the right
when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this
behaviour. Is there perhaps a bug in Bbox.union that's causing this?
Regards,
-- Damon
------
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.mcdoug...@warwick.ac.uk
On 30 Jul 2010, at 16:03, Tony S Yu wrote:
>
> On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
>
>> Hi,
>>
>> I'm interested in fiddling around with the matplotlib source. Let's say we
>> set up various things:
>>
>> from matplotlib.figure import Figure()
>> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>>
>> fig = Figure()
>> canvas = FigureCanvas(fig)
>> ax = fig.add_subplot(1, 1, 1)
>> fig.savefig('asd.pdf', bbox_inches='tight')
>>
>> I would like to know what exactly happens when bbox_inches='tight' is passed
>> to savefig(). I've been searching in the figure.py source and nowhere can I
>> see the bbox_inches='tight' keyword being tested for in the savefig()
>> method. Having said that, all of the kwargs do get passed on to the
>> canvas.print_figure() method, so I looked in the backend_pdf.py file but
>> couldn't find a print_figure() method. Could someone point me in the right
>> direction?
>>
>> Regards,
>> -- Damon
>
> That's funny: I was just looking at bbox_inches='tight' recently. You'll find
> the relevant section in matplotlib.backend_bases.print_figure.
>
> Best,
> -Tony
>
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Exploring
Aha! Even without the text, i.e. setting label1On = False for all the major
ticks, the behaviour I see is that with bbox_inches = 'tight' and pad_inches =
0.0 I get the saved figure which includes the black border line for the bottom
and left edges, but not the top and right edges. This may have something to do
with it. Maybe it's an issue with the bounding box not being 'inclusive' and
leaving out the end points?
Regards,
-- Damon
------
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.mcdoug...@warwick.ac.uk
On 30 Jul 2010, at 20:33, Eric Firing wrote:
> On 07/30/2010 06:32 AM, Damon McDougall wrote:
>> Hmm, it seems as though tick labels get clipped on the top and on the right
>> when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this
>> behaviour. Is there perhaps a bug in Bbox.union that's causing this?
>>
>
> Not likely. Much more likely is a problem in calculating the rendered
> size of the text.
>
> Eric
>
>> Regards,
>> -- Damon
>>
>> --
>> Damon McDougall
>> Mathematics Institute
>> University of Warwick
>> Coventry
>> CV4 7AL
>> d.mcdoug...@warwick.ac.uk
>>
>>
>>
>> On 30 Jul 2010, at 16:03, Tony S Yu wrote:
>>
>>>
>>> On Jul 30, 2010, at 10:54 AM, Damon McDougall wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm interested in fiddling around with the matplotlib source. Let's say we
>>>> set up various things:
>>>>
>>>> from matplotlib.figure import Figure()
>>>> from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
>>>>
>>>> fig = Figure()
>>>> canvas = FigureCanvas(fig)
>>>> ax = fig.add_subplot(1, 1, 1)
>>>> fig.savefig('asd.pdf', bbox_inches='tight')
>>>>
>>>> I would like to know what exactly happens when bbox_inches='tight' is
>>>> passed to savefig(). I've been searching in the figure.py source and
>>>> nowhere can I see the bbox_inches='tight' keyword being tested for in the
>>>> savefig() method. Having said that, all of the kwargs do get passed on to
>>>> the canvas.print_figure() method, so I looked in the backend_pdf.py file
>>>> but couldn't find a print_figure() method. Could someone point me in the
>>>> right direction?
>>>>
>>>> Regards,
>>>> -- Damon
>>>
>>> That's funny: I was just looking at bbox_inches='tight' recently. You'll
>>> find the relevant section in matplotlib.backend_bases.print_figure.
>>>
>>> Best,
>>> -Tony
>>>
>>
>>
>> --
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> ___
>> Matplotlib-devel mailing list
>> Matplotlib-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> --
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Colormap that prints nicely in black and white
Hi all,
Don't know if anybody else has found a colormap that is aesthetically pleasing
and prints well in black and white. I found one after a lot of Googling.
Perhaps useful for plotting figures in journals that charge a lot for colour
figures. I got the colormap from:
http://ieeexplore.ieee.org/iel5/74/22101/01028735.pdf%3Farnumber%3D1028735
I decided to code it up (see attached text file for the cdict). If anybody
finds it useful, maybe it could go into the default colormaps that ship with
matplotlib.
cdict = {'red' : ((0.000, 0.00, 0.00),
(0.125, 0.15, 0.15),
(0.250, 0.30, 0.30),
(0.375, 0.60, 0.60),
(0.500, 1.00, 1.00),
(0.625, 0.90, 0.90),
(0.750, 0.90, 0.90),
(0.875, 0.90, 0.90),
(1.000, 1.00, 1.00)),
'green' : ((0.000, 0.00, 0.00),
(0.125, 0.15, 0.15),
(0.250, 0.15, 0.15),
(0.375, 0.20, 0.20),
(0.500, 0.25, 0.25),
(0.625, 0.50, 0.50),
(0.750, 0.75, 0.75),
(0.875, 0.90, 0.90),
(1.000, 1.00, 1.00)),
'blue' : ((0.000, 0.00, 0.00),
(0.125, 0.50, 0.50),
(0.250, 0.75, 0.75),
(0.375, 0.50, 0.50),
(0.500, 0.15, 0.15),
(0.625, 0.00, 0.00),
(0.750, 0.10, 0.10),
(0.875, 0.50, 0.50),
(1.000, 1.00, 1.00))
}
Regards,
-- Damon
------
Damon McDougall
Mathematics Institute
University of Warwick
Coventry
CV4 7AL
d.mcdoug...@warwick.ac.uk
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Bug in Triangulation causes infinite loop if 4 or more duplicate points are used in tricontour()
On Monday, 16 April 2012 at 16:34, Kacper Kowalik wrote: > > On 16 Apr 2012 22:31, "Damon McDougall" (mailto:d.mcdoug...@warwick.ac.uk)> wrote: > > > > Hi Kacper, > > > > Just to be clear, is it tri.Triangulation(x, y) that hangs, or is it > > plt.tricontour(…)? > It's plt.tricontour that hangs, tri.Triangulation properly issues warning > about duplicates. > Cheers, > Kacper > > On Monday, 16 April 2012 at 14:28, Kacper Kowalik wrote: > >> > >> Hi, > >> I haven't been able to pin point it exactly but following script: > >> > >> import matplotlib.pyplot as plt > >> import matplotlib.tri as tri > >> import numpy as np > >> from numpy.random import uniform, seed > >> > >> seed(0) > >> npts = 200 > >> x = uniform(-2,2,npts) > >> y = uniform(-2,2,npts) > >> z = x*np.exp(-x**2-y**2) > >> > >> y[1:3] = x[0] # 4 or more duplicate points make tricontour hang!!! > >> x[1:3] = y[0] You should call z = x*np.exp(-x**2-y**2) _before_ changing the points you're triangulating. Having said that, I see the same behaviour even if I change the vertices before I compute z. > >> triang = tri.Triangulation(x, y) > >> plt.tricontour(x, y, z, 15, linewidths=0.5, colors='k') > >> > >> plt.show() > >> > >> > >> causes infinite loop in _tri.so. It happens in matplotlib-1.1.0 as well > >> as git HEAD. > >> I understand that my input is not exactly valid, but I'd rather see MPL > >> die than occupy my box for eternity ;) > >> Best regards, > >> Kacper I think the reason it's hanging is because you're trying to plot the contours of a function that is defined on an invalid triangulation (edges cross at points that are not in the vertex set). I think the best way to deal with this is to write a helper function to check the triangulation is valid. If it isn't, either tri.Triangulation(x, y) should fail, or the plotter should fail. Anybody else have any suggestions? -- Damon McDougall d.mcdoug...@warwick.ac.uk (mailto:d.mcdoug...@warwick.ac.uk) http://damon.is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On Thu, Jul 05, 2012 at 07:43:39PM +, Russell E. Owen wrote: > In article , > Russell Owen wrote: > > > I just uploaded the Mac binaries. > > > > Several minor concerns: > > - Many unit tests failed on Mac OS X 10.4 (which is where I build the > > 10.3.9 > > version) due to "too many files open", but the same binary looks fine on > > 10.5. > > - The 64-bit version (10.6 and later) had one unexpected failure on 10.7 (I > > have not yet had time to test it on 10.6)... > > When I tested on Mac OS X 10.6 I found that most unit tests were somehow > missing. Rather than try to diagnose the problem, I built a new binary > on 10.6, confirmed that it installed properly (with all unit tests) on > 10.6 and 10.7, then uploaded it to replace the earlier 10.6 binary. > > The same test I mentioned in my previous post still fails using the new > binary, on both 10.6 and 10.7. > > -- Russell > I did a git checkout of the v1.1.1 tag and compiled a 64-bit version. I have attached output from the following command: python -c "import matplotlib as m ; m.test(verbosity=1)" Note that some of the tests fail with satuses: KEFKK. I have the following requirements installed: nose: version 1.1.2 PIL: version 1.1.7 ghsotscript: version 9.05 inkscape: 0.48.3.1 All of these were installed using the latest version of macports. Is there anything I can do to improve the output of the tests? -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom $ python -c "import matplotlib as m ; m.test(verbosity=1)" ..K..EF..K.K == ERROR: matplotlib.tests.test_axes.test_formatter_ticker.test -- Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Users/damon/python/lib/matplotlib/testing/decorators.py", line 36, in failer result = f(*args, **kwargs) File "/Users/damon/python/lib/matplotlib/testing/decorators.py", line 130, in do_test err = compare_images(expected_fname, actual_fname, self._tol, in_decorator=True) File "/Users/damon/python/lib/matplotlib/testing/compare.py", line 215, in compare_images actual = convert(actual) File "/Users/damon/python/lib/matplotlib/testing/compare.py", line 139, in convert converter[extension](filename, newname) File "/Users/damon/python/lib/matplotlib/testing/compare.py", line 99, in convert raise IOError, msg IOError: Conversion command failed: inkscape -z /Users/damon/result_images/test_axes/formatter_ticker_002.svg --export-png /Users/damon/result_images/test_axes/formatter_ticker_002_svg.png Standard output: Background RRGGBBAA: ff00 Area 0:0:720:540 exported to 720 x 540 pixels (90 dpi) Bitmap saved as: /Users/damon/result_images/test_axes/formatter_ticker_002_svg.png Standard error: Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. ** Message: Error: Inkscape encountered an internal error and will close now. == FAIL: matplotlib.tests.test_axes.test_single_point.test -- Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTes
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Tue, Jul 10, 2012 at 05:36:50PM -0400, Tony Yu wrote: > On Tue, Jul 10, 2012 at 1:52 PM, John Hunter wrote: > > > > > On Tue, Jul 10, 2012 at 12:49 PM, Damon McDougall < > > damon.mcdoug...@gmail.com> wrote: > > > >> > >> Would there be any interest in porting some of that functionality into > >> the main mpl codebase? Like Ben said, that error function is nifty... :) > >> > >> > > > > I also think the styles would be widely appreciated, and we might get more > > styles contributors if it was part of the mainline. We'd ideally like to > > be able to support remote styles, eg via gist. > > > > Nice stuff, Tony. > > > > > Damon and John: Thanks for your interest. I would be happy to help port > anything that can find a home in Matplotlib. I'm low on bandwidth, so if > I'm too slow with any of it, feel free to grab the code and submit your own > PR for the port (just let me know so we don't duplicate our efforts). Well, as Ben said, that error fill plot is neato! It doesn't look too complicated, either. I'd be more than happy to port it over later today when I get bored of typing up my thesis. It'll probably only take me about 30 minutes. If nobody is opposed to this idea, I'll go ahead and submit a PR this evening (British Summer (hah!) Time). -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Wed, Jul 11, 2012 at 10:23:32AM -0500, John Hunter wrote: > On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall > wrote: > > > > Well, as Ben said, that error fill plot is neato! It doesn't look too > > complicated, either. I'd be more than happy to port it over later today > > when I get bored of typing up my thesis. It'll probably only take me > > about 30 minutes. > > > > If nobody is opposed to this idea, I'll go ahead and submit a PR this > > evening (British Summer (hah!) Time). > > > > > While it is a nice graph, I am not sure that the use case is common enough > to justify a new plotting method. One can get the same result with: > > > In [68]: x = np.linspace(0, 2 * np.pi) > > In [69]: y_sin = np.sin(x) > > In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) > > In [71]: plot(x, y_sin) > Out[71]: [] > > In [72]: fill_between(np.concatenate([x, x[::-1]]), err, facecolor='red', > alpha=0.5) > Out[72]: > > Admittedly the [::-1] thing is a bit counter-intuitive, but rather than > adding a new plotting method, perhaps we would be better off with a helper > method to create the xs and ys for fill_between > > xs, ys = mlab.pad_line(x, y, 0.2) > fill_between(xs, ys) > > JDH +1 on the helper function. That's probably a much less bloated of way of doing it. -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote: > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root wrote: > > > > > > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter wrote: > > > >> > >> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdoug...@gmail.com> wrote: > >>> > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too > >>> complicated, either. I'd be more than happy to port it over later today > >>> when I get bored of typing up my thesis. It'll probably only take me > >>> about 30 minutes. > >>> > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this > >>> evening (British Summer (hah!) Time). > >>> > >> > >> > >> While it is a nice graph, I am not sure that the use case is common > >> enough to justify a new plotting method. One can get the same result with: > >> > >> > >> In [68]: x = np.linspace(0, 2 * np.pi) > >> > >> In [69]: y_sin = np.sin(x) > >> > >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) > >> > >> In [71]: plot(x, y_sin) > >> Out[71]: [] > >> > >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err, > >> facecolor='red', alpha=0.5) > >> Out[72]: > >> > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than > >> adding a new plotting method, perhaps we would be better off with a helper > >> method to create the xs and ys for fill_between > >> > >> xs, ys = mlab.pad_line(x, y, 0.2) > >> fill_between(xs, ys) > >> > >> JDH > >> > > > > > > I could definitely agree with a pad_line() function. We might want to > > revisit the issue of how much visibility the mlab module should get in the > > documentation (it currently doesn't get much at all). My whole take on > > mlab was that it was a left-over from the days of working around issues in > > NumPy and SciPy and that it was being slowly phased out. As for other > > possible locations, cbook feels like it is more for the devs than for the > > users, and adding it to pyplot would render the whole purpose of creating > > this function as opposed to errorfill moot. > > > > As an additional point about such a pad_line function, it should probably > > be nice to mirror the errorbar() functionality to allow not only a constant > > error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar() > > for the 2xN array case does -row1 and +row2). > > > > Damon: it sounds like you're volunteering to submit a PR to add this > function ;) > > Here's the relevant bit (which should already handle the cases Ben mentions > above): > > > https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54 > > It needs a docstring and a home (pyplot.py?). I kind of think `offset_line` > is more explicit than `pad_line` (both of these are *much* better than my > original `extrema_from_error_input`). > > Cheers, > -Tony > > > > Cheers! > > Ben Root > > > > Woohoo! Something other than my thesis to do! I have one question. It looks like your function `extrema_from_error_input` just adds +/- an error scalar (or array), but in the gallery it looks like the padding is thinner in the areas of the `sin` function where the magnitude of the gradient is larger. Is this the case, or am I missing something? -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Thu, Jul 12, 2012 at 09:41:32AM -0400, Tony Yu wrote: > On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall > wrote: > > > On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote: > > > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root wrote: > > > > > > > > > > > > > > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter > > wrote: > > > > > > > >> > > > >> > > > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdoug...@gmail.com> wrote: > > > >>> > > > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too > > > >>> complicated, either. I'd be more than happy to port it over later > > today > > > >>> when I get bored of typing up my thesis. It'll probably only take me > > > >>> about 30 minutes. > > > >>> > > > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this > > > >>> evening (British Summer (hah!) Time). > > > >>> > > > >> > > > >> > > > >> While it is a nice graph, I am not sure that the use case is common > > > >> enough to justify a new plotting method. One can get the same result > > with: > > > >> > > > >> > > > >> In [68]: x = np.linspace(0, 2 * np.pi) > > > >> > > > >> In [69]: y_sin = np.sin(x) > > > >> > > > >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) > > > >> > > > >> In [71]: plot(x, y_sin) > > > >> Out[71]: [] > > > >> > > > >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err, > > > >> facecolor='red', alpha=0.5) > > > >> Out[72]: > > > >> > > > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather > > than > > > >> adding a new plotting method, perhaps we would be better off with a > > helper > > > >> method to create the xs and ys for fill_between > > > >> > > > >> xs, ys = mlab.pad_line(x, y, 0.2) > > > >> fill_between(xs, ys) > > > >> > > > >> JDH > > > >> > > > > > > > > > > > > I could definitely agree with a pad_line() function. We might want to > > > > revisit the issue of how much visibility the mlab module should get in > > the > > > > documentation (it currently doesn't get much at all). My whole take on > > > > mlab was that it was a left-over from the days of working around > > issues in > > > > NumPy and SciPy and that it was being slowly phased out. As for other > > > > possible locations, cbook feels like it is more for the devs than for > > the > > > > users, and adding it to pyplot would render the whole purpose of > > creating > > > > this function as opposed to errorfill moot. > > > > > > > > As an additional point about such a pad_line function, it should > > probably > > > > be nice to mirror the errorbar() functionality to allow not only a > > constant > > > > error, but also a N, Nx1, or 2xN array of +/- error. (note that > > errorbar() > > > > for the 2xN array case does -row1 and +row2). > > > > > > > > > > Damon: it sounds like you're volunteering to submit a PR to add this > > > function ;) > > > > > > Here's the relevant bit (which should already handle the cases Ben > > mentions > > > above): > > > > > > > > > > > https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54 > > > > > > It needs a docstring and a home (pyplot.py?). I kind of think > > `offset_line` > > > is more explicit than `pad_line` (both of these are *much* better than my > > > original `extrema_from_error_input`). > > > > > > Cheers, > > > -Tony > > > > > > > > > > Cheers! > > > > Ben Root > > > > > > > > > > > > Woohoo! Something other than my thesis to do! I have one question. It > > looks like your function `extrema_from_error_input` just adds +/- an > > error scalar (or array), but in the gallery it looks like the padding > > is thinner in the areas of the `sin` function where the magnitude of the > > gradient is larger. Is this the case, or am I missing something? > > > > -- > > Damon McDougall > > > > > Yep, that's the way it should look because it's adding the error just in > the y-direction. To get a constant thickness, you'd have to add a constant > orthogonal to the line's slope. > > Good luck procrastinating on your thesis ;) > -Tony Aha, the answer was 'yes, I was missing something'! :) Thanks. -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote: > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root wrote: > > > > > > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter wrote: > > > >> > >> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdoug...@gmail.com> wrote: > >>> > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too > >>> complicated, either. I'd be more than happy to port it over later today > >>> when I get bored of typing up my thesis. It'll probably only take me > >>> about 30 minutes. > >>> > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this > >>> evening (British Summer (hah!) Time). > >>> > >> > >> > >> While it is a nice graph, I am not sure that the use case is common > >> enough to justify a new plotting method. One can get the same result with: > >> > >> > >> In [68]: x = np.linspace(0, 2 * np.pi) > >> > >> In [69]: y_sin = np.sin(x) > >> > >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) > >> > >> In [71]: plot(x, y_sin) > >> Out[71]: [] > >> > >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err, > >> facecolor='red', alpha=0.5) > >> Out[72]: > >> > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than > >> adding a new plotting method, perhaps we would be better off with a helper > >> method to create the xs and ys for fill_between > >> > >> xs, ys = mlab.pad_line(x, y, 0.2) > >> fill_between(xs, ys) > >> > >> JDH > >> > > > > > > I could definitely agree with a pad_line() function. We might want to > > revisit the issue of how much visibility the mlab module should get in the > > documentation (it currently doesn't get much at all). My whole take on > > mlab was that it was a left-over from the days of working around issues in > > NumPy and SciPy and that it was being slowly phased out. As for other > > possible locations, cbook feels like it is more for the devs than for the > > users, and adding it to pyplot would render the whole purpose of creating > > this function as opposed to errorfill moot. > > > > As an additional point about such a pad_line function, it should probably > > be nice to mirror the errorbar() functionality to allow not only a constant > > error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar() > > for the 2xN array case does -row1 and +row2). > > > > Damon: it sounds like you're volunteering to submit a PR to add this > function ;) > > Here's the relevant bit (which should already handle the cases Ben mentions > above): > > > https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54 > > It needs a docstring and a home (pyplot.py?). I kind of think `offset_line` > is more explicit than `pad_line` (both of these are *much* better than my > original `extrema_from_error_input`). > There was talk of this living in mlab or cbook. Is there a preference? > Cheers, > -Tony > > > > Cheers! > > Ben Root > > > > -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote: > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root wrote: > > > > > > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter wrote: > > > >> > >> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdoug...@gmail.com> wrote: > >>> > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too > >>> complicated, either. I'd be more than happy to port it over later today > >>> when I get bored of typing up my thesis. It'll probably only take me > >>> about 30 minutes. > >>> > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this > >>> evening (British Summer (hah!) Time). > >>> > >> > >> > >> While it is a nice graph, I am not sure that the use case is common > >> enough to justify a new plotting method. One can get the same result with: > >> > >> > >> In [68]: x = np.linspace(0, 2 * np.pi) > >> > >> In [69]: y_sin = np.sin(x) > >> > >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) > >> > >> In [71]: plot(x, y_sin) > >> Out[71]: [] > >> > >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err, > >> facecolor='red', alpha=0.5) > >> Out[72]: > >> > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than > >> adding a new plotting method, perhaps we would be better off with a helper > >> method to create the xs and ys for fill_between > >> > >> xs, ys = mlab.pad_line(x, y, 0.2) > >> fill_between(xs, ys) > >> > >> JDH > >> > > > > > > I could definitely agree with a pad_line() function. We might want to > > revisit the issue of how much visibility the mlab module should get in the > > documentation (it currently doesn't get much at all). My whole take on > > mlab was that it was a left-over from the days of working around issues in > > NumPy and SciPy and that it was being slowly phased out. As for other > > possible locations, cbook feels like it is more for the devs than for the > > users, and adding it to pyplot would render the whole purpose of creating > > this function as opposed to errorfill moot. > > > > As an additional point about such a pad_line function, it should probably > > be nice to mirror the errorbar() functionality to allow not only a constant > > error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar() > > for the 2xN array case does -row1 and +row2). > > > > Damon: it sounds like you're volunteering to submit a PR to add this > function ;) > > Here's the relevant bit (which should already handle the cases Ben mentions > above): > > > https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54 > Great. I've basically done this. I have one suggestion, though. In the case where len(zerr) == 2, you are setting zmin, zmax = zerr I think it makes more sense to set zmin, zmax = z - zerr[0], z + zerr[1] What do you think? > It needs a docstring and a home (pyplot.py?). I kind of think `offset_line` > is more explicit than `pad_line` (both of these are *much* better than my > original `extrema_from_error_input`). > > Cheers, > -Tony > > > > Cheers! > > Ben Root > > > > Best, Damon -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release
On Tue, Jul 17, 2012 at 08:21:50AM -0500, Benjamin Root wrote: > On Tue, Jul 17, 2012 at 6:25 AM, todd rme wrote: > > > On Wed, Jul 11, 2012 at 5:23 PM, John Hunter wrote: > > > > > > > > > On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall > > > wrote: > > >> > > >> Well, as Ben said, that error fill plot is neato! It doesn't look too > > >> complicated, either. I'd be more than happy to port it over later today > > >> when I get bored of typing up my thesis. It'll probably only take me > > >> about 30 minutes. > > >> > > >> If nobody is opposed to this idea, I'll go ahead and submit a PR this > > >> evening (British Summer (hah!) Time). > > > > > > > > > > > > While it is a nice graph, I am not sure that the use case is common > > enough > > > to justify a new plotting method. One can get the same result with: > > > > > > > > > In [68]: x = np.linspace(0, 2 * np.pi) > > > > > > In [69]: y_sin = np.sin(x) > > > > > > In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2]) > > > > > > In [71]: plot(x, y_sin) > > > Out[71]: [] > > > > > > In [72]: fill_between(np.concatenate([x, x[::-1]]), err, > > facecolor='red', > > > alpha=0.5) > > > Out[72]: > > > > > > Admittedly the [::-1] thing is a bit counter-intuitive, but rather than > > > adding a new plotting method, perhaps we would be better off with a > > helper > > > method to create the xs and ys for fill_between > > > > > > xs, ys = mlab.pad_line(x, y, 0.2) > > > fill_between(xs, ys) > > > > > > JDH > > > > What about adding a property to the existing errorbar to let someone > > change it to the filled version? This could also, potentially, be > > extended with other types of error bars if the need arises. > > > > -Todd > > > > Intriguing idea. I am actually quite comfortable with that. > I like this idea, too. > Ben Root -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] mpl BOFs
On Wed, Jul 18, 2012 at 05:11:43PM -0500, Benjamin Root wrote: > technically, there is supposed to be a BOF about now, but I just realized > What is a BOF? > that no location was specified. We could meet in the atrium unless anyone > has a better idea. > > Ben > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Adding Matlab's fplot to Axes
Hello all, So, as per Philip's suggestion (https://github.com/matplotlib/matplotlib/pull/737) I've started encapsulating fplot functionality into a class. The point of this is so that the user can call either of the following: FPlot_instance = ax.fplot(f, [x0, y0, x1, y1]) ax.fplot(FPlot_instance, ...) Each of these is valid. The first does 'the obvious', as seen in the closed PR above. The second takes an instance of an FPlot object, presumably the user would also pass new limits to, say, zoom out. Then the plot is updated as necessary. This was also Philip's suggestion and there is a nice working example of changing the limits of a plot to get a more highly resolved image in examples/event_handling/viewlims.py I haven't put in a new pull request because I can't decide which of these methods is better. In short, the viewlims.py example uses a callback to adjust the plot if the user calls set_xlim or set_ylim. Would it be sensible to use a callback for fplot buried in the FPlot class or use my initial thought, which is to pass in a new tuple describing the new axes limits and update if necessary? The code isn't complete so I'm reluctant to file a new PR, but if there is overwhelming desire for people to see the code (perhaps due to my poor explanation) then I'll open a new PR so everyone can give their two pence. Suggestions welcome :) -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Adding Matlab's fplot to Axes
On Mon, Jul 23, 2012 at 08:38:07PM -0400, Benjamin Root wrote: > On Monday, July 23, 2012, Eric Firing wrote: > > > On 2012/07/23 11:43 AM, Damon McDougall wrote: > > > Hello all, > > > > > > So, as per Philip's suggestion > > > (https://github.com/matplotlib/matplotlib/pull/737) I've started > > > encapsulating fplot functionality into a class. The point of this is so > > > that the user can call either of the following: > > > > > > FPlot_instance = ax.fplot(f, [x0, y0, x1, y1]) > > > ax.fplot(FPlot_instance, ...) > > > > The second of these seems odd to me; I would expect FPlot_instance to > > have a __call__ method, so the normal use of an existing instance would be > > That is awesome! I didn't know the __call__ method existed! That's a much better way of doing it. I love Python. > > > > FPlot_instance(...) > > > > Also, regarding the second argument in the first form: I would think it > > more natural to split it up into a required [x0, x1] and an optional > > [y0, y1], with autoscaling if it is not provided. > > > > Eric > > > Agreed, it is a bit odd/awkward, and I also agree about autoscaling. > > With the whole viewlims callbacks, make sure you have the class disconnect > itself upon removal, such as through cla(). > So are you suggesting autoscaling over a callback? > l <https://lists.sourceforge.net/lists/listinfo/matplotlib-devel> > Cheers! > Ben Root -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Some update on GL backend
On Wed, Aug 01, 2012 at 11:24:06AM +0200, Nicolas Rougier wrote: > > > Hi all, > > > I'm continuing experimenting various solution for a possible GL backend for > matplotlib and I made some progress (but no integration yet). > > You can check results (and experimenting yourself at various places, sorry > for that): > > Text : http://code.google.com/p/freetype-gl/ >http://code.google.com/p/freetype-py/ > > Images interpolation & 3D : http://code.google.com/p/glumpy/ > > Lines/Shapes : http://code.google.com/p/gl-agg/ > > The last experiments (gl-agg) were about high-quality lines and shapes. It > seems OpenGL may offer pretty decent quality (IMHO) as you can see on the > various screenshots that compare agg and opengl. demo-lines.py and a > demo-circles.py show zooming/panning speed (mouse drag / scroll). > > There are still some more work to, mainly concave polygons and bezier filled > shapes. > > However, the whole integration into matplotlib may require a lot of work > since OpenGL technics may radically differ from their matplotlib counterpart > in some case. For example, a grid is rendered using a single shader that > manages internally all the lines and ticks. Another example is image > interpolation that is done entirely on the graphic card (see glumpy). > > Also, Don't be fooled by the speed of the current demo-lines.py and > demo-circles.py because they don't offer the versatility of matplotlib. > > > > At this point, I may lack time to write the actual integration into > matplotlib and I may not know enough the internal matplotlib machinery. Maybe > this could be a future project for next year / Google summer of code ? What > do you think ? > > > Nicolas Nicholas, There's a word for people like you: 'Hero'. The output, in my opinion, looks very nice. Personally, I don't see myself using this for the two-dimensional stuff unless it's because I need to quickly look at something (just like you mention on the glumpy main page), but I think this is a winner for producing 3D plots. GL is a champion when it comes to 3D rendering, a la MayaVI, VTK or Paraview and the current mplot3d toolkit is using all of matplotlib's two dimensional capabilities. I would love to have something like this that mplot3d can hook into to produce publication-quality visualisations in three-dimensional space. I have no experience with the backend side of matplotlib, I just wanted to say thank you for your effort :) -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] The beauty of Breseham's algorithm
I saw this article on hacker news and wondered if it would be applicable to us? http://free.pages.at/easyfilter/bresenham.html Perhaps not, but I certainly learned something from it so I thought I'd share anyway. Best, Damon -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] The beauty of Breseham's algorithm
On Wed, Aug 08, 2012 at 09:26:58AM +0100, Damon McDougall wrote: > I saw this article on hacker news and wondered if it would be applicable > to us? http://free.pages.at/easyfilter/bresenham.html > > Perhaps not, but I certainly learned something from it so I thought I'd > share anyway. > > Best, > Damon ...and that should be 'Bresenham', not 'Breseham'. -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: Re: [Matplotlib-users] help me Velocity depth plot in matplotlib
- Forwarded message from Damon McDougall - > Date: Fri, 10 Aug 2012 12:47:22 +0100 > From: Damon McDougall > To: satish maurya > Cc: matplotlib-us...@lists.sourceforge.net > Subject: Re: [Matplotlib-users] help me Velocity depth plot in matplotlib > > On Fri, Aug 10, 2012 at 02:09:39PM +0530, satish maurya wrote: > > Dear All, > > > > I want to stairs plot (similar in matlab) matplotlib > > First i want for i data-set then multiple data-set super impose on that. > > I attach the figure it's showing velocity-depth stairs plots for > > superimpose (like hold on in matlab) > > large data-set. > > can anybody tell me how to plot that. > > > > I'm not sure I understand what you're asking. Are you asking how to make > a stairplot, or are you asking how to make *multiple* plots on one set > of axes? > > If your question is the former, matplotlib does not currently have a > stairplot implementation, but it wouldn't be hard to use the usual > plot() function to achieve the desired effect: > > Before: > > x = arange(0, 10, 1) > y = x * (10.0 - x) > plot(x, y) > > After: > > x = arange(0, 10, 1) > x_m = x - 0.5 # left-hand midpoints > x_p = x + 0.5 # right-hand midpoints > y = x * (10.0 - x) > x_all = dstack((x_m, x, x_p)).flatten() > y_all = dstack((y, y, y)).flatten() > plot(x_all, y_all) > > If your question is the latter, you can toggle the hold state just by > calling > > hold() > > Hope this helps. > > > > > see the figure > > > > Thank you > > > > -- > > > > > > *Satish Maurya* > > *Research Scholar* > > > > > > -- > Damon McDougall > http://damon-is-a-geek.com > B2.39 > Mathematics Institute > University of Warwick > Coventry > West Midlands > CV4 7AL > United Kingdom - End forwarded message - I have put in a PR regarding this, since this feature exists in Matlab. This brings the plotting interface of matplotlib more in line with that of Matlab. You can view the request at: https://github.com/matplotlib/matplotlib/pull/1068 Feedback welcome. Best, Damon -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Q-Q Plot
Hi all, If anyone hasn't noticed already. I've been somewhat semi-perusing the Matlab interface and trying to port over any plotting functionality not current present in mpl. The other day I made a bit of a mess up regarding functionality I didn't think existed but actually did (discussion here: https://github.com/matplotlib/matplotlib/pull/1068) I'm sending a message here because I've found another one I don't think currently exists in mpl: http://www.mathworks.co.uk/help/toolbox/stats/qqplot.html I wanted to check with everyone here (who probably know better!) before I started anything. Thanks! Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Two 1.2 milestones
On Sun, Aug 19, 2012 at 12:58:53PM -0400, Michael Droettboom wrote: > There seems to be a new milestone "1.2.x known bugs". Is there a good > reason to have two milestones for 1.2? As we enter into the freeze > phase for 1.2, it would be easier to just track a single milestone. According to mpl release calendar, the feature freeze is for 2.0, not 1.2. Is this correct, or am I missing something? -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Stacked plotting in matplotlib
Hey Nic, Thanks for bringing this up. I was the author for #819, so I'd like to get some dicussion going on this, too. Sorry for the delay, I was in the midst of writing a thesis, which I am now free of. On Sun, Aug 12, 2012 at 11:51:24PM -0500, Nic Eggert wrote: > Hi all, > > I'd like to bring up a question spurred by PRs #847(mine) and #819 > (recently accepted). These PRs both deal with stacked plots. #819 adds the > stackplot function to axes.py as a new function, which plots different 2-d > datasets stacked atop each other. #847 slightly modifies the functioning of > `hist` in axes.py by adding a new kwarg which allows datasets to be > stacked. Currently this is only possible using the `barstacked` histtype. > #847 makes it also work with the `step` and `stepfilled` histtypes. > > One of the issues that has been raised in the comments of #847 is whether > we want to take this opportunity to come up with a unified way to handle > "stacked-ness". Michael Droettboom suggested I raise this issue on this > list. So far, there are 3 different approaches: > > 1. The state before #819. AFAIK the only way to do any sort of stacking was > to call `hist` with `histtype="barstacked"`. This treats stacked histograms > as a different type of histogram than non-stacked histograms. One of my > motivations for writing #847 was to get stacked step and stepfilled > histograms, which would require adding several new histtypes (stepstacked > and stepfilledstacked). It seems to me that histtype mostly controls the > style of the histogram plotted, and shouldn't have anything to do with > "stacked-ness", so I think this is kind of clunky. > > 2. The approach I take in #847. Add a new kwarg which controls whether or > not multiple datasets are stacked. I think this is the cleanest > implementation, although that's probably obvious because it's how I wrote > my PR. To keep everything consistent in this approach, we should remove the > stackplot function added in #819, and move that functionality to the `plot` > function, adding a `stacked` kwarg there. > > 3. The approach of #819. With this approach, we would add a separate > function to handle stacked versions of different plots. I'd re-write #847 > as a new function called `stackhist`. This approach, IMO, doesn't scale > well if we want to add "stacked-ness" to more plot types in the future. I'm in favour of numero dos, even though for #819 I took approach number 3. I didn't really think about the bigger picture here with regards to stackedness of other plot types. But since seeing your stacked histogram changeset, this seems like a more sensible route. I say this with zero authority, though. It'd be nice to have a few people chime in with their two cents. > Please take a look at this and send comments about these proposals or any > others you might have. I hope the community can come to a consensus which > unifies the handling of stacked-ness. > > Whatever we end up choosing, I think adding a stacked step histogram will > make it much easier to promote the use of mpl in high energy physics, where > we use this style of plot frequently. > > Thanks, > > Nic Eggert > Graduate Fellow > Cornell University -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Missing 1.1.1 tarball on PyPI
On Fri, Aug 24, 2012 at 09:03:48AM -0400, Michael Droettboom wrote: > Sorry about that. PyPI is a bear. > > It seems to finally be uploaded correctly, and "pip install > matplotlib" is working for me. Can you please confirm? > OP mentioned easy_install. Is there a difference between this and pip? > > Mike > > On 08/24/2012 05:23 AM, Ludwig Schwardt wrote: > >Hi, > > > >There does not seem to be an actual tarball of matplotlib 1.1.1 on > >PyPI at http://pypi.python.org/pypi/matplotlib/1.1.1 ... Maybe I'm > >the only person who still likes to easy_install my matplotlib :-) > > > >L. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Bug hunting
Hi all, I'm not sure if anyone's noticed, but I have been looking through some of the issues tagged 'SF' and 'wishlist' on github to try and get them sorted out. I have some spare time since I finished my thesis yesterday; woohoo! I was just wondering, since I've got a little free time now, are there any specific issues I can help out with that should be prioritised higher? I'm aware of the 1.2 feature freeze, so anything new won't be merged over issues that affect a possible release candidate. Thanks! Best, Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Transforms bug
My cherubs,
With my new found free time, I may have discovered a sneaky bug to which
you are not aware. Unless, of course, my example code is incorrect.
I do normal setup:
from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
from matplotlib.figure import Figure
from matplotlib.patches import Rectangle
from matplotlib.transforms import Affine2D
fig = Figure()
canvas = FigureCanvas(fig)
ax = fig.add_subplot(1, 1, 1)
# Make a sexy rectangle at the origin
r = Rectangle((0.0, 0.0), 0.6, 0.4)
# Construct a mind-blowing transformation: rotation by 30 degrees
t = Affine2D().rotate_deg(30.0)
# Make sure to add in the already-known axes data transformation
t += ax.transData
# Rotate that shizzle
r.set_transform(t)
# Plottify
ax.add_patch(r)
fig.savefig('my_awesome_TRAPEZIUM.pdf')
Or you can look at my output here: http://i.imgur.com/2l439.png
Rotation by 30 degrees is an angle-preserving linear transformation. So
this shouldn't happen.
Here's what's messing shiz up: the figure dimensions are not square.
Look what happens when I use a square figure and make the axes fit
exactly to the figure dimensions:
...
fig = Figure((4, 4))
...
ax = fig.add_axes([0, 0, 1, 1])
...
...
fig.savefig('my_awesome_RECTANGLE.pdf')
You can see the output here: http://i.imgur.com/baXiH.png
Boom.
I have no idea how to fix it. I came across it while trying to address
https://github.com/matplotlib/matplotlib/issues/987 but it may or may
not also be related to
https://github.com/matplotlib/matplotlib/issues/1113
Let me know if it's worth putting in github issue. I'm dont want to
create a duplicate ticket should it transpire that this problem is
actually #1113 in disguise.
Best,
Damon
--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Transforms bug
On Mon, Aug 27, 2012 at 01:26:49PM -0400, Michael Droettboom wrote:
> I'm not sure this is a bug. The transformation is being applied in data
> space, and then the mapping to physical space is not square in the x and
> y dimensions.
>
> I think calling set_aspect('equal') on the axes should fix this -- if it
> doesn't, that's indeed a bug.
>
Awesome, it worked. Honestly, I probably should have realised that when
you don't have square axes, right angles are no longer right angles:
noob error. Apologies.
>
> Mike
>
> On 08/27/2012 01:05 PM, Damon McDougall wrote:
> > My cherubs,
> >
> > With my new found free time, I may have discovered a sneaky bug to which
> > you are not aware. Unless, of course, my example code is incorrect.
> >
> > I do normal setup:
> >
> > from matplotlib.backends.backend_pdf import FigureCanvasPdf as FigureCanvas
> > from matplotlib.figure import Figure
> > from matplotlib.patches import Rectangle
> > from matplotlib.transforms import Affine2D
> >
> > fig = Figure()
> > canvas = FigureCanvas(fig)
> > ax = fig.add_subplot(1, 1, 1)
> >
> > # Make a sexy rectangle at the origin
> > r = Rectangle((0.0, 0.0), 0.6, 0.4)
> >
> > # Construct a mind-blowing transformation: rotation by 30 degrees
> > t = Affine2D().rotate_deg(30.0)
> >
> > # Make sure to add in the already-known axes data transformation
> > t += ax.transData
> >
> > # Rotate that shizzle
> > r.set_transform(t)
> >
> > # Plottify
> > ax.add_patch(r)
> >
> > fig.savefig('my_awesome_TRAPEZIUM.pdf')
> >
> > Or you can look at my output here: http://i.imgur.com/2l439.png
> >
> > Rotation by 30 degrees is an angle-preserving linear transformation. So
> > this shouldn't happen.
> >
> > Here's what's messing shiz up: the figure dimensions are not square.
> > Look what happens when I use a square figure and make the axes fit
> > exactly to the figure dimensions:
> >
> > ...
> > fig = Figure((4, 4))
> > ...
> > ax = fig.add_axes([0, 0, 1, 1])
> > ...
> > ...
> > fig.savefig('my_awesome_RECTANGLE.pdf')
> >
> > You can see the output here: http://i.imgur.com/baXiH.png
> >
> > Boom.
> >
> > I have no idea how to fix it. I came across it while trying to address
> > https://github.com/matplotlib/matplotlib/issues/987 but it may or may
> > not also be related to
> > https://github.com/matplotlib/matplotlib/issues/1113
> >
> > Let me know if it's worth putting in github issue. I'm dont want to
> > create a duplicate ticket should it transpire that this problem is
> > actually #1113 in disguise.
> >
> > Best,
> > Damon
> >
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Release Candidate
On Mon, Sep 10, 2012 at 5:00 PM, Michael Droettboom wrote: > We have a few outstanding issues, which I'll categorize below: > > Critical things that need just a little more work: > > #1223dpi= for bitmaps not handled correctly I don't believe this is release critical. It only affects metadata. Eric has fixed this for TIFFs but there may be outstanding issues with other bitmap types. My feeling is that the below issues should receive more attention. > #1209Pass linewidth to Mac context properly > #786savefig() renders paths and text differently than show() > #113dpi= doesn't seem to have any effect with MacOS X backend Michiel has provided great feedback regarding the previously proposed solution to part of this problem, and this has been reflected in the updated pull request. -- Damon McDougall http://www.damon.is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] John Hunter awarded PSF's Distinguished Service Award
All, John Hunter, lead author of matplotlib, has been awarded PSF's Distinguished Service Award. For details, see http://pyfound.blogspot.co.uk/2012/09/announcing-2012-distinctive-service.html Some of you may have already seen this. For those who haven't, it serves as a poignant reminder to the immense effort of John and the matplotlib developers over the past decade. Best, Damon -- Damon McDougall http://www.damon.is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] doc error at http://matplotlib.org/api/matplotlib_configuration_api.html#module-matplotlib
On Mon, Sep 17, 2012 at 5:12 PM, wrote: > "This is an object-orient plotting library" should say "... object-oriented > ...". > > Keith Thanks. Fixed in https://github.com/matplotlib/matplotlib/pull/1267 -- Damon McDougall http://www.damon.is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0rc1 is cut
On Mon, Sep 17, 2012 at 10:53 PM, Michael Droettboom wrote: > Thanks for this. I think it makes sense to see if we can get to the > bottom of this before putting out another release candidate. I have a > feeling that the solution might be obvious to an Objective C expert -- > which I am not. > > Mike > The problem is that gcc 4.0 does not support objective c 2.0. The "for (blah in thing) .." construct was a new addition in Objective C 2.0. -- Damon McDougall http://www.damon.is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Welcoming new core developers
On Thursday, September 20, 2012, Phil Elson wrote: > Congrats to the three of you. The hard work that you all put in doesn't go > unnoticed, and is massively appreciated! > > Mike, as lead developer, your opening round of beers for mpl devs at > SciPy13 is beginning to look costly. ;-) > > > > On 20 September 2012 03:25, Benjamin Root 'cvml', 'ben.r...@ou.edu');> > > wrote: > >> >> >> On Wednesday, September 19, 2012, Michael Droettboom wrote: >> >>> Damon McDougall, Christoph Gohlke and Russell Owen have been added to >>> the set of core developers with push rights and the ability to upload >>> files to the github download page. >>> >>> Damon has come recently on the scene, but has provided all kinds of >>> helpful bug triaging and fixing during the 1.2.0 release cycle, as well >>> as cool new features such as 3d trisurfaces and stacked plots, to name >>> only a few. >>> >>> Christoph Gohlke, besides providing tons of support on the mailing list >>> for a long while, has been providing Windows binaries for the past few >>> releases. >>> >>> Russell Owen has been providing Mac OS-X builds for the past few >>> releases and has helped track down some portability problems in the >>> 1.2.0 release. >>> >>> Thanks to everyone on the growing team! >>> >>> Mike >>> >>> >> Welcome aboard! >> >> Ben Root >> >> >> >> -- >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://ad.doubleclick.net/clk;258768047;13503038;j? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net > 'Matplotlib-devel@lists.sourceforge.net');> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> Wooohooo! Time to stretch that itchy merge finger! Thanks for the recognition, and congratulations to Christoph and Russell, too! This growth will excite more teamwork and development. I'm stoked to be a part of it. Thanks all, Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded
On Thursday, September 20, 2012, Benjamin Root wrote: > > > On Wed, Sep 19, 2012 at 1:53 PM, Michael Droettboom > > > wrote: > >> I have tagged and created a tarball for 1.2.0rc2. The githash is >> 656c88f3e546. The tarball is on the github download page here: >> >> https://github.com/matplotlib/matplotlib/downloads >> >> This includes a number of important bugfixes, including things required >> for creating Macintosh and Windows binaries. The Travis tests are also >> now passing. >> >> I hope it will be easier for the binaries to be created this time. Once >> they are available at github, I will make an announcement to >> matplotlib-users and hopefully get some serious testing out of this thing. >> >> Thanks for all of the hard work! >> >> Mike >> >> > Is it just me, or are colors looking duller? > > I attached before (v1.1.x) and after (v1.2.x) images. > > Ben Root > > Are those different colour maps? Do they look the same when you explicitly set cmap=cm.jet? -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Custom plot_trisurf triangulations
Greetings denizens, I have been playing with custom triangulations in the plot_trisurf method of the mplot3d toolkit. I thought I would share my sweet creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png Let me know your thoughts. I should probably make a pull request out of this, but the code is not currently readable by humans. I will tidy it up first. Make it look purrty. Lots of love, Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom plot_trisurf triangulations
On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas wrote: > On 20 September 2012 22:30, Damon McDougall > wrote: >> >> I have been playing with custom triangulations in the plot_trisurf >> method of the mplot3d toolkit. I thought I would share my sweet >> creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png >> >> Let me know your thoughts. I should probably make a pull request out >> of this, but the code is not currently readable by humans. I will tidy >> it up first. Make it look purrty. > > > Yes please! Ideally it would be good if all mplot3d functions supported the > same arg and kwarg combinations as their 2d equivalents, for consistency. > You may have done this already, but if not you might find the 2d tripcolor > code helpful - it calls Triangulation.get_from_args_and_kwargs(*args, > **kwargs) to do the initial heavy lifting. > Yes, I had seen it. Thank you. Unfortunately, using this is non-trivial when you have an extra 'z' variable. There are a couple of options to get around this: 1. Re-write a 3d version and add it to matplotlib.tri. Pros of this approach are that the 3d methods would basically only require one extra line, a call to Triangulation.get_from_args_and_kwargs_3d(*args, **kwargs). Cons of this approach are code repetition. Also, I'm not a fan of putting 3d code into main mpl codebase. I think it should stay in the toolkit. 2. Implement option 1. but in the mplot3d toolkit rather than the main codebase. 3. Create a new args_2d tuple exactly equal to *args but with 'z' removed. Then rely on the 2d code with: Triangulation.get_from_args_and_kwargs(args_2d, **kwargs). Since this option would be common to all 3d functions relying on the 2d heavy lifting, it could be wrapped up into a convenience function. In my opinion, option 3. is preferable. Option 3. will also produce commits with the highest signal-to-noise ratio. > Forgive my cheek, but whilst you are looking at this area mplot3d.tricontour > and tricontourf need similar improvement... > Forgiven. I might as well do it whilst I'm already half-way down the rabbit hole. > A wider issue, and something I should have mentioned when you first > implemented plot_trisurf, is that I don't like the function name. It seems > unnecessary to have the plot_ at the front as most of the other plot-related > functions manage without it. My unease extends to plot_surface and > plot_wireframe as well. I guess we can't just change such names now that > they are being used, but eventually I would like to see better naming within > mplot3d. > Agreed. Not sure how best to solve this. Furthermore, I think it should be implemented in a pull request separate to the one migrating these 3d methods to custom triangulations. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom plot_trisurf triangulations
On Fri, Sep 21, 2012 at 6:21 PM, Ian Thomas wrote: > I am happy with option 3 too, but I don't think you need to do as much as > this. The existing 2d triplot/tripcolor/tricontour call > Triangulation.get_from_args_and_kwargs, which removes the various > args/kwargs needed for the triangulation and leaves the remainder for the > calling function to process. For example lib/matplotlib/tri/tricontour.py > lines 86 to 88: > > tri, args, kwargs = \ > Triangulation.get_from_args_and_kwargs(*args, **kwargs) > z = np.asarray(args[0]) > > Can't you just do the same here, or am I missing something? Ah ok, I see. I was assuming a plot_trisurf(x, y, z, triangles, ...) signature. Copying the tricontour signature would be better for consistency reasons. It appears that I was the one missing something! Thanks for that. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom plot_trisurf triangulations
On Fri, Sep 21, 2012 at 2:38 PM, Benjamin Root wrote: > I wouldn't be against going down a deprecation path for renaming these > functions, but for what gains? The names have been there since before I > took up this toolkit, and ultimately, these functions aren't typed so often > that brevity would gain one much. Definitely any new functions should not > take up that naming, but I see no real compelling reason to change the > existing names. Technically, 1.2 hasn't been released yet. We can still change plot_trisurf to trisurf, though it appears there is still uncertainty regarding whether there will actually be a third release candidate. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Custom plot_trisurf triangulations
On Sat, Sep 22, 2012 at 10:40 AM, Damon McDougall wrote: > Ah ok, I see. I was assuming a plot_trisurf(x, y, z, triangles, ...) > signature. Copying the tricontour signature would be better for > consistency reasons. It appears that I was the one missing something! I just realised I'm not making any sense here. Please disregard most of what I say. I'm using the get_from_args_and_kwargs method and everything is fine. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded
On Wed, Sep 19, 2012 at 6:53 PM, Michael Droettboom wrote: > I have tagged and created a tarball for 1.2.0rc2. The githash is > 656c88f3e546. The tarball is on the github download page here: > > https://github.com/matplotlib/matplotlib/downloads > > This includes a number of important bugfixes, including things required > for creating Macintosh and Windows binaries. The Travis tests are also > now passing. > > I hope it will be easier for the binaries to be created this time. Once > they are available at github, I will make an announcement to > matplotlib-users and hopefully get some serious testing out of this thing. > > Thanks for all of the hard work! > > Mike The website says the current development version is rc1. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded
On Mon, Sep 24, 2012 at 2:05 PM, Michael Droettboom wrote: > Thanks for pointing this out. It should now be fixed. > Nope, it still says 1.2.0rc1: http://matplotlib.org -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded
On Mon, Sep 24, 2012 at 7:23 PM, Russell E. Owen wrote: > In article <506092fe.3020...@stsci.edu>, > Michael Droettboom > wrote: > >> For the compilation problem, I am no Objective-C expert, but in C, line >> 3557 should certainly read: >> >> NSSize pxlSize = NSMakeSize(rep->pixelsWide, rep->pixelsHigh); >> >> I wonder if that fixes it -- but that's a total stab in the dark. This >> was a part of the code that was changed quite recently. > > I opened issue #1304 > <https://github.com/matplotlib/matplotlib/issues/1304> > but did not append your comment. Fixed in https://github.com/matplotlib/matplotlib/pull/1305. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
called). > Internally, the lines will be length 3 Line2D objects, with the 3 > points being offset-.5*height, offset, and offset+.5*height. > > So what does everyone think of this approach? Does anyone have any > comments, suggestions, or just think the approach is nonsense? It > would certainly be possible to implement this based more on existing > classes, but I don't think the implementation would be as clean, as > maintainable, or as extensible as this implementation. I hope these comments are useful. Best, Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Thu, Sep 27, 2012 at 12:44 PM, Todd wrote: > On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall > wrote: >> Hi Todd, >> >> Firstly, thanks for taking the time to crystallise your thoughts in >> words first. This is one of my bad habits; I tend to rush into things. >> >> I have some feedback for you, hopefully we can all work together to >> get this right. It's difficult when something new gets implemented and >> someone expects it to do something and the only way to resolve it is >> to break the calling API. > > Where is API broken? Nowhere. I wasn't implying you were breaking something. My point was that it's easy to add functionality but hard to remove it, therefore it's important to get it right from the outset. I'm sorry for the misunderstanding; I wasn't clear. > >> Anyway, I hope you'll find my comments >> helpful at the least. I also encourage others to weigh in with >> opinions and ideas. > > Okay, I will discuss the rationale. I will snip out anything you > agree on for brevity. > >>> Assuming we go with the name, here is my proposed call signature: >>> >>> EventRaster(x, offset=0, height=1, **kargs) >> >> CamelCase is discouraged for method names. Perhaps 'eventraster'? > > Fair enough. > >> Also, we could also let **kwargs swallow the 'offset' and 'height' >> keyword arguments. Then the user isn't constrained by which order to >> put them in. The downside of this approach is that introspection is >> more difficult. > > I don't understand the advantage of this approach. If you use keyword > arguments, then the order doesn't matter. So with the approach above > you can use keyword arguments, in which case you can use whatever > order they want, or you can use positional arguments. On the other > hand putting it in **kwargs, we lose the ability to use positional > arguments. So we lose nothing by allowing both positional and keyword > arguments. It is also easier to implement. > >>> offset determines the positions of the rows. By default, the first >>> row is placed with the line center y=0, and subsequent rows are placed >>> with the line centers at increasing 1-unit increments. If offset is >>> defined and is a scalar, the first row is placed at the offset, and >>> subsequent rows are placed at increasing 1-unit increments. If offset >>> is an array, it must be a 1D array of the same length as the second >>> dimension of x. In this case each element in offset determines the >>> center of the corresponding row in the plot. >> >> How about letting offset be either: a) a scalar, determining the >> offset of all rows equally; or b) an array, determining the offset of >> each row individually. > > Because people are almost never going to want to have all the lines > stacked right on top of each other. The plot would be indecipherable > that way. The defaults are chosen to handle the most common use-cases > most easily. > >> In fact, why plot each row at integer y >> coordinates? Could we allow for an optional y-coordinate array, each >> element of which would be the y-coordinate at which to plot a row of >> lines. Then you wouldn't need offset. > > That is exactly what offset does if you pass an array. > >>> If this is going to be used to implement rug plots, it would need some >>> way to handle columns of horizontal lines in addition to rows of >>> vertical lines. I see two ways to implement this. First is to have >>> to plot types, perhaps HEventRaster and VEventRaster. The first would >>> be as described above, while the second would be similar but >>> everything rotated 90 degrees. Another possibility is to change the >>> call signature to this: >>> >>> EventRaster(x, y=None, offset=0, height=1, **kargs) >> >> I think accepting an 'orientation' kwarg, which can take either >> 'horizontal' or 'vertical', determining the orientation of the lines >> and reversing the roles of the x and y arrays. > > That would work as well. Probably cleaner that way > >>> The function will return a list of a new collection type I am >>> tentatively calling EventCollection. My thinking would be this would >>> be a subclass of a new collection type called GenericLineCollection, >>> which the current LineCollection would also subclass. They would >>> share things like the color handling and segment handling, however the >>> segment handling will be a "private&quo
[matplotlib-devel] Python 3.3 released
I've just read that Python 3.3 has been released<http://python.org/download/releases/3.3.0/> and thought I would initiate a discussion oriented around adoption and possible benefits/problems. It appears that, at least for the Mac, there are issues with certain versions of ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no experience with this, so I can't really comment further. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: Python 3.3 released
Forgot to reply all. -- Forwarded message -- From: Damon McDougall Date: Sat, Sep 29, 2012 at 8:51 PM Subject: Re: [matplotlib-devel] Python 3.3 released To: Benjamin Root On Sat, Sep 29, 2012 at 6:46 PM, Benjamin Root wrote: > > > On Saturday, September 29, 2012, Christoph Gohlke wrote: >> >> On 9/29/2012 9:48 AM, Damon McDougall wrote: >> > I've just read that Python 3.3 has been >> > released<http://python.org/download/releases/3.3.0/> and thought I >> > would initiate a discussion oriented around adoption and possible >> > benefits/problems. It appears that, at least for the Mac, there are >> > issues with certain versions of >> > ActiveTcl<http://www.python.org/download/mac/tcltk/>. I have no >> > experience with this, so I can't really comment further. >> > >> >> All tests pass with matplotlib-1.2.0rc2.win-amd64-py3.3. >> >> Christoph >> > > I wouldnt expect less. The question is if the TkAgg still works with > ActiveTcl on the Mac? > > Ben Root I almost never use the GUI stuff in mpl. When I do, it's almost always the Qt4 backend or the OS X backend. I have never gotten the Tk backend to work. It always errors out with after popping up a window (with no plot in it) and fails very gracefully with a TclError, giving no indication of what Tcl didn't like. I think Phil is a Tk-er. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] branch merge strategy
On Sun, Sep 30, 2012 at 9:24 PM, Eric Firing wrote: > On 2012/09/30 7:14 AM, Michael Droettboom wrote: >> On 09/29/2012 08:07 PM, Eric Firing wrote: >>> Mike, >>> >>> I'm getting confused about branch merge strategy. Usually, it seems >>> that it has been to periodically merge the maintenance branch into >>> master. Something like this: >>> >>> git fetch upstream >>> git checkout master >>> git merge --ff-only upstream/master >>> git merge upstream/v1.2.x >>> # test, commit changes if necessary >>> git push upstream master >>> >>> Is that correct? >>> >>> At present, however, we seem to be developing fairly long separate >>> threads on the two branches, with duplicate changesets, presumably >>> from cherry-picking. Is this intentional? Do you plan to go back to >>> the merge strategy? >> >> A few things were cherry-picked over to 1.2.x, since the PR was >> initially set up against master and github doesn't provide a way to >> change the destination of a PR after creating it. But that was meant to >> be the exception... the "preferred" way hasn't changed. >> >>> >>> I can see that a problem with branch merging is that there are >>> occasionally changesets in v1.2.x, such as the rc version tagging, >>> that are not appropriate for master. >> Tags don't merge across branches because tags are just pointers to >> particular commit hashes. When doing a merge, you always get a new >> commit hash (since the parents are different). As for updating the >> version number, however, yes, those changes need to be manually >> addressed -- though it usually shows up as a merge conflict, so it's >> obvious that it needs to be done. > > Mike, > > Thanks. I have performed the merge of v1.2.x into master, and I think > everything is OK; the changes reflect only the commits that were not > cherry-picked. I also reverted what I think was an inadvertent version > change in master, so now it is back to 1.3.x. > > Eric > > >> >> Mike I had an idea this morning about how best to resolve this. I think the developers' lives would be made slightly easier if contributors knew where to branch from at the outset. I think when most people submit a pull request (myself included) they automatically branch from master. This is where the problem lies. If someone is submitting a bug fix during a release cycle they should almost certainly branch from v1.2.x, or whatever the current version branch is. This way, if the pull request gets accept it's trivial to merge it into the correct place (v1.2.x) and if it's accepted but is not deemed suitable for v1.2.x it can be rebased onto master. This avoids the, in my opinion, ugly cherry-picking solution. Since all of our patches and contributions are taking place on github, to get this information to contributors I propose updating the readme.txt file to include this information. It's the first thing people see when they're on the matplotlib github page so I think it would make a big difference. How does that sound? -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] MEP11: Attempting to deal with the Python library dependency issue
On Wed, Oct 3, 2012 at 10:08 PM, Christoph Gohlke wrote: > On 10/3/2012 9:20 AM, Michael Droettboom wrote: >> I invite comments for a new MEP about improving the situation with >> respect to our bundling of third-party Python dependencies. >> >> In particular, I'd love feedback from the various stakeholders -- those >> producing binary installers and packages for the various platforms. >> >> https://github.com/matplotlib/matplotlib/wiki/MEP11 >> >> Mike > I think that matplotlib, the library, should not attempt to work around > Python's distribution/packaging limitations. Please do not use > post-install or run-time scripts to detect and install missing > dependencies. I whole-heartedly agree here. There are package managers for this job. I understand there are people less package-literate and, as you point out below, the development team for each separate dependency can ship a binary. Though I understand not all do this. > Optionally, for Windows users that won't touch pip or easy_install (like > me), matplotlib could provide separate downloads of installers for > dateutil, pytz, pyparsing, and six. They are trivial to create. > Also consider a separate package for the matplotlib tests, which would > include 35 MB of baseline images that are of little use to end users. I agree here, too. I think most people who want to use the library won't ever run or touch the tests. Heck, I only ever ran the tests after I started contributing back to the community. Perhaps they should be spawn off to a matplotlib-tests git submodule that Travis can use for commit-checking. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PyGTK vs PyGObject
On Friday, October 5, 2012, Michael Droettboom wrote: > On 10/05/2012 06:38 AM, todd rme wrote: > > I am trying to do some experimental packages with python 3 and the > latest RC, and I am trying to figure out the situation with some of > the backends. Some are obvious, like wxwidgets and PyQt (Qt3 > version). > > The issue I am running into is with the gtk backend PyGTK is > deprecated. According to the website, all development halted a year > and a half ago and they say to use PyGObject instead. PyGTK, as far > as I can tell, does not support Python 3 or GTK 3. PyGObject, > however, supports both. So I was wondering what I should be doing > with this backend. Does matplotlib support PyGObject, or should the > GTK backends just be disabled on Python 3 builds? > > > The new Gtk3Cairo backend uses PyGObject and works under Python 3. (This > refers to Gtk version 3, which is also only supported by PyGObject -- the > backend could perhaps have been called PyGObject, but in fact the toolkit > used is still Gtk, so the naming is perhaps a bit confusing). The older > pygtk backend still ships with Python 3, but a warning is displayed when > the user attempts to use it. > > Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a bitmap > buffer from being transferred to an on screen window, the Gtk3Agg backend > will also work. > > http://lists.cairographics.org/archives/cairo/2011-November/022519.html > > BTW -- this report has languished for almost a year. Does anyone know a > better way to get the ear of the pycairo developers? > > Mike > Do we use pycairo to interface with the Cairo library? Is there any reason we don't use the C (or C++, I can't remember what libcairo is written in) directly? This may get around the issue, but it'd be a lot of work... -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PyGTK vs PyGObject
On Fri, Oct 5, 2012 at 5:51 PM, Michael Droettboom wrote: > On 10/05/2012 11:40 AM, Damon McDougall wrote: > > On Friday, October 5, 2012, Michael Droettboom wrote: >> >> On 10/05/2012 06:38 AM, todd rme wrote: >> >> I am trying to do some experimental packages with python 3 and the >> latest RC, and I am trying to figure out the situation with some of >> the backends. Some are obvious, like wxwidgets and PyQt (Qt3 >> version). >> >> The issue I am running into is with the gtk backend PyGTK is >> deprecated. According to the website, all development halted a year >> and a half ago and they say to use PyGObject instead. PyGTK, as far >> as I can tell, does not support Python 3 or GTK 3. PyGObject, >> however, supports both. So I was wondering what I should be doing >> with this backend. Does matplotlib support PyGObject, or should the >> GTK backends just be disabled on Python 3 builds? >> >> The new Gtk3Cairo backend uses PyGObject and works under Python 3. (This >> refers to Gtk version 3, which is also only supported by PyGObject -- the >> backend could perhaps have been called PyGObject, but in fact the toolkit >> used is still Gtk, so the naming is perhaps a bit confusing). The older >> pygtk backend still ships with Python 3, but a warning is displayed when the >> user attempts to use it. >> >> Once PyGObject/PyCairo addresses a shortcoming [1] that prevents a bitmap >> buffer from being transferred to an on screen window, the Gtk3Agg backend >> will also work. >> >> http://lists.cairographics.org/archives/cairo/2011-November/022519.html >> >> BTW -- this report has languished for almost a year. Does anyone know a >> better way to get the ear of the pycairo developers? >> >> Mike > > > Do we use pycairo to interface with the Cairo library? Is there any reason > we don't use the C (or C++, I can't remember what libcairo is written in) > directly? > > This may get around the issue, but it'd be a lot of work... > > We do use pycairo. It certainly would get around the issue, but duplicate a > lot of effort that pycairo already handles for us. > > Now that I've seen that the bug has been fixed in pycairo's git (see my > earlier message), I'm comfortable just waiting for the next pycairo release > (assuming it's not too far off). > > Mike Of course. I was merely asking to qualm my curiosity rather than suggesting a major codebase re-haul. Thanks for looking into this. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Upload a higher res logo to github
On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root wrote: > Looks like github has changed the layout of the default landing page for any > github account. This now has the account's profile image shown much larger > than originally intended. Our front page now has a very pixelated logo on > display. Given how much we pride ourselves on high-quality images, we > should probably fix this: > > https://github.com/matplotlib > > Cheers! > Ben Root This has been bugging me for a while... -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PEP8 github label
On Sun, Oct 14, 2012 at 1:29 AM, Eric Firing wrote: > On 2012/10/13 1:16 PM, Damon McDougall wrote: >> I probably should have tested the waters first, but I added a PEP8 >> github label. It's neon orange so you can't miss it. The reason I did >> this is so that the list of v1.2.x milestoned issues can be easily >> filtered by eye. That way it looks less daunting (since PEP8 isn't a >> huge priority for version 1.2 (at least not compared to bug fixes)) >> and it's easier to see the more important issues. >> >> It's also temporary. Nelle's done a great job trawling through the >> codebase and raising some important points. There's a finite amount of >> bulk work to do and then the label can be removed. >> >> If anyone is offended by neon orange, please feel free to change it. I >> just wanted to be able to organise things a little more succinctly. >> > > I don't care about the color, but I don't understand the rationale for > putting these PEP8 changes in v1.2.x, especially when they are based on > master. It seemed to me that the thing to do was get out a v1.2 release > without the PEP8 changes, and let them be the basis in master for > proceeding to v1.3. > > Evidently I was wrong, and we are instead doing massive cherry-picking > from master. > > A disadvantage of this is that PEP8 changes, though seemingly innocuous, > could introduce subtle bugs, so rushing them in at the end of the rc > cycle seems like it is taking an unnecessary risk for no functional benefit. > > Eric The downside of merging them into master without cherry-picking into 1.2 is the horrific merge conflicts that will occur whenever there's a pull request based on 1.2. I see your point of introducing subtle bugs. I'm happy to wait on the PEP8 changes if it seems too risky. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing wrote: > All, > > I think we are in a messy situation, and we need to reach some agreement > as to how to proceed. This has been discussed a bit in this thread: > > http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel > > The name of that thread did not reflect the importance of the discussion > it prompted, hence the present message. > > To summarize my view: > > 1) We have a flood of PEP8 PRs based on master, many of which have been > merged, some by myself--so I have no objection to this aspect of the > situation, though I would have preferred a slower pace, a garden hose > rather than a fire hose. I am happy to see continued merging of these > PRs into master. > > 2) We are also trying to stabilize v1.2.x, getting in the last few bug > fixes and doc updates, so we can get a release out, with a high > probability that it will be solid. > > 3) The potential disagreement is over whether the PEP8 changes should be > cherry-picked into v1.2.x, or simply left in master. I favor the latter > course. First, because massive code churn shortly before a release > seems unwise. Second, because I think we should stick to the strategy > we started with, in which an effort is made to choose the most > appropriate target for each PR, frequently merge the maintenance branch > into master, and reserve cherry-picking for occasional corrections. > > 4) The PEP8 changes will cause some merge problems no matter what we do; > but I think that they can be minimal and manageable if we leave PEP8 out > of v1.2.x, and decide that once it is released, v1.2.x will be changed > only if critical bugs are found, requiring a v1.2.1 release. This also > assumes that we have only a few changes left to be made in v1.2.x before > a final rc and a release. > > Therefore I recommend that the PEP8 changes that have already been > cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x > milestone be removed from all PEP8 changes. > > If some of the PEP8 commits include genuine bug-fixes that need to be in > v1.2.x, then these fixes should be made via PRs directly against v1.2.x. > > Agreement? Disagreement? Discussion? Related aspects of strategy? > > Eric I'm happy with whatever is decided. I'd rather not have merge conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to not cherry-pick them into 1.2.x. If it is decided that we are to revert all the PEP8 changes in 1.2.x, what should be done about PEP8 changes that were merged into master before the v1.2.x branch was created? -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] strategy for 1.2.x, master, PEP8 changes
On Mon, Oct 15, 2012 at 8:59 AM, Nelle Varoquaux wrote: > > > On 15 October 2012 06:10, Eric Firing wrote: >> >> On 2012/10/14 12:44 PM, Damon McDougall wrote: >> > On Sun, Oct 14, 2012 at 9:22 PM, Eric Firing wrote: >> >> All, >> >> >> >> I think we are in a messy situation, and we need to reach some >> >> agreement >> >> as to how to proceed. This has been discussed a bit in this thread: >> >> >> >> >> >> http://sourceforge.net/mailarchive/forum.php?thread_name=507AFDC6.8000801%40hawaii.edu&forum_name=matplotlib-devel >> >> >> >> The name of that thread did not reflect the importance of the >> >> discussion >> >> it prompted, hence the present message. >> >> >> >> To summarize my view: >> >> >> >> 1) We have a flood of PEP8 PRs based on master, many of which have been >> >> merged, some by myself--so I have no objection to this aspect of the >> >> situation, though I would have preferred a slower pace, a garden hose >> >> rather than a fire hose. I am happy to see continued merging of these >> >> PRs into master. >> >> >> >> 2) We are also trying to stabilize v1.2.x, getting in the last few bug >> >> fixes and doc updates, so we can get a release out, with a high >> >> probability that it will be solid. >> >> >> >> 3) The potential disagreement is over whether the PEP8 changes should >> >> be >> >> cherry-picked into v1.2.x, or simply left in master. I favor the >> >> latter >> >> course. First, because massive code churn shortly before a release >> >> seems unwise. Second, because I think we should stick to the strategy >> >> we started with, in which an effort is made to choose the most >> >> appropriate target for each PR, frequently merge the maintenance branch >> >> into master, and reserve cherry-picking for occasional corrections. >> >> >> >> 4) The PEP8 changes will cause some merge problems no matter what we >> >> do; >> >> but I think that they can be minimal and manageable if we leave PEP8 >> >> out >> >> of v1.2.x, and decide that once it is released, v1.2.x will be changed >> >> only if critical bugs are found, requiring a v1.2.1 release. This also >> >> assumes that we have only a few changes left to be made in v1.2.x >> >> before >> >> a final rc and a release. >> >> >> >> Therefore I recommend that the PEP8 changes that have already been >> >> cherry-picked into v1.2.x be removed from v1.2.x, and that the v1.2.x >> >> milestone be removed from all PEP8 changes. >> >> >> >> If some of the PEP8 commits include genuine bug-fixes that need to be >> >> in >> >> v1.2.x, then these fixes should be made via PRs directly against >> >> v1.2.x. >> >> >> >> Agreement? Disagreement? Discussion? Related aspects of strategy? >> >> >> >> Eric >> > >> > I'm happy with whatever is decided. I'd rather not have merge >> > conflicts, but if PEP8 is seen as a high-risk merge then I'm happy to >> > not cherry-pick them into 1.2.x. >> > >> > If it is decided that we are to revert all the PEP8 changes in 1.2.x, >> > what should be done about PEP8 changes that were merged into master >> > before the v1.2.x branch was created? >> > >> >> Damon, >> >> As I said, I would not advocate trying to back out everything, and maybe >> not any of what is already in 1.2.x, or maybe just the most recent >> bunch. Anticipating that Mike D. might want to make a decision tomorrow >> (or today from your timezone), perhaps it would be helpful if you could >> make an approximate map of which PEP8 commits were cherry-picked to >> 1.2.x, and how recently? I have been trying to figure this out with >> qgit and git log with various options, but it makes my head spin. > > > List of commits that were cherry-picked recently (names only, but I can do > the commit id as well): > > PEP8 fixes on blocking_input.py > PEP8 fixes on blocking_input (patch n°2) > PEP_ fixes on cbook.py > PEP8 fixes 2. => 2.0 > PEP8 fixes on tight_bbox.py > PEP8 fixes on tight_layout.py > PEP8 fixes - break points and identation > PEP8 fixes on type1font.py > PEP8 fixes - small backslashes and breaks fixes > PEP8 fixes on transforms.py > FIX - tr
Re: [matplotlib-devel] request for code review: updates to Sankey class
On Tue, Oct 16, 2012 at 2:55 PM, Kevin Davies wrote: > Hello, > > I made a few minor changes to the Sankey class. They are listed at: > https://github.com/kdavies4/matplotlib/compare/master...sankey5 > > Please review this and let me know if I can submit a pull request. > > Thanks. > > Kevin Thanks for taking the time to fix up a part of the codebase! If you make a pull request out of your code, we'll be able to leave inline comments on your patches. Nonetheless, I have some feedback for you after a (very) quick glance: 1) I don't think 'orientations' is a python keyword. What is the error you were getting? In any case, changing it breaks backwards compatibility so I'd be an advocate of keeping 'orientations'. Unless, of course, the error you were getting was serious. 2) Your changes appear to be, mainly, cosmetic. This is good but may cause issues with some of the PEP8 pull requests we have been getting. Have you rebased to make sure these changes are incorporated? 3) Inline with my PEP8 remark in 2) above. You have some lines (maybe only one or two) that look longer than 79 characters. Other than that, I think you should turn this into a pull request so you can get more feedback on an interactive level. Best, Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] mpl_binutils: Plotting from the command-line with matplotlib
All, Several days ago I tested the waters and asked you guys, the community, how useful you thought a command-line front-end to matplotlib would be. The overwhelmingly positive feedback was enough for me to sit down and figure out how to do this well, and in a way that would mimic existing tools to achieve such tasks. One example being the `graph` utility, which is a part of GNU plotutils. Though there are subtle differences between mpl_binutils and GNU plotutils they, in my opinion, improve the user experience and reduce the ambiguity regarding the parsing of command-line options. I am announcing that mpl_binutils is in a state ready to be tested by you guys. Hopefully you'll find it useful. You can check out the source code here: https://github.com/dmcdougall/mpl_binutils Without getting into details, I ran into some serious limitations with argparse. At the end of the day, nothing is perfect, but some tools are better than others. One such tool, docopt, was shown to me by Mark Lawrence. docopt will change the way I do any python from the command-line in the future. docopt is a light-weight command-line parsing library written in python with no dependencies. mpl_binutils has two dependencies: docopt and matplotlib. Most of you should already have one of these! For the other, a simple `pip install docopt` should work but I had no problems installing it from source (python setup.py install) on OS X. mpl_binutils is currently a single script (a python script), called mpl-graph. There is example usage on the github readme if you'd like to take a look. Currently, mpl-graph doesn't fail gracefully. It should, but I wanted to get something working first. Command-line option validation is next on my todo list and since there are only a handful of command line options implemented (albeit the most useful ones, in my opinion), this shouldn't be too big of a job. Go forth and fork! -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Cutting 1.2rc3
On Monday, October 22, 2012, Benjamin Root wrote: > > > On Mon, Oct 22, 2012 at 10:10 AM, Michael Droettboom > > > wrote: > >> Thanks to everyone for the hard work on getting the last few bugs >> squashed! I think 1.2.0 is going to be a very high quality release. It >> looks like we're only down to one last issue marked for 1.2. >> >> https://github.com/matplotlib/matplotlib/pull/1326<https://github.com/matplotlib/matplotlib/pull/1326/files> >> >> Do you think it's realistic to cut a 1.2rc3 tomorrow? I hope that this >> will be the last release candidate for 1.2.0 and we won't need to make any >> significant additions before the final release. >> >> Then we can all move forward with the good number of PEP8 fixes, larger >> MEP improvements and other great features in the pipeline. >> >> Mike >> >> > That should be do-able. I think all we really need for that PR is the > addition of documentation describing what does a transform of None means. > Phil expressed some concerns regarding similar transform problems with Collections. I don't think these have been addressed yet. There have also been a few bug fixes that have popped up in the last few days. Jens Nielsen has a couple of bounding box tweaks to make tables work with bbox_inches='tight'. There was also another issue opened regarding the parsing of the edgecolors kwarg in ax.pcolor. Jens' pull request is a bug fix, in my opinion. It is currently targeted for master (as is the currently milestoned 1.2 PR regarding transforms) but I don't see any reason for it to not make 1.2. If others feel the same then I would rather see it targeted properly as opposed to it being cherry-picked. > Cheers! > Ben Root > -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: Delaying rc3 (again)
Whoops! I copied in the users mailing list by accident. Stupid iPhone gmail app is stupid. I might have possibly ruined the rc3 surprise. Sorry about that. -- Forwarded message -- From: *Damon McDougall* Date: Tuesday, October 30, 2012 Subject: [matplotlib-devel] Delaying rc3 (again) To: "Russell E. Owen" Cc: "matplotlib-us...@lists.sourceforge.net" < matplotlib-us...@lists.sourceforge.net> On Tuesday, October 30, 2012, Russell E. Owen wrote: > In article <508ff830.3050...@stsci.edu>, > Michael Droettboom > wrote: > > > Agreed! Thanks to everyone for their hard work. I think this has > > shaped up to be a great release. > > > > I'm fortunate to have power and connectivity today, so I was able to get > > a release tested, tagged and uploaded. > > > > To our binary builders: as able, it would be great to put the binaries > > up (or send them to me to do so), and then I'll make an announcement on > > matplotlib-users. I really intend (barring any really serious issues) > > this to be the last rc before the 1.2.0 final. > > > > Thanks again, > > Mike > > The Mac binaries are now up. This time it built perfectly on MacOS X > 10.4; thanks to the folks that worked so hard fixing those build > problems. > > The 32-bit version is not well tested because I have neither inkscape > nor ghostscript installed on that ancient system, but it passes the > tests that it can run under those circumstances. > > The 64-bit version passes all tests except 2 knownfail and 3 skipped. > > -- Russell > > P.S. I had to build the 64-bit version twice. The first time I tried to > build it using the same directory of code that I used to build 32-bit > version. I first deleted the "build" and "dist" subdirectories and ran > "python setup.py clean", then built as usual. There were no errors or > warnings during the build, but the unit tests would not run on the > results -- complaining of missing modules. > > So I built again using a freshly unpacked code directory and that worked > just fine. > > I'm pretty sure I've seen this problem before, but keep forgetting to > ask about it. > > Is this a bug somewhere (e.g. in matplotlib's setup.py or somewhere in > python) or is there some better way to clear out a python code directory? > Yes! I'm sending you a virtual high five! Thanks for thy Russell. -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
On Wed, Oct 31, 2012 at 7:04 AM, Maximilian Albert wrote: > [I sent this email a few weeks ago already, but I wasn't subscribed to > matplotlib-devel at the time and it seems that the message was never > approved by the moderator. So here comes my second attempt. :)] > > Hi all, > > this is my first post to this mailing list, so let me take the > opportunity to thank everyone involved for an amazing piece of > software and all the hard work you guys put into it! It is very much > appreciated indeed. > > I have a quick question/suggestion regarding the save() method in the > matplotlib.animation.Animation class. I recently produced an animation > in which I needed to set tight bounding boxes when saving the > individual frames. Obviously savefig() supports this, but there is no > way to pass this information to the Animation.save() method. Would it > make sense to let Animation.save() accept additional keyword arguments > which are simply passed on to savefig() in each step of the animation > loop? Or am I overlooking potential drawbacks of this approach? A > simple patch with this idea is attached. Feel free to use it as is or > to modify at will if you think this is useful. > > Many thanks and kind regards, > Max Hi Max, Sounds like a great idea! Would you feel comfortable having a go at an implementation? You can make a pull request out of it. The rest of the developers can then deliberate and provide feedback for you. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Animation class: let save() accept **kwargs which are passed on to savefig()?
On Wed, Oct 31, 2012 at 7:40 AM, Maximilian Albert wrote: > Hi Damon, > > many thanks for the quick (and positive :)) reply, > >> Sounds like a great idea! Would you feel comfortable having a go at an >> implementation? You can make a pull request out of it. The rest of the >> developers can then deliberate and provide feedback for you. > > I attached a patch to my previous email which contains an > implementation, but perhaps it didn't make it through to the list? But > since I had to clone the git repository anyway to implement it, I'm > happy to make a pull request, too. I'll have to find out how to do > that since I've never done it before, but I guess it can't be too > difficult. Will give it a shot later today. You need to fork the main matplotlib repo, so you have your own copy associated with your github account: https://help.github.com/articles/fork-a-repo Once you've forked it, clone it and create a branch: git clone my-forked-repo-url cd matplotlib git checkout -b my_awesome_new_feature # ... hack hack hack ... git commit -am "Useful commit message here" git push origin my_awesome_new_feature Once you've done that, make a pull request by following the instructions here: https://help.github.com/articles/using-pull-requests Once you've done that, congratulations! Hope this helps. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: 1.2.0 Final tagged and uploaded
-- Forwarded message -- From: Damon McDougall Date: Thu, Nov 8, 2012 at 6:16 PM Subject: Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded To: "Russell E. Owen" On Thu, Nov 8, 2012 at 5:52 PM, Russell E. Owen wrote: > In article <509be976.90...@stsci.edu>, > Michael Droettboom > wrote: > >> Thanks again to everyone for all of their hard work. This release has >> been tagged and uploaded. >> >> As per the usual drill, once we have the binaries up, I'll make an ANN >> on matplotlib-users. >> >> The documentation is currently being rebuilt, and the default for >> matplotlib.org will update to 1.2.0 around the same time as that >> announcement. >> >> Mike > > Congratulations! > > It looks like the binaries are all there (I uploaded the Mac binaries > and found the Windows binaries already present). Was waiting for your OK on this Russell. Glad to know they're building fine. Good work. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 Forgot to include everybody else. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Thu, Nov 8, 2012 at 6:14 PM, Mark Lawrence wrote: > On 08/11/2012 17:18, Michael Droettboom wrote: >> Thanks again to everyone for all of their hard work. > > Yep. And a fantastic memorial in its own right to the late John Hunter. > >> >> As per the usual drill, once we have the binaries up, I'll make an ANN >> on matplotlib-users. > > IIRC matplotlib is currently third in the list of libraries most wanted > by users waiting for Python3 compatibility. I'd guess that many > scientific users are aware of this wonderful milestone, but to spread > the news at a minimum I'd put this on the main Python mailing list and +1 for this > on Python announce. Or does that happen anyway, and I'd simply > forgotten about it? > >> >> The documentation is currently being rebuilt, and the default for >> matplotlib.org will update to 1.2.0 around the same time as that >> announcement. >> >> Mike >> >> -- >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_nov >> > > -- > Cheers. > > Mark Lawrence. > > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_nov > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Sun, Nov 11, 2012 at 12:19 PM, Fernando Perez wrote: > On Sun, Nov 11, 2012 at 11:47 AM, Benjamin Root wrote: >> Don't see why not. Thanks for the advertising! > > OK, so it will be! Thanks again for everyone who made this possible! > > f Yeah that's a great idea. Get the word out. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0 Final tagged and uploaded
On Mon, Nov 12, 2012 at 10:52 AM, Fernando Perez wrote: > Hi folks, > > On Sun, Nov 11, 2012 at 1:20 PM, Damon McDougall > wrote: >> Yeah that's a great idea. Get the word out. > > I did: > > https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=17 > > and the crowd actually erupted into spontaneous applause when I > pointed out the py3 support! That's what I like to hear. I played no part in the py3 support, but it's a pretty herculean effort. In general I feel the 1.2.0 release is an extremely robust release. > So good job to the whole team. > > I also put in a slide about John pointing people to the memorial fund: > > https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=50 Thanks Fernando. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] master vs maintenance branches (current process and proposal for future workflow)
On Mon, Nov 12, 2012 at 2:52 PM, Benjamin Root wrote: > > > On Mon, Nov 12, 2012 at 3:44 PM, Paul Ivanov wrote: >> >> Hey everyone, >> >> So I don't have a clear picture in my head of our development cycle, and I >> don't think it's well documented. I didn't want thread jack, but in another >> thread Mike wrote: >> >> On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom >> wrote: >> > (BTW -- feel free to submit pull requests at any point in a release >> > cycle -- we have both a master and a maintenance branch, so we can work >> > on new stuff and stable stuff at the same time). >> >> My first question is, how are these two branches related, because I've >> been submitting things against master, and then switching it to be against >> 1.2.x when I was asked. From what I have gathered, 1.2.x is for bugfixes, >> and master is for new features. >> > > That is correct. > >> >> Can someone clarify the current process, with a section like "Submitting >> new Pull Requests" - this should probably go into one of these places: >> http://matplotlib.org/devel/coding_guide.html >> http://matplotlib.org/devel/gitwash/index.html >> > > This is the essence of the gitwash process. Perhaps it needs to be clearer. > >> >> My second question is that, if I do have the right idea about the current >> process, and the distinction between master and 1.2.x, should we change >> this? (I think we should). >> >> The trouble is that it seems to me now for a bugfix, if it is submitted >> against 1.2.x, it won't be fixed in master until changes from 1.2.x are >> merged back into master. So now as a developer trying to follow "bleeding >> edge" matplotlib, I either have to live with bugs that have been fixed in >> 1.2.x if I want the features from master, or if I want the bug fixes and >> follow 1.2.x, I miss the new features in master. >> > > A general rule is that whoever merges a bugfix to the maintenance branch > should then also manually merge the maintenance branch down to master. > >> >> I think that the mental picture is sufficiently clearer if *everything* >> (bugfixes and new features) go into master, and then we backport the >> critical bugfixes against 1.2.x. This would be easier to do if the core >> developer merging the bugfix into master at least opens an issue for as a >> placeholder / reminder for the bugfix being a candidate to go into the >> maintenance branch. Because it seems like at this point, we aren't even sure >> if we're going to do a 1.2.1 release... >> > > There are other git workflows, which are all perfectly valid. If you can > convince us to use another, feel free to propose one. However, we have done > a couple of releases with gitwash, and it has worked quite well for us given > how small our maintenance overhead is. Just have to remember to regularly > merge the maintenance branch to master. That's all. Personally, I use this one: http://nvie.com/posts/a-successful-git-branching-model/ It does involve a little more effort, it does also mean that someone installing from the master branch (which is the default branch) will always get a stable release. My feeling is that the master branch shouldn't contain any unstable code. Also, it means that the user can just clone the git repository without having floating tarballs all over their home directory. I'm not necessarily proposing we should change it, I just wanted to point out a different approach. The git branching workflow we use for matplotlib is perfectly valid and I'm happy using it. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] New plot type idea -- EventRaster
On Mon, Nov 12, 2012 at 2:17 PM, Paul Ivanov wrote: > On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom wrote: >> On 11/11/2012 11:51 PM, Todd wrote: >>> Now that 1.2 is out, can we revisit this? I would like to get it >>> implemented for the next feature release. >>> >> >> Absolutely. I think the next step, once you have an implementation, >> would be to submit a pull request and we can all help with a review. > > This hasn't been mentioned yet, but Todd will hopefully find our > developer docs useful: > http://matplotlib.org/devel/index.html > > In particular, there's a section on writing a new pyplot function: > http://matplotlib.org/devel/coding_guide.html#writing-a-new-pyplot-function Thanks for that, Paul. Todd, there's also a section on writing tests for matplotlib on the page Paul pointed out. For a new feature there should be a couple of tests to go with it to make sure everything passes sanity checks. Thanks for spending your time contributing! -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Interpolation in a triangular mesh (tri.Triangulation)
On Thu, Nov 15, 2012 at 3:25 PM, Chris Barker wrote: > On Wed, Nov 14, 2012 at 1:50 AM, Ian Thomas wrote: > >> I think the code used to determine which triangle contains a certain point >> should be factored out into its own TriFinder class, > > +1 -- this is a generally useful feature. In fact, it would be nice if > a lot of this were in a pacakge that deals with triangular meshes, > apart from MPL altogether (a scikit maybe?) > >> I have a C++ TriFinder class >> that I could modify to work within matplotlib, and it is O(log N) so should >> be faster than your version for typical use cases. > > What algorithm does this use? Is the code open source and/or availabel > for other projects? I'm pretty sure there is an O(log n) algorithm in the Numerical Recipes book. It requires you to construct the triangulation in a specific way (this allows one to set up a tree data structure of triangles nicely). There may be others that I am not aware of though. > > I'm working on a package for working with unstructured grids in > general, and also have a use for "what triangle is this point in" code > for other purposes -- and I havne't found a fast, robust code for this > yet. > >>> particularly as only a few days ago I committed to writing a triangular grid >>> interpolator for quad grids > > what is a triangular interpolator for quad grids? sounds useful, too. > > -Chris > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > -- > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Matplotlib 'testing' page link broken
http://matplotlib.org/devel/coding_guide.html Scroll down to 'Testing'. Click 'Testing'. Boom. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib 'testing' page link broken
On Thu, Nov 22, 2012 at 6:23 AM, Phil Elson wrote: > Mike working his magic: > https://github.com/matplotlib/matplotlib.github.com/commits/master +1 for Mike magic. Happy Turkey Day to all my American friends! > > > On 22 November 2012 03:21, Paul Ivanov wrote: >> >> >> On Tue, Nov 20, 2012 at 2:21 PM, Damon McDougall >> wrote: >>> >>> http://matplotlib.org/devel/coding_guide.html >>> >>> Scroll down to 'Testing'. Click 'Testing'. Boom. >> >> >> seems to have been fixed now. The "Testing" link over at >> http://matplotlib.org/devel/coding_guide.html#testing takes me to >> http://matplotlib.org/devel/testing.html#testing >> >> -- >> Paul Ivanov >> 314 address only used for lists, off-list direct email at: >> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [PATCH] gtkagg backend leaks gc's.
On Sun, Nov 11, 2012 at 4:23 PM, Benjamin Root wrote:
>
>
> On Thursday, November 8, 2012, Carl Michal wrote:
>>
>> Hello,
>>
>> I noticed that a program I had that uses canvas.blit() to do animated
>> graphs
>> with the gtkagg backend was leaking memory.
>>
>> I tracked this down to gtk gc's being allocated in agg_to_gtk_drawable
>> with
>> gdk_gc_new(), but never being destroyed.
>>
>> The leak can be seen using the 'Animating selected plot elements' example
>> from:
>>
>> http://www.scipy.org/Cookbook/Matplotlib/Animations
>>
>> (if it is modified to run forever, rather than just 50 plots and also
>> changing numerix to numpy). After a few minutes, it is clear from ps that
>> the
>> memory usage is slowly but steadily climbing.
>>
>> Patch below (against matplotlib-1.1.1.) fixes it.
>>
>> Carl
>>
>> --- _gtkagg.cpp~2012-06-30 12:37:00.0 -0700
>> +++ _gtkagg.cpp 2012-11-08 14:30:23.0 -0800
>> @@ -121,6 +121,7 @@
>> destbuffer,
>> deststride);
>>
>> + gdk_gc_destroy(gc);
>> if (needfree)
>> {
>> delete [] destbuffer;
>>
>>
>>
>
> If you are willing, would you like to file a PR against the v1.2.x branch?
>
> Ben Root
Decided to follow-up on this and it looks like this patch has already
been applied.
--
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Travis numpy build failures on Python 3.x
We seem to have inherited these recently. I am questioning whether it is something caused by us or not. Can anybody build numpy/mpl under Python 3.x on their own machine successfully? -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Travis numpy build failures on Python 3.x
On Fri, Nov 30, 2012 at 4:25 PM, Damon McDougall wrote: > We seem to have inherited these recently. I am questioning whether it > is something caused by us or not. Can anybody build numpy/mpl under > Python 3.x on their own machine successfully? Looks like Jens found the problem: https://github.com/numpy/numpy/issues/2761 > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x
Forwarding to the list... -- Forwarded message -- From: Thomas Kluyver Date: Fri, Nov 30, 2012 at 4:35 PM Subject: Re: [matplotlib-devel] Travis numpy build failures on Python 3.x To: Damon McDougall On 30 November 2012 22:25, Damon McDougall wrote: > > We seem to have inherited these recently. I am questioning whether it > is something caused by us or not. Can anybody build numpy/mpl under > Python 3.x on their own machine successfully? The daily PPA builds are working fine: https://code.launchpad.net/~takluyver/+recipe/matplotlib-daily That uses the packaged version of numpy, though, rather than trying to pip install it. Thomas -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x
Forwarding to list again... -- Forwarded message -- From: Nathaniel Smith Date: Fri, Nov 30, 2012 at 5:13 PM Subject: Re: [matplotlib-devel] Travis numpy build failures on Python 3.x To: Damon McDougall On Fri, Nov 30, 2012 at 10:25 PM, Damon McDougall wrote: > We seem to have inherited these recently. I am questioning whether it > is something caused by us or not. Can anybody build numpy/mpl under > Python 3.x on their own machine successfully? Not your bug. Workaround: https://github.com/travis-ci/travis-cookbooks/issues/48#issuecomment-10843018 Also for context: https://github.com/numpy/numpy/issues/2761 https://github.com/pypa/virtualenv/issues/359 -n -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x
On Sat, Dec 1, 2012 at 12:28 PM, Michael Droettboom wrote: > Ok. I'll go ahead and put the workaround in our .travis.yml. Any > active pull requests that we want to have good Travis results for will > need to be rebased to get the workaround. That's better than having no testing at all for Python 3.x, so that gets my +1. Thanks Mike. > > Mike > > On 11/30/2012 06:20 PM, Damon McDougall wrote: >> Forwarding to list again... >> >> >> -- Forwarded message -- >> From: Nathaniel Smith >> Date: Fri, Nov 30, 2012 at 5:13 PM >> Subject: Re: [matplotlib-devel] Travis numpy build failures on Python 3.x >> To: Damon McDougall >> >> >> On Fri, Nov 30, 2012 at 10:25 PM, Damon McDougall >> wrote: >>> We seem to have inherited these recently. I am questioning whether it >>> is something caused by us or not. Can anybody build numpy/mpl under >>> Python 3.x on their own machine successfully? >> Not your bug. >> >> Workaround: >> >> https://github.com/travis-ci/travis-cookbooks/issues/48#issuecomment-10843018 >> >> Also for context: >>https://github.com/numpy/numpy/issues/2761 >>https://github.com/pypa/virtualenv/issues/359 >> >> -n >> >> > > > -- > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x
On Sat, Dec 1, 2012 at 12:56 PM, Damon McDougall wrote: > On Sat, Dec 1, 2012 at 12:28 PM, Michael Droettboom wrote: >> Ok. I'll go ahead and put the workaround in our .travis.yml. Any >> active pull requests that we want to have good Travis results for will >> need to be rebased to get the workaround. > > That's better than having no testing at all for Python 3.x, so that > gets my +1. Thanks Mike. Still failing even with the workaround. Here's proof: https://github.com/matplotlib/matplotlib/pull/1549 > >> >> Mike >> >> On 11/30/2012 06:20 PM, Damon McDougall wrote: >>> Forwarding to list again... >>> >>> >>> -- Forwarded message -- >>> From: Nathaniel Smith >>> Date: Fri, Nov 30, 2012 at 5:13 PM >>> Subject: Re: [matplotlib-devel] Travis numpy build failures on Python 3.x >>> To: Damon McDougall >>> >>> >>> On Fri, Nov 30, 2012 at 10:25 PM, Damon McDougall >>> wrote: >>>> We seem to have inherited these recently. I am questioning whether it >>>> is something caused by us or not. Can anybody build numpy/mpl under >>>> Python 3.x on their own machine successfully? >>> Not your bug. >>> >>> Workaround: >>> >>> https://github.com/travis-ci/travis-cookbooks/issues/48#issuecomment-10843018 >>> >>> Also for context: >>>https://github.com/numpy/numpy/issues/2761 >>>https://github.com/pypa/virtualenv/issues/359 >>> >>> -n >>> >>> >> >> >> -- >> Keep yourself connected to Go Parallel: >> INSIGHTS What's next for parallel hardware, programming and related areas? >> Interviews and blogs by thought leaders keep you ahead of the curve. >> http://goparallel.sourceforge.net >> _______ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x
On Sun, Dec 2, 2012 at 11:00 AM, Damon McDougall wrote: > On Sat, Dec 1, 2012 at 12:56 PM, Damon McDougall > wrote: >> On Sat, Dec 1, 2012 at 12:28 PM, Michael Droettboom wrote: >>> Ok. I'll go ahead and put the workaround in our .travis.yml. Any >>> active pull requests that we want to have good Travis results for will >>> need to be rebased to get the workaround. >> >> That's better than having no testing at all for Python 3.x, so that >> gets my +1. Thanks Mike. > > Still failing even with the workaround. Here's proof: > https://github.com/matplotlib/matplotlib/pull/1549 And looks like Thomas reported an issue too: https://github.com/matplotlib/matplotlib/issues/1548 > >> >>> >>> Mike >>> >>> On 11/30/2012 06:20 PM, Damon McDougall wrote: >>>> Forwarding to list again... >>>> >>>> >>>> -- Forwarded message -- >>>> From: Nathaniel Smith >>>> Date: Fri, Nov 30, 2012 at 5:13 PM >>>> Subject: Re: [matplotlib-devel] Travis numpy build failures on Python 3.x >>>> To: Damon McDougall >>>> >>>> >>>> On Fri, Nov 30, 2012 at 10:25 PM, Damon McDougall >>>> wrote: >>>>> We seem to have inherited these recently. I am questioning whether it >>>>> is something caused by us or not. Can anybody build numpy/mpl under >>>>> Python 3.x on their own machine successfully? >>>> Not your bug. >>>> >>>> Workaround: >>>> >>>> https://github.com/travis-ci/travis-cookbooks/issues/48#issuecomment-10843018 >>>> >>>> Also for context: >>>>https://github.com/numpy/numpy/issues/2761 >>>>https://github.com/pypa/virtualenv/issues/359 >>>> >>>> -n >>>> >>>> >>> >>> >>> ------ >>> Keep yourself connected to Go Parallel: >>> INSIGHTS What's next for parallel hardware, programming and related areas? >>> Interviews and blogs by thought leaders keep you ahead of the curve. >>> http://goparallel.sourceforge.net >>> ___ >>> Matplotlib-devel mailing list >>> Matplotlib-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> -- >> Damon McDougall >> http://www.damon-is-a-geek.com >> Institute for Computational Engineering Sciences >> 201 E. 24th St. >> Stop C0200 >> The University of Texas at Austin >> Austin, TX 78712-1229 > > > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Fwd: Travis numpy build failures on Python 3.x
On Sun, Dec 2, 2012 at 8:06 PM, Michael Droettboom wrote: > I've pushed a fix to v1.2.x and master for this new problem > (35ee2184111fb8f80027869d8ee309c7f4e5a467). Unfortunately, another rebase > of your branches is in order in order to get this fix. Still failing: https://travis-ci.org/matplotlib/matplotlib/jobs/3469141 > > Mike > > > On 12/02/2012 12:23 PM, Thomas Kluyver wrote: > > On 2 December 2012 17:02, Damon McDougall wrote: >> >> > Still failing even with the workaround. Here's proof: >> > https://github.com/matplotlib/matplotlib/pull/1549 >> >> And looks like Thomas reported an issue too: >> https://github.com/matplotlib/matplotlib/issues/1548 > > > This is a different problem, though (unless it's a really bizarre symptom of > the other problem). Now it's an error in compiling matplotlib. > > Thomas > > -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Experiments in removing/replacing PyCXX
On Mon, Dec 3, 2012 at 12:12 PM, Chris Barker - NOAA Federal wrote: > generated code is ugly and hard to maintain, it is not designed to be > human-readable, and we wouldn't get the advantages of bug-fixes > further development in Cython. As far as I'm concerned, this is an argument against Cython. I've had to touch the C/C++/ObjC codebase. It was not automatically generated by Cython and it's not that hard to read. There's almost certainly a C/C++/ObjC expert around to help out. There's almost certainly Cython experts to help out, too. There is almost certainly *not* an expert in Cython-generated C code that is hard to read. I vote raw Python/C API. Managing reference counters is not the mundane task pythonistas make it out to be, in my opinion. If you know ObjC, you've had to do your own reference counting. If you know C, you've had to do your own memory management. If you know C++, you've had to do your own new/delete (or destructor) management. I agree not having to worry about reference counting is nice positive, but I don't think it outweighs the negatives. It seems to me that Cython is a 'middle-man' tool, with the added downside of hard-to-maintain under-code. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] GitHub attachments
Did everyone see that GitHub now allows attachments in issue comments? IMO, this is awesome. Attaching a visual *thing* of output when users get unexpected results from plotting calls is a massive plus. Drag and drop right into the browser, too! No more having to upload a file to imgur or dropbox and link it to the issue comment and then have it disappear when you delete it and forgot it was linked to GitHub. Win. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Sat, Dec 15, 2012 at 5:24 PM, Michael Droettboom wrote: > On 12/14/2012 02:25 PM, Todd wrote: > > > On Dec 14, 2012 5:59 PM, "Michael Droettboom" wrote: >> >> Github has removed the ability to host binaries. They've removed this >> feature without any apparent notification except on their blog saying "it's >> gone today". And the suggested alternative is to use paid services. >> >> https://github.com/blog/1302-goodbye-uploads >> >> I had planned to complete our set of 1.2.0 binaries with a Python 3.2 from >> Russell Owen in the near future. So much for that. >> >> Any thoughts? Do we go back to Sourceforge for our download hosting? Is >> anyone familiar with any other services? Do we try to piggy-back on what >> other scipy projects are doing? >> >> Mike >> > > Is there a reason pypi is not usable? > > PyPI doesn't support large enough files. (I'm not sure what the limit is, > but I've hit it every time). We have always hosted our files elsewhere and > then just had PyPI point to them. > > Mike This seems like a pretty big minus, especially considering the work you and others have put in migrating everything over from Sourceforge. Do you think it would be worth contacting the GitHub folks about this? I'm not sure what I'm trying to achieve. I guess I'd like them to realise that GitHub Downloads were a really useful feature and their reasons for removing it without deprecation of the GitHub Uploads process has made the distribution of matplotlib more confusing for our users. Perhaps it's better just to move on... I've been (un?)fortunate enough to never have to use Sourceforge's interface. If it's the case it's not intuitive then I like Nathaniel's idea of hosting the binaries on Google Code. The downside of this, of course, is that matplotlib is then spread across three different services: Sourceforge for the mailing list; GitHub for the source and development; and Google Code for the binaries. Maybe the best thing is to host the binaries on Sourceforge. To be honest, I'm not sure that the service that hosts the binaries matters all that much. We could put links to the binaries on the webpage and then it's completely transparent to the user. Sorry for the stream of conscience. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Sat, Dec 15, 2012 at 5:47 PM, Thomas Kluyver wrote: > On 15 December 2012 23:38, Damon McDougall > wrote: >> >> Maybe the best thing is to host the binaries on Sourceforge. > > > Having recently tried to do it, Sourceforge tries really hard to avoid > giving you a direct link that can repeatably be used to download a file > automatically, i.e. without a browser. In the case I was after it for, I > ended up downloading the file (a PyWin32 binary) with a browser, and storing > it on the CI server that I wanted to install it. Thanks for that information, Thomas. I conclude hosting the binaries on Sourceforge and just linking to them from the mpl website is not feasible. Unless, of course, there is resistance to the idea of linking to them from the website. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout wrote: > On 12/14/12 10:55 AM, Nathaniel Smith wrote: >> sourceforge's horror of an interface. > > I'll second that. Every time I go to Sourceforge, I have to figure out > how in the world to download what I want (and I have to figure out which > things *not* to click on too). Ok sounds like there is a reasonable amount of resistance towards Sourceforge. Eric, when you suggest that NumFocus could 'provide hosting directly', do you mean they would have the physical hardware to host the files, or are you suggesting they provide the finances to seek hosting elsewhere? In the GitHub blog post, they suggest using S3. We could try that. It's fairly inexpensive and the first year is free (within monthly bandwidth limits). We could try it for a year and see how that pans out? I'm not entirely sure how the Amazon stuff works but I've heard good things about it. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Sun, Dec 16, 2012 at 1:38 PM, Todd wrote: > On Sun, Dec 16, 2012 at 8:21 PM, Damon McDougall > wrote: >> >> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> wrote: >> > On 12/14/12 10:55 AM, Nathaniel Smith wrote: >> >> sourceforge's horror of an interface. >> > >> > I'll second that. Every time I go to Sourceforge, I have to figure out >> > how in the world to download what I want (and I have to figure out which >> > things *not* to click on too). >> >> Ok sounds like there is a reasonable amount of resistance towards >> Sourceforge. >> >> Eric, when you suggest that NumFocus could 'provide hosting directly', >> do you mean they would have the physical hardware to host the files, >> or are you suggesting they provide the finances to seek hosting >> elsewhere? >> >> In the GitHub blog post, they suggest using S3. We could try that. >> It's fairly inexpensive and the first year is free (within monthly >> bandwidth limits). We could try it for a year and see how that pans >> out? I'm not entirely sure how the Amazon stuff works but I've heard >> good things about it. >> >> > Are you sure the monthly bandwidth limits are sufficient? > > Also, have you talked to the pypi people about making exceptions for really > popular projects? If critical packages like numpy, scipy, and matplotlib > cannot use pypi, that seems like a major failing of the system. Here's the pricing: http://aws.amazon.com/s3/#pricing. The free tier programme limits are on there too. Unfortunately, I do not have the knowledge to be able to say whether we would hit that or not. Matt, have you had experienced comitting binaries to the gh-pages branch? Are there size limits? -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Sun, Dec 16, 2012 at 2:44 PM, Eric Firing wrote: > On 2012/12/16 9:21 AM, Damon McDougall wrote: >> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >> wrote: >>> On 12/14/12 10:55 AM, Nathaniel Smith wrote: >>>> sourceforge's horror of an interface. >>> >>> I'll second that. Every time I go to Sourceforge, I have to figure out >>> how in the world to download what I want (and I have to figure out which >>> things *not* to click on too). >> >> Ok sounds like there is a reasonable amount of resistance towards >> Sourceforge. >> >> Eric, when you suggest that NumFocus could 'provide hosting directly', >> do you mean they would have the physical hardware to host the files, >> or are you suggesting they provide the finances to seek hosting >> elsewhere? > > I was thinking that perhaps NumFocus would be running a server that > could provide the hosting. Funding for an external service is also > possible, though, and might make more sense. > >> >> In the GitHub blog post, they suggest using S3. We could try that. >> It's fairly inexpensive and the first year is free (within monthly >> bandwidth limits). We could try it for a year and see how that pans >> out? I'm not entirely sure how the Amazon stuff works but I've heard >> good things about it. >> > > The github page https://github.com/matplotlib/matplotlib/downloads shows > 44,000 downloads for the 1.2 tarball, so I don't think the 20,000 > downloads per month limit of the free tier would work. Note: that's 44,000 downloads for a gzipped bundle of the *source*, which can still be downloaded via the "Tags" tab (https://github.com/matplotlib/matplotlib/tags). Any time one of us creates a tag, GitHub automagically tar/gzips it and makes it downloadable. As far as I am aware, this is separate to the "Downloads" section, which is for arbitrary files of any type, not just source tarballs. That said, not taking into account the downloads of the tarball, we're still pretty close to the 20,000 mark. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Mon, Dec 17, 2012 at 8:10 AM, Michael Droettboom wrote: > On 12/16/2012 03:44 PM, Eric Firing wrote: >> On 2012/12/16 9:21 AM, Damon McDougall wrote: >>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >>> wrote: >>>> On 12/14/12 10:55 AM, Nathaniel Smith wrote: >>>>> sourceforge's horror of an interface. >>>> I'll second that. Every time I go to Sourceforge, I have to figure out >>>> how in the world to download what I want (and I have to figure out which >>>> things *not* to click on too). >>> Ok sounds like there is a reasonable amount of resistance towards >>> Sourceforge. >>> >>> Eric, when you suggest that NumFocus could 'provide hosting directly', >>> do you mean they would have the physical hardware to host the files, >>> or are you suggesting they provide the finances to seek hosting >>> elsewhere? >> I was thinking that perhaps NumFocus would be running a server that >> could provide the hosting. Funding for an external service is also >> possible, though, and might make more sense. > > I'll definitely walk down the hall and talk to my local Numfocus board > member ;) At the 6th Annual Scientific Software Day here at UT Austin, I met and spoke to Travis Oliphant regarding funding for hosting our binaries. Travis has links with NumFOCUS and was eager to help the matplotlib community host binaries should we choose to not go with sourceforge or another free option. I'll need touch base with him again to get specifics, but I thought I'd just let everyone here know that that's still an option. To be honest with you, I'm thinking that if we only want to link to binaries from the matplotlib web page then sourceforge really doesn't sound like a bad option at all. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Github Downloads going away...
On Sun, Dec 23, 2012 at 2:24 PM, Nathaniel Smith wrote: > On Sun, Dec 23, 2012 at 12:42 AM, Damon McDougall > wrote: >> On Mon, Dec 17, 2012 at 8:10 AM, Michael Droettboom wrote: >>> On 12/16/2012 03:44 PM, Eric Firing wrote: >>>> On 2012/12/16 9:21 AM, Damon McDougall wrote: >>>>> On Sat, Dec 15, 2012 at 8:25 PM, Jason Grout >>>>> wrote: >>>>>> On 12/14/12 10:55 AM, Nathaniel Smith wrote: >>>>>>> sourceforge's horror of an interface. >>>>>> I'll second that. Every time I go to Sourceforge, I have to figure out >>>>>> how in the world to download what I want (and I have to figure out which >>>>>> things *not* to click on too). >>>>> Ok sounds like there is a reasonable amount of resistance towards >>>>> Sourceforge. >>>>> >>>>> Eric, when you suggest that NumFocus could 'provide hosting directly', >>>>> do you mean they would have the physical hardware to host the files, >>>>> or are you suggesting they provide the finances to seek hosting >>>>> elsewhere? >>>> I was thinking that perhaps NumFocus would be running a server that >>>> could provide the hosting. Funding for an external service is also >>>> possible, though, and might make more sense. >>> >>> I'll definitely walk down the hall and talk to my local Numfocus board >>> member ;) >> >> At the 6th Annual Scientific Software Day here at UT Austin, I met and >> spoke to Travis Oliphant regarding funding for hosting our binaries. >> Travis has links with NumFOCUS and was eager to help the matplotlib >> community host binaries should we choose to not go with sourceforge or >> another free option. >> >> I'll need touch base with him again to get specifics, but I thought >> I'd just let everyone here know that that's still an option. >> >> To be honest with you, I'm thinking that if we only want to link to >> binaries from the matplotlib web page then sourceforge really doesn't >> sound like a bad option at all. > > Or -- I'll just point this out one more time then leave the dead horse > alone :-) -- you could just register a project called > 'matplotlib-downloads' on google code hosting, and have static URLs > that look like e.g. > https://apa6e.googlecode.com/files/apa6e-v0.3.zip > and let Google foot the bill for reliable high-bandwidth CDN hosting. > > -n Thanks for reminding us about the google code option. Since there are quite a lot of suggestions I've used this opportunity to write a short summary of the options presented in this thread: Google Code: Free. Interface is better than sourceforge. Sourceforge: Free. Ugly. May not need interface if hotlinking to binaries from the website. PyPI: Free. Size quota too small. Will link to external files. S3: Free and not free. We're over the free tier quota. NumFOCUS can potentially fund the non-free tier (cost is circa $200/mo). I thought it was $200/yr. IMO $200/mo is very expensive. gh-pages: We're already over the size limit for this branch. new gh repo: Free. 1GB of space. https://help.github.com/articles/what-is-my-disk-quota. Will hold about 4 releases? Dropbox: Free 2GB account. Can hotlink to binaries. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Requiring numpy requirement to 1.5 on master?
On Fri, Jan 11, 2013 at 12:33 PM, Eric Firing wrote: > On 2013/01/11 5:38 AM, Michael Droettboom wrote: >> As pointed out in #1650, we have a bug on Python 3.x handling file-like >> objects that are UNIX FILEs, but not actual filesystem files, such as >> the sockets used for a urllib HTTP request. >> >> https://github.com/matplotlib/matplotlib/pull/1650 >> >> As Christoph helpfully points out, Numpy has already solved this problem >> (since 1.5.0), so it would be easiest to just use their solution. >> >> For 1.2.x, I think we shouldn't update the Numpy requirement (which is >> currently 1.4) -- there, I'll have to port Numpy's compatibility >> functions to our code base. But for master, I'd rather just use Numpy's >> stuff so all of the intricacies of this are handled in one place. >> >> (And as a detail, it isn't until Numpy 1.7 that a "CloseFile" function >> is provided, so even on master, we're stuck copying some code over). >> >> Any objections? Nope. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] PR #1599
On Thu, Jan 10, 2013 at 7:40 AM, Michael Droettboom wrote: > Alternatively, maybe we could divide the open PRs into numerical ranges > amongst some volunteers, who could triage and assign them to the attention > of the appropriate experts? I like this idea. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Usefulness of Travis-CI
On Wed, Jan 16, 2013 at 10:54 AM, Todd wrote: > On Jan 16, 2013 9:30 AM, "Fernando Perez" wrote: >> >> On Wed, Jan 16, 2013 at 12:10 AM, Nelle Varoquaux >> wrote: >> >> > Last but not least, maybe we can see what numfocus has to offer. >> >> Absolutely! I'll be offline for two weeks, but others on the list can >> certainly propose this to numfocus on the list and we can look into >> what can be done, esp. in a way that could also help other projects as >> well. >> >> Also, there's snakebite: http://www.snakebite.net. The project seemed >> very dormant for a long time, but there's been some activity since: >> http://www.snakebite.net/network. I'd ping Titus Brown on Twitter >> (@ctitusbrown) for info... >> >> Cheers, > > There is also the open build service, which is more of a build farm but can > be set up pull, build, test, and publish git snapshots for most common Linux > distributions to your own online software repository simultaneously with one > click on a website or one commandline call. > > https://build.opensuse.org/ > > They provide hosting, building, and distribution for free. You can probably > set up a script to automatically rebuild master on a change, or daily. > However, setting it up to test individual commits would be overly difficult > and probably be seen as an abuse of the system. Using it to always build, > test, and release offer the latest master to most linux distros, on the > other hand, would be fine. If someone contacts them they can probably set > up a repository just for you, or if this sort of thing is useful a more > general repository you can share with others (there is already > devel:languages:python, maybe devel:languages:python:unstable). > > You can also use it to build release rpms and debs for various distros. It > is already being used to build the packages discussed so far for openSUSE, > but if someone is willing to maintain them they can be built for other > distros as well. GitHub allow for a custom service-hook. If, as Mike says, it's not too hard to garner compute cycles, it shouldn't be too hard to write a small script to execute the test suite when the github repo receives a push. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib in daily life
On Mon, Jan 21, 2013 at 11:44 AM, Ryan May wrote: > Hi, > > Just ran across this article that shows a familiar looking graph. Just > another encounter of matplotlib in daily life. > > http://www.wired.com/wiredenterprise/2013/01/google-password/2/ Here's another one, too: http://www.wired.com/wiredscience/2013/01/why-are-lego-sets-expensive/ Maybe the next wired article will use the SVG backend :) > > Ryan > > > -- > Ryan May > Graduate Research Assistant > School of Meteorology > University of Oklahoma > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122412 > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errorbar - end bars not visible
On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker wrote: > Simple example: the bars on the two x axis ends are not visible. > > x = [3, 6, 10] > y = [1, 2, 3] > import matplotlib.pyplot as plt > > plt.errorbar (x, y, 0.2) Try adding a plt.xlim(2, 11) here. > plt.show() > > > > -- > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errorbar - end bars not visible
On Sun, Jan 27, 2013 at 11:51 AM, Neal Becker wrote: > Damon McDougall wrote: > >> On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker >> wrote: >>> Simple example: the bars on the two x axis ends are not visible. >>> >>> x = [3, 6, 10] >>> y = [1, 2, 3] >>> import matplotlib.pyplot as plt >>> >>> plt.errorbar (x, y, 0.2) >> >> Try adding a plt.xlim(2, 11) here. >> >>> plt.show() >>> > Yes that'll fix it - but ideally autoscaling should work correctly. That behaviour of autoscale appears to be consistent with plt.plot(range(3)), for example. That is, the axis limits butt up against the plotted data. By 'work correctly', do you mean that the axis limits should be padded so there is a whitespace border surrounding the data being plotted? -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] errorbar - end bars not visible
On Sun, Jan 27, 2013 at 12:28 PM, Neal Becker wrote: > Damon McDougall wrote: > >> On Sun, Jan 27, 2013 at 11:51 AM, Neal Becker >> wrote: >>> Damon McDougall wrote: >>> >>>> On Sun, Jan 27, 2013 at 8:56 AM, Neal Becker >>>> wrote: >>>>> Simple example: the bars on the two x axis ends are not visible. >>>>> >>>>> x = [3, 6, 10] >>>>> y = [1, 2, 3] >>>>> import matplotlib.pyplot as plt >>>>> >>>>> plt.errorbar (x, y, 0.2) >>>> >>>> Try adding a plt.xlim(2, 11) here. >>>> >>>>> plt.show() >>>>> >>> Yes that'll fix it - but ideally autoscaling should work correctly. >> >> That behaviour of autoscale appears to be consistent with >> plt.plot(range(3)), for example. That is, the axis limits butt up >> against the plotted data. >> >> By 'work correctly', do you mean that the axis limits should be padded >> so there is a whitespace border surrounding the data being plotted? >> > > I think you'll agree the original result in not visually appealing or clear. > The most obvious way to improve it would be to select axis limits a bit > larger. > At least large enough to completely show the error bar; I suspect a bit of > whitespace would be even more clear. Indeed, I do agree. I have actually changed my mind about this behaviour being consistent with plt.plot. I feel like the 'feet' on the error bars should be taken into account during the autoscaling procedure. This will result in the autoscaling procedure adding a small amount of whitespace such that the feet are then visible after a call to plt.show(). I have opened a new issue on our github issue tracker. See https://github.com/matplotlib/matplotlib/issues/1711 Thanks for reporting the problem, Neal. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Financial support for continuous integration
On Wed, Jan 30, 2013 at 8:44 AM, Michael Droettboom wrote: > In discussions with Perry Greenfield at STScI, it seems we are in the > position of being able to get some financial support to pay for a > continuous integration system. > > Travis has shown itself to be rather glitchy for matplotlib. The tight > integration with Github PRs is really convenient. However, matplotlib > has longer test runs and more dependencies than many projects. The > frequent false positives start to wear down at a certain point. And we > still aren't testing everything because we can't aren't installing > Inkscape and other things in the Travis VM. > > So we're looking to add another paid, hosted continuous integration > service that will better meet our needs. A hosted service is nice > because it's easy to give multiple developers access to the system so > anyone can tweak it and keep it going -- the bottleneck of a single > developer responsible for maintenance of the build machine was a problem > years ago when we were using buildbot. This may remain "in addition to" > rather than "instead of" Travis for some time. > > An obvious first choice to me is ShiningPanda, as I have experience > using it for astropy. Jenkins (the software Shining Panda is based on), > is a really easy-to-use system, for those not familiar with it. And we > can store the output of the tests (i.e. the result_images) for later > inspection. I think this feature alone is huge for matplotlib. They > also offer Windows build slaves. There is no OS-X (probably because > Apple licensing doesn't really allow for use in a VM), but results can > be "published" to their Jenkins instance. > > Are there any other similar alternatives we should consider before we > move forward? > > Mike I think hosted infrastructure is the right choice. I was initially going to suggest that we try and work with a bespoke solution. That way we could roll our own build architectures. On reflection I think the maintenance headache of managing our own build slaves outweighs the convenience of having it hosted, as you point out. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem compiling matplotlib from master
On Thu, Feb 28, 2013 at 11:24 AM, Nelle Varoquaux wrote: > Hello, > > Since I've updated my master branch, I have a new error when installing > matplotlib. It seems it doesn't find a header file from numpy: > > I've reinstalled numpy (development version), and I tried to reinstall > everything (on python 2.6) but I still get the error. Am I the only one > having installation problems ? > > Here is the (partial) traceback: > > building 'matplotlib._png' extension > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -fPIC > -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 > -I/usr/local/include -I/usr/include -I. -I/usr/include/libpng12 > -I/usr/lib/pymodules/python2.6/numpy/core/include -I/usr/include/python2.6 > -c src/_png.cpp -o build/temp.linux-x86_64-2.6/src/_png.o > In file included from src/_png.cpp:31: > src/file_compat.h:4:32: error: numpy/npy_3kcompat.h: No such file or > directory > In file included from src/_png.cpp:31: > src/file_compat.h: In function ‘int npy_PyFile_CloseFile(PyObject*)’: > src/file_compat.h:125: warning: deprecated conversion from string constant > to ‘char*’ > src/_png.cpp: In member function ‘Py::Object _png_module::write_png(const > Py::Tuple&)’: > src/_png.cpp:137: error: ‘npy_PyFile_OpenFile’ was not declared in this > scope > src/_png.cpp:147: error: ‘npy_PyFile_Dup’ was not declared in this scope > src/_png.cpp:243: error: ‘npy_PyFile_DupClose’ was not declared in this > scope > src/_png.cpp:264: error: ‘npy_PyFile_DupClose’ was not declared in this > scope > src/_png.cpp: In member function ‘PyObject* _png_module::_read_png(const > Py::Object&, bool, int)’: > src/_png.cpp:321: error: ‘npy_PyFile_OpenFile’ was not declared in this > scope > src/_png.cpp:329: error: ‘npy_PyFile_Dup’ was not declared in this scope > src/_png.cpp:577: error: ‘npy_PyFile_DupClose’ was not declared in this > scope > error: command 'gcc' failed with exit status 1 > > Thanks, > N > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > That's weird. Did you try installing a stable numpy version instead? I tried compiling mpl against numpy 1.6.2 and everything worked out fine. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] eps with usetex=False broken icw Ghostscript 9.07?
On Mon, Mar 4, 2013 at 6:44 AM, David Verelst wrote:
>
> sorry...forgot to tag the subject as [matplotlib-devel]
The server does it for you.
>
> On 4 March 2013 13:35, David Verelst wrote:
>>
>> Hi,
>>
>> I am running Arch Linux, Matplotlib 1.2, Python 2.7, and today I realized
>> that generating *.eps figures when matplotlib is using the latex output
>> rc('text', usetex=True) results in a corrupted eps figure in combination
>> with Ghostscript 9.07. The png variant of the same figure works fine, eps
>> works fine if usetex=False. Everything works fine when I downgrade back to
>> Ghostscript 9.06.
>>
>> Is this related to this?
>> https://github.com/matplotlib/matplotlib/issues/1693
>> https://github.com/matplotlib/matplotlib/pull/1694
>> If it is, I guess the problem is already solved. Haven't tested that yet
>> (need to build matplitlib from git first...)
>>
>> I have no idea if this is Arch Linux packaging, Ghostscript or Matplotlib
>> issue...hence this email.
>>
>> Regards,
>> David
>>
>>
>> An example, from: http://matplotlib.org/users/usetex.html
>>
>> #!/usr/bin/env python
>> """
>> You can use TeX to render all of your matplotlib text if the rc
>> parameter text.usetex is set. This works currently on the agg and ps
>> backends, and requires that you have tex and the other dependencies
>> described at http://matplotlib.sf.net/matplotlib.texmanager.html
>> properly installed on your system. The first time you run a script
>> you will see a lot of output from tex and associated tools. The next
>> time, the run may be silent, as a lot of the information is cached in
>> ~/.tex.cache
>>
>> """
>> from matplotlib import rc
>> from numpy import arange, cos, pi
>> from matplotlib.pyplot import figure, axes, plot, xlabel, ylabel, title, \
>> grid, savefig, show
>>
>>
>> rc('text', usetex=True)
>> rc('font', family='serif')
>> figure(1, figsize=(6,4))
>> ax = axes([0.1, 0.1, 0.8, 0.7])
>> t = arange(0.0, 1.0+0.01, 0.01)
>> s = cos(2*2*pi*t)+2
>> plot(t, s)
>>
>> xlabel(r'\textbf{time (s)}')
>> ylabel(r'\textit{voltage (mV)}',fontsize=16)
>> title(r"\TeX\ is Number
>> $\displaystyle\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$!",
>> fontsize=16, color='r')
>> grid(True)
>> savefig('tex_demo.eps')
>> savefig('tex_demo.png')
>>
>> show()
>>
>>
>> When converting the eps figure with imagemagick (just to check the file),
>> the following error is given:
>> $ convert Desktop/tex_demo.eps ddd.eps
>> Error: /dictstackunderflow in --end--
>> Operand stack:
>>
>> Execution stack:
>>%interp_exit .runexec2 --nostringval-- --nostringval--
>> --nostringval-- 2 %stopped_push --nostringval-- --nostringval--
>> --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop
>> 1899 1 3 %oparray_pop --nostringval-- 1883 1 3 %oparray_pop
>> 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2
>> --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push
>> --nostringval--
>> Dictionary stack:
>>--dict:1169/1684(ro)(G)-- --dict:0/20(G)-- --dict:82/200(L)--
>> Current allocation mode is local
>> Last OS error: No such file or directory
>> Current file position is 102614
>> GPL Ghostscript 9.07: Unrecoverable error, exit code 1
>> Error: /dictstackunderflow in --end--
>> Operand stack:
>>
>> Execution stack:
>>%interp_exit .runexec2 --nostringval-- --nostringval--
>> --nostringval-- 2 %stopped_push --nostringval-- --nostringval--
>> --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop
>> 1899 1 3 %oparray_pop --nostringval-- 1883 1 3 %oparray_pop
>> 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2
>> --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push
>> --nostringval--
>> Dictionary stack:
>>--dict:1169/1684(ro)(G)-- --dict:0/20(G)-- --dict:82/200(L)--
>> Current allocation mode is local
>> Last OS error: No such file or directory
>> Current file position is 102614
>> GPL Ghostscript 9.07: Unrecoverable error, exit code 1
>> convert: Postscript delegate failed `Desktop/tex_demo.eps': No such file
>&
Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)
On Thu, Mar 7, 2013 at 9:24 AM, Benjamin Root wrote: > > > On Thu, Mar 7, 2013 at 10:12 AM, Michael Droettboom wrote: >> >> Ah, yes. I forgot that my issues with trying to do rendering in the >> browser shared some similarities here. >> >> When I did the last major backend refactoring (which is coming on 6 >> years ago now), I considered exactly this, which is why draw_path takes >> both a path object (which is unlikely to change) and a transform. It >> turned out to not be terribly useful for most the backends we have, >> since PDF, PS, SVG (at least in the versions of the specs we're using) >> all scale the stroke width along with the vertices, so you couldn't, for >> example, zoom in on a line plot without the line width exploding. The >> Agg backend is able to perform the transform itself since we wrote it to >> not scale the stroke using the path's transform, but there's little >> advantage since it's all software anyway. But the API still works this >> way even if nothing takes advantage of it. Though technically paths are >> mutable, since they store Numpy arrays which are mutable, in practice >> they are rarely if never mutated (I'll have to verify this, but >> certainly in the course of panning and zooming, they wouldn't be), so it >> should be possible to know whether a path is already on the GPU by >> checking its id against a table of what's on the GPU. >> >> The other wrinkle is that the transform is a combination of affine >> transforms (which I'm sure OpenGL handles just fine) with arbitrary >> transforms such as log scaling or polar transformations. I assume this >> would all have to be implemented as a vertex shader to get the >> performance benefits of OpenGL. We could probably implement all of the >> transforms built in to matplotlib (which cover a lot of cases), and then >> just provide some slow "escape route" to handle arbitrary transforms >> written in Numpy/Python, and for bonus points provide a hook for users >> to add their own OpenGL transforms (just as it would have been necessary >> to do with Javascript in the case of web browser rendering). But I bet >> a lot of people would be happy as a start to just have the built-in >> transforms working. >> >> The last thing to raise is the case of very large data. When I was >> investigating rendering in a web browser, there were pretty low limits >> to the number of vertices I could keep hold of in the browser. >> matplotlib has a "path simplification" algorithm to reduce the number of >> vertices without changing the appearance of the plot, but of course >> that's dependant on the scale, so it has to be rerun every time the >> scale changes. While path simplification may not be as necessary for >> speed on the GPU, it may be necessary due to memory constraints. >> >> Mike >> > > Just to voice what my main interest in an OpenGL backend is a chance to move > away from the layering approach of the matplotlib renderer to the ability to > specify three dimensional data to plot. Performance is a nice side-benefit, > certainly, but breaking out our low-level assumptions of how we plot would > be refreshing. I agree here. I would certainly benefit from this. I'm really lost when it comes to how to could optimise our rendering, especially with text rendering being extremely slow at present. I am, however, a little concerned we may be reinventing the wheel here with useful tools that already exist for 3d rendering. Paraview and MayaVi come to mind. > > Ben Root > > > -- > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.1rc1 Tagged
On Thu, Mar 7, 2013 at 1:30 PM, Michael Droettboom wrote: > Packagers: I don't expect a lot of glitches as nothing significant has > changed about the build since 1.2.0, but now is the best time to try to > build for your various packaging systems and report back any problems. Ryan, if you're out there, let me know if you run into snags with building for the Mac. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] SciPy 2013
On Fri, Mar 22, 2013 at 12:11 PM, Nelle Varoquaux wrote: > > > > On 22 March 2013 18:06, Michael Droettboom wrote: >> >> On 03/22/2013 12:45 PM, Nelle Varoquaux wrote: >> >> >>> I'm hoping to host a matplotlib sprint during the final two days of Scipy >>> 2013 this year, and I hope to see as many as possible of you there. I think >>> it's also really important to bring new developers into sprints, because >>> it's such an efficient way to get people familiar with the code base. Awesome idea. I am for sure in. In fact, I work in Austin now; it'd be great to actually meet some of you in person. We should share some breakfast tacos or interior Mexican food! >> Being in Europe, it is very unlikely I'll come to Scipy this year, but I >> think it is a great idea to organize a sprint during this period. >> >> >> I'll also try to set up some sort of remote communication tool (such as >> Google Hangouts, or even just IRC) so that people can "participate" in the >> sprint remotely. > > > There's a #matplotlib chanel on irc, where a dozen people hang out. That > could be a nice place to gather people during the sprint. Is this on freenode? I joined it yesterday to scope it out but it was pretty quiet. > >> >> >> >> >>> >>> It might be helpful to start brainstorming now about which projects we >>> may want to tackle so that we can have as much in place as possible by then >>> and hit the ground running. >> >> >> One of the things I think would be great to tackle is the replacement of >> the Travis bot. Ideally, I'd like to see a pep8 check of each patch and a >> daily build of the documentation on master in addition of the tests. >> >> >> Agreed. That's definitely on my todo list. We've got some funding >> through my employer to pay for continuous integration hosting -- it's just >> taking a while to work its way through the system. Once we have some sort >> of paid hosting system, we should be able to do a lot more than Travis >> currently can. >> >> Mike >> >> >> >>> >>> >>> I've set up a wiki page here: >>> >>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013 I have edited the Wiki to confirm my attendance. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
