matplotlib-devel Mailing List for matplotlib (Page 2)

It looks like something fishy in your font cache -- "None" has been 
entered in the table as a filename.

Can you move away your ~/.matplotlib/fontList.cache file (to force a 
regeneration) and see if that resolves the problem?  If so, I'd like to 
see the original broken fontList.cache file to see if I can get to the 
bottom of what's wrong with it.

Have you set any font-related rcParams to anything non-standard that 
might be causing the lookup to fail?

Cheers,
Mike

On 06/21/2011 04:24 AM, Fernando Perez wrote:
> Howdy,
>
> a simple
>
> plot(rand(100))
> savefig('foo.eps')
>
> is giving me the traceback below.  Is it something I'm doing wrong on my side?
>
> Running on linux, ubuntu 10.10, python2.6.
>
> Thanks for any tips...
>
>
> f
>
> ---------------------------------------------------------------------------
> TypeError                                 Traceback (most recent call last)
> /home/fperez/research/dif-tx/src/python/<ipython-input-2-3f85c055f45e>
> in<module>()
> ---->  1 savefig('foo.eps')
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/pyplot.pyc
> in savefig(*args, **kwargs)
>      426 def savefig(*args, **kwargs):
>      427     fig = gcf()
> -->  428     return fig.savefig(*args, **kwargs)
>      429
>      430 @docstring.copy_dedent(Figure.ginput)
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/figure.pyc
> in savefig(self, *args, **kwargs)
>     1160             kwargs.setdefault('edgecolor',
> rcParams['savefig.edgecolor'])
>     1161
> ->  1162         self.canvas.print_figure(*args, **kwargs)
>     1163
>     1164         if transparent:
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_qt4agg.pyc
> in print_figure(self, *args, **kwargs)
>      151
>      152     def print_figure(self, *args, **kwargs):
> -->  153         FigureCanvasAgg.print_figure(self, *args, **kwargs)
>      154         self.draw()
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backend_bases.pyc
> in print_figure(self, filename, dpi, facecolor, edgecolor,
> orientation, format, **kwargs)
>     1977                 orientation=orientation,
>     1978                 bbox_inches_restore=_bbox_inches_restore,
> ->  1979                 **kwargs)
>     1980         finally:
>     1981             if bbox_inches and restore_bbox:
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backend_bases.pyc
> in print_eps(self, *args, **kwargs)
>     1744         from backends.backend_ps import FigureCanvasPS # lazy import
>     1745         ps = self.switch_backends(FigureCanvasPS)
> ->  1746         return ps.print_eps(*args, **kwargs)
>     1747
>     1748     def print_pdf(self, *args, **kwargs):
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
> in print_eps(self, outfile, *args, **kwargs)
>      933
>      934     def print_eps(self, outfile, *args, **kwargs):
> -->  935         return self._print_ps(outfile, 'eps', *args, **kwargs)
>      936
>      937
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
> in _print_ps(self, outfile, format, *args, **kwargs)
>      966             self._print_figure(outfile, format, imagedpi,
> facecolor, edgecolor,
>      967                                orientation, isLandscape, papertype,
> -->  968                                **kwargs)
>      969
>      970     def _print_figure(self, outfile, format, dpi=72,
> facecolor='w', edgecolor='w',
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
> in _print_figure(self, outfile, format, dpi, facecolor, edgecolor,
> orientation, isLandscape, papertype, **kwargs)
>     1059             bbox_inches_restore=_bbox_inches_restore)
>     1060
> ->  1061         self.figure.draw(renderer)
>     1062
>     1063         if dryrun: # return immediately if dryrun (tightbbox=True)
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
> in draw_wrapper(artist, renderer, *args, **kwargs)
>       53     def draw_wrapper(artist, renderer, *args, **kwargs):
>       54         before(artist, renderer)
> --->  55         draw(artist, renderer, *args, **kwargs)
>       56         after(artist, renderer)
>       57
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/figure.pyc
> in draw(self, renderer)
>      872         dsu.sort(key=itemgetter(0))
>      873         for zorder, func, args in dsu:
> -->  874             func(*args)
>      875
>      876         renderer.close_group('figure')
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
> in draw_wrapper(artist, renderer, *args, **kwargs)
>       53     def draw_wrapper(artist, renderer, *args, **kwargs):
>       54         before(artist, renderer)
> --->  55         draw(artist, renderer, *args, **kwargs)
>       56         after(artist, renderer)
>       57
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axes.pyc
> in draw(self, renderer, inframe)
>     1981
>     1982         for zorder, a in dsu:
> ->  1983             a.draw(renderer)
>     1984
>     1985         renderer.close_group('axes')
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
> in draw_wrapper(artist, renderer, *args, **kwargs)
>       53     def draw_wrapper(artist, renderer, *args, **kwargs):
>       54         before(artist, renderer)
> --->  55         draw(artist, renderer, *args, **kwargs)
>       56         after(artist, renderer)
>       57
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axis.pyc
> in draw(self, renderer, *args, **kwargs)
>     1035
>     1036         ticks_to_draw = self._update_ticks(renderer)
> ->  1037         ticklabelBoxes, ticklabelBoxes2 =
> self._get_tick_bboxes(ticks_to_draw, renderer)
>     1038
>     1039         for tick in ticks_to_draw:
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axis.pyc
> in _get_tick_bboxes(self, ticks, renderer)
>      986         for tick in ticks:
>      987             if tick.label1On and tick.label1.get_visible():
> -->  988                 extent = tick.label1.get_window_extent(renderer)
>      989                 ticklabelBoxes.append(extent)
>      990             if tick.label2On and tick.label2.get_visible():
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/text.pyc
> in get_window_extent(self, renderer, dpi)
>      745             raise RuntimeError('Cannot get window extent w/o renderer')
>      746
> -->  747         bbox, info = self._get_layout(self._renderer)
>      748         x, y = self.get_position()
>      749         x, y = self.get_transform().transform_point((x, y))
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/text.pyc
> in _get_layout(self, renderer)
>      298         tmp, lp_h, lp_bl = get_text_width_height_descent('lp',
>      299
> self._fontproperties,
> -->  300                                                          ismath=False)
>      301         offsety = lp_h * self._linespacing
>      302
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
> in get_text_width_height_descent(self, s, prop, ismath)
>      338         if rcParams['ps.useafm']:
>      339             if ismath: s = s[1:-1]
> -->  340             font = self._get_font_afm(prop)
>      341             l,b,w,h,d = font.get_str_bbox_and_descent(s)
>      342
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
> in _get_font_afm(self, prop)
>      366         font = self.afmfontd.get(key)
>      367         if font is None:
> -->  368             fname = findfont(prop, fontext='afm',
> directory=self._afm_font_dir)
>      369             if fname is None:
>      370                 fname = findfont(
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/font_manager.pyc
> in findfont(prop, **kw)
>     1319     def findfont(prop, **kw):
>     1320         global fontManager
> ->  1321         font = fontManager.findfont(prop, **kw)
>     1322         return font
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/font_manager.pyc
> in findfont(self, prop, fontext, directory, fallback_to_default,
> rebuild_if_missing)
>     1211                 default_prop = prop.copy()
>     1212                 default_prop.set_family(self.defaultFamily[fontext])
> ->  1213                 return self.findfont(default_prop, fontext,
> directory, False)
>     1214             else:
>     1215                 # This is a hard fail -- we can't find
> anything reasonable,
>
>
> /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/font_manager.pyc
> in findfont(self, prop, fontext, directory, fallback_to_default,
> rebuild_if_missing)
>     1226             result = best_font.fname
>     1227
> ->  1228         if not os.path.isfile(result):
>     1229             if rebuild_if_missing:
>     1230                 verbose.report(
>
> /usr/lib/python2.6/genericpath.pyc in isfile(path)
>       27     """Test whether a path is a regular file"""
>       28     try:
> --->  29         st = os.stat(path)
>       30     except os.error:
>       31         return False
>
> TypeError: coercing to Unicode: need string or buffer, NoneType found
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

I see what is happening here...  The SVG backend was recently re-written 
to write some of the path data in C -- unfortunately the numbers being 
written there are locale-aware, and in your locale it appears to be 
using ',' as a decimal point.

I put up a fix for this here:

https://github.com/matplotlib/matplotlib/pull/369

In the meantime, you may have some luck by setting your locale before 
running python, i.e.:

   LANG=en_US.UTF-8 python svg_export2.py

Cheers,
Mike

On 06/21/2011 06:47 AM, Dieter Weber wrote:
> Hi folks,
> when I tried to export figures as SVG, the result was completely messed
> up. Export in other formats works.
>
> Appended you find:
> * Script to reproduce error
> * Broken SVG
> * Working EPS
> * Broken SVG rendered by Gnome image viewer (eog)
> * Broken SVG rendered by Inkscape
>
> Setup:
> Ubuntu 10.04 LTS
> Python 2.6.5 (stock)
> Matplotlib current version from git, installed with "python setupegg.py
> develop"
>
> Can you reproduce the problem on your machine?
>
> Greetings,
> Dieter
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Mon, Jun 20, 2011 at 6:18 PM, Eric Firing <ef...@ha...> wrote:
> On 06/20/2011 11:29 AM, Darren Dale wrote:
>
>> Ok, I've migrated the issues over to github.
>>
>> Darren
>
> Darren,
>
> Thank you.  Now I see another possible problem with the issue tracker:
> it doesn't seem to have a way to select issues that do *not* have a
> particular label.

I just filed a support request and asked if this feature could be added.

> Well, at least that gives us extra incentive to plow
> through the sourceforge imports and try to close as many as possible.
> Also to figure out a good standard set of labels.

Since github thinks I am the original reporter of all of the migrated
issues, I'm getting notifications on all the sourceforge issues
activity. Impressive progress! I think we closed over 80 issues since
yesterday, and you handled a big majority of them.

Hi folks,
when I tried to export figures as SVG, the result was completely messed
up. Export in other formats works. 

Appended you find:
* Script to reproduce error
* Broken SVG
* Working EPS
* Broken SVG rendered by Gnome image viewer (eog)
* Broken SVG rendered by Inkscape

Setup:
Ubuntu 10.04 LTS
Python 2.6.5 (stock)
Matplotlib current version from git, installed with "python setupegg.py
develop"

Can you reproduce the problem on your machine?

Greetings,
Dieter

Hi everybody,
just now I noticed that I was still running the old SVN version of
matplotlib and not the most recent one from git. Apparently the files
installed to (in my
case) /usr/local/lib/python2.6/dist-packages/matplotlib from SVN with
"python setup.py install" took precedence over the installation with
"python setupegg.py develop". I therefore suggest to modify
http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-git by replacing

"If you want to be able to follow the development branch as it changes
just replace the last step with (make sure you have setuptools
installed):"

with 

"If you want to be able to follow the development branch as it changes
just uninstall any existing copy of matplotlib and replace the last step
with (make sure you have setuptools installed):"

Best wishes,
Dieter

Howdy,

a simple

plot(rand(100))
savefig('foo.eps')

is giving me the traceback below.  Is it something I'm doing wrong on my side?

Running on linux, ubuntu 10.10, python2.6.

Thanks for any tips...


f

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
/home/fperez/research/dif-tx/src/python/<ipython-input-2-3f85c055f45e>
in <module>()
----> 1 savefig('foo.eps')

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/pyplot.pyc
in savefig(*args, **kwargs)
    426 def savefig(*args, **kwargs):
    427     fig = gcf()
--> 428     return fig.savefig(*args, **kwargs)
    429
    430 @docstring.copy_dedent(Figure.ginput)

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/figure.pyc
in savefig(self, *args, **kwargs)
   1160             kwargs.setdefault('edgecolor',
rcParams['savefig.edgecolor'])
   1161
-> 1162         self.canvas.print_figure(*args, **kwargs)
   1163
   1164         if transparent:

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_qt4agg.pyc
in print_figure(self, *args, **kwargs)
    151
    152     def print_figure(self, *args, **kwargs):
--> 153         FigureCanvasAgg.print_figure(self, *args, **kwargs)
    154         self.draw()

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backend_bases.pyc
in print_figure(self, filename, dpi, facecolor, edgecolor,
orientation, format, **kwargs)
   1977                 orientation=orientation,
   1978                 bbox_inches_restore=_bbox_inches_restore,
-> 1979                 **kwargs)
   1980         finally:
   1981             if bbox_inches and restore_bbox:

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backend_bases.pyc
in print_eps(self, *args, **kwargs)
   1744         from backends.backend_ps import FigureCanvasPS # lazy import
   1745         ps = self.switch_backends(FigureCanvasPS)
-> 1746         return ps.print_eps(*args, **kwargs)
   1747
   1748     def print_pdf(self, *args, **kwargs):

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in print_eps(self, outfile, *args, **kwargs)
    933
    934     def print_eps(self, outfile, *args, **kwargs):
--> 935         return self._print_ps(outfile, 'eps', *args, **kwargs)
    936
    937

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in _print_ps(self, outfile, format, *args, **kwargs)
    966             self._print_figure(outfile, format, imagedpi,
facecolor, edgecolor,
    967                                orientation, isLandscape, papertype,
--> 968                                **kwargs)
    969
    970     def _print_figure(self, outfile, format, dpi=72,
facecolor='w', edgecolor='w',

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in _print_figure(self, outfile, format, dpi, facecolor, edgecolor,
orientation, isLandscape, papertype, **kwargs)
   1059             bbox_inches_restore=_bbox_inches_restore)
   1060
-> 1061         self.figure.draw(renderer)
   1062
   1063         if dryrun: # return immediately if dryrun (tightbbox=True)

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *args, **kwargs)
     53     def draw_wrapper(artist, renderer, *args, **kwargs):
     54         before(artist, renderer)
---> 55         draw(artist, renderer, *args, **kwargs)
     56         after(artist, renderer)
     57

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/figure.pyc
in draw(self, renderer)
    872         dsu.sort(key=itemgetter(0))
    873         for zorder, func, args in dsu:
--> 874             func(*args)
    875
    876         renderer.close_group('figure')

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *args, **kwargs)
     53     def draw_wrapper(artist, renderer, *args, **kwargs):
     54         before(artist, renderer)
---> 55         draw(artist, renderer, *args, **kwargs)
     56         after(artist, renderer)
     57

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axes.pyc
in draw(self, renderer, inframe)
   1981
   1982         for zorder, a in dsu:
-> 1983             a.draw(renderer)
   1984
   1985         renderer.close_group('axes')

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/artist.pyc
in draw_wrapper(artist, renderer, *args, **kwargs)
     53     def draw_wrapper(artist, renderer, *args, **kwargs):
     54         before(artist, renderer)
---> 55         draw(artist, renderer, *args, **kwargs)
     56         after(artist, renderer)
     57

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axis.pyc
in draw(self, renderer, *args, **kwargs)
   1035
   1036         ticks_to_draw = self._update_ticks(renderer)
-> 1037         ticklabelBoxes, ticklabelBoxes2 =
self._get_tick_bboxes(ticks_to_draw, renderer)
   1038
   1039         for tick in ticks_to_draw:

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/axis.pyc
in _get_tick_bboxes(self, ticks, renderer)
    986         for tick in ticks:
    987             if tick.label1On and tick.label1.get_visible():
--> 988                 extent = tick.label1.get_window_extent(renderer)
    989                 ticklabelBoxes.append(extent)
    990             if tick.label2On and tick.label2.get_visible():

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/text.pyc
in get_window_extent(self, renderer, dpi)
    745             raise RuntimeError('Cannot get window extent w/o renderer')
    746
--> 747         bbox, info = self._get_layout(self._renderer)
    748         x, y = self.get_position()
    749         x, y = self.get_transform().transform_point((x, y))

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/text.pyc
in _get_layout(self, renderer)
    298         tmp, lp_h, lp_bl = get_text_width_height_descent('lp',
    299
self._fontproperties,
--> 300                                                          ismath=False)
    301         offsety = lp_h * self._linespacing
    302

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in get_text_width_height_descent(self, s, prop, ismath)
    338         if rcParams['ps.useafm']:
    339             if ismath: s = s[1:-1]
--> 340             font = self._get_font_afm(prop)
    341             l,b,w,h,d = font.get_str_bbox_and_descent(s)
    342

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/backends/backend_ps.pyc
in _get_font_afm(self, prop)
    366         font = self.afmfontd.get(key)
    367         if font is None:
--> 368             fname = findfont(prop, fontext='afm',
directory=self._afm_font_dir)
    369             if fname is None:
    370                 fname = findfont(

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/font_manager.pyc
in findfont(prop, **kw)
   1319     def findfont(prop, **kw):
   1320         global fontManager
-> 1321         font = fontManager.findfont(prop, **kw)
   1322         return font

/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/font_manager.pyc
in findfont(self, prop, fontext, directory, fallback_to_default,
rebuild_if_missing)
   1211                 default_prop = prop.copy()
   1212                 default_prop.set_family(self.defaultFamily[fontext])
-> 1213                 return self.findfont(default_prop, fontext,
directory, False)
   1214             else:
   1215                 # This is a hard fail -- we can't find
anything reasonable,


/home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/font_manager.pyc
in findfont(self, prop, fontext, directory, fallback_to_default,
rebuild_if_missing)
   1226             result = best_font.fname
   1227
-> 1228         if not os.path.isfile(result):
   1229             if rebuild_if_missing:
   1230                 verbose.report(

/usr/lib/python2.6/genericpath.pyc in isfile(path)
     27     """Test whether a path is a regular file"""
     28     try:
---> 29         st = os.stat(path)
     30     except os.error:
     31         return False

TypeError: coercing to Unicode: need string or buffer, NoneType found

On 06/20/2011 11:29 AM, Darren Dale wrote:

> Ok, I've migrated the issues over to github.
>
> Darren

Darren,

Thank you.  Now I see another possible problem with the issue tracker: 
it doesn't seem to have a way to select issues that do *not* have a 
particular label.  Well, at least that gives us extra incentive to plow 
through the sourceforge imports and try to close as many as possible. 
Also to figure out a good standard set of labels.

Eric

On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing <ef...@ha...> wrote:
> On 06/15/2011 10:35 AM, Darren Dale wrote:
>
>>
>> I figured out how to migrate soureforges tracker to github issues with
>> the new github api. There are 232 open issues on the sourceforge
>> tracker, 79 of which are feature requests. Most sf issues are from
>> 2009 and on, many in the last few months. How do we want to handle
>> this? Migrate now and then cull the list at github? I can add a
>> sourceforge-import label that we can use to filter the list, closing
>> or assigning milestones and labels as we go, removing the sf-import
>> label once the issue has been inspected. Then we could disable the
>> tracker at the github site. Alternatively, we could try cull the list
>> at sourceforge first. Whatever you guys want to do.
>
> Dale,
>
> I'm willing to go along with the transfer.  Probably just as well to get
> it over with now, assuming attached example files are included in some
> usable fashion.  As Mike notes, the sourceforge tracker is sluggish,
> although in some ways it is better-designed.

Ok, I've migrated the issues over to github.

Darren

On 06/20/2011 08:47 AM, Darren Dale wrote:
> On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing<ef...@ha...>  wrote:
>> On 06/15/2011 10:35 AM, Darren Dale wrote:
>>
>>>
>>> I figured out how to migrate soureforges tracker to github issues with
>>> the new github api. There are 232 open issues on the sourceforge
>>> tracker, 79 of which are feature requests. Most sf issues are from
>>> 2009 and on, many in the last few months. How do we want to handle
>>> this? Migrate now and then cull the list at github? I can add a
>>> sourceforge-import label that we can use to filter the list, closing
>>> or assigning milestones and labels as we go, removing the sf-import
>>> label once the issue has been inspected. Then we could disable the
>>> tracker at the github site. Alternatively, we could try cull the list
>>> at sourceforge first. Whatever you guys want to do.
>>
>> Dale,
>>
>> I'm willing to go along with the transfer.  Probably just as well to get
>> it over with now, assuming attached example files are included in some
>> usable fashion.  As Mike notes, the sourceforge tracker is sluggish,
>> although in some ways it is better-designed.
>
> Eric,
>
> Github's issue tracker still doesn't support attachements, so I've
> been inserting a hyperlink in the github issue to direct to the
> sourceforge issue, and I've included information at the bottom of the
> github issue concerning the history, which would indicate an
> attachment was submitted at sourceforge. Is that acceptable?

Darren,

Yes, I think that will work fine.  Thank you for all the work you have 
done and are doing for the sourceforge-to-github switch.

>
> Darren (Dale is my last name)

Oops, sorry--I knew that, but my brain disconnected from my fingers.

Eric

On Mon, Jun 20, 2011 at 2:33 PM, Eric Firing <ef...@ha...> wrote:
> On 06/15/2011 10:35 AM, Darren Dale wrote:
>
>>
>> I figured out how to migrate soureforges tracker to github issues with
>> the new github api. There are 232 open issues on the sourceforge
>> tracker, 79 of which are feature requests. Most sf issues are from
>> 2009 and on, many in the last few months. How do we want to handle
>> this? Migrate now and then cull the list at github? I can add a
>> sourceforge-import label that we can use to filter the list, closing
>> or assigning milestones and labels as we go, removing the sf-import
>> label once the issue has been inspected. Then we could disable the
>> tracker at the github site. Alternatively, we could try cull the list
>> at sourceforge first. Whatever you guys want to do.
>
> Dale,
>
> I'm willing to go along with the transfer.  Probably just as well to get
> it over with now, assuming attached example files are included in some
> usable fashion.  As Mike notes, the sourceforge tracker is sluggish,
> although in some ways it is better-designed.

Eric,

Github's issue tracker still doesn't support attachements, so I've
been inserting a hyperlink in the github issue to direct to the
sourceforge issue, and I've included information at the bottom of the
github issue concerning the history, which would indicate an
attachment was submitted at sourceforge. Is that acceptable?

Darren (Dale is my last name)

On 06/15/2011 10:35 AM, Darren Dale wrote:

>
> I figured out how to migrate soureforges tracker to github issues with
> the new github api. There are 232 open issues on the sourceforge
> tracker, 79 of which are feature requests. Most sf issues are from
> 2009 and on, many in the last few months. How do we want to handle
> this? Migrate now and then cull the list at github? I can add a
> sourceforge-import label that we can use to filter the list, closing
> or assigning milestones and labels as we go, removing the sf-import
> label once the issue has been inspected. Then we could disable the
> tracker at the github site. Alternatively, we could try cull the list
> at sourceforge first. Whatever you guys want to do.

Dale,

I'm willing to go along with the transfer.  Probably just as well to get 
it over with now, assuming attached example files are included in some 
usable fashion.  As Mike notes, the sourceforge tracker is sluggish, 
although in some ways it is better-designed.

Eric

On 06/15/2011 04:35 PM, Darren Dale wrote:
>
> I figured out how to migrate soureforges tracker to github issues with
> the new github api. There are 232 open issues on the sourceforge
> tracker, 79 of which are feature requests. Most sf issues are from
> 2009 and on, many in the last few months. How do we want to handle
> this? Migrate now and then cull the list at github? I can add a
> sourceforge-import label that we can use to filter the list, closing
> or assigning milestones and labels as we go, removing the sf-import
> label once the issue has been inspected. Then we could disable the
> tracker at the github site. Alternatively, we could try cull the list
> at sourceforge first. Whatever you guys want to do.

My humble preference is to migrate them all to github with the special 
"SF" label.  I find the github tracker (while not as full featured) 
faster to use.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Perhaps my greatest annoyance with the matplotlib HTML documentation is
the simply absurd length of some of the module pages. For instance, the
reference for the axes module[1] amounts to more than 150 printed pages
(for lack of a better measure).

Despite this length, there is no table of contents summarizing the
methods in the module. Due to this I (and no doubt others) have spent
innumerable hours wandering aimlessly looking for the function whose
name I can't quite remember. Is there some way to get sphinx to produce
a table of contents on each page produced? The current layout makes the
HTML documentation completely unapproachable without Google.

Cheers,

- Ben

Great work everybody for the recent set of fixes and changes to the master
branch.  I am quickly putting master through its paces and checking out the
docs and I have a few things I have noticed.  I figure this might be a good
thread to air out any remaining quirks that we want resolved before
branching v1.1.0.

First, we obviously need to update the What's New page.  The top two changes
that stand out in my mind are tight_layout and animation modules.

Second, the doc build system is not pulling in the animation.py module for
the API docs.  Plus, I recall a fantastic example posted a few months back
of a pendulum demo that used the animation module.  That example should be
front and center for the animation docs.

Third, like the animation.py module, the tight_layout.py module is not
pulled in for the API docs (but does it need to?).  However, the
tight_layout guide for the User's Guide looks good.

Some build errors/warnings for the docs are interesting.  In particular, we
still see Invalid Value messages with respect to the polar projections and
some geo projections.  I don't know if anybody has a clue about those.
(along a similar note, I have been unable to use log scale for polar
projection).

When running the tests, I have 1 error (ERROR: Failure: AttributeError
('module' object has no attribute 'test_textmatplotlib')), and two
failures.  The failures are:

======================================================================
FAIL: matplotlib.tests.test_axes.test_single_point.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest
    self.test(*self.arg)
  File "/home/bvr/Programs/matplotlib/lib/matplotlib/testing/decorators.py",
line 34, in failer
    result = f(*args, **kwargs)
  File "/home/bvr/Programs/matplotlib/lib/matplotlib/testing/decorators.py",
line 124, in do_test
    '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/home/bvr/testy/result_images/test_axes/single_point.png vs.
/home/bvr/testy/result_images/test_axes/expected-single_point.png (RMS
10.392)

======================================================================
FAIL: matplotlib.tests.test_image.test_image_interps.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 187, in runTest
    self.test(*self.arg)
  File "/home/bvr/Programs/matplotlib/lib/matplotlib/testing/decorators.py",
line 34, in failer
    result = f(*args, **kwargs)
  File "/home/bvr/Programs/matplotlib/lib/matplotlib/testing/decorators.py",
line 124, in do_test
    '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/home/bvr/testy/result_images/test_image/image_interps_pdf.png vs.
/home/bvr/testy/result_images/test_image/expected-image_interps_pdf.png (RMS
281.963)

----------------------------------------------------------------------

I can not tell the difference for the single-point test, but there is a
difference for the interps test.  The transition from blue to green for the
top subplot is in a slightly different location and might be due to some
sort of changes made to rasterization?

These are just what I have noticed so far.  Good work, everybody!

Ben Root

On Wednesday, June 15, 2011, Darren Dale <dsd...@gm...> wrote:
> On Wed, Jun 15, 2011 at 2:37 PM, Michael Droettboom <md...@st...> wrote:
>> On 06/15/2011 01:00 PM, Darren Dale wrote:
>>>
>>> On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<md...@st...>
>>>  wrote:
>>>>
>>>> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>>>>
>>>>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>
>>>>>  wrote:
>>>>>>
>>>>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>
>>>>>>  wrote:
>>>>>>
>>>>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>>>>> consider it as a placeholder for now. Then we bump the version number
>>>>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>>>>> everyone's attention to the fact the next release will be the first to
>>>>>>> drop support for<=python-2.5. Once folks start working with the
>>>>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>>>>> branch.
>>>>>>
>>>>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>>>>> release, but this will be a good impetus.  Should we give people a
>>>>>> couple of days to close any open tickets they want or push any last
>>>>>> minute changes in that we want before making the 1.1 release branch?
>>>>>> Once we branch, I suggest only release critical bug fixes go in as we
>>>>>> discussed last.
>>>>>
>>>>> Each pull request gets assigned to an issue.
>>>>
>>>> How do I apply labels to an issue with an associated pull request?  I see
>>>> how to do it for free-standing issues, but not the pull request ones.
>>>
>>> On the main issues page, you can select the check box for an issue,
>>> and then you can use the label, assignee, milestone widgets at the top
>>> of the issues list
>>>
>> Ok.  I have also added a milestone for v1.0.x for simple fixes to very
>> well-defined bugs -- things we should be able to get out as soon as
>> possible.
>
> I figured out how to migrate soureforges tracker to github issues with
> the new github api. There are 232 open issues on the sourceforge
> tracker, 79 of which are feature requests. Most sf issues are from
> 2009 and on, many in the last few months. How do we want to handle
> this? Migrate now and then cull the list at github? I can add a
> sourceforge-import label that we can use to filter the list, closing
> or assigning milestones and labels as we go, removing the sf-import
> label once the issue has been inspected. Then we could disable the
> tracker at the github site. Alternatively, we could try cull the list
> at sourceforge first. Whatever you guys want to do.
>

Just a quick note for my work, I am currently without Internet access
and (most) people in my apartment complex has learned to secure their
wifi.  I will try to look through the list of issues and pull requests
soon enough.

Ben Root

On Wed, Jun 15, 2011 at 2:37 PM, Michael Droettboom <md...@st...> wrote:
> On 06/15/2011 01:00 PM, Darren Dale wrote:
>>
>> On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<md...@st...>
>>  wrote:
>>>
>>> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>>>
>>>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>
>>>>  wrote:
>>>>>
>>>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>
>>>>>  wrote:
>>>>>
>>>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>>>> consider it as a placeholder for now. Then we bump the version number
>>>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>>>> everyone's attention to the fact the next release will be the first to
>>>>>> drop support for<=python-2.5. Once folks start working with the
>>>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>>>> branch.
>>>>>
>>>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>>>> release, but this will be a good impetus.  Should we give people a
>>>>> couple of days to close any open tickets they want or push any last
>>>>> minute changes in that we want before making the 1.1 release branch?
>>>>> Once we branch, I suggest only release critical bug fixes go in as we
>>>>> discussed last.
>>>>
>>>> Each pull request gets assigned to an issue.
>>>
>>> How do I apply labels to an issue with an associated pull request?  I see
>>> how to do it for free-standing issues, but not the pull request ones.
>>
>> On the main issues page, you can select the check box for an issue,
>> and then you can use the label, assignee, milestone widgets at the top
>> of the issues list
>>
> Ok.  I have also added a milestone for v1.0.x for simple fixes to very
> well-defined bugs -- things we should be able to get out as soon as
> possible.

I figured out how to migrate soureforges tracker to github issues with
the new github api. There are 232 open issues on the sourceforge
tracker, 79 of which are feature requests. Most sf issues are from
2009 and on, many in the last few months. How do we want to handle
this? Migrate now and then cull the list at github? I can add a
sourceforge-import label that we can use to filter the list, closing
or assigning milestones and labels as we go, removing the sf-import
label once the issue has been inspected. Then we could disable the
tracker at the github site. Alternatively, we could try cull the list
at sourceforge first. Whatever you guys want to do.

On 06/15/2011 01:00 PM, Darren Dale wrote:
> On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom<md...@st...>  wrote:
>> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>    wrote:
>>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>    wrote:
>>>>
>>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>>> consider it as a placeholder for now. Then we bump the version number
>>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>>> everyone's attention to the fact the next release will be the first to
>>>>> drop support for<=python-2.5. Once folks start working with the
>>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>>> branch.
>>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>>> release, but this will be a good impetus.  Should we give people a
>>>> couple of days to close any open tickets they want or push any last
>>>> minute changes in that we want before making the 1.1 release branch?
>>>> Once we branch, I suggest only release critical bug fixes go in as we
>>>> discussed last.
>>> Each pull request gets assigned to an issue.
>> How do I apply labels to an issue with an associated pull request?  I see
>> how to do it for free-standing issues, but not the pull request ones.
> On the main issues page, you can select the check box for an issue,
> and then you can use the label, assignee, milestone widgets at the top
> of the issues list
>
Ok.  I have also added a milestone for v1.0.x for simple fixes to very 
well-defined bugs -- things we should be able to get out as soon as 
possible.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Wed, Jun 15, 2011 at 12:49 PM, Michael Droettboom <md...@st...> wrote:
> On 06/15/2011 12:13 PM, Darren Dale wrote:
>>
>> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>  wrote:
>>>
>>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>  wrote:
>>>
>>>> I suggest we make a 1.1.x branch from the current state of master, and
>>>> consider it as a placeholder for now. Then we bump the version number
>>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>>> everyone's attention to the fact the next release will be the first to
>>>> drop support for<=python-2.5. Once folks start working with the
>>>> master (2.0) branch, if we have any complaints that a version 1.1
>>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>>> branch.
>>>
>>> This works for me -- I obviously dropped the ball pushing for a 1.1
>>> release, but this will be a good impetus.  Should we give people a
>>> couple of days to close any open tickets they want or push any last
>>> minute changes in that we want before making the 1.1 release branch?
>>> Once we branch, I suggest only release critical bug fixes go in as we
>>> discussed last.
>>
>> Each pull request gets assigned to an issue.
>
> How do I apply labels to an issue with an associated pull request?  I see
> how to do it for free-standing issues, but not the pull request ones.

On the main issues page, you can select the check box for an issue,
and then you can use the label, assignee, milestone widgets at the top
of the issues list

>>  I just added two labels
>> in the github issue tracker: wishlist and ongoing.
>
> So, to be clear, "wishlist" means "would be nice to have, but no real target
> date", and "ongoing" means someone is working on it?

That was the idea. Ongoing meaning some progress has been made, but
nobody has taken ownership of the issue.

>>  I also created two
>> milestones: v1.1.0 and v2.0.0. Could the devs please look through the
>> issues and assign each one to either one of the milestones or apply
>> the wishlist label? I could try to merge the issues from sourceforge
>> as well, though that may take some time.
>
> It would be nice to merge those in -- wasn't there some tools other projects
> were using to import them en masse?

Yes: https://github.com/ddale/mpl-issues

I need to see if the code will still work since they upgraded their
issue tracker. I can have a look tonight.

On 06/15/2011 12:13 PM, Darren Dale wrote:
> On Wed, Jun 15, 2011 at 10:06 AM, John Hunter<jd...@gm...>  wrote:
>> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale<dsd...@gm...>  wrote:
>>
>>> I suggest we make a 1.1.x branch from the current state of master, and
>>> consider it as a placeholder for now. Then we bump the version number
>>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>>> everyone's attention to the fact the next release will be the first to
>>> drop support for<=python-2.5. Once folks start working with the
>>> master (2.0) branch, if we have any complaints that a version 1.1
>>> release was needed after all, we can cut it from the 1.1.x placeholder
>>> branch.
>> This works for me -- I obviously dropped the ball pushing for a 1.1
>> release, but this will be a good impetus.  Should we give people a
>> couple of days to close any open tickets they want or push any last
>> minute changes in that we want before making the 1.1 release branch?
>> Once we branch, I suggest only release critical bug fixes go in as we
>> discussed last.
> Each pull request gets assigned to an issue.

How do I apply labels to an issue with an associated pull request?  I 
see how to do it for free-standing issues, but not the pull request ones.

>   I just added two labels
> in the github issue tracker: wishlist and ongoing.

So, to be clear, "wishlist" means "would be nice to have, but no real 
target date", and "ongoing" means someone is working on it?

>   I also created two
> milestones: v1.1.0 and v2.0.0. Could the devs please look through the
> issues and assign each one to either one of the milestones or apply
> the wishlist label? I could try to merge the issues from sourceforge
> as well, though that may take some time.

It would be nice to merge those in -- wasn't there some tools other 
projects were using to import them en masse?  If we do so, I would also 
suggest (somewhat controversially) that we deleted everything before 
some arbitrary cut off date.  There are a lot of really old, and most 
likely obsolete bugs in there, and we should probably just declare 
bankruptcy on them.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Wed, Jun 15, 2011 at 10:06 AM, John Hunter <jd...@gm...> wrote:
> On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale <dsd...@gm...> wrote:
>
>> I suggest we make a 1.1.x branch from the current state of master, and
>> consider it as a placeholder for now. Then we bump the version number
>> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
>> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
>> everyone's attention to the fact the next release will be the first to
>> drop support for <=python-2.5. Once folks start working with the
>> master (2.0) branch, if we have any complaints that a version 1.1
>> release was needed after all, we can cut it from the 1.1.x placeholder
>> branch.
>
> This works for me -- I obviously dropped the ball pushing for a 1.1
> release, but this will be a good impetus.  Should we give people a
> couple of days to close any open tickets they want or push any last
> minute changes in that we want before making the 1.1 release branch?
> Once we branch, I suggest only release critical bug fixes go in as we
> discussed last.

Each pull request gets assigned to an issue. I just added two labels
in the github issue tracker: wishlist and ongoing. I also created two
milestones: v1.1.0 and v2.0.0. Could the devs please look through the
issues and assign each one to either one of the milestones or apply
the wishlist label? I could try to merge the issues from sourceforge
as well, though that may take some time.

On Wed, Jun 15, 2011 at 9:02 AM, Darren Dale <dsd...@gm...> wrote:

> I suggest we make a 1.1.x branch from the current state of master, and
> consider it as a placeholder for now. Then we bump the version number
> in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
> delete the py3 repo. The reason for bumping to v2.0 is simply to draw
> everyone's attention to the fact the next release will be the first to
> drop support for <=python-2.5. Once folks start working with the
> master (2.0) branch, if we have any complaints that a version 1.1
> release was needed after all, we can cut it from the 1.1.x placeholder
> branch.

This works for me -- I obviously dropped the ball pushing for a 1.1
release, but this will be a good impetus.  Should we give people a
couple of days to close any open tickets they want or push any last
minute changes in that we want before making the 1.1 release branch?
Once we branch, I suggest only release critical bug fixes go in as we
discussed last.

On Mon, Jun 13, 2011 at 2:29 PM, Michael Droettboom <md...@st...> wrote:
> On 06/13/2011 01:38 PM, Darren Dale wrote:
>>
>> On Mon, Jun 13, 2011 at 12:25 PM, Michael Droettboom<md...@st...>
>>  wrote:
>>>
>>> This was recently discussed in the thread "v1.0.x branch seems confused."
>>>
>>> I (believe) the consensus was to get out another v1.0.x maintenance
>>> release out in the near future (which would not support py3k, but would
>>> still support Python 2.4), and then merge the py3 branch into master so
>>> it starts to get some more testing before making the next major release.
>>>
>>> I'm just today merging master into py3 so that when we are ready to do
>>> the merge the other way most of the hard work will have already been
>>> done.
>>
>> Are there features already in master that should be supported by
>> <python-2.6? If so, I think we should consider releasing 1.1.0 and
>> making a 1.1.x maintenance branch before merging the py3 stuff back
>> into master. Then mpl-1.2 could be the first to support py3.
>
> That's a good question.  We're now *officially* on 2.7 in my environment, so
> I don't have any compulsion to raise my hand here.  But others may.  Speak
> up!  :)

I suggest we make a 1.1.x branch from the current state of master, and
consider it as a placeholder for now. Then we bump the version number
in the py3 repo to *2.0*, merge py3/master back into mpl/master, and
delete the py3 repo. The reason for bumping to v2.0 is simply to draw
everyone's attention to the fact the next release will be the first to
drop support for <=python-2.5. Once folks start working with the
master (2.0) branch, if we have any complaints that a version 1.1
release was needed after all, we can cut it from the 1.1.x placeholder
branch.

Darren

On Tue, Jun 14, 2011 at 8:46 AM, Kevin Davies <dav...@ya...> wrote:
> Hello,
> I should have sent the original email in plain text rather than HTML, so I am resending it.  Please give me suggestions regarding my email below.  Thanks.


Hey Kevin,

the toolkit looks quite nice and we would be happy to distribute it,
but we require a BSD compatible license (for a rationale, please see
http://matplotlib.sourceforge.net/devel/coding_guide.html#license-discussion).
 Although we could technically distribute a GPL licensed product as a
toolkit, I think it might be confusing to users so I prefer to keep
everything in our distribution BSD compatible.  I think the benefits
of having your code part of the core distribution with users seeing
samples on our web pages and gallery outweigh the risks that someone
might sell your code, but that is just my opinion.  Having a lot of
visibility and users increases the odds that others will contribute to
and extend your toolkit.    Personally, it doesn't bother me that
companies sell products that use matplotlib, despite having
contributed a considerable amount of time on the code.  Some of these
companies have expressed interest in supporting matplotlib development
via donations or sponsored features.  But I understand that you may
feel otherwise.

If you elect to keep your code under a GPL license, feel free to
distribute it as you see fit.  Many scientific computing projects in
python use github.  Google code is another option.  We would be happy
to link to your code from our existing sankey examples, etc.

Hello,
I should have sent the original email in plain text rather than HTML, so I am resending it.  Please give me suggestions regarding my email below.  Thanks.

Kevin

________________________________
From: Kevin Davies <dav...@ya...>
To: "mat...@li..." <mat...@li...>
Sent: Sunday, June 12, 2011 2:32 PM
Subject: Sankey diagram toolkit


Hello,
I'm new to the matplotlib-devel list, but I wanted to ask for your opinions and suggestions about sharing a toolkit/module for drawing Sankey diagrams.  I've continued from the work of Yannick Chopin (see http://matplotlib.sourceforge.net/examples/api/sankey_demo.html) to help support more complex diagrams.  I'm attaching an example.  

Specifically, I'd like to know:
1.  Would the matplotlib community be interested in the code shared under a GPL license?  Due to the fact that there are companies selling Sankey software (see http://www.sankey-diagrams.com/sankey-diagram-software/), I'd rather keep a little more control than BSD provides.  
2.  If there is interest, would the code be best shared as a matplotlib toolkit?  It seems so, but I don't think it directly fits with any of the other current toolkits.
3.  If it is best shared as a toolkit, how would I go about doing it?  Currently, the code exists as about 900 lines of Python with five examples and inline documentation.  Do I need to make special preparations?

Thank you!

Kevin

Hi,
1.0.3 packages are available for OS X.

I'll be going on vacation next week and my work project using PySide 
will be winding down over the same period.  It would be nice if the 
PySide changes could be pulled into master before then

Thanks,
Gerald.

On 31/05/2011 5:10 PM, Gerald Storer wrote:
> 1.0.3 packages for Windows and Ubuntu/Debian are available to test with.
>
> I'm not sure that the OS X package is ready yet.  If you want to get
> testing with it quicker jumping up and down on their mailing list
> normally gets them out faster.
>
> I also added an update to formlayout.py.  I've merged in Pierre's latest
> version that validates the floats so an exception isn't thrown when a
> user inputs an invalid number.
>
> Gerald.
>
> On 31/05/2011 4:43 PM, David Trémouilles wrote:
>> The pyside bug affecting matplotlib pyside backend is now fixed
>> with pyside 1.0.3
>>
>> I would be nice to have the pyside option in the next matplotlib release...
>>
>> Regards,
>>
>> David
>>
>> Le 06/05/11 10:32, David Trémouilles a écrit :
>>> Hello,
>>>
>>> This is not directly related to your patch but I would like to
>>> report here that I still have at least one issue on MacOs
>>> that prevent matplotlib to work with your pyside backend.
>>> Indeed current PySide version (1.0.2) have a bug on MacOS that seems to
>>> have been fixed recently:
>>> http://bugs.pyside.org/show_bug.cgi?id=809
>>> But I will have to wait for next PySide release to
>>> confirm your pyside patch works on MacOs.
>>> Will test as soon as next pyside version is out and available on
>>> macports. I do not have time nor will to test with the latest current
>>> pyside head.
>>>
>>> Regards,
>>>
>>> David
>>>
>>>
>>>
>>> Le 06/05/11 03:36, Gerald Storer a écrit :
>>>> Hi,
>>>> I was wondering if I could get a comment on this. Its been 4 weeks
>>>> since I submitted the original version and it has been more or less
>>>> production ready since Monday.
>>>>
>>>> https://github.com/matplotlib/matplotlib/pull/80
>>>>
>>>> Thanks,
>>>> Gerald.
>>>>
>>>> On 11/04/2011 4:49 PM, Gerald Storer wrote:
>>>>> Hi,
>>>>> I've submitted a pull request with backend changes that (should) let
>>>>> all currently supported versions of PyQt work along side PySide. I've
>>>>> tested with PyQt 4.8.3 and PySide 1.0.0.
>>>>>
>>>>> I haven't bothered chasing down old versions of PyQt as they seem
>>>>> elusive.
>>>>>
>>>>> Gerald.
>>>>>
>>>>> On 29/03/2011 3:25 AM, bu...@gm... wrote:
>>>>>> Looking forward, supporting the Python 3 compatible PyQt API is
>>>>>> likely the way to go.
>>>>>>
>>>>>> Le , Gerald Storer<gd...@mr...>   a écrit :
>>>>>>> On 28/03/2011 1:10 AM, Peter Butterworth wrote:
>>>>>>>
>>>>>>>
>>>>>>> Wouldn't it be possible to use a single backend compatible with both
>>>>>>>
>>>>>>> PyQt and Pyside ?
>>>>>>>
>>>>>>>
>>>>>>> The current Qt mpl backend uses the old PyQt slots/signals API
>>>>>> which PySide doesn't really support (there are some macros but they
>>>>>> don't work 100% the same). From a quick glance at the IPython
>>>>>> implementation it looks like they are using the new API which means
>>>>>> older versions (<4.5) of PyQt won't be supported. This might be ok, I
>>>>>> don't know.
>>>>>>> If it isn't then, there will need to be some try...excepts around
>>>>>> the place or separate back ends. If you ignore the PySide bugs I had
>>>>>> to work around I've only changed ~4 lines in the main backend.
>>>>>>>
>>>>>>> Pierre's formlayout is also using an obsolete method that isn't
>>>>>> present in PySide. I've opted to emulate it, but it would be best to
>>>>>> change the code to use the alternative method available in both PyQt
>>>>>> and PySide. formlayout also uses the old QString implementation of
>>>>>> PyQt, PySide only supports the new implementation where QString is
>>>>>> transparently convert to/from str/unicode. Setting QString = unicode
>>>>>> seems to work though.
>>>>>>>
>>>>>>> Gerald.
>>>>>>>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel