matplotlib-users Mailing List for matplotlib (Page 8)

Yes, it looks like if it were an "unsigned int", we would have been 
okay.  That looks like (essentially) what your patch does, but in a C++ 
idiom.  I'll submit your patch and put a note out to the Windows guys to 
help test it.  There's a good chance that if it compiles at all, it 
should work.

Thanks for getting to the bottom of this.

Cheers,
Mike

Malte Marquarding wrote:
> Hi
>
> Attached is the the patch. It uses stringstream, so I don't know if it 
> will work on all platforms. I am not a windows person ;-)
> I didn't read your email properly about  the existence of "atoll", so 
> as I am a c++er I am a bit more comfortable with stringstream.
>
> Cheers,
> Malte.
>
>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, May 15, 2008 at 10:20:23AM +0200, Friedrich Hagedorn wrote:
> Hello,
> 
> I think the following is'nt right:
> 
> In [1]: plot([1,2,3])
> Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]
> 
> In [2]: ylim(-4,4)
> Out[2]: (-4, 4)
> 
> In [3]: axhline()
> Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>
> 
> In [4]: ylim()
> Out[4]: (0.0, 3.0)

With the attached patch the thinks are ok:

In [1]: plot([1,2,3])
Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ac>]

In [2]: ylim(-4,4)
Out[2]: (-4, 4)

In [3]: xlim(-4,4)
Out[3]: (-4, 4)

In [4]: axhline()
Out[4]: <matplotlib.lines.Line2D object at 0x8fa6e6c>

In [5]: axvline()
Out[5]: <matplotlib.lines.Line2D object at 0x9062fec>

In [6]: xlim()
Out[6]: (-4.0, 4.0)

In [7]: ylim()
Out[7]: (-4.0, 4.0)

By,

  Friedrich

Hello,

I think the following is'nt right:

In [1]: plot([1,2,3])
Out[1]: [<matplotlib.lines.Line2D object at 0x8f9b0ec>]

In [2]: ylim(-4,4)
Out[2]: (-4, 4)

In [3]: axhline()
Out[3]: <matplotlib.lines.Line2D object at 0x8f9bc0c>

In [4]: ylim()
Out[4]: (0.0, 3.0)

By,

  Friedrich

Hi Jon,

On Thursday 15 May 2008 03:17:29 Jon Choy wrote:
> I maybe asking a dumb question, forgive me I'm a novice. I try to add
> a ylabel and the left portion of the signal name is cut off when it is
> plotted. I can't seem to find the option for displaying the whole
> signal. Or do I need to resize the plotting window?

I think resizing the window is a good first attempt to see, if there is 
everything written, but not shown to you.
Is your ylabel a very long string? Could you provide a small stand-alone 
example of your problem, please?

regards
Matthias

Hi

Attached is the the patch. It uses stringstream, so I don't know if  
it will work on all platforms. I am not a windows person ;-)
I didn't read your email properly about  the existence of "atoll", so  
as I am a c++er I am a bit more comfortable with stringstream.

Cheers,
Malte.

Hi,

we were on the right track just the inverse. The number of argv[4] is  
bigger then MAX_LONG on 32bit.
So what I did is:

unsigned long tmplong;
std::stringstream ss;
ss.str(argv[4]);
ss >> tmplong;
bboxo = (PyObject*)tmplong;

Now it works.

Also, I will change all other atol()'s to stringstream, we are c++  
er's anyway.

I will check out  the svn and send a patch. Where do I send it to?

Cheers,
Malte

On 15/05/2008, at 8:40 AM, Malte Marquarding wrote:

> Hi,
>
> unfortunately  32-bit ;-) I tried digging around, but I don't know
> much about tcl/tk. Seeing a  char string argv atol'ed into a pointer
> address left me with an uncomfortable feeling...
> Anyway her is the argv value
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7c516c0 (LWP 5638)]
> 0xb6f4500e in PyAggImagePhoto (clientdata=0x0, interp=0x87396f0,  
> argc=5,
>      argv=0xbfc8874c) at src/_transforms.h:362
> 362       Point* ll_api() {return _ll;}
> Current language:  auto; currently c++
> (gdb) p argv[4]
> $1 = 0x895d0f0 "3085736160"
> (gdb) p bboxo
> $2 = (PyObject *) 0x7fffffff
>
> The cast doesn't seem to work.
>
> Cheers,
> Malte
>
> On 14/05/2008, at 10:47 PM, Michael Droettboom wrote:
>
>> Ouch!  The way that pointer is obtained is really weird (though I
>> believe it is a common idiom in Tcl extensions):
>>
>> PyAggImagePhoto(ClientData clientdata, Tcl_Interp* interp,
>>               int argc, char **argv) {
>>    ...
>>      bboxo = (PyObject*)atol(argv[4]);
>>    if (bboxo != Py_None) {
>>      bbox = (Bbox*)bboxo;
>>
>> That means the pointer comes to us encoded as a string of digits,
>> which gets converted to an integer, cast to a (PyObject*), and then
>> cast to a (Bbox*) (which is a subclass of PyObject, in the C-object-
>> oriented sense).  That's just one of those things you'd rather not
>> be doing ;)
>>
>> Are you running the 64-bit version of OpenSUSE by any chance?  That
>> might explain this if the atol call is overflowing.  That's only
>> theoretical, as I think it *should* work.  atol is supposed to
>> return a "long", which is supposed to be 64-bit on a 64-bit Linux
>> machine.  Could you try replacing "atol" with "atoll", recompile
>> and see what happens?  Do you get any warnings during compilation
>> of _tkagg.cpp?
>>
>> Failing that, it would be useful, I suppose, to print out "argv[4]"
>> from the debugger.
>>
>> Thanks for helping with this.  Hopefully we're honing in on  
>> something.
>>
>> Mike
>>
>> Malte Marquarding wrote:
>>> Hi,
>>>
>>> The segv also occurs in matplotlib-0.90.1. A clean build doesn't
>>> help.
>>>
>>> Here is the gdb output, looks like something is pointing into
>>> nirvana..
>>>
>>> (gdb) p bboxo
>>> $1 = <value optimized out>
>>> (gdb) p bbox
>>> $2 = (Bbox *) 0x7ffffffb
>>> (gdb) p bbox->_ll
>>> Cannot access memory at address 0x7ffffffb
>>>
>>> Cheers,
>>> Malte
>>>
>>> On 13/05/2008, at 10:19 PM, Michael Droettboom wrote:
>>>
>>>> p bboxo
>>>> p bbox
>>>> p bbox->_ll
>>>
>>>
>>>
>>>
>>>
>>
>> -- 
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>
> Malte Marquarding
> Mal...@cs...
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Malte Marquarding
Mal...@cs...

I maybe asking a dumb question, forgive me I'm a novice. I try to add
a ylabel and the left portion of the signal name is cut off when it is
plotted. I can't seem to find the option for displaying the whole
signal. Or do I need to resize the plotting window?

 Jon

Hi,

unfortunately  32-bit ;-) I tried digging around, but I don't know  
much about tcl/tk. Seeing a  char string argv atol'ed into a pointer  
address left me with an uncomfortable feeling...
Anyway her is the argv value

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7c516c0 (LWP 5638)]
0xb6f4500e in PyAggImagePhoto (clientdata=0x0, interp=0x87396f0, argc=5,
     argv=0xbfc8874c) at src/_transforms.h:362
362       Point* ll_api() {return _ll;}
Current language:  auto; currently c++
(gdb) p argv[4]
$1 = 0x895d0f0 "3085736160"
(gdb) p bboxo
$2 = (PyObject *) 0x7fffffff

The cast doesn't seem to work.

Cheers,
Malte

On 14/05/2008, at 10:47 PM, Michael Droettboom wrote:

> Ouch!  The way that pointer is obtained is really weird (though I  
> believe it is a common idiom in Tcl extensions):
>
> PyAggImagePhoto(ClientData clientdata, Tcl_Interp* interp,
>               int argc, char **argv) {
>    ...
>      bboxo = (PyObject*)atol(argv[4]);
>    if (bboxo != Py_None) {
>      bbox = (Bbox*)bboxo;
>
> That means the pointer comes to us encoded as a string of digits,  
> which gets converted to an integer, cast to a (PyObject*), and then  
> cast to a (Bbox*) (which is a subclass of PyObject, in the C-object- 
> oriented sense).  That's just one of those things you'd rather not  
> be doing ;)
>
> Are you running the 64-bit version of OpenSUSE by any chance?  That  
> might explain this if the atol call is overflowing.  That's only  
> theoretical, as I think it *should* work.  atol is supposed to  
> return a "long", which is supposed to be 64-bit on a 64-bit Linux  
> machine.  Could you try replacing "atol" with "atoll", recompile  
> and see what happens?  Do you get any warnings during compilation  
> of _tkagg.cpp?
>
> Failing that, it would be useful, I suppose, to print out "argv[4]"  
> from the debugger.
>
> Thanks for helping with this.  Hopefully we're honing in on something.
>
> Mike
>
> Malte Marquarding wrote:
>> Hi,
>>
>> The segv also occurs in matplotlib-0.90.1. A clean build doesn't  
>> help.
>>
>> Here is the gdb output, looks like something is pointing into  
>> nirvana..
>>
>> (gdb) p bboxo
>> $1 = <value optimized out>
>> (gdb) p bbox
>> $2 = (Bbox *) 0x7ffffffb
>> (gdb) p bbox->_ll
>> Cannot access memory at address 0x7ffffffb
>>
>> Cheers,
>> Malte
>>
>> On 13/05/2008, at 10:19 PM, Michael Droettboom wrote:
>>
>>> p bboxo
>>> p bbox
>>> p bbox->_ll
>>
>>
>>
>>
>>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>

Malte Marquarding
Mal...@cs...

Hi,

I'm trying to insert a slider into my figure like the on in the example
slider_demo.py.

from the slider_demo i have:

axcolor = 'lightgoldenrodyellow'
axfreq = axes([0.25, 0.1, 0.65, 0.03])
sfreq = Slider(axfreq, 'Freq', 0.1, 30.0, valinit = f0)

i have a figure with an axes where i displayed an image using imshow. Like:

a = self.fig.gca()
a.imshow(img)

I've tried different stuff, but i get an assertion error when I try:

self.fig.add_axes(axfreq)

Has anyone here tried doing the slider_demo under wxpython?

Soren

On Wed, May 14, 2008 at 11:41 AM, Michael Droettboom <md...@st...> wrote:

> I haven't done anything with the record array stuff, so I'll leave this
> to another developer to look at.

Fixed in r5139.  This was a consequence of moving the excel and gtk
imports out of mlab to improve load time.  The location is now
mpl_toolkits.exceltools.rec2xls

JDH

Thanks.  These have been applied on the SVN trunk r5138.  The problem 
with legend_scatter.py was a type error created when edgecolors changed 
to a Numpy array (which is optionally zero-length).

Matthias Michler wrote:
> - the function mlab.rec2excel does not exist anymore
> -> in matplotlib/mlab.py:  
>     line 73:  rec2excel(r, 'test.xls', formatd=formatd) 
>     needs to be removed
> -> examples/loadrec.py needs to be changed accordingly (I don't 
> know what is properly in that case )
>   
I haven't done anything with the record array stuff, so I'll leave this 
to another developer to look at.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello list,

It may not be very important, but I collected some small bugs while exploring 
the examples and for some of them I got little patches. 

- for me their occur two "typos" in matplotlib/text.py (see the attached 
text.patch, please)

- some examples don't work for me (see attached some_examples.patch, please)
  e.g. changes in legend_scatter.py due to a DeprecationWarning
  (matplotlib/axes.py:4288) although that doesn't fix the problem of the 
legend_scatter.py (see attached output_of_legend_scatter.out, please)
I recognized, that the 'handle._edgecolors' is an empty list at this point, 
but unfortunately I couldn't figure out why.

- the function mlab.rec2excel does not exist anymore
-> in matplotlib/mlab.py:  
    line 73:  rec2excel(r, 'test.xls', formatd=formatd) 
    needs to be removed
-> examples/loadrec.py needs to be changed accordingly (I don't 
know what is properly in that case )

best regards
Matthias

Ouch!  The way that pointer is obtained is really weird (though I 
believe it is a common idiom in Tcl extensions):

PyAggImagePhoto(ClientData clientdata, Tcl_Interp* interp,
               int argc, char **argv) {
    ...
   
    bboxo = (PyObject*)atol(argv[4]);
    if (bboxo != Py_None) {
      bbox = (Bbox*)bboxo;

That means the pointer comes to us encoded as a string of digits, which 
gets converted to an integer, cast to a (PyObject*), and then cast to a 
(Bbox*) (which is a subclass of PyObject, in the C-object-oriented 
sense).  That's just one of those things you'd rather not be doing ;)

Are you running the 64-bit version of OpenSUSE by any chance?  That 
might explain this if the atol call is overflowing.  That's only 
theoretical, as I think it *should* work.  atol is supposed to return a 
"long", which is supposed to be 64-bit on a 64-bit Linux machine.  Could 
you try replacing "atol" with "atoll", recompile and see what happens?  
Do you get any warnings during compilation of _tkagg.cpp?

Failing that, it would be useful, I suppose, to print out "argv[4]" from 
the debugger.

Thanks for helping with this.  Hopefully we're honing in on something.

Mike

Malte Marquarding wrote:
> Hi,
>
> The segv also occurs in matplotlib-0.90.1. A clean build doesn't help.
>
> Here is the gdb output, looks like something is pointing into nirvana..
>
> (gdb) p bboxo
> $1 = <value optimized out>
> (gdb) p bbox
> $2 = (Bbox *) 0x7ffffffb
> (gdb) p bbox->_ll
> Cannot access memory at address 0x7ffffffb
>
> Cheers,
> Malte
>
> On 13/05/2008, at 10:19 PM, Michael Droettboom wrote:
>
>> p bboxo
>> p bbox
>> p bbox->_ll
>
>
>
>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Sorry -- I don't know where slider_demo.py lives and am not too familiar 
with how the website is updated.  Anyone?

Cheers,
Mike

Matthias Michler wrote:
> Hello list,
>
> On Wednesday 07 May 2008 19:08:23 Michael Droettboom wrote:
>   
>> Matthias Michler wrote:
>>     
>>> The second problem arises only with latest svn.
>>> At the end of the mail there's the Traceback, which arises after clicking
>>> the radiobutton during running examples/widgets/radio_buttons.py.
>>>       
>> This is now fixed in SVN.  It hadn't been updated to use the new
>> transforms framework.
>>     
>
> First of all: Thank you Mike for the fast implementation.
>
> Secondly I ask again for changing the online-version of the nice Slider-demo 
> at http://matplotlib.sourceforge.net/screenshots/slider_demo.py , where the 
> replacement 
> hovercolor=0.975
> to hovercolor="0.975"
> is needed to fulfill standards of mpl colors, please.
> We refered our students to the nice collection of screenshots on mpl-homepage 
> and therefore it would be great, if someone could change that, so that we 
> don't run into much bug reports on our side.
>
> Thanks in advance. 
> Matthias
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello list,

On Wednesday 07 May 2008 19:08:23 Michael Droettboom wrote:
> Matthias Michler wrote:
> > The second problem arises only with latest svn.
> > At the end of the mail there's the Traceback, which arises after clicking
> > the radiobutton during running examples/widgets/radio_buttons.py.
>
> This is now fixed in SVN.  It hadn't been updated to use the new
> transforms framework.

First of all: Thank you Mike for the fast implementation.

Secondly I ask again for changing the online-version of the nice Slider-demo 
at http://matplotlib.sourceforge.net/screenshots/slider_demo.py , where the 
replacement 
hovercolor=0.975
to hovercolor="0.975"
is needed to fulfill standards of mpl colors, please.
We refered our students to the nice collection of screenshots on mpl-homepage 
and therefore it would be great, if someone could change that, so that we 
don't run into much bug reports on our side.

Thanks in advance. 
Matthias

Hello Markus,

On Saturday 10 May 2008 22:01:22 Markus Kuhn wrote:
> How can I extract from a figure or axes the data that it currently
> displays?
>
> I had hoped that something like
>
> from pylab import *
> plot([1,3,2])
> data = getp(gca(), 'data')
> xdata = getp(gca(), 'xdata')
> ydata = getp(gca(), 'ydata')

An axes instance does not provide data-properties. They belong to the lines, 
that were already plotted in that axes. But the axes instance provides a list 
of all plotted lines (gca().lines).

xdata = getp(gca().lines[0], 'xdata')
# or the OOP-way
# last line instance of the list of lines: 
line = gca().lines[-1]                                   
ydata = line.get_ydata()

regards Matthias

> P.S.: It seems that the link
>
>   http://matplotlib.sourceforge.net/matplotlib.pyplot.html#-getp
>
> on
>
>   http://matplotlib.sourceforge.net/
>
> is broken.

(+1)

Hi,

The segv also occurs in matplotlib-0.90.1. A clean build doesn't help.

Here is the gdb output, looks like something is pointing into nirvana..

(gdb) p bboxo
$1 = <value optimized out>
(gdb) p bbox
$2 = (Bbox *) 0x7ffffffb
(gdb) p bbox->_ll
Cannot access memory at address 0x7ffffffb

Cheers,
Malte

On 13/05/2008, at 10:19 PM, Michael Droettboom wrote:

> p bboxo
> p bbox
> p bbox->_ll

Hi,

I want to be able to disable the zoom tool (when it has been selected) when
I press another button on the toolbar, and disable the same button when I
click the zoom tool... anyone know how to do this??

Thanks,
Soren

Hi,
thanks for the input.

In fact this happens on a dual core machine. As for the Ipython version etc it
is written at the end of my original email.

I'll try to see with the Ipython forum maybe. Not sure where it comes from,
which is the difficult part (mpl, ipython, or...?)

I'll also try to isolate some simple functions which does this... But this may
be hard to do.

thanks

Eric

It would also be useful to know what matplotlib version and backend you are 
using, and what version of ipython. For what its worth, I use ipython -pylab 
with svn/bzr ipython and the qt4agg backend on a multicore machine without 
any problems. If you can, I suggest trying the development branch of ipython 
(not ipython1), there was some improvement to the threading code recently, 
although I don't know if it would relate to the problem you reported.

Darren

On Tuesday 13 May 2008 8:09:38 am Michael Droettboom wrote:
> That's a good one ;)  There are some pretty clever things done with
> threading when you do "ipython -pylab" to make the GUI and the shell
> responsive at the same time.  I wonder if you've entered a race
> condition/deadlock or something.  A useful piece of information is
> whether you are running on a multi-core machine.  Have you ever seen it
> lock up if you don't use "-pylab"?  (In that case it would be normal for
> the shell to stop responding, but the GUI should still repaint and
> resize etc.)
>
> There may be others on this list who are of more help than me, but you
> may also want to ask your question on the ipython mailing list if we
> can't solve it here.  I suspect this is related to the interaction of
> the two projects.
>
> Cheers,
> Mike
>
> Eric Emsellem wrote:
> > Hi,
> >
> > I am having a recurrent (and very annoying) problem with plotting.
> >
> > Basically: I enter my Ipython session (with -pylab), execute a few
> > commands from locally developed modules, and then try to make one plot.
> > The plot does not appear (I don't get back the command line), and my
> > session is then completely stuck, and I have no other way out (as far as
> > I could find) than to just do a shell "kill" of my Ipython session.
> > I then RE-enter the Ipython session, relaunch the exact SAME commands,
> > including the plotting one, and there it works.
> >
> > This happens very frequently (first trial = I get stuck with the first
> > plotting, then after killing the session and redoing the same thing, it
> > works).
> >
> > This is VERY annoying specially as some of the calculations I commonly
> > use are quite long (which makes it very difficult for me to provide more
> > info here, sorry...). I guess this may be a memory problem of some sort?
> > Any clue of either how to solve this or at least how to find out what is
> > exactly the problem?
> >
> > thanks for your help
> >
> > Eric
> > ========
> > CONFIG =
> > ========
> > Under OpenSuse 10.3 (x86_64)
> >
> > matplotlib version 0.90.1
> > verbose.level helpful
> > interactive is False
> > units is False
> > platform is linux2
> > numerix numpy 1.0.3.1
> > font search path
> > ['/usr/lib64/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf',
> > '/usr/lib64/python2.5/site-packages/matplotlib/mpl-data/fonts/afm']
> > matplotlib data path
> > /usr/lib64/python2.5/site-packages/matplotlib/mpl-data backend WXAgg
> > version 2.8.4.0
> > Python 2.5.1 (r251:54863, Jan 10 2008, 18:00:49)
> > IPython 0.8.1 -- An enhanced Interactive Python.
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users



-- 
Darren S. Dale, Ph.D.
dd...@co...

This looks like the same symptoms as this (unresolved) bug here:

http://sourceforge.net/tracker/index.php?func=detail&aid=1949982&group_id=80706&atid=560720

Your gdb backtrace reveals that you have debugging symbols in 
matplotlib, so we've got a little more information now.  Thanks.

Since this crash is in an inlined C++ method, I would try forcing a 
clean rebuild of matplotlib (by deleting the build directory under the 
source tree) and rebuilding/reinstalling.  Beyond that, I'm a little 
stumped.  Could you run the following in gdb when the crash happens?

p bboxo
p bbox
p bbox->_ll

Cheers,
Mike

Malte Marquarding wrote:
> Hi,
>
> I had a look through the archives but couldn't find an answer to this.
> Using the tkagg backend (agg is fine) I get a segmentation fault  
> doing a simple plot.
> gdb returns the following:
>
> 362       Point* ll_api() {return _ll;}
> Current language:  auto; currently c++
> (gdb) bt
> #0  0xb6fc1bac in PyAggImagePhoto (clientdata=0x0, interp=0x87a9430,  
> argc=5,
>      argv=0xbf97fc9c) at src/_transforms.h:362
> #1  0xb712ea5c in TclInvokeStringCommand () from /usr/lib/libtcl8.4.so
> #2  0xb712ff05 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
> #3  0xb7131015 in Tcl_EvalObjv () from /usr/lib/libtcl8.4.so
> #4  0xb73d34a6 in ?? () from /usr/lib/python2.5/lib-dynload/_tkinter.so
> snip
>
> This is matplotlib-0.91.2, python 2.5 on linux (opensuse 10.3)
>
>
> Cheers,
> Malte.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

That's a good one ;)  There are some pretty clever things done with 
threading when you do "ipython -pylab" to make the GUI and the shell 
responsive at the same time.  I wonder if you've entered a race 
condition/deadlock or something.  A useful piece of information is 
whether you are running on a multi-core machine.  Have you ever seen it 
lock up if you don't use "-pylab"?  (In that case it would be normal for 
the shell to stop responding, but the GUI should still repaint and 
resize etc.)

There may be others on this list who are of more help than me, but you 
may also want to ask your question on the ipython mailing list if we 
can't solve it here.  I suspect this is related to the interaction of 
the two projects.

Cheers,
Mike

Eric Emsellem wrote:
> Hi,
>
> I am having a recurrent (and very annoying) problem with plotting.
>
> Basically: I enter my Ipython session (with -pylab), execute a few commands from
>  locally developed modules, and then try to make one plot. The plot does not
> appear (I don't get back the command line), and my session is then completely
> stuck, and I have no other way out (as far as I could find) than to just do a
> shell "kill" of my Ipython session.
> I then RE-enter the Ipython session, relaunch the exact SAME commands, including
> the plotting one, and there it works.
>
> This happens very frequently (first trial = I get stuck with the first plotting,
> then after killing the session and redoing the same thing, it works).
>
> This is VERY annoying specially as some of the calculations I commonly use are
> quite long (which makes it very difficult for me to provide more info here,
> sorry...). I guess this may be a memory problem of some sort? Any clue of either
> how to solve this or at least how to find out what is exactly the problem?
>
> thanks for your help
>
> Eric
> ========
> CONFIG =
> ========
> Under OpenSuse 10.3 (x86_64)
>
> matplotlib version 0.90.1
> verbose.level helpful
> interactive is False
> units is False
> platform is linux2
> numerix numpy 1.0.3.1
> font search path
> ['/usr/lib64/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf',
> '/usr/lib64/python2.5/site-packages/matplotlib/mpl-data/fonts/afm']
> matplotlib data path /usr/lib64/python2.5/site-packages/matplotlib/mpl-data
> backend WXAgg version 2.8.4.0
> Python 2.5.1 (r251:54863, Jan 10 2008, 18:00:49)
> IPython 0.8.1 -- An enhanced Interactive Python.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Presently, there's no direct way to do this.  matplotlib uses the 
standard Python (derived from C) number formatting which uses a hyphen.  
There are a couple of workarounds, however.

You can set a custom tick formatter by providing a function and wrapping 
it in a FuncFormatter object.  (See attached).  You can have your 
function replace all of the hyphens with minus signs, or force it to use 
the mathtext formatting (which uses minus signs by default) by wrapping 
the text in '$'.  Alternatively, if your plot is designed for inclusion 
in t a (La)TeX document, you can turn usetex on in your matplotlibrc.

All that said, it might be nice to make this the default behavior in 
future versions of matplotlib.  We're about to make a release, so I 
don't want to put this in right now.  Could you possibly file a "Feature 
Request" in the tracker so we don't lose track of this?

Cheers,
Mike

Markus Kuhn wrote:
> Matplotlib currently uses the "hyphen" character instead of a "minus
> sign" when printing negative numbers in plots.
>
> While these two characters are traditionally not distinguished in
> monospaced fonts, there is a big difference in proportional fonts. A
> hyphen (Unicode character 0x002d) is very short and used between words,
> whereas a minus sign (Unicode: 0x2212) is much longer and looks exactly
> like the horizontal part of a plus sign.
>
> Practically all modern fonts do contain a minus sign. In those fonts
> that still lack a minus sign, the (often slightly lower/thinner/longer)
> "en dash" is usually a much less painful substitute than the hyphen.
> [The PostScript standard encoding lacks a minus sign, but the PostScript
> symbol font has one at 0x2d, as documented in
> http://www.unicode.org/Public/MAPPINGS/VENDORS/ADOBE/symbol.txt ]
>
> Example:
>
> from pylab import *
> plot([-3, -2, -1], [1,-3,-2])
> title(u"wrong: -2..+2   correct: \u22122..+2")
> show()
>
> Is there a way to cause matplotlib to use the correct minus-sign glyph?
> That would help to keep typographically very picky editors of scientific
> journals happy ...
>
> Markus
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Your matplotlib is probably configured to use a GUI backend.  Set the 
backend to "pdf" in either your matplotlibrc file or with

import matplotlib
matplotlib.use("pdf")

at the top of your script.

If you still see flashing windows, that's a bug, and let us know so we 
can fix it.

Cheers,
Mike

Neal Becker wrote:
> To produce a batch of pdfs, I'm using:
>
> close ()
> figure (1, figsize=(11,8))
> ...
> savefig (open (whatever, 'w'))
>
> Works, but causes my display to flash, I think each time either close() or
> figure() is called (not sure which).  Any better way?
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Forgot to attach example.  Sorry.

Michael Droettboom wrote:
> Presently, there's no direct way to do this.  matplotlib uses the 
> standard Python (derived from C) number formatting which uses a 
> hyphen.  There are a couple of workarounds, however.
>
> You can set a custom tick formatter by providing a function and 
> wrapping it in a FuncFormatter object.  (See attached).  You can have 
> your function replace all of the hyphens with minus signs, or force it 
> to use the mathtext formatting (which uses minus signs by default) by 
> wrapping the text in '$'.  Alternatively, if your plot is designed for 
> inclusion in t a (La)TeX document, you can turn usetex on in your 
> matplotlibrc.
>
> All that said, it might be nice to make this the default behavior in 
> future versions of matplotlib.  We're about to make a release, so I 
> don't want to put this in right now.  Could you possibly file a 
> "Feature Request" in the tracker so we don't lose track of this?
>
> Cheers,
> Mike
>
> Markus Kuhn wrote:
>> Matplotlib currently uses the "hyphen" character instead of a "minus
>> sign" when printing negative numbers in plots.
>>
>> While these two characters are traditionally not distinguished in
>> monospaced fonts, there is a big difference in proportional fonts. A
>> hyphen (Unicode character 0x002d) is very short and used between words,
>> whereas a minus sign (Unicode: 0x2212) is much longer and looks exactly
>> like the horizontal part of a plus sign.
>>
>> Practically all modern fonts do contain a minus sign. In those fonts
>> that still lack a minus sign, the (often slightly lower/thinner/longer)
>> "en dash" is usually a much less painful substitute than the hyphen.
>> [The PostScript standard encoding lacks a minus sign, but the PostScript
>> symbol font has one at 0x2d, as documented in
>> http://www.unicode.org/Public/MAPPINGS/VENDORS/ADOBE/symbol.txt ]
>>
>> Example:
>>
>> from pylab import *
>> plot([-3, -2, -1], [1,-3,-2])
>> title(u"wrong: -2..+2   correct: \u22122..+2")
>> show()
>>
>> Is there a way to cause matplotlib to use the correct minus-sign glyph?
>> That would help to keep typographically very picky editors of scientific
>> journals happy ...
>>
>> Markus
>>
>>   
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA