matplotlib-users Mailing List for matplotlib

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:

    Humufr>                     Hi, the problem who appearded with the
    Humufr> new pygtk version is resolved. Thanks to John and the guys
    Humufr> from pygtk.

    Humufr> http://bugzilla.gnome.org/show_bug.cgi?id=155304

Great.  Thanks for your help testing and tracking this one down.  I
updated the matplotlib FAQ

  http://matplotlib.sourceforge.net/faq.html#PYGTK24

Make sure that I got it right!

JDH

                    Hi,

the problem who appearded with the new pygtk version is resolved. Thanks 
to John and the guys from pygtk.

http://bugzilla.gnome.org/show_bug.cgi?id=155304

    Nicolas

On Wednesday 13 October 2004 09:22 am, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> I am seeing some strange behavior during IPython and
>     Darren> vanilla Python interactive sessions. My .matplotlibrc is
>     Darren> not being respected. I have tried making changes to the
>     Darren> copy in my home diretory and the one in
>     Darren> /usr/share/matplotlib. If I run the commands below or do
>     Darren> an execfile('/home/darren/test.py') from an interactive
>     Darren> session, .matplotlibrc is not read. If I run the script
>     Darren> from the console, .matplotlibrc is read.
>
>     Darren> I'm on gentoo with either 0.63.0 or the current cvs,
>     Darren> python 2.3.3. Has anyboody else seen this?
>
>
>     Darren> from matplotlib.matlab import * a=[1,10,100,1000,10000]
>     Darren> figure(1) loglog(a,a) figure(2) plot(a,a) show()
>
> Changes to rc made after you have started an interactive session would
> not be expected to have an effect -- the rc file is parsed when any
> matplotlib module is imported and not parsed again.  If you make some
> obvious change to the rc file in your home dir, say
>

I understand that these .matplotlibrc changes must be made before importing 
matplotlib. The problem I was having was that the file was not being read 
when starting ipython -pylab. I have reinstalled MPL a couple times now, and 
can't reproduce the problem.

Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I am seeing some strange behavior during IPython and
    Darren> vanilla Python interactive sessions. My .matplotlibrc is
    Darren> not being respected. I have tried making changes to the
    Darren> copy in my home diretory and the one in
    Darren> /usr/share/matplotlib. If I run the commands below or do
    Darren> an execfile('/home/darren/test.py') from an interactive
    Darren> session, .matplotlibrc is not read. If I run the script
    Darren> from the console, .matplotlibrc is read.

    Darren> I'm on gentoo with either 0.63.0 or the current cvs,
    Darren> python 2.3.3. Has anyboody else seen this?


    Darren> from matplotlib.matlab import * a=[1,10,100,1000,10000]
    Darren> figure(1) loglog(a,a) figure(2) plot(a,a) show()

Changes to rc made after you have started an interactive session would
not be expected to have an effect -- the rc file is parsed when any
matplotlib module is imported and not parsed again.  If you make some
obvious change to the rc file in your home dir, say

figure.facecolor : g    # figure facecolor; 0.75 is scalar gray

and *restart* ipython, do the changes take effect?

Note that you don't need to execfile with ipython, since that is what
the ipython 'run' command is for, and run does some smart things
before exec-ing your file, namely turning interactive off for the
duration of the run, which is more efficient.

There has been some interest in a loadrc command, which would be used
to load a specified rc file from the command line or script.  Should
be easy to add, and it is on the todo list.

Note that matplotlib in CVS has a new verbose setting which is
described at the bottom of the rc file.  By changing the verbose
setting to helpful, it will give you diagnostic information when you
run, including which rc file is loaded.  If you continue having
trouble with this, I suggest grabbing the latest from CVS and try
running with verbose : helpful.

JDH

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:

    Humufr>        Hi, I think to have found a bug in axis. You can't
    Humufr> choose a multiplelocator with 0.5 or 0.3 for example, you
    Humufr> can but the result is not what you're expecting. (see fig1
    Humufr> for the effect)

This appears to be a bug in your code

  xmajorLocator   = MultipleLocator(0.3)
  xmajorFormatter = FormatStrFormatter('%d')
                                        ^^^
You are telling it to format the numbers as integers.  Try   

  xmajorFormatter = FormatStrFormatter('%1.2f')


    Humufr> Another funny script (see scripts2 and scripts3) with tick
    Humufr> problem. Compare the two following scripts, the only
    Humufr> difference is to tell to yaxis to use the same
    Humufr> characteristic than xaxis. The very funny thing is to
    Humufr> change the ymajorLocator in xmajorLocator and etc with
    Humufr> you're doing the setting for the y axis... That influx in
    Humufr> the x axis. See fig2 and fig3.

    Humufr> Perhaps (probably) I'm doing something bad but I'm not
    Humufr> able to find where.

This is a problem with matplotlib but I don't have a quick fix for
you.  I'll look into it more when I get some time.  For now, sharing
the same tick locator between multiple axes is not recommended, though
I understand this is a desirable thing to be able to do.  You can make
two identical locators, however, and shouldn't have troubles, which if
I understand you correctly, is what you observe.

JDH

                        Hi John,

I'm using a debian linux with gcc 3.3.5, pygtk 2.4.0, precompiled

It's definitively a problem with pygtk2.4 because I have no problem to 
compile with 2.0 (from testing). Morever the problem comes only with the 
compilation. If I compile matplotlib with pygtk 2.2.0 I have no problem 
to use matplotlib even if I'm upgrading pygtk to 2.4.0. The problem 
seems to be in the header who comes from pygtk but I know nothing in 
these sort of file so I can't debug it.

Thanks,

    Nicolas


 > gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared 
--with-system-zlib --enable-nls --without-included-gettext 
--enable-__cxa_atexit --enable-clocale=gnu --enable-debug 
--enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-1)





gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -fPIC   -I/usr/local/include -I/usr/include 
-I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/python2.3 -c test.cpp
In file included from /usr/include/python2.3/Python.h:8,
                 from /usr/include/pygtk-2.0/pygobject.h:5,
                 from test.cpp:8:
/usr/include/python2.3/pyconfig.h:856:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from /usr/include/string.h:26,
                 from /usr/include/c++/3.3/cstring:51,
                 from test.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the 
previous definition
In file included from test.cpp:8:
/usr/include/pygtk-2.0/pygobject.h:140: error: parse error before `typename'
/usr/include/pygtk-2.0/pygobject.h:147: error: parse error before `typename'

and when I put the pkg-config inside the line a obtain exactly the same 
thing.

 gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -fPIC   -I/usr/local/include -I/usr/include 
-I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/python2.3 `pkg-config-c test.cpp
`pkg-config
gruel@wheeloftime:~/Matplotlib$ gcc -pthread -fno-strict-aliasing 
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC   -I/usr/local/include 
-I/usr/include -I/usr/include/pygtk-2.0 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/gtk-2.0/include -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/python2.3 `pkg-config 
pygtk-2.0` -c test.cpp
In file included from /usr/include/python2.3/Python.h:8,
                 from /usr/include/pygtk-2.0/pygobject.h:5,
                 from test.cpp:8:
/usr/include/python2.3/pyconfig.h:856:1: warning: "_POSIX_C_SOURCE" 
redefined
In file included from /usr/include/string.h:26,
                 from /usr/include/c++/3.3/cstring:51,
                 from test.cpp:1:
/usr/include/features.h:131:1: warning: this is the location of the 
previous definition
In file included from test.cpp:8:
/usr/include/pygtk-2.0/pygobject.h:140: error: parse error before `typename'
/usr/include/pygtk-2.0/pygobject.h:147: error: parse error before `typename'

I am trying to make an animation. The examples provided in matplotlib work 
very well. In my own closely related code, I am plotting 3 lines, each 
containing 5000 doubles.  Calls to manager.canvas.draw() take 0.4 seconds on 
my speedy gentoo setup, 0.15 seconds if I dont use mathtext tick labels. So I 
dont think this has anything to do with my numerix setup.

Is there a way around re-rendering the entire canvas?

Thanks,

Darren