matplotlib-users Mailing List for matplotlib

What does "print matplotlib.get_backend()" say?

I just installed matplotlib on a new MacBook Pro

ActivePython 2.7.2.5 (ActiveState Software Inc.) based on
Python 2.7.2 (default, Jun 24 2011, 12:20:15) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__version__
'1.7.1'
>>> import matplotlib
>>> matplotlib.__version__
'1.2.1'
>>> matplotlib.matplotlib_fname()
'/Users/tgrav/.matplotlib/matplotlibrc'
>>> 

That works fine. However, when I try to do

import matplotlib.pyplot as plt

it tries to open X11, which I have not installed and would like to 
try to avoid. The matplotlibrc file has

backend     : MacOSX 

Anyone know why it is still trying to open X11 and how I can avoid that?

Le Mer 17 juillet 2013 14:56, Michael Droettboom a écrit :
> Can you please provide a completely standalone example?  The following
> code has undefined variables etc.

Here it is, I'm afraid this testcase intent is less clear than what I
pasted previously (I replaced variables with precomputed values)

As shown in the attached png, the bottom tick labels (month names) are
missing. It worked in matplotlib ≤ 1.2.0

-- 
Nicolas Mailhot

Le Jeu 18 juillet 2013 14:12, Nicolas Mailhot a écrit :
> Le Mer 17 juillet 2013 15:04, Michael Droettboom a écrit :
>> This patch doesn't make a whole lot of sense to me.  get_name should
>> work just fine if self._family is None, and indeed it does in my own
>> testing:
>>
>> ```
>> from matplotlib import font_manager
>>
>> f = font_manager.FontProperties(None)
>> print f._family
>> print f.get_family()
>> print f.get_name()
>> ```
>>
>> So I'd much prefer to get to the bottom of the root cause of this
>> problem than patch it unnecessarily in this way.  Any idea what that is?
>
> I haven't the faintest idea. The function seems to be called with a "None"
> font, and then it crashes. As it's executed under a Linux system it uses
> the fontconfig backend with cairo. The call only occurs when matplotlib is
> fed more data than can be isolated in an simple example
>
> Attaching the only patches Fedora/Red Hat applied before the build :
>
> Patch0:         %{name}-noagg.patch
> Patch1:         %{name}-tk.patch
> # http://sourceforge.net/mailarchive/message.php?msg_id=30202451
> # https://github.com/matplotlib/matplotlib/pull/1666
> # https://bugzilla.redhat.com/show_bug.cgi?id=896182
> Patch2:         %{name}-fontconfig.patch
>
> […]
>
> # Remove bundled libraries
> rm -r agg24 lib/matplotlib/pyparsing_py?.py
>
> # Remove references to bundled libraries
> %patch0 -p1 -b .noagg
> sed -i -e s/matplotlib\.pyparsing_py./pyparsing/g lib/matplotlib/*.py
>
> # Correct tcl/tk detection
> %patch1 -p1 -b .tk
> sed -i -e 's|@@libdir@@|%{_libdir}|' setupext.py
>
> # Use fontconfig by default
> %patch2 -p1 -b .fontconfig

BTW if you have some code to add to the crashing function to identify
what's wrong, I can reproduce the crash at will (though the processing
before crash time is rather long)

Regards,

-- 
Nicolas Mailhot

@Eric: thanks, i see the point

@Jody: thanks for the trick, I'll first try Eric's approach

2013/7/18 Eric Firing <ef...@ha...>:
> On 2013/07/17 11:25 PM, Gregorio Bastardo wrote:
>> Thanks Mike, it's hard to spot, but still better than nothing. Anyway,
>> could it be the default behaviour of plotting masked arrays (single
>> pixel for an isolated element)?
>
> Gregorio,
>
> I don't think this would be a good idea.  It adds quite a bit of
> complexity for a special case--and inevitably, the next request from
> someone would be to have the option of using any marker for the isolated
> points.  The concept of "single pixel" gets slippery across backends and
> output devices.
>
> A better solution would be a simple function to identify such isolated
> points, for use when needed, to plot such points however you choose,
> typically with a separate call to "plot" specifying a marker.  This way,
> the extra complexity is called explicitly when needed, not carried along
> by every call to "plot".
>
> Eric
>
>>
>> 2013/7/17 Michael Droettboom <md...@st...>:
>>> You could use a single pixel for a marker (','), I guess.  But as you
>>> say, you need at least two points for a line segment.
>>>
>>> Mike
>>>
>>> On 07/17/2013 10:45 AM, Gregorio Bastardo wrote:
>>>> Hi,
>>>>
>>>> The following example demonstrates the problem, value 5 could not be
>>>> seen w/o marker:
>>>>
>>>> data = np.arange(10)
>>>> mask = [0,0,0,1,1,0,1,0,0,0]
>>>> x = np.ma.masked_array(data, mask)
>>>> plot(x)
>>>> plot(x, '+')
>>>>
>>>> In my datasets, isolated unmasked values are rare, but placing a
>>>> marker to spot them makes the whole graph cluttered. I do realize that
>>>> at least 2 valid points are needed for a line segment, but still, is
>>>> there any way to visualize these isolated unmasked values w/o a
>>>> marker?
>>>>
>>>> Thanks,
>>>> Gregorio
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi Brendan, Justin,
Thanks for your reply. I agree then that a .stop() method is needed. This is not very difficult; I'll try and implement it over the weekend.
Best,
-Michiel.




________________________________
 From: Brendan Barnwell <bre...@br...>
To: mat...@li... 
Sent: Friday, July 19, 2013 3:54 AM
Subject: Re: [Matplotlib-users] timer objects in macosx backend
 

On 2013-07-18 06:56, Justin Lazear wrote:> Hi Michiel,
>
> On my system, deleting the timer has no effect and the timer continues
> to send events. The __del__ method seems to call the same unimplemented
> _timer_stop method. Regardless, something else has a reference to the
> timer (MPL event loop maybe?) and __del__ is not being called once the
> timer has been started. It's not clear to me what should be 
stopping the
> timer in that case.
>
> Does del t stop the timer on your system? If so, could we hunt down 
what
> is happening after you delete the name t that is causing the timer 
to stop?
>
> I would personally prefer an explicit .stop() method, since I would
> prefer not to rely on the garbage collector's behavior being consistent
> (hard to make sure nothing else is holding a reference to timer) when
> there is a very well-defined function that does what I want.

    Relying on "del t" can't be the right solution, since like you note, 
it only deletes the name, not the object.  If you create multiple 
references to a timer and only del some of them, e.g.:

t = fig.canvas.new_timer()
x = t
del t

Then the object's __del__ will definitely not be called yet.  It makes 
sense to have a way to stop the timer directly, regardless of how many 
names are pointing to it.

-- 
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is 
no path, and leave a trail."
    --author unknown

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users