matplotlib-devel Mailing List for matplotlib

On Friday 23 May 2008 7:54:27 pm John Hunter wrote:
> On Fri, May 23, 2008 at 6:14 PM, Darren Dale <dar...@co...>
> wrote
>
> > I have to break here for the weekend, I'll be back monday afternoon.
> > Leave some for me! (although I'll owe doughnut to whoever can fix the
> > arrow docstring).
>
> I'll claim that doughnut.
When was the last time you received one in the mail?
(more at the end...)
> This is a bit complicated. The problem is that we have to do the
> interpolation into the patch doc strings at class definition time (eg
> for Patch and Rectangle), but we can't use the object inspector and
> doc string generator artist.kwdoc to automatically generate them until
> *after* they are defined. So we have a bit of a race condition. The
> solution, which is not terribly elegant, is to define the string for
> the *classes* manually with the setting at the top of
> matplotlib.patches:
>
> artist.kwdocd['Patch'] = """\
> alpha: float
> animated: [True | False]
> antiali
>
> We interpolate this into the class docstrings. Once the classes are
> defined, we can introspect the class and auto generate the strings for
> use in *methods* that operate on class instances. At the bottom of
> patches:
>
> artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
>
> artist.kwdocd['Patch'] = patchdoc = artist.kwdoc(Patch)
> for k in ('Rectangle', 'Circle', 'RegularPolygon', 'Polygon',
> 'Wedge', 'Arrow',
> 'FancyArrow', 'YAArrow', 'CirclePolygon', 'Ellipse'):
> artist.kwdocd[k] = patchdoc
>
> so the changes you make in the kwdocd dict will affect the classes in
> matplotlib.patches, bu will not affect the docstrings in the plotting
> functions, eg matplotlib.axes.Axes.arrow, which will use the
> auto-generated version from artist.kwdoc. So you need to make your
> changes in two places: in the kwdocd dict at the top of patches, as
> you did before, *and* in the artist.kwdoc function which
> auto-generates the property tables. If this function returns rest
> tables, you will be in good shape. It is not good design to have to
> make the changes in two places, but when we implemented this we could
> not find a way to do the class doc string interpolation after the
> class was defined, but we still wanted to use the autogenerated docs
> where possible (eg in methods that handle artists like the plotting
> methods) since the auto-generated stuff is more likely to remain
> current.
>
> Maybe an entry in the developer's guide is warranted....
Thanks for the detailed explanation. I'm tagging the message so I can remember 
to include it in the developers guide. Now that I understand it, it wasn't 
too difficult to reformat the output into a ReST table. Onwards!
Darren

On Saturday 31 May 2008 12:36:11 pm John Hunter wrote:
> On Sat, May 31, 2008 at 9:19 AM, Darren Dale <dar...@co...> 
wrote:
> > I'll be working on converting docstrings to rest this weekend. Should any
> > of this be done on the branch? Or should we just focus on the trunk?
>
> As far as I am concerned, the documentation effort is for the trunk.
I would really prefer to concentrate on the trunk. There's enough work as it 
is.
Darren

On Sat, May 31, 2008 at 9:19 AM, Darren Dale <dar...@co...> wrote:
> I'll be working on converting docstrings to rest this weekend. Should any of
> this be done on the branch? Or should we just focus on the trunk?
As far as I am concerned, the documentation effort is for the trunk.
The only reason to do them on the branch too is to make merges of
other code changes easier, which may be a compelling reason. If the
docstrings get far out of whack, it may make merging other changes
very painful. But at the same time, I don't want the burden of
trying to keep the two in sync stopping you from getting the work done
that you need to do. Maybe you can try it and see how hard it is, and
if proves to be too much of an impediment, just concentrate on the
trunk. Michael, any advice here?
JDH

Rolling gtk and pygtk back to 2.10 worked.
https://sourceforge.net/project/showfiles.php?group_id=80706
I may be a little rusty on the builds, so please give them a try
before the announcement.
- Charlie
On Sat, May 31, 2008 at 12:31 PM, John Hunter <jd...@gm...> wrote:
> On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <cw...@gm...> wrote:
>> Sorry for the delay but I am running into windows/gtk problems. I am
>> getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk
>> symbols. I can't seem to find which lib they are in either. I
>> installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific
>> version of gtk? I am thinking I might have to fall back to an older
>
> We are not targeting a specific gtk version and I am not sure that we
> need to be supporting gtk in win32 anymore. I used to distribute a
> gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is
> actively using this anymore (it is part of nipy now). We could do a
> test build w/o gtk and see if anyone complains, or simply revert back
> to the last gtk version that worked for you.
>
> In any case, I don't think you should burn a lot of time on it. If
> you can get a gtk enabled win32 build, great. If not, just disable
> gtk support. Our goal is to get rid of as much gui dependent
> extension code as possible anyhow. I think we've concluded that we
> can't get rid of the tkagg extension, but for the rest of the GUIs we
> should be able to use python buffer objects. Perhaps this will
> provide some impetus to develop a pure pygtk enabled gtkagg.
>
> JDH
>

On Sat, May 31, 2008 at 9:47 AM, Charlie Moad <cw...@gm...> wrote:
> Sorry for the delay but I am running into windows/gtk problems. I am
> getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk
> symbols. I can't seem to find which lib they are in either. I
> installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific
> version of gtk? I am thinking I might have to fall back to an older
We are not targeting a specific gtk version and I am not sure that we
need to be supporting gtk in win32 anymore. I used to distribute a
gtk app on win32 that needed mpl (pbrain) but I am not sure anyone is
actively using this anymore (it is part of nipy now). We could do a
test build w/o gtk and see if anyone complains, or simply revert back
to the last gtk version that worked for you.
In any case, I don't think you should burn a lot of time on it. If
you can get a gtk enabled win32 build, great. If not, just disable
gtk support. Our goal is to get rid of as much gui dependent
extension code as possible anyhow. I think we've concluded that we
can't get rid of the tkagg extension, but for the rest of the GUIs we
should be able to use python buffer objects. Perhaps this will
provide some impetus to develop a pure pygtk enabled gtkagg.
JDH

Sorry for the delay but I am running into windows/gtk problems. I am
getting linking errors for "_gdk_draw_rgb_32_image" and two other gdk
symbols. I can't seem to find which lib they are in either. I
installed "gtk-dev-2.12.9-win32-2.exe". Do we target a specific
version of gtk? I am thinking I might have to fall back to an older
version.
- Charlie
On Fri, May 30, 2008 at 10:06 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 29, 2008 at 11:11 PM, Charlie Moad <cw...@gm...> wrote:
>> I went ahead and called it 0.98.0. I am getting a parallels image
>> updated so I can do the windows builds, but it is getting late. I
>> will get those cranked out tomorrow. The source and mac builds are up
>> though. I got two internal compiler errors on the 0.98.0 build, which
>> I fixed by replacing -O3 with -Os on those two commands only. I also
>> updated the MANIFEST.in file to include agg24 instead of agg23.
>
> Hey Charlie -- thanks for getting these two releases out. I think we
> should probably hide them, though, until the windows binaries are up,
> since it will confuse windows users who follow the link to the latest
> releases but find no binaries. So if you are more than a few hours
> away from putting up the windows installers, let's hide these until
> they are ready.
>
> Thanks,
> JDH
>

I'll be working on converting docstrings to rest this weekend. Should any of 
this be done on the branch? Or should we just focus on the trunk?

Hi Pierre,
On Friday 30 May 2008 5:21:01 pm Pierre Raybaut wrote:
> First, I would like to congratulate you for your work on Matplotlib. I
> am using Matplotlib widgets in all my current projects, embedded in PyQt
> graphical user interfaces.
>
> As you may know, PyQt 4.4.2 has been released a few days ago.
> And I found out a performance bug when embedding a Matplotlib 0.91.2
> canvas in a PyQt 4.4.2 object: the pan/zoom feature is very slow (with
> PyQt 4.3.3, and the exact same scripts, pan/zoom is real-time).
Would it be possible to post some benchmarks, something a little more 
concrete, like specifically what calls are taking the most time, and how they 
compare for the different versions of PyQt?
> I am posting this in PyQt mailing-list too, but I guess that you could
> have more ideas on that matter (Matplotlib widgets may not be used very
> often in PyQt).
Please don't do that. Its not fair to the people who volunteer their time on 
open source projects to try to draw so many people into the problem before 
the problem is understood.
Cheers,
Darren