matplotlib-devel Mailing List for matplotlib

On Sun, May 22, 2011 at 4:11 PM, Eric Firing <ef...@ha...> wrote:

> On 05/22/2011 10:07 AM, Benjamin Root wrote:
>
> > I went ahead with the merge conflict procedure, and everything appear to
> > be ok.  I had also noticed a few additional mistakes in the INSTALL file
> > currently in v1.0.x that I fixed as well.  I will double-check the
> > commit/merge before pushing it up.
> >
> > I also noticed that the INSTALL doc on v1.0.x provided an equivalent
> > command of `apt-get build-dep` for Fedora/RedHat users.  I believe this
> > information should also be included in the install_faq.rst document
> > (because it only has the debian version).  I will make that a separate
> > commit.
> >
> > Ben Root
>
> Ben, a quick look at installing_faq.rst shows some anachronisms:
> references to installing obsolete versions.  This is another worm
> barrel.  Those anachronisms are not the only problems with the file--or
> with installation in general.
>
> Eric
>
>
I'll double-check for that.  Note that I am merely moving my changes over to
INSTALL, so whatever INSTALL has should be the final version.  Below is the
current diff between them.

On a separate note, I think there might be some unspecified requirements for
building the documentation.  On my newly set up Ubuntu machine, the build
gets to the thumbnails stage and recognizes that I have no thumbnails, and
then the process goes to sleep.  Maybe we have an error check missing
somewhere?

Ben Root


ben@tigger:~/Programs/matplotlib$ diff INSTALL doc/users/installing.rst
0a1,2
> .. _installing:
>
23c25
< Manually installing pre-built packages
---
> OK, so you want to do it the hard way?
81c83
< :ref:`install_osx_binaries`.
---
> ref:`install_osx_binaries`.
88,112d89
< Installing on Windows
< ---------------------
<
< If you don't already have python installed, you may want to consider
< using the enthought edition of python, which has scipy, numpy, and
< wxpython, plus a lot of other goodies, preinstalled - `Enthought
< Python <http://www.enthought.com/python>`_.  With the enthought
< edition of python + matplotlib installer, the following backends
< should work out of the box: agg, wx, wxagg, tkagg, ps, pdf and svg.
<
< For standard python installations, you will also need to install numpy
< in addition to the matplotlib installer.  On some systems you will
< also need to download msvcp71.dll library, which you can download from
< http://www.dll-files.com/dllindex/dll-files.shtml?msvcp71 or other
< sites.  You will need to unzip the archive and drag the dll into
< :file:`c:\windows\system32`.
<
< All of the GUI backends run on windows, but TkAgg is probably the
< best for interactive use from the standard python shell or ipython.
< The windows installer (:file:`*.exe`) on the download page contains all
the
< code you need to get up and running.  However, there are many
< examples that are not included in the windows installer.  If you
< want to try the many demos that come in the matplotlib src
< distribution, download the zip file and look in the examples subdir.
<
142,147d118
< If you have installed prerequisites to nonstandard places and need to
< inform matplotlib where they are, edit ``setupext.py`` and add the base
< dirs to the ``basedir`` dictionary entry for your ``sys.platform``.
< e.g., if the header to some required library is in
< ``/some/path/include/someheader.h``, put ``/some/path`` in the
< ``basedir`` list for your platform.
163,178d133
< .. note::
<
<     If you are on debian/ubuntu, you can get all the dependencies
<     required to build matplotlib with::
<
<       sudo apt-get build-dep python-matplotlib
<
<     This does not build matplotlib, but it does get the install the
<     build dependencies, which will make building from svn easy.
<
<     If you are on Fedora/RedHat, you can get all the dependencies
<     required to build matplotlib by first installing ``yum-builddep``
<     and then running::
<
<        su -c "yum-builddep python-matplotlib"
<
186c141
< libpng 1.2 (or later)
---
> libpng 1.1 (or later)
216a172,175
> :term:`wxpython` 2.6 or later
>     The python wrappers for the wx widgets library for use with the
>     WXAgg backend
>
219c178
<     WX or WXAgg backend
---
>     WX backend
242a202,203
>
>
246c207
< ===============
---
> ==================

On 05/22/2011 10:07 AM, Benjamin Root wrote:

> I went ahead with the merge conflict procedure, and everything appear to
> be ok.  I had also noticed a few additional mistakes in the INSTALL file
> currently in v1.0.x that I fixed as well.  I will double-check the
> commit/merge before pushing it up.
>
> I also noticed that the INSTALL doc on v1.0.x provided an equivalent
> command of `apt-get build-dep` for Fedora/RedHat users.  I believe this
> information should also be included in the install_faq.rst document
> (because it only has the debian version).  I will make that a separate
> commit.
>
> Ben Root

Ben, a quick look at installing_faq.rst shows some anachronisms: 
references to installing obsolete versions.  This is another worm 
barrel.  Those anachronisms are not the only problems with the file--or 
with installation in general.

Eric

On 05/22/2011 07:04 AM, Mike Kaufman wrote:
> Hi,
>
> After switching over from the MacOSX backend to the GTKAgg backend, I
> started notice a big change in drawing behavior.
>
> Now I know that MacOSX is interactive all the time by [mis]design, so I
> wasn't surprised that I would have to add draw() commands when
> isinteractive()==False; however, when using the non-pyplot commands,
> i.e. ax.plot() rather than plot(), I must use draw() to render the new
> Line2D even when isinteractive()==True. This doesn't seem correct
> behavior to me. A lot of drawing just can't be done by the pyplot
> functions. You have to go to the axes functions.

This is inherent in the design.  Pyplot functions are wrappers that do 
two things: call Axes methods on the current axes, and then call 
draw_if_interactive().  The rationale is that even when working 
interactively, one doesn't necessarily want to draw immediately every 
time a new Artist is created.  So yes, working interactively with the OO 
interface requires frequent plt.draw() invocations, making it only 
semi-interactive.

>
> On another, but related topic, I use ipython -pylab, and generally
> develop by using the `run -i file.py` syntax. I have found what I think
> is a bug where if I have a file that consists of:
>
> cat>>  file.py<<EOF
> print isinteractive()
> EOF
>
> and I do
>
> In [1]: isinteractive()
> Out[1]: True
> In [2]: run -i file.py
> False
>
> which means I either have to do ion() or draw() each time even for
> pyplot commands. Is this a bug in ipython or matplotlib?

I think it is inherent in the -pylab mode of ipython, which is designed 
to run a script as if it were being run directly from the command line. 
To do that, it turns interactive mode off before running the script, and 
restores interactive mode to its original value afterwards.  A script 
intended to produce a screen plot includes a show() command.  Running 
such a script with ipython -pylab then leaves one or more plots with 
which one can interact directly or via the ipython command line--but in 
the latter case, if pyplot functions are not used, then draw() must be 
used for a redraw.

If you want the contents of the file to be executed exactly as if you 
had typed them in at the ipython command line, you can use the built-in 
execfile() function instead of the ipython %run magic.

The ipython %edit magic can also be used for this.

Eric

>
> M
>

On Sun, May 22, 2011 at 2:13 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Fri, May 20, 2011 at 6:58 PM, Eric Firing <ef...@ha...> wrote:
>
>>
>> I have not yet tried to build from your branch, but based on
>> descriptions and discussions, it should be a substantial improvement. Go
>> ahead and push when you feel ready. Thank you for all the work.
>>
>>
> I have started to try and merge my branch into the v1.0.x branch when I
> discovered some interesting oddities, and I am not 100% sure how I should go
> about resolving them.  My very first commit in the docfix/smalltypos branch
> edited the doc/users/installing.rst document.  However, it appears that on
> April 1, this file was removed from the repository and its information was
> consolidated over to the INSTALL file.  However, even though I created my
> branch from the v1.0.x branch on April 30th, none of these changes are in my
> branch.  Therefore, given how many other changes that were made to the
> documents, I wonder what other commits are missing.
>
> Should I rebase my docfix/smalltypos branch with v1.0.x first or should I
> use the conflict merge process to let the installing.rst file be removed and
> make the changes I made over in INSTALL?  Or maybe another idea that I
> haven't thought of?
>
> Ben Root
>
>
I went ahead with the merge conflict procedure, and everything appear to be
ok.  I had also noticed a few additional mistakes in the INSTALL file
currently in v1.0.x that I fixed as well.  I will double-check the
commit/merge before pushing it up.

I also noticed that the INSTALL doc on v1.0.x provided an equivalent command
of `apt-get build-dep` for Fedora/RedHat users.  I believe this information
should also be included in the install_faq.rst document (because it only has
the debian version).  I will make that a separate commit.

Ben Root

FYI, here is a github nugget from the scipy people:

-------- Original Message --------
Subject: 	Re: [SciPy-Dev] Used "Automatic Merge" on my github pull
request...
Date: 	Sun, 22 May 2011 11:49:44 +0200
From: 	Ralf Gommers <ral...@go...>
Reply-To: 	SciPy Developers List <sci...@sc...>
To: 	SciPy Developers List <sci...@sc...>





On Sun, May 22, 2011 at 7:51 AM, Warren Weckesser
<war...@en... <mailto:war...@en...>>
wrote:

     I used the "Automatic merge" button on my own pull request on
     github, but afterwards discovered that it uses --no-ff, so my single
     commit also resulted in a "merge" commit:
 
https://github.com/scipy/scipy/commit/cf04a2b8dd4cf258413687ec146883ea5ab197cb

     Should I try to get rid of that merge?  If so, how?  (The git book
     is by my side, but I suspect an answer will show up here faster than
     I can find it.)


No, it's public now so you shouldn't touch it anymore.

That button is very pointless - best to ignore it.

Ralf

On Fri, May 20, 2011 at 6:58 PM, Eric Firing <ef...@ha...> wrote:

>
> I have not yet tried to build from your branch, but based on
> descriptions and discussions, it should be a substantial improvement. Go
> ahead and push when you feel ready. Thank you for all the work.
>
>
I have started to try and merge my branch into the v1.0.x branch when I
discovered some interesting oddities, and I am not 100% sure how I should go
about resolving them.  My very first commit in the docfix/smalltypos branch
edited the doc/users/installing.rst document.  However, it appears that on
April 1, this file was removed from the repository and its information was
consolidated over to the INSTALL file.  However, even though I created my
branch from the v1.0.x branch on April 30th, none of these changes are in my
branch.  Therefore, given how many other changes that were made to the
documents, I wonder what other commits are missing.

Should I rebase my docfix/smalltypos branch with v1.0.x first or should I
use the conflict merge process to let the installing.rst file be removed and
make the changes I made over in INSTALL?  Or maybe another idea that I
haven't thought of?

Ben Root

Hi,

After switching over from the MacOSX backend to the GTKAgg backend, I 
started notice a big change in drawing behavior.

Now I know that MacOSX is interactive all the time by [mis]design, so I 
wasn't surprised that I would have to add draw() commands when 
isinteractive()==False; however, when using the non-pyplot commands, 
i.e. ax.plot() rather than plot(), I must use draw() to render the new 
Line2D even when isinteractive()==True. This doesn't seem correct 
behavior to me. A lot of drawing just can't be done by the pyplot 
functions. You have to go to the axes functions.

On another, but related topic, I use ipython -pylab, and generally 
develop by using the `run -i file.py` syntax. I have found what I think 
is a bug where if I have a file that consists of:

cat >> file.py <<EOF
print isinteractive()
EOF

and I do

In [1]: isinteractive()
Out[1]: True
In [2]: run -i file.py
False

which means I either have to do ion() or draw() each time even for 
pyplot commands. Is this a bug in ipython or matplotlib?

M