You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(2) |
2
(2) |
3
(7) |
|
4
(3) |
5
(17) |
6
(20) |
7
(11) |
8
(19) |
9
(3) |
10
(7) |
|
11
(4) |
12
|
13
|
14
|
15
(2) |
16
(5) |
17
(1) |
|
18
(8) |
19
(8) |
20
(10) |
21
(6) |
22
(16) |
23
(4) |
24
(1) |
|
25
(4) |
26
(4) |
27
(6) |
28
(2) |
29
(3) |
30
(7) |
31
(2) |
|
From: Erik T. <eri...@gm...> - 2010-07-27 17:14:31
|
Great - if anything's unclear, I can fairly easily make a test case as Benjamin suggested, so just let me know if that's necessary - thank! On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres <re...@he...> wrote: > Hi Erik, > > Sorry for the delay. From just looking at the diff I would say it's a > great addition. I'll test tomorrow and push it if it works (which I > assume it does). > > Cheers, > Reinier > > On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...> wrote: >> Just a quick ping about this - did it get applied, or was there >> something wrong with it? (Or am I just too impatient?) >> >> On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote: >>> I noticed some odd behavior when trying to set ticks on 3d plots made >>> using mplot3d.Axes3D ... specifically, if you tries to access any of >>> the 3D axes and change the ticks, it would result in a plot all >>> squashed to one side (indicating some sort of projection problem). >>> After a bit of digging, I discovered the source of the problem: >>> axis.XAxis, the base of the 3D Axis class, calls set_view_interval, >>> which is not overridden in mplot3d.axis3d.Axis, causing the wrong >>> interval to get the range assigned when ticks were added. So the >>> solution was to implement set_view_interval on the 3D Axis. That fix >>> is attached as a diff against the current svn in mpl3d-ticks-fix.diff >>> . Now setting ticks seems to work just fine, so I've included another >>> diff that additionally implements set_?ticks3d and get_?ticks3d >>> methods for Axes3D - that's attached as >>> mpl3d-ticks-fix-add-methods.diff . >>> >>> -- >>> Erik Tollerud >>> >> >> >> >> -- >> Erik Tollerud >> >> ------------------------------------------------------------------------------ >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> of $1 Million in cash or HP Products. Visit us here for more details: >> http://ad.doubleclick.net/clk;226879339;13503038;l? >> http://clk.atdmt.com/CRS/go/247765532/direct/01/ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > > -- > Reinier Heeres > Tel: +31 6 10852639 > -- Erik Tollerud |
|
From: Benjamin R. <ben...@ou...> - 2010-07-27 14:26:43
|
On Tue, Jul 27, 2010 at 12:11 AM, David Trem <dav...@gm...> wrote: > Just for the records, the fix now applied to the svn and > discuss on this list under """Plot moves while using the "Zoom to > rectangle" button""" thread also fixes the problem I reported > earlier this year (see email below). > > Best Regards, > > David > > Le 20/01/10 18:01, David Trem a écrit : > > Hi, > > > > I do see strange behavior when using "Zoom to rectangle" > > on my figures embedded in gtk through glade. > > When clicking on the figure and start drawing the rectangle, > > the bottom axis moves up as well as the graph which screw up > > the whole figure during the rectangle definition. When releasing > > the mouse button the figure looks ok. > > > > I attach a small script together with glade file (slightly modified > > from the matplotlib examples) that allows to reproduce the problem: > > -> launch the script, press the "Zoom to rectangle button" and start > > drawing the rectangle region on the graph, you will see the issue... > > It as to be noticed that pure gtk version (without glade) does work > > properly. > > > > I'm on MacOsX 10.5.8 using gtk.gtk_version (2, 18, 6) > > and gtk.pygtk_version (2, 16, 0) with python 2.6 > > > > Hope someone could help me solving this annoying issue. > > > > Regards, > > > > David > > David, I am glad to see that this solved your problem. Sorry for the lack of a follow-up on your issue. I guess the solution to your problem wasn't entirely obvious at that time. I take it that no ticket was filed for it that we have to close? Ben Root |
|
From: Reinier H. <re...@he...> - 2010-07-27 07:28:07
|
Hi Erik, Sorry for the delay. From just looking at the diff I would say it's a great addition. I'll test tomorrow and push it if it works (which I assume it does). Cheers, Reinier On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud <eri...@gm...> wrote: > Just a quick ping about this - did it get applied, or was there > something wrong with it? (Or am I just too impatient?) > > On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote: >> I noticed some odd behavior when trying to set ticks on 3d plots made >> using mplot3d.Axes3D ... specifically, if you tries to access any of >> the 3D axes and change the ticks, it would result in a plot all >> squashed to one side (indicating some sort of projection problem). >> After a bit of digging, I discovered the source of the problem: >> axis.XAxis, the base of the 3D Axis class, calls set_view_interval, >> which is not overridden in mplot3d.axis3d.Axis, causing the wrong >> interval to get the range assigned when ticks were added. So the >> solution was to implement set_view_interval on the 3D Axis. That fix >> is attached as a diff against the current svn in mpl3d-ticks-fix.diff >> . Now setting ticks seems to work just fine, so I've included another >> diff that additionally implements set_?ticks3d and get_?ticks3d >> methods for Axes3D - that's attached as >> mpl3d-ticks-fix-add-methods.diff . >> >> -- >> Erik Tollerud >> > > > > -- > Erik Tollerud > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://ad.doubleclick.net/clk;226879339;13503038;l? > http://clk.atdmt.com/CRS/go/247765532/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Reinier Heeres Tel: +31 6 10852639 |
|
From: David T. <dav...@gm...> - 2010-07-27 05:12:07
|
Just for the records, the fix now applied to the svn and discuss on this list under """Plot moves while using the "Zoom to rectangle" button""" thread also fixes the problem I reported earlier this year (see email below). Best Regards, David Le 20/01/10 18:01, David Trem a écrit : > Hi, > > I do see strange behavior when using "Zoom to rectangle" > on my figures embedded in gtk through glade. > When clicking on the figure and start drawing the rectangle, > the bottom axis moves up as well as the graph which screw up > the whole figure during the rectangle definition. When releasing > the mouse button the figure looks ok. > > I attach a small script together with glade file (slightly modified > from the matplotlib examples) that allows to reproduce the problem: > -> launch the script, press the "Zoom to rectangle button" and start > drawing the rectangle region on the graph, you will see the issue... > It as to be noticed that pure gtk version (without glade) does work > properly. > > I'm on MacOsX 10.5.8 using gtk.gtk_version (2, 18, 6) > and gtk.pygtk_version (2, 16, 0) with python 2.6 > > Hope someone could help me solving this annoying issue. > > Regards, > > David |
|
From: Benjamin R. <ben...@ou...> - 2010-07-27 01:38:39
|
On Mon, Jul 26, 2010 at 7:55 PM, Erik Tollerud <eri...@gm...>wrote: > Just a quick ping about this - did it get applied, or was there > something wrong with it? (Or am I just too impatient?) > > On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> > wrote: > > I noticed some odd behavior when trying to set ticks on 3d plots made > > using mplot3d.Axes3D ... specifically, if you tries to access any of > > the 3D axes and change the ticks, it would result in a plot all > > squashed to one side (indicating some sort of projection problem). > > After a bit of digging, I discovered the source of the problem: > > axis.XAxis, the base of the 3D Axis class, calls set_view_interval, > > which is not overridden in mplot3d.axis3d.Axis, causing the wrong > > interval to get the range assigned when ticks were added. So the > > solution was to implement set_view_interval on the 3D Axis. That fix > > is attached as a diff against the current svn in mpl3d-ticks-fix.diff > > . Now setting ticks seems to work just fine, so I've included another > > diff that additionally implements set_?ticks3d and get_?ticks3d > > methods for Axes3D - that's attached as > > mpl3d-ticks-fix-add-methods.diff . > > > > -- > > Erik Tollerud > > > > > Erik, Do you have a short, simple script that demonstrates the problem so that we can test the patch? Ben Root |
|
From: Erik T. <eri...@gm...> - 2010-07-27 00:55:48
|
Just a quick ping about this - did it get applied, or was there something wrong with it? (Or am I just too impatient?) On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud <eri...@gm...> wrote: > I noticed some odd behavior when trying to set ticks on 3d plots made > using mplot3d.Axes3D ... specifically, if you tries to access any of > the 3D axes and change the ticks, it would result in a plot all > squashed to one side (indicating some sort of projection problem). > After a bit of digging, I discovered the source of the problem: > axis.XAxis, the base of the 3D Axis class, calls set_view_interval, > which is not overridden in mplot3d.axis3d.Axis, causing the wrong > interval to get the range assigned when ticks were added. So the > solution was to implement set_view_interval on the 3D Axis. That fix > is attached as a diff against the current svn in mpl3d-ticks-fix.diff > . Now setting ticks seems to work just fine, so I've included another > diff that additionally implements set_?ticks3d and get_?ticks3d > methods for Axes3D - that's attached as > mpl3d-ticks-fix-add-methods.diff . > > -- > Erik Tollerud > -- Erik Tollerud |