matplotlib-users Mailing List for matplotlib

Hi guys,
 I can't figure this one out. Look at the example 
http://matplotlib.sourceforge.net/screenshots/finance_work2.py
 
When I am moving my mouse over the middle subplot which has two Y axes,
the data coordinates are for the volume axis, not the candlestick axis.
(Presumably because the volume axis was added later...) How do I change
which coordinates are shown at the bottom of the interactive window so
that it will show me the datapoints from the candlestick axis?
 
Thanks in advance,
-Ryan
Ryan Wagner 
rw...@vn...
 

Hi Everyone,
I have a peculiar problem, and I wonder if anyone can assist me.
I have two figures generated from matplotlib and saved as svgs. They 
both print fine, and they load in Inkscape just fine.
However, when I copy one figure and paste it into the other, the pasted 
figure's labels and text become garbled.
Screenshots on this page
http://assorted-experience.blogspot.com/2008/03/inkscape-matplotlibs-svg-one-strange.html
Any suggestions would be most welcome
Thanks
-Kaushik

John -
What you are saying makes sense, because whatever option I give, I always
get Vera included in my eps file but nothing else.
Thanks for looking into this,
Mark
On Tue, Mar 25, 2008 at 6:50 PM, John Hunter <jd...@gm...> wrote:
> On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom <md...@st...>
> wrote:
>
> > The *intention* is that the fonts *should* be included (with the
> > exception of ps.useafm == True). That was definitely not a deliberate
> > change.
> >
> > However, as one of the ones who hasn't been able to reproduce this
> > problem, I'm afraid I'm not of much help. From reading the code, I'm
> > still completely stumped as to why the font is not embedded. Someone
> > will have to step through with a debugger on one of the broken systems
> > to figure this out, I'm afraid.
>
> I was able to replicate the bug and find the source of the problem. I
> am not 100% sure how to fix it, but someone who knows os.stat better
> might. The problem is that matplotlib.cbook.get_realpath_and_stat
>
> class GetRealpathAndStat:
> def __init__(self):
> self._cache = {}
>
> def __call__(self, path):
> result = self._cache.get(path)
> if result is None:
> realpath = os.path.realpath(path)
> stat = os.stat(realpath)
> stat_key = (stat.st_ino, stat.st_dev)
> result = realpath, stat_key
> self._cache[path] = result
> return result
> get_realpath_and_stat = GetRealpathAndStat()
>
>
> is returning the same stat ino and dev for all the font files, and
> thus the renderer.used_characters dictionary is getting improper keys
> -- always (0,0). So the first font in the gate, in this case Vera, is
> getting a place in the dict and subsequent fonts (the cm* ones) are
> not. The basic problem is that the inode and dev appear to be unix
> only.
>
> Michael: if you let me know better what this key is supposed to be
> doing (can we not simply use the filename for windows?) then I can
> attempt or test some fixes.
>
> JDH
>

Jpeg.
On Mar 25, 2008, at 8:12 AM, Einar M. Einarsson wrote:
>
> Hi all,
>
> I'm trying to find ways to make the file-size of my PNG images 
> smaller.
>
> When I generate my 660*440px image I get a big 168kb file.
> (8bit RGB color model, has an alpha channel (need that) but no
> interlacing scheme)
>
> Here it is:
> http://metphys.org/eme/T05.png
>
> I'm using the savefig method of-course.
>
>
> To see how much I could compress it I used pngcrush (the best tool
> according to the interwebs) and got it down to 128kb.
>
> But thats still way to large for my intended use. (plotting results
> from an operational weather model, see. www.belgingur.is
> We are currently using IDL.)
>
> From what I've read about PNG files, which is supposed to be rather
> compact image format, it seems to me that the most effective way is
> to have an indexed color table.
>
> So to cut it short:
>
> Is there any way to save a PNG file with an indexed color table?
>
> Or do you see any other way to shrink the files?
>
>
> Best regards.
> Einar M. Einarsson
> www.belgingur.is
>
>
> -------------------------------------------------------------------------
> 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 <md...@st...> writes:
> One possible solution is to calculate a hash of the file and key off
> of that (with an I/O penalty, of course). I vaguely recall that keying
> off of the Postscript name embedded in the file wasn't good enough.
How about checking first the size of the file, assuming that
os.stat('filename').st_size is sensible on Windows? If the size matches
an existing file, compute a hash of the contents of both to see if they
are the same, and in any case, memoize the results so that future checks
of the exact same filename are fast. That way you only incur the cost of
the hash if the same file is included with multiple names, or in the
rare case that two different files have the same size.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hmm... That fix was in there in the first place to work around another Windows (well, case-insensitive filesystem) -related bug, in that occasionally the same font would get included with different "paths", and therefore get included twice leading to other Postscript problems.
One possible solution is to calculate a hash of the file and key off of that (with an I/O penalty, of course). I vaguely recall that keying off of the Postscript name embedded in the file wasn't good enough.
I don't have time to look at this today, but maybe others have some better suggestions anyway.
Cheers,
Mike

"John Hunter" <jd...@gm...> writes:
> Michael: if you let me know better what this key is supposed to be
> doing (can we not simply use the filename for windows?) then I can
> attempt or test some fixes.
I seem to recall that there was some problem with case-insensitive file
systems. On OS X os.path.realpath doesn't normalize case (some OS X file
systems are case sensitive but the usual one is not):
>>> os.path.realpath
<function realpath at 0x474b0>
>>> r=_
>>> r('/system/library/fonts/LucidaGrande.dfont')
'/system/library/fonts/LucidaGrande.dfont'
>>> r('/System/Library/Fonts/LucidaGrande.dfont')
'/System/Library/Fonts/LucidaGrande.dfont'
>>> s=os.stat
>>> s('/system/library/fonts/LucidaGrande.dfont')
(33188, 10369L, 234881026L, 1, 0, 0, 2295501L, 1206468480, 1191377895, 1194639447)
>>> s('/System/Library/Fonts/LucidaGrande.dfont')
(33188, 10369L, 234881026L, 1, 0, 0, 2295501L, 1206468480, 1191377895, 1194639447)
Stat is a clever way of finding the "real identity" of the file on
Unix-like systems. On Windows we clearly need something else...
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Jou...@xt... writes:
> Michael Droettboom <md...@st...> writes:
>> All the magic happens in "convert_ttf_to_ps", which is C code, called 
>> from backend_ps.py. I'd start by seeing if that function is even 
>> called, and if not, why...
>
> One possible source of platform-specific issues is
> cbook.get_realpath_and_stat, which is used on the font files to obtain
> hash keys. Does stat do anything sensible on Windows?
Oh, never mind, John seems to have found the bug in a message that
didn't quite make it to my newsreader before I posted. Apparently stat
does not do on Windows what this code is expecting it to do.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Michael Droettboom <md...@st...> writes:
> All the magic happens in "convert_ttf_to_ps", which is C code, called 
> from backend_ps.py. I'd start by seeing if that function is even 
> called, and if not, why...
One possible source of platform-specific issues is
cbook.get_realpath_and_stat, which is used on the font files to obtain
hash keys. Does stat do anything sensible on Windows?
Mark: Could you try applying the following patch to your installed
version of lib/matplotlib/backends/backend_ps.py? There should be no
need to recompile anything. If you don't have a patch utility, just make
a backup of the file, open it in a text editor, find the relevant parts,
and add each line prefixed with + below (omitting the + signs,
naturally). Then run your script and post the output. That should tell
us if the chi character is not even registered as used, or if the bug is
in the embedding code.

On Tue, Mar 25, 2008 at 12:50 PM, John Hunter <jd...@gm...> wrote:
> result = self._cache.get(path)
> if result is None:
> realpath = os.path.realpath(path)
> stat = os.stat(realpath)
> stat_key = (stat.st_ino, stat.st_dev)
The hackish:
 if stat_key==(0,0):
 stat_key = (path, path)
does produce a working chi enabled EPS file, FYI
JDH

On Tue, Mar 25, 2008 at 12:02 PM, Michael Droettboom <md...@st...> wrote:
> The *intention* is that the fonts *should* be included (with the
> exception of ps.useafm == True). That was definitely not a deliberate
> change.
>
> However, as one of the ones who hasn't been able to reproduce this
> problem, I'm afraid I'm not of much help. From reading the code, I'm
> still completely stumped as to why the font is not embedded. Someone
> will have to step through with a debugger on one of the broken systems
> to figure this out, I'm afraid.
I was able to replicate the bug and find the source of the problem. I
am not 100% sure how to fix it, but someone who knows os.stat better
might. The problem is that matplotlib.cbook.get_realpath_and_stat
class GetRealpathAndStat:
 def __init__(self):
 self._cache = {}
 def __call__(self, path):
 result = self._cache.get(path)
 if result is None:
 realpath = os.path.realpath(path)
 stat = os.stat(realpath)
 stat_key = (stat.st_ino, stat.st_dev)
 result = realpath, stat_key
 self._cache[path] = result
 return result
get_realpath_and_stat = GetRealpathAndStat()
is returning the same stat ino and dev for all the font files, and
thus the renderer.used_characters dictionary is getting improper keys
-- always (0,0). So the first font in the gate, in this case Vera, is
getting a place in the dict and subsequent fonts (the cm* ones) are
not. The basic problem is that the inode and dev appear to be unix
only.
Michael: if you let me know better what this key is supposed to be
doing (can we not simply use the filename for windows?) then I can
attempt or test some fixes.
JDH

The *intention* is that the fonts *should* be included (with the 
exception of ps.useafm == True). That was definitely not a deliberate 
change.
However, as one of the ones who hasn't been able to reproduce this 
problem, I'm afraid I'm not of much help. From reading the code, I'm 
still completely stumped as to why the font is not embedded. Someone 
will have to step through with a debugger on one of the broken systems 
to figure this out, I'm afraid.
All the magic happens in "convert_ttf_to_ps", which is C code, called 
from backend_ps.py. I'd start by seeing if that function is even 
called, and if not, why...
Cheers,
Mike
Mark Bakker wrote:
> I know. In version 0.90.1 (and earlier) all greek symbols were 
> included in the EPS.
> Now they are not anymore, and I cannot get any of the options to 
> include them.
> Does anybody know how to fix this?
> Mark
> 
>
>
> Date: 2008年3月25日 10:43:43 -0400
> From: Alan G Isaac <ai...@am... <mailto:ai...@am...>>
> Subject: Re: [Matplotlib-users] can any windows 0.91.2 user reproduce
> this bug?
> To: mat...@li...
> <mailto:mat...@li...>
> Message-ID: <Mah...@am...
> <mailto:Mah...@am...>>
> Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
>
> On 2008年3月25日, Jim Vickroy apparently wrote:
> > I loaded the eps file in Adobe Photoshop and the chi
> > letter **was** displayed along the x-axis. -- jv
>
> Sounds like perhaps the symbol is not embedded in the EPS file.
>
> Cheers,
> Alan Isaac
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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

I know. In version 0.90.1 (and earlier) all greek symbols were included in
the EPS.
Now they are not anymore, and I cannot get any of the options to include
them.
Does anybody know how to fix this?
Mark
>
> Date: 2008年3月25日 10:43:43 -0400
> From: Alan G Isaac <ai...@am...>
> Subject: Re: [Matplotlib-users] can any windows 0.91.2 user reproduce
> this bug?
> To: mat...@li...
> Message-ID: <Mah...@am...>
> Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
>
> On 2008年3月25日, Jim Vickroy apparently wrote:
> > I loaded the eps file in Adobe Photoshop and the chi
> > letter **was** displayed along the x-axis. -- jv
>
> Sounds like perhaps the symbol is not embedded in the EPS file.
>
> Cheers,
> Alan Isaac
>

On Tue, Mar 25, 2008 at 11:39 AM, Amit Finkler <ami...@gm...> wrote:
> I am using matplotlib to dynamically plot a graph with both my x and y
> points taken from a measurement device. That is to say, in each iteration of
> my while loop I'm reading two variables which I then want to plot with
> matplotlib.
Odd, are you using an older version of matplotlib (it works for me).
Try seeding your data with an initial point
xdata = [x]
ydata = [y]
or setting the axis limits before plotting
ax.set_xlim(0,1)
ax.set_ylim(0,1)
Not sure why you are having problems....
JDH

Hi,
On Mar 25, 2008, at 12:23 PM, Christopher Barker wrote:
>
> To summarize where we are at with OS-X installer:
>
> The binary egg that Charlie built is supposed to work with Python 2.5,
> either Apple or python.org version on OS-X 10.5, and pythonorg version
> on OS-X 10.3.9 and 10.4.*
>
> However, for some odd reason none of us understand, under some
> circumstances, easy-install tries to build from source anyway.
[snip]
I haven't really been following this thread too closely, but I read 
through it and saw that no body made mention of the "superpack"?
http://trichech.us/?p=5
For a long while now, I've been using python2.4 through macports and 
installing ipython/numpy/scipy/matplotlib from SVN, but I wanted to 
just try to use Leopard's Python (quickly ;-).
Instead of installing everything from source, I took a stab at d/ling 
the superpack and it all worked out pretty well for me. The only thing 
I had to do was to install freetype2 from source (simple ./configure, 
make, sudo make install) and everything seems to be working. Once I 
had that in there, I could use matplotlib with the WXAgg backend and 
it required no additional tweaking.
You can give that a go and see if it works.
If the numpy/scipy versions fall sufficiently out of data w/o a re- 
release of the superpack, I reckon you can install those from SVN (and 
remove the installed eggs) and things should work out fine.
-steve

John Hunter wrote:
> On Sun, Mar 23, 2008 at 3:54 AM, Amit Finkler <ami...@gm...> wrote:
>
> 
>> I am using matplotlib to dynamically plot a graph with both my x and y
>> points taken from a measurement device. That is to say, in each iteration of
>> my while loop I'm reading two variables which I then want to plot with
>> matplotlib.
>> 
>
> You will want to do something like (this is just a sketch)
>
> xdata = []
> ydata = []
>
> fig = figure()
> ax = fig.add_subplot(111)
> ax.set_xlabel('my xlabel')
> ax.set_ylabel('my ylabel')
> line, = ax.plot(xdata, ydata)
>
> def add_point(x, y):
> xdata.append(x)
> ydata.append(y)
> if len(xdata)>30: # optional, prune the early points
> del xdata[0]
> del ydata[0]
> xmin = xdata[0]
> xmax = xdata[-1]
> line.set_data(xdata, ydata)
> ax.set_xlim(xmin, xmax)
> fig.canvas.draw()
>
> while 1:
> x,y = get_data_point()
> add_point(x, y)
>
> JDH
> 
John,
Thanks for getting back to me. Indeed this works, at least when I try it
line by line. When I inserted it into my module, it shot back some error
message which goes like this:
 File
 "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py",
 line 154, in draw
 FigureCanvasAgg.draw(self)
 File
 "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py",
 line 392, in draw
 self.figure.draw(renderer)
 File "/usr/lib/python2.4/site-packages/matplotlib/figure.py", line
 544, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line
 1004, in draw
 try: self.transData.freeze() # eval the lazy objects
 ValueError: Domain error on eval_scalars in Transformation::freeze
Since it did work on the console, i.e., line by line, I think it's only
a matter of resolving my own source code, unless of course you think
otherwise. By the way, isn't there a way to do the set_xlim/ylim
automatically? When I use only figure(), hold(False) and plot(X, Y), it
updates it automatically, so why doesn't it do it with the subplot?
Thanks for your help.
Amit.

Sorry, this really is OT, but I've been doing some research on this 
issue, so I thought I see what folks here think:
Francesco Biscani wrote:
> However the C++ programming style which is 
> sometimes referred to as "modern" C++ 
OK, so I'll take it as a given for the moment that Modern C++ is 
typesafe, and, of course JAVA is. Those are the two primary languages 
that people seem to want to use rather than Python.
I recently had a Java vs. Python discussion at work, so I dug into it on 
the net once again -- My thesis is that aside from syntax, library 
support etc, etc, the difference is static vs. dynamic typing. Here's my 
quickie synopsis:
* Dynamic typing allows more flexibility and therefor greater productivity.
* Static typing provides more safety, and the ability to optimize 
compiled code.
Ignoring performance issues, that leaves: Productivity vs. type safety.
What I've found is that folks that are fans of statically typed 
languages really don't get how much productivity can increase. If you 
haven't really written code in a dynamic language (and I mean "really", 
if you write Fortran with Python syntax, that doesn't count), you tend 
to think that all you're saving is the typing involved in declaring 
types and interfaces, etc. That's simply not the case -- dynamically 
typed languages let you build far more flexible systems with far less 
code. This has been well documented, at least anecdotally.
So the question is: does the type safety you get out weigh the 
productivity gains? Some say not for quickie scripts, but yes to big 
systems, or particularly for "if it fails, someone can die" systems. I'm 
not so sure.
We all make type errors when writing code (forget to turn that string 
into a number before passing it off to the calculation code, or 
whatever), the fact that a static language's compiler catches a lot of 
errors like that doesn't mean at all that they wouldn't get caught 
quickly with a dynamic language. In fact, my personal experience is that 
those kind of errors get caught very quickly, usually the first test of 
the code in question. The point is that while the compiler can catch 
those bugs for you, those aren't the bugs I care about. In fact, in my 
reading, I haven't found a SINGLE anecdote by anyone about a deep, hard 
to find bug caused by a type error in a dynamic language, Not one.
Has anyone seen such an anecdote? Or better yet, a real study?
So why are people so concerned, and letting these issues drive their 
decisions? A couple reasons:
1) All they know is that their compiler is catching a lot of errors, so 
they can imagine that some of those errors would never be found if the 
compiler wasn't finding them -- you know that sense of relief when you 
finally get a bunch of code to compile! Even though it may not work 
right at all, there's still a sense of accomplishment.
2) When you've primarily worked with static languages, you really don't 
get how much less code you can write with a dynamically typed language 
-- you're so used to thinking that a given method is designed to work 
with a couple specific types and classes -- what's so hard about 
declaring them? I think folks see the gains from type checking, and 
really have no idea that there are significant costs. Here's a good 
essay about that:
http://www.artima.com/weblogs/viewpost.jsp?thread=4639
A quote from that: "So I tried writing some applications in Python, and 
then Ruby (well known dynamically typed languages). I was not entirely 
surprised when I found that type issues simply never arose."
3) A point made in that article: some folks have bad memories from C (or 
Fortran), with type issues. The problem is that they are mistaking weak 
typing (or no typing!), like you get when you cast a pointer to a new 
type, with dynamic typing, where the type is checked, just not 'till run 
time. I used to write Fortran code where you'd pass in references to a 
procedure that expected certain types, and the compiler wouldn't check 
anything, it would just merrily go along and use that memory address, 
which could be total garbage -- that did suck!
This is also a good article about the issue (from the Author of 
"Thinking in Java", no less):
http://mindview.net/WebLog/log-0066
Here's a choice quote from that one:
"""
you bring up an interesting question in suggesting that a 
dynamically-typed language may require more unit testing than a 
statically typed language. Of this I am not convinced; I suspect the 
amount may be roughly the same and if I am correct it implies that the 
extra effort required to jump through the static type-checking hoops may 
be less fruitful than we might believe.
"""
My way of phrasing that -- you're either testing a given code path or 
you're not -- if you are not, then you don't know if the code works. If 
you are, then you're testing the types and the results at the same time 
-- there's no extra testing required to test the typing.
Well, enough written about that! Sorry for the OT post.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

To summarize where we are at with OS-X installer:
The binary egg that Charlie built is supposed to work with Python 2.5, 
either Apple or python.org version on OS-X 10.5, and pythonorg version 
on OS-X 10.3.9 and 10.4.*
However, for some odd reason none of us understand, under some 
circumstances, easy-install tries to build from source anyway.
We're not distributing it as a *.mpgk, 'cause bdist_mpgk doesn't work 
right the last time it was tried.
It would be great if someone could work out one or both of these issues, 
but it looks like none of us has the energy and/or time at the moment.
On the bright side, it looks like building from source is getting 
easier, with only libpng being a dependency not supplied by Apple (at 
least on 10.5). Which is odd -- libpng is really common!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi all,
I'm trying to find ways to make the file-size of my PNG images smaller.
When I generate my 660*440px image I get a big 168kb file.
(8bit RGB color model, has an alpha channel (need that) but no
interlacing scheme)
Here it is:
http://metphys.org/eme/T05.png
I'm using the savefig method of-course.
To see how much I could compress it I used pngcrush (the best tool
according to the interwebs) and got it down to 128kb.
But thats still way to large for my intended use. (plotting results
from an operational weather model, see. www.belgingur.is
We are currently using IDL.)
 From what I've read about PNG files, which is supposed to be rather
compact image format, it seems to me that the most effective way is
to have an indexed color table.
So to cut it short:
Is there any way to save a PNG file with an indexed color table?
Or do you see any other way to shrink the files?
Best regards.
Einar M. Einarsson
www.belgingur.is

Well, that is odd.
The *chi* letter doesn't show up with GSView, or Preview on the Mac.
What's going on?
Mark
On Tue, Mar 25, 2008 at 3:19 PM, Jim Vickroy <Jim...@no...> wrote:
> Mark Bakker wrote:
>
> Thanks to Fred, Chris, and JV for reproducing this bug.
> We all get the same eps file, that doesn't show the greek symbols produced
> with mathtext.
> And we all do get correct results on the screen (using Tk) and in pdf and
> png files.
>
> I loaded the *eps* file in Adobe Photoshop and the *chi* letter **was**
> displayed along the x-axis. -- jv
>
> It seems not to work on windows, while it used to work on versions 0.90.1and earlier.
> Sorry for the bad news.
> Anybody know how to fix this?
>
> Thanks, Mark
>
> On Sun, Mar 23, 2008 at 5:02 PM, Mark Bakker <ma...@gm...> wrote:
>
> > Hello windows users -
> >
> > Can anybody using mpl 0.91.2 on windows reproduce this bug:
> >
> > from pylab import *
> > plot([1,2,3])
> > xlabel(r'$\chi$')
> > savefig('c:/temp/test.eps')
> >
> > This should give an eps file that when viewed does not show the letter
> > chi along the x-axis (that's the bug).
> >
> > We have been discussing this problem, and I think it is a bug in the
> > windows distribution.
> > (It worked on all the previous mpl versions fine, just when upgrading
> > from 0.90.1 the problem arose).
> >
> > If you can, please email me your eps file: ma...@gm...
> >
> > Thanks for your help, Mark
> >
>
> ------------------------------
>
> -------------------------------------------------------------------------
> 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 lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>

On Sun, Mar 23, 2008 at 3:54 AM, Amit Finkler <ami...@gm...> wrote:
> I am using matplotlib to dynamically plot a graph with both my x and y
> points taken from a measurement device. That is to say, in each iteration of
> my while loop I'm reading two variables which I then want to plot with
> matplotlib.
You will want to do something like (this is just a sketch)
xdata = []
ydata = []
fig = figure()
ax = fig.add_subplot(111)
ax.set_xlabel('my xlabel')
ax.set_ylabel('my ylabel')
line, = ax.plot(xdata, ydata)
def add_point(x, y):
 xdata.append(x)
 ydata.append(y)
 if len(xdata)>30: # optional, prune the early points
 del xdata[0]
 del ydata[0]
 xmin = xdata[0]
 xmax = xdata[-1]
 line.set_data(xdata, ydata)
 ax.set_xlim(xmin, xmax)
 fig.canvas.draw()
while 1:
 x,y = get_data_point()
 add_point(x, y)
JDH

On 2008年3月25日, Jim Vickroy apparently wrote:
> I loaded the eps file in Adobe Photoshop and the chi 
> letter **was** displayed along the x-axis. -- jv 
Sounds like perhaps the symbol is not embedded in the EPS file.
Cheers,
Alan Isaac

On 2008年3月25日, Chris Withers apparently wrote:
> Install NumPy from here:
> http://downloads.sourceforge.net/numpy/numpy-1.0.4.win32-p3-py2.5.exe 
I missed the OP's query, so just for insurance:
use the p3 version if you have a Pentium 3 (no SSE2 support).
On newer Pentiums, you do not need this version.
Cheers,
Alan Isaac

Mark Bakker wrote:
> Thanks to Fred, Chris, and JV for reproducing this bug.
> We all get the same eps file, that doesn't show the greek symbols 
> produced with mathtext.
> And we all do get correct results on the screen (using Tk) and in pdf 
> and png files.
I loaded the *eps* file in Adobe Photoshop and the *chi* letter **was** 
displayed along the x-axis. -- jv
> It seems not to work on windows, while it used to work on versions 
> 0.90.1 and earlier.
> Sorry for the bad news.
> Anybody know how to fix this?
>
> Thanks, Mark
>
> On Sun, Mar 23, 2008 at 5:02 PM, Mark Bakker <ma...@gm... 
> <mailto:ma...@gm...>> wrote:
>
> Hello windows users -
>
> Can anybody using mpl 0.91.2 on windows reproduce this bug:
>
> from pylab import *
> plot([1,2,3])
> xlabel(r'$\chi$')
> savefig('c:/temp/test.eps')
>
> This should give an eps file that when viewed does not show the
> letter chi along the x-axis (that's the bug).
>
> We have been discussing this problem, and I think it is a bug in
> the windows distribution.
> (It worked on all the previous mpl versions fine, just when
> upgrading from 0.90.1 the problem arose).
>
> If you can, please email me your eps file: ma...@gm...
> <mailto:ma...@gm...>
>
> Thanks for your help, Mark
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> 

Can you attach the traceback?
Cheers,
Mike
Wolfgang Kerzendorf wrote:
> Hello,
>
> I have some trouble with ipython and matplotlib. I create a figure in 
> one of my functions that I call from ipython. The first time it runs 
> fine and I can use the figure interactively (selecting/ deselcting 
> points and so on). The second time I run it, the code doesnt stop but 
> continues without halting at the show routine.
> I'm doing this on a Mac (10.5.2/ Intel). On my Linux machine I did 
> pylab.get_current_figure_manager().destroy() and bound it to a key to 
> prevent this. If I do this on the mac (WXAgg) The next time I want to 
> plot it complains about a deleted C++ extension and doesnt plot at all.
> Please help
> Wolfgang
>
> -------------------------------------------------------------------------
> 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