matplotlib-devel Mailing List for matplotlib

Hi,
I had problems to build the version 1.0.1-r1 in gentoo with linux-3.0.0-rcX.
As chromium, the matplotlib need fix the use of 'linux2' label. See chromium
thread:
http://code.google.com/p/chromium/issues/detail?id=85845
Is very simple fix. If you want, i can send one patch.
Thanks,
-- 
Tiago Rezende Campos Falcão
http://www.tiagofalcao.com
--
ProFUSION | embedded systems
Computer Systems Laboratory - IC - Unicamp
Grupo Pró Software Livre - Unicamp
Laboratory of Information Systems - IC - Unicamp

Howdy,
https://www.ohloh.net/p/matplotlib/enlistments
has duplicate enlistments, which duplicates the LOC count and other
statistics, as best I can tell (from comparing the numbers reported by
Ohloh to a local run of sloccount).
I was trying to collect some stats from Ohloh for a grant, but I don't
want to report these numbers as they can be easily proven to be wrong
against a local check.
Cheers,
f

On 06/24/2011 10:24 AM, Benjamin Root wrote:
>
>
>
> I put up a pull request for adding the method "add_signal" to the 
> CallbackRegistry here: https://github.com/matplotlib/matplotlib/pull/381
>
> Ben Root
>
I put up an alternative request to just do away with the fixed set of 
signals altogether. I personally think this is more Pythonic, but I 
could be persuaded otherwise if there's a good reason to maintain the 
list of acceptable callbacks.
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On Sun, Jun 26, 2011 at 11:57 AM, Narf <na...@mu...> wrote:
> Hi,
>
> I'm porting a python application that makes use of matplotlib from
> gtk2 to gtk3.
I don't think matplotlib includes support for PyGObject yet, so gtk3
is not supported.

Hi,
I'm porting a python application that makes use of matplotlib from
gtk2 to gtk3. However, if I try to embed a matplotlib graph in a gtk3
app I get this:
/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40:
Warning: specified class size for type `PyGtkGenericCellRenderer' is
smaller than the parent type's `GtkCellRenderer' class size
 from gtk import _gtk
/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40:
Warning: g_type_get_qdata: assertion `node != NULL' failed
 from gtk import _gtk
/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/__init__.py:40:
Warning: g_ascii_strncasecmp: assertion `s2 != NULL' failed
 from gtk import _gtk
Segmentation fault
Is there any way to embed a plot in gtk3? If not, are there plans to
support gtk3 in the near future?
Thanks and regards,
Fran

Dale: something is wrong with the way you are closing out issues on the 
old matplotlib tracker because the two of mine you closed out are 
getting an ever accumulating number of copies of the same closeout 
message from you.
This is needless clutter on the old system, and means a lot of garbage 
emails for folks to reported the bugs.
I hope you can fix this quickly. Though I suppose by the time you get to 
it most users will have stopped tracking their issues in sourceforge in 
self defense.
-- Russell

On Fri, Jun 24, 2011 at 4:02 PM, Eric Firing <ef...@ha...> wrote:
>
>>>
>>> Darren,
>>>
>>> I thought the Sourceforge tracker was supposed to be closed to new
>>> entries
>>> after your transition to github--is that not the case?
>>
>> Unfortunately, disabling the sourceforge tracker makes the links I
>> created in the github issues unreachable.
>
> Then we have a real mess. Any ideas? Continuing with a couple hundred
> issues duplicated in the two trackers, and with people still filing issues
> in both, is completely unacceptable. I'm inclined to think that having gone
> this far, we have to simply shut off the sourceforge tracker and accept the
> loss of some information. As it is, conversation about issues that have
> been transferred to github is effectively disconnected from the original
> posters, without their having been notified. Ideally, all open issues on
> sourceforge would be closed with a final comment noting the transfer to
> github, but I suspect this is not feasible.
>
> You may switch any replies to matplotlib-devel if you like; maybe someone
> else has an idea.
I'm working on a mass-closing of issues at the sourceforge tracker. I
made a canned response that will direct to the github issues site.
Darren

On Fri, Jun 24, 2011 at 9:56 AM, Benjamin Root <ben...@ou...> wrote:
> Hello again,
>
> I am trying to figure out a regression in mplot3d code where the plot's
> ability to rotate and zoom are severely hindered. I want to do some
> profiling comparisons, but I need identical runs to do this. I know I
> probably could figure out how to properly simulate the motion of a mouse and
> button presses through the callback system, but I wanted to first see if
> anybody else has done anything like this.
>
> Thanks,
> Ben Root
>
Solved. I figured out how to use ldtp and use it to interact with an
example script. For future reference, I am attaching a script that
demonstrates this usage.
I hope it helps someone in the future! (Maybe we might even want to
consider it as an option to turn on in our test suite for a full test
system?).
Ben Root

Hello again,
I am trying to figure out a regression in mplot3d code where the plot's
ability to rotate and zoom are severely hindered. I want to do some
profiling comparisons, but I need identical runs to do this. I know I
probably could figure out how to properly simulate the motion of a mouse and
button presses through the callback system, but I wanted to first see if
anybody else has done anything like this.
Thanks,
Ben Root

On Thu, Jun 23, 2011 at 6:55 PM, Benjamin Root <ben...@ou...> wrote:
> On Thu, Jun 23, 2011 at 4:29 PM, Eric Firing <ef...@ha...> wrote:
>
>> On 06/23/2011 10:53 AM, John Hunter wrote:
>> > On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom<md...@st...>
>> wrote:
>> >> On 06/23/2011 03:49 PM, Benjamin Root wrote:
>> >>
>> >> Hello all,
>> >>
>> >> I am working to make mplot3d feature-parity with regular axes objects.
>> I
>> >> have come across a possible design flaw with the CallbackRegistry.
>> >>
>> >> Many of the Axes3D methods are merely wrappers around Axes methods
>> letting
>> >> it do the work for x and y axis and then let Axes3D do the same for the
>> z
>> >> axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
>> >> named "xlim_changed" and "ylim_changed". However, once that is set, it
>> does
>> >> not appear to be a way for me to add another signal of "zlim_changed"
>> in
>> >> Axes3D.cla(). I could replace self.callbacks with a new
>> CallbackRegistry,
>> >> but since there is a lot of interveaning code between that first
>> >> initialization of self.callbacks and coming back out of Axes.cla(), I
>> worry
>> >> that some callbacks may have been registered by then and would get
>> >> eliminated in the process.
>> >>
>> >> Is there a recommended way around this? Or maybe this is more evidence
>> that
>> >> we should move towards the use of a dictionary of axis objects and make
>> Axes
>> >> functions more agnostic to the number of axis?
>> >>
>> >> I don't know if there is a way around it as the code currently stands.
>> Your
>> >> proposal here:
>> >>
>> >> https://github.com/matplotlib/matplotlib/issues/379
>> >>
>> >> seems like one way out. Then the code that creates the
>> CallbackRegistry in
>> >> Axes.cla() could iterate through all the axes and create a callback
>> type for
>> >> each of them.
>> >>
>> >> However, to step back from this, I've never quite understood why it was
>> >> necessary to have a fixed set of callback types in the CallbackRegistry
>> to
>> >> begin with. It seems to me it comes from a history of callback
>> registry
>> >> classes I've seen in more static languages (such as libsigc++). We
>> could
>> >> just as easily create new signal types on the fly as they are
>> registered.
>> >> You lose some error checking, I suppose, if the caller and receiver
>> don't
>> >> agree on the names, but seems like a small price to pay.
>> >
>> > CallbackRegistry.signals is a "public" attribute, so is there anything
>> > preventing you Ben from just doing
>> >
>> > self.callbacks.signals.add('zlim_changed')
>> >
>> > and then connecting your desired callback?
>>
>> Yes, it requires some modification to the CallbackRegistry:
>>
>> def __init__(self, signals):
>> '*signals* is a sequence of valid signals'
>> self.signals = set(signals)
>> self.callbacks = dict([(s, dict()) for s in signals])
>> self._cid = 0
>>
>> So adding to the set of signals is not enough. It would be easy to made
>> an add_signal() method to take care of the two necessary steps. It
>> would seem simpler, however, to just let the signals be added
>> automatically as needed, as I believe Mike is suggesting.
>>
>> Actually, it looks like self.signals could be replaced by a property
>> that, upon reading, would return self.callbacks.keys(). Why use two
>> data structures if one will do? Of course, since signals is public,
>> that would represent API breakage--but of a rather obscure sort.
>>
>> (Shooting from the hip; I haven't looked closely.)
>>
>> Eric
>>
>>
> I am willing to go with whatever makes everyone happy. I have a limited
> amount of time, and my goal with the feature-parity branch (found here:
> https://github.com/WeatherGod/matplotlib/tree/mplot3d/consistency ) is to
> get a z-version of every single axis-related function into Axes3D, and make
> sure that most other functions that operate on arbitrary axis are capable of
> acting on the z-axis.
>
> However, I do not intend to make sure that everything works (only that
> there are no regressions). For example, setting axis label properties
> ('right', 'left', etc.) make little sense in the current context, and
> working with minor ticks do nothing in mplot3d. The idea is that if the
> added functions work, then that is good news. If the added functions do not
> work, then that can be a bug report.
>
> Therefore, anything that gets me to that goal would be fine. Heck, doing
> nothing about this might also work because there never was a callback for
> zlim_changed before, so not having it now will be no loss of function.
>
> Sorry for rambling,
> Ben Root
>
>
I put up a pull request for adding the method "add_signal" to the
CallbackRegistry here: https://github.com/matplotlib/matplotlib/pull/381
Ben Root

On Thu, Jun 23, 2011 at 4:29 PM, Eric Firing <ef...@ha...> wrote:
> On 06/23/2011 10:53 AM, John Hunter wrote:
> > On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom<md...@st...>
> wrote:
> >> On 06/23/2011 03:49 PM, Benjamin Root wrote:
> >>
> >> Hello all,
> >>
> >> I am working to make mplot3d feature-parity with regular axes objects.
> I
> >> have come across a possible design flaw with the CallbackRegistry.
> >>
> >> Many of the Axes3D methods are merely wrappers around Axes methods
> letting
> >> it do the work for x and y axis and then let Axes3D do the same for the
> z
> >> axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
> >> named "xlim_changed" and "ylim_changed". However, once that is set, it
> does
> >> not appear to be a way for me to add another signal of "zlim_changed" in
> >> Axes3D.cla(). I could replace self.callbacks with a new
> CallbackRegistry,
> >> but since there is a lot of interveaning code between that first
> >> initialization of self.callbacks and coming back out of Axes.cla(), I
> worry
> >> that some callbacks may have been registered by then and would get
> >> eliminated in the process.
> >>
> >> Is there a recommended way around this? Or maybe this is more evidence
> that
> >> we should move towards the use of a dictionary of axis objects and make
> Axes
> >> functions more agnostic to the number of axis?
> >>
> >> I don't know if there is a way around it as the code currently stands.
> Your
> >> proposal here:
> >>
> >> https://github.com/matplotlib/matplotlib/issues/379
> >>
> >> seems like one way out. Then the code that creates the CallbackRegistry
> in
> >> Axes.cla() could iterate through all the axes and create a callback type
> for
> >> each of them.
> >>
> >> However, to step back from this, I've never quite understood why it was
> >> necessary to have a fixed set of callback types in the CallbackRegistry
> to
> >> begin with. It seems to me it comes from a history of callback registry
> >> classes I've seen in more static languages (such as libsigc++). We
> could
> >> just as easily create new signal types on the fly as they are
> registered.
> >> You lose some error checking, I suppose, if the caller and receiver
> don't
> >> agree on the names, but seems like a small price to pay.
> >
> > CallbackRegistry.signals is a "public" attribute, so is there anything
> > preventing you Ben from just doing
> >
> > self.callbacks.signals.add('zlim_changed')
> >
> > and then connecting your desired callback?
>
> Yes, it requires some modification to the CallbackRegistry:
>
> def __init__(self, signals):
> '*signals* is a sequence of valid signals'
> self.signals = set(signals)
> self.callbacks = dict([(s, dict()) for s in signals])
> self._cid = 0
>
> So adding to the set of signals is not enough. It would be easy to made
> an add_signal() method to take care of the two necessary steps. It
> would seem simpler, however, to just let the signals be added
> automatically as needed, as I believe Mike is suggesting.
>
> Actually, it looks like self.signals could be replaced by a property
> that, upon reading, would return self.callbacks.keys(). Why use two
> data structures if one will do? Of course, since signals is public,
> that would represent API breakage--but of a rather obscure sort.
>
> (Shooting from the hip; I haven't looked closely.)
>
> Eric
>
>
I am willing to go with whatever makes everyone happy. I have a limited
amount of time, and my goal with the feature-parity branch (found here:
https://github.com/WeatherGod/matplotlib/tree/mplot3d/consistency ) is to
get a z-version of every single axis-related function into Axes3D, and make
sure that most other functions that operate on arbitrary axis are capable of
acting on the z-axis.
However, I do not intend to make sure that everything works (only that there
are no regressions). For example, setting axis label properties ('right',
'left', etc.) make little sense in the current context, and working with
minor ticks do nothing in mplot3d. The idea is that if the added functions
work, then that is good news. If the added functions do not work, then that
can be a bug report.
Therefore, anything that gets me to that goal would be fine. Heck, doing
nothing about this might also work because there never was a callback for
zlim_changed before, so not having it now will be no loss of function.
Sorry for rambling,
Ben Root

On 06/23/2011 10:53 AM, John Hunter wrote:
> On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom<md...@st...> wrote:
>> On 06/23/2011 03:49 PM, Benjamin Root wrote:
>>
>> Hello all,
>>
>> I am working to make mplot3d feature-parity with regular axes objects. I
>> have come across a possible design flaw with the CallbackRegistry.
>>
>> Many of the Axes3D methods are merely wrappers around Axes methods letting
>> it do the work for x and y axis and then let Axes3D do the same for the z
>> axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
>> named "xlim_changed" and "ylim_changed". However, once that is set, it does
>> not appear to be a way for me to add another signal of "zlim_changed" in
>> Axes3D.cla(). I could replace self.callbacks with a new CallbackRegistry,
>> but since there is a lot of interveaning code between that first
>> initialization of self.callbacks and coming back out of Axes.cla(), I worry
>> that some callbacks may have been registered by then and would get
>> eliminated in the process.
>>
>> Is there a recommended way around this? Or maybe this is more evidence that
>> we should move towards the use of a dictionary of axis objects and make Axes
>> functions more agnostic to the number of axis?
>>
>> I don't know if there is a way around it as the code currently stands. Your
>> proposal here:
>>
>> https://github.com/matplotlib/matplotlib/issues/379
>>
>> seems like one way out. Then the code that creates the CallbackRegistry in
>> Axes.cla() could iterate through all the axes and create a callback type for
>> each of them.
>>
>> However, to step back from this, I've never quite understood why it was
>> necessary to have a fixed set of callback types in the CallbackRegistry to
>> begin with. It seems to me it comes from a history of callback registry
>> classes I've seen in more static languages (such as libsigc++). We could
>> just as easily create new signal types on the fly as they are registered.
>> You lose some error checking, I suppose, if the caller and receiver don't
>> agree on the names, but seems like a small price to pay.
>
> CallbackRegistry.signals is a "public" attribute, so is there anything
> preventing you Ben from just doing
>
> self.callbacks.signals.add('zlim_changed')
>
> and then connecting your desired callback?
Yes, it requires some modification to the CallbackRegistry:
 def __init__(self, signals):
 '*signals* is a sequence of valid signals'
 self.signals = set(signals)
 self.callbacks = dict([(s, dict()) for s in signals])
 self._cid = 0
So adding to the set of signals is not enough. It would be easy to made 
an add_signal() method to take care of the two necessary steps. It 
would seem simpler, however, to just let the signals be added 
automatically as needed, as I believe Mike is suggesting.
Actually, it looks like self.signals could be replaced by a property 
that, upon reading, would return self.callbacks.keys(). Why use two 
data structures if one will do? Of course, since signals is public, 
that would represent API breakage--but of a rather obscure sort.
(Shooting from the hip; I haven't looked closely.)
Eric
>
> JDH
>
> ------------------------------------------------------------------------------
> 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

On Thu, Jun 23, 2011 at 3:11 PM, Michael Droettboom <md...@st...> wrote:
> On 06/23/2011 03:49 PM, Benjamin Root wrote:
>
> Hello all,
>
> I am working to make mplot3d feature-parity with regular axes objects. I
> have come across a possible design flaw with the CallbackRegistry.
>
> Many of the Axes3D methods are merely wrappers around Axes methods letting
> it do the work for x and y axis and then let Axes3D do the same for the z
> axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
> named "xlim_changed" and "ylim_changed". However, once that is set, it does
> not appear to be a way for me to add another signal of "zlim_changed" in
> Axes3D.cla(). I could replace self.callbacks with a new CallbackRegistry,
> but since there is a lot of interveaning code between that first
> initialization of self.callbacks and coming back out of Axes.cla(), I worry
> that some callbacks may have been registered by then and would get
> eliminated in the process.
>
> Is there a recommended way around this? Or maybe this is more evidence that
> we should move towards the use of a dictionary of axis objects and make Axes
> functions more agnostic to the number of axis?
>
> I don't know if there is a way around it as the code currently stands. Your
> proposal here:
>
> https://github.com/matplotlib/matplotlib/issues/379
>
> seems like one way out. Then the code that creates the CallbackRegistry in
> Axes.cla() could iterate through all the axes and create a callback type for
> each of them.
>
> However, to step back from this, I've never quite understood why it was
> necessary to have a fixed set of callback types in the CallbackRegistry to
> begin with. It seems to me it comes from a history of callback registry
> classes I've seen in more static languages (such as libsigc++). We could
> just as easily create new signal types on the fly as they are registered.
> You lose some error checking, I suppose, if the caller and receiver don't
> agree on the names, but seems like a small price to pay.
CallbackRegistry.signals is a "public" attribute, so is there anything
preventing you Ben from just doing
 self.callbacks.signals.add('zlim_changed')
and then connecting your desired callback?
JDH

On 06/23/2011 03:49 PM, Benjamin Root wrote:
> Hello all,
>
> I am working to make mplot3d feature-parity with regular axes 
> objects. I have come across a possible design flaw with the 
> CallbackRegistry.
>
> Many of the Axes3D methods are merely wrappers around Axes methods 
> letting it do the work for x and y axis and then let Axes3D do the 
> same for the z axis. In Axes.cla(), self.callbacks gets a 
> CallbackRegistry of signals named "xlim_changed" and "ylim_changed". 
> However, once that is set, it does not appear to be a way for me to 
> add another signal of "zlim_changed" in Axes3D.cla(). I could replace 
> self.callbacks with a new CallbackRegistry, but since there is a lot 
> of interveaning code between that first initialization of 
> self.callbacks and coming back out of Axes.cla(), I worry that some 
> callbacks may have been registered by then and would get eliminated in 
> the process.
>
> Is there a recommended way around this? Or maybe this is more 
> evidence that we should move towards the use of a dictionary of axis 
> objects and make Axes functions more agnostic to the number of axis?
I don't know if there is a way around it as the code currently stands. 
Your proposal here:
https://github.com/matplotlib/matplotlib/issues/379
seems like one way out. Then the code that creates the CallbackRegistry 
in Axes.cla() could iterate through all the axes and create a callback 
type for each of them.
However, to step back from this, I've never quite understood why it was 
necessary to have a fixed set of callback types in the CallbackRegistry 
to begin with. It seems to me it comes from a history of callback 
registry classes I've seen in more static languages (such as 
libsigc++). We could just as easily create new signal types on the fly 
as they are registered. You lose some error checking, I suppose, if the 
caller and receiver don't agree on the names, but seems like a small 
price to pay.
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hello all,
I am working to make mplot3d feature-parity with regular axes objects. I
have come across a possible design flaw with the CallbackRegistry.
Many of the Axes3D methods are merely wrappers around Axes methods letting
it do the work for x and y axis and then let Axes3D do the same for the z
axis. In Axes.cla(), self.callbacks gets a CallbackRegistry of signals
named "xlim_changed" and "ylim_changed". However, once that is set, it does
not appear to be a way for me to add another signal of "zlim_changed" in
Axes3D.cla(). I could replace self.callbacks with a new CallbackRegistry,
but since there is a lot of interveaning code between that first
initialization of self.callbacks and coming back out of Axes.cla(), I worry
that some callbacks may have been registered by then and would get
eliminated in the process.
Is there a recommended way around this? Or maybe this is more evidence that
we should move towards the use of a dictionary of axis objects and make Axes
functions more agnostic to the number of axis?
Thanks,
Ben Root

Yep. That's the reason that's not the default setting. The docs for 
svg.fonttype says:
#svg.fonttype : 'path' # How to handle SVG fonts:
# 'none': Assume fonts are installed on the machine where the SVG 
will be viewed.
# 'path': Embed characters as paths -- supported by most SVG renderers
# 'svgfont': Embed characters as SVG fonts -- supported only by Chrome,
# Opera and Safari
Mike
On 06/22/2011 03:56 PM, Dieter Weber wrote:
> Hi,
> it's not directly a problem with matplotlib, but I just wanted to let
> you know that SVGs generated with
>
> matplotlib.rcParams['svg.fonttype'] = 'svgfont'
>
> hang inkscape<https://bugs.launchpad.net/inkscape/+bug/800265>.
>
> Greetings,
> Dieter
>
>
> ------------------------------------------------------------------------------
> 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
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hi,
it's not directly a problem with matplotlib, but I just wanted to let
you know that SVGs generated with 
matplotlib.rcParams['svg.fonttype'] = 'svgfont'
hang inkscape <https://bugs.launchpad.net/inkscape/+bug/800265>.
Greetings,
Dieter

Hi Mike,
On Tue, Jun 21, 2011 at 6:07 AM, Michael Droettboom <md...@st...> wrote:
> 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.
here's the files from the machine that showed the problem:
http://fperez.org/tmp/fontList.cache
http://fperez.org/tmp/matplotlibrc
I hope they help you track down what can be happening, and perhaps a
layer of protection can be added to mpl so that it recovers gracefully
from this condition.
Cheers,
f

Hello all,
I am trying to track down an odd bug I found in mplot3d and I need some help
in understanding some core parts of matplotlib. The issue is that when one
colors scatterpoints in mplot3d with a colormap, then the points looses the
colors after any sort of interaction. I traced the problem down to the
Patch3DCollection object assuming that all color data will be stored as part
of facecolors and edgecolors. However, this does not appear to be the case
when using a colormap.
Because Patch3DCollection wants to modify the alpha value of the scatter
points based on the distance the points are from the "camera", I need/want a
consistent spot for modifying the alpha values on each draw. Is there some
sort of standard way to make the colormap data end up in the
facecolor/edgecolor members? Or am I going to have to code for each case?
If the latter, what is the appropriate test to know which situation is going
on?
Thanks,
Ben Root

On Tuesday, June 21, 2011, Eric Firing <ef...@ha...> wrote:
> Suggestion: let's try to keep the labels short. I think that will make
> it easier to see what we have as the number of labels increases, and
> will make the labels a bit less visually overwhelming. (It looks like
> existing labels can be edited in the Manage Labels function, but I was
> afraid to try for fear I would mess something up.)
>
> e.g.,
> mac-osx -> OSX or Mac
> ms-windows -> Win or MS
> sourceforge-import -> SF
>
>
> I have been marking feature requests from the old SF as "wishlist"; I
> hope that is consistent with the intentions of whoever made the label.
>
> Eric
>
I am fine with shortening them. I have also interpreated wishlist to mean that.
I also want to bring in lessons I learned when participating in
Ubuntu's BugSquad. For the "triaging" process, the report needs to be
confirmed. Whenever we confirm a bug, we can tag it as such. If more
information is needed or if you don't have time to confirm, you can
tag it as "need_confirm". The tags are updated as progress is made.
There is also "ongoing" which I take to mean that the report has been
assigned and actively worked on.
Any others we want (or changes to the idea)?
Ben Root

Suggestion: let's try to keep the labels short. I think that will make 
it easier to see what we have as the number of labels increases, and 
will make the labels a bit less visually overwhelming. (It looks like 
existing labels can be edited in the Manage Labels function, but I was 
afraid to try for fear I would mess something up.)
e.g.,
mac-osx -> OSX or Mac
ms-windows -> Win or MS
sourceforge-import -> SF
I have been marking feature requests from the old SF as "wishlist"; I 
hope that is consistent with the intentions of whoever made the label.
Eric

Hi Mike,
On Tue, Jun 21, 2011 at 6:07 AM, Michael Droettboom <md...@st...> wrote:
> 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.
I think you're right, because now at my office I can't even reproduce
the problem.
The machine where I saw it is at home, so tonight I'll fish out the
font cache file and send it to you so you can investigate, along with
my matplotlibrc file, just in case.
Thanks, and sorry for the semi-false alarm!
Cheers,
f

Hi Mike,
your changes in the pull request fixed the problem for me, thanks a lot!
Greetings,
Dieter
Am Dienstag, den 21.06.2011, 09:01 -0400 schrieb Michael Droettboom:
> 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
> ------------------------------------------------------------------------------
> 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

Sandro, did you ever figure anything out with this behavior? I see the same
thing (example scripts for which the docs contain the Exception error yet
run just fine from the command line). 
Sandro Tosi-4 wrote:
> 
> Hi,
> 
> On Tue, Jan 4, 2011 at 19:11, Jakub Wilk <jw...@de...> wrote:
>> Package: python-matplotlib-doc
>> Version: 0.99.3-1
>> Severity: minor
>>
>> There are several "Exception occurred rendering plot" warnings in the
>> generated documentation:
>>
>> $ cd /usr/share/doc/python-matplotlib-doc/html/ && grep -r 'Exception
>> occurred' .
>> ./users/screenshots.html:[ 
>> href="../plot_directive/mpl_examples/pylab_examples/scatter_demo2.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./users/screenshots.html:[ 
>> href="../plot_directive/mpl_examples/api/date_demo.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./users/screenshots.html:[ 
>> href="../plot_directive/mpl_examples/pylab_examples/finance_work2.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./users/screenshots.html:[ 
>> href="../plot_directive/pyplots/plotmap.py">source code ]<p>Exception
>> occurred rendering plot.</p>
>> ./examples/units/date_support.html:[ 
>> href="../../plot_directive/mpl_examples/units/date_support.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/units/basic_units.html:[ 
>> href="../../plot_directive/mpl_examples/units/basic_units.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/units/artist_tests.html:[ 
>> href="../../plot_directive/mpl_examples/units/artist_tests.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/axes_grid/demo_image.html:[ 
>> href="../../plot_directive/mpl_examples/axes_grid/demo_image.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/data_helper.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/data_helper.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/date_demo2.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/date_demo2.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/geo_demo.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/geo_demo.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/centered_ticklabels.html:[ external"
>> href="../../plot_directive/mpl_examples/pylab_examples/centered_ticklabels.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/finance_demo.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/finance_demo.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/date_demo1.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/date_demo1.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/finance_work2.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/finance_work2.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/loadrec.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/loadrec.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/scatter_demo2.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/scatter_demo2.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/pylab_examples/multipage_pdf.html:[ 
>> href="../../plot_directive/mpl_examples/pylab_examples/multipage_pdf.py">source
>> code ]<p>Exception occurred rendering plot.</p>
>> ./examples/api/date_demo.html:[ 
>> href="../../plot_directive/mpl_examples/api/date_demo.py">source
>> code ]<p>Exception occurred rendering plot.</p>
> 
> The updated list is:
> 
> api/axes_api.html
> api/pyplot_api.html
> examples/api/hinton_demo.html
> examples/api/radar_chart.html
> examples/api/sankey_demo.html
> examples/pylab_examples/anchored_artists.html
> examples/pylab_examples/arrow_demo.html
> examples/pylab_examples/axes_zoom_effect.html
> examples/pylab_examples/data_helper.html
> examples/pylab_examples/demo_bboximage.html
> examples/pylab_examples/geo_demo.html
> examples/pylab_examples/image_demo2.html
> examples/pylab_examples/legend_auto.html
> examples/pylab_examples/multipage_pdf.html
> examples/units/artist_tests.html
> examples/units/basic_units.html
> users/annotations_guide.html
> users/screenshots.html
> 
> But I have some problems debugging these issues, since when I run the
> code by-hand, it works fine but in the html file it's not shown. How
> can I debug that? in the log there's nothing about these problems (but
> other error, I'll follow them up in another mail).
> 
> Thanks in advance,
> -- 
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> 
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand 
> malware threats, the impact they can have on your business, and how you 
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-----
Josh Hemann
Group Manager - Advanced Analytics 
Sports Authority
jhemann at sportsauthority com 
-- 
View this message in context: http://old.nabble.com/Re%3A--Python-modules-team--Bug-608932%3A-python-matplotlib-doc%3A-%22Exception-occurred-rendering-plot%22-tp30695603p31894837.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hi Dan,
Is 
http://matplotlib.sourceforge.net/examples/api/radar_chart.html?highlight=radar
this the example you are referring to? If so, this is the one I submitted
to the gallery a couple of years ago and I would be happy to see the
underlying methodology improved.
Josh
texas_ranger wrote:
> 
> Hello dev people,
> 
> I had an app where I needed the radar chart (aka Kiviat diagrams) source
> code out of matplotlib. Turns out the example source code is very limited
> the way it is currently written. Not good.
> 
> I re-wrote parts of the source code to make it much more flexible and
> easier
> to include in an app. For example, if run in stand-alone mode, the user
> can
> specify upto 25 different radar charts in one window. Titles and labels
> are
> much more general as well. The legend can have multiple columns, etc.
> 
> If anyone is interested, I will be happy to send you my source code,
> hoping
> you might consider replacing the current version in the docs with the one
> I'll send.
> 
> Just reply and I'll send the code. You can decide from there whether to
> use
> it to replace current version.
> 
> I did not want to attach the code if no one is interested.
> 
> Daniel Barnette
> 
> ------------------------------------------------------------------------------
> Xperia(TM) PLAY
> It's a major breakthrough. An authentic gaming
> smartphone on the nation's most reliable network.
> And it wants your games.
> http://p.sf.net/sfu/verizon-sfdev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
-----
Josh Hemann
Group Manager - Advanced Analytics 
Sports Authority
jhemann at sportsauthority com 
-- 
View this message in context: http://old.nabble.com/improved-source-code-for-radar-chart-example-in-matplotlib-docs-tp31351398p31894586.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.