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

Hi all,
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).
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).
Thanks for your help!
Regards,
Pierre Raybaut

On Friday 30 May 2008 10:51:50 am John Hunter wrote:
> On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <md...@st...> wrote:
> > FYI: I have a little time today to do some documentation work myself
> > today. I've been doing some minor edits (mostly formatting things) on the
> > developer docs, and then was going to hit up the user docs. Does that
> > step on your toes / duplicate effort? Anywhere where you think I would
> > be more useful?
I am planning on converting docstrings this weekend. We should keep everyone 
posted of what we are working on though, with so much to do, it would be a 
shame to duplicate effort.
Perhaps we should temporarily copy the users guide and htdocs into the doc 
directory on the trunk. When someone is working on converting a section in 
the users guide or an html file, he can add his name to the top of the file, 
and then delete the file when done. That way we slowly delete the old docs 
and can be sure we converted everything.
> Three areas that you are the residing expert on are fonts, mathtext
> and transformations, so user's guide chapters on these would be great.
>
> In addition, one place where we can all make small, frequent
> contributions is in the new faq section. Much of the stuff on the web
> is out of date. When we answer questions on the mailing list that
> recur, with 5 minutes of extra work, could put an entry in the FAQ
> (user interface specific stuff, font stuff, install problems, seg
> faults, web app server...).
Sounds good.

On Fri, May 30, 2008 at 9:12 AM, Michael Droettboom <md...@st...> wrote:
> FYI: I have a little time today to do some documentation work myself today.
> I've been doing some minor edits (mostly formatting things) on the
> developer docs, and then was going to hit up the user docs. Does that step
> on your toes / duplicate effort? Anywhere where you think I would be more
> useful?
Three areas that you are the residing expert on are fonts, mathtext
and transformations, so user's guide chapters on these would be great.
In addition, one place where we can all make small, frequent
contributions is in the new faq section. Much of the stuff on the web
is out of date. When we answer questions on the mailing list that
recur, with 5 minutes of extra work, could put an entry in the FAQ
(user interface specific stuff, font stuff, install problems, seg
faults, web app server...).

Hi,
John Hunter wrote:
> I've done a fair amount of testing on the branch (0.91.3),
> particularly looking at all the PDF and SVG output from backend
> driver, and these backends are in the best shape I've ever seen them.
> [...]
> I think we should take a crack at fixing these since the branch is
> otherwise in such good shape that we could perhaps go a long time w/o
> another maintenance release.
Before the branches and releases are all frozen for the foreseeable
future, I might mention a minor but long-lived bug that has been
around since at least the end of 2006... Please excuse me if this is
old news, as I haven't checked the archives recently for any progress
on this. I've noticed that the bug is still around in r5314 of trunk.
On Mac OS X (both Tiger and Leopard), there is a small misalignment
between grid lines and tick marks on the standard plot (as well as
loglog and semilog) with the PS backend. I did not check which one of
the lines is in the correct place. The problem does not occur with the
PDF backend.
I attach a ps and pdf file produced by the following snippet:
import pylab as pl
pl.plot([1,2,3,4,5])
pl.grid()
pl.savefig('grid_misaligned_with_ticks.ps')
pl.savefig('grid_misaligned_with_ticks.pdf')
The pdf file is fine, but the ps file shows a misalignment. To view
this in Mac OS X, I used Preview (which converts the PS to PDF first).
To eliminate Preview as the problem, I also saved the file as an EPS
and used epstopdf from MacTeX to convert it for Preview. Viewed on
Linux with acroread, the PS file produced on the Mac also shows
misalignment (I haven't verified this recently).
The same code snippet produces no problems on Linux.
I realise this might not be a problem with matplotlib itself, but I'm
just curious if anyone picked it up and whether it is fixable before
the next release.
Thanks!
Ludwig

Done.
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
>

Darren Dale wrote:
> On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
> 
>> Darren Dale wrote:
>> 
>>> I'm sorry, I just don't understand how to use this.
>>> 
>
> And I'm also sorry for my mild panic attack yesterday. I had way too many 
> things coming at me all at once. Things are back to normal today.
> 
I know I've been there, and I completely understand. Sorry I was trying 
to "teach to fish" rather than just "giving you a bloody fish, already" 
in the midst of that... ;)
> 
>> I can do the merge for you.
>>
>> [mdroe@wonkabar matplotlib]$ svn update
>> U lib/matplotlib/ticker.py
>> U CHANGELOG
>> Updated to revision 5299.
>> [mdroe@wonkabar matplotlib]$ svnmerge merge
>> U CHANGELOG
>> C lib/matplotlib/texmanager.py
>> C lib/matplotlib/backends/backend_svg.py
>>
>> property 'svnmerge-integrated' set on '.'
>>
>> # We don't want to merge backend_svg.py -- we just want what's currently
>> on the trunk
>> [mdroe@wonkabar matplotlib]$ cp
>> lib/matplotlib/backends/backend_svg.py.working
>> lib/matplotlib/backends/backend_svg.py
>>
>> # Manually resolve texmanager.py
>> [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py
>>
>> # Mark everything as resolved
>> [mdroe@wonkabar matplotlib]$ svn -R resolved .
>> Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'
>>
>> # Commit
>> [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt
>> Sending .
>> Sending CHANGELOG
>> Sending lib/matplotlib/texmanager.py
>> Transmitting file data ..
>> Committed revision 5300.
>> [mdroe@wonkabar matplotlib]$
>> 
>
> Thanks for posting this. I'll take a sweep through the bug tracker this 
> weekend, and see if I can do this myself. I'll be working on documentation 
> this weekend, I'll add a section on merging to the documentation once I can 
> do it on my own.
> 
There is a little blurb on merging already in the coding guidelines, but 
it would be great to have it expanded by someone while it's still a 
fresh experience.
FYI: I have a little time today to do some documentation work myself 
today. I've been doing some minor edits (mostly formatting things) on 
the developer docs, and then was going to hit up the user docs. Does 
that step on your toes / duplicate effort? Anywhere where you think I 
would be more useful?
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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

On Thursday 29 May 2008 10:59:40 am Michael Droettboom wrote:
> Darren Dale wrote:
> > I'm sorry, I just don't understand how to use this.
And I'm also sorry for my mild panic attack yesterday. I had way too many 
things coming at me all at once. Things are back to normal today.
> I can do the merge for you.
>
> [mdroe@wonkabar matplotlib]$ svn update
> U lib/matplotlib/ticker.py
> U CHANGELOG
> Updated to revision 5299.
> [mdroe@wonkabar matplotlib]$ svnmerge merge
> U CHANGELOG
> C lib/matplotlib/texmanager.py
> C lib/matplotlib/backends/backend_svg.py
>
> property 'svnmerge-integrated' set on '.'
>
> # We don't want to merge backend_svg.py -- we just want what's currently
> on the trunk
> [mdroe@wonkabar matplotlib]$ cp
> lib/matplotlib/backends/backend_svg.py.working
> lib/matplotlib/backends/backend_svg.py
>
> # Manually resolve texmanager.py
> [mdroe@wonkabar matplotlib]$ emacs -nw lib/matplotlib/texmanager.py
>
> # Mark everything as resolved
> [mdroe@wonkabar matplotlib]$ svn -R resolved .
> Resolved conflicted state of 'lib/matplotlib/backends/backend_svg.py'
>
> # Commit
> [mdroe@wonkabar matplotlib]$ svn commit -F svnmerge-commit-message.txt
> Sending .
> Sending CHANGELOG
> Sending lib/matplotlib/texmanager.py
> Transmitting file data ..
> Committed revision 5300.
> [mdroe@wonkabar matplotlib]$
Thanks for posting this. I'll take a sweep through the bug tracker this 
weekend, and see if I can do this myself. I'll be working on documentation 
this weekend, I'll add a section on merging to the documentation once I can 
do it on my own.
Darren

 Yeah. I am totally updated with 10.5.3 and the latest dev tools.
 They have been talked about for a while on the list, but I just
wanted to record what I ran into during the builds. I'll reproduce
those errors after I get the windows builds done tonight and shoot
them this way.
- Charlie
On Fri, May 30, 2008 at 8:19 AM, Michael Droettboom <md...@st...> wrote:
> Were the internal compiler errors on the Mac? Can you share them? It would
> be nice to work around these in a cleaner way if possible.
>
> Cheers,
> Mike
>
> Charlie Moad 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.
>>
>> - Charlie
>>
>> On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote:
>>
>>>
>>> On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
>>>
>>>>
>>>> Just to confirm, I should use the version tag, "0.98pre"?
>>>>
>>>
>>> My preference is to call it 0.98.0 unless Michael is feeling extra
>>> cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
>>> ...
>>>
>>> JDH
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

Were the internal compiler errors on the Mac? Can you share them? It 
would be nice to work around these in a cleaner way if possible.
Cheers,
Mike
Charlie Moad 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.
>
> - Charlie
>
> On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote:
> 
>> On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
>> 
>>> Just to confirm, I should use the version tag, "0.98pre"?
>>> 
>> My preference is to call it 0.98.0 unless Michael is feeling extra
>> cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
>> ...
>>
>> JDH
>>
>> 
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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.
- Charlie
On Thu, May 29, 2008 at 10:06 PM, John Hunter <jd...@gm...> wrote:
> On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
>> Just to confirm, I should use the version tag, "0.98pre"?
>
> My preference is to call it 0.98.0 unless Michael is feeling extra
> cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
> ...
>
> JDH
>

On Thu, May 29, 2008 at 5:44 PM, Charlie Moad <cw...@gm...> wrote:
> Just to confirm, I should use the version tag, "0.98pre"?
My preference is to call it 0.98.0 unless Michael is feeling extra
cautious. In which case we can call it 0.98pre or 0.98rc1 or whatever
...
JDH

Michael Droettboom wrote:
> John Hunter wrote:
> 
>> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> wrote:
>>
>> 
>> 
>>> Minor point: On my machine at least, I don't have to manually clean up the
>>> conflict files -- they are removed for me on the next commit. Those files
>>> are really just for reference. If you use a SVN frontend for diffing (such
>>> as psvn.el or meld) they are largely unnecessary.
>>> 
>>> 
>> On my machine I do need to manually purge these -- svn commit will
>> fail with a message like
>>
>> johnh@flag:mpl> svn commit -F svnmerge-commit-message.txt
>> svn: Commit failed (details follow):
>> svn: Aborting commit:
>> '/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
>> remains in conflict
>>
>>
>> even if I have manually edited out all the conflicts. 
>> 
> Oh -- it appears that "svn resolved" is what does this, not "svn 
> commit". I didn't realise that just deleting the files was enough and 
> have always used "svn resolved" as a matter of course. The convenient 
> thing about "svn resolved" is you can do "svn -R resolved ." to resolve 
> the whole tree once you're sure you're done.
> 
>> I then need to do
>>
>> johnh@flag:mpl> rm lib/matplotlib/image.py.*
>>
>> Maybe one of your emacs modes is helping you out behind the scenes?
>> Can you send me your emacs configs for svn?
>> 
>> 
>
> I use psvn.el, which is far easier to use IMHO than the built-in 
> pcl-svn. You can get it here -- I haven't set any customizations on it.
> 
I lied. There is one keyboard mapping I added that I've found pretty 
useful:
(global-set-key (kbd "s-s") 'svn-status-switch-to-status-buffer)
(define-key svn-status-mode-map (kbd "s-s") 'svn-status-bury-buffer)
This lets me toggle between the file I'm editing and the svn-status 
buffer using "Super-s" (Windows key-s). Makes it very convenient to 
edit a file, check the differences against the repository, and check 
them in.
Cheers,
Mike

John Hunter wrote:
> On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> wrote:
>
> 
>> Minor point: On my machine at least, I don't have to manually clean up the
>> conflict files -- they are removed for me on the next commit. Those files
>> are really just for reference. If you use a SVN frontend for diffing (such
>> as psvn.el or meld) they are largely unnecessary.
>> 
>
> On my machine I do need to manually purge these -- svn commit will
> fail with a message like
>
> johnh@flag:mpl> svn commit -F svnmerge-commit-message.txt
> svn: Commit failed (details follow):
> svn: Aborting commit:
> '/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
> remains in conflict
>
>
> even if I have manually edited out all the conflicts. 
Oh -- it appears that "svn resolved" is what does this, not "svn 
commit". I didn't realise that just deleting the files was enough and 
have always used "svn resolved" as a matter of course. The convenient 
thing about "svn resolved" is you can do "svn -R resolved ." to resolve 
the whole tree once you're sure you're done.
> I then need to do
>
> johnh@flag:mpl> rm lib/matplotlib/image.py.*
>
> Maybe one of your emacs modes is helping you out behind the scenes?
> Can you send me your emacs configs for svn?
> 
I use psvn.el, which is far easier to use IMHO than the built-in 
pcl-svn. You can get it here -- I haven't set any customizations on it.
http://www.xsteve.at/prg/vc_svn/
My favorite feature is the integration with ediff -- press 'E' in the 
svn-status buffer and it brings up an ediff session between your working 
copy and the SVN revision it came from.
Cheers,
Mike

Just to confirm, I should use the version tag, "0.98pre"?
- Charlie
On Thu, May 29, 2008 at 1:09 PM, John Hunter <jd...@gm...> wrote:
> On Wed, May 28, 2008 at 8:30 PM, Charlie Moad <cw...@gm...> wrote:
>> Should we still proceed with this now that numpy 1.1.0 is out? Any holdups?
>
> We are now ready to do 0.98pre -- fire when ready Charlie.
>
> JDH
>

For those of you who haven't had the pleasure of seeing Michael's
spline paths in action, I added a new interactive demo on the trunk:
 examples/event_handling/path_editor.py
Click and drag the vertices to edit the spline path. It needs some
more work - eg I want to be able to add and delete vertices, which
means tracking groups (all related CURVE4 vertices for example) and
the ability to add a curve4, lineto, eg... But with a little work
we'll have inkscape-lite. Just need to add some load/save features...
JDH

On Thu, May 29, 2008 at 9:49 AM, Michael Droettboom <md...@st...> wrote:
> Minor point: On my machine at least, I don't have to manually clean up the
> conflict files -- they are removed for me on the next commit. Those files
> are really just for reference. If you use a SVN frontend for diffing (such
> as psvn.el or meld) they are largely unnecessary.
On my machine I do need to manually purge these -- svn commit will
fail with a message like
 johnh@flag:mpl> svn commit -F svnmerge-commit-message.txt
 svn: Commit failed (details follow):
 svn: Aborting commit:
'/home/titan/johnh/python/svn/matplotlib.trunk/matplotlib/lib/matplotlib/image.py'
remains in conflict
even if I have manually edited out all the conflicts. I then need to do
 johnh@flag:mpl> rm lib/matplotlib/image.py.*
Maybe one of your emacs modes is helping you out behind the scenes?
Can you send me your emacs configs for svn?
JDH