Dang that looks good. The only glitches that I see are:
1) after the ">>> hist(x, 100)""" line in the Python pre-formatted text
box, there's an extra line's worth of vertical space.
2) The heading "Plotting commands" overlaps slightly with the top line
of the following table.
This is on Firefox
Ryan May wrote:
> John Hunter wrote:
>
>> On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <[EMAIL PROTECTED]> wrote:
>>
>>
>>> 1) Have psd(x) call csd(x,x)
>>> 2) Have csd() check if y is x, and if so, avoid doing the extra work.
>>>
>>> Would this be an acceptable solution to reduce code duplica
Hi Stan,
You may want to have a look at the mplsizer MPL toolkit I wrote a long
time ago and have failed to properly advertise or maintain. But, it does
much of what you propose by emulating wx sizers for matplotlib. Anyhow,
this is available by svn checkout from
https://matplotlib.svn.sourceforge
Since using git for some time on several projects (including projects
with a central svn repository), it's been hard to go back to the
universally slow web-based subversion history browsers and the absence
of 'git bisect'. Thus, I'm thinking about cloning the MPL SVN history
into a git repo, but I
John Hunter wrote:
> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> Hi All,
>>
>> I have been testing the latest svn matplotlib, which failed to produce
>> any visible data in some long-standing scripts of mine. :(
>>
>> In
m a machine with build tools at the moment, so can't
> confirm. Does the attached patch work for you?
>
> Mike
>
> Andrew Straw wrote:
>> John Hunter wrote:
>>
>>> On Sat, Nov 29, 2008 at 3:55 PM, Andrew Straw <[EMAIL PROTECTED]>
>>>
ctually suggest getting moderately comfortable with pure
git before attempting to do git/svn juggling. I suggest playing with the
sympy git repository: git clone git://git.sympy.org/sympy.git
Michael Droettboom wrote:
> I don't know of any, but if you create one let us know. I'd be
>
, which could become a significant piece of the
> low-level infrastructure (eg for axes layout) so I do want to make
> sure we get this right. In particular, I'd like Andrew Straw, who has
> a toolkit for sizers, and Michael Droettboom, who implemented the
> Knuth boxes in suppor
I just put my git mirror of the matplotlib svn repository online. This
is experimental in nature. Thanks to github for hosting this project.
Anyhow, I added instructions for how to use this (including to interact
with the central svn repository) here:
http://github.com/astraw/matplotlib/tree/maste
of course give you and Michael and anyone else write
permissions if need be.) I'm new to git in a multi-developer context and
git-svn may add another layer here, so please bear with me.
-Andrew
John Hunter wrote:
> On Wed, Dec 3, 2008 at 8:12 PM, Andrew Straw <[EMAIL PROTECTED]> wro
I updated the documentation to hopefully address the issue that John
(and Michael) had. I also moved the git documentation to a section in
doc/faq/installing_faq.rst.
And I noticed that github does automatic parsing of rst files. Check
this out -- Sweet! :)
http://github.com/astraw/matplotlib/tree
Hi Nils. I think I fixed the issue causing the traceback with r6563. Can
you please update and try again with text.usetex enabled?
My guess is that you don't have dvipng installed, which was causing the
detection check to throw a traceback rather than return a value
signifying undetected. So, enab
Michael Droettboom wrote:
> Darren Dale wrote:
>
>> Having worked with bzr and launchpad for a few months now, I wonder if
>> we might consider such an approach in the future. I know there has
>> been some experimentation with a git repository, is git supported on
>> windows now?
>>
> I'
t # Actually apply to svn
Finally, you may want to continue working on your whizbang-branch, so
rebase it to the new master::
git checkout whizbang-branch
git rebase master
Michael Droettboom wrote:
> This is mostly for Andrew Straw, but thought anyone else experimenting
> with git may be
Andrew Straw wrote:
I realize I may have ignored an important question.
> Michael Droettboom wrote:
>> Now I feel stuck. How do I "undo" the merge from experimental to master?
To do that, I actually delete the master branch with "git branch -D
master" and then
I have also developed some image-based unit tests to compare MPL output,
and I completely agree that getting something like this into MPL is a
very good idea. As Ted writes, the hard part is defining "close" for
images. Minor changes to, for example, agg pixel alignment, cause the
tests to fail whe
> there's a quick answer, let me know, otherwise I'll do a little digging
> to see if it's possible.
>
> Mike
>
> Andrew Straw wrote:
>> Hi Michael,
>>
>> The main issue is that we can't use git "normally" because the main
>
Hi Sandro,
It's great news that a book may come out on MPL.
Speaking as an aspiring university professor in neuroscience, I would
like to see something that could be used as a resource for undergraduate
students just learning Python and MPL. Due to this perspective, I think
such a book would cove
me use git full-time, particularly with
>> the way matplotlib and other projects I work on are laid out in SVN. So
>> I'm pretty motivated to figure this out.
>>
>> I'll certainly share any findings in this regard.
>>
>> Cheers,
>> Mike
>&g
John Hunter wrote:
> Andrew, since you are the original author of the isnan port, could you
> patch the branch and the trunk to take care of this?
Done in r6791 and r6792.
Sorry for the trouble.
Now I just hope we don't get a problem with "long long", although now if
_ISOC99_SOURCE is defined, w
nter wrote:
> On Fri, Jan 16, 2009 at 12:38 PM, Andrew Straw wrote:
>> John Hunter wrote:
>>> Andrew, since you are the original author of the isnan port, could you
>>> patch the branch and the trunk to take care of this?
>> Done in r6791 and r6792.
>>
>>
For the past month or two, I've been experimenting with using git to
interact with the MPL subversion repository. The bottom line is that I I
haven't been able to create any kind of one-to-one mapping between git
branches and svnmerge.py branches. As we're using svnmerge.py on top of
subversion to
Patrick,
Can you see if adding "#include " at the top of src/path.cpp
will do the job?
I'm not super-optimistic, though -- I think this is defined by the C99
standard, which I'm not sure Microsoft supports.
-Andrew
Patrick Marsh wrote:
> Greetings,
>
> I have previously been able to build matpl
Ryan May wrote:
> On Fri, Feb 6, 2009 at 3:27 PM, Andrew Straw <mailto:straw...@astraw.com>> wrote:
>
> Patrick,
>
> Can you see if adding "#include " at the top of src/path.cpp
> will do the job?
>
> I'm not super-optimist
Hi Gary, I have a couple comments:
1) No need for:
+ax = fig.add_subplot(111)
+ax.set_axis_off()
2) It's probably best to have maximum compatibility with imshow().
Therefore, use vmin=None and vmax=None as keyword arguments (rather than
clims).
Otherwise, I tested and it works for me.
Gary, this looks fine to me. Do you have commit access? If not, I'll be
happy to check it in for you.
-Andrew
Gary Ruben wrote:
> Thanks for the quick test and comments Andrew. I've made your suggested
> changes and attached a new patch.
>
> Gary
>
> Andrew Straw
Gary Ruben wrote:
> Hi Andrew,
>
> I don't have commit access. If you would check it in, that would be great.
Committed to the trunk in r6899... Thanks!
And, sheesh, SourceForge's SVN server is slooow today for me, although
it seems to have finally improved.
Eric Firing wrote:
> Sandro Tosi wrote:
>> Hi Sam,
>>
>> On Wed, Feb 25, 2009 at 09:35, sam tygier wrote:
>>> I think this topic has come up before, but i don't think anything has
>>> resulted from it.
>>>
> Correct, because the capability would require a *lot* of work to
> implement, and most of
Paul Kienzle wrote:
> On Mar 12, 2009, at 9:49 AM, Michael Droettboom wrote:
>
>
>> We've done some experiments with Enthought Traits at various times to
>> address this issue. There were always various obstacles to making it
>> work, but it may be worth another look. Traits has its nice auto-
John Hunter wrote:
> In general, only very clear bugfixes which are unlikely to result in
> "surprise" breakages should go in. The _png patch, though a bug fix,
> has more of the feel of a feature enhancement, and given its
> complexity, should probably not go in to the branch unless someone
> mak
Nicolas Rougier wrote:
>
> I read the thread about mplot3d and the work that has been done by
> Jonathan Taylor. I wonder if an OpenGL backend is necessary at all.
> Jonathan's work seems to be great for simple 3D plotting while the
> mayavi mlab module is here for more "serious" rendering.
Nicolas Rougier wrote:
>
> What I do generally to have "nice" OpenGL output is to render
> screenshots at high resolution and then use something like gimp to
> resize them. I agree that it is far from optimal but it's pretty
> decent for a scientific paper. Other solutions are vector renderi
Charlie Moad wrote:
> I am running into an error when importing matplotlib though. I'll
> poke around but would appreciate extra eyes.
>
> ImportError: DLL load failed: The specified procedure could not be found.
Hi Charlie, we've been batting this one around on MPL-users for a little
while... s
I've been hacking away at adding support for "dropped spines" to MPL
(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
have come to the conclusion that there is a fundamental issue in the
code base that the traits package has solved -- many values that depend
on other values wit
Hi all,
I am attempting to get a collective.buildbot service working on the
Matplotlib trunk (branches could be enabled in the future) and James
Evans' test suite. Right there are errors that prevent the test suite
from even being run. I'll attempt to work through these, and you can
check progress
Andrew Straw wrote:
> Hi all,
>
> I am attempting to get a collective.buildbot service working on the
> Matplotlib trunk (branches could be enabled in the future) and James
> Evans' test suite. Right there are errors that prevent the test suite
> from even being run. I
Andrew Straw wrote:
>> I am attempting to get a collective.buildbot service working on the
>> Matplotlib trunk (branches could be enabled in the future) and James
>> Evans' test suite. Right there are errors that prevent the test suite
>> from even being run.
I be
ote:
> On Wed, May 20, 2009 at 3:48 AM, Andrew Straw wrote:
>
>> Let's see if we can get all the tests passing and if this buildbot
>> approach looks sustainable -- if so, I'd like to get some more build
>> slaves into the mix and make MPL a good continuous int
John Hunter wrote:
> When plotting the polar demo, I am not getting radial grids on the
> trunk (but I am getting them on the branch). Any ideas?
git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
using git to interact with MPL svn again. Just don't ask me to deal
with the
Andrew Straw wrote:
> John Hunter wrote:
>> When plotting the polar demo, I am not getting radial grids on the
>> trunk (but I am getting them on the branch). Any ideas?
>
> git bisect let me narrow it down to r7100 in a few minutes. (I'm back to
> using git to inter
John Hunter wrote:
> On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee wrote:
>
>
>> 2) Axes.frame
>> Is it okay to simply drop this attribute? Any code that access this
>> attribute will raise an exception. For example, some of my code in
>> mpl_toolkits.axes_grid access this attribute, althoug
Hi MPL transform gurus (aka Mike),
I'm trying to close on this "dropped spine" thing, and I have a question
I think you could save me some time on.
I need to get a transform that will be combined with the normal xaxis
transform to shift the spine and associated ticks and tick labels by
some amoun
I've gone ahead and committed my arbitrary spine location implementation
to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
To get you started, try the new demo:
examples/pylab_examples/spine_placement_demo.py
I believe I addressed all the issues raised with the patch I email
Andrew Straw wrote:
> I believe I addressed all the issues raised with the patch I emailed the
> list last week and I tried to avoid any breakage. Thanks to all who
> commented -- you made this a better implementation.
Upon further reflection, I realize I didn't add any Axes conven
John Hunter wrote:
> I was just updating the site docs and a few examples are failing to
> build. Some of these are easy pickens, so if you have a quick fix,
> please put it in, and reply here when you've fixed one to avoid
> duplication of effort.
If you can coerce the recipe I sent this list on
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_edgecolor().
More below.
> On
Eric Firing wrote:
> Andrew Straw wrote:
>> The slight API change is that spine.set_color() is now
>> spine.set_edgecolor().
>
> But spine.set_color() is much more natural and easy to remember, so
> maybe it can be restored:
Good idea. I just re-added Spine.set_color()
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 patches.
I think it's useful
Eric Firing wrote:
>
>>> 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
>
Gael Varoquaux wrote:
> On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote:
>
>> Anyone interested? And if so, feel free to suggest topics or weigh in
>> on some I listed.
>>
>
> Actually, I have something I would like to discuss, but never really
> could pull myself together to d
Erik Tollerud wrote:
> Personally, I think traits must be kept out of MPL, for three main reasons:
>
As these comments are in respose to my email, let me again state the
main point of my email:
My main feeling about MPL is that there's just too much layout happening to
keep using the non-syst
John Hunter wrote:
> On Thu, Jul 30, 2009 at 1:56 PM, Jae-Joon Lee wrote:
>
>
>> ps. Are we having a sprint during the scipy conference by the way? I
>> may join remotely.
>>
>
> I'll definitely be there Sat and Sun, so having you join in remotely
> would be great. I haven't organized any
Brian Granger wrote:
>
>
> I think this happens in all mpl graphs, you just don't see it. The
> axis limits are set to -2..2, and the sine is draw from -2..2. The
> linewidth extends beyond 2, so it is clipped by the axes clipping to
> the bounding rectangle. Normally you don't
jason-s...@creativetrax.com wrote:
> On this thread:
>
> http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg05383.html
>
> clip_on was a suggested way of getting around the clipping that happens
> at the edge of a frame. In the Sage project, we are always setting the
> limits
Hi All,
At the SciPy 09 sprints I worked with John Hunter on our automated build
and test infrastructure. It's still not *quite* there, but I thought I'd
point out a few things at this stage. (Much of this email is
more-or-less a status update for John.)
0. We have automated tests now running tri
Andrew Straw wrote:
> I'm publishing these onto http://mpl.code.astraw.com/
Which I have now actually created a DNS entry for. If you tried and got
an error like "Address not found, can't find the server at
mpl.code.astraw.com", you should have better luck in a few mi
Hi,
I'm hoping to elicit the help of a developer who can fix the last
remaining failing test on the Mac buildslave. In a nutshell, there looks
to be a regression with the interaction between Axes.autoscale_view()
and the xunits kwarg of Axes.plot(). I have posted a bug report at
https://sourceforg
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 address as an experiment.
>>
>
> Tony,
>
> It did appear the first time, but
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
>> little things like this.
>
> I agree that the newer ver
Jouni K. Seppänen wrote:
> Eric Firing writes:
>
>
>> Andrew Straw wrote:
>>
>>> Eric Firing wrote:
>>>
>>>>> Specifically, it looks like the farthest left xticklabel is no longer
>>>>> getting displayed. Pers
John Hunter wrote:
> On Sun, Aug 30, 2009 at 4:17 PM, John Hunter wrote:
>> According to RobK, you can reconfigure your ubuntu system to turn
>> these off. He suggests:
>>
>> To use autohinting, use the hint in this post, or just run the
>> following command:
>>
>> sudo dpkg-reconfigure fontconf
Michael Droettboom wrote:
> You can also turn hinting off at runtime by passing a flag to freetype.
> matplotlib currently exposes this flag in the FT2Font extension, but we
> don't really expose the option to the user. It would be simple enough
> to make it an rcParam, though, which could the
jason-s...@creativetrax.com wrote:
> Do the right and top spines display correctly when the position is set
> using 'axes' coordinates?
>
Jason,
This looks like a bug. I'll look into it. Please ping me in a few days
if you haven't heard back.
-Andrew
-
Stan West wrote:
> Greetings. I had previously succeeded at building matplotlib in Windows XP
> using Visual Studio 2003. (Thanks to Charlie Moad for much guidance!) I'm
> now running Win7RC and want to set up builds in that OS for Python 2.5. I
> read in the messages of May 28 about the releas
Andrew Straw wrote:
> I am interested in getting the buildbot infrastructure to build
> automatic nightly binaries for Windows (XP was my thought, but 7 would
> also be good). If you you'd be willing to perform the work to automate
> build and installation from the svn repo o
It looks like we may be on the hook for some c++ ABI breakage with
Apple's latest OS (Snow Leopard). See the attached email forwarded from
the numpy mailing list.
-Andrew
--- Begin Message ---
On Fri, Sep 4, 2009 at 1:49 AM, Charles R
Harris wrote:
>
>
> On Thu, Sep 3, 2009 at 10:39 AM, Robert Ker
mpl-buildmas...@code.astraw.com wrote:
> STATUS: Failure
> revision: 7635 (
> http://matplotlib.svn.sourceforge.net/matplotlib/?view=rev&rev=7635 )
>
I just installed dvipng on the test machines, which I think will make
them pass this test next time.
But it looks from the traceback
http://mp
Jae-Joon Lee wrote:
> On Fri, Sep 4, 2009 at 4:10 PM, Jae-Joon Lee wrote:
>
>> Yes, this should be my fault. I didn't expect that importing a
>> texmager would raise an exception. I'll fix it soon.
>>
>>
>
> I just committed a changeset that I think would fix this (the
> textpath.py imports
jason-s...@creativetrax.com wrote:
> https://sourceforge.net/tracker/?func=detail&aid=2852168&group_id=80706&atid=560720
>
I fixed this in svn r7638. Thanks for the report.
Can a dev merge r7638 from the v0_99_maint branch into the trunk? I'm
having a hard time figuring out svnmerge and I reall
Today I committed to svn a simplified testing infrastructure, which I've
committed to matplotlib/testing/*. A few sample tests are in
matplotlib/tests/*. I also wrote some docs, which are now in the
developer coding guide. See that (
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/mat
Andrew Straw wrote:
> Today I committed to svn a simplified testing infrastructure, which I've
> committed to matplotlib/testing/*. A few sample tests are in
> matplotlib/tests/*. I also wrote some docs, which are now in the
> developer coding guide.
John Hunter wrote:
> I was able to run the buildbot mac script when logged into sage with::
>
So it seems the bus error on Mac is due to networking (DNS lookups)
being broken in non-interactive logins. This is a pain for the
get_sample_data() approach. (Although I suspect we could work around it
John Hunter wrote:
> On Sun, Sep 6, 2009 at 3:44 PM, John Hunter wrote:
>
>> I am working on this stuff now and am near a solution for the empty
>> datetime bug which is cleaner and more general. I'll populate tests
>> for this stuff so just let me know where to put the baselines.
>>
>
> H
John Hunter wrote:
> I must be missing something obvious, but I tried to add a new module
> to lib/matplotlib/tests called test_image, which has a single method
> so far, test_image_interps. I added the standard decorator and
> baseline image, and I can see it being installed in the stdio on the
>
John Hunter wrote:
> Perhaps with hinting turned off this won't be necessary. Ie, maybe we
> can get more agreement across a wide range of freetype versions w/o
> hinting. Are you planning on committing the unhinted baselines?
I have a presentation to give tomorrow, so I'd just as soon let you an
Michael Droettboom wrote:
> Doing so, my results are even *less* in agreement with the baseline, but
> the real question is whether my results are in agreement with those on
> the buildbot machines with this change to forcibly turn hinting off. I
> should no pretty quickly when the buildbots st
Michael Droettboom wrote:
> On 09/08/2009 10:24 AM, John Hunter wrote:
>
>> On Tue, Sep 8, 2009 at 8:54 AM, Michael Droettboom wrote:
>>
>>
>>> I've been only skimming the surface of the discussion about the new test
>>> framework up until now.
>>>
>>> Just got around to trying it, and
John Hunter wrote:
> I wrote a script at scipy when Andrew and I worked on this to
> recursively move known good actuals into the baselines directory, with
> some yes/no prompting, but it looks like it did not survive the test
> code migration, so we may want to develop something to replace it.
Yes
John Hunter wrote:
> On Tue, Sep 8, 2009 at 12:34 PM, Andrew Straw wrote:
>
>> Michael Droettboom wrote:
>>
>>> More information after another build iteration.
>>>
>>> The two tests that failed after updating to the unhinted images were
>>
Michael Droettboom wrote:
> Interesting result. I pulled all of the new "actual" files from the 21
> failing tests on the buildbots to my local machine and all of those
> tests now pass for me. Good. Interestingly, there are still two tests
> failing on my machine which did not fail on the bu
Michael Droettboom wrote:
> More information after another build iteration.
>
> The two tests that failed after updating to the unhinted images were
> subtests of tests that were failing earlier. If a single test
> function outputs multiple images, image comparison stops after the
> first mismatch
Michael Droettboom wrote:
> Yes -- a bug was introduced where non-finite values were no longer being
> ignored by the data extents finder. This has now been fixed on the
> 0.99.x branch (r7774) and the trunk.
>
Hi Mike,
This would seem like something useful to write a test for to make sure
t
Michael Droettboom wrote:
> Thanks. The subslicing optimization added in 0.99 was truncating the
> polar path. Subslicing has been made more "cautious" now and will only
> be applied when the axes are rectilinear and non-logarithmic.
>
> Interestingly, there was already a test in the test frame
David Warde-Farley wrote:
> On 18-Sep-09, at 6:42 PM, David Warde-Farley wrote:
>
>> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line
>> 627, in __init__
>> user_ns,user_global_ns,b2 =
>> self._matplotlib
Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
>
>> I am thinking about adding pdf comparison ability to compare_images. One
>> simple way to do this would be to convert pdf files to pngs using
>> Ghostscript: if we store reference pdf files, and both the reference
>> file and the result o
Jouni K. Seppänen wrote:
> Andrew Straw writes:
>
>
>> Michael Droettboom wrote:
>>
>>> We can probably standardize the version of gs on the buildbot machines,
>>> but it's been very useful up to now to have tests that can run on
Jouni K. Seppänen wrote:
> John Hunter writes:
>
>
>>>pyplot.savefig('foo1')
>>>
>> Take a look at the pyplot "switch_backends" function.
>>
>
> Yes, that function was on the next line after the part you quoted. :-)
> It calls matplotlib.use with warn=False, but that function en
John Hunter wrote:
> On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw wrote:
>
>
>> Sorry, I should have been more clear. I was thinking that the
>> image_compare() decorator would call the test function multiple times,
>> having switched the backend between inv
John Hunter wrote:
> On Wed, Sep 23, 2009 at 12:56 PM, Andrew Straw wrote:
>
>> John Hunter wrote:
>>
>>> On Wed, Sep 23, 2009 at 12:42 PM, Andrew Straw wrote:
>>>
>>>
>>>
>>>> Sorry, I should have been more clear.
Jouni K. Seppänen wrote:
> Jouni K. Seppänen writes:
>
>
>> I committed something based on this, and a new rc parameter
>> savefig.extension that sets the filename extension when you call savefig
>> with a bare filename. The pdf tests seem to be working, at least for me,
>> but I am sure that t
David Cournapeau wrote:
> Hi,
>
> I don't know if that's of any interest for matplotlib developers,
> but I added scripts to build matplotlib with numscons:
>
> http://github.com/cournape/matplotlib/tree/scons_build
>
> Not every configuration is supported yet, but I can successfully build
>
David Cournapeau wrote:
> I have a question about git as well, actually - I could not update the
> svn metadata, unfortunately, by using git-svn rebase -l (I used your
> branch on github and the instructions on matplotlib website). It gives
> me an awful lot of merging errors, which seems to indica
Eric Firing wrote:
> The only concern that occurs to me with respect to including both
> setup.py and setupscons.py is that when a module is added or removed,
> it means figuring out what to do with two systems instead of one. So
> the question is, will it make it easier or significantly harder fo
Andrew Straw wrote:
> David Cournapeau wrote:
>
>> I have a question about git as well, actually - I could not update the
>> svn metadata, unfortunately, by using git-svn rebase -l (I used your
>> branch on github and the instructions on matplotlib website). It giv
David Cournapeau wrote:
> Andrew Straw wrote:
>
>> Andrew Straw wrote:
>>
>>
>>> David Cournapeau wrote:
>>>
>>>
>>>
>>>> I have a question about git as well, actually - I could not update the
&
Jouni K. Seppänen wrote:
> Andrew Straw writes:
>
>
>> This test function is a generator that nose will then generate two test
>> cases out of. So, perhaps the image_comparison decorator could be
>> changed to become a generator? I'm not 100% sure it will work,
David Cournapeau wrote:
> Hi,
>
> I don't know if that's of any interest for matplotlib developers,
> but I added scripts to build matplotlib with numscons:
>
> http://github.com/cournape/matplotlib/tree/scons_build
>
Hi David,
I'm trying to download your git repository, but I'm having trou
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:
Hi, Thanks for the report. Do you have a simple test script that we can
use to see the problem and then fix it? We
Jouni K. Seppänen wrote:
> Jouni K. Seppänen writes:
>
>
>> Oh, right. My fault: when I implemented the pdf comparison, I made it
>> run the test for only those formats for which a baseline image exists,
>>
>
> I committed a change to make it run both png and pdf tests all the time.
>
tually requires the OS. And that would require
building on Snow Leopard to work, as I understand it.
-Andrew
>From d6ae15c5495930963d2d124bf3fc70e8bc6f80a9 Mon Sep 17 00:00:00 2001
From: Andrew Straw
Date: Fri, 9 Oct 2009 10:38:09 -0700
Subject: [PATCH] don't test simplification
---
.../
1 - 100 of 244 matches
Mail list logo
