matplotlib-devel Mailing List for matplotlib

John Hunter a écrit :
> It would have been smart to tag CVS before the migration so that we
> could run a diff against the tagged version and then just apply the
> diff to svn. Oh well, I'll have to remember that for next time.
You can still make a cvs diff between two dates if you know when the 
switch to the SVN occured.
-- 
 .''`. Aurelien Jarno	 | GPG: 1024D/F1BCDB73
 : :' : Debian developer | Electrical Engineer
 `. `' au...@de... | aur...@au...
 `- people.debian.org/~aurel32 | www.aurel32.net

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> I meant no more commits to cvs, but I sent that before I
 Charlie> saw the "CVS is dead" comment. So please just ignore me!
 Charlie> ;)
OK, I did just add a cvs_dead tag to CVS in case anyone makes a commit
to the wrong place and we want to grab a diff.
JDH

I meant no more commits to cvs, but I sent that before I saw the "CVS
is dead" comment. So please just ignore me! ;)
On 2/28/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Charlie" =3D=3D Charlie Moad <cw...@gm...> writes:
>
> Charlie> I saw quite a few updates this morning in cvs as well.
> Charlie> Should we declare a code freeze at some point?
>
> Could you email everyone who made a commit to CVS and let them know
> that those changes need to go into the svn repository instead, with
> all due apologies. I'm not sure what you mean about a code freeze.
>
> It would have been smart to tag CVS before the migration so that we
> could run a diff against the tagged version and then just apply the
> diff to svn. Oh well, I'll have to remember that for next time.
>
> JDH
>

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> None necessary. However, could you post an example of how
 Darren> to do a dev checkout? I thought I had followed the
 Darren> instructions, but commit is asked for a password for the
I did
svn co --username=jdh2358 --password=mypass https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
and then I could make commits with no prompting.
JDH

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> I saw quite a few updates this morning in cvs as well.
 Charlie> Should we declare a code freeze at some point?
Could you email everyone who made a commit to CVS and let them know
that those changes need to go into the svn repository instead, with
all due apologies. I'm not sure what you mean about a code freeze.
It would have been smart to tag CVS before the migration so that we
could run a diff against the tagged version and then just apply the
diff to svn. Oh well, I'll have to remember that for next time.
JDH

I saw quite a few updates this morning in cvs as well. Should we
declare a code freeze at some point?
On 2/28/06, Darren Dale <dd...@co...> wrote:
> I have a some changes that I would like to commit. When is it ok to do so=
?
>
> Darren
>
> On Monday 27 February 2006 15:44, John Hunter wrote:
> > >>>>> "Andrew" =3D=3D Andrew Straw <str...@as...> writes:
> >
> > Andrew> Yes, tags, too.
> >
> > The migration is complete
> >
> > # what most people will want
> > svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotli=
b
> >
> > # the toolkits, eg basemap
> > svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits
> >
> > # the source code for the website
> > svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/htdocs
> >
> > # the source code for the user's guide
> > svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/users_gui=
de
> >
> > Not sure what is up with the hhtps/SSL -- on at least one platform I
> > get
> >
> > > svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplot=
lib
> >
> > svn: SSL is not supported
> >
> > Apparently on this machine SSL support wasn't built into svn. Any
> > ideas if we can get non-ssl checkouts from sourceforge?
> >
> > But it did build and I was able to commit -- woohoo!
> >
> > matplotlib> svn commit --username=3Djdh2358 -m 'trying to commit'
> > Authentication realm: <https://svn.sourceforge.net:443> SourceForge
> > Subversion area Password for 'jdh2358':
> > Sending CHANGELOG
> > Transmitting file data .
> > Committed revision 2100.
> >
> > CVS is dead! Long live svn!
> >
> > JDH
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> > that extends applications into web and mobile media. Attend the live
> > webcast and join the prime developer group breaking into this new codin=
g
> > territory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> --
> Darren S. Dale, Ph.D.
> Cornell High Energy Synchrotron Source
> Cornell University
> 200L Wilson Lab
> Rt. 366 & Pine Tree Road
> Ithaca, NY 14853
>
> dd...@co...
> office: (607) 255-9894
> fax: (607) 255-9001
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tuesday 28 February 2006 10:21, you wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> I have a some changes that I would like to commit. When is
> Darren> it ok to do so? Darren
>
> The svn repository is live, so fire away. The CVS tree is dead.
>
> I should have paid more attention to Andrew's suggestion to make sure
> everyone got their CVS tree in before the migration, but I was so
> excited when I saw it was a simple button push that I got ahead of
> myself, so apologies for any inconvenience.
None necessary. However, could you post an example of how to do a dev 
checkout? I thought I had followed the instructions, but commit is asked for 
a password for the wrong username. When that failed, it asked for a username 
and then a password, so I was able to commit, but I would like to get this 
working the right way.
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I have a some changes that I would like to commit. When is
 Darren> it ok to do so? Darren
The svn repository is live, so fire away. The CVS tree is dead.
I should have paid more attention to Andrew's suggestion to make sure
everyone got their CVS tree in before the migration, but I was so
excited when I saw it was a simple button push that I got ahead of
myself, so apologies for any inconvenience.
JDH

I have a some changes that I would like to commit. When is it ok to do so?
Darren
On Monday 27 February 2006 15:44, John Hunter wrote:
> >>>>> "Andrew" == Andrew Straw <str...@as...> writes:
>
> Andrew> Yes, tags, too.
>
> The migration is complete
>
> # what most people will want
> svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
>
> # the toolkits, eg basemap
> svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits
>
> # the source code for the website
> svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/htdocs
>
> # the source code for the user's guide
> svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/users_guide
>
> Not sure what is up with the hhtps/SSL -- on at least one platform I
> get
>
> > svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
>
> svn: SSL is not supported
>
> Apparently on this machine SSL support wasn't built into svn. Any
> ideas if we can get non-ssl checkouts from sourceforge?
>
> But it did build and I was able to commit -- woohoo!
>
> matplotlib> svn commit --username=jdh2358 -m 'trying to commit'
> Authentication realm: <https://svn.sourceforge.net:443> SourceForge
> Subversion area Password for 'jdh2358':
> Sending CHANGELOG
> Transmitting file data .
> Committed revision 2100.
>
> CVS is dead! Long live svn!
>
> JDH
>
>
> -------------------------------------------------------
> 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.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> The migration is complete
Heads up warning -- in the initial conversion apparently some of the
binary files were corrupt (fonts, toolbar icons). I fixed these for
fonts and icons, but there are other areas that may need
fixing, particularly any basemap binary datafiles may be corrupted, as
well as other example data used in examples/data, the htdocs and
users_guide figures.
JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Yes, tags, too.
The migration is complete
 # what most people will want
 svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib 
 # the toolkits, eg basemap
 svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits
 
 # the source code for the website
 svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/htdocs
 
 # the source code for the user's guide
 svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/users_guide
 
Not sure what is up with the hhtps/SSL -- on at least one platform I
get
 > svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
 svn: SSL is not supported
Apparently on this machine SSL support wasn't built into svn. Any
ideas if we can get non-ssl checkouts from sourceforge?
But it did build and I was able to commit -- woohoo!
matplotlib> svn commit --username=jdh2358 -m 'trying to commit'
Authentication realm: <https://svn.sourceforge.net:443> SourceForge Subversion area
Password for 'jdh2358':
Sending CHANGELOG
Transmitting file data .
Committed revision 2100.
CVS is dead! Long live svn!
JDH

Albert Chin wrote:
>On Mon, Feb 27, 2006 at 09:45:34AM -0800, Andrew Straw wrote:
>
>>I propose the following structure, which we could implement as the first
>>commits of the subversion repository once the CVS data is installed.
>>
>>matplotlib/ (top level)
>> branches/ (empty for now)
>> trunk/
>> setup.py
>> lib/
>> (and so on)
>>
>
>What about tags?
> tags/
> 0.87
> 0.87.1
> 0.88
> ...
>
>
Yes, tags, too.
I've gone ahead and created a test subversion repository on my local
machine. Everything looks OK. It looks like the new checkout string to
get matplotlib (and not toolkits, htdocs, and users_guide) would be
something like "svn co http://path.to/repos trunk/matplotlib matplotlib".
You probably don't want to check out the tags directory -- 3.4 are
generated on your disk then!
Here's the top-level layout created directly by cvs2svn. Sorry I didn't
have time to format this nicely.
astraw@hdmg:~/tmp/MPL/svn_co/mpl.svn$ ls
branches tags trunk
astraw@hdmg:~/tmp/MPL/svn_co/mpl.svn$ ls branches/
jdhunter vendor
astraw@hdmg:~/tmp/MPL/svn_co/mpl.svn$ ls tags/
basemap_v0_1_1 v0_2_1 v0_4_2 v0_61 v0_62_2 v0_7 v0_8 v0_86_2
post_numerix v0_3 v0_4_3 v0_6_1 v0_62_3 v0_70 v0_80 v0_87
pre_numerix v0_3_1 v0_5 v0_61_0 v0_62_4 v0_71 v0_8_1
release-0-1 v0_3_2 v0_5_1 v0_6_1b v0_63_0 v0_7_1 v0_82
start v0_3_3 v0_5_2 v0_6_2 v0_64 v0_72 v0_83_2
v0_1_2 v0_4 v0_6 v0_62_0 v0_65 v0_73 v0_86
v0_2 v0_4_1 v0_60_2 v0_62_1 v0_65_1 v0_74 v0_86_1
astraw@hdmg:~/tmp/MPL/svn_co/mpl.svn$ ls trunk/
course CVSROOT htdocs matplotlib toolkits users_guide
astraw@hdmg:~/tmp/MPL/svn_co/mpl.svn$ ls trunk/matplotlib/
agg23 examples KNOWN_BUGS MANIFEST setupext.py
API_CHANGES fonts lib MANIFEST.in setup.py
boilerplate.py images license matplotlibrc.template src
CHANGELOG __init__.py license.py NUMARRAY_ISSUES swig
CXX INSTALL Makefile README TODO
DEVNOTES INTERACTIVE makeswig.py setupegg.py unit

Hi all,
I will endeavor to switch matplotlib to a subversion repository (newly
available courtesy of SourceForge) tomorrow afternoon/evening
(US/Pacific time) unless I hear pleas from developers with unmerged changes.
I believe the new command for anonymous checkout of matplotlib will be:
svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib
I'll post the developer checkout command on the matplotlib-devel list
when I figure it out.
Cheers!
Andrew

On Mon, Feb 27, 2006 at 09:45:34AM -0800, Andrew Straw wrote:
> I propose the following structure, which we could implement as the first
> commits of the subversion repository once the CVS data is installed.
> 
> matplotlib/ (top level)
> branches/ (empty for now)
> trunk/
> setup.py
> lib/
> (and so on)
What about tags?
 tags/
 0.87
 0.87.1
 0.88
 ...
-- 
albert chin (ch...@th...)

On Mon, Feb 27, 2006 at 10:23:12AM -0600, John Hunter wrote:
> >>>>> "Albert" == Albert Chin <mat...@ml...> writes:
> 
> Albert> The problem is duplicate function names. An error occurs
> Albert> because set_bg() is contained in more than one loadable
> Albert> module, and the wrong one is selected at
> Albert> runtime. examples/image_demo.py won't run because Python
> Albert> gives an AttributeError in lib/matplotlib/image.py, line
> Albert> 141: im.set_bg( *bg)
> 
> I'm confused here. The only extension code that defines set_bg is the
> _image module
But src/_image.cpp is built into _n?_backend_agg.so and _n?_image.so.
We really don't want duplicate symbols in loadable modules if they
will be loaded at once.
> johnh@jitter:src> grep set_bg *.h
> _image.h: Py::Object set_bg(const Py::Tuple& args);
> _image.h: static char set_bg__doc__[];
> 
> I don't see why you should be having a problem with this. Can you
> submit a complete traceback?
$ python image_demo.py
Traceback (most recent call last):
 File "image_demo.py", line 14, in ?
 savefig('image_demo')
 File "/tmp/m/matplotlib/pylab.py", line 839, in savefig
 return fig.savefig(*args, **kwargs)
 File "/tmp/m/matplotlib/figure.py", line 654, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/tmp/m/matplotlib/backends/backend_gtkagg.py", line 111, in print_figure
 agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
 File "/tmp/m/matplotlib/backends/backend_agg.py", line 447, in print_figure
 self.draw()
 File "/tmp/m/matplotlib/backends/backend_agg.py", line 384, in draw
 self.figure.draw(renderer)
 File "/tmp/m/matplotlib/figure.py", line 529, in draw
 for a in self.axes: a.draw(renderer)
 File "/tmp/m/matplotlib/axes.py", line 1420, in draw
 im.draw(renderer)
 File "/tmp/m/matplotlib/image.py", line 206, in draw
 im = self.make_image()
 File "/tmp/m/matplotlib/image.py", line 141, in make_image
 im.set_bg( *bg)
AttributeError: set_bg
The AttributeError is kinda odd though. If I print 'im', I get:
 <Image object at 0x40cdd374>
Regardless of whether or not Image is picked from _na_backend_agg.so
or _na_image.so, you'd think im.set_bg() would be available. However,
removing the duplicate src/_image.cpp file from being included in
_n?_backend_agg.so solved things.
> Albert> Also, src/mplutils.cpp is included multiple times but I
> Albert> haven't encountered any errors because of this yet.
> 
> This shouldn't pose a problem as long as there isn't a global
> variable, right? My understanding is that the ft2font problem arises
> because of the use of the global FT_Library _ft2Library .
_image.o is linked into _n?_backend_agg.so and _n?_image.so. Both will
be loaded at runtime.
I don't think the problem is limited to global variables. Rather, I'd
say duplicate symbols. According to one of the GCC developers (who
specializes in HP-UX/PA):
 When a weak symbol is linked into a shared library, it becomes a
 strong global symbol. So, if the symbol appears in more than one
 shared object, then you can can get the problem that you found. This
 is one area where the HP linker differs from the SYSV ABI. The other
 is in the handling of undefined weak symbols.
The default object file format on HP-UX/PA is SOM, not ELF. HP-UX/IA
is ELF and HP-UX/PA 64-bit is ELF.
-- 
albert chin (ch...@th...)

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Great! I'm unable to do it myself (I lack admin rights),
I updated your permissions -- you are now fully enabled -- and
submitted a migration request just using the default options.
Once the migration is complete, you can do your proposed
reorganization and then let us know what we've got :-)
 Andrew> I propose the following structure, which we could
 Andrew> implement as the first commits of the subversion
 Andrew> repository once the CVS data is installed.
 Andrew> matplotlib/ (top level) branches/ (empty for now) trunk/
 Andrew> setup.py lib/ (and so on)
 Andrew> This will make life easier down the track when we want to
 Andrew> make branches and will allow checkouts of just the trunk
 Andrew> with: svn co
 Andrew> https://svn.sourceforge.net/svnroot/matplotlib/trunk
 Andrew> matplotlib
How will this affect the other top level packages, eg
 htdocs
 matplotlib
 toolkits
 users_guide
JDH

John Hunter wrote:
>>>>>>"Andrew" == Andrew Straw <str...@as...> writes:
>>>>>> 
>>>>>>
>
> Andrew> Hi All, It looks like SourceForge has (finally) adopted
> Andrew> site-wide subversion repositories:
> Andrew> http://sourceforge.net/docs/E09/
>
> Andrew> What do people feel about migrating from CVS to svn?
>
>I'm +20 on this. I've complained about sourceforge CVS for a long
>time, mainly because of the lag which in the past could be days, but
>also because of the lack of proper directory management. Every time
>we wanted to reorganize the directories we would lose history.
>
>If you (or anyone else) want to have a go at migration, please do. It
>should be pretty easy because we have a pretty simple CVS setup, no
>branches etc. 
> 
>
Great! I'm unable to do it myself (I lack admin rights), but hopefully
someone else can follow the directions on that page. Or else someone can
give me commit rights (astraw@sf) and I'll do it, probably tomorrow
afternoon. Obviously, we should announce in advance when the changeover
will happen.
I propose the following structure, which we could implement as the first
commits of the subversion repository once the CVS data is installed.
matplotlib/ (top level)
 branches/ (empty for now)
 trunk/
 setup.py
 lib/
 (and so on)
This will make life easier down the track when we want to make branches
and will allow checkouts of just the trunk with:
svn co https://svn.sourceforge.net/svnroot/matplotlib/trunk matplotlib
I just downloaded inkscape from SF via svn, and all apparently went
well. So, I'm optimistic on SF's subversion implementation.

>>>>> "Albert" == Albert Chin <mat...@ml...> writes:
 Albert> The problem is duplicate function names. An error occurs
 Albert> because set_bg() is contained in more than one loadable
 Albert> module, and the wrong one is selected at
 Albert> runtime. examples/image_demo.py won't run because Python
 Albert> gives an AttributeError in lib/matplotlib/image.py, line
 Albert> 141: im.set_bg( *bg)
I'm confused here. The only extension code that defines set_bg is the
_image module
johnh@jitter:src> grep set_bg *.h
_image.h: Py::Object set_bg(const Py::Tuple& args);
_image.h: static char set_bg__doc__[];
I don't see why you should be having a problem with this. Can you
submit a complete traceback?
 Albert> Also, src/mplutils.cpp is included multiple times but I
 Albert> haven't encountered any errors because of this yet.
This shouldn't pose a problem as long as there isn't a global
variable, right? My understanding is that the ft2font problem arises
because of the use of the global FT_Library _ft2Library .
JDH

On Mon, Feb 27, 2006 at 09:44:51AM -0600, John Hunter wrote:
> >>>>> "Albert" == Albert Chin <mat...@ml...> writes:
> 
> Albert> src/_image.cpp is also duplicated and is a problem as
> Albert> well. It'll need a similar fix.
> 
> Do you mean _image is bringing in ft2font? It shouldn't be. agg
> definitely uses it but image does not. Can you provide a little more
> detail here.
The problem is duplicate function names. An error occurs because
set_bg() is contained in more than one loadable module, and the wrong
one is selected at runtime. examples/image_demo.py won't run because
Python gives an AttributeError in lib/matplotlib/image.py, line 141:
 im.set_bg( *bg)
Also, src/mplutils.cpp is included multiple times but I haven't
encountered any errors because of this yet.
-- 
albert chin (ch...@th...)

>>>>> "Albert" == Albert Chin <mat...@ml...> writes:
 >> > The throw Py::RuntimeError is coming from
 >> src/ft2font.cpp. There's a > global that holds information for
 >> FreeType libraries: > FT_Library _ft2Library;
Hi Albert, thanks for digging in to this. I think I understand now
the cause of your problem, though the best solution will require a bit
more thought. 
I don't think embedding python is the right approach at the moment.
Hopefully we can be a little more clever about linking rather than
embedding ft2font multiple times. Alternatively, we can recode
backend agg to not use the font object directly, but pass around a
pixel buffer of the rendered glyphs.
 Albert> src/_image.cpp is also duplicated and is a problem as
 Albert> well. It'll need a similar fix.
Do you mean _image is bringing in ft2font? It shouldn't be. agg
definitely uses it but image does not. Can you provide a little more
detail here.
JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:
 Andrew> Hi All, It looks like SourceForge has (finally) adopted
 Andrew> site-wide subversion repositories:
 Andrew> http://sourceforge.net/docs/E09/
 Andrew> What do people feel about migrating from CVS to svn?
I'm +20 on this. I've complained about sourceforge CVS for a long
time, mainly because of the lag which in the past could be days, but
also because of the lack of proper directory management. Every time
we wanted to reorganize the directories we would lose history.
If you (or anyone else) want to have a go at migration, please do. It
should be pretty easy because we have a pretty simple CVS setup, no
branches etc. 
JDH

This is a problem with debugging a program (in Wing) that uses pylab (a
graphing module), which in turn uses wxWidgets to display its graphs (I'm
using pylab's WXAgg drawing backend). I'm not sure which community would
have the best insight into the issue so please forgive me for crossposting
to all three.
The problem I'm having is very simple. When I'm stopped at a breakpoint in
the IDE, the wxWidgets loop stops running too, so the graphs don't refresh
their drawing.
On the other hand, in the Wing IDE, if I just let the program run to
completion, then the graphs disappear before I have a chance to look at
them. wx, pylab, and Wing are all pretty compex things, so I'm not sure
where to look for how to fix this particular behavior.
WX folks: Is there some way to make it so that the wx main loop stay active
at an IDEs breakpoint? Or some way to say at the end of my program "just g=
o
into the loop currently in progress".
Pylab folks: Is there a setting that I can use to make graphs run in
separate threads or processes?
Wing folks: is there some Wing setting I can use to change the breakpoint
behavior? Assuming pylab graphs are in a separate thread, would there be
some way to specify that a breakpoint shouldn't stop that thread?
Thanks for any suggestions,
--Bill Baxter

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