You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Neil G. <mis...@gm...> - 2015-05-14 02:14:39
|
Thanks, it works! I needed to add: import matplotlib.patches to one file and plt.show() to the other. Any word on the locations in the code of the seven arrow drawing methods? I've located the arrow drawing code in tikz, and so I can start porting it over. I'm curious, do we know the linewidth of the edge being decorated by the arrow? To make arrows scale nicely, most of the arrow dimensions are given in two pieces: an absolute value (in points for example) and a line width factor. The dimension is the absolute value plus the line width factor times the line width. The TikZ manual explains: "This makes it easy to vary the size of an arrow tip in accordance with the line width – usually a very good idea since thicker lines will need thicker arrow tips." Best, Neil On Wed, May 13, 2015 at 10:07 PM, Benjamin Reedlunn <bre...@gm...> wrote: > Neil, > > I have attached code to draw the arrowhead. > > -Ben > > > > On May 13, 2015, at 7:44 PM, Neil Girdhar <mis...@gm...> wrote: > > Do you have the code that you used to draw the arrowhead? I'm up to date > now on the development workflow ( > http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm > ready to start working. > > Thanks, > > Neil > > On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn <bre...@gm...> > wrote: > >> Yes, I fully agree that we need to unify the many different ways to draw >> arrows. >> >> Neil, in case an example would be helpful for you, I have attached a >> module that includes a custom arrowhead class. The arrowhead class works >> with the with the ax.annotate() method. (I like the annotate method >> because it allows me to easily mix and match coordinate systems for arrow >> placement.) As you can see in the attached pdf, the custom arrowhead >> doesn't include fancy Bezier curves, but that could be added. >> >> -Ben >> >> >> >> On May 13, 2015, at 2:54 PM, Thomas Caswell <tca...@gm...> wrote: >> >> The other thing that should be done is to unify the (I think 7?!?) unique >> ways to draw arrows in mpl. >> >> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar <mis...@gm...> >> wrote: >> >>> Yes, I just noticed that as well. That's how the tikz pgf code looks (a >>> sequence of line_to and curve_to commands and so on) so it should be easy >>> to port over the various shapes. >>> >>> On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...> wrote: >>> >>>> On 2015/05/13 10:12 AM, Neil Girdhar wrote: >>>> >>>>> If you want to make arrowheads look at all decent, they really need to >>>>> be enclosed in Bezier curves. See the diagram here: >>>>> >>>> >>>> Mpl paths support Bezier curves. >>>> http://matplotlib.org/api/path_api.html?highlight=bezier >>>> >>>> >>>>> >>>>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 >>>>> >>>>> The first two look like garbage. The last one is the only one that >>>>> looks good imho. >>>>> >>>> >>>> That depends on the application, and the observer. >>> >>> >>> Sure, but I may as well port them all of the tikz arrowheads over since >>> most of the work would be figuring out how to do it. >>> >>> >>>> >>>> >>>> Eric >>>> >>>> >>>>> Best, >>>>> >>>>> Neil >>>>> >>>>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... >>>>> <mailto:ef...@ha...>> wrote: >>>>> >>>>> On 2015/05/13 9:36 AM, Neil Girdhar wrote: >>>>> >>>>> I don't know matplotlib well enough (yet) to know what the >>>>> change would >>>>> consist of. >>>>> >>>>> I suggest you take a look at the beautiful tikz manual: >>>>> http://pgf.sourceforge.net/pgf_CVS.pdf >>>>> >>>>> >>>>> Very helpful, thank you. >>>>> >>>>> >>>>> The arrows.meta on page 201–212 are really well-designed and >>>>> beautiful. >>>>> >>>>> Compare this with matplotlib's custom arrows: >>>>> >>>>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate >>>>> >>>>> How do I make tikz's arrowheads available for all backends? >>>>> >>>>> >>>>> My guess offhand is that this is a matter of using the mpl API. I >>>>> don't think we would want to add all of these types and options to >>>>> the mpl core; but a toolkit might be ideal for this. The mpl API, >>>>> which generates the same results for all backends, is quite >>>>> complete >>>>> and flexible. Things like arrowheads are Patch objects, and you >>>>> can >>>>> specify any path you want. The main trick is figuring out how to >>>>> handle transforms--what kind of coordinates should the path be >>>>> specifying? How should things scale as a figure is reshaped and >>>>> resized? >>>>> >>>>> For many of these types you could also use mpl Line2D objects, for >>>>> which several properties including cap style can be specified. Not >>>>> all of the TikZ options would be available, but perhaps enough. >>>>> >>>>> Eric >>>>> >>>>> >>>>> >>>> >>> ------------------------------------------------------------------------------ >>> One dashboard for servers and applications across Physical-Virtual-Cloud >>> Widest out-of-the-box monitoring support with 50+ applications >>> Performance metrics, stats and reports that give you Actionable Insights >>> Deep dive visibility with transaction tracing using APM Insight. >>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >>> _______________________________________________ >>> Matplotlib-devel mailing list >>> Mat...@li... >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >>> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> >> >> > > > |
From: Benjamin R. <bre...@gm...> - 2015-05-14 02:07:58
|
Neil, I have attached code to draw the arrowhead. -Ben On May 13, 2015, at 7:44 PM, Neil Girdhar <mis...@gm...> wrote: > Do you have the code that you used to draw the arrowhead? I'm up to date now on the development workflow (http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm ready to start working. > > Thanks, > > Neil > > On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn <bre...@gm...> wrote: > Yes, I fully agree that we need to unify the many different ways to draw arrows. > > Neil, in case an example would be helpful for you, I have attached a module that includes a custom arrowhead class. The arrowhead class works with the with the ax.annotate() method. (I like the annotate method because it allows me to easily mix and match coordinate systems for arrow placement.) As you can see in the attached pdf, the custom arrowhead doesn't include fancy Bezier curves, but that could be added. > > -Ben > > > > On May 13, 2015, at 2:54 PM, Thomas Caswell <tca...@gm...> wrote: > >> The other thing that should be done is to unify the (I think 7?!?) unique ways to draw arrows in mpl. >> >> On Wed, May 13, 2015 at 4:52 PM Neil Girdhar <mis...@gm...> wrote: >> Yes, I just noticed that as well. That's how the tikz pgf code looks (a sequence of line_to and curve_to commands and so on) so it should be easy to port over the various shapes. >> >> On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...> wrote: >> On 2015/05/13 10:12 AM, Neil Girdhar wrote: >> If you want to make arrowheads look at all decent, they really need to >> be enclosed in Bezier curves. See the diagram here: >> >> Mpl paths support Bezier curves. >> http://matplotlib.org/api/path_api.html?highlight=bezier >> >> >> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 >> >> The first two look like garbage. The last one is the only one that >> looks good imho. >> >> That depends on the application, and the observer. >> >> Sure, but I may as well port them all of the tikz arrowheads over since most of the work would be figuring out how to do it. >> >> >> >> Eric >> >> >> Best, >> >> Neil >> >> On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... >> <mailto:ef...@ha...>> wrote: >> >> On 2015/05/13 9:36 AM, Neil Girdhar wrote: >> >> I don't know matplotlib well enough (yet) to know what the >> change would >> consist of. >> >> I suggest you take a look at the beautiful tikz manual: >> http://pgf.sourceforge.net/pgf_CVS.pdf >> >> >> Very helpful, thank you. >> >> >> The arrows.meta on page 201–212 are really well-designed and >> beautiful. >> >> Compare this with matplotlib's custom arrows: >> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate >> >> How do I make tikz's arrowheads available for all backends? >> >> >> My guess offhand is that this is a matter of using the mpl API. I >> don't think we would want to add all of these types and options to >> the mpl core; but a toolkit might be ideal for this. The mpl API, >> which generates the same results for all backends, is quite complete >> and flexible. Things like arrowheads are Patch objects, and you can >> specify any path you want. The main trick is figuring out how to >> handle transforms--what kind of coordinates should the path be >> specifying? How should things scale as a figure is reshaped and >> resized? >> >> For many of these types you could also use mpl Line2D objects, for >> which several properties including cap style can be specified. Not >> all of the TikZ options would be available, but perhaps enough. >> >> Eric >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > |
From: Neil G. <mis...@gm...> - 2015-05-14 01:44:44
|
Do you have the code that you used to draw the arrowhead? I'm up to date now on the development workflow ( http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm ready to start working. Thanks, Neil On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn <bre...@gm...> wrote: > Yes, I fully agree that we need to unify the many different ways to draw > arrows. > > Neil, in case an example would be helpful for you, I have attached a > module that includes a custom arrowhead class. The arrowhead class works > with the with the ax.annotate() method. (I like the annotate method > because it allows me to easily mix and match coordinate systems for arrow > placement.) As you can see in the attached pdf, the custom arrowhead > doesn't include fancy Bezier curves, but that could be added. > > -Ben > > > > On May 13, 2015, at 2:54 PM, Thomas Caswell <tca...@gm...> wrote: > > The other thing that should be done is to unify the (I think 7?!?) unique > ways to draw arrows in mpl. > > On Wed, May 13, 2015 at 4:52 PM Neil Girdhar <mis...@gm...> > wrote: > >> Yes, I just noticed that as well. That's how the tikz pgf code looks (a >> sequence of line_to and curve_to commands and so on) so it should be easy >> to port over the various shapes. >> >> On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...> wrote: >> >>> On 2015/05/13 10:12 AM, Neil Girdhar wrote: >>> >>>> If you want to make arrowheads look at all decent, they really need to >>>> be enclosed in Bezier curves. See the diagram here: >>>> >>> >>> Mpl paths support Bezier curves. >>> http://matplotlib.org/api/path_api.html?highlight=bezier >>> >>> >>>> >>>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 >>>> >>>> The first two look like garbage. The last one is the only one that >>>> looks good imho. >>>> >>> >>> That depends on the application, and the observer. >> >> >> Sure, but I may as well port them all of the tikz arrowheads over since >> most of the work would be figuring out how to do it. >> >> >>> >>> >>> Eric >>> >>> >>>> Best, >>>> >>>> Neil >>>> >>>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... >>>> <mailto:ef...@ha...>> wrote: >>>> >>>> On 2015/05/13 9:36 AM, Neil Girdhar wrote: >>>> >>>> I don't know matplotlib well enough (yet) to know what the >>>> change would >>>> consist of. >>>> >>>> I suggest you take a look at the beautiful tikz manual: >>>> http://pgf.sourceforge.net/pgf_CVS.pdf >>>> >>>> >>>> Very helpful, thank you. >>>> >>>> >>>> The arrows.meta on page 201–212 are really well-designed and >>>> beautiful. >>>> >>>> Compare this with matplotlib's custom arrows: >>>> >>>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate >>>> >>>> How do I make tikz's arrowheads available for all backends? >>>> >>>> >>>> My guess offhand is that this is a matter of using the mpl API. I >>>> don't think we would want to add all of these types and options to >>>> the mpl core; but a toolkit might be ideal for this. The mpl API, >>>> which generates the same results for all backends, is quite complete >>>> and flexible. Things like arrowheads are Patch objects, and you can >>>> specify any path you want. The main trick is figuring out how to >>>> handle transforms--what kind of coordinates should the path be >>>> specifying? How should things scale as a figure is reshaped and >>>> resized? >>>> >>>> For many of these types you could also use mpl Line2D objects, for >>>> which several properties including cap style can be specified. Not >>>> all of the TikZ options would be available, but perhaps enough. >>>> >>>> Eric >>>> >>>> >>>> >>> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > |
From: Neil G. <mis...@gm...> - 2015-05-14 01:20:18
|
Wow, this looks great. Thank you all of you so far for the quick responses and pointers. I've already done many diagrams in Python-generated TikZ, which I want to port over to pure Python. They are basically variants of this: http://www.texample.net/tikz/examples/graph/ . Do you think this will be possible? That is, drawing nodes with labels inside and then anchoring the arrows to the edges of the nodes? With respect to the unification of arrow types, would you be able to point me to which files or methods in the source they are based on? I would like to familiarize myself with all of them before I make a proposal of what I intend to do. Thanks, Neil On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn <bre...@gm...> wrote: > Yes, I fully agree that we need to unify the many different ways to draw > arrows. > > Neil, in case an example would be helpful for you, I have attached a > module that includes a custom arrowhead class. The arrowhead class works > with the with the ax.annotate() method. (I like the annotate method > because it allows me to easily mix and match coordinate systems for arrow > placement.) As you can see in the attached pdf, the custom arrowhead > doesn't include fancy Bezier curves, but that could be added. > > -Ben > > > > On May 13, 2015, at 2:54 PM, Thomas Caswell <tca...@gm...> wrote: > > The other thing that should be done is to unify the (I think 7?!?) unique > ways to draw arrows in mpl. > > On Wed, May 13, 2015 at 4:52 PM Neil Girdhar <mis...@gm...> > wrote: > >> Yes, I just noticed that as well. That's how the tikz pgf code looks (a >> sequence of line_to and curve_to commands and so on) so it should be easy >> to port over the various shapes. >> >> On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...> wrote: >> >>> On 2015/05/13 10:12 AM, Neil Girdhar wrote: >>> >>>> If you want to make arrowheads look at all decent, they really need to >>>> be enclosed in Bezier curves. See the diagram here: >>>> >>> >>> Mpl paths support Bezier curves. >>> http://matplotlib.org/api/path_api.html?highlight=bezier >>> >>> >>>> >>>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 >>>> >>>> The first two look like garbage. The last one is the only one that >>>> looks good imho. >>>> >>> >>> That depends on the application, and the observer. >> >> >> Sure, but I may as well port them all of the tikz arrowheads over since >> most of the work would be figuring out how to do it. >> >> >>> >>> >>> Eric >>> >>> >>>> Best, >>>> >>>> Neil >>>> >>>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... >>>> <mailto:ef...@ha...>> wrote: >>>> >>>> On 2015/05/13 9:36 AM, Neil Girdhar wrote: >>>> >>>> I don't know matplotlib well enough (yet) to know what the >>>> change would >>>> consist of. >>>> >>>> I suggest you take a look at the beautiful tikz manual: >>>> http://pgf.sourceforge.net/pgf_CVS.pdf >>>> >>>> >>>> Very helpful, thank you. >>>> >>>> >>>> The arrows.meta on page 201–212 are really well-designed and >>>> beautiful. >>>> >>>> Compare this with matplotlib's custom arrows: >>>> >>>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate >>>> >>>> How do I make tikz's arrowheads available for all backends? >>>> >>>> >>>> My guess offhand is that this is a matter of using the mpl API. I >>>> don't think we would want to add all of these types and options to >>>> the mpl core; but a toolkit might be ideal for this. The mpl API, >>>> which generates the same results for all backends, is quite complete >>>> and flexible. Things like arrowheads are Patch objects, and you can >>>> specify any path you want. The main trick is figuring out how to >>>> handle transforms--what kind of coordinates should the path be >>>> specifying? How should things scale as a figure is reshaped and >>>> resized? >>>> >>>> For many of these types you could also use mpl Line2D objects, for >>>> which several properties including cap style can be specified. Not >>>> all of the TikZ options would be available, but perhaps enough. >>>> >>>> Eric >>>> >>>> >>>> >>> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > |
From: Benjamin R. <bre...@gm...> - 2015-05-14 01:10:58
|
Yes, I fully agree that we need to unify the many different ways to draw arrows. Neil, in case an example would be helpful for you, I have attached a module that includes a custom arrowhead class. The arrowhead class works with the with the ax.annotate() method. (I like the annotate method because it allows me to easily mix and match coordinate systems for arrow placement.) As you can see in the attached pdf, the custom arrowhead doesn't include fancy Bezier curves, but that could be added. -Ben On May 13, 2015, at 2:54 PM, Thomas Caswell <tca...@gm...> wrote: > The other thing that should be done is to unify the (I think 7?!?) unique ways to draw arrows in mpl. > > On Wed, May 13, 2015 at 4:52 PM Neil Girdhar <mis...@gm...> wrote: > Yes, I just noticed that as well. That's how the tikz pgf code looks (a sequence of line_to and curve_to commands and so on) so it should be easy to port over the various shapes. > > On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...> wrote: > On 2015/05/13 10:12 AM, Neil Girdhar wrote: > If you want to make arrowheads look at all decent, they really need to > be enclosed in Bezier curves. See the diagram here: > > Mpl paths support Bezier curves. > http://matplotlib.org/api/path_api.html?highlight=bezier > > > http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 > > The first two look like garbage. The last one is the only one that > looks good imho. > > That depends on the application, and the observer. > > Sure, but I may as well port them all of the tikz arrowheads over since most of the work would be figuring out how to do it. > > > > Eric > > > Best, > > Neil > > On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > > On 2015/05/13 9:36 AM, Neil Girdhar wrote: > > I don't know matplotlib well enough (yet) to know what the > change would > consist of. > > I suggest you take a look at the beautiful tikz manual: > http://pgf.sourceforge.net/pgf_CVS.pdf > > > Very helpful, thank you. > > > The arrows.meta on page 201–212 are really well-designed and > beautiful. > > Compare this with matplotlib's custom arrows: > http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate > > How do I make tikz's arrowheads available for all backends? > > > My guess offhand is that this is a matter of using the mpl API. I > don't think we would want to add all of these types and options to > the mpl core; but a toolkit might be ideal for this. The mpl API, > which generates the same results for all backends, is quite complete > and flexible. Things like arrowheads are Patch objects, and you can > specify any path you want. The main trick is figuring out how to > handle transforms--what kind of coordinates should the path be > specifying? How should things scale as a figure is reshaped and > resized? > > For many of these types you could also use mpl Line2D objects, for > which several properties including cap style can be specified. Not > all of the TikZ options would be available, but perhaps enough. > > Eric > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Juan Nunez-I. <jni...@gm...> - 2015-05-14 00:33:22
|
Fascinating! Can you "unpack" (heh) that error for us mere mortals? In particular: - never seen that "or" syntax before... Is it coercing both expressions as bool, or is it evaluating to left if bool(left) evaluates to True, else to right? - Why do you expect the second expression to work? Is ** supposed to have lower preference than "or"? (Which seems weird to me.) Thanks! Juan. On Thu, May 14, 2015 at 5:08 AM, Thomas Caswell <tca...@gm...> wrote: > > The failures on python nightly are currently due to a bug in python ( > http://bugs.python.org/issue24176) > > Tom > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Thomas C. <tca...@gm...> - 2015-05-13 20:54:18
|
The other thing that should be done is to unify the (I think 7?!?) unique ways to draw arrows in mpl. On Wed, May 13, 2015 at 4:52 PM Neil Girdhar <mis...@gm...> wrote: > Yes, I just noticed that as well. That's how the tikz pgf code looks (a > sequence of line_to and curve_to commands and so on) so it should be easy > to port over the various shapes. > > On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...> wrote: > >> On 2015/05/13 10:12 AM, Neil Girdhar wrote: >> >>> If you want to make arrowheads look at all decent, they really need to >>> be enclosed in Bezier curves. See the diagram here: >>> >> >> Mpl paths support Bezier curves. >> http://matplotlib.org/api/path_api.html?highlight=bezier >> >> >>> >>> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 >>> >>> The first two look like garbage. The last one is the only one that >>> looks good imho. >>> >> >> That depends on the application, and the observer. > > > Sure, but I may as well port them all of the tikz arrowheads over since > most of the work would be figuring out how to do it. > > >> >> >> Eric >> >> >>> Best, >>> >>> Neil >>> >>> On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... >>> <mailto:ef...@ha...>> wrote: >>> >>> On 2015/05/13 9:36 AM, Neil Girdhar wrote: >>> >>> I don't know matplotlib well enough (yet) to know what the >>> change would >>> consist of. >>> >>> I suggest you take a look at the beautiful tikz manual: >>> http://pgf.sourceforge.net/pgf_CVS.pdf >>> >>> >>> Very helpful, thank you. >>> >>> >>> The arrows.meta on page 201–212 are really well-designed and >>> beautiful. >>> >>> Compare this with matplotlib's custom arrows: >>> >>> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate >>> >>> How do I make tikz's arrowheads available for all backends? >>> >>> >>> My guess offhand is that this is a matter of using the mpl API. I >>> don't think we would want to add all of these types and options to >>> the mpl core; but a toolkit might be ideal for this. The mpl API, >>> which generates the same results for all backends, is quite complete >>> and flexible. Things like arrowheads are Patch objects, and you can >>> specify any path you want. The main trick is figuring out how to >>> handle transforms--what kind of coordinates should the path be >>> specifying? How should things scale as a figure is reshaped and >>> resized? >>> >>> For many of these types you could also use mpl Line2D objects, for >>> which several properties including cap style can be specified. Not >>> all of the TikZ options would be available, but perhaps enough. >>> >>> Eric >>> >>> >>> >> > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Neil G. <mis...@gm...> - 2015-05-13 20:52:04
|
Yes, I just noticed that as well. That's how the tikz pgf code looks (a sequence of line_to and curve_to commands and so on) so it should be easy to port over the various shapes. On Wed, May 13, 2015 at 4:49 PM, Eric Firing <ef...@ha...> wrote: > On 2015/05/13 10:12 AM, Neil Girdhar wrote: > >> If you want to make arrowheads look at all decent, they really need to >> be enclosed in Bezier curves. See the diagram here: >> > > Mpl paths support Bezier curves. > http://matplotlib.org/api/path_api.html?highlight=bezier > > >> >> http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 >> >> The first two look like garbage. The last one is the only one that >> looks good imho. >> > > That depends on the application, and the observer. Sure, but I may as well port them all of the tikz arrowheads over since most of the work would be figuring out how to do it. > > > Eric > > >> Best, >> >> Neil >> >> On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... >> <mailto:ef...@ha...>> wrote: >> >> On 2015/05/13 9:36 AM, Neil Girdhar wrote: >> >> I don't know matplotlib well enough (yet) to know what the >> change would >> consist of. >> >> I suggest you take a look at the beautiful tikz manual: >> http://pgf.sourceforge.net/pgf_CVS.pdf >> >> >> Very helpful, thank you. >> >> >> The arrows.meta on page 201–212 are really well-designed and >> beautiful. >> >> Compare this with matplotlib's custom arrows: >> >> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate >> >> How do I make tikz's arrowheads available for all backends? >> >> >> My guess offhand is that this is a matter of using the mpl API. I >> don't think we would want to add all of these types and options to >> the mpl core; but a toolkit might be ideal for this. The mpl API, >> which generates the same results for all backends, is quite complete >> and flexible. Things like arrowheads are Patch objects, and you can >> specify any path you want. The main trick is figuring out how to >> handle transforms--what kind of coordinates should the path be >> specifying? How should things scale as a figure is reshaped and >> resized? >> >> For many of these types you could also use mpl Line2D objects, for >> which several properties including cap style can be specified. Not >> all of the TikZ options would be available, but perhaps enough. >> >> Eric >> >> >> > |
From: Eric F. <ef...@ha...> - 2015-05-13 20:49:52
|
On 2015/05/13 10:12 AM, Neil Girdhar wrote: > If you want to make arrowheads look at all decent, they really need to > be enclosed in Bezier curves. See the diagram here: Mpl paths support Bezier curves. http://matplotlib.org/api/path_api.html?highlight=bezier > > http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 > > The first two look like garbage. The last one is the only one that > looks good imho. That depends on the application, and the observer. Eric > > Best, > > Neil > > On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > > On 2015/05/13 9:36 AM, Neil Girdhar wrote: > > I don't know matplotlib well enough (yet) to know what the > change would > consist of. > > I suggest you take a look at the beautiful tikz manual: > http://pgf.sourceforge.net/pgf_CVS.pdf > > > Very helpful, thank you. > > > The arrows.meta on page 201–212 are really well-designed and > beautiful. > > Compare this with matplotlib's custom arrows: > http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate > > How do I make tikz's arrowheads available for all backends? > > > My guess offhand is that this is a matter of using the mpl API. I > don't think we would want to add all of these types and options to > the mpl core; but a toolkit might be ideal for this. The mpl API, > which generates the same results for all backends, is quite complete > and flexible. Things like arrowheads are Patch objects, and you can > specify any path you want. The main trick is figuring out how to > handle transforms--what kind of coordinates should the path be > specifying? How should things scale as a figure is reshaped and > resized? > > For many of these types you could also use mpl Line2D objects, for > which several properties including cap style can be specified. Not > all of the TikZ options would be available, but perhaps enough. > > Eric > > |
From: Neil G. <mis...@gm...> - 2015-05-13 20:12:52
|
If you want to make arrowheads look at all decent, they really need to be enclosed in Bezier curves. See the diagram here: http://tex.stackexchange.com/questions/150289/how-do-you-accomplish-stealth-with-the-new-arrows-meta/230965#230965 The first two look like garbage. The last one is the only one that looks good imho. Best, Neil On Wed, May 13, 2015 at 4:09 PM, Eric Firing <ef...@ha...> wrote: > On 2015/05/13 9:36 AM, Neil Girdhar wrote: > >> I don't know matplotlib well enough (yet) to know what the change would >> consist of. >> >> I suggest you take a look at the beautiful tikz manual: >> http://pgf.sourceforge.net/pgf_CVS.pdf >> > > Very helpful, thank you. > > >> The arrows.meta on page 201–212 are really well-designed and beautiful. >> >> Compare this with matplotlib's custom arrows: >> >> http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate >> >> How do I make tikz's arrowheads available for all backends? >> >> > My guess offhand is that this is a matter of using the mpl API. I don't > think we would want to add all of these types and options to the mpl core; > but a toolkit might be ideal for this. The mpl API, which generates the > same results for all backends, is quite complete and flexible. Things like > arrowheads are Patch objects, and you can specify any path you want. The > main trick is figuring out how to handle transforms--what kind of > coordinates should the path be specifying? How should things scale as a > figure is reshaped and resized? > > For many of these types you could also use mpl Line2D objects, for which > several properties including cap style can be specified. Not all of the > TikZ options would be available, but perhaps enough. > > Eric > > |
From: Eric F. <ef...@ha...> - 2015-05-13 20:09:35
|
On 2015/05/13 9:36 AM, Neil Girdhar wrote: > I don't know matplotlib well enough (yet) to know what the change would > consist of. > > I suggest you take a look at the beautiful tikz manual: > http://pgf.sourceforge.net/pgf_CVS.pdf Very helpful, thank you. > > The arrows.meta on page 201–212 are really well-designed and beautiful. > > Compare this with matplotlib's custom arrows: > http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate > > How do I make tikz's arrowheads available for all backends? > My guess offhand is that this is a matter of using the mpl API. I don't think we would want to add all of these types and options to the mpl core; but a toolkit might be ideal for this. The mpl API, which generates the same results for all backends, is quite complete and flexible. Things like arrowheads are Patch objects, and you can specify any path you want. The main trick is figuring out how to handle transforms--what kind of coordinates should the path be specifying? How should things scale as a figure is reshaped and resized? For many of these types you could also use mpl Line2D objects, for which several properties including cap style can be specified. Not all of the TikZ options would be available, but perhaps enough. Eric |
From: Benjamin R. <ben...@ou...> - 2015-05-13 19:50:02
|
Just to point out, matplotlib does have a fairly new PGF backend. Perhaps you might want to look at that and see where the TikZ library might fit in with that? Cheers! Ben Root On Wed, May 13, 2015 at 3:36 PM, Neil Girdhar <mis...@gm...> wrote: > I don't know matplotlib well enough (yet) to know what the change would > consist of. > > I suggest you take a look at the beautiful tikz manual: > http://pgf.sourceforge.net/pgf_CVS.pdf > > The arrows.meta on page 201–212 are really well-designed and beautiful. > > Compare this with matplotlib's custom arrows: > http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate > > How do I make tikz's arrowheads available for all backends? > > > > On Wed, May 13, 2015 at 2:55 PM, Eric Firing <ef...@ha...> wrote: > >> On 2015/05/13 12:39 AM, Neil Girdhar wrote: >> > TikZ is an extremely well-designed library for generating professional >> > figures within the cumbersome TeX framework. Currently, my work flow is >> > to generate TikZ code using Python. The TikZ is compiled into PDFs, >> > which are then included in my LaTeX files. I would like to work >> > entirely in Python. >> > >> > This means that I want to incorporate TikZ's features into matplotlib. >> > I want to start with custom pgf arrowheads. Will this be possible. >> > What is the process from feature idea to pull request that I would have >> > to go through? >> >> You're on the right track by raising the idea here. Depending on how >> complicated the idea is, the next step after some mailing list >> discussion could be either a MEP or a PR; but personally I would prefer >> to get a better picture of what you are talking about via this mailing >> list first. >> >> Are you talking about adding high-level functionality that would be >> applicable to all backends? Can you give an example of what sorts of >> changes would be required in mpl, and what they would accomplish? >> >> Eric >> >> > >> > Best, >> > >> > Neil >> >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Neil G. <mis...@gm...> - 2015-05-13 19:37:23
|
I don't know matplotlib well enough (yet) to know what the change would consist of. I suggest you take a look at the beautiful tikz manual: http://pgf.sourceforge.net/pgf_CVS.pdf The arrows.meta on page 201–212 are really well-designed and beautiful. Compare this with matplotlib's custom arrows: http://stackoverflow.com/questions/16968007/custom-arrow-style-for-matplotlib-pyplot-annotate How do I make tikz's arrowheads available for all backends? On Wed, May 13, 2015 at 2:55 PM, Eric Firing <ef...@ha...> wrote: > On 2015/05/13 12:39 AM, Neil Girdhar wrote: > > TikZ is an extremely well-designed library for generating professional > > figures within the cumbersome TeX framework. Currently, my work flow is > > to generate TikZ code using Python. The TikZ is compiled into PDFs, > > which are then included in my LaTeX files. I would like to work > > entirely in Python. > > > > This means that I want to incorporate TikZ's features into matplotlib. > > I want to start with custom pgf arrowheads. Will this be possible. > > What is the process from feature idea to pull request that I would have > > to go through? > > You're on the right track by raising the idea here. Depending on how > complicated the idea is, the next step after some mailing list > discussion could be either a MEP or a PR; but personally I would prefer > to get a better picture of what you are talking about via this mailing > list first. > > Are you talking about adding high-level functionality that would be > applicable to all backends? Can you give an example of what sorts of > changes would be required in mpl, and what they would accomplish? > > Eric > > > > > Best, > > > > Neil > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Thomas C. <tca...@gm...> - 2015-05-13 19:08:19
|
The failures on python nightly are currently due to a bug in python ( http://bugs.python.org/issue24176) Tom |
From: Eric F. <ef...@ha...> - 2015-05-13 18:55:44
|
On 2015/05/13 12:39 AM, Neil Girdhar wrote: > TikZ is an extremely well-designed library for generating professional > figures within the cumbersome TeX framework. Currently, my work flow is > to generate TikZ code using Python. The TikZ is compiled into PDFs, > which are then included in my LaTeX files. I would like to work > entirely in Python. > > This means that I want to incorporate TikZ's features into matplotlib. > I want to start with custom pgf arrowheads. Will this be possible. > What is the process from feature idea to pull request that I would have > to go through? You're on the right track by raising the idea here. Depending on how complicated the idea is, the next step after some mailing list discussion could be either a MEP or a PR; but personally I would prefer to get a better picture of what you are talking about via this mailing list first. Are you talking about adding high-level functionality that would be applicable to all backends? Can you give an example of what sorts of changes would be required in mpl, and what they would accomplish? Eric > > Best, > > Neil |
From: Neil G. <mis...@gm...> - 2015-05-13 10:39:39
|
TikZ is an extremely well-designed library for generating professional figures within the cumbersome TeX framework. Currently, my work flow is to generate TikZ code using Python. The TikZ is compiled into PDFs, which are then included in my LaTeX files. I would like to work entirely in Python. This means that I want to incorporate TikZ's features into matplotlib. I want to start with custom pgf arrowheads. Will this be possible. What is the process from feature idea to pull request that I would have to go through? Best, Neil |
From: Brian G. <ell...@gm...> - 2015-05-11 18:18:53
|
Hi all, I wanted to let the community know that we are currently hiring 3 full time software engineers to work full time on Project Jupyter/IPython. These positions will be in my group at Cal Poly in San Luis Obispo, CA. We are looking for frontend and backend software engineers with lots of Python/JavaScript experience and a passion for open source software. The details can be found here: https://www.calpolycorporationjobs.org/postings/736 This is an unusual opportunity in a couple of respects: * These positions will allow you to work on open source software full time - not as a X% side project (aka weekends and evenings). * These are fully benefited positions (CA state retirement, health care, etc.) * You will get to work and live in San Luis Obispo, one of the nicest places on earth. We are minutes from the beach, have perfect year-round weather and are close to both the Bay Area and So Cal. I am more than willing to talk to any who interested in these positions. Cheers, Brian -- Brian E. Granger Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgr...@ca... and ell...@gm... |
From: Thomas C. <tca...@gm...> - 2015-05-11 12:28:50
|
I think that so long as you maintain the mapping of 'manager' to be 'gui element holding the Figure' (rather than 'gui window holding figure') numbering the managers should be ok. That is, the tabs are the managers and the multi-figure windows are a layer above the managers. The notion of 'figure number' is very thoroughly a pyplot/figure manager idea I am -1 on pushing that logic down in to the Figure class. Tom On Wed, May 6, 2015 at 4:42 PM Eric Firing <ef...@ha...> wrote: > On 2015/05/06 9:19 AM, Federico Ariza wrote: > > Hello > > > > Is there any reason why the "num" property is assigned to the manager > > and not to the figure? > > I think this is because the figure is at the object-oriented API level. > The manager is in the pyplot state-machine level. > > > Pyplot.gcf is to get the "current figure" not the "current manager". > > It is really "get current managed figure", combined with the original > idea that the manager is the pyplot layer on top of the figure, with one > manager per figure. The "current" concept comes from the state machine. > > > > > In general this is not a problem. But I'm working on MEP23 where one > > manager can contain several figures. And it would be pretty nice if I > > could reference the figures by that number not the managers. > > > > A priori, do you see any problem with a PR changing that? > > It seems like it could work--but what will it do to existing user code? > > Eric > > > > > Thanks > > Federico > > > > > > > > > ------------------------------------------------------------------------------ > > One dashboard for servers and applications across Physical-Virtual-Cloud > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insights > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > > > > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Nathan G. <nat...@gm...> - 2015-05-07 16:40:05
|
For what it's worth, there are matplotlib, scipy, and IPython channels on the freenode IRC network. I often answer questions there. On Monday, May 4, 2015, Bryan Van de Ven <br...@co...> wrote: > We've thought about gitter as well, personally my (slight) preference for > Slack is that it does not require a GH account, and also, there is a nice > OSS heroku app that provides a really nice "self-invite" button that shows > how many users are on, too. You can see it on our test docs deploy: > > http://bokeh.pydata.org/en/test/index.html > > That said it is probably six of one, half dozen of the other. I'm not > categorically opposed to looking into gitter some more. > > My hope (and intent) is really to have this as a place for users to > congregate and self-support. We do intend to monitor, to the extent we can, > but like you there is precious little bandwidth form core devs. > > Bryan > > > > On May 4, 2015, at 11:45 AM, Thomas Caswell <tca...@gm... > <javascript:;>> wrote: > > > > That sounds reasonable to me. My only concern is getting enough (any?) > bandwidth from enough of the core mpl developers. > > > > IPython and scikit image both have gitter rooms running that seem to > working well for them as well, is there any reason to go with slack over > gitter? > > > > Tom > > > > ---------- Forwarded message --------- > > From: Bryan Van de Ven <br...@co... <javascript:;>> > > Date: Mon, May 4, 2015 at 11:44 AM > > Subject: python data vis Slack channels? > > To: Michael Droettboom <md...@st... <javascript:;>>, < > tca...@gm... <javascript:;>> > > > > > > Hi guys, > > > > We have been experimenting/toying with the idea of using a free Slack > channel to provide a place for casual Bokeh user interactions. It occurred > that it might be nice to have a single "pyvis.slack.com", that has > channels for several OSS python vis libraries in one place. Would you have > any interest in a #matplotlib channel there? If there is a better place to > submit this proposal, please let me know. > > > > Regards, > > > > Bryan Van de Ven > > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... <javascript:;> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Eric F. <ef...@ha...> - 2015-05-06 20:42:04
|
On 2015/05/06 9:19 AM, Federico Ariza wrote: > Hello > > Is there any reason why the "num" property is assigned to the manager > and not to the figure? I think this is because the figure is at the object-oriented API level. The manager is in the pyplot state-machine level. > Pyplot.gcf is to get the "current figure" not the "current manager". It is really "get current managed figure", combined with the original idea that the manager is the pyplot layer on top of the figure, with one manager per figure. The "current" concept comes from the state machine. > > In general this is not a problem. But I'm working on MEP23 where one > manager can contain several figures. And it would be pretty nice if I > could reference the figures by that number not the managers. > > A priori, do you see any problem with a PR changing that? It seems like it could work--but what will it do to existing user code? Eric > > Thanks > Federico > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Federico A. <ari...@gm...> - 2015-05-06 19:19:39
|
Hello Is there any reason why the "num" property is assigned to the manager and not to the figure? Pyplot.gcf is to get the "current figure" not the "current manager". In general this is not a problem. But I'm working on MEP23 where one manager can contain several figures. And it would be pretty nice if I could reference the figures by that number not the managers. A priori, do you see any problem with a PR changing that? Thanks Federico |
From: Thomas K. <th...@kl...> - 2015-05-04 17:53:17
|
On 4 May 2015 at 09:45, Thomas Caswell <tca...@gm...> wrote: > IPython and scikit image both have gitter rooms running that seem to > working well for them as well, is there any reason to go with slack over > gitter? > Gitter rooms are closely tied to Github repositories or organisations, so if you wanted to use it for something as broad as Python visualisation, you'd need a new Github organisation. That's not a big deal, of course, but it might be a small point against it for that kind of use case. Thomas |
From: Bryan V. de V. <br...@co...> - 2015-05-04 17:16:43
|
We've thought about gitter as well, personally my (slight) preference for Slack is that it does not require a GH account, and also, there is a nice OSS heroku app that provides a really nice "self-invite" button that shows how many users are on, too. You can see it on our test docs deploy: http://bokeh.pydata.org/en/test/index.html That said it is probably six of one, half dozen of the other. I'm not categorically opposed to looking into gitter some more. My hope (and intent) is really to have this as a place for users to congregate and self-support. We do intend to monitor, to the extent we can, but like you there is precious little bandwidth form core devs. Bryan > On May 4, 2015, at 11:45 AM, Thomas Caswell <tca...@gm...> wrote: > > That sounds reasonable to me. My only concern is getting enough (any?) bandwidth from enough of the core mpl developers. > > IPython and scikit image both have gitter rooms running that seem to working well for them as well, is there any reason to go with slack over gitter? > > Tom > > ---------- Forwarded message --------- > From: Bryan Van de Ven <br...@co...> > Date: Mon, May 4, 2015 at 11:44 AM > Subject: python data vis Slack channels? > To: Michael Droettboom <md...@st...>, <tca...@gm...> > > > Hi guys, > > We have been experimenting/toying with the idea of using a free Slack channel to provide a place for casual Bokeh user interactions. It occurred that it might be nice to have a single "pyvis.slack.com", that has channels for several OSS python vis libraries in one place. Would you have any interest in a #matplotlib channel there? If there is a better place to submit this proposal, please let me know. > > Regards, > > Bryan Van de Ven > |
From: Thomas C. <tca...@gm...> - 2015-05-04 16:45:47
|
That sounds reasonable to me. My only concern is getting enough (any?) bandwidth from enough of the core mpl developers. IPython and scikit image both have gitter rooms running that seem to working well for them as well, is there any reason to go with slack over gitter? Tom ---------- Forwarded message --------- From: Bryan Van de Ven <br...@co...> Date: Mon, May 4, 2015 at 11:44 AM Subject: python data vis Slack channels? To: Michael Droettboom <md...@st...>, <tca...@gm...> Hi guys, We have been experimenting/toying with the idea of using a free Slack channel to provide a place for casual Bokeh user interactions. It occurred that it might be nice to have a single "pyvis.slack.com", that has channels for several OSS python vis libraries in one place. Would you have any interest in a #matplotlib channel there? If there is a better place to submit this proposal, please let me know. Regards, Bryan Van de Ven |
From: Nicolas P. R. <Nic...@in...> - 2015-04-27 07:08:02
|
--------------------------------- Submission deadline in 3 days !!! --------------------------------- EuroScipy 2015, the annual conference on Python in science will take place in Cambridge, UK on 26-30 August 2015. The conference features two days of tutorials followed by two days of scientific talks & posters and an extra day dedicated to developer sprints. It is the major event in Europe in the field of technical/scientific computing within the Python ecosystem. Data scientists, analysts, quants, PhD's, scientists and students from more than 20 countries attended the conference last year. The topics presented at EuroSciPy are very diverse, with a focus on advanced software engineering and original uses of Python and its scientific libraries, either in theoretical or experimental research, from both academia and the industry. Submissions for posters, talks & tutorials (beginner and advanced) are welcome on our website at http://www.euroscipy.org/2015/ Sprint proposals should be addressed directly to the organisation at eur...@py... Important dates =============== Mar 24, 2015 Call for talks, posters & tutorials Apr 30, 2015 Talk and tutorials submission deadline May 1, 2015 Registration opens May 30, 2015 Final program announced Jun 15, 2015 Early-bird registration ends Aug 26-27, 2015 Tutorials Aug 28-29, 2015 Main conference Aug 30, 2015 Sprints We look forward to an exciting conference and hope to see you in Cambridge The EuroSciPy 2015 Team - http://www.euroscipy.org/2015/ |