On 7/13/07, Rob Hetland <[EMAIL PROTECTED]> wrote:
>
> Nope -- the same occurs in the regular terminal, so it's not
> iPython's fault.
>
> Also, although I though I remembered this happening with qt4 (as
> posted below), I do not seem to be able to reproduce this now..
>
> Also, clearing and closin
Nope -- the same occurs in the regular terminal, so it's not
iPython's fault.
Also, although I though I remembered this happening with qt4 (as
posted below), I do not seem to be able to reproduce this now..
Also, clearing and closing the figure works fine -- only clicking it
away triggers
FWIW, I'm able to reproduce this here. I have a hunch it may be related
to my recent Tk memory leak "improvements". I'll look into this further
and get back soon.
Cheers,
Mike
John Hunter wrote:
> On 7/13/07, Rob Hetland <[EMAIL PROTECTED]> wrote:
>
>> Nope -- the same occurs in the regula
On Jul 13, 2007, at 9:14 AM, John Hunter wrote:
>
> Try importing these packages individually
>
> import matplotlib._image
> import matplotlib._transforms
>
> #one of these three depending on which numerix package you are using
> import matplotlib.backends._na_backend_agg # for numarray
> imp
This looks like that was introduced by a patching error when fixing the
Tk save figure bug recently. The bug tracker added an extraneous
newline to my patch submitted as a comment. (That's the last time I do
that ;)
http://sourceforge.net/tracker/index.php?func=detail&aid=1716732&group_id=807
hello,
I'm writing a program where the user can create annotations while interactively
zooming and panning the graph. I kept getting errors when my panning would for
the arrows to point toward the right. you can recreate the error by going to
the example 'annotation_demo.py' and try to make th
On 7/13/07, BOONTHANOME NOUANESENGSY <[EMAIL PROTECTED]> wrote:
> r = math.sqrt((y2-y1)**2. + (x2-x1)**2.)
>
> This change seemed to fix the errors I was getting
Fixed in svn. Thanks for the report.
JDH
-
This SF.net email
John, Darren,
Yes, the STIX schedule is still slip-sliding away...
Eric
--- Begin Message ---
We will put you on the email notification list for when the beta fonts are
available. Currently, it appears that 15 August is about the earliest that
might occur.
With best regards,
Tim Ingoldsby
Di
On 7/13/07, Tom Holroyd (NIH/NIMH) [E] <[EMAIL PROTECTED]> wrote:
> import matplotlib as mpl
>
> and use mpl.artist, etc.
I don't think this will work in this form. artist is a module, and it
is not imported simply by importing matplotlib
In [1]: import matplotlib as mpl
In [2]: mpl.artist
---
John Hunter wrote:
> from matplotlib import artist as mpl_artist
> from matplotlib import agg as mpl_agg
> from matplotlib import axis as mpl_axis
> from matplotlib import cbook as mpl_cbook
> from matplotlib import collections as mpl_collections
> from matplotlib import colors as mpl_colors
> fr
On 7/13/07, Ted Drain <[EMAIL PROTECTED]> wrote:
> I think he means that the matplotlib/__init__.py file should be
> changed to that those things are imported.
but if __init__.py imports axes, and axes import matplotlib, don't we
still have the problem of recursive imports?
JDH
-
I think he means that the matplotlib/__init__.py file should be
changed to that those things are imported.
At 01:12 PM 7/13/2007, John Hunter wrote:
>On 7/13/07, Tom Holroyd (NIH/NIMH) [E] <[EMAIL PROTECTED]> wrote:
>
> > import matplotlib as mpl
> >
> > and use mpl.artist, etc.
>
>I don't think
I just removed the last vestiges of the numerix extension code layer.
The conditional imports are gone from the extension code, the -D flags
are gone from the compile, as is the _ns_ module naming scheme. This
is a fairly major change, so please blow away your install and build
dirs after updating
On Fri, Jul 13, 2007 at 03:06:45PM -0500, John Hunter wrote:
> Because the mpl_ prefix occurs nowhere else, we can easily change this
> to whatever we want with a single search replace.
I haven't sync'd with the repository yet so I can check this assertion:
h123063:~/src/matplotlib$ find . -nam
First of all, Qt4 does appear to work fine.
Second. I am trying to recompile, and I get the error attached
below. Somebody had mentioned needing a recent version of gcc. Is
this the problem here, or is it another bug?
-Rob
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4
Yes - it doesn't solve or address the recursive import problem. My
impression was that Tom was making a user interface assertion that doing:
import matplotlib as mpl
would be simpler for people than doing:
from matplotlib import mpl
of course I could be complete wrong as well :)
I think the
grr. that's probably my fault. I just fiddled with the definition of
npy. I tested this on linux and thought I copied it pretty directly from
numpy, so I assumed it would work elsewhere, but it's not. I'll see what
I can do...
Rob Hetland wrote:
> First of all, Qt4 does appear to work fine.
>
> S
Ted Drain wrote:
> I think the basic idea is that if I want to use MPL, I should import
> it and go and I should not have to import a sub-module out of MPL as
> the main API.
Yeah, about that, my typical usage is actually "from pylab import *".
I guess I am unclear about the relationship betwe
On 7/13/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> grr. that's probably my fault. I just fiddled with the definition of
> npy. I tested this on linux and thought I copied it pretty directly from
> numpy, so I assumed it would work elsewhere, but it's not. I'll see what
> I can do...
It amy also
John Hunter wrote:
> On 7/13/07, Ted Drain <[EMAIL PROTECTED]> wrote:
>> I think he means that the matplotlib/__init__.py file should be
>> changed to that those things are imported.
>
> but if __init__.py imports axes, and axes import matplotlib, don't we
> still have the problem of recursive imp
Tom Holroyd (NIH/NIMH) [E] wrote:
>
> Ted Drain wrote:
>> I think the basic idea is that if I want to use MPL, I should import
>> it and go and I should not have to import a sub-module out of MPL as
>> the main API.
>
> Yeah, about that, my typical usage is actually "from pylab import *".
> I g
John Hunter wrote:
> On 7/13/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> grr. that's probably my fault. I just fiddled with the definition of
>> npy. I tested this on linux and thought I copied it pretty directly from
>> numpy, so I assumed it would work elsewhere, but it's not. I'll see what
>>
Eric Firing wrote:
> Tom Holroyd (NIH/NIMH) [E] wrote:
>>
>> Ted Drain wrote:
>>> I think the basic idea is that if I want to use MPL, I should import
>>> it and go and I should not have to import a sub-module out of MPL as
>>> the main API.
>>
>> Yeah, about that, my typical usage is actually "f
Eric Firing wrote:
> John Hunter wrote:
>> On 7/13/07, Ted Drain <[EMAIL PROTECTED]> wrote:
>>> I think he means that the matplotlib/__init__.py file should be
>>> changed to that those things are imported.
>> but if __init__.py imports axes, and axes import matplotlib, don't we
>> still have the p
I think I figured out and fixed the situation with isnan.
>From http://lists.apple.com/archives/xcode-users/2005/Feb/msg00196.html
>
> Basically the story is this:
> isnan() is a C99 extension to standard C.
> Standard C++ is based on an older standard of C.
> Hence isnan() is not part of standa
John Hunter wrote:
> I don't think this will work in this form. artist is a module, and it
> is not imported simply by importing matplotlib
>
> In [1]: import matplotlib as mpl
>
> In [2]: mpl.artist
however, this seems to work (though it looks perhaps a bit odd)
>>> import matplotlib as mpl
>
Christopher Barker wrote:
> John Hunter wrote:
[...]
> I do wish that:
>
import matplotlib as mpl
import mpl.artist
> Traceback (most recent call last):
>File "", line 1, in
> ImportError: No module named mpl.artist
>
> worked.
The way I have it working now (on my machine, not in
Tom Holroyd (NIH/NIMH) [E] wrote:
[...]
> If I say
>
import matplotlib
help(matplotlib)
>
> (This is with 0.90.0 by the way)
>
> It basically gives me the help I'd expect for pylab. Oh, and it says
> "the" instead of "to". It's a little weird thinking of a library as the
> top level
It seems to be working now. Thanks!
This is a perfect example of quick response. I keep telling people
that, sure, the scientific python suite has occasional bugs, but the
community is *very* responsive. This is a perfect example. Thanks
to everybody that helped,
-Rob
> Rob, you shoul
On 7/13/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
> I think I figured out and fixed the situation with isnan.
>
> >From http://lists.apple.com/archives/xcode-users/2005/Feb/msg00196.html
>
> >
> > Basically the story is this:
> > isnan() is a C99 extension to standard C.
> > Standard C++ is based
Can you stick this in the top of src/_transforms.cpp and see if you
still get the problem?
#define _GLIBCPP_USE_C99
-Andrew
John Hunter wrote:
> On 7/13/07, Andrew Straw <[EMAIL PROTECTED]> wrote:
>> I think I figured out and fixed the situation with isnan.
>>
>> >From http://lists.apple.com/arc
OK, I reverted back to the tried and true MPL way... It hasn't been
completely unproductive, however: I added tests for infinity (either
sign) and finite-ness to MPL_isnan.h. (On top of which I now understand
the IEEE 754 representations far better than I care to.)
Now, this should work just li
32 matches
Mail list logo
