matplotlib-devel Mailing List for matplotlib

>>>>> "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