We still require only gtk 2.2, and consequently carry around some extra
chunks of code to support versions before 2.4. Can we drop this and
require 2.4 or later? Or possibly even a later version? It looks like
2.4 came out in the fall of 2004.
Eric
--
Michael Droettboom wrote:
> I'm +1 on dropping support for gtk+ < 2.4 (if even later). Those
> multiple code paths were a pain, and installing multiple versions of
> gtk+ for testing is also something I'd like to stop doing.
>
> Cheers,
> Mike
Done.
Eric
>
Andrew Straw wrote:
> Thanks everyone for the feedback. I have made Spine subclass Patch in
> svn r7170, which I just committed. This resulted in a slight API
> change, but addresses most of the more substantial points raised.
>
> The slight API change is that spine.set_color() is now
> spine.set
Jouni K. Seppänen wrote:
> The current pyplot wrappers all have an argspec of (*args, **kwargs),
> which means that any interactive tools that show the possible arguments
> will not be able to show anything very useful for the wrapped functions.
> Also, since the docstrings are generated dynamicall
>> And now that we're talking about this, Eric, as the only MPL dev that I
>> know who prefers Hg over git, have you seen
>> http://github.com/blog/439-hg-git-mercurial-plugin and would you be
>> willing to try it out? I'd be very interested to know if it could make a
>> git central repo work seam
Andrew Straw wrote:
> Jouni K. Seppänen wrote:
>
>> I coded up what I think is an improvement, but since it has a lot of
>> potential to break something and release time is near, I didn't commit
>> my changes into svn. I tried playing around with git, to see if it is
>> useful for communicating pa
Ray Speth wrote:
> I believe I have found a simple change that improves the rendering speed
> of quiver plots, which can be quite slow for large vector fields. Based
> on some profiling, the problem appears to stem from the use of numpy's
> MaskedArrays in PolyCollection.set_verts. If I add the
Gael Varoquaux wrote:
> It seems that matplotlib needs the following patch for wxPython 2.8
> (traceback hard to replicate, as you need to import wx before importing
> matplotlib):
>
> Index: lib/matplotlib/backends/backend_wx.py
> ==
Gael Varoquaux wrote:
> On Fri, Jul 10, 2009 at 08:12:14AM -1000, Eric Firing wrote:
>> Gael Varoquaux wrote:
>>> It seems that matplotlib needs the following patch for wxPython 2.8
>>> (traceback hard to replicate, as you need to import wx before importing
>>
Gael Varoquaux wrote:
> On Fri, Jul 10, 2009 at 11:05:24PM +0200, Gael Varoquaux wrote:
>>> Committed to svn. Please check it.
>
>> Certainly does work betters.
>
> Actually, I beg your pardon, but it does not really work: if you have
> 2.6 and 2.8 installed, it will still import 2.6, which is
Gael Varoquaux wrote:
> On Sat, Jul 11, 2009 at 08:10:23AM -1000, Eric Firing wrote:
>> OK, I tried again in svn 7256. I think this is a little cleaner. More
>> diagnostic information could still be added to the exception messages if
>> this is going to be a continuing p
Gael Varoquaux wrote:
> On Sat, Jul 11, 2009 at 12:49:03PM -0500, John Hunter wrote:
>>> Can you do an 'import wxversion; print wxversion.__file__', so that we
>>> understand better why you are getting these warnings.
>
>> In [1]: import wxversion
>
>> In [2]: print wxversion.__file__
>> /Library
Rob Clewley wrote:
> I wrote a wrapper to do this for my own code because I wanted it so
> much. I can't see why it would be a problem to support, it's only one
> extra if statement.
>
> +1 from me!
Done in svn 7294.
Eric
>
> On Sat, Jul 25, 2009 at 1:16 AM, Jan Müller wrote:
>> basically thi
In svn 7298 I changed a key chunk of code that was working fine, so I
would like to explain why I fixed it when it wasn't broken, and ask for
review and testing, or at least keeping your eyes open for anything I
may have overlooked.
In the course of making the very simple change to support scal
Ray Speth wrote:
> I believe I have found a simple change that improves the rendering speed
> of quiver plots, which can be quite slow for large vector fields. Based
> on some profiling, the problem appears to stem from the use of numpy's
> MaskedArrays in PolyCollection.set_verts. If I add the
John Hunter wrote:
> On Mon, Aug 3, 2009 at 2:15 PM, John Hunter wrote:
>
>> This may have been Eric's change to clean up the pylab imports -- all
>> the mlab imports come before the pylab imports. Was this intentional?
>> My guess is not, since np.loadtxt is the replacement for pylab.load.
>> I
John Hunter wrote:
> On Mon, Aug 3, 2009 at 2:40 PM, Eric Firing wrote:
>> John Hunter wrote:
>>> On Mon, Aug 3, 2009 at 2:15 PM, John Hunter wrote:
>>>
>>>> This may have been Eric's change to clean up the pylab imports -- all
>>>> t
Mike,
When I eliminate the cuts from filled contour paths, I do find
pathological cases where the filling works correctly with the cuts in
place, but not without them. Attached are a data file and a script to
plot it, illustrating the problem. Is this due to a known limitation of
filled pat
Fernando Perez wrote:
> On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner wrote:
>> When I set the linewidths to 0 (in the patch I'm working on) I get an image
>> looking like this:
>>
>> http://static.ryanjwagner.com/mpl_patches/lw0.png
>>
>> I don't think this looks correct to me, as I can still see t
inside cntr.c, directly generating the verts and codes
that will be input to Path. I think I have the main structure in place,
but finishing and debugging will take some time. I hope to be able to
commit it in a few days.
Eric
>
> -JJ
>
>
>
> On Thu, Aug 6, 2009 at 1:58 PM,
John Hunter wrote:
> On Thu, Aug 6, 2009 at 11:31 PM, Ryan Wagner wrote:
>>> Does your workaround work for all supported backends, and with alpha
>>> less than 1? If so, what is it?
>> I believe it will... it is to set the edgecolors (RGBA) of the polygons to
>> that of the facecolors. I will cer
Michael Droettboom wrote:
> I've tracked it down to this revision 7395
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395
>
>
That was John's. I knew there was a reason why I had written it the way
it was bef
the contourf_demo.py, I have tested it
with basemap's simpletest.py and with random data, without detecting any
obvious artifacts. More testing is welcome, of course.
Eric
>
> -JJ
>
>
>
> On Thu, Aug 6, 2009 at 1:58 PM, Eric Firing wrote:
>> Mike,
>>
&g
Eric Firing wrote:
> Michael Droettboom wrote:
>> I've tracked it down to this revision 7395
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/colors.py?r1=7318&r2=7395&pathrev=7395
>>
>>
>
> T
[email protected] wrote:
> Here are a few patches that we in Sage have been applying to our version
> of matplotlib. I'm wondering if some or all of these might be
> incorporated into matplotlib, or if not, if you could comment on these
> patches. I've updated the following diffs to
Reinier Heeres wrote:
> Hi all,
>
> I would like to propose the attached patch to be able to use a gamma
> value for color maps. This will make it simple to make your color
> scale more 'sensitive' at the bottom or at the top, as can be seen in
> the attached example. This could in principle also
Jason R. Coombs wrote:
>
>> -Original Message-
>> From: Darren Dale [mailto:[email protected]]
>>
>> On Thu, Aug 13, 2009 at 7:44 AM, John Hunter wrote:
>>> On Wed, Aug 12, 2009 at 7:12 AM, John Hunter
>> wrote:
>> I appreciate how much time has gone into the patch, but this impacts
>> so
John Hunter wrote:
> On Thu, Aug 13, 2009 at 1:08 PM, Eric Firing wrote:
>
>> Ideally, all the docstring manipulations would be done once at the time of
>> installation or of compilation to .pyc, not at every mpl startup. I think
>> that doing it at compilation time is im
Jason R. Coombs wrote:
> I'm about to upload a new patch that implements some of the ideas John and
> Darren have sent. Would you mind running the performance tests against that
> one also? This new change has the potential to increase performance drag.
>
> Jason
I'll test it, but it might be a
Jason R. Coombs wrote:
I'm about to upload a new patch that implements some of the ideas John and
Darren have sent. Would you mind running the performance tests against that
one also? This new change has the potential to increase performance drag.
I tested it; performance still is not a proble
Jason R. Coombs wrote:
> I'm about to upload a new patch that implements some of the ideas John and
> Darren have sent. Would you mind running the performance tests against that
> one also? This new change has the potential to increase performance drag.
Jason,
There is a problem with rev4, runni
After ignoring it for a long time, I took a look at the Sourceforge bug
tracker, and closed a couple bugs. Our bug list is a bit embarrassing;
there are 52 open ones going back to 2005. Is any of this an artifact
of all the reworking going on at SF? Did some closed bugs get reopened
by accid
Michael Droettboom wrote:
> I think this is just a vanilla bug that set_clip_on is being ignored for
> collections. That patch is rather straightforward.
>
> Other developers: do you agree this should be fixed, or is there a good
> reason for current behavior that I'm missing?
It certainly loo
Jason R. Coombs wrote:
> It appears that the docstring.py module somehow got omitted from the rev5
> patch (I was working from two different machines, and one didn't have it
> added to SVN).
>
> So I'm attaching missing_docstring.patch which is a patch against the latest
> trunk to include the lat
ivate ones, and calling those in __init__.)
5) In _cm.py, if the maps you condensed are already identified in
comments as to their sources, then you should add to those comments a
note on how you modified them.
Thank you for your work on this.
Eric
>
> Regards,
> Reinier
>
> On Thu
Michael Droettboom wrote:
> We recently saw some breakage with our PyRAF plotting tool (which uses
> matplotlib as a "dumb" rendering backend) and matplotlib 0.99. It stops
> inside the subslice support that was added to Line2D, since subslicing
> requires that the Line2D object have an "axes"
nts passed to the renderer -- the actually
> speed at which those points are located is nothing compared to stroking
> points.
>
> Cheers,
> Mike
>
> Eric Firing wrote:
>> Michael Droettboom wrote:
>>> We recently saw some breakage with our PyRAF plotting tool (
[email protected] wrote:
> Revision: 7567
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7567&view=rev
> Author: mdboom
> Date: 2009-08-25 15:31:10 + (Tue, 25 Aug 2009)
>
> Log Message:
> ---
> Support Line2D objects without associated Axes objects.
Tony S Yu wrote:
> Did this email ever appear on list? I didn't see it after sending my
> original post, but I found it on the Sourceforge mail archives. I'm
> trying a different email address as an experiment.
Tony,
It did appear the first time, but I guess everyone who saw it figured
someo
Andrew Straw wrote:
> Eric Firing wrote:
>> Tony S Yu wrote:
>>
>>> Did this email ever appear on list? I didn't see it after sending my
>>> original post, but I found it on the Sourceforge mail archives. I'm
>>> trying a different email
Andrew Straw wrote:
> Eric Firing wrote:
>>> Specifically, it looks like the farthest left xticklabel is no longer
>>> getting displayed. Personally, I think it looks better this way, but now
>>> that the test suite is coming online, we will finally start noticing
>
John Hunter wrote:
> On Sun, Aug 30, 2009 at 12:57 PM, John Hunter wrote:
>
>> OK, I figured this out. The new failure was on formatter4, not
>> formatter5. I didn't see that when I posted earlier. It turns out
>> when we were working at scipy and I wrote that script to move new
>> saved-result
Reinier Heeres wrote:
> Eric, all,
>
> Here's the latest version of my color map patch. I deferred your
> suggestion #4; perhaps we can fix that later.
>
> Please let me know what you think; if everybody is ok with it I'll
> push to trunk.
>
> Regards,
> Reinier
Looks good. I haven't tested it
[email protected] wrote:
> Revision: 7620
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7620&view=rev
> Author: heeres
> Date: 2009-08-31 19:50:13 + (Mon, 31 Aug 2009)
Reinier,
Thanks! Don't forget to make a note in CHANGELOG.
Eric
-
Jouni K. Seppänen wrote:
> I just happened to type getp(gca()) on matplotlib 0.99.0, and the output
> looks all garbled:
Fixed in r7780 (branch) and 7781 (trunk).
Eric
>
getp(gca())
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/axes.py:1269:
>
Ryanitus wrote:
> I may have found a bug in the __setitem__ method of the maxdict class.
>
Fixed--thanks for pointing it out.
Eric
> Since a dictionary is a mapping class, if an item is set that already
> exists, it overwrites the previous. However, you are still appending that
> item to _kill
Brad Chivari wrote:
> SUBJECT:
> Filtering out 0 bar height/width not working
>
> FILE:
> matplotlib/ trunk/ matplotlib/ lib/ matplotlib/ axes.py
>
> PROBLEM:
> xmin = np.amin(width[width!=0]) # filter out the 0 width rects
> ymin = np.amin(height[height!=0]) # filter out the 0 height rects
>
>
[email protected] wrote:
> Revision: 7824
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7824&view=rev
> Author: jrevans
> Date: 2009-09-24 20:47:11 + (Thu, 24 Sep 2009)
>
> Log Message:
> ---
> Fixed a comparison in update_patch_limits that compare
Stéfan van der Walt wrote:
> Hi all,
>
> When saving plots (using plt.figsave and matplotlib from SVN)
> consisting of subplots, the layout is a bit messed up. As an example,
> have a look at
>
> http://mentat.za.net/refer/segmentation.pdf
Wow, that's really ugly! I suspect that for anyone to
David Cournapeau wrote:
> Hi Andrew,
>
> Andrew Straw wrote:
>> Dear David,
>>
>> It certainly is of interest to me. When I get a little time (maybe this
>> weekend), I'd like to try it. Specifically, I'd like to setup a buildbot
>> that would automatically build and run the test suite with it. Al
Reinier Heeres wrote:
> Hi Philip, all,
>
> This work seems to overlap a lot with the recent color map changes I
> committed
> (http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/colors.py?r1=7488&r2=7620),
> except for the piece-wise constant color maps.
Exa
Benjamin Drung wrote:
> Hi,
>
> setupext.py contains a basedir directory. Please add there
> 'linux2-alpha', 'linux2-hppa', 'linux2-mips', 'linux2-sparc',
> 'gnukfreebsd7', 'gnukfreebsd8'.
>
> It would be nice, if matplotlib had an option to disable '/usr/local'.
> This would be useful for distri
Benjamin Drung wrote:
> Am Montag, den 05.10.2009, 12:50 -1000 schrieb Eric Firing:
>> Benjamin Drung wrote:
>>> Hi,
>>>
>>> setupext.py contains a basedir directory. Please add there
>>> 'linux2-alpha', 'linux2-hppa', 'linux2
from the doc strings. I've found the HTML easier to read
> because of color, italics, etc., but the content of the doc strings is
> sometimes better and/or quite different. It would be great if these
> could be harmonized.
The API html docs are built automatically from the docstrings;
Gellule Xg wrote:
> This is a bug report for matplotlib version 0.99.1.1
>
> The clip_path keyword of imshow() does not work when setting it to
> (Path, Transform) for two reasons:
>
> 1. On line 622 of artist.py, v is now the tuple (Path,Transform) and
> should be apply to func with apply(func
Phillip M. Feldman wrote:
>
> When I look at the online documentaiton for from_list, here's what I
> see: "Make a linear segmented colormap with /name/ from a sequence of
> /colors/ which evenly transitions from colors[0] at val=1 to colors[-1]
> at val=1. N is the number of rgb quantization l
e quantization problem I mentioned in
connection with discrete colormaps. But it is not a problem when the
colors are linearly interpolated--that is, smoothly varying from one end
of the map to the other. It is only a problem when there are jumps.
Eric
>
> Phillip
>
> Eric Firing wrot
Jens wrote:
> Hi,
>
> on a fresh CentOS5.3 with SciPy installed from repository
> http://software.opensuse.org/download/home:/ashigabou/ and additional
> packages
> freetype-devel-2.*
> libpng-devel-1.*
> pygtk2-devel
> gtk2-devel
> the matplotlib-setup script "setup.
Eric Bruning wrote:
> I'm seeing problems with reversed colormaps (attached code and image).
> The problem seems to be with colormaps that are specified functionally
> or that don't have equal numbers of red, green, and blue entries. For
> instance, 'flag', 'rainbow', and 'gist_earth'.
>
> Further
Eric Bruning wrote:
> I'm seeing problems with reversed colormaps (attached code and image).
> The problem seems to be with colormaps that are specified functionally
> or that don't have equal numbers of red, green, and blue entries. For
> instance, 'flag', 'rainbow', and 'gist_earth'.
>
> Further
James Evans wrote:
> All,
>
>
>
> I have a question regarding the default alpha value for an Artist. Why
> is it 1.0 instead of None? The color conversion code takes into account
> if alpha is None and having it default to something other than None
> makes it impossible for any Patch to ha
Stéfan van der Walt wrote:
> Hi Eric,
>
> 2009/9/28 Eric Firing :
>>> When saving plots (using plt.figsave and matplotlib from SVN)
>>> consisting of subplots, the layout is a bit messed up. As an example,
>>> have a look at
>>>
>>> http
[email protected] wrote:
> How hard would it be to extend the quiver command to support curved
> arrows? For example, the U and V arrays, instead of giving just the
> vector, could for each vector give a list of x coordinates and a list of
> y coordinates for each segment of a vector.
Michiel de Hoon wrote:
> Hi everybody,
>
> I was looking at this bug about a memory leak:
>
> https://sourceforge.net/tracker/?func=detail&atid=560720&aid=2889570&group_id=80706
>
> While this bug is now essentially fixed, I noticed that the Figure class
> contains some circular references that
Andrew Straw wrote:
> Hi All,
>
> I have addressed what I think is a long-standing wart: zorder is mostly
> ignored for imshow(). (See e.g.
> http://old.nabble.com/Re%3A--Matplotlib-users--imshow-zorder-tt19047314.html#a19047314
>
> ) The question is whether I should apply the attached patch.
Jae-Joon Lee wrote:
> Andrew,
>
> One of my worry is that this can results in inconsistent ouputs
> between backends. Your patch only affects backends with compositing
> capabilities. And backends such as ps backend will still render images
> at the bottom of all other artists.
PS backend already
Drain, Theodore R (343P) wrote:
> FYI: Thanks for the help John.
>
> This is case where having path.simplify = True causes the plot to be
> incorrect. Attached are two different images (not quite the same data
> as the original post- but the same affect). One with path.simplify as
> true and
James Evans wrote:
> All,
>
> I have been looking at some of the recent z-order changes and have found an
> issue that breaks previous behavior. Previously when
> items were added to a Figure or an Axes with the same z-order value, they
> were rendered in order of when they were added, so that
James Evans wrote:
> All,
>
> I have been looking at some of the recent z-order changes and have found an
> issue that breaks previous behavior. Previously when
> items were added to a Figure or an Axes with the same z-order value, they
> were rendered in order of when they were added, so that
John Hunter wrote:
> On Tue, Dec 1, 2009 at 6:21 PM, Eric Firing wrote:
>> This is easy to fix by using the key kwarg (added in python 2.4) of the
>> sort method, because python uses a stable sort. It looks like it only
>> needs to be fixed in Axes.draw, because Figure.dr
Jae-Joon Lee wrote:
> The recent zorder-related changes broke the some of the rasterization
> feature, and I just committed a fix. In doing so, I replaced
>
> dsu.sort(key=lambda x: x[0])
>
> to
>
> dsu.sort(key=itemgetter(0))
>
> which I think is slightly faster (although spee
Jouni K. Seppänen wrote:
> Christopher Barker writes:
>
>> Joey Wilson wrote:
>>> I would like to be able to save the figures from
>>> matplotlib in an editable form, without flattening down to an image
>>> file.
>> I think to do this right, you'd need to completely re-design MPL to be
>> bas
Stéfan van der Walt wrote:
> Hi all,
>
> According to the `spy` docstring, it can display sparse matrices from
> scipy. The following code snippet seems to break, however:
>
> In [20]: import scipy.sparse as sp
> In [21]: d = sp.lil_eye((15, 15))
> In [22]: plt.spy(d)
>
> Am I using the `spy` f
Stéfan van der Walt wrote:
> Hi all,
>
> According to the `spy` docstring, it can display sparse matrices from
> scipy. The following code snippet seems to break, however:
Fixed in the trunk.
Eric
>
> In [20]: import scipy.sparse as sp
> In [21]: d = sp.lil_eye((15, 15))
> In [22]: plt.spy(d)
Gael Varoquaux wrote:
> Line 157 of image.py, there is a typo:
>
> Index: matplotlib/image.py
> ===
> --- matplotlib/image.py (revision 8036)
> +++ matplotlib/image.py (working copy)
> @@ -144,7 +144,7 @@
> sy = d
I wanted to make a small fix to the contour docstring, and test it
before committing, so I tried building the docs from scratch. It fails
with the last part of the traceback being:
File
"/usr/local/lib/python2.6/dist-packages/matplotlib/sphinxext/plot_directive.py",
line 414, in plot_dire
n"?
Yes, if the generated files can't all land in the "build" directory (as
would seem preferable), then the next-best thing would be to have
make.py able to do a thorough cleaning.
Eric
>
> Regards,
>
> -JJ
>
>
> On Fri, Jan 1, 2010 at 11:09 PM, Eri
http://www.mail-archive.com/[email protected]/msg14772.html
The above thread includes two reasonable requests:
1) add color cycle as an rcParam
2) add a line style cycle as well
The first of these is easier to implement, although it requires a bit
more than the patch provi
John Hunter wrote:
> On Sat, Jan 2, 2010 at 12:34 AM, Eric Firing wrote:
>> Jae-Joon Lee wrote:
>>> The error happens because of the *.rst files under doc/examples that
>>> are not in sync with examples/*.py.
>>> Removing that directory (doc/examples) will
>> 2) It was pointed out that there is a strange connection between the color
>> cycle and the lines.color rcParam. This connection looks to me like a bit
>> of legacy that can be dropped with little risk of pain in user land, since
>> the default would still be to have the initial color in the c
John Hunter wrote:
> On Sun, Jan 3, 2010 at 3:54 PM, Eric Firing wrote:
>> The only problem is that lines.color is the default for LineCollection and
>> Line2D, both of which are fairly separate from Axes, so having them default
>> to rcParams['axes.color_cycle'][
Ian Thomas wrote:
> Hello all,
>
> I think I have fixed two bugs in the contouring code (src/cntr.c):
> 1) inconsistent behaviour in how contour and contourf handle saddle
> grid squares, and
> 2) incorrect handling of masked regions in filled contour plots.
>
> Attached is a gzipped tar file con
Ian Thomas wrote:
> Hello all,
>
> I think I have fixed two bugs in the contouring code (src/cntr.c):
> 1) inconsistent behaviour in how contour and contourf handle saddle
> grid squares, and
> 2) incorrect handling of masked regions in filled contour plots.
Ian,
I have applied your patch and mo
John Haiducek wrote:
> I have a matplotlib application whose memory consumption increases with
> each call to matplotlib.colorbar.draw_all(). I'm using the matplotlib
> 0.99.0 as found in the ubuntu karmic (universe) repository.
>
> I've filed a bug report, ID 2934351, titled "Possible memory lea
Jae-Joon Lee wrote:
> John and others developers,
>
> I think the current colorbar implementation has some (minor) issue
> related with how ticks are treated.
>
> Here is a quick example,
>
> imshow(np.arange(100).reshape((10,10)))
> cb = colorbar()
>
> This gives you a nice colorbar, Howev
Jae-Joon Lee wrote:
On Mon, Jan 25, 2010 at 7:19 PM, Jae-Joon Lee wrote:
Adding a "set_ticks" method seems reasonable.
A patch is attached.
It looks like exactly what I had in mind with respect to set_ticks. I
wasn't thinking about set_ticklabels; my sense is that manually setting
tickla
Ryan May wrote:
> Hi,
>
> I was shown a bug today by a colleague, demonstrated by the following example:
>
> import numpy as np
> import matplotlib.pyplot as plt
>
> a = np.zeros([10, 10])
> a[2:6,3:8] = 1
> ls = plt.contour(a, 1, colors='r', linewidths=3, zorder=5)
> print ls.collections[0]l.ge
Benjamin Drung wrote:
> Hi,
>
> we applied 40_hurd.patch for building matplotlib on Debian GNU/Hurd.
>
> Additional attached the 10_build_fix.patch. This patch does two things.
> First it enables matplotlib on all Debian architectures. The second
> things is that it removes /usr/local from the ba
Ian,
I hit a bug (segfault) in cntr.c that is likely related to your changes.
It is ID 2956378 in the tracker. Sample script and data file are there.
Will you be able to take a look soon?
(Not sure whether the following link will work for you.)
https://sourceforge.net/tracker/?func=detail&ai
Michiel de Hoon wrote:
> Dear all,
>
> The draw_path method in backend_cairo.py starts with a check for the number
> of vertices in the path, and raises an error if the path contains more than
> 18980 vertices:
>
> def draw_path(self, gc, path, transform, rgbFace=None):
> if len(p
Ian Thomas wrote:
> Eric,
>
>> I hit a bug (segfault) in cntr.c that is likely related to your changes. It
>> is ID 2956378 in the tracker.
>
> Attached is a patch file with a fix for this bug. I've also included
> a minimal test file to demonstrate the behaviour before and after the
> fix, alon
All,
I think the git migration deserves its own thread on the devel list, so
here is a start.
The full svn repo includes much more than just matplotlib: also course,
htdocs, py4science, sample_data, sampledoc_tut, scipy06, toolkits, and
users_guide. Before moving matplotlib, I think we should
Andrew Straw wrote:
[...]
> This is a good point. My preferred option is that we jettison all the
> stuff that is not going to be shipped with MPL 1.0 from the git repo.
> (More correctly - we build a git repo without that stuff ever going in.)
> We can keep the old svn tree around and migrate the
Eric Firing wrote:
> All,
>
> I think the git migration deserves its own thread on the devel list, so
> here is a start.
Explanation: the last bit of discussion was actually off-list, but
because it was tacked onto a matplotlib-users list thread, and appeared
there in my mailer,
Günter Lichtenberg wrote:
> On Thursday 04 March 2010 14:20:41 you wrote:
>> 2010/3/4 Günter Lichtenberg :
>>> Hi
>>>
>>> I think there is a bug in the conversion routines jul2num() and
>>> num2jul(). I tried to define a date axis for satellite data. The time is
>>> measured in a modified Julian Da
Ian Thomas wrote:
> Chris Barker wrote:
>> I think it would be great to have in MPL.
>>
>> What code are you using for the triangulation? Does it do constrained
>> delauney?
>
> My code only does the contouring; you have to input the triangulation.
> In the examples included with the code I used
Christopher Barker wrote:
> John Hunter wrote:
>> It would probably
>> be beneficial, but by no means required, to use CXX to expose the C++
>> part to python so take a look if you are inclined.
>
> What about Cython -- is any one using Cython in MPL yet?
No, not yet, but I think we should be loo
Sandro Tosi wrote:
> forwarded 573179 [email protected]
> thanks
>
> Hello Matplotlib developers,
> I'm forwarding this bug a Debian user reported some days ago. It would
> be nice it you could give it a look
Using svn trunk mpl and numpy 1.5.0.dev8042, I can't reproduce it;
Fernando Perez wrote:
> Howdy,
>
> On Wed, Feb 24, 2010 at 11:27 AM, Fernando Perez wrote:
>> OK, since I know people are busy, I took silence as acquiescence.
>> Committed in r8151, please let me know if I messed anything up and
>> I'll try to fix it. I'm used to the numpy docstring standard, b
David J. Raymond wrote:
> I am using python 2.5.5 and the gtk background (as far as I can tell).
> Turning off path.simplify gets rid of the extraneous line. I am
> attaching pngs with path.simplify both on and off. I am also
> attaching the full coastline file that produced the original problem.
101 - 200 of 1085 matches
Mail list logo
