matplotlib

On Sat, 28 Jul 2012, Dimitrios Apostolou wrote:

> Even though some things needed time-consuming hacks, matplotlib worked
> fine. Thanks for your work on this fantastic library!  And if you are
> curious you can see my automatic generated graphs (temporarily) at:
>
> http://teras-ics.mooo.com:8003

Sorry but my primary PC died last night, this page will be unavailable for 
some time. :-(


> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

I didn't add this signature! Either Sourceforge is advertising through 
email now too, or my MUA has a virus...


Dimitris

Collin,

My problem is not with the actual "resize" functionality, which works fine,
but with attaching a callback to a resize_event ("say_hello" in my example).
Specifically, I have a figure that uses blitting, i.e., saves the background
and only updates some artists as a function of events in another figure.
Obviously, when the user resizes the blitting figure, the background changes
and the snapshot image has to be regenerated. Hence my need to attach a
callback to a resize event. This works fine in other backends that support
blitting, but not in Qt4Agg.

The reason why it doesn't work lies in
lib/matplotlib/backends/backend_qt4.py, where the last line is missing in: 

def resizeEvent( self, event ):
    ...
    FigureCanvasBase.resize_event(self) 

I was hoping that someone could confirm that this is a bug and that adding
the line is the correct fix for the problem. I was then going to file a bug
report.

Thanks,
Stefan

-- 
View this message in context: http://old.nabble.com/Matplotlib-Qt4Agg-backend-ignores-%27resize_event%27-tp34205981p34226500.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On 2012/07/23 11:43 AM, Damon McDougall wrote:
> Hello all,
>
> So, as per Philip's suggestion
> (https://github.com/matplotlib/matplotlib/pull/737) I've started
> encapsulating fplot functionality into a class. The point of this is so
> that the user can call either of the following:
>
> FPlot_instance = ax.fplot(f, [x0, y0, x1, y1])
> ax.fplot(FPlot_instance, ...)

The second of these seems odd to me; I would expect FPlot_instance to 
have a __call__ method, so the normal use of an existing instance would be

FPlot_instance(...)

Also, regarding the second argument in the first form: I would think it 
more natural to split it up into a required [x0, x1] and an optional 
[y0, y1], with autoscaling if it is not provided.

Eric

On Monday, July 23, 2012, Eric Firing wrote:

> On 2012/07/23 11:43 AM, Damon McDougall wrote:
> > Hello all,
> >
> > So, as per Philip's suggestion
> > (https://github.com/matplotlib/matplotlib/pull/737) I've started
> > encapsulating fplot functionality into a class. The point of this is so
> > that the user can call either of the following:
> >
> > FPlot_instance = ax.fplot(f, [x0, y0, x1, y1])
> > ax.fplot(FPlot_instance, ...)
>
> The second of these seems odd to me; I would expect FPlot_instance to
> have a __call__ method, so the normal use of an existing instance would be
>
> FPlot_instance(...)
>
> Also, regarding the second argument in the first form: I would think it
> more natural to split it up into a required [x0, x1] and an optional
> [y0, y1], with autoscaling if it is not provided.
>
> Eric


Agreed, it is a bit odd/awkward, and I also agree about autoscaling.

With the whole viewlims callbacks, make sure you have the class disconnect
itself upon removal, such as through cla().
l <https://lists.sourceforge.net/lists/listinfo/matplotlib-devel>
Cheers!
Ben Root

On Mon, Jul 23, 2012 at 08:38:07PM -0400, Benjamin Root wrote:
> On Monday, July 23, 2012, Eric Firing wrote:
> 
> > On 2012/07/23 11:43 AM, Damon McDougall wrote:
> > > Hello all,
> > >
> > > So, as per Philip's suggestion
> > > (https://github.com/matplotlib/matplotlib/pull/737) I've started
> > > encapsulating fplot functionality into a class. The point of this is so
> > > that the user can call either of the following:
> > >
> > > FPlot_instance = ax.fplot(f, [x0, y0, x1, y1])
> > > ax.fplot(FPlot_instance, ...)
> >
> > The second of these seems odd to me; I would expect FPlot_instance to
> > have a __call__ method, so the normal use of an existing instance would be
> >

That is awesome! I didn't know the __call__ method existed! That's a
much better way of doing it. I love Python.

> >
> > FPlot_instance(...)
> >
> > Also, regarding the second argument in the first form: I would think it
> > more natural to split it up into a required [x0, x1] and an optional
> > [y0, y1], with autoscaling if it is not provided.
> >
> > Eric
> 
> 
> Agreed, it is a bit odd/awkward, and I also agree about autoscaling.
> 
> With the whole viewlims callbacks, make sure you have the class disconnect
> itself upon removal, such as through cla().
>

So are you suggesting autoscaling over a callback?

> l <https://lists.sourceforge.net/lists/listinfo/matplotlib-devel>
> Cheers!
> Ben Root

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Fri, Jul 20, 2012 at 3:21 PM, John Hunter <jdh2358@...> wrote:

> I would like to discuss a timetable towards a python3 release (1.2 or
> 2.0).  I'll throw this out there, and am happy to make modifications
> according to feedback
>
> Aug 20th : feature freeze and branch.  bugfixes only going forward from
> this point
>
> Sept 15th: rc1
>
> Oct 7th: rc2
>
> Oct 15th release
>
> I know we have lots of open and interesting pull requests to get in, and
> so if we need to push these times back to get them in that is fine.  Just
> wanted to put something out there to see if this timeline seems plausible
> to people.
>
> JDH
>
>
I think the schedule is reasonable.  We are going to need significant help
getting through our backlog of PRs.  At the very least, we need to identify
which ones are release critical or not.

Just as a note, I don't know whether or not we want to have my axes.py
refactor included in this release or not.  If most of my attention is going
to be on the documentation and PR push, it is extremely unlikely I am going
to get much further with it in the next couple of months.

Ben Root

On 2012/07/20 9:34 AM, Ryan May wrote:
> Hi,
>
> I'm here at the SciPy sprints trying to fix switching inline/gui for
> the ipython notebook. I've noticed something weird about
> matplotlib.use() :
>
>      if 'matplotlib.backends' in sys.modules:
>          if warn: warnings.warn(_use_error_msg)
>          return
>      if arg.startswith('module://'):
>          name = arg
>      else:
>          # Lowercase only non-module backend names (modules are case-sensitive)
>          arg = arg.lower()
>          name = validate_backend(arg)
>      rcParams['backend'] = name
>
> Notice the return if it finds the module loaded. This return basically
> makes it impossible to make use() have any effect one backends has
> been loaded. However, matplotlib.pyplot.switch_backend(). Eric added
> this in 2008 as a bug fix, but no more detail than that. Does anyone
> have a problem putting the return with the warning? Therefore if you
> pass warn=False, you can actually make the setting take effect, but
> the average user won't accidentally shoot their foot off. Something
> like:
>
>      if 'matplotlib.backends' in sys.modules:
>          if warn:
>              warnings.warn(_use_error_msg)
>              return

This would be defeating the basic idea: use() is *only* designed to take 
effect *once*.  If you need to switch backends, it takes more than what 
use() does, hence the need for switch_backend().  (But see below.)

The warn=False invocation of use, with the return statement were it is 
now, is for the case where you may have a script or module that 
specifies a backend (in case it is the first or only import of 
matplotlib), but that may itself be imported or called by something else 
that has already imported matplotlib and set the backend.  In this case 
we want the warning to be suppressed, which is all the warn=False flag 
is supposed to do.  I use this myself.

So it looks like the problem is that switch_backends is broken because 
what it needs matplotlib.use to do is go ahead and make the switch. This 
could be done by adding a force=True kwarg (default would be False) to 
matplotlib.use, or by deleting the reference to the backends module from 
sys.modules in switch_backends before calling matplotlib.use.  A 
variation would be to use the force kwarg and to include the 
switch_backends logic, or at least the reload line, in matplotlib.use. 
That probably makes sense: add the force kwarg, and when the module is 
replaced, reload it immediately within matplotlib.use.  Then 
pyplot.switch_backends only needs to do the pyplot-specific operations. 
  I think that is the cleanest solution.

Eric



>
>
> Ryan
>

On Fri, Jul 20, 2012 at 3:20 PM, Eric Firing <efiring@...> wrote:

> On 2012/07/20 9:34 AM, Ryan May wrote:
> > Hi,
> >
> > I'm here at the SciPy sprints trying to fix switching inline/gui for
> > the ipython notebook. I've noticed something weird about
> > matplotlib.use() :
> >
> >      if 'matplotlib.backends' in sys.modules:
> >          if warn: warnings.warn(_use_error_msg)
> >          return
> >      if arg.startswith('module://'):
> >          name = arg
> >      else:
> >          # Lowercase only non-module backend names (modules are
> case-sensitive)
> >          arg = arg.lower()
> >          name = validate_backend(arg)
> >      rcParams['backend'] = name
> >
> > Notice the return if it finds the module loaded. This return basically
> > makes it impossible to make use() have any effect one backends has
> > been loaded. However, matplotlib.pyplot.switch_backend(). Eric added
> > this in 2008 as a bug fix, but no more detail than that. Does anyone
> > have a problem putting the return with the warning? Therefore if you
> > pass warn=False, you can actually make the setting take effect, but
> > the average user won't accidentally shoot their foot off. Something
> > like:
> >
> >      if 'matplotlib.backends' in sys.modules:
> >          if warn:
> >              warnings.warn(_use_error_msg)
> >              return
>
> This would be defeating the basic idea: use() is *only* designed to take
> effect *once*.  If you need to switch backends, it takes more than what
> use() does, hence the need for switch_backend().  (But see below.)
>
> The warn=False invocation of use, with the return statement were it is
> now, is for the case where you may have a script or module that
> specifies a backend (in case it is the first or only import of
> matplotlib), but that may itself be imported or called by something else
> that has already imported matplotlib and set the backend.  In this case
> we want the warning to be suppressed, which is all the warn=False flag
> is supposed to do.  I use this myself.
>
> So it looks like the problem is that switch_backends is broken because
> what it needs matplotlib.use to do is go ahead and make the switch. This
> could be done by adding a force=True kwarg (default would be False) to
> matplotlib.use, or by deleting the reference to the backends module from
> sys.modules in switch_backends before calling matplotlib.use.  A
> variation would be to use the force kwarg and to include the
> switch_backends logic, or at least the reload line, in matplotlib.use.
> That probably makes sense: add the force kwarg, and when the module is
> replaced, reload it immediately within matplotlib.use.  Then
> pyplot.switch_backends only needs to do the pyplot-specific operations.
>   I think that is the cleanest solution.
>
> Eric
>
>
I like the "force" idea very much.  It means exactly what it says.

Ben Root

On Fri, Jul 20, 2012 at 3:20 PM, Eric Firing <efiring@...> wrote:
> This would be defeating the basic idea: use() is *only* designed to take
> effect *once*.  If you need to switch backends, it takes more than what
> use() does, hence the need for switch_backend().  (But see below.)
>
> The warn=False invocation of use, with the return statement were it is
> now, is for the case where you may have a script or module that
> specifies a backend (in case it is the first or only import of
> matplotlib), but that may itself be imported or called by something else
> that has already imported matplotlib and set the backend.  In this case
> we want the warning to be suppressed, which is all the warn=False flag
> is supposed to do.  I use this myself.
>
> So it looks like the problem is that switch_backends is broken because
> what it needs matplotlib.use to do is go ahead and make the switch. This
> could be done by adding a force=True kwarg (default would be False) to
> matplotlib.use, or by deleting the reference to the backends module from
> sys.modules in switch_backends before calling matplotlib.use.  A
> variation would be to use the force kwarg and to include the
> switch_backends logic, or at least the reload line, in matplotlib.use.
> That probably makes sense: add the force kwarg, and when the module is
> replaced, reload it immediately within matplotlib.use.  Then
> pyplot.switch_backends only needs to do the pyplot-specific operations.
>   I think that is the cleanest solution.

I agree, this is a better way to go. (And occurred to me as well after
the initial PR.)

Glad I asked rather than doing my 2-line fix. The updated PR is at
https://github.com/matplotlib/matplotlib/pull/1028

Ryan

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On 07/19/2012 09:24 AM, Benjamin Root wrote:
> Working on my refactor of axes.py, I needed to use defaultdict and
> possibly OrderedDict from the collections standard module.  Problem is
> that matplotlib already has a collections.py module in lib/matplotlib.
> This file takes precedence in the import process and gets in my way.
> Does anybody know of any way to force the import to do what I want?
> This has completely stumped me.

Looking at http://www.python.org/dev/peps/pep-0328/ it appears that for 
2.6 and later, using

from __future__ import absolute_import

should cause "import collections" to refer to the standard library.

Eric

>
> Thanks,
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Thu, Jul 19, 2012 at 2:32 PM, Eric Firing <efiring@...> wrote:

> On 07/19/2012 09:24 AM, Benjamin Root wrote:
> > Working on my refactor of axes.py, I needed to use defaultdict and
> > possibly OrderedDict from the collections standard module.  Problem is
> > that matplotlib already has a collections.py module in lib/matplotlib.
> > This file takes precedence in the import process and gets in my way.
> > Does anybody know of any way to force the import to do what I want?
> > This has completely stumped me.
>
> Looking at http://www.python.org/dev/peps/pep-0328/ it appears that for
> 2.6 and later, using
>
> from __future__ import absolute_import
>
> should cause "import collections" to refer to the standard library.
>
> Eric
>
>
Good to know.  But aren't we supporting 2.5, or did we decide on 2.6?

Ben

On 07/19/2012 09:37 AM, Benjamin Root wrote:
>
>
> On Thu, Jul 19, 2012 at 2:32 PM, Eric Firing <efiring@...
> <mailto:efiring@...>> wrote:
>
>     On 07/19/2012 09:24 AM, Benjamin Root wrote:
>      > Working on my refactor of axes.py, I needed to use defaultdict and
>      > possibly OrderedDict from the collections standard module.
>       Problem is
>      > that matplotlib already has a collections.py module in
>     lib/matplotlib.
>      > This file takes precedence in the import process and gets in my way.
>      > Does anybody know of any way to force the import to do what I want?
>      > This has completely stumped me.
>
>     Looking at http://www.python.org/dev/peps/pep-0328/ it appears that for
>     2.6 and later, using
>
>     from __future__ import absolute_import
>
>     should cause "import collections" to refer to the standard library.
>
>     Eric
>
>
> Good to know.  But aren't we supporting 2.5, or did we decide on 2.6?

 >=2.6 only from now on.  This is so that we can support 3.2+ in the 
same codebase.

Eric

>
> Ben
>

On Thu, Jul 19, 2012 at 4:39 AM, Philippe MALLET
<philippe.mallet@...:

> Dear all,
>
> When I use the Qt4Agg backend and I want to save the figure by clicking the
> save button, I get this Error message:
>
> kfilemodule(5951): couldn't create slave: "Unable to create io-slave:
> klauncher said: Protocole «  » inconnu.
>
> It is like an empty string is given for the protocole name.
>
> infos:
> Distribution: Archlinux
> Python 2.7.3
> matplotlib 1.1.1
> Kde 4.8.4
> Linux  3.4.5-1-ARCH x86_64
>
> Best regards,
>
>
Philippe,

Was there a more complete traceback displayed?

Ben Root

On Thu, Jul 19, 2012 at 5:39 AM, Philippe MALLET
<philippe.mallet@...> wrote:
> Dear all,
>
> When I use the Qt4Agg backend and I want to save the figure by clicking the
> save button, I get this Error message:
>
> kfilemodule(5951): couldn't create slave: "Unable to create io-slave:
> klauncher said: Protocole «  » inconnu.
>
> It is like an empty string is given for the protocole name.
>
> infos:
> Distribution: Archlinux
> Python 2.7.3
> matplotlib 1.1.1
> Kde 4.8.4
> Linux  3.4.5-1-ARCH x86_64

I don't think this is a matplotlib bug. It is probably a KDE
configuration problem specific to your system. See
http://forums.gentoo.org/viewtopic-t-601154.html.

You could try editing your backend_qt4.py, in the save_figure method,
to add QFileDialog.DontUseNativeDialog to the end of the list of
arguments passed to _getSaveFileName. But that is only a workaround.

Darren

On Thu, Jul 19, 2012 at 4:43 AM, Philippe MALLET
<philippe.mallet@...:

> **
>
> Dear all,
>
>
>
> when I use the GTKAgg backend, I get the following message when I launch
> Ipython -pylab:
>
>
>
> ** (process:27239): WARNING **: Trying to register gtype
> 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
>
>
>
> ** (process:27239): WARNING **: Trying to register gtype
> 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
>
>
>
> ** (process:27239): WARNING **: Trying to register gtype 'GSocketMsgFlags'
> as enum when in fact it is of type 'GFlags'
>
>
>
> Infos:
>
> Distribution: Archlinux
>
> Python 2.7.3
>
> matplotlib 1.1.1
>
> Linux  3.4.5-1-ARCH x86_64
>
> Best regards,
>
>
Phillippe,

What is the full version number of GTK on your system (i.e., #.#.#)?

Cheers!
Ben Root

Le jeudi 19 juillet 2012 08:18:14 Benjamin Root a écrit :




On Thu, Jul 19, 2012 at 4:43 AM, Philippe MALLET <philippe.mallet@...> 
wrote:

Dear all,
 
when I use the GTKAgg backend, I get the following message when I launch 
Ipython -pylab:
 
** (process:27239): WARNING **: Trying to register gtype 'GMountMountFlags' as 
enum when in fact it is of type 'GFlags' 
 
** (process:27239): WARNING **: Trying to register gtype 'GDriveStartFlags' as 
enum when in fact it is of type 'GFlags' 
 
** (process:27239): WARNING **: Trying to register gtype 'GSocketMsgFlags' as 
enum when in fact it is of type 'GFlags' 
 
Infos:
Distribution: Archlinux
Python 2.7.3
matplotlib 1.1.1
Linux  3.4.5-1-ARCH x86_64

Best regards,



Phillippe,

What is the full version number of GTK on your system (i.e., #.#.#)?

Cheers!
Ben Root



Sorry I forgot to mention it:
gtk 1.2.10
gtk2 2.24.10
gtk3 3.4.3
pygtk 2.24

Cheers!