Re: [matplotlib-devel] Plot line style cycle?
On Sun, Aug 28, 2011 at 11:44 AM, Benjamin Root wrote: > > > On Friday, August 26, 2011, Benjamin Root wrote: > > Just brain-storming here... What about two rcparams: cycle.color = true > and cycle.style = false? > > > > This way, cycling for both colors and line styles could be turned on and > off accordingly. Then, a b&w mode could utilize this. as well as possibly > substitute default values. > > > > Ben Root > > Taking it a step further, a cycle for markers would be nice, too. > > Ben Root > I went ahead and started up a branch to test this idea out. I am not doing a pull request on this yet because there are a lot of style issues (names of rcParams and such), as well as the potential for easily producing lots of redundant code if we expand this idea to other things like markers, fill styles and such. Here is the branch: https://github.com/WeatherGod/matplotlib/tree/cycles Let me know what you think! This branch does give me enough control to solve my immediate problem by setting the following rcParams: # B&W mode axes.color_cycle = 'k' style.cycle = True Cheers! Ben Root -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] boilerplate.py
Hello all, In my continuing quest to get style cycles working, I wanted to get errorbar() to support it as well. Unfortunately, errorbar() has a default kwarg 'fmt' that takes a value of '-', and *None* already has a special meaning in errorbar(). Therefore, I wanted to determine if the user wants to use the stylecycle by seeing if 'fmt' does not get specified in the call to errorbar(). This requires removing the 'fmt' kwarg from the call signature for errorbar() in axes.py. Of course, changing the call signature for errorbar() in axes.py would require changing the call signature in pyplot.py. But this is supposed to be done by boilerplate.py. How/when during the build does this file get called? Also, pyplot.py is under revision control, so it seems to be a bit odd to have auto-generated files under revision control (or is it just me?). Is boilerplate.py antiquated? Should we give it another look after the v1.1 release? Cheers! Ben Root -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] boilerplate.py
On Wed, Aug 31, 2011 at 7:34 PM, Benjamin Root wrote: > Hello all, > > In my continuing quest to get style cycles working, I wanted to get > errorbar() to support it as well. Unfortunately, errorbar() has a default > kwarg 'fmt' that takes a value of '-', and *None* already has a special > meaning in errorbar(). Therefore, I wanted to determine if the user wants > to use the stylecycle by seeing if 'fmt' does not get specified in the call > to errorbar(). This requires removing the 'fmt' kwarg from the call > signature for errorbar() in axes.py. > > Of course, changing the call signature for errorbar() in axes.py would > require changing the call signature in pyplot.py. But this is supposed to > be done by boilerplate.py. How/when during the build does this file get > called? Also, pyplot.py is under revision control, so it seems to be a bit > odd to have auto-generated files under revision control (or is it just me?). > > Is boilerplate.py antiquated? Should we give it another look after the v1.1 > release? boilerplate is called manually when you want to add a new function to pyplot, and you manually remove all the lines from pyplot.py from the first instance of # This function was autogenerated by boilerplate.py. Do not edit as # changes will be lost to the end, and replace it with the output of boilerplate.py. We could automate this, or make it better, eg by having boilerplate.py generate some module like _pyplot_boilerplate.py and having pyplot do an import * from that, but for now you can just do it the manual way if you prefer, JDH -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Issue with colored latex text on plots
Hi,
I'm trying to generate colored text on my plots, but can only seem
to get black and white. I've attached an example python scriptx
(test.py) that demonstrates the problem. This produces a plot
(test.png) with black and white text even though I've explicitly told
latex to use color, and in fact the intermediate image gets colored
correctly (attached 25a9904ac88febf5f01477f069213537.png file taken
from .matplotlib/tex.cache). I'm currently using matplotlib 0.99.3.
Thanks for any help with this issue.
Note that I'm not subscribed to this list, so please CC me on replies.
Best wishes,
Mike
#!/usr/bin/python
import numpy , pylab
x = numpy.arange( 0.0 , 5.0 )
pylab.rc( 'text' , usetex=True )
pylab.rc( 'text.latex' , preamble='\usepackage[usenames]{color}' )
pylab.title( '\\textcolor{Blue}{colored title wanted}' )
pylab.plot( x )
pylab.savefig( 'test.png' )
<><>--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Issue with colored latex text on plots
On Sat, Aug 27, 2011 at 4:15 PM, Michael Gilbert
wrote:
> Hi,
>
> I'm trying to generate colored text on my plots, but can only seem
> to get black and white. I've attached an example python scriptx
> (test.py) that demonstrates the problem. This produces a plot
> (test.png) with black and white text even though I've explicitly told
> latex to use color, and in fact the intermediate image gets colored
> correctly (attached 25a9904ac88febf5f01477f069213537.png file taken
> from .matplotlib/tex.cache). I'm currently using matplotlib 0.99.3.
> Thanks for any help with this issue.
>
> Note that I'm not subscribed to this list, so please CC me on replies.
That won't work because mpl converts all tex png raster to black and
white and handles color on its own in post-processing. The following
does work:
import numpy , pylab
x = numpy.arange( 0.0 , 5.0 )
pylab.rc( 'text' , usetex=True )
pylab.title( r'$\rm{colored\ title\ wanted}$', color='blue' )
pylab.plot( x )
pylab.savefig( 'test.png' )
pylab.show()
>
> Best wishes,
> Mike
>
> --
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Issue with colored latex text on plots
On Wed, Aug 31, 2011 at 8:49 PM, John Hunter wrote:
>> Note that I'm not subscribed to this list, so please CC me on replies.
>
> That won't work because mpl converts all tex png raster to black and
> white and handles color on its own in post-processing. The following
> does work:
>
> import numpy , pylab
>
> x = numpy.arange( 0.0 , 5.0 )
> pylab.rc( 'text' , usetex=True )
> pylab.title( r'$\rm{colored\ title\ wanted}$', color='blue' )
> pylab.plot( x )
> pylab.savefig( 'test.png' )
> pylab.show()
But since you set usetex, you shouldn't need the $ escapes and the
literal rm font. It should be enough to do:
pylab.title( r'colored title wanted 2.5', color='blue' )\
JDH
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] github workflow
github workflow: this seems to present a different workflow than that espoused in gitwash used by mpl and other projects http://scottchacon.com/2011/08/31/github-flow.html I like the idea of lots of feature branches off upstream/master and master always being deployable (nightly builds?). What is the advantage of core devs working in their own forks, as we currently do, over working on feature branches off of https://github.com/matplotlib/matplotlib? Seems like a lighter-weight approach that works, and it would probably make it easier for users to follow mpl development by tracking the mpl repo and all the branches off of it, rather than having to pull in the various dev's forked branches. -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
Yo, On Wed, Aug 31, 2011 at 7:54 PM, John Hunter wrote: > github workflow: this seems to present a different workflow than that > espoused in gitwash used by mpl and other projects > > http://scottchacon.com/2011/08/31/github-flow.html > > I like the idea of lots of feature branches off upstream/master and > master always being deployable (nightly builds?). What is the > advantage of core devs working in their own forks, as we currently do, > over working on feature branches off of > https://github.com/matplotlib/matplotlib? Seems like a lighter-weight > approach that works, and it would probably make it easier for users to > follow mpl development by tracking the mpl repo and all the branches > off of it, rather than having to pull in the various dev's forked > branches. The issue being - why not have all the development branches in the same main repo? Because: a) Everyone needs write access to the main repo b) It's much less tempting to start experimental and highly unstable branches c) You can get a very similar effect by adding remotes to your own repo. d) It only very slightly simplifies an unusual case (what'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 currently working on: https://github.com/matthew-brett/nipy/tree/fmristat-test-refactor - I am constantly rebasing and reorganizing while I try to work out what I'm doing. I'd think much harder about that if I thought other people were expecting to pull down all my stuff. Thinking harder = slower coding (for me at least :)) Similar effect - I'd like to see what Gael and Jonathan Taylor are up to from time to time: Once: git clone g...@github.com:matthew-brett/nipy.git # origin remote git remote add gael git://github.com/GaelVaroquaux/nipy.git git remote add jonathan git://github.com/jtaylor/nipy.git >From time to time: git fetch --all - same effect, and it allows me to chose who I'm following. But actually, I very rarely do that in the abstract, I look when they tell me to look at something, and I'm pretty sure it's the same for them and my stuff. See you, Matthew -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
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 > > espoused in gitwash used by mpl and other projects > > > > http://scottchacon.com/2011/08/31/github-flow.html > > > > I like the idea of lots of feature branches off upstream/master and > > master always being deployable (nightly builds?). What is the > > advantage of core devs working in their own forks, as we currently do, > > over working on feature branches off of > > https://github.com/matplotlib/matplotlib? Seems like a lighter-weight > > approach that works, and it would probably make it easier for users to > > follow mpl development by tracking the mpl repo and all the branches > > off of it, rather than having to pull in the various dev's forked > > branches. > > The issue being - why not have all the development branches in the > same main repo? > > Because: > > a) Everyone needs write access to the main repo > b) It's much less tempting to start experimental and highly unstable > branches > c) You can get a very similar effect by adding remotes to your own repo. > d) It only very slightly simplifies an unusual case (what'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 currently working on: > > https://github.com/matthew-brett/nipy/tree/fmristat-test-refactor > > - I am constantly rebasing and reorganizing while I try to work out > what I'm doing. I'd think much harder about that if I thought other > people were expecting to pull down all my stuff. Thinking harder = > slower coding (for me at least :)) > > Similar effect > > > - I'd like to see what Gael and Jonathan Taylor are up to from time to > time: > > Once: > git clone g...@github.com:matthew-brett/nipy.git # origin remote > git remote add gael git://github.com/GaelVaroquaux/nipy.git > git remote add jonathan git://github.com/jtaylor/nipy.git > > >From time to time: > git fetch --all > > - same effect, and it allows me to chose who I'm following. But > actually, I very rarely do that in the abstract, I look when they tell > me to look at something, and I'm pretty sure it's the same for them > and my stuff. > > See you, > > Matthew > > I agree with Matthew here, but I could see a possible hybrid approach. Let's say we were a more organized group (I will wait for the laughter to die down...), then one could imagine having branches with names of approved milestones/goals/planned features for the next release. The names would convey the features actively being worked on, and provide a focus for us. When a feature is finished, we then merge into master. If a feature is not ready for prime-time, then we can just hold it off. Just a thought, Ben Root -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
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 >> espoused in gitwash used by mpl and other projects >> >> http://scottchacon.com/2011/08/31/github-flow.html >> >> I like the idea of lots of feature branches off upstream/master and >> master always being deployable (nightly builds?). What is the >> advantage of core devs working in their own forks, as we currently do, >> over working on feature branches off of >> https://github.com/matplotlib/matplotlib? Seems like a lighter-weight >> approach that works, and it would probably make it easier for users to >> follow mpl development by tracking the mpl repo and all the branches >> off of it, rather than having to pull in the various dev's forked >> branches. > > The issue being - why not have all the development branches in the > same main repo? > > Because: > > a) Everyone needs write access to the main repo I'm thinking about core devs here -- they all have write access to the main repo. Users and non core devs can continue with the fork approach. > b) It's much less tempting to start experimental and highly unstable branches This can still be done in forks. And experimental and unstable branches are a minor threat -- they may increase the signal-to-noise, but dead branches can be pruned and users and devs can probably get a pretty good feel for which are active by looking at the "last update" time on the branch list. > c) You can get a very similar effect by adding remotes to your own repo. Yes, I do this and I'm sure other mpl developers do to, but you need to know who to follow, which is harder for the casual developer or user. By having the core devs develop in feature branches off of upstream, it makes it easier for users and other developers to see what all the other cores devs are up to w/o having to specify who to track. They track the main repo, they see the main work of the core devs as they come and go. > d) It only very slightly simplifies an unusual case (what's developer > X working on today?). I think it simplifies it dramatically, because the average user or part time developer doesn't have to ask "which developers should I follow?" and do the work to add them to externals. They can assume that by tracking the upstream branches, they see the important non-experimental branches the core developers are working on. It is easy to follow developer X if you know a priori who X is. But since 95% of the work is done by people who have write access to the central repo, and 95% of the users want to track this, it makes sense to me to push more of the workflow into the central repo, while still supporting external contributions via pull requests from forks. Maybe I'm missing something, but I feel the gitwash workflow is more complicated than it needs to be and this article re-inforces that view. JDH -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Matplotlib 1.0.1 Tk backend
On 08/31/2011 05:00 PM, Trevor J Christensen wrote: > I went here: > > http://matplotlib.sourceforge.net/api/index_backend_api.html > > and didn't see tkagg listed. > > Trevor Trevor, Thank you. It is still missing from the devel branch, along with several others. I can see how this could cause some confusion. Maybe we can get it fixed before the next release, maybe not. Part of the problem here is that auto-generation of docs saves a huge amount of work, but can also lead to problems, of which this is just one example. Eric > > > - Original Message - > From: "Eric Firing" > To: matplotlib-us...@lists.sourceforge.net > Sent: Wednesday, August 31, 2011 10:33:45 AM > Subject: Re: [Matplotlib-users] Matplotlib 1.0.1 Tk backend > > On 08/31/2011 04:01 AM, Trevor J Christensen wrote: >> In preparing to upgrade from 0.99 to 1.0.1, I was reading the online >> documentation about the various backends. I do not see a TkAgg backend >> listed. Is that because there is no longer a backend for Tk? Has support >> for Tk been dropped in 1.0.1? Or has it not yet been added to the >> documentation? >> >> Trevor > > Trevor, > > Where did you expect to find it, but not see it? > > Eric > > > -- > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > ___ > Matplotlib-users mailing list > matplotlib-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
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 >>> espoused in gitwash used by mpl and other projects >>> >>> http://scottchacon.com/2011/08/31/github-flow.html >>> >>> I like the idea of lots of feature branches off upstream/master and >>> master always being deployable (nightly builds?). What is the >>> advantage of core devs working in their own forks, as we currently do, >>> over working on feature branches off of >>> https://github.com/matplotlib/matplotlib? Seems like a lighter-weight >>> approach that works, and it would probably make it easier for users to >>> follow mpl development by tracking the mpl repo and all the branches >>> off of it, rather than having to pull in the various dev's forked >>> branches. >> >> The issue being - why not have all the development branches in the >> same main repo? >> >> Because: >> >> a) Everyone needs write access to the main repo > > I'm thinking about core devs here -- they all have write access to the > main repo. Users and non core devs can continue with the fork > approach. Will you document both workflows? Will the core-devs have to keep track of two working sets that belong to them, some in forks and some on the main repo? Will you document what criteria the core-devs should use for this transfer? I suppose I can see that the one-repo workflow would make sense for 20 people in the same building working on a private repo, but, for y'all, with people coming in all the time saying, hey, I've got a patch, and much less direct contact between the developers, I'd be really surprised if it wasn't substantially more complicated than what you have. >> b) It's much less tempting to start experimental and highly unstable branches > > This can still be done in forks. And experimental and unstable > branches are a minor threat -- they may increase the signal-to-noise, > but dead branches can be pruned and users and devs can probably get a > pretty good feel for which are active by looking at the "last update" > time on the branch list. Right - or follow Benjamin's suggestion, which seems very reasonable, of having one or two sensible branches in your main repo, like, master (maybe always deployable) and feature-several-of-us-are-working on, and just do pull requests from forks into whichever one make sense. >> c) You can get a very similar effect by adding remotes to your own repo. > > Yes, I do this and I'm sure other mpl developers do to, but you need > to know who to follow, which is harder for the casual developer or > user. By having the core devs develop in feature branches off of > upstream, it makes it easier for users and other developers to see > what all the other cores devs are up to w/o having to specify who to > track. They track the main repo, they see the main work of the core > devs as they come and go. > >> d) It only very slightly simplifies an unusual case (what's developer >> X working on today?). > > I think it simplifies it dramatically, because the average user or > part time developer doesn't have to ask "which developers should I > follow?" and do the work to add them to externals. They can assume > that by tracking the upstream branches, they see the important > non-experimental branches the core developers are working on. It is > easy to follow developer X if you know a priori who X is. But since > 95% of the work is done by people who have write access to the central > repo, and 95% of the users want to track this, it makes sense to me to > push more of the workflow into the central repo, while still > supporting external contributions via pull requests from forks. I'm the core dev on a couple of projects, and I almost never want the thing that you want, which is to see what everyone is working on right now. I don't think I've knowingly come across the user who is a) not up to adding remotes to the repo and b) will benefit from seeing or want to see what everyone is working on. I'm not saying they aren't out there, it's just not something I've considered. > Maybe I'm missing something, but I feel the gitwash workflow is more > complicated than it needs to be and this article re-inforces that > view. I'm missing it though - isn't the article describing a work-flow substantially the same as gitwash? That's what I meant in my reply, the one-repo thing is - as far as I can see - only a minor difference from what you have. Is that what you meant? Just the one-repo thing? See you, Matthew -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http
