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
|
From: John H. <jdh...@ac...> - 2005-02-07 12:08:13
|
>>>>> "Andrew" == Andrew Straw <str...@as...> writes: Andrew> Again, a no brainer: Glad you found the answer :-) See also Fernando's matshow command in CVS. The data scaling with aspect='preserve' in imshow is currently broken -- the axes coordinates on the shorter dimension are wrong and because of this zoom to rect doesn't do what it should. Fernando's command works around this problem by creating a figure and axes with the proper aspect ratio . Currently, it only works with arrays, but you could easily patch it to work with pil images as you did for imshow. Cheers, JDH |
From: Andrew S. <str...@as...> - 2005-02-07 06:48:43
|
Andrew Straw wrote: > > Now, on to determine how to plot an image with origin='upper' with the > extent going the other way... Again, a no brainer: (modifications to image_demo3.py) w,h = lena.size extent = 0,w,h,0 figure(figsize=figsize) im = imshow(lena, origin='upper', aspect='preserve', extent=extent) |
From: Andrew S. <str...@as...> - 2005-02-07 06:29:41
|
Andrew Straw wrote: > Simple question: how can I plot something such that the y axis is > "inverted"? (Increasing downwards?) Simple answer: ymin,ymax= get(gca(),'ylim') set(gca(),'ylim',[ymax,ymin]) Now, on to determine how to plot an image with origin='upper' with the extent going the other way... Cheers! Andrew |
From: Andrew S. <str...@as...> - 2005-02-07 06:14:43
|
Simple question: how can I plot something such that the y axis is "inverted"? (Increasing downwards?) (I thought I'd better ask before fubaring my copy of mpl's transAxes, transData, bbox code and going insane in the process.) Cheers! Andrew |
From: Robert K. <rk...@uc...> - 2005-02-05 22:36:08
|
Chris Barker wrote: > Robert Kern wrote: >> Change the paths that distutils will add to the link line. They're at >> the top of setupext.py . Remove the ones you don't need. > > > Except that the *.a and *.dylib are put in the same place. Darn. Copy (and re-ranlib) the static library and headers to another place. -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter |
From: Chris B. <Chr...@no...> - 2005-02-04 23:09:21
|
John Hunter wrote: > I do statically link png, freetype and zlib for win32 so that users > don't have to install any of those prereqs. Thanks John, I have a plan now. I have a question, however. How do I get distutils to statically link a given lib? the only method I have now is to make sure that only the static lib is available. I can do that (for the moment) with libpng, but for freetype, I have a problem. In setupext.py, there is: basedir = { 'darwin' : ['/usr/local', '/usr', '/sw', '/usr/X11R6'], } There is a libfreetype in /usr/X11R6, but only if X11 is installed, so I don't want to use it. However, I imagine that /usr/X11R6 is required to the GTK build, so I can't take that out. Any ideas? I notice that for win32, you have only: basedir = { 'win32' : ['win32_static',], Should I do that for darwin, and put my static libs in there? I'm off to try some of this. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: John H. <jdh...@ac...> - 2005-02-04 22:39:01
|
>>>>> "Chris" == Chris Barker <Chr...@no...> writes: Chris> The question is: Can I build a binary version that will Chris> work with all the back ends, if they are there, but also Chris> work on what is there if they aren't all. This comes down Chris> to when the linking happens, I guess. Experimentation will Chris> answer this for me, but I welcome and insight any of you Chris> may have. Chris> One issue that has come up is libfreetype. If you have GTK, Chris> you have X11, so you have libfreetype. Indeed, I don't have Chris> GTK, but I do have X11, and the X11 freetype got linked to Chris> my package. I can probably fix this by removing Chris> "/usr/X11R6" from the basedir list for darwin. Then I'll Chris> have libfreetype statically linked to matplotlib, but Chris> PyGTK, if the user has it, will have a different version Chris> dynamically linked. Is this going to cause problems? Here is what I do for the win32 which has some related issues. matplotlib needs Tkinter and pygtk to be installed on your build system in order to build the matplotlib extension code for those modules. But you do not need to statically link in any gtk or tk library code. I do statically link png, freetype and zlib for win32 so that users don't have to install any of those prereqs. Then they get a package that has Agg, PS, SVG out of the box regardless of their system. If they have pygtk on their system, they also get GTK and GTKAgg. If they have Tkinter, they also get TkAgg. If they have wxpython, they also get WX, WXAgg. The key is, if you want your package to be maximally usable, you should have pygtk and tk (and the requisite devel stuff) and should probably statically link freetype, png and zlib. Of course there is now also a Cairo and GTKCairo backend, which may interest some OSX X11 users, but I haven't had to worry about this for win32 users. And FLTK and QT ..., but we can save that for another day. I think if you have the tkagg extension compiled in, most OSX people will be happy with either that or wxagg. JDH |
From: Chris B. <Chr...@no...> - 2005-02-04 22:19:35
|
Robert Kern wrote: > Chris Barker wrote: >> However, that doesn't seem to work if I have libfreetype.dylib >> somewhere standard, and I certainly don't want to remove it! (Maybe I >> could temporarily, but that's hardly the robust solution I'm looking for) > > Change the paths that distutils will add to the link line. They're at > the top of setupext.py . Remove the ones you don't need. Except that the *.a and *.dylib are put in the same place. Darn. >> By the way, it would also be good to get this to work with TK and/or >> GTK. Has anyone done that successfully that would like to help out >> with this? > With TclTkAqua, it Just Works. Someone posted recently to the MacPython Mailing list with a series of questions that this was not the case, at least to for him. So I wasn't sure. >> Also, as far as PyGTK is concerned. Can you run it without running >> Fink? That's the only way I've seen it done. If it is a Fink only >> option, then this is moot, as I'm looking for a Fink free approach, >> and someone else has put together a fink matplotlib package. > You could try Darwinports. Set Darwinports' prefix to /usr/local, and > use port(1) to make Installer.app packages for GTK et al. Bundle them > with your bdist_mpkg metapackage. Hmm. That sounds promising. However... My immediate need to to get matplotlib installed on and OS-X Server box that someone else is administering. For this purpose, I only need the Agg back end. However, for my own purposes, I also want wx. The easiest way for me to accomplish my immediate goal is probably to just install all the libs needed on that server, but I'm trying to keep it simple for the admin, and I figured this could be a useful contribution to the MacPython community. However, here is the complication. As long as I am doing this, I'd like to make it as useful as possible. That means it would be nice if I could come up with a single binary that works with all the available back ends on OS-X (Agg, wx, PyGTK, Tkinter). I also want people to be able to install it on a stock box and have it work. This doesn't mean that I want it to include PyGTK and TK, but it would be nice if it worked with those, if they were present. The question is: Can I build a binary version that will work with all the back ends, if they are there, but also work on what is there if they aren't all. This comes down to when the linking happens, I guess. Experimentation will answer this for me, but I welcome and insight any of you may have. One issue that has come up is libfreetype. If you have GTK, you have X11, so you have libfreetype. Indeed, I don't have GTK, but I do have X11, and the X11 freetype got linked to my package. I can probably fix this by removing "/usr/X11R6" from the basedir list for darwin. Then I'll have libfreetype statically linked to matplotlib, but PyGTK, if the user has it, will have a different version dynamically linked. Is this going to cause problems? More as I make more progress... -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: John H. <jdh...@ac...> - 2005-02-04 15:50:44
|
>>>>> "Travis" == Travis Brady <td...@fa...> writes: Travis> Hi Everyone, I'm using plot_date to scatter a ton of data Travis> retrieved from a database and have encountered an error Travis> with the date ticks. Travis> I more or less copied the format of the example in Travis> http://matplotlib.sourceforge.net/examples/date_demo2.py Travis> and my ticks ended up being months in order but never Travis> making it past the year 2001 (they just recycle) though my Travis> data begin in 2000 and end in 2004. Travis> I took another look at the plot generated by date_demo2.py Travis> and it turns out that the same is true there. Travis> I'm thinking this is not intentional, but if so does Travis> anyone have any advice or example scripts that might help Travis> me fix my plot? That's because the format string is printing 'month day' and not 'month year' and the day is always 01 in the example. You might want monthsFmt = DateFormatter("%b '%y") Hope this helps, JDH |
From: Steve C. <ste...@ya...> - 2005-02-04 14:28:24
|
> On Wed, 2005-02-02 at 10:14 -0800, matplotlib-users- > re...@li... wrote: > > On Wednesday 02 February 2005 04:51 am, Steve Chaplin wrote: > > > > > > When resizing the FigureCanvas on my system I notice: > > > GTK sets a FigureCanvas size that can only be increased. > > > QtAgg sets a FigureCanvas size that can be increased or decreased > > > TkAgg sets a FigureCanvas size that can be increased or decreased to a > > > minimum (of perhaps 400 x 300 pixels) > > > Wx I do not have, is it like Qt or Tk or is there a 4th variation? > > > > on linux, wx lets me increase or decrease all the way. I wonder if it is > > different on windows. > > > > > > > > I looked at changing GTK so the FigureCanvas could be decreased a while > > > ago but the problem is that while the axes scale/shrink nicely the text > > > stays the same size and becomes misaligned or clipped and gives an odd > > > looking graph. Perhaps thats why Tk allows you shrink the window but > > > only to a certain size. > > > > > > Matplotlib currently has 3 (or more) ways of handling window resizing, > > > which one of these behaviours is 'correct' or most desirable? > > > > > > > I think the most desirable for interactive use would be to allow scaling, but > > if it doesn't scale properly, I think the current behavior is appropriate. I > > guess I just didnt notice it before now. > > > > Darren I've changed the GTK backends (in cvs) so they will now allow the window to be resized smaller than the original size. Text still does not scale down when the window shrinks, but if the matplotlib user wants a smaller window they now have the option to resize the window. Steve |
From: kristen k. <co...@ya...> - 2005-02-04 11:18:04
|
Hola When i try to fit a polynomial of order 4 to 5 data points, I get an answer far from what I would expect. Try and run the attached script an see if you can fit the datapoints in x and y better than me. When I run the script, the fit doesn't go through any of the points. The problem is also present for higher order pol. Kristen __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Robert K. <rk...@uc...> - 2005-02-04 05:27:41
|
And while we're on the subject of OS X builds, I have a request. Can you add /usr/local/share/matplotlib to the list of default locations search for the data directory? /System/Library/Frameworks/Python.framework/Versions/Current/share/matplotlib is not, I think a good place for it. -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter |
From: Robert K. <rk...@uc...> - 2005-02-04 05:17:47
|
Chris Barker wrote: > However, that doesn't seem to work if I have libfreetype.dylib somewhere > standard, and I certainly don't want to remove it! (Maybe I could > temporarily, but that's hardly the robust solution I'm looking for) Change the paths that distutils will add to the link line. They're at the top of setupext.py . Remove the ones you don't need. > By the way, it would also be good to get this to work with TK and/or > GTK. Has anyone done that successfully that would like to help out with > this? With TclTkAqua, it Just Works. > Also, as far as PyGTK is concerned. Can you run it without running Fink? > That's the only way I've seen it done. If it is a Fink only option, then > this is moot, as I'm looking for a Fink free approach, and someone else > has put together a fink matplotlib package. You could try Darwinports. Set Darwinports' prefix to /usr/local, and use port(1) to make Installer.app packages for GTK et al. Bundle them with your bdist_mpkg metapackage. My strategy for building matplotlib (and I've done it *a lot* in the past few weeks) is as follows: I have Darwinports with a prefix in a GNU Stow repository. What Stow does is it allows you to install stuff into it's own directory (/usr/local/stow/darwinports, which has bin/, lib/, share/ et al.) and then makes symlinks such that everything appears to be installed to /usr/local. So I have Darwinports install libpng and libfreetype. I have a script that will remove the symlinks to the dylibs for libpng, libfreetype, and libz (I could probably resolve this by changing the order of search). I build matplotlib and double-check the dylib dependencies with "otool -L". I do not bother with GTK at this time. -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter |
From: Bob I. <bo...@re...> - 2005-02-04 00:27:19
|
On Feb 3, 2005, at 19:07, Chris Barker wrote: > I posted a note here the other day about a matplotlib binary. I've > discovered a problem with it. Apparently, it has linked against the > libfreetype in /usr/X11. That means it will work fine on a system with > Apple's X11 installed (like mine or the first system I tested it on). .. and the system that I tested it on :) > So, the question remains: How to I get distutils to statically link > selected libs? Bob had suggested: > > """Make sure you don't have libpng.dylib or libfreetype.dylib sitting > around on your link paths... > > Build them like this: > ./configure --disable-shared --enable static > > Make sure you only have libpng.a and libfreetype.a on your link paths. > It will link statically. > """ > > However, that doesn't seem to work if I have libfreetype.dylib > somewhere standard, and I certainly don't want to remove it! (Maybe I > could temporarily, but that's hardly the robust solution I'm looking > for) You have three options: - make sure the dylibs aren't sitting around in the same location as the .a, and make sure the .a's path is preferred (you could make a local dir, -L to it, symlink the archives in) - change the setup.py relatively significantly and specify them as object files with their full path (I can't tell you off the top of my head what the distutils incantation would be for this, but you definitely can not use it's "libraries" option, or whatever that is called) - don't link statically and install the dylibs too, somehow (possibly by building+installing them with --prefix=/Library/Python/2.3/matplotlib/lib-dynload/ and -L to that when linking.. note that this would require a bdist_mpkg subclass to make a .pkg out of it) -bob |
From: Chris B. <Chr...@no...> - 2005-02-04 00:07:15
|
Hi all, I posted a note here the other day about a matplotlib binary. I've discovered a problem with it. Apparently, it has linked against the libfreetype in /usr/X11. That means it will work fine on a system with Apple's X11 installed (like mine or the first system I tested it on). So, the question remains: How to I get distutils to statically link selected libs? Bob had suggested: """Make sure you don't have libpng.dylib or libfreetype.dylib sitting around on your link paths... Build them like this: ./configure --disable-shared --enable static Make sure you only have libpng.a and libfreetype.a on your link paths. It will link statically. """ However, that doesn't seem to work if I have libfreetype.dylib somewhere standard, and I certainly don't want to remove it! (Maybe I could temporarily, but that's hardly the robust solution I'm looking for) By the way, it would also be good to get this to work with TK and/or GTK. Has anyone done that successfully that would like to help out with this? Also, as far as PyGTK is concerned. Can you run it without running Fink? That's the only way I've seen it done. If it is a Fink only option, then this is moot, as I'm looking for a Fink free approach, and someone else has put together a fink matplotlib package. By the way the package, as it stands, can be found at: http://undefined.org/python/matplotlib-0.71-py2.3-macosx10.3.zip thanks to Bob Ippolito -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Travis B. <td...@fa...> - 2005-02-03 17:13:23
|
Hi Everyone, I'm using plot_date to scatter a ton of data retrieved from a database and have encountered an error with the date ticks. I more or less copied the format of the example in http://matplotlib.sourceforge.net/examples/date_demo2.py and my ticks ended up being months in order but never making it past the year 2001 (they just recycle) though my data begin in 2000 and end in 2004. I took another look at the plot generated by date_demo2.py and it turns out that the same is true there. I'm thinking this is not intentional, but if so does anyone have any advice or example scripts that might help me fix my plot? Thank you, Travis Brady -- Travis Brady td...@fa... |
From: <fcc...@fi...> - 2005-02-03 15:00:14
|
hi, I am plotting two figures in a row and I am getting a duplicated colorb= ar=20 in the second figure: imshow(stats[0]) title('Distance Matrix') colorbar() savefig('dm.png') imshow(stats[12]) colorbar() title('Conectivity Matrix') savefig('cm.png') I tried omitting the second colorbar() command. Then I get a single colorba= r=20 in the second figure but with same scale of figure 1. What am I doing wrong? =46l=E1vio |
From: John H. <jdh...@ac...> - 2005-02-03 14:45:38
|
>>>>> "Graeme" == Graeme O'Keefe <gj...@ne...> writes: Graeme> Hi, I've installed matplotlib 0.71 on Mac OS X 10.3 which Graeme> completed without errors. Graeme> when I run python "import matplotlib" is fine, but "import Graeme> pylab" bombs with "ImportError: cannot import name POLAR" rm -rf the build directory *and* site-packages/matplotlib and rebuild/reinstall. This cures the problem 95% of the time. It is usually caused from some detritus from a previous build or install that distutils doesn't handle so well. Let mw know... JDH |
From: John H. <jdh...@ac...> - 2005-02-03 14:42:49
|
>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes: Eric> Hi John, sorry to bother you about this again, but is there Eric> a fix to the bug in the imshow routine (using the Eric> aspect='preserve' option). If not, let me know if you have Eric> an idea when this could be done (no pushing there, just to Eric> plan things on my side: I am at the moment using an Eric> artificial way to replace that option by calculating Eric> coordinates on the plot, just to know if I need to go on Eric> with that or not). Hi Eric, there is not a fix yet, but there is a workaround in CVS. I played around with some things that got the initial coords right but then broke under window resizes and I rolled these changes back. It is a somewhat tough problem, to preserve aspect ration under possible figure and axes resizes, and/or view limit navigation. It is a very high priority bug for me, but because it is also a hard one its taking a little while. SO I can't give you a firm date -- I'll try and get something serviceable in the next couple of weeks. This is the same bug that causes zoom to rect on aspect=preserve plots to get the wrong limits. Fernando Perez submitted a patch in CVS that works around the problem for now using the "matshow" command. This command takes the same arguments as imshow and creates a figure and an axes which are scaled to have the same dimensions as the array. Thus if you don't resize your window, you can plot an array with matshow with either free or preserve and the aspect ratio will be correct. But, if you zoom to rect or resize your window, even with matshow you'll lose the aspect ratio. I'll include the docstring for matshow below so you can see if you're interested I've very aware of the scientists need to "just see the data" w/o any fancy stuff. Hopefully a fix will be in soon. JDH matshow: """Display an array as a matrix. The origin is set at the upper left hand corner and rows (first dimension of the array) are displayed horizontally. The aspect ratio of the figure window is that of the array, as long as it is possible to fit it within the constraints of your figure.figsize_min/max parameters with no stretching. If the window dimensions can't accomodate this (extremely tall/wide arrays), some stretching will inevitably occur. matshow() calls imshow() with args and **kwargs, but by default it sets interpolation='nearest' (unless you override it). All other arguments and keywords are passed to imshow(), so see its docstring for further details. Tick labels for the xaxis are placed on top by default. return value is a (fig, ax, im) tuple Example usage: def samplemat(dims): aa = zeros(dims) for i in range(min(dims)): aa[i,i] = i return aa dimlist = [(12,12),(128,64),(64,512),(2048,256)] for d in dimlist: fig, ax, im = matshow(samplemat(d)) show() """ |
From: Eric E. <ems...@ob...> - 2005-02-03 07:42:02
|
Hi John, sorry to bother you about this again, but is there a fix to the bug in the imshow routine (using the aspect='preserve' option). If not, let me know if you have an idea when this could be done (no pushing there, just to plan things on my side: I am at the moment using an artificial way to replace that option by calculating coordinates on the plot, just to know if I need to go on with that or not). Let me know; Thanks! Eric -- =============================================================== Observatoire de Lyon ems...@ob... 9 av. Charles-Andre tel: +33 4 78 86 83 84 69561 Saint-Genis Laval Cedex fax: +33 4 78 86 83 86 France http://www-obs.univ-lyon1.fr/eric.emsellem =============================================================== |
From: Graeme O'K. <gj...@ne...> - 2005-02-03 04:20:39
|
Hi, I've installed matplotlib 0.71 on Mac OS X 10.3 which completed without errors. when I run python "import matplotlib" is fine, but "import pylab" bombs with "ImportError: cannot import name POLAR" see below for a screendump of the reported errors when I try to import pylab. I did not run this in the build directory. /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ site-packages (which is linked to /Library/Python/2.3) /Library/Python/2.3/matplotlib/transforms.py, line 189: from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY /Library/Python/2.3/matplotlib/_transforms.so exists and is 3503536 bytes in size. here is a screendump of the reported errors when I try to import pylab. I did not run this in the build directory. can anyone help? regards, Graeme [graeme:~/Desktop/downloads/matplotlib-0.71] gjok% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import pylab Traceback (most recent call last): File "<stdin>", line 1, in ? File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/pylab.py", line 1, in ? from matplotlib.pylab import * File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/pylab.py", line 190, in ? from axes import Axes, PolarAxes File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/axes.py", line 12, in ? from artist import Artist File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/artist.py", line 3, in ? from transforms import identity_transform File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/matplotlib/transforms.py", line 189, in ? from _transforms import IDENTITY, LOG10, POLAR, Func, FuncXY ImportError: cannot import name POLAR |
From: John H. <jdh...@ac...> - 2005-02-03 03:17:10
|
>>>>> "Chris" == Chris Barker <Chr...@no...> writes: Chris> Hi all, I think I've successfully build a binary matplotlib Chris> package for use with Apple's Python on OS-X 10.3.* In Chris> theory the only other thing it requires is Numeric, and I Chris> have a package for that too (courtesy of Bob Ippolito). Chris> It's almost 5 MB, so I haven't included it here. I also Chris> don't have a web site to put it on at the moment, so: Chris> A) if you send me a note, I'll send it to you B) if you Chris> have a place to host it, please volunteer to do so. Chris> I'd like people to test it out, all I know now is that it Chris> works on my system. Chris> Once it's been better tested, perhaps we can get it put on Chris> the sourceforge download page. High Chris, Thanks for doing this. Are either the GTK or Tk GUI backends compiled in. If not, wx* will still work on boxes that have wxpython installed, but it would be a good idea to summarize what is available in the package. Thanks! JDH |
From: Chris B. <Chr...@no...> - 2005-02-03 01:08:53
|
Hi all, I think I've successfully build a binary matplotlib package for use with Apple's Python on OS-X 10.3.* In theory the only other thing it requires is Numeric, and I have a package for that too (courtesy of Bob Ippolito). It's almost 5 MB, so I haven't included it here. I also don't have a web site to put it on at the moment, so: A) if you send me a note, I'll send it to you B) if you have a place to host it, please volunteer to do so. I'd like people to test it out, all I know now is that it works on my system. Once it's been better tested, perhaps we can get it put on the sourceforge download page. thanks, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Dominique O. <Dom...@po...> - 2005-02-02 23:33:51
|
Hello, How complicated would it be to obtain the add_patch() capability in polar axes? Right now, the script -------------------- from pylab import * import matplotlib.patches as patches ax = axes( [0.1, 0.1, 0.8, 0.8], polar = True ) ptch = patches.RegularPolygon( (pi/2,.5), 5, orientation = 20 ) ax.add_patch() show() -------------------- fails, Python complaining that polar axes don't have an add_patch() method. Now, I believe if we simply mimic what's in the Axes class and try to use artists.extend(patches) in PolarAxes, the coordinates are going to be all wacko. The following works for me, and I wonder whether it is a useful addition to PolarAxes (sorry for the wrapped lines): -------------------- from matplotlib.pylab import * def RegularPolygon_polar( ax, xy, numVertices, radius = 5, orientation = 0, **kwargs ): import matplotlib.patches as patches import matplotlib.transforms as transforms ptch = patches.RegularPolygon( (0,0), numVertices, radius = radius, orientation = orientation, **kwargs ) trans = transforms.identity_affine() trans.set_offset( xy, ax.transData ) ptch.set_transform( trans ) return ptch ax = axes( [0.1, 0.1, 0.8, 0.8], polar = True ) ptch = RegularPolygon_polar( ax, (150*pi/180,.5), 5, radius = 10, orientation = 80 ) ax.add_patch( ptch ) show() -------------------- If this sounds like the way to go, let me know. I'm willing to write the few methods similar to the above and add them to PolarAxes. On the other hand, it might be easier to simply modify the classes in patches.py, but I am not sure how they would access the Axes instance. Cheers, Dominique |
From: John H. <jdh...@ac...> - 2005-02-02 19:04:55
|
>>>>> "Delbert" == Delbert D Franz <iq...@so...> writes: Delbert> I just did another test. mx2num fails for dates prior to Delbert> 1970 because it uses the magical Unix seconds from epoch. Delbert> We need mx2num to work for the whole range of dates for Delbert> which date2num works-at least that is my vote. Delbert Delbert> On Wednesday 02 February 2005 10:10 am, Delbert D. Franz wrote: If you feel up to making an mx2num that satisfies these requirements, I'm happy to include it as a patch. JDH |