You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(6) |
2
(29) |
3
(19) |
4
(6) |
5
(5) |
6
(9) |
7
(9) |
8
(19) |
9
(14) |
10
(19) |
11
(26) |
12
(10) |
13
(26) |
14
(22) |
15
(19) |
16
(17) |
17
(16) |
18
(2) |
19
|
20
(1) |
21
(1) |
22
(10) |
23
(11) |
24
(17) |
25
(6) |
26
(1) |
27
|
28
(9) |
29
(9) |
30
(9) |
|
|
|
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...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 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: 2011年11月09日 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.