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: Thomas C. <tca...@gm...> - 2014-07-27 23:52:53
|
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0rc2/ Thanks to Christoph Gohlike the widows binaries now posted on sourceforge. Tom -- Thomas Caswell tca...@gm... |
From: Thomas C. <tca...@gm...> - 2014-07-26 13:35:03
|
Hi all, I just did the version bump and tagged 1.4.0rc2. There is one outstanding issue with possible memory corruption, but we do not have a reproducible example. Everything else we have left for 1.4.0 is documentation. Tom -- Thomas Caswell tca...@gm... |
From: Benjamin R. <ben...@ou...> - 2014-07-24 20:18:55
|
When dealing with the C/C++ layer and switching back and forth between upstream master and your branch, I would suggest running "git clean -fxd" and then do a complete rebuild. We have recently fixed a number of memory leaks that may or may not have merged well with your code as it involved the CXX layer. On Tue, Jul 22, 2014 at 5:41 AM, Stefan H. <shm...@gm...> wrote: > Hi! Last year, I have been working on making matplotlib compatible with > PyPy > here: > > https://github.com/shmuller/matplotlib.git > > I succeeded to get the svg and pdf backends working, but then had to drop > the ball. My changes involve mostly the C++ parts in src, in particular > replacing some PyCXX (which didn't work with PyPy) with the plain Python C > API. I also needed some minor fixes in .py files. > > I understand that it is desirable to remove the PyCXX layer altogether from > matplotlib, and I have come a good deal along this route. I would also be > happy to continue working in this direction. > > I have a bit of time now, and so I merged my branch with upstream/master. > The few conflicts were easy to resolve. However, then I tried to run the > test suites (python tests.py), both on the current master and my branch, to > see if I broke anything. > > Unfortunately, the test suites randomly segfault on my computer (Macbook > Air > 2011), at the latest when I try to run them 10 times in a row. Not only on > my branch, but also on upstream/master. I ran the Apple Hardware Test, > which > didn't report any issues, so my Mac seems to be fine. I went back to the > state of my branch before merging, which i have been using in production > for > a year now without any issues, and noticed that even there the test suite > segfaulted if I try to run it 10 times in a loop. I haven't noticed this > before (and didn't have any issues in production use of matplotlib for a > year). The crashes occur randomly and not always at one specific test. > > - Did anyone have this issue before? > > - Could someone pull my branch and run the test suite on a different > computer, so that I can exclude that my hardware is at fault after all? > > - Could someone please guide me to get my work pulled into the main > repository? > > Many thanks, > Stefan > > > > -- > View this message in context: > http://matplotlib.1069221.n5.nabble.com/Trying-to-prepare-a-pull-request-but-tests-py-keeps-crashing-on-master-tp43680.html > Sent from the matplotlib - devel mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Federico A. <ari...@gm...> - 2014-07-23 16:47:24
|
Hello everybody I was wondering if you had the chance to try the PR https://github.com/matplotlib/matplotlib/pull/2759 I am waiting for comments, suggestions, critics etc.. To keep moving I would like to finish this MEP22 and have it merged to continue with my main goal... The MEP23 Thanks Federico |
From: Stefan H. <shm...@gm...> - 2014-07-22 09:41:15
|
Hi! Last year, I have been working on making matplotlib compatible with PyPy here: https://github.com/shmuller/matplotlib.git I succeeded to get the svg and pdf backends working, but then had to drop the ball. My changes involve mostly the C++ parts in src, in particular replacing some PyCXX (which didn't work with PyPy) with the plain Python C API. I also needed some minor fixes in .py files. I understand that it is desirable to remove the PyCXX layer altogether from matplotlib, and I have come a good deal along this route. I would also be happy to continue working in this direction. I have a bit of time now, and so I merged my branch with upstream/master. The few conflicts were easy to resolve. However, then I tried to run the test suites (python tests.py), both on the current master and my branch, to see if I broke anything. Unfortunately, the test suites randomly segfault on my computer (Macbook Air 2011), at the latest when I try to run them 10 times in a row. Not only on my branch, but also on upstream/master. I ran the Apple Hardware Test, which didn't report any issues, so my Mac seems to be fine. I went back to the state of my branch before merging, which i have been using in production for a year now without any issues, and noticed that even there the test suite segfaulted if I try to run it 10 times in a loop. I haven't noticed this before (and didn't have any issues in production use of matplotlib for a year). The crashes occur randomly and not always at one specific test. - Did anyone have this issue before? - Could someone pull my branch and run the test suite on a different computer, so that I can exclude that my hardware is at fault after all? - Could someone please guide me to get my work pulled into the main repository? Many thanks, Stefan -- View this message in context: http://matplotlib.1069221.n5.nabble.com/Trying-to-prepare-a-pull-request-but-tests-py-keeps-crashing-on-master-tp43680.html Sent from the matplotlib - devel mailing list archive at Nabble.com. |
From: Thomas C. <tca...@gm...> - 2014-07-22 03:38:49
|
Once #3277 and #3284 get merged I think we will have squashed all the reported code bugs from rc1 (both are from me and need a second set of eyes). Can someone who understands the freetype code take a look at #3262 to see if we can relax the version requirement on the installation? Everything else outstanding is documentation related, if those three things get taken care of tomorrow, I will tag rc2 tomorrow night. Tom -- Thomas Caswell tca...@gm... |
From: R H. <rha...@gm...> - 2014-07-21 17:01:21
|
On 21 July 2014 17:40, R Hattersley <rha...@gm...> wrote: > In the case of two Axes, the CSS version would be: > > Axes#axes1 { > border: 1px solid black; > } > > Axes#axes2 { > border: 2px dashed green; > } > > Or if you want to borrow from more advanced selector syntax, you could do fun stuff like: Axes:nth-child(odd) { border: 1px solid black; } Axes:nth-child(even) { border: 2px dashed green; } |
From: R H. <rha...@gm...> - 2014-07-21 16:40:07
|
On 21 July 2014 14:48, jamesramm <jam...@gm...> wrote: > You've just noted it: Line2D isn't a CSS selector CSS doesn't define any particular element names - it just operates on element names in a document tree. So a standard CSS parser will work just as well with "line2d { ... }" as it would with "h1 { ... }". On 21 July 2014 14:48, jamesramm <jam...@gm...> wrote: > ..likewise, the properties we want to call upon (like linewidth) are not > CSS attributes. Agreed - not all properties are standard CSS properties, so I was suggesting borrowing SVG properties to augment the list. NB. That would make the property controlling line width be called "stroke-width". But whatever names we choose, a CSS parser doesn't care what the names are. But really the issue is not so much about CSS and SVG-styling-properties - it is whether to use existing standards or not. Clearly I'm in favour of adopting standards. But perhaps there is another standard set of CSS styling properties which would be a closer match to matplotlib? Perhaps CSS is not the answer at all, and something like SLD/SE would be better? (I suspect not! But there could easily be other technologies I'm not aware of!) Axes { > gid: 'axes1'; > autoscalex_on: True; > ::ylabel { > text: 'Y-Axis'; > font-size: 10; > } > } > > I think this would be easier to parse and slightly clearer to read as it > can be 'attached' to the artist container it refers to (imagine if there > were 2 axes in a figure...) In the case of two Axes, the CSS version would be: Axes#axes1 { border: 1px solid black; } Axes#axes2 { border: 2px dashed green; } |
From: Thomas C. <tca...@gm...> - 2014-07-21 16:28:44
|
As a side note, SVG already has specs which extend css to apply to 2D graphics: www.w3.org/TR/SVGTiny12/styling.html so we don't need to entirely re-inventing the wheel. On Mon, Jul 21, 2014 at 9:48 AM, jamesramm <jam...@gm...> wrote: > R Hattersley wrote > I'm not sure what it is about CSS syntax that isn't up to the job. For > example, SVG works with standard CSS syntax (see > http://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just have > a different view of what constitutes CSS vs. HTML/SVG/whatever. The example > in the SVG spec is: > > rect { > fill: red; > stroke: blue; > stroke-width: 3 > } > > But if we define the element name for a Line2D instance as "line2d" then CSS > snippet could just become: > > line2d { > stroke: blue; > stroke-width: 3 > } > > You've just noted it: Line2D isn't a CSS selector..likewise, the properties > we want to call upon (like linewidth) are not CSS attributes. There are many > matplotlib properties that don't have an analogous CSS property/attribute > (that I know of); we might aswell define the mpl properties in our 'CSS' > subset. So we could base our language on CSS rules, but we need to define > new tokens. This means writing, or more likely, extending a parser. Not > huge, but not trivial. > > R Hattersley wrote > The DOM facade could help bridge the gap. For example, a "DOM" instance > returned by an Axes object could pretend to have "text" element children. > Styling those would route the style information back to the underlying Axes > object. For example: > > text { > font-size: 12pt; > } > > axes text.ylabel { > font-size: 10pt; > } > > This could be one way. Another way that would fit and I quite like is > similar to what is employed by mapnik/the tilemill, in that we simply have > nested declaration blocks, e.g: > > Axes { > gid: 'axes1'; > autoscalex_on: True; > ::ylabel { > text: 'Y-Axis'; > font-size: 10; > } > } > > I think this would be easier to parse and slightly clearer to read as it can > be 'attached' to the artist container it refers to (imagine if there were 2 > axes in a figure...). It is also easy to write in BNF, by just adding > another option to the Declaration block: > > Rule := Selector '{' [Declaration] '}' > > Declaration := Attribute':' Value';' | Rule > > ... > > But...small steps. I would start by introducing something for artist > primitives and for selectively applying to primitives using the gid > ________________________________ > View this message in context: Re: MEP26: Artist-level stylesheets > > Sent from the matplotlib - devel mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Thomas Caswell tca...@gm... |
From: jamesramm <jam...@gm...> - 2014-07-21 13:48:15
|
R Hattersley wrote > I'm not sure what it is about CSS syntax that isn't up to the job. > Forexample, SVG works with standard CSS syntax > (seehttp://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just > havea different view of what constitutes CSS vs. HTML/SVG/whatever.The > example in the SVG spec is: > rect { fill: red; stroke: blue; stroke-width: 3} > But if we define the element name for a Line2D instance as "line2d" > thenCSS snippet could just become: > line2d { stroke: blue; stroke-width: 3} You've just noted it: Line2D isn't a CSS selector..likewise, the properties we want to call upon (like linewidth) are not CSS attributes. There are many matplotlib properties that don't have an analogous CSS property/attribute (that I know of); we might aswell define the mpl properties in our 'CSS' subset.So we could base our language on CSS rules, but we need to define new tokens. This means writing, or more likely, extending a parser. Not huge, but not trivial. R Hattersley wrote > The DOM facade could help bridge the gap. For example, a "DOM" > instancereturned by an Axes object could pretend to have "text" element > children.Styling those would route the style information back to the > underlying Axesobject. For example: > text { font-size: 12pt;}axes text.ylabel { font-size: 10pt;} This could be one way. Another way that would fit and I quite like is similar to what is employed by mapnik/the tilemill, in that we simply have nested declaration blocks, e.g: Axes { gid: 'axes1'; autoscalex_on: True; ::ylabel { text: 'Y-Axis'; font-size: 10; } } I think this would be easier to parse and slightly clearer to read as it can be 'attached' to the artist container it refers to (imagine if there were 2 axes in a figure...). It is also easy to write in BNF, by just adding another option to the Declaration block: Rule := Selector '{' [Declaration] '}'Declaration := Attribute':' Value';' | Rule... But...small steps. I would start by introducing something for artist primitives and for selectively applying to primitives using the gid -- View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43673.html Sent from the matplotlib - devel mailing list archive at Nabble.com. |
From: R H. <rha...@gm...> - 2014-07-21 09:38:59
|
On 20 July 2014 14:23, jamesramm <jam...@gm...> wrote: > We cannot stick with the 'standard' CSS syntax by necessity, simply because > the standard CSS selectors and properties are defined from HTML and do not > match with matplotlib. > I.E we want to select by artist type, which doesn't exist in HTML and use > properties such as linewidth. > I'm not sure what it is about CSS syntax that isn't up to the job. For example, SVG works with standard CSS syntax (see http://www.w3.org/TR/SVG/styling.html#StylingWithCSS). Perhaps we just have a different view of what constitutes CSS vs. HTML/SVG/whatever. The example in the SVG spec is: rect { fill: red; stroke: blue; stroke-width: 3 } But if we define the element name for a Line2D instance as "line2d" then CSS snippet could just become: line2d { stroke: blue; stroke-width: 3 } Sure, matplotlib doesn't define a genuine DOM, but I understand there is interest in moving to a model more like that. In which case, perhaps a good way to proceed in the meantime would be to have artists expose a DOM facade suitable for styling. (Perhaps even using SVG element conventions?) NB. matplotlib already uses pyparsing, so it would be pretty straightforward to knock together a parser for CSS (or whatever subset is needed). Or there are existing Python CSS parser libraries. > Qt - Pyside/PyQt ('QSS') > Mapnik ('CartoCSS') > PyGal supports stylesheets (don't know much about this library) > > If we don't use CSS then +1 for using some other standard. > As I say, an alternative could be simply using the ConfigParser > > > Richard Hattersley wrote > >> > >> Do you have ideas on how one or more stylesheets would be "attached" to > a > >> particular figure, etc? > >> > >> Regards, > >> Richard Hattersley > >> > > > b) Filtering artists > Another problem is that we would generally want to treat artists which are > solely for the construction of the Axes differently to those artists that > define a plot. I.E we might want to define Line2D as having the colour red, > but we want lines which compose the Axes to be black or grey. > My initial proposal is to develop stylesheets for artist primitives only. > But eventually we will want to style artist containers aswell. > The problem matplotlib has is that the properties for artist containers are > not uniform/intuitive. > It generally has a API where artists which are 'contained' by other artists > are set by calling properties...e.g. axes.set_ylabel(text = , etc...) > The DOM facade could help bridge the gap. For example, a "DOM" instance returned by an Axes object could pretend to have "text" element children. Styling those would route the style information back to the underlying Axes object. For example: text { font-size: 12pt; } axes text.ylabel { font-size: 10pt; } I would imagine setting stylesheets through the axes or figure methods > (axes.setStyleSheet() or figure.setStyleSheet()). Via figure would require > being able to differentiate between different axes - i.e. introducing the > 'container' level syntax I mentioned above. > > I would imagine that this would eventually replace rcparams to define the > default style. I would also like to see the default look of graphs moving > away from the very dated, 90's style MATLAB appearance! > That would be an excellent start. More complicated mechanisms can always be added later if necessary. Richard |
From: jamesramm <jam...@gm...> - 2014-07-20 13:23:51
|
Nelle Varoquaux wrote >> I'd strongly encourage you to stick with standard CSS syntax/behaviour >> instead of extending it. For example, the selector of "Axes.ylabel" would >> be more consistent as "Axes .ylabel" (or perhaps "Axis.y .label"). >> > > I actually think we need to focus on something easy to parse and easy to > use, not necessarily stick to the CSS syntax and behaviour. Back in the > day > where I was doing web development and design integration, everyone seemed > to hate CSS, so I am a bit curious and dubious about this choice. We cannot stick with the 'standard' CSS syntax by necessity, simply because the standard CSS selectors and properties are defined from HTML and do not match with matplotlib. I.E we want to select by artist type, which doesn't exist in HTML and use properties such as linewidth. So, we would need to define a new syntax based on these tokens. I have updated MEP26 with a BNF form of a basic syntax to use - take a look! Another option would be to use the syntax for the ConfigParser module; this way we already have a parser :) Nelle Varoquaux wrote > I think we need to be careful about the choice of the grammar and the API: > we know there are tools that are "doing it right", and tools that aren't > (matplotlib falls in the second category). Before trying our own recipe I > suggest that we look elsewhere, on how other libraries are tackling this > problem, to see if we can reuse some of the good ideas and avoid errors. I > am thinking in particular about ggplot2 (which I have never used, but I > hear is very nice). > > Thanks, > Nelle I thought CSS would be a good language to base it on as it is a widely known and by far the most popular (as far as I know) 'stylesheet' language. Other libraries that use style sheets, based on some form of CSS are: Qt - Pyside/PyQt ('QSS') Mapnik ('CartoCSS') PyGal supports stylesheets (don't know much about this library) As I say, an alternative could be simply using the ConfigParser Richard Hattersley wrote >> >> Do you have ideas on how one or more stylesheets would be "attached" to a >> particular figure, etc? >> >> Regards, >> Richard Hattersley >> This is the big question. We need a standard way in which to traverse all the artists in a figure, filter them by the selectors and applying the property updates. The last part is easiest - the update() method on artists will accept a dictionary. We can simply ensure that our stylesheet rules are parsed into a dict structure (which is quite a common method to use). The hard part is a) Getting a complete figure description/traversing the artists. This is currently tricky, but I think the ideas proposed in MEP25 will make it much easier. b) Filtering artists Another problem is that we would generally want to treat artists which are solely for the construction of the Axes differently to those artists that define a plot. I.E we might want to define Line2D as having the colour red, but we want lines which compose the Axes to be black or grey. My initial proposal is to develop stylesheets for artist primitives only. But eventually we will want to style artist containers aswell. The problem matplotlib has is that the properties for artist containers are not uniform/intuitive. It generally has a API where artists which are 'contained' by other artists are set by calling properties...e.g. axes.set_ylabel(text = , etc...) I would prefer to be able to simply pass a class instance...e.g create an instance of Text() and pass that to set_ylabel() I believe this is similar to the Plotly API that is quite nice: https://plot.ly/python/line-and-scatter/ An ideal solution would be trying to seperate out the style of artists from the actual drawing/data PyGal accepts a `Style` instance as an arguement to it's plotting functions, which would be a good way to go. I would imagine setting stylesheets through the axes or figure methods (axes.setStyleSheet() or figure.setStyleSheet()). Via figure would require being able to differentiate between different axes - i.e. introducing the 'container' level syntax I mentioned above. I would imagine that this would eventually replace rcparams to define the default style. I would also like to see the default look of graphs moving away from the very dated, 90's style MATLAB appearance! Anyway, there are a lot of ideas above, some of which are feasible, some of which perhaps not, all of which need more thinking about! -- View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43671.html Sent from the matplotlib - devel mailing list archive at Nabble.com. |
From: Nelle V. <nel...@gm...> - 2014-07-18 16:10:04
|
Hi James, > Thanks for sharing the MEP - it's a really interesting idea, and the MEP > itself looks like a good start. > It is indeed a very interesting idea, and a challenging one! Thanks for tackling this problem. > I'd strongly encourage you to stick with standard CSS syntax/behaviour > instead of extending it. For example, the selector of "Axes.ylabel" would > be more consistent as "Axes .ylabel" (or perhaps "Axis.y .label"). > I actually think we need to focus on something easy to parse and easy to use, not necessarily stick to the CSS syntax and behaviour. Back in the day where I was doing web development and design integration, everyone seemed to hate CSS, so I am a bit curious and dubious about this choice. I think we need to be careful about the choice of the grammar and the API: we know there are tools that are "doing it right", and tools that aren't (matplotlib falls in the second category). Before trying our own recipe I suggest that we look elsewhere, on how other libraries are tackling this problem, to see if we can reuse some of the good ideas and avoid errors. I am thinking in particular about ggplot2 (which I have never used, but I hear is very nice). Thanks, Nelle > > Do you have ideas on how one or more stylesheets would be "attached" to a > particular figure, etc? > > Regards, > Richard Hattersley > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: R H. <rha...@gm...> - 2014-07-18 12:56:30
|
Hi James, Thanks for sharing the MEP - it's a really interesting idea, and the MEP itself looks like a good start. I'd strongly encourage you to stick with standard CSS syntax/behaviour instead of extending it. For example, the selector of "Axes.ylabel" would be more consistent as "Axes .ylabel" (or perhaps "Axis.y .label"). Do you have ideas on how one or more stylesheets would be "attached" to a particular figure, etc? Regards, Richard Hattersley |
From: James R. <jam...@gm...> - 2014-07-16 16:34:40
|
Hi, I just started working on MEP26 <https://github.com/matplotlib/matplotlib/wiki/MEP26> to create a stylesheet syntax & implementation for dynamic, artist-level stylesheets. There is still a lot of work to be done on the MEP, but hopefully it is a good starting point for discussion Thanks James |
From: Paul H. <pmh...@gm...> - 2014-07-16 13:28:55
|
The defaults got reverted, but the baseline images did not. Here's a branch with (un-?)updated baseline images: https://github.com/phobson/matplotlib/commit/8b719e7bda4cef254fbe515e5dfc23d88f3ff5da I based it off of master, should probably pull them into the 1.4.x branch before submitting the PR. -p On Tue, Jul 15, 2014 at 11:28 PM, Lennart Fricke <le...@di...> wrote: > Hello Paul Hobson, > > you changed defaults in: > > commit 7df0313b010d211997cf391d1bee38e194db5618 > Author: Paul Hobson <pmh...@gm...> > Date: Wed May 14 00:01:57 2014 -0700 > > restored default boxplot style and respect for the sym kwa > > since then the plots look like they do now. > Maybe we should change the baseline images. > > Best regards > Lennart > > |
From: Lennart F. <le...@di...> - 2014-07-16 06:28:55
|
Hello Paul Hobson, you changed defaults in: commit 7df0313b010d211997cf391d1bee38e194db5618 Author: Paul Hobson <pmh...@gm...> Date: Wed May 14 00:01:57 2014 -0700 restored default boxplot style and respect for the sym kwa since then the plots look like they do now. Maybe we should change the baseline images. Best regards Lennart |
From: David P. S. <dps...@ci...> - 2014-07-15 23:31:24
|
Hi, I am trying to do some reorganization of the examples in the gallery by moving the files into other directories. I am using ack to look for references from other parts of the documentation to those example files and have successfully caught most of them. But now I am trying to move legend_demo.py from the api subdirectory of examples, and when I compile the API docs, it says that it can't find the file (error output below). However, there does not seem to be anywhere that actually references that file... Can anybody suggest what is going on? Thanks, David. reading sources... [ 0%] api/axes_api Exception occurred: File "/usr/local/Cellar/python/2.7.8/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.9-x86_64.egg/matplotlib/sphinxext/plot_directive.py", line 718, in run with io.open(source_file_name, 'r', encoding='utf-8') as fd: IOError: [Errno 2] No such file or directory: '/Users/david/development/matplotlib/doc/mpl_examples/api/legend_demo.py' -- Dr. David P. Sanders Profesor Titular "A" / Associate Professor Departamento de Física, Facultad de Ciencias Universidad Nacional Autónoma de México (UNAM) dps...@ci... http://sistemas.fciencias.unam.mx/~dsanders Cubículo / office: #414, 4o. piso del Depto. de Física Tel.: +52 55 5622 4965 |
From: Paul H. <pmh...@gm...> - 2014-07-15 22:46:28
|
I'll look into this now. On Tue, Jul 15, 2014 at 11:43 AM, Lennart Fricke <le...@di...> wrote: > > Hello, > > could somebody please check if the baseline_image is like it should be. > During refactoring some of the linestyle handling, the test mentioned > fails. > And it seems to me, that the expected image is not correct. > > Best regards > Lennart > > > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Lennart F. <le...@di...> - 2014-07-15 19:01:56
|
Hello, could somebody please check if the baseline_image is like it should be. During refactoring some of the linestyle handling, the test mentioned fails. And it seems to me, that the expected image is not correct. Best regards Lennart |
From: Lennart F. <le...@di...> - 2014-07-15 18:56:56
|
Hello, could somebody please check if the baseline_image is like it should be. During refactoring some of the linestyle handling, the test mentioned fails. And it seems to me, that the expected image is not correct. Best regards Lennart |
From: Nathaniel S. <nj...@po...> - 2014-07-14 21:48:20
|
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 they do that could have an option)...? -n On 14 Jul 2014 22:16, "Matthew Brett" <mat...@gm...> wrote: > 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: > > plt.figure() > plt.plot(range(5), 'r') > ``` > > In the second panel you see plots for both the first figure and the > second figure, because the underlying code is making this call: > > fig_managers = _pylab_helpers.Gcf.get_all_fig_managers() > > to find all current figures, finding the first and the second figure, > and rendering both. I think this is unlikely to be what the user > expects (it confused me), but I wasn't sure what the best way to work > round it was. I considered adding another option like `:myfigs: true` > to the directive which would only pick up figures I create using the > current code block - is there a better way? > > Cheers, > > Matthew > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Matthew B. <mat...@gm...> - 2014-07-14 21:15:40
|
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: plt.figure() plt.plot(range(5), 'r') ``` In the second panel you see plots for both the first figure and the second figure, because the underlying code is making this call: fig_managers = _pylab_helpers.Gcf.get_all_fig_managers() to find all current figures, finding the first and the second figure, and rendering both. I think this is unlikely to be what the user expects (it confused me), but I wasn't sure what the best way to work round it was. I considered adding another option like `:myfigs: true` to the directive which would only pick up figures I create using the current code block - is there a better way? Cheers, Matthew |
From: Nelle V. <nel...@gm...> - 2014-07-14 12:56:16
|
On 14 July 2014 00:10, Damon McDougall <dam...@gm...> wrote: > On Sun, Jul 13, 2014 at 12:27 AM, Eric Firing <ef...@ha...> wrote: > > On 2014/07/12, 7:20 PM, Thomas Caswell wrote: > >> Hey all, > >> > >> After a very productive sprint at scipy (according to pluse, we merged > >> 35 PRs in the last 3 days), I have created the 1.4.x branch and tagged > >> the first release candidate (1.4.0rc1). > >> > >> There are a good number of outstanding issues with documentation (re > >> the fate of pylab and installation) and one small issue with data > >> cleaning in boxplots. > >> > >> I proposing giving our selves a 2 week deadline to have everything > finalized. > >> > >> Tom > >> > > > > Excellent! Thanks very much for keeping on top of all this, and for the > > amazing amount of work you have been doing. > > I echo Eric's comments. > > Fantastic job, Thomas. > And very much appreciated! N > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 > > > ------------------------------------------------------------------------------ > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck® > Code Sight™ - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Damon M. <dam...@gm...> - 2014-07-14 04:10:32
|
On Sun, Jul 13, 2014 at 12:27 AM, Eric Firing <ef...@ha...> wrote: > On 2014/07/12, 7:20 PM, Thomas Caswell wrote: >> Hey all, >> >> After a very productive sprint at scipy (according to pluse, we merged >> 35 PRs in the last 3 days), I have created the 1.4.x branch and tagged >> the first release candidate (1.4.0rc1). >> >> There are a good number of outstanding issues with documentation (re >> the fate of pylab and installation) and one small issue with data >> cleaning in boxplots. >> >> I proposing giving our selves a 2 week deadline to have everything finalized. >> >> Tom >> > > Excellent! Thanks very much for keeping on top of all this, and for the > amazing amount of work you have been doing. I echo Eric's comments. Fantastic job, Thomas. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 |