matplotlib-devel — matplotlib developers

[matplotlib-devel] windows binaries for 1.4.0rc2 are available

[Thomas C. <tca...@gm...>]

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...

[matplotlib-devel] rc2

[Thomas C. <tca...@gm...>]

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...

Re: [matplotlib-devel] Trying to prepare a pull request but tests.py keeps crashing on master

[Benjamin R. <ben...@ou...>]

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
>

[matplotlib-devel] MEP22 comments

[Federico A. <ari...@gm...>]

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

[matplotlib-devel] Trying to prepare a pull request but tests.py keeps crashing on master

[Stefan H. <shm...@gm...>]

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.

[matplotlib-devel] rc2 prep

[Thomas C. <tca...@gm...>]

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...

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[R H. <rha...@gm...>]

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;
}

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[R H. <rha...@gm...>]

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;
}

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[Thomas C. <tca...@gm...>]

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...

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[jamesramm <jam...@gm...>]

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.

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[R H. <rha...@gm...>]

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

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[jamesramm <jam...@gm...>]

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.

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[Nelle V. <nel...@gm...>]

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
>
>

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[R H. <rha...@gm...>]

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

[matplotlib-devel] MEP26: Artist-level stylesheets

[James R. <jam...@gm...>]

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

Re: [matplotlib-devel] test_axes:test_bxp_custombox baseline image wrong?

[Paul H. <pmh...@gm...>]

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
>
>

Re: [matplotlib-devel] test_axes:test_bxp_custombox baseline image wrong?

[Lennart F. <le...@di...>]

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

[matplotlib-devel] How to find references to examples?

[David P. S. <dps...@ci...>]

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

Re: [matplotlib-devel] test_axes:test_bxp_custombox baseline image wrong?

[Paul H. <pmh...@gm...>]

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
>

[matplotlib-devel] test_axes:test_bxp_custombox baseline image wrong?

[Lennart F. <le...@di...>]

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

[matplotlib-devel] test_axes:test_bxp_custombox baseline image wrong?

[Lennart F. <le...@di...>]

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

Re: [matplotlib-devel] plot_directive, context and multiple plots

[Nathaniel S. <nj...@po...>]

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
>

[matplotlib-devel] plot_directive, context and multiple plots

[Matthew B. <mat...@gm...>]

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

Re: [matplotlib-devel] 1.4.0rc1 has been tagged

[Nelle V. <nel...@gm...>]

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&#174;
> Code Sight&#153; - 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
>

Re: [matplotlib-devel] 1.4.0rc1 has been tagged

[Damon M. <dam...@gm...>]

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