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
(1) |
2
(1) |
3
(9) |
4
(2) |
5
|
6
(6) |
7
(3) |
8
(1) |
9
(6) |
10
(1) |
11
|
12
|
13
(2) |
14
(8) |
15
(2) |
16
|
17
(11) |
18
(5) |
19
(2) |
20
(2) |
21
(4) |
22
(2) |
23
(5) |
24
(6) |
25
|
26
|
27
(2) |
28
(9) |
|
Hey everyone, Sorry to posters who may have seen this on the scikit mailing list. I started a small project for drawing and manipulating particles on images. All of the particles optionally support matplotlib patches on the backend. I thought I'd share in case anyone was interested, or if any of the images might be useful just for the aesthetic appeal on your site. Here is the page: https://github.com/hugadams/pyparty In the "documentation" section, there are several notebooks with various examples of patch objects used. If this is inappropriate for the list, feel free to delete. Thanks. -- View this message in context: http://matplotlib.1069221.n5.nabble.com/small-library-with-matplotlib-patches-backend-crosslist-post-tp42828.html Sent from the matplotlib - users mailing list archive at Nabble.com.
The solution is following: uninstall numpy using yum. build numpy from source and install it. Build matplotlib from source! Best On Mon, Feb 3, 2014 at 3:29 PM, Nemanja Savic <vla...@gm...> wrote: > Hi all guys, I am back to the same issue again. At the moment I am not > able to reazlize where does matplotlib configure script find that my > version of numpy is 1.4.1? > > > On Tue, Nov 12, 2013 at 4:20 PM, Nemanja Savic <vla...@gm...> wrote: > >> I see. But is there any other way to cope with this x server problem and >> multiple figures plotting? >> >> >> On Tue, Nov 12, 2013 at 3:21 PM, Benjamin Root <ben...@ou...> wrote: >> >>> >>> >>> >>> On Tue, Nov 12, 2013 at 7:37 AM, Nemanja Savic <vla...@gm...>wrote: >>> >>>> Hi all guys, >>>> >>>> I am using RHEL6 and I am ploting figures throughout my project, so I >>>> wanted some workaroung blocking show() function call. I have found few >>>> solutions that use multiprocessing, so finally i finished with this: >>>> >>>> pool.map(plot_graph, c) >>>> >>>> and >>>> >>>> def plot_graph(*args): >>>> plt.figure(args[0][2]) >>>> plt.bar(args[0][1][:-1], args[0][0], width=1) >>>> plt.show() >>>> >>>> But when I have more than one figure the following error occures: >>>> >>>> >>>> /usr/lib64/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621: >>>> DeprecationWarning: Use the new widget gtk.Tooltip >>>> self.tooltips = gtk.Tooltips() >>>> /usr/lib64/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621: >>>> DeprecationWarning: Use the new widget gtk.Tooltip >>>> self.tooltips = gtk.Tooltips() >>>> [xcb] Unknown sequence number while processing queue >>>> [xcb] Most likely this is a multi-threaded client and XInitThreads has >>>> not been called >>>> [xcb] Aborting, sorry about that. >>>> python: xcb_io.c:273: poll_for_event: Assertion >>>> `!xcb_xlib_threads_sequence_lost' failed. >>>> runner.py: Fatal IO error 0 (Success) on X server :0.0. >>>> >>>> Since my version of matplolib doesnt support blocking = false solution, >>>> I wanted to install new version. For that I installed new version of numpy >>>> but when i run python setup.py build in matplolib foldet i get following: >>>> >>>> Edit setup.cfg to change the build options >>>> >>>> BUILDING MATPLOTLIB >>>> matplotlib: yes [1.3.1] >>>> python: yes [2.6.6 (r266:84292, May 27 2013, 05:35:12) >>>> [GCC >>>> 4.4.7 20120313 (Red Hat 4.4.7-3)]] >>>> platform: yes [linux2] >>>> >>>> REQUIRED DEPENDENCIES AND EXTENSIONS >>>> numpy: yes [version 1.8.0] >>>> dateutil: yes [using dateutil version 1.4.1] >>>> tornado: yes [tornado was not found. It is required for >>>> the >>>> WebAgg backend. pip/easy_install may attempt to >>>> install it after matplotlib.] >>>> pyparsing: yes [pyparsing was not found. It is required for >>>> mathtext support. pip/easy_install may attempt >>>> to >>>> install it after matplotlib.] >>>> pycxx: yes [Couldn't import. Using local copy.] >>>> libagg: yes [pkg-config information for 'libagg' could >>>> not >>>> be found. Using local copy.] >>>> freetype: yes [version 9.22.3] >>>> png: yes [version 1.2.49] >>>> >>>> OPTIONAL SUBPACKAGES >>>> sample_data: yes [installing] >>>> toolkits: yes [installing] >>>> tests: yes [nose 0.11.1 or later is required to run the >>>> matplotlib test suite] >>>> >>>> OPTIONAL BACKEND EXTENSIONS >>>> macosx: no [Mac OS-X only] >>>> qt4agg: yes [installing, Qt: 4.6.2, PyQt4: 4.6.2] >>>> gtk3agg: no [Requires pygobject to be installed.] >>>> gtk3cairo: no [Requires pygobject to be installed.] >>>> gtkagg: yes [installing, Gtk: 2.18.9 pygtk: 2.16.0] >>>> tkagg: yes [installing, version 73770] >>>> wxagg: yes [installing, version 2.8.12.0] >>>> gtk: yes [installing, Gtk: 2.18.9 pygtk: 2.16.0] >>>> agg: yes [installing] >>>> cairo: yes [installing, version 1.8.6] >>>> windowing: no [Microsoft Windows only] >>>> >>>> OPTIONAL LATEX DEPENDENCIES >>>> dvipng: yes [version 1.14] >>>> ghostscript: yes [version 8.70] >>>> latex: yes [version 3.1415926] >>>> pdftops: no >>>> >>>> Traceback (most recent call last): >>>> File "setup.py", line 268, in <module> >>>> **extra_args >>>> File "/usr/lib64/python2.6/distutils/core.py", line 113, in setup >>>> _setup_distribution = dist = klass(attrs) >>>> File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 221, in >>>> __init__ >>>> File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 245, in >>>> fetch_build_eggs >>>> File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 592, in >>>> resolve >>>> plugin_projects.sort() # scan project names in alphabetic order >>>> pkg_resources.VersionConflict: (numpy 1.4.1 >>>> (/usr/lib64/python2.6/site-packages), Requirement.parse('numpy>=1.5')) >>>> >>>> When I run python and check numpy version it is indeed 1.8.0, but >>>> matplotlib buils script somehow founded older one. >>>> >>>> >>>> I would be really happy if somebody can help me overcome problem with >>>> many figures. >>>> >>>> Best and cheers >>>> >>>> >>> The issue is rather complex, and it is a very difficult one to solve on >>> our end. What is happening is that in order to build matplotlib from >>> source, you need to compile against the numpy headers at build-time. >>> Unfortunately, python packaging being what it is, there is difficulty in >>> making sure that the version of numpy that will be installed is the version >>> used for the build. You seem to have numpy installed both at the system >>> level and possibly at the user level. If possible, I would try removing >>> numpy from your system level (and that likely means removing any other >>> installed package that depends on it, and reinstalling via source). >>> >>> Ben Root >>> >> >> >> >> -- >> Nemanja Savić >> > > > > -- > Nemanja Savić > -- Nemanja Savić
Hi all guys, I am back to the same issue again. At the moment I am not able to reazlize where does matplotlib configure script find that my version of numpy is 1.4.1? On Tue, Nov 12, 2013 at 4:20 PM, Nemanja Savic <vla...@gm...> wrote: > I see. But is there any other way to cope with this x server problem and > multiple figures plotting? > > > On Tue, Nov 12, 2013 at 3:21 PM, Benjamin Root <ben...@ou...> wrote: > >> >> >> >> On Tue, Nov 12, 2013 at 7:37 AM, Nemanja Savic <vla...@gm...>wrote: >> >>> Hi all guys, >>> >>> I am using RHEL6 and I am ploting figures throughout my project, so I >>> wanted some workaroung blocking show() function call. I have found few >>> solutions that use multiprocessing, so finally i finished with this: >>> >>> pool.map(plot_graph, c) >>> >>> and >>> >>> def plot_graph(*args): >>> plt.figure(args[0][2]) >>> plt.bar(args[0][1][:-1], args[0][0], width=1) >>> plt.show() >>> >>> But when I have more than one figure the following error occures: >>> >>> >>> /usr/lib64/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621: >>> DeprecationWarning: Use the new widget gtk.Tooltip >>> self.tooltips = gtk.Tooltips() >>> /usr/lib64/python2.6/site-packages/matplotlib/backends/backend_gtk.py:621: >>> DeprecationWarning: Use the new widget gtk.Tooltip >>> self.tooltips = gtk.Tooltips() >>> [xcb] Unknown sequence number while processing queue >>> [xcb] Most likely this is a multi-threaded client and XInitThreads has >>> not been called >>> [xcb] Aborting, sorry about that. >>> python: xcb_io.c:273: poll_for_event: Assertion >>> `!xcb_xlib_threads_sequence_lost' failed. >>> runner.py: Fatal IO error 0 (Success) on X server :0.0. >>> >>> Since my version of matplolib doesnt support blocking = false solution, >>> I wanted to install new version. For that I installed new version of numpy >>> but when i run python setup.py build in matplolib foldet i get following: >>> >>> Edit setup.cfg to change the build options >>> >>> BUILDING MATPLOTLIB >>> matplotlib: yes [1.3.1] >>> python: yes [2.6.6 (r266:84292, May 27 2013, 05:35:12) >>> [GCC >>> 4.4.7 20120313 (Red Hat 4.4.7-3)]] >>> platform: yes [linux2] >>> >>> REQUIRED DEPENDENCIES AND EXTENSIONS >>> numpy: yes [version 1.8.0] >>> dateutil: yes [using dateutil version 1.4.1] >>> tornado: yes [tornado was not found. It is required for >>> the >>> WebAgg backend. pip/easy_install may attempt to >>> install it after matplotlib.] >>> pyparsing: yes [pyparsing was not found. It is required for >>> mathtext support. pip/easy_install may attempt to >>> install it after matplotlib.] >>> pycxx: yes [Couldn't import. Using local copy.] >>> libagg: yes [pkg-config information for 'libagg' could >>> not >>> be found. Using local copy.] >>> freetype: yes [version 9.22.3] >>> png: yes [version 1.2.49] >>> >>> OPTIONAL SUBPACKAGES >>> sample_data: yes [installing] >>> toolkits: yes [installing] >>> tests: yes [nose 0.11.1 or later is required to run the >>> matplotlib test suite] >>> >>> OPTIONAL BACKEND EXTENSIONS >>> macosx: no [Mac OS-X only] >>> qt4agg: yes [installing, Qt: 4.6.2, PyQt4: 4.6.2] >>> gtk3agg: no [Requires pygobject to be installed.] >>> gtk3cairo: no [Requires pygobject to be installed.] >>> gtkagg: yes [installing, Gtk: 2.18.9 pygtk: 2.16.0] >>> tkagg: yes [installing, version 73770] >>> wxagg: yes [installing, version 2.8.12.0] >>> gtk: yes [installing, Gtk: 2.18.9 pygtk: 2.16.0] >>> agg: yes [installing] >>> cairo: yes [installing, version 1.8.6] >>> windowing: no [Microsoft Windows only] >>> >>> OPTIONAL LATEX DEPENDENCIES >>> dvipng: yes [version 1.14] >>> ghostscript: yes [version 8.70] >>> latex: yes [version 3.1415926] >>> pdftops: no >>> >>> Traceback (most recent call last): >>> File "setup.py", line 268, in <module> >>> **extra_args >>> File "/usr/lib64/python2.6/distutils/core.py", line 113, in setup >>> _setup_distribution = dist = klass(attrs) >>> File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 221, in >>> __init__ >>> File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 245, in >>> fetch_build_eggs >>> File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 592, in >>> resolve >>> plugin_projects.sort() # scan project names in alphabetic order >>> pkg_resources.VersionConflict: (numpy 1.4.1 >>> (/usr/lib64/python2.6/site-packages), Requirement.parse('numpy>=1.5')) >>> >>> When I run python and check numpy version it is indeed 1.8.0, but >>> matplotlib buils script somehow founded older one. >>> >>> >>> I would be really happy if somebody can help me overcome problem with >>> many figures. >>> >>> Best and cheers >>> >>> >> The issue is rather complex, and it is a very difficult one to solve on >> our end. What is happening is that in order to build matplotlib from >> source, you need to compile against the numpy headers at build-time. >> Unfortunately, python packaging being what it is, there is difficulty in >> making sure that the version of numpy that will be installed is the version >> used for the build. You seem to have numpy installed both at the system >> level and possibly at the user level. If possible, I would try removing >> numpy from your system level (and that likely means removing any other >> installed package that depends on it, and reinstalling via source). >> >> Ben Root >> > > > > -- > Nemanja Savić > -- Nemanja Savić
On 2/3/2014 1:36 AM, Eric Firing wrote: > The default of not including the > head in the length is puzzling, to say the least. And again, it does not match the behavior of Arrow. So perhaps the current behavior could be changed? (E.g., after a period of requiring `length_includes_head`, which I'll bet practically all users are already setting, because of the puzzling default.) Also, am I wrong that the default head_width and head_length are buggy (i.e., not set in proportion to the `width`, as the documentation requires)? Thanks, Alan PS Thanks for 'none'; I'd forgotten. Also, quiver is somewhat useful (good arrows), but lacks easy control over individual arrow properties.
On 2014年02月02日 7:45 PM, Alan G Isaac wrote: > Last question about this for now ... > > Yet another issue with `arrow`: the > docs say a dashed linestyle is supported > http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.arrow > but really it is not: the *edge* is dashed rather than the tail! > > Maybe I'm missing the intended usage here. But > I'm starting to think Matplotlib could use a "SimpleArrow". > The tail would just be a line. > The head would just be a filled triangle. > The default would be length_includes_head=True. > > Alan Isaac > Alan, I think you are raising good points. (The default of not including the head in the length is puzzling, to say the least.) Actually making a *good* simple arrow is not as simple as it might seem, but it can be done. The main difficulty is the need to use a mix of coordinates and transforms to handle varying axes sizes and aspect ratios. In any case, I think you have pointed to one of many areas where mpl's present design and user interface could be improved. It's all a matter of volunteer labor to make such improvements--with the added difficulty of needing to maintain backward compatibility over fairly long periods. For your immediate needs, might quiver work better? It's interface is also rather complex because of the use cases it covers. If you are using the arrows for annotation rather than as representations of vectors, then of course the annotate() function is appropriate. Eric
On 2014年02月02日 6:52 PM, Alan G Isaac wrote: > Also, despite setting `edgecolor=None`, the edge is still stroked. I suspect you need edgecolor='none'. In general, specifying a color as the string 'none' means "don't draw it".
Last question about this for now ... Yet another issue with `arrow`: the docs say a dashed linestyle is supported http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.arrow but really it is not: the *edge* is dashed rather than the tail! Maybe I'm missing the intended usage here. But I'm starting to think Matplotlib could use a "SimpleArrow". The tail would just be a line. The head would just be a filled triangle. The default would be length_includes_head=True. Alan Isaac
On 2/2/2014 11:13 PM, Alan G Isaac wrote: > A follow-on question: the `arrow` method of an axes > has `length_includes_head` default to False. Why? > This seems very unfriendly behavior for an "arrow". > It also conflicts with the behavior of an `Arrow`. One more follow-on question: the documented behavior of head_width and head_length is: http://matplotlib.org/api/axes_api.html head_width: float or None (default: 3*width) total width of the full arrow head head_length: float or None (default: 1.5 * head_width) length of arrow head But I believe that does not match the behavior I am seeing. E.g., the following produces two completely different arrow heads. fig, ax = plt.subplots(1,1) ax.set_aspect('equal') w=0.01 ax.arrow(0,0,1,1, width=w,head_width=3*w,head_length=1.5*3*w, facecolor='red',edgecolor=None,length_includes_head=True) ax.arrow(0,1,1,-1, width=w, facecolor='k',edgecolor='red',length_includes_head=True) Am I missing something? Also, despite setting `edgecolor=None`, the edge is still stroked. Alan Isaac
A follow-on question: the `arrow` method of an axes has `length_includes_head` default to False. Why? This seems very unfriendly behavior for an "arrow". It also conflicts with the behavior of an `Arrow`. Thanks, Alan Isaac