Hi guys,
> You can now do:
>
> .. plot::
>
> from matplotlib.pyplot import *
> plot([1,2,3])
This is very nice - thank you for doing that.
But, thinking about the online tutorials, you often want to do
something as you can do with the sourcecode directive, as in:
.. testcode::
impor
Hi,
I am rashly building matplotlib from source on Snow Leopard, and
getting a segmentation fault as soon as I try and do a plot.
me $ python -c 'import pylab; pylab.plot(range(10))'
Segmentation fault
I've built python myself with:
export MACOSX_DEPLOYMENT_TARGET=10.6
./configure --prefix=/Use
> I am rashly building matplotlib from source on Snow Leopard, and
> getting a segmentation fault as soon as I try and do a plot.
>
> me $ python -c 'import pylab; pylab.plot(range(10))'
> Segmentation fault
Sorry - here the is top of the build output:
export PKG_CONFIG_PATH="/Users/mb312/usr/loc
Hi,
On Sun, Nov 29, 2009 at 1:30 AM, Jouni K. Seppänen wrote:
> Matthew Brett writes:
>
>> I am rashly building matplotlib from source on Snow Leopard, and
>> getting a segmentation fault as soon as I try and do a plot.
>
> Can you get a backtrace in gdb?
(gdb) r
Hi,
>> Can you get a backtrace in gdb?
>
> (gdb) run scipybuild/matplotlib/examples/pylab_examples/simple_plot.py
...
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: 13 at address: 0x
> 0x000102d96ffb in py_to_agg_transformation_matrix
> (obj=0x102d
On Sun, Nov 29, 2009 at 9:49 AM, Jouni K. Seppänen wrote:
> Matthew Brett
> writes:
>
>>> Can you get a backtrace in gdb?
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: 13 at address: 0x
>> 0x00010
Hi,
>> I've been having an almost identical problem with described above with
>> the MacOSX backend. When I switched to the TkAgg backend, the segfault
>> occurs when I try pylab.close() instead.
>>
> I may have had the same problem. Do you happen to be on a recent revision?
>
> Christoph Gohlke
Hi,
Can I suggest the following generalization in the make.osx make file?
It makes it a bit easier to configure for odd builds like mine...
Thanks a lot,
Matthew
generalize_mac_deployment.diff
Description: Binary data
Hi,
> Apart from being inflammatory, has anyone considered code.google.com (GC) as
> a solution?
;) - speaking as someone with no right to offer an opinion - please,
no. Google blocks Cuba from google code completely, for no obvious
reason, and a) that seems to me quite wrong and outside the s
Hi,
On Tue, Mar 2, 2010 at 10:17 PM, william ratcliff
wrote:
> I think there's a legal reason for the embargo--sourceforge apparently also
> has such a policy:
> http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/
> So, as a
Hi,
>> Multiple options (as far as I have understand github). You could use one
>> account with multiple ssh-keys or you can add "contributors" to the
>> repository
>> in the repositorys Admin-panel, which I haven't tried out, yet.
>
> The github TOS allow only one person per account. I guess tha
Hi,
Sorry to ask, but would y'all mind unblocking matlplotlib downloads from Cuba?
I just tried the download from here in Havana, and got:
403 Error – Forbidden
Your request is being denied as it appears to be coming from a
location banned by our Terms of Use.
That's because Sourceforge runs a
Hi,
>> That's because Sourceforge runs an opt-out blocking policy. If y'all
>> agree that there's no reason to block matplotlib downloads from Cuba,
>> China etc, would someone mind setting the 'this is not a cryptographic
>> program' setting in the sourceforge interface?
>
> Done.
>
> The releva
Hi,
On Sat, Oct 9, 2010 at 7:30 PM, Eric Firing wrote:
> https://sourceforge.net/tracker/?func=detail&aid=2973874&group_id=80706&atid=560720
>
> Would someone with a Mac please look at this bug and say whether it is
> occurring with our release of mpl? If not, I will close the ticket.
Not for m
Hi,
First - thank you - it makes my heart very glad to be able to do this:
.. plot::
:include-source:
import matplotlib.pyplot as plt
plt.plot(range(10))
plt.show()
Here's my question. This is already a huge step forward for me, but
the full monty would be to be able to do:
.
Hi,
On Mon, Nov 8, 2010 at 7:06 PM, John Hunter wrote:
> On Mon, Nov 8, 2010 at 6:55 PM, Matthew Brett wrote:
...
>> and so on. I mean, the ability to keep the code context across the
>> page, both in the ..plot: and ..testcode:: and even >>> directives, so
>&
Hi,
>> >> What have been the proposed solutions to dealing with basemap's data?
>> >
>> > Separate repo?
I just fished up some previous discussions:
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8275
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8461
Do I remember
Yo,
On Fri, Feb 25, 2011 at 12:02 PM, Fernando Perez wrote:
> On Fri, Feb 25, 2011 at 11:48 AM, Darren Dale wrote:
>> On Fri, Feb 25, 2011 at 2:43 PM, Ryan May wrote:
>
>>> Agreed in principle. However, do we as devs want to get/give reviews
>>> on every change that fixes typos in the docs or f
Hi,
On Sat, Feb 26, 2011 at 4:30 AM, Michiel de Hoon wrote:
>> In any case it appears that with the exception of Tkinter, it may take a
>> long time before interactive mpl backends can be used with py3k.
>
> The MacOSX backend has already been ported to Py3k (at least the C part of
> it, which i
Hi,
On Sat, Feb 26, 2011 at 6:23 AM, Pauli Virtanen wrote:
> On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
> [clip]
>> Yes. The minimum version for this Python 3.x compatibility work is
>> Python 2.6. Anything earlier is just insane ;)
>
> Out of curiosity: did you consider usin
Hi Paul,
On Thu, Mar 24, 2011 at 2:55 AM, Paul Ivanov wrote:
> Paul Ivanov, on 2011-03-24 01:30, wrote:
>> I offer my sincerest apologies, I royally screwed up and thought
>> that I was pushing out to one of my own branches and somehow
>> ended up pushing a 2 day old copy of master out to
>> mat
Yo,
On Mon, Mar 28, 2011 at 8:17 AM, Michael Droettboom wrote:
> There's also this git command I just discovered. It seems to solve all of
> these issues, and the documentation is written in the same crystal-clear
> style of the other git manpages:
>
> http://wingolog.org/archives/2011/03/28/g
Hi,
On Wed, Mar 30, 2011 at 12:06 PM, James Evans wrote:
> Hello All,
>
>
>
> I am finally getting around to checking out a local copy of the git
> repository following the directions here:
>
> http://matplotlib.github.com/devel/gitwash/set_up_fork.html
>
>
>
> and I keep getting the following er
Hi,
On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing wrote:
>> The current practice worked very nicely with SVN (IMHO), and I think it
>
> (I recall that Mike had to rescue us more than once from svnmerge
> confusions, at least during the earlier days.)
I was just idly looking at the matplotlib netw
Hi,
On Wed, Jun 1, 2011 at 4:05 PM, Darren Dale wrote:
> On Wed, Jun 1, 2011 at 6:38 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing wrote:
>>>> The current practice worked very nicely with SVN (IMHO), and I think it
>>
Hi,
On Wed, Jun 1, 2011 at 4:06 PM, Eric Firing wrote:
> On 06/01/2011 12:38 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Wed, Jun 1, 2011 at 12:58 PM, Eric Firing wrote:
>>>> The current practice worked very nicely with SVN (IMHO), and I think it
>>>
>
Hi,
On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale wrote:
> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote:
...
>> Even without the foulup, I think you would see that the merges from
>> maintenance branches into subsequent branches and into master make it
>> very hard to figure out what has actu
Hi,
On Thu, Jun 2, 2011 at 7:06 PM, Darren Dale wrote:
> Matthew,
>
> On Thu, Jun 2, 2011 at 8:17 PM, Matthew Brett wrote:
>> Hi,
>>
>> On Thu, Jun 2, 2011 at 5:07 PM, Darren Dale wrote:
>>> On Thu, Jun 2, 2011 at 7:46 PM, Eric Firing wrote:
>> ...
hat's developer
X working on today?).
Less tempting
--
Just as a minor example, here's my nipy branch list:
https://github.com/matthew-brett/nipy/branches
Lots of crap in there; I just made a branch with a single extra commit
that I may well throw away, the branch I'm current
Hi,
On Wed, Aug 31, 2011 at 8:37 PM, John Hunter wrote:
> On Wed, Aug 31, 2011 at 10:16 PM, Matthew Brett
> wrote:
>> Yo,
>>
>> On Wed, Aug 31, 2011 at 7:54 PM, John Hunter wrote:
>>> github workflow: this seems to present a different workflow than that
>&g
Hi,
On Tue, Sep 6, 2011 at 8:38 AM, Michael Droettboom wrote:
> I think most of the points being made here are valid. However, a common
> occurrence (at least for me) is for a user to struggle against a bug
> that I'm currently working on in one of my branches. Looking at the
> main repository,
> I have never run into a problem with relative imports, though I don't
> object to removing them. Why are they bad style and what is the danger?
I had assumed because it would not be as obvious that the imports were
local modules, but might be wrong...
Best,
Matthew
--
Hi,
I'm testing the binary installer build:
https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220
and I'm getting a test failure on Python 3.3 (not Python 2.7):
=
Hi,
On Fri, Oct 18, 2013 at 4:47 AM, Michael Droettboom wrote:
> On 10/18/2013 02:11 AM, Matthew Brett wrote:
>> Hi,
>>
>> I'm testing the binary installer build:
>>
>> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220
>>
>>
erry's example, I'm testing the builds and then the
installers here:
https://travis-ci.org/matthew-brett/mpl-osx-binaries
It would be great if you could give them a try.
Cheers,
Matthew
--
October Webinars: Code
Hi,
On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen wrote:
> In article
> ,
> Matthew Brett
> wrote:
>
>> Hi Chris,
>>
>> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
>> wrote:
>> > Are there recent binaries for OS-X anyw
o (something odd with wx back end re-rendering,
> but I doubt that's a Mac build issue...)
>
> I tok a quick look at your waf scripts and I couldn't tell how you are
> handling the external compiled dependencies (png, zlib, freetype) --
> are these statically linked in?
Hi,
Very sorry to miss this one - I'm in Cuba at the moment - if Google
doesn't block hangouts, then there would not be enough bandwidth.
Sorry not to get to setting up buildbot testing. Paul - do you have
time for that?
Cheers,
Matthew
On Thu, Nov 14, 2013 at 5:57 PM, Paul Ivanov wrote:
> Mi
Hi,
Prompted by Chris B, I just added matplotlib wheels building to the
framework here:
https://github.com/matthew-brett/mpl-osx-binaries
Instructions for build in the README.
Sorry - am In Cuba at the moment with very low internet bandwidth and
can't upload the wheels, but they shou
Hi,
I just noticed that the installation page points to the old github
download page:
http://matplotlib.org/users/installing.html
https://github.com/matplotlib/matplotlib/downloads
I think it should point to the website download page:
http://matplotlib.org/downloads.html
Is that right?
https
Hi,
On Sat, Dec 14, 2013 at 12:28 PM, Matthew Brett wrote:
> Hi,
>
> Prompted by Chris B, I just added matplotlib wheels building to the
> framework here:
>
> https://github.com/matthew-brett/mpl-osx-binaries
>
> Instructions for build in the README.
>
> Sorry -
Hi,
On Sun, Mar 23, 2014 at 1:46 AM, Matthew Brett wrote:
> Hi,
>
> On Sat, Dec 14, 2013 at 12:28 PM, Matthew Brett
> wrote:
>> Hi,
>>
>> Prompted by Chris B, I just added matplotlib wheels building to the
>> framework here:
>>
>> h
Hi,
On Mon, Mar 24, 2014 at 6:29 AM, Benjamin Root wrote:
> I thought we fixed this one...
>
> Seems like we haven't as there is an open issue for it:
> https://github.com/matplotlib/matplotlib/issues/2842
Sorry - I didn't say - but the wheels are for the 1.3.1 release...
Cheers,
Matthew
Hi,
I've built and tested some binary wheels for OSX - available here:
https://nipy.bic.berkeley.edu/scipy_installers/
I'd really like to upload these to pypi so that people get them by
default with 'pip install matplotlb'. Is that OK? Can someone give
me permission to do that?
Thanks a lot,
Hi,
I've just uploaded binary wheels for OSX to pypi.
If you're on Python.org python, then this should work
pip install --upgrade pip # if you're not on latest pip already
pip install matplotlib
I mean - you should get the binary wheel for matplotlib.
If fact this wheel will also work for Mac
ems.
The page above explains why the wheels I built are compatible with the
other Pythons, and this test grid:
https://travis-ci.org/matthew-brett/scipy-stack-osx-testing/builds/26482436
confirms that the renamed wheels install and test OK on homebrew,
macports, system python.
So, I propose t
Hi,
On Mon, Jun 2, 2014 at 5:14 PM, Chris Barker wrote:
> On Mon, Jun 2, 2014 at 11:48 AM, Matthew Brett
> wrote:
>>
>> I want to rename the matplotlib wheel OSX wheel files on pypi so they
>> will also install into homebrew, macports and system python.
>
>
> +1
Hi,
On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen wrote:
> In article
> ,
> Chris Barker wrote:
>
>> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett
>>
>> wrote:
>>
>> > > what is this going to do on OS-X 10.7 and 10.8 systems running homebre
ing of the thread. I propose to do that tomorrow unless
anyone can think of a reason not to.
Cheers,
Matthew
[1] https://github.com/matthew-brett/numpy-atlas-binaries
[2] https://travis-ci.org/matthew-brett/scipy-stack-osx-testing
-
On Fri, Jun 20, 2014 at 12:01 PM, Matthew Brett wrote:
> Hi,
>
> On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker wrote:
>> On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen wrote:
>>>
>>> What I need is a python, numpy, and matplotlib that support 32-bit and
>>
Hi,
On Wed, Jun 25, 2014 at 4:49 PM, wrote:
> Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz.
>
> kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py
>
> Keith
>
>
> From: ben.v.r...@gmail.com [ben.v.r...@gmail.com]
Hi,
I am happily using `plot_directive`, but I've run into an
inconvenience when using the 'context' option. Consider this rst
file:
```
###
A title
###
.. plot::
:context:
import matplotlib.pyplot as plt
plt.plot(range(10))
Then some text.
.. plot::
:context:
pl
heels.scikit-image.org/
Wheels built via travis-ci from
https://github.com/matthew-brett/matplotlib-wheels.
Usual procedure:
pip install -f http://wheels.scikit-image.org --pre matplotlib
Please do send feedback.
Chee
Hi,
Sorry for the repost - just in case OSX users out there missed it...
We have automatically built OSX wheels for the upcoming release here:
http://wheels.scikit-image.org/
Wheels built via travis-ci from
https://github.com/matthew-brett/matplotlib-wheels.
Usual procedure:
pip install -f
improved the install documentation enough, and to make sure that docs
> for backend_bases gets added to sphinx) and the re-design of the front
> page.
Thanks for doing this.
I did a full test against the scipy stack:
https://travis-ci.org/matthew-brett/scipy-stack-osx-testing/builds/32131131
It turns
Hi,
On 8/22/14, Thomas Caswell wrote:
> Are we planning to make and distribute .dmg (damage?!?) files for 1.4?
> If so who is making them? If not, we should remove that section form
> `installing_faq.rst`.
I can build them, but they are a bit frightening because they
unconditionally replace an
Sorry - I accidentally sent this reply just to Nathaniel - returning
to this as it bit me again:
On 7/14/14, Nathaniel Smith wrote:
> Wouldn't a better default be to just close all figures when they're
> displayed? It can't be common that someone wants to show the same plot
> repeatedly (and if t
Hi,
On Tue, Oct 28, 2014 at 12:15 PM, Benjamin Root wrote:
> Yeah, put together a PR, and we can evaluate it better that way. I think the
> current plot directive behavior might need this sort of tightening up
Thanks for the feedback, sorry for the delay:
https://github.com/matplotlib/matplotli
Hi,
On Mon, Feb 2, 2015 at 2:58 AM, Jens Nielsen wrote:
> Thanks Tom,
>
> I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2 including
> the tex and QT4 tests that are skipped on Travis.
> Everything passes as expected.
I built wheels for OSX testing, via the automated travis bui
Hi,
On Mon, Feb 16, 2015 at 10:53 AM, Nelle Varoquaux
wrote:
>
> IMO, never.
Rationale, please?
>>>
>>>
>>> Consistency: it is never capitalized in matplotlib's documentation.
>>
>>
>> True, and a valid point--but we could easily change that. Wouldn't it make
>> it bit mor
Hi,
On Mon, Feb 16, 2015 at 1:26 PM, Paul Kuin wrote:
> Ah, since it is a proper name it should be capitalised, but it never was. I
> think that it should remain uncapitalised and that you want to propose an
> alternative, like a change in type for the proper name matplotlib. Could be
> typescri
61 matches
Mail list logo
