matplotlib-devel Mailing List for matplotlib

Hi Gerald,

thank you very much! I applied most of your changes to my matplotlib
version 1.0.1
on Windows with Python 2.6. Together with the new package of PySide I
was able to
migrate a whole project of mine from PyQt to PySide with only minimal changes.
The first test are very promissing. Even some bugs with missing icons
in connection
with py2exe are fixed now.

It would be great to have these changes in the next release of matplotlib!

Best regard,
Lars

On Tue, May 31, 2011 at 11:10 AM, Gerald Storer <gd...@mr...> wrote:
> 1.0.3 packages for Windows and Ubuntu/Debian are available to test with.
>
> I'm not sure that the OS X package is ready yet.  If you want to get
> testing with it quicker jumping up and down on their mailing list
> normally gets them out faster.
>
> I also added an update to formlayout.py.  I've merged in Pierre's latest
> version that validates the floats so an exception isn't thrown when a
> user inputs an invalid number.
>
> Gerald.
>
> On 31/05/2011 4:43 PM, David Trémouilles wrote:
>> The pyside bug affecting matplotlib pyside backend is now fixed
>> with pyside 1.0.3
>>
>> I would be nice to have the pyside option in the next matplotlib release...
>>
>> Regards,
>>
>> David
>>
>> Le 06/05/11 10:32, David Trémouilles a écrit :
>>> Hello,
>>>
>>> This is not directly related to your patch but I would like to
>>> report here that I still have at least one issue on MacOs
>>> that prevent matplotlib to work with your pyside backend.
>>> Indeed current PySide version (1.0.2) have a bug on MacOS that seems to
>>> have been fixed recently:
>>> http://bugs.pyside.org/show_bug.cgi?id=809
>>> But I will have to wait for next PySide release to
>>> confirm your pyside patch works on MacOs.
>>> Will test as soon as next pyside version is out and available on
>>> macports. I do not have time nor will to test with the latest current
>>> pyside head.
>>>
>>> Regards,
>>>
>>> David
>>>
>>>
>>>
>>> Le 06/05/11 03:36, Gerald Storer a écrit :
>>>> Hi,
>>>> I was wondering if I could get a comment on this. Its been 4 weeks
>>>> since I submitted the original version and it has been more or less
>>>> production ready since Monday.
>>>>
>>>> https://github.com/matplotlib/matplotlib/pull/80
>>>>
>>>> Thanks,
>>>> Gerald.
>>>>
>>>> On 11/04/2011 4:49 PM, Gerald Storer wrote:
>>>>> Hi,
>>>>> I've submitted a pull request with backend changes that (should) let
>>>>> all currently supported versions of PyQt work along side PySide. I've
>>>>> tested with PyQt 4.8.3 and PySide 1.0.0.
>>>>>
>>>>> I haven't bothered chasing down old versions of PyQt as they seem
>>>>> elusive.
>>>>>
>>>>> Gerald.
>>>>>
>>>>> On 29/03/2011 3:25 AM, bu...@gm... wrote:
>>>>>> Looking forward, supporting the Python 3 compatible PyQt API is
>>>>>> likely the way to go.
>>>>>>
>>>>>> Le , Gerald Storer<gd...@mr...>  a écrit :
>>>>>>> On 28/03/2011 1:10 AM, Peter Butterworth wrote:
>>>>>>>
>>>>>>>
>>>>>>> Wouldn't it be possible to use a single backend compatible with both
>>>>>>>
>>>>>>> PyQt and Pyside ?
>>>>>>>
>>>>>>>
>>>>>>> The current Qt mpl backend uses the old PyQt slots/signals API
>>>>>> which PySide doesn't really support (there are some macros but they
>>>>>> don't work 100% the same). From a quick glance at the IPython
>>>>>> implementation it looks like they are using the new API which means
>>>>>> older versions (<4.5) of PyQt won't be supported. This might be ok, I
>>>>>> don't know.
>>>>>>> If it isn't then, there will need to be some try...excepts around
>>>>>> the place or separate back ends. If you ignore the PySide bugs I had
>>>>>> to work around I've only changed ~4 lines in the main backend.
>>>>>>>
>>>>>>>
>>>>>>> Pierre's formlayout is also using an obsolete method that isn't
>>>>>> present in PySide. I've opted to emulate it, but it would be best to
>>>>>> change the code to use the alternative method available in both PyQt
>>>>>> and PySide. formlayout also uses the old QString implementation of
>>>>>> PyQt, PySide only supports the new implementation where QString is
>>>>>> transparently convert to/from str/unicode. Setting QString = unicode
>>>>>> seems to work though.
>>>>>>>
>>>>>>>
>>>>>>> Gerald.
>>>>>>>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

1.0.3 packages for Windows and Ubuntu/Debian are available to test with.

I'm not sure that the OS X package is ready yet.  If you want to get 
testing with it quicker jumping up and down on their mailing list 
normally gets them out faster.

I also added an update to formlayout.py.  I've merged in Pierre's latest 
version that validates the floats so an exception isn't thrown when a 
user inputs an invalid number.

Gerald.

On 31/05/2011 4:43 PM, David Trémouilles wrote:
> The pyside bug affecting matplotlib pyside backend is now fixed
> with pyside 1.0.3
>
> I would be nice to have the pyside option in the next matplotlib release...
>
> Regards,
>
> David
>
> Le 06/05/11 10:32, David Trémouilles a écrit :
>> Hello,
>>
>> This is not directly related to your patch but I would like to
>> report here that I still have at least one issue on MacOs
>> that prevent matplotlib to work with your pyside backend.
>> Indeed current PySide version (1.0.2) have a bug on MacOS that seems to
>> have been fixed recently:
>> http://bugs.pyside.org/show_bug.cgi?id=809
>> But I will have to wait for next PySide release to
>> confirm your pyside patch works on MacOs.
>> Will test as soon as next pyside version is out and available on
>> macports. I do not have time nor will to test with the latest current
>> pyside head.
>>
>> Regards,
>>
>> David
>>
>>
>>
>> Le 06/05/11 03:36, Gerald Storer a écrit :
>>> Hi,
>>> I was wondering if I could get a comment on this. Its been 4 weeks
>>> since I submitted the original version and it has been more or less
>>> production ready since Monday.
>>>
>>> https://github.com/matplotlib/matplotlib/pull/80
>>>
>>> Thanks,
>>> Gerald.
>>>
>>> On 11/04/2011 4:49 PM, Gerald Storer wrote:
>>>> Hi,
>>>> I've submitted a pull request with backend changes that (should) let
>>>> all currently supported versions of PyQt work along side PySide. I've
>>>> tested with PyQt 4.8.3 and PySide 1.0.0.
>>>>
>>>> I haven't bothered chasing down old versions of PyQt as they seem
>>>> elusive.
>>>>
>>>> Gerald.
>>>>
>>>> On 29/03/2011 3:25 AM, bu...@gm... wrote:
>>>>> Looking forward, supporting the Python 3 compatible PyQt API is
>>>>> likely the way to go.
>>>>>
>>>>> Le , Gerald Storer<gd...@mr...>  a écrit :
>>>>>> On 28/03/2011 1:10 AM, Peter Butterworth wrote:
>>>>>>
>>>>>>
>>>>>> Wouldn't it be possible to use a single backend compatible with both
>>>>>>
>>>>>> PyQt and Pyside ?
>>>>>>
>>>>>>
>>>>>> The current Qt mpl backend uses the old PyQt slots/signals API
>>>>> which PySide doesn't really support (there are some macros but they
>>>>> don't work 100% the same). From a quick glance at the IPython
>>>>> implementation it looks like they are using the new API which means
>>>>> older versions (<4.5) of PyQt won't be supported. This might be ok, I
>>>>> don't know.
>>>>>> If it isn't then, there will need to be some try...excepts around
>>>>> the place or separate back ends. If you ignore the PySide bugs I had
>>>>> to work around I've only changed ~4 lines in the main backend.
>>>>>>
>>>>>>
>>>>>> Pierre's formlayout is also using an obsolete method that isn't
>>>>> present in PySide. I've opted to emulate it, but it would be best to
>>>>> change the code to use the alternative method available in both PyQt
>>>>> and PySide. formlayout also uses the old QString implementation of
>>>>> PyQt, PySide only supports the new implementation where QString is
>>>>> transparently convert to/from str/unicode. Setting QString = unicode
>>>>> seems to work though.
>>>>>>
>>>>>>
>>>>>> Gerald.
>>>>>>

The pyside bug affecting matplotlib pyside backend is now fixed
with pyside 1.0.3

I would be nice to have the pyside option in the next matplotlib release...

Regards,

David

Le 06/05/11 10:32, David Trémouilles a écrit :
> Hello,
>
> This is not directly related to your patch but I would like to
> report here that I still have at least one issue on MacOs
> that prevent matplotlib to work with your pyside backend.
> Indeed current PySide version (1.0.2) have a bug on MacOS that seems to
> have been fixed recently:
> http://bugs.pyside.org/show_bug.cgi?id=809
> But I will have to wait for next PySide release to
> confirm your pyside patch works on MacOs.
> Will test as soon as next pyside version is out and available on
> macports. I do not have time nor will to test with the latest current
> pyside head.
>
> Regards,
>
> David
>
>
>
> Le 06/05/11 03:36, Gerald Storer a écrit :
>> Hi,
>> I was wondering if I could get a comment on this. Its been 4 weeks
>> since I submitted the original version and it has been more or less
>> production ready since Monday.
>>
>> https://github.com/matplotlib/matplotlib/pull/80
>>
>> Thanks,
>> Gerald.
>>
>> On 11/04/2011 4:49 PM, Gerald Storer wrote:
>>> Hi,
>>> I've submitted a pull request with backend changes that (should) let
>>> all currently supported versions of PyQt work along side PySide. I've
>>> tested with PyQt 4.8.3 and PySide 1.0.0.
>>>
>>> I haven't bothered chasing down old versions of PyQt as they seem
>>> elusive.
>>>
>>> Gerald.
>>>
>>> On 29/03/2011 3:25 AM, bu...@gm... wrote:
>>>> Looking forward, supporting the Python 3 compatible PyQt API is
>>>> likely the way to go.
>>>>
>>>> Le , Gerald Storer<gd...@mr...> a écrit :
>>>>> On 28/03/2011 1:10 AM, Peter Butterworth wrote:
>>>>>
>>>>>
>>>>> Wouldn't it be possible to use a single backend compatible with both
>>>>>
>>>>> PyQt and Pyside ?
>>>>>
>>>>>
>>>>> The current Qt mpl backend uses the old PyQt slots/signals API
>>>> which PySide doesn't really support (there are some macros but they
>>>> don't work 100% the same). From a quick glance at the IPython
>>>> implementation it looks like they are using the new API which means
>>>> older versions (<4.5) of PyQt won't be supported. This might be ok, I
>>>> don't know.
>>>>>
>>>>> If it isn't then, there will need to be some try...excepts around
>>>> the place or separate back ends. If you ignore the PySide bugs I had
>>>> to work around I've only changed ~4 lines in the main backend.
>>>>>
>>>>>
>>>>>
>>>>> Pierre's formlayout is also using an obsolete method that isn't
>>>> present in PySide. I've opted to emulate it, but it would be best to
>>>> change the code to use the alternative method available in both PyQt
>>>> and PySide. formlayout also uses the old QString implementation of
>>>> PyQt, PySide only supports the new implementation where QString is
>>>> transparently convert to/from str/unicode. Setting QString = unicode
>>>> seems to work though.
>>>>>
>>>>>
>>>>>
>>>>> Gerald.
>>>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today. Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Fri, 27 May 2011 09:51:37 -1000, Eric Firing wrote:
[clip]
> Nice--but what exactly is the meaning of "left" and "right"?

When you write

	git checkout this-branch
	git merge other-branch

the left parent of the new merge commit is `this-branch` and
the right one is `other-branch`.

The "commits pulled" just means the commits that are in the DAG of one
parent but not in that of the other.

I just pulled the terminology out from thin air...

> Is it true that if all best practices were followed, there would 
> be no "left to right" commits pulled?  

No: if you have this situation:

    --A-------B    main branch
        \
         C----D    topic branch 

and merge the topic branch back to the main branch, you will get
merges to "both" directions, with "B" appearing left-to-right.
If you rebase first on B, then you will get only right-to-left, though.

> Is "master" always farthest left?

Not necessarily if things like this have been done:

	git checkout v1.0.x
	git merge upstream/master
	git push upstream HEAD:master

This would give the same result as

        git checkout master
	git merge upstream/v1.0.x
	git push upstream master

but with an inverted order of the parents.

If the merge command is used in the natural way, the "trunk" of the branch
tends to be on the left, and right-to-left merges show what new was merged
to it. But you can manually change this order, and this seems to have
occurred in this case.

	Pauli

On 05/27/2011 08:31 AM, Pauli Virtanen wrote:
> On Fri, 27 May 2011 07:29:15 -1000, Eric Firing wrote:
> [clip]
>> I wouldn't worry about it.  It seems likely that other things from
>> master did leak into v1.0.x, but at this point I don't think it matters.
>> v1.0.x and master both build and run (or did last time I checked).
>> The division between the two is somewhat arbitrary anyway.  Tracking
>> down and reversing the leakage, if there is any other than the _png.cpp
>> change (which certainly does no harm in v1.0.x), would not be
>> worthwhile.
>
> This probably was already clear to everybody, but you can find
> out what came in the merges:
>
> If no force-pushes have been made, and only one merge was mistaken,
> then there is a single merge commit that brings *all* of
> the mistakenly merged commits into the commit graph.
>
> 1) Locate the merge that pulled lots of stuff, e.g., with
>     http://pav.iki.fi/tmp/git-merge-pull-history
>     git merge-pull-history -l upstream/v1.0.x|less
>

Pauli,

Nice--but what exactly is the meaning of "left" and "right"?  Is it true 
that if all best practices were followed, there would be no "left to 
right" commits pulled?  Is "master" always farthest left?

Eric

On Fri, 27 May 2011 07:29:15 -1000, Eric Firing wrote:
[clip]
> I wouldn't worry about it.  It seems likely that other things from
> master did leak into v1.0.x, but at this point I don't think it matters.
> v1.0.x and master both build and run (or did last time I checked).
> The division between the two is somewhat arbitrary anyway.  Tracking
> down and reversing the leakage, if there is any other than the _png.cpp
> change (which certainly does no harm in v1.0.x), would not be
> worthwhile.

This probably was already clear to everybody, but you can find
out what came in the merges:

If no force-pushes have been made, and only one merge was mistaken,
then there is a single merge commit that brings *all* of
the mistakenly merged commits into the commit graph.

1) Locate the merge that pulled lots of stuff, e.g., with
   http://pav.iki.fi/tmp/git-merge-pull-history
   git merge-pull-history -l upstream/v1.0.x|less

   14406a68c appears to be the first one combining stuff both from
   master and v1.0.x.

   668ef6d8 is a red herring as it shows a merge from already
   contaminated v1.0.x.

2) git show 14406a68c

commit 14406a68c039dc6578730f23955bf34d34008a08
Merge: fdf5fae 132f967
...

3) 

What was pulled in from master to v1.0.x:

git log --oneline fdf5fae ^132f967
git diff 132f967 fdf5fae

On 05/27/2011 05:02 AM, Michael Droettboom wrote:
> On 05/26/2011 03:19 PM, Eric Firing wrote:
>>
>> Mike,
>>
>> I think you did--unintentionally!  If you look at the graph with qgit
>> (or presumably any other such tool) in the vicinity of your commits on
>> May 6, you will see that this one
>>
>> a50874b711983cba505ecdb2801c4996eccf3812
>>
>> made v1.0.x branch off of master; the v1.0.x line was broken by the
>> previous commit.  To confirm that this break had the effect of
>> propagating the change in _png.cpp into what is now v1.0.x, you can look
>> at the diff between two commits on "v1.0.x", one of which is a bit
>> before the break, the other after:
>>
>> git diff 069c21d 0e6dad src/_png.cpp
>>
>> You will see that the file was changed.
>>
>> Eric
>>
> I'm still not sure what happened there, and even less sure how to
> resolve it.  Does this mean we have a bunch of other things from master
> in v1.0.x as well?

Mike,

I wouldn't worry about it.  It seems likely that other things from 
master did leak into v1.0.x, but at this point I don't think it matters. 
  v1.0.x and master both build and run (or did last time I checked). 
The division between the two is somewhat arbitrary anyway.  Tracking 
down and reversing the leakage, if there is any other than the _png.cpp 
change (which certainly does no harm in v1.0.x), would not be worthwhile.

Better to just move forward, make improvements, and get some good 
releases out.

Eric

>
> Mike
>

On 05/26/2011 03:19 PM, Eric Firing wrote:
>
> Mike,
>
> I think you did--unintentionally!  If you look at the graph with qgit
> (or presumably any other such tool) in the vicinity of your commits on
> May 6, you will see that this one
>
> a50874b711983cba505ecdb2801c4996eccf3812
>
> made v1.0.x branch off of master; the v1.0.x line was broken by the
> previous commit.  To confirm that this break had the effect of
> propagating the change in _png.cpp into what is now v1.0.x, you can look
> at the diff between two commits on "v1.0.x", one of which is a bit
> before the break, the other after:
>
> git diff 069c21d 0e6dad src/_png.cpp
>
> You will see that the file was changed.
>
> Eric
>
I'm still not sure what happened there, and even less sure how to 
resolve it.  Does this mean we have a bunch of other things from master 
in v1.0.x as well?

Mike

On 05/26/2011 04:40 AM, Michael Droettboom wrote:
> On 05/25/2011 05:36 PM, Eric Firing wrote:
>> On 05/25/2011 10:53 AM, Dieter Schön wrote:
>>
>>> hi list,
>>>
>>> first, thanks for providing matplotlib, i am using it in several projects.
>>>
>>> i had problems with several png files and decided to upgrade libpng.
>>> this broke matplotlib.
>>> as you can see in the documentation of libpng15, it is no longer possible
>>> to directly access png_infop.
>>>
>>> i have created the following patch:
>>>
>> Dieter,
>>
>> Thank you, but the modification has already been made to the master
>> branch.  I did not consider this as a bug fix, so I applied it only to
>> master, not to the maintenance branch.
>>
> It seems to have been applied to the maintenance branch...  Maybe
> someone backported it?

Mike,

I think you did--unintentionally!  If you look at the graph with qgit 
(or presumably any other such tool) in the vicinity of your commits on 
May 6, you will see that this one

a50874b711983cba505ecdb2801c4996eccf3812

made v1.0.x branch off of master; the v1.0.x line was broken by the 
previous commit.  To confirm that this break had the effect of 
propagating the change in _png.cpp into what is now v1.0.x, you can look 
at the diff between two commits on "v1.0.x", one of which is a bit 
before the break, the other after:

git diff 069c21d 0e6dad src/_png.cpp

You will see that the file was changed.

Eric



>
> https://github.com/matplotlib/matplotlib/blob/v1.0.x/src/_png.cpp
>
> Mike

On 05/25/2011 05:36 PM, Eric Firing wrote:
> On 05/25/2011 10:53 AM, Dieter Schön wrote:
>    
>> hi list,
>>
>> first, thanks for providing matplotlib, i am using it in several projects.
>>
>> i had problems with several png files and decided to upgrade libpng.
>> this broke matplotlib.
>> as you can see in the documentation of libpng15, it is no longer possible
>> to directly access png_infop.
>>
>> i have created the following patch:
>>      
> Dieter,
>
> Thank you, but the modification has already been made to the master
> branch.  I did not consider this as a bug fix, so I applied it only to
> master, not to the maintenance branch.
>    
It seems to have been applied to the maintenance branch...  Maybe 
someone backported it?

https://github.com/matplotlib/matplotlib/blob/v1.0.x/src/_png.cpp

Mike

> Eric
>
>    
>> --- matplotlib-1.0.1/src/_png.cpp	2010-10-12 16:14:42.000000000 +0000
>> +++ matplotlib-1.0.1X/src/_png.cpp	2011-05-25 19:23:36.261752651 +0000
>> @@ -350,18 +350,21 @@
>>        png_set_sig_bytes(png_ptr, 8);
>>        png_read_info(png_ptr, info_ptr);
>>
>> -    png_uint_32 width = info_ptr->width;
>> -    png_uint_32 height = info_ptr->height;
>> +    png_uint_32 width = png_get_image_width(png_ptr, info_ptr);
>> +    png_uint_32 height = png_get_image_height(png_ptr, info_ptr);
>>
>> -    int bit_depth = info_ptr->bit_depth;
>> +    int bit_depth = png_get_bit_depth(png_ptr, info_ptr);
>>
>>        // Unpack 1, 2, and 4-bit images
>>        if (bit_depth<   8)
>>            png_set_packing(png_ptr);
>>
>> +    // this is needed several times, so safe it in a variable
>> +    png_byte color_type = png_get_color_type(png_ptr, info_ptr);
>> +
>>        // If sig bits are set, shift data
>>        png_color_8p sig_bit;
>> -    if ((info_ptr->color_type != PNG_COLOR_TYPE_PALETTE)&&
>> +    if ((color_type != PNG_COLOR_TYPE_PALETTE)&&
>>            png_get_sBIT(png_ptr, info_ptr,&sig_bit))
>>        {
>>            png_set_shift(png_ptr, sig_bit);
>> @@ -374,13 +377,13 @@
>>        }
>>
>>        // Convert palletes to full RGB
>> -    if (info_ptr->color_type == PNG_COLOR_TYPE_PALETTE)
>> +    if (color_type == PNG_COLOR_TYPE_PALETTE)
>>        {
>>            png_set_palette_to_rgb(png_ptr);
>>        }
>>
>>        // If there's an alpha channel convert gray to RGB
>> -    if (info_ptr->color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
>> +    if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
>>        {
>>            png_set_gray_to_rgb(png_ptr);
>>        }
>> @@ -408,11 +411,11 @@
>>        npy_intp dimensions[3];
>>        dimensions[0] = height;  //numrows
>>        dimensions[1] = width;   //numcols
>> -    if (info_ptr->color_type&   PNG_COLOR_MASK_ALPHA)
>> +    if (color_type&   PNG_COLOR_MASK_ALPHA)
>>        {
>>            dimensions[2] = 4;     //RGBA images
>>        }
>> -    else if (info_ptr->color_type&   PNG_COLOR_MASK_COLOR)
>> +    else if (color_type&   PNG_COLOR_MASK_COLOR)
>>        {
>>            dimensions[2] = 3;     //RGB images
>>        }
>> @@ -421,7 +424,7 @@
>>            dimensions[2] = 1;     //Greyscale images
>>        }
>>        //For gray, return an x by y array, not an x by y by 1
>> -    int num_dims  = (info_ptr->color_type&   PNG_COLOR_MASK_COLOR) ? 3 : 2;
>> +    int num_dims  = (color_type&   PNG_COLOR_MASK_COLOR) ? 3 : 2;
>>
>>        double max_value = (1<<   ((bit_depth<   8) ? 8 : bit_depth)) - 1;
>>        PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNew(
>>
>>
>> kind regards,
>> dieter
>>
>> ------------------------------------------------------------------------------
>> vRanger cuts backup time in half-while increasing security.
>> With the market-leading solution for virtual backup and recovery,
>> you get blazing-fast, flexible, and affordable data protection.
>> Download your free trial now.
>> http://p.sf.net/sfu/quest-d2dcopy1
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>      
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 05/25/2011 10:53 AM, Dieter Schön wrote:
> hi list,
>
> first, thanks for providing matplotlib, i am using it in several projects.
>
> i had problems with several png files and decided to upgrade libpng.
> this broke matplotlib.
> as you can see in the documentation of libpng15, it is no longer possible
> to directly access png_infop.
>
> i have created the following patch:

Dieter,

Thank you, but the modification has already been made to the master 
branch.  I did not consider this as a bug fix, so I applied it only to 
master, not to the maintenance branch.

Eric

>
> --- matplotlib-1.0.1/src/_png.cpp	2010-10-12 16:14:42.000000000 +0000
> +++ matplotlib-1.0.1X/src/_png.cpp	2011-05-25 19:23:36.261752651 +0000
> @@ -350,18 +350,21 @@
>       png_set_sig_bytes(png_ptr, 8);
>       png_read_info(png_ptr, info_ptr);
>
> -    png_uint_32 width = info_ptr->width;
> -    png_uint_32 height = info_ptr->height;
> +    png_uint_32 width = png_get_image_width(png_ptr, info_ptr);
> +    png_uint_32 height = png_get_image_height(png_ptr, info_ptr);
>
> -    int bit_depth = info_ptr->bit_depth;
> +    int bit_depth = png_get_bit_depth(png_ptr, info_ptr);
>
>       // Unpack 1, 2, and 4-bit images
>       if (bit_depth<  8)
>           png_set_packing(png_ptr);
>
> +    // this is needed several times, so safe it in a variable
> +    png_byte color_type = png_get_color_type(png_ptr, info_ptr);
> +
>       // If sig bits are set, shift data
>       png_color_8p sig_bit;
> -    if ((info_ptr->color_type != PNG_COLOR_TYPE_PALETTE)&&
> +    if ((color_type != PNG_COLOR_TYPE_PALETTE)&&
>           png_get_sBIT(png_ptr, info_ptr,&sig_bit))
>       {
>           png_set_shift(png_ptr, sig_bit);
> @@ -374,13 +377,13 @@
>       }
>
>       // Convert palletes to full RGB
> -    if (info_ptr->color_type == PNG_COLOR_TYPE_PALETTE)
> +    if (color_type == PNG_COLOR_TYPE_PALETTE)
>       {
>           png_set_palette_to_rgb(png_ptr);
>       }
>
>       // If there's an alpha channel convert gray to RGB
> -    if (info_ptr->color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
> +    if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
>       {
>           png_set_gray_to_rgb(png_ptr);
>       }
> @@ -408,11 +411,11 @@
>       npy_intp dimensions[3];
>       dimensions[0] = height;  //numrows
>       dimensions[1] = width;   //numcols
> -    if (info_ptr->color_type&  PNG_COLOR_MASK_ALPHA)
> +    if (color_type&  PNG_COLOR_MASK_ALPHA)
>       {
>           dimensions[2] = 4;     //RGBA images
>       }
> -    else if (info_ptr->color_type&  PNG_COLOR_MASK_COLOR)
> +    else if (color_type&  PNG_COLOR_MASK_COLOR)
>       {
>           dimensions[2] = 3;     //RGB images
>       }
> @@ -421,7 +424,7 @@
>           dimensions[2] = 1;     //Greyscale images
>       }
>       //For gray, return an x by y array, not an x by y by 1
> -    int num_dims  = (info_ptr->color_type&  PNG_COLOR_MASK_COLOR) ? 3 : 2;
> +    int num_dims  = (color_type&  PNG_COLOR_MASK_COLOR) ? 3 : 2;
>
>       double max_value = (1<<  ((bit_depth<  8) ? 8 : bit_depth)) - 1;
>       PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNew(
>
>
> kind regards,
> dieter
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

hi list,

first, thanks for providing matplotlib, i am using it in several projects.

i had problems with several png files and decided to upgrade libpng.
as you can see in the documentation of libpng, 
direct access to png_infop is no longer possible.

i have created the following patch:


--- matplotlib-1.0.1/src/_png.cpp	2010-10-12 16:14:42.000000000 +0000
+++ matplotlib-1.0.1X/src/_png.cpp	2011-05-25 19:23:36.261752651 +0000
@@ -350,18 +350,21 @@
     png_set_sig_bytes(png_ptr, 8);
     png_read_info(png_ptr, info_ptr);
 
-    png_uint_32 width = info_ptr->width;
-    png_uint_32 height = info_ptr->height;
+    png_uint_32 width = png_get_image_width(png_ptr, info_ptr);
+    png_uint_32 height = png_get_image_height(png_ptr, info_ptr);
 
-    int bit_depth = info_ptr->bit_depth;
+    int bit_depth = png_get_bit_depth(png_ptr, info_ptr);
 
     // Unpack 1, 2, and 4-bit images
     if (bit_depth < 8)
         png_set_packing(png_ptr);
 
+    // this is needed several times, so safe it in a variable
+    png_byte color_type = png_get_color_type(png_ptr, info_ptr);
+
     // If sig bits are set, shift data
     png_color_8p sig_bit;
-    if ((info_ptr->color_type != PNG_COLOR_TYPE_PALETTE) &&
+    if ((color_type != PNG_COLOR_TYPE_PALETTE) &&
         png_get_sBIT(png_ptr, info_ptr, &sig_bit))
     {
         png_set_shift(png_ptr, sig_bit);
@@ -374,13 +377,13 @@
     }
 
     // Convert palletes to full RGB
-    if (info_ptr->color_type == PNG_COLOR_TYPE_PALETTE)
+    if (color_type == PNG_COLOR_TYPE_PALETTE)
     {
         png_set_palette_to_rgb(png_ptr);
     }
 
     // If there's an alpha channel convert gray to RGB
-    if (info_ptr->color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
+    if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
     {
         png_set_gray_to_rgb(png_ptr);
     }
@@ -408,11 +411,11 @@
     npy_intp dimensions[3];
     dimensions[0] = height;  //numrows
     dimensions[1] = width;   //numcols
-    if (info_ptr->color_type & PNG_COLOR_MASK_ALPHA)
+    if (color_type & PNG_COLOR_MASK_ALPHA)
     {
         dimensions[2] = 4;     //RGBA images
     }
-    else if (info_ptr->color_type & PNG_COLOR_MASK_COLOR)
+    else if (color_type & PNG_COLOR_MASK_COLOR)
     {
         dimensions[2] = 3;     //RGB images
     }
@@ -421,7 +424,7 @@
         dimensions[2] = 1;     //Greyscale images
     }
     //For gray, return an x by y array, not an x by y by 1
-    int num_dims  = (info_ptr->color_type & PNG_COLOR_MASK_COLOR) ? 3 : 2;
+    int num_dims  = (color_type & PNG_COLOR_MASK_COLOR) ? 3 : 2;
 
     double max_value = (1 << ((bit_depth < 8) ? 8 : bit_depth)) - 1;
     PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNew(

kind regards,
dieter

hi list,

first, thanks for providing matplotlib, i am using it in several projects.

i had problems with several png files and decided to upgrade libpng.
this broke matplotlib.
as you can see in the documentation of libpng15, it is no longer possible
to directly access png_infop.

i have created the following patch:

--- matplotlib-1.0.1/src/_png.cpp	2010-10-12 16:14:42.000000000 +0000
+++ matplotlib-1.0.1X/src/_png.cpp	2011-05-25 19:23:36.261752651 +0000
@@ -350,18 +350,21 @@
     png_set_sig_bytes(png_ptr, 8);
     png_read_info(png_ptr, info_ptr);

-    png_uint_32 width = info_ptr->width;
-    png_uint_32 height = info_ptr->height;
+    png_uint_32 width = png_get_image_width(png_ptr, info_ptr);
+    png_uint_32 height = png_get_image_height(png_ptr, info_ptr);

-    int bit_depth = info_ptr->bit_depth;
+    int bit_depth = png_get_bit_depth(png_ptr, info_ptr);

     // Unpack 1, 2, and 4-bit images
     if (bit_depth < 8)
         png_set_packing(png_ptr);

+    // this is needed several times, so safe it in a variable
+    png_byte color_type = png_get_color_type(png_ptr, info_ptr);
+
     // If sig bits are set, shift data
     png_color_8p sig_bit;
-    if ((info_ptr->color_type != PNG_COLOR_TYPE_PALETTE) &&
+    if ((color_type != PNG_COLOR_TYPE_PALETTE) &&
         png_get_sBIT(png_ptr, info_ptr, &sig_bit))
     {
         png_set_shift(png_ptr, sig_bit);
@@ -374,13 +377,13 @@
     }

     // Convert palletes to full RGB
-    if (info_ptr->color_type == PNG_COLOR_TYPE_PALETTE)
+    if (color_type == PNG_COLOR_TYPE_PALETTE)
     {
         png_set_palette_to_rgb(png_ptr);
     }

     // If there's an alpha channel convert gray to RGB
-    if (info_ptr->color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
+    if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
     {
         png_set_gray_to_rgb(png_ptr);
     }
@@ -408,11 +411,11 @@
     npy_intp dimensions[3];
     dimensions[0] = height;  //numrows
     dimensions[1] = width;   //numcols
-    if (info_ptr->color_type & PNG_COLOR_MASK_ALPHA)
+    if (color_type & PNG_COLOR_MASK_ALPHA)
     {
         dimensions[2] = 4;     //RGBA images
     }
-    else if (info_ptr->color_type & PNG_COLOR_MASK_COLOR)
+    else if (color_type & PNG_COLOR_MASK_COLOR)
     {
         dimensions[2] = 3;     //RGB images
     }
@@ -421,7 +424,7 @@
         dimensions[2] = 1;     //Greyscale images
     }
     //For gray, return an x by y array, not an x by y by 1
-    int num_dims  = (info_ptr->color_type & PNG_COLOR_MASK_COLOR) ? 3 : 2;
+    int num_dims  = (color_type & PNG_COLOR_MASK_COLOR) ? 3 : 2;

     double max_value = (1 << ((bit_depth < 8) ? 8 : bit_depth)) - 1;
     PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNew(


kind regards,
dieter

Dear list,

I am trying to work with matplotlib to plot on an AGG canvas of size
50000x1100.

It seems to be the constraint is in AGG. Does anybody has experience
in this regard?


After removing the exception about the image size and replacing 'int'
with long long, figimage correctly puts an image and save to a rgba
raw file.

There are, however, two problems that I can't solve.

1 when the border rectangle(0,0) - (50000, 0) - (50000, 1100) - (0,
1100) - (0,0) is rendered, I see the scanlines all end up with a
length of 16636(which happens to be 65536 - 50000). and nothing is
evidently drawn in the final image.

2  when I try to plot a circle at (40000, 0). Nothing is shown and no
scanline is produced at all.

In both situation the vertices are correctly passed to the rasterizer.
Is there a version of Agg that can do with larger images?


Yu



Yu

Hi,

I have a problem. I need to find specific date in datetime.datetime vector.
Fox example, I've created a vector of dates and I want to find the positions
with february month. In Matlab the code is:

date1 = datenum([1981 1 1 0 0 0]); %date start
date2 = datenum([2010 12 31 0 0 0]); %date end
delta = datenum([2010 1 1 6 0 0]) - datenum([2010 1 1 0 0 0]); %interval -
6h
dates = date1:delta:date2; %creating vector of dates
dates = datevec(dates); %converting date to matrix
my_positions = find(dates(:,2)==2); %searching the positions with month=2
(february)

How is in numpy? How I search a specific date? The beginning of code is:

import datetime

date1 =datetime.datetime( 1981, 1, 1, 0, 0, 0); #date start
date2 = datetime.datetime( 2010, 12, 31, 0, 0, 0); #date end
delta = datetime.timedelta(hours=6); #interval - 6h
dates = drange(date1, date2, delta); #creating vector of dates

Thank's and best regards.

Helvio P. Gregório

On Mon, May 23, 2011 at 12:11 PM, Ben Gamari <bga...@gm...> wrote:

> On Mon, 23 May 2011 09:35:57 -0400, Michael Droettboom <md...@st...>
> wrote:
> > Generating the thumbnails has no additional requirements (it uses
> > matplotlib's image module to scale the images).  However, it may be a
> > problem with multiprocessing -- the thumbnails are generated in parallel
> > on multi-core machines.  I haven't had problems myself, but it seems
> > multiprocessing doesn't always work in certain environments.
> >
> > Can you do me a favor?  Can you edit gen_gallery.py and replace the line
> > beginning with "pool.map" to just "map" and let me know if that resolves
> > this issue?  If it does, perhaps we should not use multiprocessing here.
> >
> Given this seems to be one of the longer stages of the build process,
> I'd appreciate if if we identified and fixed the underlying problem and
> not simply sweep it under the rug.
>
> - Ben
>
>
Don't have a lot of time because I am on travel right now, but I think I
figured out the cause.  For whatever reason, there was some sort of missing
file error that caused the generation of the thumbnails to drop down to the
debugger prompt.  When within the multiprocessing pool, everything just
pauses, but nothing shows because the input is disconnected.  After a call
to clean, I was able to run the docs with and without "pool".

I hope that is a useful tip that could help figure out how to prevent a
unresponsive process.

Ben Root

On Mon, 23 May 2011 09:35:57 -0400, Michael Droettboom <md...@st...> wrote:
> Generating the thumbnails has no additional requirements (it uses 
> matplotlib's image module to scale the images).  However, it may be a 
> problem with multiprocessing -- the thumbnails are generated in parallel 
> on multi-core machines.  I haven't had problems myself, but it seems 
> multiprocessing doesn't always work in certain environments.
> 
> Can you do me a favor?  Can you edit gen_gallery.py and replace the line 
> beginning with "pool.map" to just "map" and let me know if that resolves 
> this issue?  If it does, perhaps we should not use multiprocessing here.
> 
Given this seems to be one of the longer stages of the build process,
I'd appreciate if if we identified and fixed the underlying problem and
not simply sweep it under the rug.

- Ben

On 05/22/2011 05:33 PM, Benjamin Root wrote:
>
>
> On Sun, May 22, 2011 at 4:11 PM, Eric Firing <ef...@ha... 
> <mailto: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?
Generating the thumbnails has no additional requirements (it uses 
matplotlib's image module to scale the images).  However, it may be a 
problem with multiprocessing -- the thumbnails are generated in parallel 
on multi-core machines.  I haven't had problems myself, but it seems 
multiprocessing doesn't always work in certain environments.

Can you do me a favor?  Can you edit gen_gallery.py and replace the line 
beginning with "pool.map" to just "map" and let me know if that resolves 
this issue?  If it does, perhaps we should not use multiprocessing here.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 05/22/2011 11:33 AM, Benjamin Root wrote:
>
>
> On Sun, May 22, 2011 at 4:11 PM, Eric Firing <ef...@ha...
> <mailto: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.

Right.  It looks like INSTALL is a slightly fixed-up version of the 
now-deleted install.rst.  I was referring to install_faq.rst.  Maybe 
that (or large parts of it) should go away, and be replaced by a 
reference to INSTALL?

Eric

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