matplotlib-users Mailing List for matplotlib

Ted Drain wrote:
> I don't think so.  We always manually check for horizontal and 
> vertical axis crossings and split the line as many times as necessary.
>   

One other solution  might be to not plot a line, but use scatter to plot 
the individual points.  If there are enough of them, it will look OK.

-Jeff
> At 03:31 PM 8/2/2007, James Boyle wrote:
>   
>> This is probably for Jeff but maybe someone else has an answer.
>> If I plot a satellite orbit on the globe when the groundtrack passes
>> the edge of the map - in this case the Greenwich meridian  - the
>> line  'snaps back ' across the plot where the line picks up on the
>> other side of the globe.
>> The attached plot shows the problem, note the line across the
>> northern polar regions. I have encountered this before. In this case
>> I can break the ground track into two segments, one up to and
>> including Greenwich and the other from Greenwich eastward.
>>
>> My question: Is there a more elegant way to deal with this situation
>> in Basemap? I have a nagging feeling that Jeff has addressed this
>> issue but I cannot find anything in the examples.
>>
>> --Jim
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>     
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

I don't think so.  We always manually check for horizontal and 
vertical axis crossings and split the line as many times as necessary.

At 03:31 PM 8/2/2007, James Boyle wrote:
>This is probably for Jeff but maybe someone else has an answer.
>If I plot a satellite orbit on the globe when the groundtrack passes
>the edge of the map - in this case the Greenwich meridian  - the
>line  'snaps back ' across the plot where the line picks up on the
>other side of the globe.
>The attached plot shows the problem, note the line across the
>northern polar regions. I have encountered this before. In this case
>I can break the ground track into two segments, one up to and
>including Greenwich and the other from Greenwich eastward.
>
>My question: Is there a more elegant way to deal with this situation
>in Basemap? I have a nagging feeling that Jeff has addressed this
>issue but I cannot find anything in the examples.
>
>--Jim
>
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >>  http://get.splunk.com/
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users

This is probably for Jeff but maybe someone else has an answer.
If I plot a satellite orbit on the globe when the groundtrack passes  
the edge of the map - in this case the Greenwich meridian  - the  
line  'snaps back ' across the plot where the line picks up on the  
other side of the globe.
The attached plot shows the problem, note the line across the  
northern polar regions. I have encountered this before. In this case  
I can break the ground track into two segments, one up to and  
including Greenwich and the other from Greenwich eastward.

My question: Is there a more elegant way to deal with this situation  
in Basemap? I have a nagging feeling that Jeff has addressed this  
issue but I cannot find anything in the examples.

--Jim

Oh--sorry I didn't read carefully--I don't need to install from source if
there is a binary of the current svn version.

Thanks!!

William


On 8/2/07, william ratcliff <wil...@gm...> wrote:
>
> One of my colleagues, Paul Kienzle has made a number of additions to
> matplotlib for interacting with artists.  I need to use some of those
> additions--which are not included in the stable release.  Paul's on
> vacation, so I am trying to start from source.
>
> Thanks,
> William
>
> On 8/2/07, John Hunter <jd...@gm...> wrote:
> >
> > On 8/2/07, william ratcliff <wil...@gm...> wrote:
> > > Thanks again for all your work on this.  I moved my old minGW and
> > installed
> > > MinGW-5.1.3 , and was already running the others--except numpy, I have
> > the
> > > latest version from svn, which I compiled and built fine after
> > building
> > > atlas.  I checked out matplotlib from svn and did the same as you
> > > --I didn't try using the importlib batch file--I have a
> > libpython25.a--so,
> > > after changing the profile24.bat to profile25.bat with appropriate
> > path
> > > changes and your modifications to setup.py, I built it.  I then
> > installed
> > > it--no problems yet.  I then tried to use it with embedding_in_wx4.py
> > and
> > > python crashes and burns.  I find that it crashes with the same
> > LazyValue
> > > error. Something similar happened to one of my colleagues who tried
> > building
> > > with visual studio instead of mingw.  He's given up and is now running
> > it on
> > > his Mac.  Sadly, I don't have that option.  Does anyone else have any
> > ideas?
> >
> > Charlie Moad does our win32 builds for releases -- Charlie if you get
> > a minute could you see if your build pipeline is still working OK with
> > the recent svn changes, and if so take pity on poor William and send
> > him an installer?
> >
> > Or is there some reason you *need* to be building from src William?
> >
> > Thanks,
> > JDH
> >
>
>

One of my colleagues, Paul Kienzle has made a number of additions to
matplotlib for interacting with artists.  I need to use some of those
additions--which are not included in the stable release.  Paul's on
vacation, so I am trying to start from source.

Thanks,
William

On 8/2/07, John Hunter <jd...@gm...> wrote:
>
> On 8/2/07, william ratcliff <wil...@gm...> wrote:
> > Thanks again for all your work on this.  I moved my old minGW and
> installed
> > MinGW-5.1.3, and was already running the others--except numpy, I have
> the
> > latest version from svn, which I compiled and built fine after building
> > atlas.  I checked out matplotlib from svn and did the same as you
> > --I didn't try using the importlib batch file--I have a
> libpython25.a--so,
> > after changing the profile24.bat to profile25.bat with appropriate path
> > changes and your modifications to setup.py, I built it.  I then
> installed
> > it--no problems yet.  I then tried to use it with embedding_in_wx4.py
> and
> > python crashes and burns.  I find that it crashes with the same
> LazyValue
> > error. Something similar happened to one of my colleagues who tried
> building
> > with visual studio instead of mingw.  He's given up and is now running
> it on
> > his Mac.  Sadly, I don't have that option.  Does anyone else have any
> ideas?
>
> Charlie Moad does our win32 builds for releases -- Charlie if you get
> a minute could you see if your build pipeline is still working OK with
> the recent svn changes, and if so take pity on poor William and send
> him an installer?
>
> Or is there some reason you *need* to be building from src William?
>
> Thanks,
> JDH
>

On 8/2/07, william ratcliff <wil...@gm...> wrote:
> Thanks again for all your work on this.  I moved my old minGW and installed
> MinGW-5.1.3, and was already running the others--except numpy, I have the
> latest version from svn, which I compiled and built fine after building
> atlas.  I checked out matplotlib from svn and did the same as you
> --I didn't try using the importlib batch file--I have a libpython25.a--so,
> after changing the profile24.bat to profile25.bat with appropriate path
> changes and your modifications to setup.py, I built it.  I then installed
> it--no problems yet.  I then tried to use it with embedding_in_wx4.py and
> python crashes and burns.  I find that it crashes with the same LazyValue
> error. Something similar happened to one of my colleagues who tried building
> with visual studio instead of mingw.  He's given up and is now running it on
> his Mac.  Sadly, I don't have that option.  Does anyone else have any ideas?

Charlie Moad does our win32 builds for releases -- Charlie if you get
a minute could you see if your build pipeline is still working OK with
the recent svn changes, and if so take pity on poor William and send
him an installer?

Or is there some reason you *need* to be building from src William?

Thanks,
JDH

Thanks again for all your work on this.  I moved my old minGW and installed
MinGW-5.1.3, and was already running the others--except numpy, I have the
latest version from svn, which I compiled and built fine after building
atlas.  I checked out matplotlib from svn and did the same as you
--I didn't try using the importlib batch file--I have a libpython25.a--so,
after changing the profile24.bat to profile25.bat with appropriate path
changes and your modifications to setup.py, I built it.  I then installed
it--no problems yet.  I then tried to use it with embedding_in_wx4.py and
python crashes and burns.  I find that it crashes with the same LazyValue
error. Something similar happened to one of my colleagues who tried building
with visual studio instead of mingw.  He's given up and is now running it on
his Mac.  Sadly, I don't have that option.  Does anyone else have any ideas?

Thanks,
William

On 8/2/07, Michael Droettboom <md...@st...> wrote:
>
> Well, the good news is that I was able to get it to compile and run the
> wxPython backend on Windows.  The bad news is that my symptoms are different
> enough from yours that I'm not sure this will help you.
>
> I started with a reasonably clean Windows XP SP2 machine with no
> development tools on it.  I installed (using the standard binary installers)
> the most recent stable releases of the following:
>
> - Python 2.5.1 (python.org)
> - wxPython-2.8.4.0
> - numpy-1.0.3
> - MinGW-5.1.3 (selecting the "current" release option)
> - MSys-1.0.10
>
> I checked out the latest matplotlib from svn (r3662).
>
> I downloaded and uncompressed win32_static from here:
> http://matplotlib.sourceforge.net/win32_static.tar.gz
>
> I did not do the pexports step, as I don't think MinGW requires it any
> longer.
>
> I updated profile24.bat to point at my new Python 2.5 (this should
> probably be added to win32_static when someone gets a chance).
>
> I then built and installed using:
>
> python setup.py build --compiler=mingw32 install
>
> (Note that I didn't build and use the Windows installer as the
> instructions suggest -- I doubt that makes a difference, though).
>
> It built fine the first time.
>
> Then I ran into problems.  When importing certain extension modules
> (ft2font, _transforms etc.), but not others (ttconv), I got a dialog with
> the error message:
>
>   "The procedure entry point _ctype could not be located in
> the dynamic link library msvcr71.dll"
>
> ...and then the module would fail to load.
>
> This is quite different from what William was seeing, since for him the
> modules were obviously loading and then failing in the initialization code.
>
> Googling tells me that this is because libstdc++ (specifically the
> <string> and <iostream> stuff) depends on _ctype for determining the types
> of various ASCII characters, which was in msvcrt.dll but was removed from
> msvcrt71.dll.  Python2.5 is built with and therefore requires its
> extensions to link to msvcrt71.dll, so that's what you get by
> default.  Fortunately, it doesn't seem to hurt to link to both.  I added the
> following to setup.py, right before the final "distrib = setup(..."
> section:
>
>     from setupext import get_win32_compiler
>     if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
>         for module in ext_modules:
>             module.libraries.append("msvcrt")
>
> After this change, I was able to run embedding_in_wx4.py and get a window
> with a plot in it.  Everything *seems* to be in order.
>
> William, I'm really curious if the above fix solves your problem.  I
> probably shouldn't spend too much more time on this myself, as Windows isn't
> a very common platform for us (by that I mean my employer, STScI, not
> matplotlib as a whole).  If I can admit selfishness, I really just wanted to
> make sure I hadn't hosed anything with my recent setup.py changes.  I
> think that has been ruled out, and instead we now have what looks like a big
> amorphous configuration-difference problem.
>
> Cheers,
> Mike
>

Well, the good news is that I was able to get it to compile and run the wxPython backend on Windows.  The bad news is that my symptoms are different enough from yours that I'm not sure this will help you.

I started with a reasonably clean Windows XP SP2 machine with no development tools on it.  I installed (using the standard binary installers) the most recent stable releases of the following:

 - Python 2.5.1 (python.org)
 - wxPython-2.8.4.0
 - numpy-1.0.3
 - MinGW-5.1.3 (selecting the "current" release option)
 - MSys-1.0.10

I checked out the latest matplotlib from svn (r3662).

I downloaded and uncompressed win32_static from here: http://matplotlib.sourceforge.net/win32_static.tar.gz

I did not do the pexports step, as I don't think MinGW requires it any longer.

I updated profile24.bat to point at my new Python 2.5 (this should probably be added to win32_static when someone gets a chance).

I then built and installed using:

python setup.py build --compiler=mingw32 install

(Note that I didn't build and use the Windows installer as the instructions suggest -- I doubt that makes a difference, though).

It built fine the first time.

Then I ran into problems.  When importing certain extension modules (ft2font, _transforms etc.), but not others (ttconv), I got a dialog with the error message:

  "The procedure entry point _ctype could not be located in
the dynamic link library msvcr71.dll"

...and then the module would fail to load.

This is quite different from what William was seeing, since for him the modules were obviously loading and then failing in the initialization code.

Googling tells me that this is because libstdc++ (specifically the <string> and <iostream> stuff) depends on _ctype for determining the types of various ASCII characters, which was in msvcrt.dll but was removed from msvcrt71.dll.  Python2.5 is built with and therefore requires its extensions to link to msvcrt71.dll, so that's what you get by default.  Fortunately, it doesn't seem to hurt to link to both.  I added the following to setup.py, right before the final "distrib = setup(..." section:

    from setupext import get_win32_compiler
    if sys.platform == 'win32' and get_win32_compiler() == 'mingw32':
        for module in ext_modules:
            module.libraries.append("msvcrt")

After this change, I was able to run embedding_in_wx4.py and get a window with a plot in it.  Everything *seems* to be in order.

William, I'm really curious if the above fix solves your problem.  I probably shouldn't spend too much more time on this myself, as Windows isn't a very common platform for us (by that I mean my employer, STScI, not matplotlib as a whole).  If I can admit selfishness, I really just wanted to make sure I hadn't hosed anything with my recent setup.py changes.  I think that has been ruled out, and instead we now have what looks like a big amorphous configuration-difference problem.

Cheers,
Mike

Thank you Christopher that's great. wxPython working fine, no warnings.

Cong.

On 8/2/07, Christopher Barker <Chr...@no...> wrote:
>
> fri...@gm... wrote:
> > Dear all: The first problem was fixed by upgrading to a recent version
> > of ipython. As for the second (IPP stuff) warning ... still pending but
> > doesn't doing harm currently.
>
> A question to the wxPython mailing list may be in order for that one. AS
> a little test, trying running the enclosed, about-as-small-as-it-gets
> wxPython app, and see if you get the same warning.
>
> -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,
Here a quick update:
I'm trying to have a concise / sparse module with containing only
pylab-specific names and not all names I already have in numpy.
To easy typing I want to call numpy "N" and my pylab "P".

I'm now using this code:
<code snipplet for importing matplotlib>
    import matplotlib, new
    matplotlib.use('WXAgg')
    from  matplotlib import pylab
    P = new.module("pylab_sparse","""pylab module minus stuff alreay
in numpy""")
    for k,v in pylab.__dict__.iteritems():
        try:
           if v is N.__dict__[k]:
               continue
        except KeyError:
           pass
        P.__dict__[k] = v

    P.ion()
    del matplotlib, new, pylab
</code sniplet for importing matplotlib>

The result is "some" reduction in the number of non-pylab-specific
names in my "P"-module. However there seem to be still many extra
names left, like e.g.:
alltrue, amax, array, ...
look at this:
    # 20070802
    # >>> len(dir(pylab))
    # 441
    # >>> len(dir(P))
    # 346
    # >>> P.nx.numpy.__version__
    # '1.0.1'
    # >>> N.__version__
    # '1.0.1'
    # >>> N.alltrue
    # <function alltrue at 0x01471B70>
    # >>> P.alltrue
    # <function alltrue at 0x019142F0>
    # >>> N.alltrue.__doc__
    # 'Perform a logical_and over the given axis.'
    # >>> P.alltrue.__doc__
    # >>> #N.alltrue(x, axis=None, out=None)
    # >>> #P.alltrue(x, axis=0)

I'm using matplotlib with
__version__  = '0.90.0'
__revision__ = '$Revision: 3003 $'
__date__     = '$Date: 2007-02-06 22:24:06 -0500 (Tue, 06 Feb 2007) $'


Any hint how to further reduce the number of names in "P" ?
My ideal would be that the "P" module (short for pylab) would only
contain the stuff described in the __doc__ strings of `pylab.py` and
`__init__.py`(in matplotlib)  (+ plus some extra, undocumented, yet
pylab specific things)

Thanks
-Sebastian


On 3/16/07, Eric Firing <ef...@ha...> wrote:
> Sebastian Haase wrote:
> > Hi!
> > I use the wxPython PyShell.
> > I like especially the feature that when typing a module and then the
> > dot "." I get a popup list of all available functions (names) inside
> > that module.
> >
> > Secondly,  I think it really makes code clearer when one can see where
> > a function comes from.
> >
> > I have a default
> > import numpy as N
> > executed before my shell even starts.
> > In fact I have a bunch of my "standard" modules imported as <some
> > single capital letter>.
> >
> > This - I think - is a good compromise to the commonly used "extra
> > typing" and "unreadable"  argument.
> >
> > a = sin(b) * arange(10,50, .1) * cos(d)
> > vs.
> > a = N.sin(b) * N.arange(10,50, .1) * N.cos(d)
>
> I generally do the latter, but really, all those "N." bits are still
> visual noise when it comes to reading the code--that is, seeing the
> algorithm rather than where the functions come from.  I don't think
> there is anything wrong with explicitly importing commonly-used names,
> especially things like sin and cos.
>
> >
> > I would like to hear some comments by others.
> >
> >
> > On a different note: I just started using pylab, so I did added an
> > automatic  "from matplotlib import pylab as P" -- but now P contains
> > everything that I already have in N.  It makes it really hard to
> > *find* (as in *see* n the popup-list) the pylab-only functions. --
> > what can I do about this ?
>
> A quick and dirty solution would be to comment out most of the imports
> in pylab.py; they are not needed for the pylab functions and are there
> only to give people lots of functionality in a single namespace.
>
> I am cross-posting this to matplotlib-users because it involves mpl, and
> an alternative solution would be for us to add an rcParam entry to allow
> one to turn off all of the namespace consolidation.  A danger is that if
> someone is using "from pylab import *" in a script, then whether it
> would run would depend on the matplotlibrc file.  To get around that,
> another possibility would be to break pylab.py into two parts, with
> pylab.py continuing to do the namespace consolidation and importing the
> second part, which would contain the actual pylab functions.  Then if
> you don't want the namespace consolidation, you could simply import the
> second part instead of pylab.  There may be devils in the details, but
> it seems to me that this last alternative--splitting pylab.py--might
> make a number of people happier while having no adverse effects on
> everyone else.
>
> Eric
> >
> >
> > Thanks,
> > Sebastian