matplotlib-users Mailing List for matplotlib

2011/11/10 Michael Droettboom <md...@st...>:
> Can you get a traceback from gdb?  The following should do it:
>
>     gdb python2.6

For some reason I cannot load python2.6 from gdb:

This GDB was configured as "x86_64-apple-darwin"...Reading symbols for
shared libraries .. done

(gdb) run
Starting program:
/Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6
Reading symbols for shared libraries +. done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe01030 in __dyld__dyld_start ()
(gdb) The program is running.  Exit anyway? (y or n) y

This is the same as superuser.

I instead fell "back" to dtrace (``dapptrace -b 100m -U -p <pid>``,
which requires superuser privilegue, hence my note above).  dtrace is
a pretty decent tool to trace function calls etc. on the kernel level,
and ships with OS X 10.6.  I send the gzip'ed output attached to an
off-list mail, the full log is 4.8 MB even gzip'ed.  I found it by
first inspection useful to grep for ft2font.so and libfreetype.  Make
your own conclusions.  From what my naked eye can see, freetype itself
seems to be not the problem.  The last thing freetype appears to do is
to return from FT_GetSfnt_Name.

Friedrich

In article 
<132...@we...>,
 Michiel de Hoon <mjl...@ya...> 
 wrote:

> --- On Wed, 11/9/11, Russell E. Owen <ro...@uw...> 
> wrote:
> > There is no matplotlib binary for 64-bit Python yet because
> > I've not 
> > figured out how to build one successfully -- I get horrible
> > conflicts 
> > with Tcl/Tk.
> > 
> Would it be possible to release a matplotlib binary for 64-bit Python using 
> the MacOSX backend instead of tkagg?

It's not hard to build your own 64-bit matplotlib on 10.6 (and I assume 
the instructions are the same on 10.7, but perhaps not). The 
prerequisite libraries are already present. Just make sure you have the 
following installed:
- XCode with gcc 4.2 as the default compiler (one way to change the 
default is using a pair of symlinks in /usr/bin or /usr/local/bin -- one 
for gcc, one for g++)
- Python.org's 64-bit python installed and preferably running as the 
default.

Download and unpack the matplotlib source.
Edit setupext.py and change the entry for darwin to include those two 
directories: /usr/X11 and /usr/lib. 

Then copy setup.cfg.template to setup.cfg and edit setup.cfg to enable 
the backends you want. Be sure to disable TkAgg because it won't build 
properly.

Then build in the usual way:
python setup.py build
python setup.py install

I personally don't think the matplotlib project should serve such a 
product unless and until somebody has time to deal with the Tk linking 
issues, which apparently require editing some resulting libraries (more 
than I want to attempt). But that's just my opinion.

-- Russell

2011/11/10 Benjamin Root <ben...@ou...>:
> On Wednesday, November 9, 2011, Friedrich Romstedt
> <fri...@gm...> wrote:
>> ``git bisect`` finds "some" first bad commit, but due to the commits
>> in other branches after the first real bad commit it gets it a bit
>> wrong.  The binary search then skips too far.
>
> Friedrich, just curious.  Is your Git mpl repo a clean clone from
> github.com/matplotlib and *not* from astraw's experimental repo, right?  I
> haven't had issues with bisect before and so I wonder if somehow you might
> have rebased astraw's repo with mpl's repo, which could have introduced
> issues?

No issues like that, clean clone (although I forked it and then cloned that).

For the bisect, without further reading it'll be speculation.  I
guess, bisecting on the basis of branches is difficult, just imagine
you have merged in some branch.  Since you can specify only one "good"
commit as starting point, if the merge occured later, the whole other
branch would have to be considered for bisecting.  I guess that's not
what bisect does.

The machanism, as I imagine it, to make bisect not work, is like this:
The good commit is on branch A, bad commits are on branch B, and they
are intermangled in the time line.  So bisect might just hit always,
up to some point, the good commits, concluding that everything between
them is good too, what is wrong (because only those from A are good,
the B ones not).

Furthermore, Michael is right, while bisecting I didn't ``rm build/``
properly; I just did ``python2.6 setup.py clean``.  Later on I did
that properly, after I noticed that the offending commit reported by
bisect actually runs cleanly.  I then wrote a test script for ``git
bisect run`` that applies all those steps, so I couldn't keep
forgetting it any longer :-)

Friedrich

On Thu, Nov 10, 2011 at 11:14 AM, Joe Kington <jki...@wi...> wrote:

> <snip>
>
>> Although, this doesn't give me millisecond precision. Is there any way to
>> get ms precision via datetime module?
>>
>  <snip>
>
> Well, datetime objects, matplotlib's internal float dates, and numpy
> datetime64 objects all support microsecond resolution.
>

I260 ncnt = np.array([num2date(1 + time[j]/86400.0) for j in
range(len(time))])

I261 time[0]
O261 32643.785958051682

I262 ncnt[0]
O262 datetime.datetime(1, 1, 1, 9, 4, 3, 785958,
tzinfo=<matplotlib.dates._UTC object at 0x2da2610>)

int conversion for time[j] was eating my milliseconds. Now it is finely
returning the ms part.



>
> However matplotlib's locator rules can't handle microsecond or millisecond
> resolution. There aren't any locators for less than second resolution.
>
> Also, imshow sets the aspect of the plot to 1 by default, which is
> probably why you're having to set the extents manually. If you specify
> "aspect='auto'" in the imshow call you can avoid that step.  (However,
> strange things happen when the span of the extents drops below 100
> microseconds... I'm guessing something is being cast to float32's
> somewhere?)
>

plt.imshow(z.T, interpolation='nearest', aspect='auto', origin='lower',
extent=[xmin, xmax, 0, z.shape[1]])

I need to set both aspect and extent for my case, without the extend I
can't get the time axis placed.


>
>
> As a quick example to demonstrate using sub-second resolution (without a
> proper tick locator):
>
> import matplotlib.pyplot as plt
> import numpy as np
> import matplotlib.dates as mdates
> from datetime import datetime
>
>
> # Generate data...
> ny = 100
> nx = 100
> xmin, xmax = mdates.date2num([datetime(2011, 01, 01, microsecond=1),
>                               datetime(2011, 01, 01, microsecond=nx)])
> data = np.random.random((ny, nx)) - 0.5
>
> data = data.cumsum(axis=1)
>
> # Plot...
> fig, ax = plt.subplots()
> ax.imshow(data, aspect='auto', extent=[xmin, xmax, 0, ny])
> ax.xaxis_date()
>
> plt.show()
>
> At any rate, you can write a quick-and-dirty millisecond locator...  Give
> me a bit and I'll cobble one together. (It's turning out to be slightly
> more complex than I thought...)


I am fine seeing the ticks at second resolution. It might be overkill for
my plots to place millisecond ticks. It takes a while to render these
ticks.


>
>
>
> On Thu, Nov 10, 2011 at 10:06 AM, Gökhan Sever <gok...@gm...>wrote:
>
>> Thanks Joe,
>>
>> I forgot to convert my numeric time array into a form that mpl can
>> understand.
>>
>> I198 time
>> O198
>> array([ 32643.78595805,  32643.82032609,  32643.85445309, ...,
>>         32871.46535802,  32871.49946594,  32871.53384495])
>>
>> I199 ncnt
>> O199
>> array([0001-01-01 09:04:03+00:00, 0001-01-01 09:04:03+00:00,
>>        0001-01-01 09:04:03+00:00, ..., 0001-01-01 09:07:51+00:00,
>>        0001-01-01 09:07:51+00:00, 0001-01-01 09:07:51+00:00],
>> dtype=object)
>>
>> Although, this doesn't give me millisecond precision. Is there any way to
>> get ms precision via datetime module?
>> This is not a matter for plotting, since second precision is good enough
>> for eyes.
>>
>> Then setting extent properly and either calling ax.xaxis_date or calling
>> setters manually
>>
>> I196 xmin = mdates.date2num(ncnt[0])
>>
>> I197 xmax = mdates.date2num(ncnt[-1])
>>
>> plt.imshow(z.T, interpolation='nearest', aspect='auto', origin='lower',
>> extent=[xmin, xmax, 0, z.shape[1]])
>>
>> ax = plt.gca()
>> ax.xaxis.set_major_formatter(DateFormatter('%H:%M:%S'))
>> ax.xaxis.set_major_locator(SecondLocator(interval=30))
>> ax.xaxis.set_minor_locator(SecondLocator(interval=5))
>>
>> gives me better control over the major/minor ticks.
>>
>>
>> On Thu, Nov 10, 2011 at 8:15 AM, Joe Kington <jki...@wi...> wrote:
>>
>>> On Wed, Nov 9, 2011 at 11:45 PM, Gökhan Sever <gok...@gm...>wrote:
>>>
>>>> Hello,
>>>>
>>>> Is there any easy way to specify a time-axis using imshow to plot 2D
>>>> data?
>>>>
>>>>
>>> Sure, just call "ax.xaxis_date()" (or "yaxis_date", depending on which
>>> axis you want to represent a date).
>>>
>>> As a quick example:
>>>
>>> import matplotlib.pyplot as plt
>>> import matplotlib.dates as mdates
>>> import numpy as np
>>>
>>> # Generate data...
>>> ny = 100
>>> xmin, xmax = mdates.datestr2num(['01/01/2011', '11/10/2011'])
>>> data = np.random.random((ny, int(xmax-xmin)+1)) - 0.5
>>> data = data.cumsum(axis=1)
>>>
>>> # Plot...
>>> fig, ax = plt.subplots()
>>> ax.imshow(data, extent=[xmin, xmax, 0, ny])
>>> ax.xaxis_date()
>>> fig.autofmt_xdate()
>>>
>>> plt.show()
>>>
>>> Cheers,
>>> -Joe
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> RSA(R) Conference 2012
>>> Save $700 by Nov 18
>>> Register now
>>> http://p.sf.net/sfu/rsa-sfdev2dev1
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>
>>
>> --
>> Gökhan
>>
>
>


-- 
Gökhan

<snip>

> Although, this doesn't give me millisecond precision. Is there any way to
> get ms precision via datetime module?
>
 <snip>

Well, datetime objects, matplotlib's internal float dates, and numpy
datetime64 objects all support microsecond resolution.

However matplotlib's locator rules can't handle microsecond or millisecond
resolution. There aren't any locators for less than second resolution.

Also, imshow sets the aspect of the plot to 1 by default, which is probably
why you're having to set the extents manually. If you specify
"aspect='auto'" in the imshow call you can avoid that step.  (However,
strange things happen when the span of the extents drops below 100
microseconds... I'm guessing something is being cast to float32's
somewhere?)


As a quick example to demonstrate using sub-second resolution (without a
proper tick locator):

import matplotlib.pyplot as plt
import numpy as np
import matplotlib.dates as mdates
from datetime import datetime

# Generate data...
ny = 100
nx = 100
xmin, xmax = mdates.date2num([datetime(2011, 01, 01, microsecond=1),
                              datetime(2011, 01, 01, microsecond=nx)])
data = np.random.random((ny, nx)) - 0.5
data = data.cumsum(axis=1)

# Plot...
fig, ax = plt.subplots()
ax.imshow(data, aspect='auto', extent=[xmin, xmax, 0, ny])
ax.xaxis_date()

plt.show()

At any rate, you can write a quick-and-dirty millisecond locator...  Give
me a bit and I'll cobble one together. (It's turning out to be slightly
more complex than I thought...)


On Thu, Nov 10, 2011 at 10:06 AM, Gökhan Sever <gok...@gm...>wrote:

> Thanks Joe,
>
> I forgot to convert my numeric time array into a form that mpl can
> understand.
>
> I198 time
> O198
> array([ 32643.78595805,  32643.82032609,  32643.85445309, ...,
>         32871.46535802,  32871.49946594,  32871.53384495])
>
> I199 ncnt
> O199
> array([0001-01-01 09:04:03+00:00, 0001-01-01 09:04:03+00:00,
>        0001-01-01 09:04:03+00:00, ..., 0001-01-01 09:07:51+00:00,
>        0001-01-01 09:07:51+00:00, 0001-01-01 09:07:51+00:00], dtype=object)
>
> Although, this doesn't give me millisecond precision. Is there any way to
> get ms precision via datetime module?
> This is not a matter for plotting, since second precision is good enough
> for eyes.
>
> Then setting extent properly and either calling ax.xaxis_date or calling
> setters manually
>
> I196 xmin = mdates.date2num(ncnt[0])
>
> I197 xmax = mdates.date2num(ncnt[-1])
>
> plt.imshow(z.T, interpolation='nearest', aspect='auto', origin='lower',
> extent=[xmin, xmax, 0, z.shape[1]])
>
> ax = plt.gca()
> ax.xaxis.set_major_formatter(DateFormatter('%H:%M:%S'))
> ax.xaxis.set_major_locator(SecondLocator(interval=30))
> ax.xaxis.set_minor_locator(SecondLocator(interval=5))
>
> gives me better control over the major/minor ticks.
>
>
> On Thu, Nov 10, 2011 at 8:15 AM, Joe Kington <jki...@wi...> wrote:
>
>> On Wed, Nov 9, 2011 at 11:45 PM, Gökhan Sever <gok...@gm...>wrote:
>>
>>> Hello,
>>>
>>> Is there any easy way to specify a time-axis using imshow to plot 2D
>>> data?
>>>
>>>
>> Sure, just call "ax.xaxis_date()" (or "yaxis_date", depending on which
>> axis you want to represent a date).
>>
>> As a quick example:
>>
>> import matplotlib.pyplot as plt
>> import matplotlib.dates as mdates
>> import numpy as np
>>
>> # Generate data...
>> ny = 100
>> xmin, xmax = mdates.datestr2num(['01/01/2011', '11/10/2011'])
>> data = np.random.random((ny, int(xmax-xmin)+1)) - 0.5
>> data = data.cumsum(axis=1)
>>
>> # Plot...
>> fig, ax = plt.subplots()
>> ax.imshow(data, extent=[xmin, xmax, 0, ny])
>> ax.xaxis_date()
>> fig.autofmt_xdate()
>>
>> plt.show()
>>
>> Cheers,
>> -Joe
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
>
> --
> Gökhan
>

Hello, 

I am installing matplotlib on Snow Leopard 10.6.  I downloaded v1.1.0 from the sourceforge site and installed in this manner:

############################

$ export CFLAGS="-arch i386 -arch x86_64 -I/usr/X11/include -I/usr/X11/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk"
$ export LDFLAGS="-Wall -undefined dynamic_lookup -bundle -arch i386 -arch x86_64 -L/usr/X11/lib -syslibroot,/Developer/SDKs/MacOSX10.6.sdk"
$ export FFLAGS="-arch i386 -arch x86_64"
$ tar -xf matplotlib-1.1.0.tar.gz
$ cd matplotlib-1.1.0
$ python setup.py build
$ python setup.py install
$
$ python
>>> import matplotlib as mpl
>>> mpl.test("1")
...........EEEEEEEEEEE
======================================================================
ERROR: Failure: AttributeError ('module' object has no attribute 'test_backend_svg')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/private/tmp/test/lib/python2.6/site-packages/nose/loader.py", line 379, in loadTestsFromName
    module = resolve_name(addr.module)
  File "/private/tmp/test/lib/python2.6/site-packages/nose/util.py", line 331, in resolve_name
    obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_backend_svg'

(etc.)
#############################

The failure is for all modules in matplotlib.tests except for test_agg, test_cbook, test_mlab, and test_transform.

Is the sourceforge achive incomplete?

-Dave

--
David Welch
dav...@gm...

I'm doing data_files += matplotlib.get_py2exe_datafiles().

By the way, the plot I'm trying to do is in log scale, so it is using
superscripts (when I was searching the lists for an answer I saw some posts
mentioning this had caused problems).

Oh, and I'm using options={'py2exe':{'bundle_files':1, 'optimize':1}}.

Python 2.5.4 and matplotlib 1.0.0.

On Thu, Nov 10, 2011 at 5:03 PM, Michael Droettboom <md...@st...> wrote:

>
> Did you include the fonts as described here?
>
> http://www.py2exe.org/index.cgi/MatPlotLib
>
> Mike
>
>
> On 11/10/2011 08:03 AM, Armando Serrano Lombillo wrote:
>
> Hello, I'm having a weird problem with matplotlib not finding fonts when
> being used from a py2exe packed program. The weird thing is that the
> program works fine on some computers, gives an annoying warning in others
> (but otherwise keeps working and plots things ok) or gives an error (and no
> plot is produced) in others.
>
> A strange thing I noticed is that I'm using python 2.5 and one of the
> warnings is referring to python 2.6, so somehow it must be confusing itself
> with a python version installed in that computer.
>
> Can somebody help?
>
> Thanks,
> Armando.
>
> Warning it gives on some computers:
>
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['STIXGeneral'] not found. Falling back
> to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252:
> UserWarning: findfont: Could not match :family=Bitstream Vera
> Sans:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
> Returning C:\Windows\Fonts\cour.ttf
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['STIXNonUnicode'] not found. Falling
> back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252:
> UserWarning: findfont: Could not match :family=Bitstream Vera
> Sans:style=normal:variant=normal:weight=bold:stretch=normal:size=12.0.
> Returning C:\Windows\Fonts\cour.ttf
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['STIXSizeThreeSym'] not found. Falling
> back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['STIXSizeFourSym'] not found. Falling
> back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['STIXSizeFiveSym'] not found. Falling
> back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['STIXSizeOneSym'] not found. Falling
> back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['STIXSizeTwoSym'] not found. Falling
> back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252:
> UserWarning: findfont: Could not match :family=Bitstream Vera
> Sans:style=italic:variant=normal:weight=normal:stretch=normal:size=12.0.
> Returning C:\Windows\Fonts\cour.ttf
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['cmb10'] not found. Falling back to
> Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['cmtt10'] not found. Falling back to
> Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['cmmi10'] not found. Falling back to
> Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['cmex10'] not found. Falling back to
> Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['cmsy10'] not found. Falling back to
> Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['cmr10'] not found. Falling back to
> Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
> UserWarning: findfont: Font family ['cmss10'] not found. Falling back to
> Bitstream Vera Sans
>
> Error it gives in another computer:
>
> Traceback (most recent call last):
>   File "gui.pyw", line 489, in parejas_fN
>   File "postproceso.pyo", line 714, in __init__
>   File "matplotlib\backends\backend_wxagg.pyo", line 59, in draw
>   File "matplotlib\backends\backend_agg.pyo", line 394, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\figure.pyo", line 798, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\axes.pyo", line 1934, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\axis.pyo", line 1017, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\axis.pyo", line 234, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\text.pyo", line 524, in draw
>   File "matplotlib\text.pyo", line 298, in _get_layout
>   File "matplotlib\backends\backend_agg.pyo", line 180, in
> get_text_width_height_descent
>   File "matplotlib\backends\backend_agg.pyo", line 221, in _get_agg_font
> RuntimeError: Could not open facefile
> C:\Python26\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf;
> Cannot_Open_Resource
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register nowhttp://p.sf.net/sfu/rsa-sfdev2dev1
>
>
>
> _______________________________________________
> Matplotlib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Thanks Joe,

I forgot to convert my numeric time array into a form that mpl can
understand.

I198 time
O198
array([ 32643.78595805,  32643.82032609,  32643.85445309, ...,
        32871.46535802,  32871.49946594,  32871.53384495])

I199 ncnt
O199
array([0001-01-01 09:04:03+00:00, 0001-01-01 09:04:03+00:00,
       0001-01-01 09:04:03+00:00, ..., 0001-01-01 09:07:51+00:00,
       0001-01-01 09:07:51+00:00, 0001-01-01 09:07:51+00:00], dtype=object)

Although, this doesn't give me millisecond precision. Is there any way to
get ms precision via datetime module?
This is not a matter for plotting, since second precision is good enough
for eyes.

Then setting extent properly and either calling ax.xaxis_date or calling
setters manually

I196 xmin = mdates.date2num(ncnt[0])

I197 xmax = mdates.date2num(ncnt[-1])

plt.imshow(z.T, interpolation='nearest', aspect='auto', origin='lower',
extent=[xmin, xmax, 0, z.shape[1]])

ax = plt.gca()
ax.xaxis.set_major_formatter(DateFormatter('%H:%M:%S'))
ax.xaxis.set_major_locator(SecondLocator(interval=30))
ax.xaxis.set_minor_locator(SecondLocator(interval=5))

gives me better control over the major/minor ticks.


On Thu, Nov 10, 2011 at 8:15 AM, Joe Kington <jki...@wi...> wrote:

> On Wed, Nov 9, 2011 at 11:45 PM, Gökhan Sever <gok...@gm...>wrote:
>
>> Hello,
>>
>> Is there any easy way to specify a time-axis using imshow to plot 2D data?
>>
>>
> Sure, just call "ax.xaxis_date()" (or "yaxis_date", depending on which
> axis you want to represent a date).
>
> As a quick example:
>
> import matplotlib.pyplot as plt
> import matplotlib.dates as mdates
> import numpy as np
>
> # Generate data...
> ny = 100
> xmin, xmax = mdates.datestr2num(['01/01/2011', '11/10/2011'])
> data = np.random.random((ny, int(xmax-xmin)+1)) - 0.5
> data = data.cumsum(axis=1)
>
> # Plot...
> fig, ax = plt.subplots()
> ax.imshow(data, extent=[xmin, xmax, 0, ny])
> ax.xaxis_date()
> fig.autofmt_xdate()
>
> plt.show()
>
> Cheers,
> -Joe
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>


-- 
Gökhan

Did you include the fonts as described here?

http://www.py2exe.org/index.cgi/MatPlotLib

Mike

On 11/10/2011 08:03 AM, Armando Serrano Lombillo wrote:
> Hello, I'm having a weird problem with matplotlib not finding fonts 
> when being used from a py2exe packed program. The weird thing is that 
> the program works fine on some computers, gives an annoying warning in 
> others (but otherwise keeps working and plots things ok) or gives an 
> error (and no plot is produced) in others.
>
> A strange thing I noticed is that I'm using python 2.5 and one of the 
> warnings is referring to python 2.6, so somehow it must be confusing 
> itself with a python version installed in that computer.
>
> Can somebody help?
>
> Thanks,
> Armando.
>
> Warning it gives on some computers:
>
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['STIXGeneral'] not found. Falling 
> back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252: 
> UserWarning: findfont: Could not match :family=Bitstream Vera 
> Sans:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0. 
> Returning C:\Windows\Fonts\cour.ttf
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['STIXNonUnicode'] not found. 
> Falling back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252: 
> UserWarning: findfont: Could not match :family=Bitstream Vera 
> Sans:style=normal:variant=normal:weight=bold:stretch=normal:size=12.0. 
> Returning C:\Windows\Fonts\cour.ttf
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['STIXSizeThreeSym'] not found. 
> Falling back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['STIXSizeFourSym'] not found. 
> Falling back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['STIXSizeFiveSym'] not found. 
> Falling back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['STIXSizeOneSym'] not found. 
> Falling back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['STIXSizeTwoSym'] not found. 
> Falling back to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252: 
> UserWarning: findfont: Could not match :family=Bitstream Vera 
> Sans:style=italic:variant=normal:weight=normal:stretch=normal:size=12.0. 
> Returning C:\Windows\Fonts\cour.ttf
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['cmb10'] not found. Falling back 
> to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['cmtt10'] not found. Falling back 
> to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['cmmi10'] not found. Falling back 
> to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['cmex10'] not found. Falling back 
> to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['cmsy10'] not found. Falling back 
> to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['cmr10'] not found. Falling back 
> to Bitstream Vera Sans
> C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242: 
> UserWarning: findfont: Font family ['cmss10'] not found. Falling back 
> to Bitstream Vera Sans
>
> Error it gives in another computer:
>
> Traceback (most recent call last):
>   File "gui.pyw", line 489, in parejas_fN
>   File "postproceso.pyo", line 714, in __init__
>   File "matplotlib\backends\backend_wxagg.pyo", line 59, in draw
>   File "matplotlib\backends\backend_agg.pyo", line 394, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\figure.pyo", line 798, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\axes.pyo", line 1934, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\axis.pyo", line 1017, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\axis.pyo", line 234, in draw
>   File "matplotlib\artist.pyo", line 55, in draw_wrapper
>   File "matplotlib\text.pyo", line 524, in draw
>   File "matplotlib\text.pyo", line 298, in _get_layout
>   File "matplotlib\backends\backend_agg.pyo", line 180, in 
> get_text_width_height_descent
>   File "matplotlib\backends\backend_agg.pyo", line 221, in _get_agg_font
> RuntimeError: Could not open facefile 
> C:\Python26\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf; 
> Cannot_Open_Resource
>
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Can you get a traceback from gdb?  The following should do it:

     gdb python2.6

at the gdb prompt, type "run", then at the Python prompt, reproduce the 
error using "import matplotlib.figure".  It should crash, then type "bt" 
to get a traceback.  That may illustrate the source of the error.

Also of note, when using bisect -- the distutils build doesn't always 
rebuild enough if only header files change.  I recommend clearing out 
the build directory before each compile when using bisect to track down 
a C++-related change.

Mike

On 11/09/2011 10:44 PM, Friedrich Romstedt wrote:
> Hi,
>
> as announced on the devel list here my report on "my" Bus error.
>
> I first noticed the Bus error with a freshly compiled version from
> today's git.  A ``import matplotlib.figure`` was sufficient to produce
> the bus error.  ``python2.6 -v`` showed that it appears when
> matplotlib.ft2font is imported, dynamically loaded from
> matplotlib/ft2font.so.
>
> I don't know much about this C++ stuff (ft2font.cpp), but I did a
> bisect.  Unfortunately, it seems (to me) that bisect acts on the
> timeline, not respecting the branch structure, hence it gets it a bit
> wrong, at least not right enough to enable me to find the offending
> commit.
>
> ``git bisect`` finds "some" first bad commit, but due to the commits
> in other branches after the first real bad commit it gets it a bit
> wrong.  The binary search then skips too far.
>
> Nevertheless, I found that e05c2fa32f0fc31 fails, its parent cb609d5
> fails too.  The very first ancestor of this tree in 2011 I can find is
> 05631088 (2011-02-20): That one succeeds.  But it has some nonstandard
> setupext.py.  So my test script for ``git bisect run`` cannot be
> applied.  Its only child is df25e31309b, with a standard setupext.py:
> It succeeds.
>
> git bisect seems to work on the full timeline, so it's useless here.
> Manual bisecting (using gitk on cb609d5415e): 9a93a5c4 (2011-02-24)
> fails; 2ab8582f (2011-02-21) fails; df25e3130 (2011-02-20, the merge
> of 0.98 into 0.99) succeeds (see above).  13894992 (2011-02-20, the
> merge of 0.99 into 1.0) fails.
>
> So I conclude the failure is introduced somewhere in the 0.99 branch.
>
> Compiling randomly while searching the history: e38440f2 (2010-08-18) fails.
>
> A git blame _src/ft2font.cpp shows that most lines are due to Michael
> Droettboom in 6b643862.  Unfortunately this is just "Standardizing
> formatting of C/C++ code."
>
> The 1.0.0 release 668a769fb fails.
>
> Finally testing the 6b643862 ("Standardizing formatting [...]",
> 2010-06-24): fails
>
> The next one with modifications to ft2font.cpp is b5ce84214f2
> (2010-06-10): fails, its predecessor 97b98e33c: fails.
>
> Next with modifications to ft2font.cpp is 7c228264e (2010-06-04):
> fails, its predecessor e8f143c78: fails.
>
> Next one is 857adaee2 (2010-04-16): fails, its predecessor 5a9d580b81: fails.
>
> There is no other modification to ft2font.cpp apparently in 2010 on this branch.
>
> Btw, python2.6-32 signals "Bus error", while python-64 exits with
> "Abort trap".  The Python is self-compiled Python 2.6:
>
> Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
> [GCC 4.2.1 (Apple Inc. build 5659)] on darwin
>
> I'm building by patching setupext.py to include /usr/local/.
>
> Can anyone maybe provide with a pointer what I should try to sort this
> out, aside of updating my freetype2 (what shouldn't count as a
> solution, it should just work also with not fully-recent freetype2).
> I'm not sure if I'm doing something stupid wrong, but since it
> succeeds before the 0.99 branch is merged in I suspect something
> non-trivial.
>
> I wonder why I did not notice this before on my machine.  Admittedly,
> I did not compile in 2011 at all, I think.  But in Autumn 2010, I did,
> and with success.  So I wonder how this error was making its way
> around my machine?  I remember that the git mirror of the svn was no
> longer maintained the time I last worked on matplotlib.
>
> Friedrich
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Wed, Nov 9, 2011 at 11:45 PM, Gökhan Sever <gok...@gm...> wrote:

> Hello,
>
> Is there any easy way to specify a time-axis using imshow to plot 2D data?
>
>
Sure, just call "ax.xaxis_date()" (or "yaxis_date", depending on which axis
you want to represent a date).

As a quick example:

import matplotlib.pyplot as plt
import matplotlib.dates as mdates
import numpy as np

# Generate data...
ny = 100
xmin, xmax = mdates.datestr2num(['01/01/2011', '11/10/2011'])
data = np.random.random((ny, int(xmax-xmin)+1)) - 0.5
data = data.cumsum(axis=1)

# Plot...
fig, ax = plt.subplots()
ax.imshow(data, extent=[xmin, xmax, 0, ny])
ax.xaxis_date()
fig.autofmt_xdate()

plt.show()

Cheers,
-Joe

Hello, I'm having a weird problem with matplotlib not finding fonts when
being used from a py2exe packed program. The weird thing is that the
program works fine on some computers, gives an annoying warning in others
(but otherwise keeps working and plots things ok) or gives an error (and no
plot is produced) in others.

A strange thing I noticed is that I'm using python 2.5 and one of the
warnings is referring to python 2.6, so somehow it must be confusing itself
with a python version installed in that computer.

Can somebody help?

Thanks,
Armando.

Warning it gives on some computers:

C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['STIXGeneral'] not found. Falling back
to Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=normal:variant=normal:weight=normal:stretch=normal:size=12.0.
Returning C:\Windows\Fonts\cour.ttf
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['STIXNonUnicode'] not found. Falling
back to Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=normal:variant=normal:weight=bold:stretch=normal:size=12.0.
Returning C:\Windows\Fonts\cour.ttf
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['STIXSizeThreeSym'] not found. Falling
back to Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['STIXSizeFourSym'] not found. Falling
back to Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['STIXSizeFiveSym'] not found. Falling
back to Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['STIXSizeOneSym'] not found. Falling
back to Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['STIXSizeTwoSym'] not found. Falling
back to Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1252:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=italic:variant=normal:weight=normal:stretch=normal:size=12.0.
Returning C:\Windows\Fonts\cour.ttf
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['cmb10'] not found. Falling back to
Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['cmtt10'] not found. Falling back to
Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['cmmi10'] not found. Falling back to
Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['cmex10'] not found. Falling back to
Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['cmsy10'] not found. Falling back to
Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['cmr10'] not found. Falling back to
Bitstream Vera Sans
C:\Program Files\myprogram\gui.exe\matplotlib\font_manager.py:1242:
UserWarning: findfont: Font family ['cmss10'] not found. Falling back to
Bitstream Vera Sans

Error it gives in another computer:

Traceback (most recent call last):
  File "gui.pyw", line 489, in parejas_fN
  File "postproceso.pyo", line 714, in __init__
  File "matplotlib\backends\backend_wxagg.pyo", line 59, in draw
  File "matplotlib\backends\backend_agg.pyo", line 394, in draw
  File "matplotlib\artist.pyo", line 55, in draw_wrapper
  File "matplotlib\figure.pyo", line 798, in draw
  File "matplotlib\artist.pyo", line 55, in draw_wrapper
  File "matplotlib\axes.pyo", line 1934, in draw
  File "matplotlib\artist.pyo", line 55, in draw_wrapper
  File "matplotlib\axis.pyo", line 1017, in draw
  File "matplotlib\artist.pyo", line 55, in draw_wrapper
  File "matplotlib\axis.pyo", line 234, in draw
  File "matplotlib\artist.pyo", line 55, in draw_wrapper
  File "matplotlib\text.pyo", line 524, in draw
  File "matplotlib\text.pyo", line 298, in _get_layout
  File "matplotlib\backends\backend_agg.pyo", line 180, in
get_text_width_height_descent
  File "matplotlib\backends\backend_agg.pyo", line 221, in _get_agg_font
RuntimeError: Could not open facefile
C:\Python26\lib\site-packages\matplotlib\mpl-data\fonts\ttf\Vera.ttf;
Cannot_Open_Resource

Elmar,
Please let me know if you have any comments or suggestions on the 
ternary projection.  I hope that it's not too far from being worthy to 
pull into matplotlib.  (I'd need to merge the branch with the latest 
development version of matplotlib.)

Thanks,
Kevin


On 11/04/2011 07:11 AM, Elmar Werling wrote:
> On 03.11.2011 22:28, Joe Kington wrote:
>> The link on Nabble is broken, so here's (I think) a fixed version. It
>> looks like the name of the branch was changed slightly at some point.
>>
>> https://github.com/kdavies4/matplotlib/compare/master...ternary2
>>
>> Cheers,
>> -Joe
>>
>>
>>
>> On Thu, Nov 3, 2011 at 3:14 PM, Benjamin Root
>> <ben...@ou...
>> <mailto:ben...@ou...>>  wrote:
>>
>>
>>
>>      On Thu, Nov 3, 2011 at 2:58 PM, elmar werling
>>      <el...@ne...
>>      <mailto:el...@ne...>>  wrote:
>>
>>          Hi,
>>
>>          could not found anything like plot_ternary() in the matplotlib
>>          documentation. Is there an easy to use method to plot data
>>          points and
>>          lines in a ternary plot using matplotlib?
>>
>>          Any hint is wellcome
>>
>>          Elmar
>>
>>
>>      This is a requested feature, but has not been implemented yet within
>>      matplotlib.  However, some other users have created a hack to do this:
>>
>>      http://old.nabble.com/Ternary-or-triangle-plots-td32506324.html
>>
>>      Ben Root
>>
>>
>>      ------------------------------------------------------------------------------
>>      RSA(R) Conference 2012
>>      Save $700 by Nov 18
>>      Register now
>>      http://p.sf.net/sfu/rsa-sfdev2dev1
>>
>>      _______________________________________________
>>      Matplotlib-users mailing list
>>      Mat...@li...
>>      <mailto:Mat...@li...>
>>      https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>>
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> thanks - hope it will help
> elmar
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi Bedartha and others,  

I have matplotlib 1.1.0 running fine on Mac OS X Lion with TkAgg, Qt4Agg, MacOSX and mplh5canvas ;-) backends in good working condition. My humble opinion is that this works because I do not try to replace System Python with my own version. Given that Lion ships with Python 2.7.1, I do not feel the need to upgrade it to Python.org's 2.7.2 and potentially endure these kinds of installation woes. My current installation instructions for NumPy / SciPy / matplotlib / IPython on Lion ("current" because this is quite a moving target!) can be condensed as follows:

- use homebrew as far as possible (but don't use it to install Python, doh!)
- brew install pkg-config gfortran zeromq pyqt (follow homebrew instructions for PYTHONPATH settings for pyqt dependencies)
- use the System NumPy 1.5.1 - it's good enough for my purposes
- build git version of SciPy using gcc-4.2 - unfortunately still a (slight) pain until next stable release
- sudo easy_install readline nose pyzmq Pygments ipython matplotlib

The detailed instructions are available upon request…

Once you have pkg-config installed via homebrew or otherwise, you can literally just easy_install matplotlib! (Thanks to JDH for recently updating the PyPI repository)

Regards,
Ludwig


On Thursday 10 November 2011 at 5:44 AM, mat...@li... wrote:

> Message: 2
> Date: Wed, 09 Nov 2011 11:22:42 -0800
> From: "Russell E. Owen" <ro...@uw... (mailto:ro...@uw...)>
> Subject: Re: [Matplotlib-users] Matplotlib "show()" error Mac OS X
> Lion
> To: mat...@li... (mailto:mat...@li...)
> Message-ID: <row...@ne... (mailto:row...@ne...)>
>  
> In article <629...@pi... (mailto:629...@pi...)>,
> Bedartha Goswami <go...@pi... (mailto:go...@pi...)>
> wrote:
>  
> > Hi,
> >  
> > I have recently installed Python 32/64bit from Python.org (http://Python.org) and then I
> > proceeded to install bumpy, scipy, matplotlib and igraph on it. But the
> > Matplotlib does not show the plots even if it opens a Figure window. Here is
> > a summary of what I had done in my installation:
> > -----
> > I first did a "clean install" by following the instructions at (with an idea
> > to reinstall Matplotlib and see if the rror repeats):
> > http://matplotlib.sourceforge.net/faq/installing_faq.html#clean-install
> > -----
> > So now my python does not have matplotlib:
> >  
> > Bedarthas-MacBook-Air:~ bedartha$ cd ~/Desktop/
> > Bedarthas-MacBook-Air:Desktop bedartha$ python
> > Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34)
> > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> > Type "help", "copyright", "credits" or "license" for more information.
> > > > > import matplotlib
> > > >  
> > >  
> >  
> > Traceback (most recent call last):
> > File "<stdin>", line 1, in <module>
> > ImportError: No module named matplotlib
> > > > >  
> > > >  
> > >  
> >  
> > Bedarthas-MacBook-Air:Desktop bedartha$
> > -----
> > Then I downloaded (again) the DMG file at:
> > http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/m
> > atplotlib-1.1.0-py2.7-python.org-macosx10.3.dmg/download
> > -----
> > and installed Matplotlib (which seems to go through fine). But after that:
> >  
> > Bedarthas-MacBook-Air:~ bedartha$ cd ~/Desktop/
> > Bedarthas-MacBook-Air:Desktop bedartha$ python
> > Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34)
> > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> >  
>  
>  
> I suspect you are trying to install matplotlib on the 64-bit Python
> instead of the 32-bit python for which it was built
>  
> I say this because 32-bit python is built using GCC 4.0.1.
>  
> There is no matplotlib binary for 64-bit Python yet because I've not
> figured out how to build one successfully -- I get horrible conflicts
> with Tcl/Tk.
>  
> -- Russell

Hello,

Is there any easy way to specify a time-axis using imshow to plot 2D data?

Thanks.

-- 
Gökhan

Hi, 

Could someone tell me how to set the thickness of the frame surrounding a
figure? I suppose this is the axis.spines object but I can't figure out how
to use the "lindewidth" property.

Thanks!

Pawel
-- 
View this message in context: http://old.nabble.com/set-thickness-of-axis-spine-tp32816281p32816281.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Wednesday, November 9, 2011, Friedrich Romstedt <
fri...@gm...> wrote:
> Hi,
>
> as announced on the devel list here my report on "my" Bus error.
>
> I first noticed the Bus error with a freshly compiled version from
> today's git.  A ``import matplotlib.figure`` was sufficient to produce
> the bus error.  ``python2.6 -v`` showed that it appears when
> matplotlib.ft2font is imported, dynamically loaded from
> matplotlib/ft2font.so.
>
> I don't know much about this C++ stuff (ft2font.cpp), but I did a
> bisect.  Unfortunately, it seems (to me) that bisect acts on the
> timeline, not respecting the branch structure, hence it gets it a bit
> wrong, at least not right enough to enable me to find the offending
> commit.
>
> ``git bisect`` finds "some" first bad commit, but due to the commits
> in other branches after the first real bad commit it gets it a bit
> wrong.  The binary search then skips too far.
>
> Nevertheless, I found that e05c2fa32f0fc31 fails, its parent cb609d5
> fails too.  The very first ancestor of this tree in 2011 I can find is
> 05631088 (2011-02-20): That one succeeds.  But it has some nonstandard
> setupext.py.  So my test script for ``git bisect run`` cannot be
> applied.  Its only child is df25e31309b, with a standard setupext.py:
> It succeeds.
>
> git bisect seems to work on the full timeline, so it's useless here.
> Manual bisecting (using gitk on cb609d5415e): 9a93a5c4 (2011-02-24)
> fails; 2ab8582f (2011-02-21) fails; df25e3130 (2011-02-20, the merge
> of 0.98 into 0.99) succeeds (see above).  13894992 (2011-02-20, the
> merge of 0.99 into 1.0) fails.
>
> So I conclude the failure is introduced somewhere in the 0.99 branch.
>
> Compiling randomly while searching the history: e38440f2 (2010-08-18)
fails.
>
> A git blame _src/ft2font.cpp shows that most lines are due to Michael
> Droettboom in 6b643862.  Unfortunately this is just "Standardizing
> formatting of C/C++ code."
>
> The 1.0.0 release 668a769fb fails.
>
> Finally testing the 6b643862 ("Standardizing formatting [...]",
> 2010-06-24): fails
>
> The next one with modifications to ft2font.cpp is b5ce84214f2
> (2010-06-10): fails, its predecessor 97b98e33c: fails.
>
> Next with modifications to ft2font.cpp is 7c228264e (2010-06-04):
> fails, its predecessor e8f143c78: fails.
>
> Next one is 857adaee2 (2010-04-16): fails, its predecessor 5a9d580b81:
fails.
>
> There is no other modification to ft2font.cpp apparently in 2010 on this
branch.
>
> Btw, python2.6-32 signals "Bus error", while python-64 exits with
> "Abort trap".  The Python is self-compiled Python 2.6:
>
> Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
> [GCC 4.2.1 (Apple Inc. build 5659)] on darwin
>
> I'm building by patching setupext.py to include /usr/local/.
>
> Can anyone maybe provide with a pointer what I should try to sort this
> out, aside of updating my freetype2 (what shouldn't count as a
> solution, it should just work also with not fully-recent freetype2).
> I'm not sure if I'm doing something stupid wrong, but since it
> succeeds before the 0.99 branch is merged in I suspect something
> non-trivial.
>
> I wonder why I did not notice this before on my machine.  Admittedly,
> I did not compile in 2011 at all, I think.  But in Autumn 2010, I did,
> and with success.  So I wonder how this error was making its way
> around my machine?  I remember that the git mirror of the svn was no
> longer maintained the time I last worked on matplotlib.
>
> Friedrich
>

Friedrich, just curious.  Is your Git mpl repo a clean clone from
github.com/matplotlib and *not* from astraw's experimental repo, right?  I
haven't had issues with bisect before and so I wonder if somehow you might
have rebased astraw's repo with mpl's repo, which could have introduced
issues?

Just speculating out loud.

Ben Root

Hi,

as announced on the devel list here my report on "my" Bus error.

I first noticed the Bus error with a freshly compiled version from
today's git.  A ``import matplotlib.figure`` was sufficient to produce
the bus error.  ``python2.6 -v`` showed that it appears when
matplotlib.ft2font is imported, dynamically loaded from
matplotlib/ft2font.so.

I don't know much about this C++ stuff (ft2font.cpp), but I did a
bisect.  Unfortunately, it seems (to me) that bisect acts on the
timeline, not respecting the branch structure, hence it gets it a bit
wrong, at least not right enough to enable me to find the offending
commit.

``git bisect`` finds "some" first bad commit, but due to the commits
in other branches after the first real bad commit it gets it a bit
wrong.  The binary search then skips too far.

Nevertheless, I found that e05c2fa32f0fc31 fails, its parent cb609d5
fails too.  The very first ancestor of this tree in 2011 I can find is
05631088 (2011-02-20): That one succeeds.  But it has some nonstandard
setupext.py.  So my test script for ``git bisect run`` cannot be
applied.  Its only child is df25e31309b, with a standard setupext.py:
It succeeds.

git bisect seems to work on the full timeline, so it's useless here.
Manual bisecting (using gitk on cb609d5415e): 9a93a5c4 (2011-02-24)
fails; 2ab8582f (2011-02-21) fails; df25e3130 (2011-02-20, the merge
of 0.98 into 0.99) succeeds (see above).  13894992 (2011-02-20, the
merge of 0.99 into 1.0) fails.

So I conclude the failure is introduced somewhere in the 0.99 branch.

Compiling randomly while searching the history: e38440f2 (2010-08-18) fails.

A git blame _src/ft2font.cpp shows that most lines are due to Michael
Droettboom in 6b643862.  Unfortunately this is just "Standardizing
formatting of C/C++ code."

The 1.0.0 release 668a769fb fails.

Finally testing the 6b643862 ("Standardizing formatting [...]",
2010-06-24): fails

The next one with modifications to ft2font.cpp is b5ce84214f2
(2010-06-10): fails, its predecessor 97b98e33c: fails.

Next with modifications to ft2font.cpp is 7c228264e (2010-06-04):
fails, its predecessor e8f143c78: fails.

Next one is 857adaee2 (2010-04-16): fails, its predecessor 5a9d580b81: fails.

There is no other modification to ft2font.cpp apparently in 2010 on this branch.

Btw, python2.6-32 signals "Bus error", while python-64 exits with
"Abort trap".  The Python is self-compiled Python 2.6:

Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin

I'm building by patching setupext.py to include /usr/local/.

Can anyone maybe provide with a pointer what I should try to sort this
out, aside of updating my freetype2 (what shouldn't count as a
solution, it should just work also with not fully-recent freetype2).
I'm not sure if I'm doing something stupid wrong, but since it
succeeds before the 0.99 branch is merged in I suspect something
non-trivial.

I wonder why I did not notice this before on my machine.  Admittedly,
I did not compile in 2011 at all, I think.  But in Autumn 2010, I did,
and with success.  So I wonder how this error was making its way
around my machine?  I remember that the git mirror of the svn was no
longer maintained the time I last worked on matplotlib.

Friedrich

--- On Wed, 11/9/11, Russell E. Owen <ro...@uw...> wrote:
> There is no matplotlib binary for 64-bit Python yet because
> I've not 
> figured out how to build one successfully -- I get horrible
> conflicts 
> with Tcl/Tk.
> 
Would it be possible to release a matplotlib binary for 64-bit Python using the MacOSX backend instead of tkagg?

Best,
-Michiel.