matplotlib-devel Mailing List for matplotlib (Page 5)

Are your tests including the "@cleanup" decorator? (The @cleanup 
decorator is run implicitly with the @image_comparison decorator, so you 
really only need one or the other).
Beyond that wild guess, I'm not sure what could be going on. You could 
file a pull request with your new code, even if it's not fully ready, so 
we could try it out and poke at it. Or just point us to your git branch 
so we could check it out.
Mike
On 10/10/2013 07:33 AM, Todd wrote:
> I have been implementing some new plot types, with tests. This code 
> passes all existing tests. I have also expanded the tests on some 
> existing plot types and mlab functions. These tests run fine on their 
> own.
>
> The problem is that, when I run the code with the new tests, I get a 
> lot of out of memory errors. Further, the errors do not occur in the 
> new tests, but rather in other, unrelated tests. Further, the tests 
> that fail work fine when run on their own, they only fail when run as 
> part of the complete test suite.
>
> Even stranger, when I run the tests in parallel (even with only one 
> process) and enable "--process-restartworker", the tests run fine 
> (with a large enough timeout). But "--process-restartworker" doesn't 
> help if parallel tests are not turned on.
>
> So I am not sure exactly what to do here. Even if I leave out my own 
> tests, I may be running into some limit or memory leak that may very 
> well result in problems for other people down the road.
>
> A solution might be to force tests to run in parallel with 
> "--process-restartworker", but of course it would be better to find 
> out where the leak is.
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

Hello,
I am developing a toolkit to parse, analyse and plot some scientific
data using matplotlib. Among them are some application-specific plotting
functions that sort of extend matplotlib.
There are these nice image comparison decorators to test code like that
but I am not sure how to use them for unit testing outside the scope of
matplotlib itself. Is this use case intended and possible for the decorator?
I have experimented with this unsuccessfully in the following way:
There is a tests directory within my package with test functions
decorated like so
@image_comparison(baseline_images=['custom_function'])
def test_custom_function():
 # plot stuff...
When I run nosetests, it fails creating some output images in
result_images.
Copying the appropriate files according to [1] to
my_package/tests/baseline_images does not seem to have any effect. There
are neither *-expected* nor *_{pdf,svg}.png files in there, only
custom_function.{pdf,svg,png}. What am I doing wrong?
Eduard
[1] http://matplotlib.org/devel/testing.html

I have been implementing some new plot types, with tests. This code passes
all existing tests. I have also expanded the tests on some existing plot
types and mlab functions. These tests run fine on their own.
The problem is that, when I run the code with the new tests, I get a lot of
out of memory errors. Further, the errors do not occur in the new tests,
but rather in other, unrelated tests. Further, the tests that fail work
fine when run on their own, they only fail when run as part of the complete
test suite.
Even stranger, when I run the tests in parallel (even with only one
process) and enable "--process-restartworker", the tests run fine (with a
large enough timeout). But "--process-restartworker" doesn't help if
parallel tests are not turned on.
So I am not sure exactly what to do here. Even if I leave out my own
tests, I may be running into some limit or memory leak that may very well
result in problems for other people down the road.
A solution might be to force tests to run in parallel with
"--process-restartworker", but of course it would be better to find out
where the leak is.

Hi,
I am trying to use matplotlib to create script files that I can use to
render 3D plots in blender. I have already created the code to create the
file itself. I am currently trying to find the best place to put my code
into. I have tried using top level methods like get_path(), however these
functions do not work because they return the data points after they have
been projected and to render in blender I need the raw data points.
I have tried editing the axes3d file and was able to create a working file.
However, I am worried there will be too much code recreation at this level. 
I have also attempted to edit the art3d file to try to have less code
generation. However, I was unable to find all of the data for the points.
Any help or ideas on where to put the code would be greatly appreciated.
If anymore information is needed please let me know, this is my first post
so I apologize if I left something out.
Thanks,
James
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Rendering-in-Blender-tp42205.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On 7 October 2013 15:22, Michael Droettboom <md...@st...> wrote:
> I like this idea. I've seen this called "extern" in other projects, but I
> don't have a strong feeling about the name. I think it's good idea for all
> of the reasons you mention.
>
OK, 'extern' seems the best directory name. After I've finished the qhull
PR I'll create another one to move the existing directories across.
Ian

Sorry for this delay.
I've put up the site at: http://conference.scipy.org/jhepc2013/
I'll get Jim to incorporate it in the main site.
-- Andy
On Thu, Aug 8, 2013 at 12:38 PM, Michael Droettboom <md...@st...> wrote:
> On 08/08/2013 11:56 AM, Andy Ray Terrel wrote:
>
>> Doh, I never got the site up! This looks good, although copyright
>> shouldn't go to Michael. We don't have copyright on the images or
>> text just permission to display them. (I would probably just delete
>> it or be specific what the copyright is.) I like the idea of having a
>> site next to conference.scipy.org to display these.
>>
>
> Yeah -- the copyright ended up to me accidentally because I filled it out
> as the "author" field in Sphinx in the original version. I think if we
> want to have an "author" it should say "Scipy Conference Organizers"
> (without copyright), and maybe we give Nelle some well deserved credit for
> the web design as well.
>
> Mike
>
>
>
>> -- Andy
>>
>> On Thu, Aug 8, 2013 at 10:48 AM, Nelle Varoquaux
>> <nel...@gm...> wrote:
>>
>>> Hi everyone,
>>>
>>> Here is my attempt at making the website:
>>> http://nellev.github.io/tmp/**jhepc/index.html<http://nellev.github.io/tmp/jhepc/index.html>
>>> This is still work in progress, but feedback is welcomed.
>>>
>>> I chose to display only the "winners" (three top place + honorable
>>> mention).
>>>
>>> Cheers,
>>> N
>>>
>>>
>>> On 31 July 2013 17:54, Andy Ray Terrel <and...@gm...> wrote:
>>>
>>>> Okay, I'll get it up.
>>>>
>>>> -- Andy
>>>>
>>>>
>>>> On Wed, Jul 31, 2013 at 10:48 AM, Michael Droettboom <md...@st...>
>>>> wrote:
>>>>
>>>>> On 07/31/2013 11:38 AM, Andy Ray Terrel wrote:
>>>>>
>>>>>
>>>>> The plan was to have it on the SciPy conference website, but we haven't
>>>>> really got it up. If someone can point me to rendered html, I can ask
>>>>> Jim to
>>>>> put it up there now.
>>>>>
>>>>> The rendered HTML is in the scipy2013_talks github repo.
>>>>>
>>>>> https://github.com/scipy/**scipy2013_talks/tree/master/**
>>>>> plotting_contest<https://github.com/scipy/scipy2013_talks/tree/master/plotting_contest>
>>>>>
>>>>> That will be fine for now, and it sounds like Nelle will make the
>>>>> presentation much better down the road, at which case we can update it
>>>>> then.
>>>>>
>>>>> Mike
>>>>>
>>>>
>>>>
>

I like this idea. I've seen this called "extern" in other projects, but I don't have a strong feeling about the name. I think it's good idea for all of the reasons you mention.
Mike
________________________________________
From: Ian Thomas [ian...@gm...]
Sent: Sunday, October 06, 2013 4:09 PM
To: mat...@li...
Subject: [matplotlib-devel] Directories for C/C++ extensions
Fellow developers,
I am working on a PR to replace the use of matplotlib.delaunay with the Qhull library. Installation will be similar to the existing packages LibAgg and CXX in that if the system already has a sufficiently recent version of Qhull installed then matplotlib will use that, otherwise it will build the required library from the source code shipped with matplotlib.
I have a thin C wrapper called qhull_wrap.c (following the coding guidelines) which I'll put in the top-level src directory along with most of the existing C/C++ extensions. But my question is where to put the qhull source code?
Current practice has separate top-level directories called agg24 and CXX for the LibAgg and CXX packages respectively, so my initial thought was to follow this and create a new top-level directory called qhull to place the library code in. But I don't like this approach of creating a new top-level directory as (1) I think the top-level should remain as simple and uncluttered as possible, (2) it tends to overemphasize the importance of these third-party libraries as they are some of the first directories users see when unzipping the mpl tarball, and (3) it is not immediately obvious that the code in these directories is from third-party libraries rather than something we ourselves have written.
Hence my preference is to create a new top-level directory called something like 'third-party' (or should that be 'third_party'?), and place all the third-party libraries in that; i.e. move the agg24 and CXX directories into third-party, and place the new qhull source code in third-party/qhull.
What do others think of this idea?
Ian Thomas

On 2013年10月06日 10:09 AM, Ian Thomas wrote:
> Fellow developers,
>
> I am working on a PR to replace the use of matplotlib.delaunay with the
> Qhull library. Installation will be similar to the existing packages
> LibAgg and CXX in that if the system already has a sufficiently recent
> version of Qhull installed then matplotlib will use that, otherwise it
> will build the required library from the source code shipped with
> matplotlib.
>
> I have a thin C wrapper called qhull_wrap.c (following the coding
> guidelines) which I'll put in the top-level src directory along with
> most of the existing C/C++ extensions. But my question is where to put
> the qhull source code?
>
> Current practice has separate top-level directories called agg24 and CXX
> for the LibAgg and CXX packages respectively, so my initial thought was
> to follow this and create a new top-level directory called qhull to
> place the library code in. But I don't like this approach of creating a
> new top-level directory as (1) I think the top-level should remain as
> simple and uncluttered as possible, (2) it tends to overemphasize the
> importance of these third-party libraries as they are some of the first
> directories users see when unzipping the mpl tarball, and (3) it is not
> immediately obvious that the code in these directories is from
> third-party libraries rather than something we ourselves have written.
>
> Hence my preference is to create a new top-level directory called
> something like 'third-party' (or should that be 'third_party'?), and
> place all the third-party libraries in that; i.e. move the agg24 and CXX
> directories into third-party, and place the new qhull source code in
> third-party/qhull.
>
> What do others think of this idea?
Adding this top-level directory is OK with me, but since I hope we will 
not need to carry along very many of such library source trees, it 
doesn't seem so important to segregate them in this way. If you do, 
alternative names might be "dependencies" or "external". The contents 
don't necessarily match what can be found elsewhere; Mike has needed to 
make local patches on occasion.
Eric
>
> Ian Thomas

Fellow developers,
I am working on a PR to replace the use of matplotlib.delaunay with the
Qhull library. Installation will be similar to the existing packages
LibAgg and CXX in that if the system already has a sufficiently recent
version of Qhull installed then matplotlib will use that, otherwise it will
build the required library from the source code shipped with matplotlib.
I have a thin C wrapper called qhull_wrap.c (following the coding
guidelines) which I'll put in the top-level src directory along with most
of the existing C/C++ extensions. But my question is where to put the
qhull source code?
Current practice has separate top-level directories called agg24 and CXX
for the LibAgg and CXX packages respectively, so my initial thought was to
follow this and create a new top-level directory called qhull to place the
library code in. But I don't like this approach of creating a new
top-level directory as (1) I think the top-level should remain as simple
and uncluttered as possible, (2) it tends to overemphasize the importance
of these third-party libraries as they are some of the first directories
users see when unzipping the mpl tarball, and (3) it is not immediately
obvious that the code in these directories is from third-party libraries
rather than something we ourselves have written.
Hence my preference is to create a new top-level directory called something
like 'third-party' (or should that be 'third_party'?), and place all the
third-party libraries in that; i.e. move the agg24 and CXX directories into
third-party, and place the new qhull source code in third-party/qhull.
What do others think of this idea?
Ian Thomas

In article <201...@me...>,
 mark <ma...@me...> wrote:
> Many thanks for the feedback.
> 
> So ,my first cut was to segregate the user guide by topic. Below is
> the summary I had in mind for an Introduction for New Users.
> 
> Hopefully this gives a flavour of what I have in mind.
> 
> I will attempt to put this into practice and post again when I have a
> user guide coded that might work in my view.
> 
> mark
> 
> 
> Introducing Plotting with Matplotlib
> 
> Pyplot tutorial
> Controlling line properties
> Working with multiple figures and axes
> Working with text
> Interactive navigation
> Navigation Keyboard Shortcuts
> Working with text
> Text introduction
> Basic text commands
> Text properties and layout
> Writing mathematical expressions
> Text rendering With LaTeX
> Annotating text
...
On the whole this looks good to me. I so have a few comments, however:
- Would you be willing to include a section on using the class API? (I'm 
assuming the above is all based on using pyplot?). I find there is a 
huge gap between pyplot and the class API, and the documentation I've 
found does little to bridge that gap.
- You have "Working with text" (including "annotating text") early on, 
then "Legend guide" and "Annotating Axes" much later on. I wish these 
were all together, as axes (values and labels), plot titles and legends 
are arguably the main use cases for text in plots. Perhaps it would 
suffice to have "Working with text" give a brief overview of how to do 
each of these things, with pointers to the other sections for details. 
An alternative is subsections within Working with text.
- In a similar vein: I'm surprised GridSpec comes before legends and 
annotating axes.
- Please consider a section on 3-d plots.
- Please consider a section on animation.
-- Russell

In article <524...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> On 10/02/2013 01:34 PM, Russell E. Owen wrote:
> > In article <524...@st...>,
> > Michael Droettboom <md...@st...>
> > wrote:
> >
> >> I haven't heard of this issue before.
> >>
> >> fc-list comes from the fontconfig project. It is used to get a list of
> >> all of the fonts installed on the system. It sounds like there is some
> >> bug there -- the usual culprit is that there is a slightly non-standard
> >> font installed on the system and fontconfig has a hard time parsing it.
> >> You could try updating fc-list (it's in all the major package managers).
> >>
> >> As for a workaround from our end, we could try to set a timeout on
> >> fc-list and just skip it if it takes too long. We can't rely on it
> >> being there on a Mac at all, so already we gracefully degrade to a less
> >> thorough search for fonts when fc-list can't be found.
> > Thanks for the advice. A defective font is an interesting possibility.
> >
> > I was wrong it's new in 1.3.0; turns out it's seen in much older
> > versions of my application (back to using mpl 1.0.0), but apparently on
> > few machines.
> >
> > The issue showed up when I added some fancy animated strip charts to my
> > application (which may be a coincidence), not when I upgraded mpl.
> >
> > I'm surprised the timeout on fc-list isn't working.
> 
> We don't currently do a timeout -- we make a blocking call to fc-list. 
> I was only suggesting it as a possible fix for this problem.
Sorry. I read too hastily. If it's not too hard to code a time limit, it 
sounds like a good idea.
> > Maybe something else
> > is also using fc-list, but the fix is to add an ~/.matplotlib dir, which
> > suggests it's an mpl issue.
> 
> When you copy over the .matplotlib dir, you copy over the font cache. 
> When matplotlib finds a font cache, it doesn't need to generate a list 
> of fonts, so thus doesn't need to call fc-list. But copying font caches 
> from one machine to another is unlikely to work (the set of fonts and 
> their locations is quite likely different). Worse yet, if matplotlib 
> attempts to look up a font and finds that it isn't where the cache says 
> it is, it regenerates the cache again, and thus you could get this 
> hanging anyway.
Thank you for that warning.
As a followup: one of the two computers had 3 copies of fc-list (one 
from darwinports, one in /usr/local/bin and the on provided with Apple's 
X11). Making sure Apple's version ran seems to have cleared up the 
problem, based on one test. So we may have a fix.
I really appreciate the help.
-- Russell

Using git blame, I can see that the AxisMenu class was last touched by John
Hunter back in 2004, during a massive restructuring of the code-base. It
looks like at that time, there were only 3 interactive backends: Gtk, Wx
and TkAgg. Maybe someone with a much longer history than I could chime in
on the purpose of this class.

Hi
All around the documentation, there are plenty of places where the
signature of class variables is displayed straight and without any
formating.
For example
http://matplotlib.org/api/backend_bases_api.html?highlight=toolitems#matplotlib.backend_bases.NavigationToolbar2.toolitems
Is it possible to override this signature?
If I'm not wrong the autodoc_docstring_signature (sphinx
configuration) only works on callables
Thanks
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

Hello
I am preparing the Tkinter implementation of my MultiFigureManager
In backend_tkagg there is AxisMenu
Looking throught all the matplotlib code I do not see any place where
this is used, not even an example
Is this something that we want to keep around? does somebody use it?
Just as a reminder to get feedback on the multifigure-manager
Compare: https://github.com/fariza/matplotlib/compare/tabbed-gtk3-figuremanager
PR: https://github.com/matplotlib/matplotlib/pull/2465
Thanks
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

On Wed, Oct 2, 2013 at 11:46 AM, Michael Droettboom <md...@st...> wrote:
> I think the poll is in, and it looks like the best time for us to meet
> is Thursdays, 14:00 - 16:00 UTC.
>
> Given some other commitments, I can't make it until October 24. Does
> that work? I've tentatively added it to the matplotlib calendar.
>
> Mike
Thanks for doing that Mike, that works for me.
>
> On 09/18/2013 11:50 AM, Michael Droettboom wrote:
>> As I had considered doing a while ago, I think it might be beneficial to
>> start having regular Google Hangouts for matplotlib. I'm thinking
>> monthly is probably adequate for now while we experiment with the format.
>>
>> As you may know, Google Hangouts has a maximum number of 10
>> participants, but an unlimited number of people may watch both live and
>> from the archive. I believe also (correct me if I'm wrong) there is no
>> such limit on the people who can participate by text chat.
>>
>> I've created a "Doodle" poll [1] to help find a time during the week
>> that would be best for most.
>>
>> [1] http://doodle.com/fek9q2wsyegg6ytt
>>
>> I figure many of these meetings will include a "core" group of people
>> with "special guests" for various specific topics as they arise. Anyone
>> can fill out the poll, but please send me an e-mail off list if you plan
>> to attend on a regular basis rather than just drop in when possible so I
>> can prioritize things. Once we've determined a good time of the week
>> for everyone, I'll schedule the next 6 or so months on the matplotlib
>> Google calendar [2].
>>
>> [2]
>> https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic
>>
>> Cheers,
>> Mike
>>
>
>
> --
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
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

On 10/02/2013 01:34 PM, Russell E. Owen wrote:
> In article <524...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
>> I haven't heard of this issue before.
>>
>> fc-list comes from the fontconfig project. It is used to get a list of
>> all of the fonts installed on the system. It sounds like there is some
>> bug there -- the usual culprit is that there is a slightly non-standard
>> font installed on the system and fontconfig has a hard time parsing it.
>> You could try updating fc-list (it's in all the major package managers).
>>
>> As for a workaround from our end, we could try to set a timeout on
>> fc-list and just skip it if it takes too long. We can't rely on it
>> being there on a Mac at all, so already we gracefully degrade to a less
>> thorough search for fonts when fc-list can't be found.
> Thanks for the advice. A defective font is an interesting possibility.
>
> I was wrong it's new in 1.3.0; turns out it's seen in much older
> versions of my application (back to using mpl 1.0.0), but apparently on
> few machines.
>
> The issue showed up when I added some fancy animated strip charts to my
> application (which may be a coincidence), not when I upgraded mpl.
>
> I'm surprised the timeout on fc-list isn't working.
We don't currently do a timeout -- we make a blocking call to fc-list. 
I was only suggesting it as a possible fix for this problem.
> Maybe something else
> is also using fc-list, but the fix is to add an ~/.matplotlib dir, which
> suggests it's an mpl issue.
When you copy over the .matplotlib dir, you copy over the font cache. 
When matplotlib finds a font cache, it doesn't need to generate a list 
of fonts, so thus doesn't need to call fc-list. But copying font caches 
from one machine to another is unlikely to work (the set of fonts and 
their locations is quite likely different). Worse yet, if matplotlib 
attempts to look up a font and finds that it isn't where the cache says 
it is, it regenerates the cache again, and thus you could get this 
hanging anyway.
Mike
>
> -- Russell
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

In article <524...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> I haven't heard of this issue before.
> 
> fc-list comes from the fontconfig project. It is used to get a list of 
> all of the fonts installed on the system. It sounds like there is some 
> bug there -- the usual culprit is that there is a slightly non-standard 
> font installed on the system and fontconfig has a hard time parsing it. 
> You could try updating fc-list (it's in all the major package managers).
> 
> As for a workaround from our end, we could try to set a timeout on 
> fc-list and just skip it if it takes too long. We can't rely on it 
> being there on a Mac at all, so already we gracefully degrade to a less 
> thorough search for fonts when fc-list can't be found.
Thanks for the advice. A defective font is an interesting possibility.
I was wrong it's new in 1.3.0; turns out it's seen in much older 
versions of my application (back to using mpl 1.0.0), but apparently on 
few machines. 
The issue showed up when I added some fancy animated strip charts to my 
application (which may be a coincidence), not when I upgraded mpl.
I'm surprised the timeout on fc-list isn't working. Maybe something else 
is also using fc-list, but the fix is to add an ~/.matplotlib dir, which 
suggests it's an mpl issue.
-- Russell

I think the poll is in, and it looks like the best time for us to meet 
is Thursdays, 14:00 - 16:00 UTC.
Given some other commitments, I can't make it until October 24. Does 
that work? I've tentatively added it to the matplotlib calendar.
Mike
On 09/18/2013 11:50 AM, Michael Droettboom wrote:
> As I had considered doing a while ago, I think it might be beneficial to
> start having regular Google Hangouts for matplotlib. I'm thinking
> monthly is probably adequate for now while we experiment with the format.
>
> As you may know, Google Hangouts has a maximum number of 10
> participants, but an unlimited number of people may watch both live and
> from the archive. I believe also (correct me if I'm wrong) there is no
> such limit on the people who can participate by text chat.
>
> I've created a "Doodle" poll [1] to help find a time during the week
> that would be best for most.
>
> [1] http://doodle.com/fek9q2wsyegg6ytt
>
> I figure many of these meetings will include a "core" group of people
> with "special guests" for various specific topics as they arise. Anyone
> can fill out the poll, but please send me an e-mail off list if you plan
> to attend on a regular basis rather than just drop in when possible so I
> can prioritize things. Once we've determined a good time of the week
> for everyone, I'll schedule the next 6 or so months on the matplotlib
> Google calendar [2].
>
> [2]
> https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic
>
> Cheers,
> Mike
>
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

I haven't heard of this issue before.
fc-list comes from the fontconfig project. It is used to get a list of 
all of the fonts installed on the system. It sounds like there is some 
bug there -- the usual culprit is that there is a slightly non-standard 
font installed on the system and fontconfig has a hard time parsing it. 
You could try updating fc-list (it's in all the major package managers).
As for a workaround from our end, we could try to set a timeout on 
fc-list and just skip it if it takes too long. We can't rely on it 
being there on a Mac at all, so already we gracefully degrade to a less 
thorough search for fonts when fc-list can't be found.
Mike
On 10/01/2013 08:15 PM, Russell E. Owen wrote:
> I distribute a Mac application using matplotlib.
>
> Recent versions that use matplotlib 1.3.0 fail to run on some new
> accounts. The symptoms are that the application never finishes loading
> and a task named "fc-list" takes up 100% of a core -- for as long as
> we've let it run (a good fraction of an hour).
>
> The only solution we've found is to copy ~/.matplotlib from an account
> where it works to the new account.
>
> It is reproducible on some machines, but unfortunately not mine. When I
> create a new account on my machine I do not see the problem. Thus I have
> not yet been able to come up with a minimal case that shows the problem.
> I'll try to get more info.
>
> Is this is a known issue?
>
> -- Russell
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

I distribute a Mac application using matplotlib.
Recent versions that use matplotlib 1.3.0 fail to run on some new 
accounts. The symptoms are that the application never finishes loading 
and a task named "fc-list" takes up 100% of a core -- for as long as 
we've let it run (a good fraction of an hour).
The only solution we've found is to copy ~/.matplotlib from an account 
where it works to the new account.
It is reproducible on some machines, but unfortunately not mine. When I 
create a new account on my machine I do not see the problem. Thus I have 
not yet been able to come up with a minimal case that shows the problem. 
I'll try to get more info.
Is this is a known issue?
-- Russell

Hello
I don't know why it is failing with the macports... not much help
about that from me ;)
If I make it fail on pourpuse, for example adding and unwanted int
third argument in the plot call
import matplotlib
matplotlib.use('gtk3agg')
from numpy import *
from matplotlib.pyplot import *
x = arange(0,10,0.1)
plot(x, sin(x), 0)
show()
The method FigureManagerGTK3.destroy() is being called twice, and
because it calls
self.__dict__.clear()
the second time it is called, it does not find any attribute, and that
is the reason for the UGLY message that hides the real problem. In my
example it is hiding the
ValueError: third arg must be a format string
Actually there is a comment on the line asking why is it called there...
In gtkagg there is a bunch of hasattr calls in the destroy method just
to bypass this problem
Is there any reason for the
self.__dict__.clear() ????
Federico
On Tue, Oct 1, 2013 at 9:43 AM, Michael Kaufman <kau...@or...> wrote:
> Hello all,
>
> I just upgraded my matplotlib and gtk distributions because I thought
> I'd try the GTK3Agg backend (I had been using the GTKAgg backend).
>
> I'm using macports for the supporting libraries with git repositories
> for ipython and matplotlib (today's master [0b8481977016e8f], but I seem
> to have the same issues with tag v1.3.x)
>
> Before installing matplotlib, I did a make clean and then removed
> everything from the build/ directory, and matplotlib* from
> python2.7/site-packages/
>
> The following ports are currently installed:
> gtk2 @2.24.17_1+x11 (active)
> gtk3 @3.10.0_0+x11 (active)
> py27-gobject3 @3.8.3_0 (active)
> py27-gobject @2.28.6_0 (active)
>
> If I use the GTKAgg backend I get these warnings (which I did not get
> before).
>
> ===
> Using matplotlib backend: GTKAgg
>
> In [1]: x = arange(0,10,0.1)
>
> In [2]: plot(x,sin(x))
> /Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk.py:651:
> Warning: Attempt to add property GtkSettings::gtk-label-select-on-focus
> after class was initialised
> gtk.Toolbar.__init__(self)
> /Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk.py:651:
> Warning: Attempt to add property GtkSettings::gtk-button-images after
> class was initialised
> gtk.Toolbar.__init__(self)
> Out[2]: [<matplotlib.lines.Line2D at 0x11025e250>]
> ===
>
> Otherwise everything else seems ok.
>
> If I use the GTK3Agg backend, I get no plot window when I do a show(),
> and when I attempt to exit ipython, I get these errors:
>
> ===
> object? -> Details about 'object', use 'object??' for extra details.
> Using matplotlib backend: GTK3Agg
>
> In [1]: x = arange(0,10,0.1)
>
> In [2]: plot(x,sin(x))
> Out[2]: [<matplotlib.lines.Line2D at 0x10957d450>]
>
> In [3]: show()
>
> In [4]:
> Do you really want to exit ([y]/n)?
> Error in atexit._run_exitfuncs:
> Traceback (most recent call last):
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py",
> line 24, in _run_exitfuncs
> func(*targs, **kargs)
> File
> "/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/_pylab_helpers.py",
> line 89, in destroy_all
> manager.destroy()
> File
> "/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk3.py",
> line 433, in destroy
> self.canvas.destroy()
> AttributeError: FigureManagerGTK3Agg instance has no attribute 'canvas'
> Error in sys.exitfunc:
> Traceback (most recent call last):
> File
> "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py",
> line 24, in _run_exitfuncs
> func(*targs, **kargs)
> File
> "/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/_pylab_helpers.py",
> line 89, in destroy_all
> manager.destroy()
> File
> "/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk3.py",
> line 433, in destroy
> self.canvas.destroy()
> AttributeError: FigureManagerGTK3Agg instance has no attribute 'canvas'
> ===
>
> Anyone have a clue?
>
> M
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

Hello all,
I just upgraded my matplotlib and gtk distributions because I thought 
I'd try the GTK3Agg backend (I had been using the GTKAgg backend).
I'm using macports for the supporting libraries with git repositories 
for ipython and matplotlib (today's master [0b8481977016e8f], but I seem 
to have the same issues with tag v1.3.x)
Before installing matplotlib, I did a make clean and then removed 
everything from the build/ directory, and matplotlib* from
python2.7/site-packages/
The following ports are currently installed:
 gtk2 @2.24.17_1+x11 (active)
 gtk3 @3.10.0_0+x11 (active)
 py27-gobject3 @3.8.3_0 (active)
 py27-gobject @2.28.6_0 (active)
If I use the GTKAgg backend I get these warnings (which I did not get 
before).
===
Using matplotlib backend: GTKAgg
In [1]: x = arange(0,10,0.1)
In [2]: plot(x,sin(x))
/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk.py:651: 
Warning: Attempt to add property GtkSettings::gtk-label-select-on-focus 
after class was initialised
 gtk.Toolbar.__init__(self)
/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk.py:651: 
Warning: Attempt to add property GtkSettings::gtk-button-images after 
class was initialised
 gtk.Toolbar.__init__(self)
Out[2]: [<matplotlib.lines.Line2D at 0x11025e250>]
===
Otherwise everything else seems ok.
If I use the GTK3Agg backend, I get no plot window when I do a show(), 
and when I attempt to exit ipython, I get these errors:
===
object? -> Details about 'object', use 'object??' for extra details.
Using matplotlib backend: GTK3Agg
In [1]: x = arange(0,10,0.1)
In [2]: plot(x,sin(x))
Out[2]: [<matplotlib.lines.Line2D at 0x10957d450>]
In [3]: show()
In [4]:
Do you really want to exit ([y]/n)?
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
 File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", 
line 24, in _run_exitfuncs
 func(*targs, **kargs)
 File 
"/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/_pylab_helpers.py", 
line 89, in destroy_all
 manager.destroy()
 File 
"/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk3.py", 
line 433, in destroy
 self.canvas.destroy()
AttributeError: FigureManagerGTK3Agg instance has no attribute 'canvas'
Error in sys.exitfunc:
Traceback (most recent call last):
 File 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/atexit.py", 
line 24, in _run_exitfuncs
 func(*targs, **kargs)
 File 
"/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/_pylab_helpers.py", 
line 89, in destroy_all
 manager.destroy()
 File 
"/Users/mcj/lib/python2.7/site-packages/matplotlib-1.4.x-py2.7-macosx-10.8-x86_64.egg/matplotlib/backends/backend_gtk3.py", 
line 433, in destroy
 self.canvas.destroy()
AttributeError: FigureManagerGTK3Agg instance has no attribute 'canvas'
===
Anyone have a clue?
M