matplotlib-devel Mailing List for matplotlib

On Sun, Feb 26, 2006 at 01:32:44PM -0600, Albert Chin wrote:
> On Sun, Feb 26, 2006 at 01:00:07AM -0600, Albert Chin wrote:
> > On Fri, Feb 24, 2006 at 12:15:29AM -0600, Albert Chin wrote:
> > > On Wed, Feb 22, 2006 at 09:24:38PM -0600, Albert Chin wrote:
> > > > 
> > > > The failure occurs when displaying the data. I've also tried
> > > > anim_tk.py to determine if it was a problem with the GTK+ backend but
> > > > anim_tk.py fails in the same way.
> > > 
> > > I did some more digging and the "terminate called after throwing an
> > > instance ..." error is coming from G++. Maybe something funk with C++
> > > exceptions on HP/PA that isn't triggered on HP/IA.
> > 
> > The throw Py::RuntimeError is coming from src/ft2font.cpp. There's a
> > global that holds information for FreeType libraries:
> >   FT_Library _ft2Library;
> > 
> > This is initialized when Python loads the module. That works fine.
> > However, sometime after, _ft2Library is reinitialized to 0. This
> > doesn't occur the _first_ time matplotlib is run. Only on subsequent
> > runs when it reads in the font cache file does this occur. Odd.
> 
> Ok, I think I found the problem. src/ft2font.cpp is used by
> _nc_backend_agg.so and ft2font.so. They _both_ have a global
> _ft2Library. This isn't good. On HP-UX/PA, it seems the _ft2Library
> from ft2font.so is used when matplotlib programs are run first.
> However, after the cache file is generated, it seems to start using
> the _ft2Library from ft2font.so but then when 'FT2Font()' is called,
> the _ft2Library from _nc_backend_agg.so is used.

src/_image.cpp is also duplicated and is a problem as well. It'll need
a similar fix.

-- 
albert chin (ch...@th...)

On Sun, Feb 26, 2006 at 01:32:44PM -0600, Albert Chin wrote:
> Another alternative is to have anything requiring src/ft2font.cpp to
> simply 'import ft2font'. For the moment, I've remove src/ft2font.cpp
> from all modules except ft2font.so. This seems to work. Patch
> attached. Should I submit patches to PyImport_ImportModule("ft2font")
> as well?

Attached is a patch to import matplotlib.ft2font from
src/_backend_agg.cpp. I chose PyRun_SimpleString() rather than
PyImport_ImportModule() so the initf2font() function would be invoked
automatically.

I'm thinking that instead of:
  FT2Font *font = static_cast<FT2Font*>(args[0].ptr());
we could use some Python calls to essentially duplicate
"FT2Font(args[0].ptr())" like so:
  PyObject *fromlist = PyList_New (1);
  PyObject *matplotlib_ft2font = PyString_FromString ("matplotlib.ft2font");
  PyList_Append (fromlist, matplotlib_ft2font);
  PyObject *ft2font = PyImport_ImportModuleEx("FT2Font", NULL, NULL,
    fromlist);
  PyObject *font = PyInstance_New (PyDict_GetItemString (ft2font,
    (char *)"FT2Font"), Py_BuildValue ("s", args[0].ptr()), NULL);
  Py_INCREF (font);

Of course, we'd have to expose the FT2Image members to Python but that
seems cleaner. The above might not be right but it should give an idea
of what I'm talking about (I've never embedded Python in C/C++
before).

-- 
albert chin (ch...@th...)

Ted Drain <ted...@jp...> writes:

> Something else that might be useful is to put a RC file version
> number in the RC file itself [...] If you're more ambitious, you can
> write RC file version converters so that older versions are
> auto-converted (and maybe even auto-updated) to the current version
> when used.

The simplest possible implementation doesn't require much: perform a
three-way merge (using e.g. diff3 or merge, if present on the system)
with the old version of the default rc file as the ancestor, and the
new default rc file and the user's rc file as the modified versions. 
If there are any conflicts, let the user handle them.

I suspect that the usual reason for getting rc warnings is that the
user neither knows nor cares about the changed options; if the options
have the old default values, it's probably safe to change them to the
new defaults.

-- 
Jouni

On Sun, Feb 26, 2006 at 01:00:07AM -0600, Albert Chin wrote:
> On Fri, Feb 24, 2006 at 12:15:29AM -0600, Albert Chin wrote:
> > On Wed, Feb 22, 2006 at 09:24:38PM -0600, Albert Chin wrote:
> > > 
> > > The failure occurs when displaying the data. I've also tried
> > > anim_tk.py to determine if it was a problem with the GTK+ backend but
> > > anim_tk.py fails in the same way.
> > 
> > I did some more digging and the "terminate called after throwing an
> > instance ..." error is coming from G++. Maybe something funk with C++
> > exceptions on HP/PA that isn't triggered on HP/IA.
> 
> The throw Py::RuntimeError is coming from src/ft2font.cpp. There's a
> global that holds information for FreeType libraries:
>   FT_Library _ft2Library;
> 
> This is initialized when Python loads the module. That works fine.
> However, sometime after, _ft2Library is reinitialized to 0. This
> doesn't occur the _first_ time matplotlib is run. Only on subsequent
> runs when it reads in the font cache file does this occur. Odd.

Ok, I think I found the problem. src/ft2font.cpp is used by
_nc_backend_agg.so and ft2font.so. They _both_ have a global
_ft2Library. This isn't good. On HP-UX/PA, it seems the _ft2Library
from ft2font.so is used when matplotlib programs are run first.
However, after the cache file is generated, it seems to start using
the _ft2Library from ft2font.so but then when 'FT2Font()' is called,
the _ft2Library from _nc_backend_agg.so is used.

What we really want is just one _ft2Library, the one from
src/ft2font.cpp. src/_nc_backend_agg.cpp does need the functions in
src/ft2font.cpp but I think _nc_backend_agg.so should depend on
ft2font.so, not load a private copy of src/ft2font.cpp and expect
cross-platform behavior wrt a duplicate global _ft2Library.

Another alternative is to have anything requiring src/ft2font.cpp to
simply 'import ft2font'. For the moment, I've remove src/ft2font.cpp
from all modules except ft2font.so. This seems to work. Patch
attached. Should I submit patches to PyImport_ImportModule("ft2font")
as well?

-- 
albert chin (ch...@th...)

John Hunter <jdh...@ac...> 
writes:

> There have been a lot of changes to the rc file of late, and I fear
> these may be getting lost on users.  It is not uncommon for me to see
> someone launch mpl and get a host of rc warnings.

It would probably help if the warnings did not merely say
"Unrecognized key bar in group foo" but something like "Option foo.bar
has been replaced by baz.quux, see release notes of version 0.87" so
the user would have some idea how to fix the problem. This wouldn't
probably require very much effort, if you are going to record the
changes somewhere in any case.

Ted Drain suggested having a version number in the rc file. How about
showing the user a brief list of release notes for all versions since
the one mentioned in the rc file?

-- 
Jouni

Hmm - I just ran your test and everything seems to work fine.  I'm using 
MPL 0.85 and Qt 3.3.5.  I did a diff of backend_qt.py and backend_qtagg.py 
from 0.85 to the current CVS repository and they're identical.  So I'm not 
sure what could be going on...

Ted

At 10:30 AM 2/26/2006, Darren Dale wrote:
>On Sunday 26 February 2006 1:06 pm, Ted Drain wrote:
> > Darren,
> > I'll have someone take a look at it soon.  We're right in the middle of a
> > big delivery so we don't really have a lot of time to spend on this right
> > now...
>
>Thanks, Ted. I'm not in a rush.
>
>I'm about to start my first python-based gui project, and want to use Qt. 
>I'll
>also continue to poke around at these problems myself as I find time.
>
>Darren
>
>
> > At 08:20 AM 2/26/2006, Darren Dale wrote:
> > >Respectfully: Is the QtAgg backend supported?
> > >
> > >On Saturday 18 February 2006 6:01 pm, Darren Dale wrote:
> > > > I'm having two problems with the QtAgg backend. If I do:
> > > > >>> from pylab import *
> > > > >>> plot([1,2])
> > > >
> > > > [<matplotlib.lines.Line2D instance at 0x2aaab1ead830>]
> > > >
> > > > >>> show()
> > > >
> > > > My figure window should be 8in x 6in, but instead it is 6in tall and as
> > > > wide as my screen will allow. So thats the first issue. The second is
> > > > this: if I close that window, and then do
> > > >
> > > > >>> plot([1,2])
> > > >
> > > > [<matplotlib.lines.Line2D instance at 0x2aaab1ebbcf8>]
> > > >
> > > > >>> show()
> > > >
> > > > I get the following traceback:
> > > >
> > > > Traceback (most recent call last):
> > > >   File "<stdin>", line 1, in ?
> > > >   File
> > > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py",
> > > > line 47, in show
> > > >     manager.window.show()
> > > > RuntimeError: underlying C/C++ object has been deleted
> > > >
> > > > I'm using qt version 3.3.4, with cvs mpl 0.86.2, on a gentoo linux
> > > > system. The only nondefault rc setting is the choice of backend.
> > > >
> > > > Darren
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > > > files for problems?  Stop!  Download the new AJAX search engine that
> > > > makes searching your log files as easy as surfing the  web.  DOWNLOAD
> > > > SPLUNK!
> > > >
> > > > _______________________________________________
> > > > Matplotlib-devel mailing list
> > > > Mat...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > >
> > >--
> > >Darren S. Dale, Ph.D.
> > >dd...@co...
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language that extends applications into web and mobile media. Attend the
> > > live webcast and join the prime developer group breaking into this new
> > > coding territory! _______________________________________________
> > >Matplotlib-devel mailing list
> > >Mat...@li...
> > >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> > that extends applications into web and mobile media. Attend the live
> > webcast and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>--
>Darren S. Dale, Ph.D.
>dd...@co...
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Something else that might be useful is to put a RC file version number in 
the RC file itself (i.e. a version on the set of RC inputs that are 
there).  This would allow MPL to check the version number of the RC file 
the user is inputting against the current number in the software.  At the 
least, this allows for an error/warning message telling someone that there 
input is out of date.  If you're more ambitious, you can write RC file 
version converters so that older versions are auto-converted (and maybe 
even auto-updated) to the current version when used.

Ted

At 09:49 AM 2/26/2006, Darren Dale wrote:
>On Friday 24 February 2006 14:57, John Hunter wrote:
> > There have been a lot of changes to the rc file of late, and I fear
> > these may be getting lost on users.  It is not uncommon for me to see
> > someone launch mpl and get a host of rc warnings.
> >
> > I think we should put these in API_CHANGES and announce them a little
> > more prominently in the release notes and on the user's list.
>
>I'm probably the guilty party here, although I have tried to make visible
>announcements on the users list and clear explanations in the CHANGELOG.
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sunday 26 February 2006 1:06 pm, Ted Drain wrote:
> Darren,
> I'll have someone take a look at it soon.  We're right in the middle of a
> big delivery so we don't really have a lot of time to spend on this right
> now...

Thanks, Ted. I'm not in a rush. 

I'm about to start my first python-based gui project, and want to use Qt. I'll 
also continue to poke around at these problems myself as I find time.

Darren


> At 08:20 AM 2/26/2006, Darren Dale wrote:
> >Respectfully: Is the QtAgg backend supported?
> >
> >On Saturday 18 February 2006 6:01 pm, Darren Dale wrote:
> > > I'm having two problems with the QtAgg backend. If I do:
> > > >>> from pylab import *
> > > >>> plot([1,2])
> > >
> > > [<matplotlib.lines.Line2D instance at 0x2aaab1ead830>]
> > >
> > > >>> show()
> > >
> > > My figure window should be 8in x 6in, but instead it is 6in tall and as
> > > wide as my screen will allow. So thats the first issue. The second is
> > > this: if I close that window, and then do
> > >
> > > >>> plot([1,2])
> > >
> > > [<matplotlib.lines.Line2D instance at 0x2aaab1ebbcf8>]
> > >
> > > >>> show()
> > >
> > > I get the following traceback:
> > >
> > > Traceback (most recent call last):
> > >   File "<stdin>", line 1, in ?
> > >   File
> > > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py",
> > > line 47, in show
> > >     manager.window.show()
> > > RuntimeError: underlying C/C++ object has been deleted
> > >
> > > I'm using qt version 3.3.4, with cvs mpl 0.86.2, on a gentoo linux
> > > system. The only nondefault rc setting is the choice of backend.
> > >
> > > Darren
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > > files for problems?  Stop!  Download the new AJAX search engine that
> > > makes searching your log files as easy as surfing the  web.  DOWNLOAD
> > > SPLUNK!
> > >
> > > _______________________________________________
> > > Matplotlib-devel mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >--
> >Darren S. Dale, Ph.D.
> >dd...@co...
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language that extends applications into web and mobile media. Attend the
> > live webcast and join the prime developer group breaking into this new
> > coding territory! _______________________________________________
> >Matplotlib-devel mailing list
> >Mat...@li...
> >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
dd...@co...

Darren,
I'll have someone take a look at it soon.  We're right in the middle of a 
big delivery so we don't really have a lot of time to spend on this right 
now...

Ted

At 08:20 AM 2/26/2006, Darren Dale wrote:
>Respectfully: Is the QtAgg backend supported?
>
>On Saturday 18 February 2006 6:01 pm, Darren Dale wrote:
> > I'm having two problems with the QtAgg backend. If I do:
> > >>> from pylab import *
> > >>> plot([1,2])
> >
> > [<matplotlib.lines.Line2D instance at 0x2aaab1ead830>]
> >
> > >>> show()
> >
> > My figure window should be 8in x 6in, but instead it is 6in tall and as
> > wide as my screen will allow. So thats the first issue. The second is this:
> > if I close that window, and then do
> >
> > >>> plot([1,2])
> >
> > [<matplotlib.lines.Line2D instance at 0x2aaab1ebbcf8>]
> >
> > >>> show()
> >
> > I get the following traceback:
> >
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> >   File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py",
> > line 47, in show
> >     manager.window.show()
> > RuntimeError: underlying C/C++ object has been deleted
> >
> > I'm using qt version 3.3.4, with cvs mpl 0.86.2, on a gentoo linux system.
> > The only nondefault rc setting is the choice of backend.
> >
> > Darren
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> > files for problems?  Stop!  Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>--
>Darren S. Dale, Ph.D.
>dd...@co...
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I'm probably the guilty party here, although I have tried
    Darren> to make visible announcements on the users list and clear
    Darren> explanations in the CHANGELOG.

You're not alone -- I am guilty too, eg splitting out the xtick and
ytick settings...  I just notice more and more that people in my group
are getting these kinds of warnings, so I thought it was worht
mentioning.

JDH

On Friday 24 February 2006 14:57, John Hunter wrote:
> There have been a lot of changes to the rc file of late, and I fear
> these may be getting lost on users.  It is not uncommon for me to see
> someone launch mpl and get a host of rc warnings.
>
> I think we should put these in API_CHANGES and announce them a little
> more prominently in the release notes and on the user's list.

I'm probably the guilty party here, although I have tried to make visible 
announcements on the users list and clear explanations in the CHANGELOG.

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, I updated from CVS, made a one-line change to
    Eric> contour.py to add alpha support, and tested using
    Eric> contour_demo.py from bash shell--and found that with linux
    Eric> default gtk-agg backend, the gtk.main() doesn't return when
    Eric> the plot window is closed.  I have to Ctl-C to get out.

Steve's recent change should fix your problem -- it was my bad.

JDH

Respectfully: Is the QtAgg backend supported?

On Saturday 18 February 2006 6:01 pm, Darren Dale wrote:
> I'm having two problems with the QtAgg backend. If I do:
> >>> from pylab import *
> >>> plot([1,2])
>
> [<matplotlib.lines.Line2D instance at 0x2aaab1ead830>]
>
> >>> show()
>
> My figure window should be 8in x 6in, but instead it is 6in tall and as
> wide as my screen will allow. So thats the first issue. The second is thi=
s:
> if I close that window, and then do
>
> >>> plot([1,2])
>
> [<matplotlib.lines.Line2D instance at 0x2aaab1ebbcf8>]
>
> >>> show()
>
> I get the following traceback:
>
> Traceback (most recent call last):
> =A0 File "<stdin>", line 1, in ?
> =A0 File
> "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py",
> line 47, in show
> =A0 =A0 manager.window.show()
> RuntimeError: underlying C/C++ object has been deleted
>
> I'm using qt version 3.3.4, with cvs mpl 0.86.2, on a gentoo linux system.
> The only nondefault rc setting is the choice of backend.
>
> Darren
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

=2D-=20
Darren S. Dale, Ph.D.
dd...@co...

On Saturday 25 February 2006 8:01 pm, Andrew Straw wrote:
> Hi All,
>
> It looks like SourceForge has (finally) adopted site-wide subversion
> repositories: http://sourceforge.net/docs/E09/
>
> What do people feel about migrating from CVS to svn? SourceForge
> apparently even has an automated tool to do so. They also state that
> there will be no more delays between developer access and anonymous access.
>
> Personally I'm +1 on switching -- matplotlib is the only project I keep
> up with that still uses CVS.

+1 for switching.

On Fri, Feb 24, 2006 at 12:15:29AM -0600, Albert Chin wrote:
> On Wed, Feb 22, 2006 at 09:24:38PM -0600, Albert Chin wrote:
> > 
> > The failure occurs when displaying the data. I've also tried
> > anim_tk.py to determine if it was a problem with the GTK+ backend but
> > anim_tk.py fails in the same way.
> 
> I did some more digging and the "terminate called after throwing an
> instance ..." error is coming from G++. Maybe something funk with C++
> exceptions on HP/PA that isn't triggered on HP/IA.

The throw Py::RuntimeError is coming from src/ft2font.cpp. There's a
global that holds information for FreeType libraries:
  FT_Library _ft2Library;

This is initialized when Python loads the module. That works fine.
However, sometime after, _ft2Library is reinitialized to 0. This
doesn't occur the _first_ time matplotlib is run. Only on subsequent
runs when it reads in the font cache file does this occur. Odd.

-- 
albert chin (ch...@th...)

I can't speak about switchers using the SourceForge site, since it's
only been recently they've offered subversion. Here are various projects
I know about and their histories:

Python - switched to svn from cvs some time ago, (I think) dropping
SourceForge hosting of their repository in the process. I'm not close to
the development process, but as an occasional source-tree grabber and
c.l.py reader, I didn't hear of any issues.

numpy/scipy - switched to svn from cvs several months ago (September?).
there were some initial problems converting the history with the cvs2svn
script, but I think they were worked out, perhaps with the help of the
subversion developers. as far as I know, there have been no issues with
svn itself once the history was converted.

ipython - I think they are very pleased with subversion. They're
maintaining one branch and actively developing next generation ipython
(what will hopefully become v1) in another.

Personally, the biggest win for me with subversion is that I can do "svn
diff" and it's nearly instant -- no network access is needed. It would
also be nice to finally be rid of the asynchronous developer vs.
anonymous access that sourceforge's cvs solution entails.

Cheers!
Andrew

Eric Firing wrote:

> Andrew Straw wrote:
>
>> Hi All,
>>
>> It looks like SourceForge has (finally) adopted site-wide subversion
>> repositories: http://sourceforge.net/docs/E09/
>>
>> What do people feel about migrating from CVS to svn? SourceForge
>> apparently even has an automated tool to do so. They also state that
>> there will be no more delays between developer access and anonymous
>> access.
>>
>> Personally I'm +1 on switching -- matplotlib is the only project I keep
>> up with that still uses CVS.
>>
>> Cheers!
>> Andrew
>
>
> Andrew,
>
> I don't mind switching; I installed svn on my main machine some time
> ago so I could grab numpy, so I presume that using it for mpl will not
> be difficult.  Do you know what the experience has been in other
> projects that have switched?  Everything smooth?  Or a week or two of
> chaos?
>
> Eric

Andrew Straw wrote:
> Hi All,
> 
> It looks like SourceForge has (finally) adopted site-wide subversion
> repositories: http://sourceforge.net/docs/E09/
> 
> What do people feel about migrating from CVS to svn? SourceForge
> apparently even has an automated tool to do so. They also state that
> there will be no more delays between developer access and anonymous access.
> 
> Personally I'm +1 on switching -- matplotlib is the only project I keep
> up with that still uses CVS.
> 
> Cheers!
> Andrew

Andrew,

I don't mind switching; I installed svn on my main machine some time ago 
so I could grab numpy, so I presume that using it for mpl will not be 
difficult.  Do you know what the experience has been in other projects 
that have switched?  Everything smooth?  Or a week or two of chaos?

Eric

Eric Firing wrote:
> John,
> 
> I updated from CVS, made a one-line change to contour.py to add alpha 
> support, and tested using contour_demo.py from bash shell--and found 
> that with linux default gtk-agg backend, the gtk.main() doesn't return 
> when the plot window is closed.  I have to Ctl-C to get out.
> 
> Eric


John,

The following patch fixes the problem for me, and makes sense to me:

Index: backend_gtk.py
===================================================================
RCS file: 
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py,v
retrieving revision 1.123
diff -u -r1.123 backend_gtk.py
--- backend_gtk.py      24 Feb 2006 20:00:28 -0000      1.123
+++ backend_gtk.py      26 Feb 2006 02:30:42 -0000
@@ -76,8 +76,8 @@
          manager.window.show()

      if mainloop and gtk.main_level() == 0:
-        gtk.main()
          show._mainloop = True
+        gtk.main()
  show._mainloop = False

  def new_figure_manager(num, *args, **kwargs):


You have show._mainloop = True after the call to gtk.main(), but that 
doesn't return; when the windows are deleted, the mainloop is still 
running but the flag has not been set, so deleting the last window does 
not end the loop.  So the obvious solution (above) is to set the flag 
before calling gtk.main()

I was about to simply make the change, but decided to leave it to you, 
since I don't understand the bug you were trying to fix in the first 
place.  Maybe some sort of locking is actually needed to make sure 
nothing unexpected can happen in another thread between the setting of 
the flag and the call to gtk.main().

Eric

Hi All,

It looks like SourceForge has (finally) adopted site-wide subversion
repositories: http://sourceforge.net/docs/E09/

What do people feel about migrating from CVS to svn? SourceForge
apparently even has an automated tool to do so. They also state that
there will be no more delays between developer access and anonymous access.

Personally I'm +1 on switching -- matplotlib is the only project I keep
up with that still uses CVS.

Cheers!
Andrew