matplotlib-devel Mailing List for matplotlib

On Tue, Apr 12, 2011 at 4:13 PM, John Hunter <jd...@gm...> wrote:
> Yes, I'll get thus fixed ASAP

John,  quick note: our local network is down (firewall transfer went
awry), so if you need to rebuild the docs, you'll need to do it on
another system than my box (I'm using a laptop over wireless to send
this).

Cheers,

f

On Apr 12, 2011, at 6:03 PM, Ian Bell <ib...@pu...> wrote:

> Fernando, 
> 
> Perfect!  Thanks for the information.  Perhaps this can get updated on the web somehow?

Yes, I'll get thus fixed ASAP


> 
> Ian
> 
> ----
> Ian Bell
> Graduate Research Assistant
> Herrick Labs
> Purdue University
> email: ib...@pu...
> cell: (607)227-7626
> 
> 
> On Tue, Apr 12, 2011 at 6:28 PM, Fernando Perez <fpe...@gm...> wrote:
> Hi Ian,
> 
> On Tue, Apr 12, 2011 at 3:03 PM, Ian Bell <ib...@pu...> wrote:
> > Where is the bleeding edge MPL source located?  It doesn't seem to be
> > subversion,
> > http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/
> > stuck at revision 8988  or https://github.com/astraw/matplotlib, which is
> > also from november of last year.  If the bleeding-edge code is somewhere
> > else, would it be possible to update the MPL website to reflect this?
> 
> sorry for the doc confusion, the new official repo (for all mpl
> development) lives at:
> 
> https://github.com/matplotlib/matplotlib
> 
> Cheers,
> 
> f
> 
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Fernando,

Perfect!  Thanks for the information.  Perhaps this can get updated on the
web somehow?

Ian

----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626


On Tue, Apr 12, 2011 at 6:28 PM, Fernando Perez <fpe...@gm...>wrote:

> Hi Ian,
>
> On Tue, Apr 12, 2011 at 3:03 PM, Ian Bell <ib...@pu...> wrote:
> > Where is the bleeding edge MPL source located?  It doesn't seem to be
> > subversion,
> >
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/
> > stuck at revision 8988  or https://github.com/astraw/matplotlib, which
> is
> > also from november of last year.  If the bleeding-edge code is somewhere
> > else, would it be possible to update the MPL website to reflect this?
>
> sorry for the doc confusion, the new official repo (for all mpl
> development) lives at:
>
> https://github.com/matplotlib/matplotlib
>
> Cheers,
>
> f
>

Hi Ian,

On Tue, Apr 12, 2011 at 3:03 PM, Ian Bell <ib...@pu...> wrote:
> Where is the bleeding edge MPL source located?  It doesn't seem to be
> subversion,
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/
> stuck at revision 8988  or https://github.com/astraw/matplotlib, which is
> also from november of last year.  If the bleeding-edge code is somewhere
> else, would it be possible to update the MPL website to reflect this?

sorry for the doc confusion, the new official repo (for all mpl
development) lives at:

https://github.com/matplotlib/matplotlib

Cheers,

f

Where is the bleeding edge MPL source located?  It doesn't seem to be
subversion,
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/stuck
at revision 8988  or
https://github.com/astraw/matplotlib, which is also from november of last
year.  If the bleeding-edge code is somewhere else, would it be possible to
update the MPL website to reflect this?

Regards,
Ian


----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626

On Tue, Apr 12, 2011 at 8:55 AM, Darren Dale <dsd...@gm...> wrote:
> That looks right to me. I find it easier to keep a local copy of
> integration branches like v1.0.x and master

BTW, I do that for my old stable branches: in addition to my main
ipython repo directory, I keep a branches/ dir with static copies of
those:

/home/fperez/ipython/branches
total 8
drwxr-xr-x 10 fperez 4096 2010-10-25 13:13 0.10.1/
drwxr-xr-x 12 fperez 4096 2011-04-09 00:42 0.10.2/

which I manage with the very useful git new-workdir tool:

http://kohei.us/2010/11/16/working-with-a-branch-using-git-new-workdir/

Cheers,

f

On Mon, Apr 11, 2011 at 2:19 PM, Darren Dale <dsd...@gm...> wrote:
>
> Brilliant, whatever they use allows uploading attachments.

I know this isn't ideal, but a workaround for screenshots/images in
mpl bug reports would be to upload them to something like imgur (free
- no registration required):

http://imgur.com/tools/

and then put the image link in the markdown for the bug report:

https://github.com/blog/831-issues-2-0-the-next-generation#comment-11405


I realize it's a workaround, but better than nothing...

f

On Tue, Apr 12, 2011 at 9:38 AM, Michael Droettboom <md...@st...> wrote:
> Ok.  I hope I fixed it.  Here's what I did (from my clone of the
> matplotlib/matplotlib repository)
>
>  > git branch v1.0.x e5970f4
>  > git push origin v1.0.x
>
> Looking at the commit history and contents at the tip of this branch,
> everything looks ok.  Someone want to verify for me?

That looks right to me. I find it easier to keep a local copy of
integration branches like v1.0.x and master, so I had a slightly out
of date local v1.0.x from April 2, and it compares well with what you
just pushed. I was just missing the gitwash clarifications, my
lingering print statement and the fixed agg link. Thank you for fixing
it.

Any chance you did a "git push upstream :v1.0.x"? That is how a branch
gets deleted.

Darren

Ok.  I hope I fixed it.  Here's what I did (from my clone of the 
matplotlib/matplotlib repository)

 > git branch v1.0.x e5970f4
 > git push origin v1.0.x

Looking at the commit history and contents at the tip of this branch, 
everything looks ok.  Someone want to verify for me?

Mike

On 04/12/2011 09:29 AM, Michael Droettboom wrote:
> Looking at the network, this seems to be the last commit on the 1.0.x
> branch:
>
> https://github.com/matplotlib/matplotlib/commit/e5970f4fa6589089ce60dad955831c7632606ead
>
> This seems to be where I somehow killed the 1.0.x branch by doing what I
> thought was a regular merge into master:
>
> https://github.com/matplotlib/matplotlib/commit/0d81e6774388b7bf2150f91f95fa83db6ad7bfc4
>
> So, I suppose we need to make a branch that points to e5970f?  I'm not
> going to experiment with this stuff -- any thoughts on how to correct it?
>
> Mike
>
> On 04/12/2011 09:55 AM, Darren Dale wrote:
>    
>> On Tue, Apr 12, 2011 at 9:47 AM, Jae-Joon Lee<lee...@gm...>   wrote:
>>
>>      
>>> Hi all,
>>>
>>> I thought we have a "v1.0.x" branch on the github repo, but no more.
>>>
>>> https://github.com/matplotlib/matplotlib/branches
>>>
>>> Hmm...
>>> Is it (accidentally?) removed or do we now use another branch for
>>> maintenance (although I don't see any alternative)?
>>>
>>>        
>> Mike, you may be the most likely to have the latest changes in a local
>> branch. Would you please push it?
>>
>> ------------------------------------------------------------------------------
>> Forrester Wave Report - Recovery time is now measured in hours and minutes
>> not days. Key insights are discussed in the 2010 Forrester Wave Report as
>> part of an in-depth evaluation of disaster recovery service providers.
>> Forrester found the best-in-class provider in terms of services and vision.
>> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
>> _______________________________________________
>> 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 04/12/2011 08:34 AM, Tobias Hoppe wrote:
> I've read the status page for py3k and stumbled upon the cleanup tasks,
> especially the version checks. I agree that calling sys.version_info[0] is not a
> smart choice.
>
> Why not use a new variable in __init__.py, something like a boolean __is_py3k__.
> Every module which needs a choice between py2.x and 3.x can simply:
>
> from matplotlib import __is_py3k__
>
> and use:
>
> if __is_py3k__:
>
>    
It can't live in __init__.py without creating cyclical imports.  
(__init__.py includes most everything else).  I think the solution, 
though not ideal either, is to create a new module called "compat" or 
some such that contains this and possibly other python2/python3 
compatibility code.

Cheers,
Mike

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

Looking at the network, this seems to be the last commit on the 1.0.x 
branch:

https://github.com/matplotlib/matplotlib/commit/e5970f4fa6589089ce60dad955831c7632606ead

This seems to be where I somehow killed the 1.0.x branch by doing what I 
thought was a regular merge into master:

https://github.com/matplotlib/matplotlib/commit/0d81e6774388b7bf2150f91f95fa83db6ad7bfc4

So, I suppose we need to make a branch that points to e5970f?  I'm not 
going to experiment with this stuff -- any thoughts on how to correct it?

Mike

On 04/12/2011 09:55 AM, Darren Dale wrote:
> On Tue, Apr 12, 2011 at 9:47 AM, Jae-Joon Lee<lee...@gm...>  wrote:
>    
>> Hi all,
>>
>> I thought we have a "v1.0.x" branch on the github repo, but no more.
>>
>> https://github.com/matplotlib/matplotlib/branches
>>
>> Hmm...
>> Is it (accidentally?) removed or do we now use another branch for
>> maintenance (although I don't see any alternative)?
>>      
> Mike, you may be the most likely to have the latest changes in a local
> branch. Would you please push it?
>
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
> _______________________________________________
> 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 Tue, Apr 12, 2011 at 9:47 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi all,
>
> I thought we have a "v1.0.x" branch on the github repo, but no more.
>
> https://github.com/matplotlib/matplotlib/branches
>
> Hmm...
> Is it (accidentally?) removed or do we now use another branch for
> maintenance (although I don't see any alternative)?

Mike, you may be the most likely to have the latest changes in a local
branch. Would you please push it?

Hi all,

I thought we have a "v1.0.x" branch on the github repo, but no more.

https://github.com/matplotlib/matplotlib/branches

Hmm...
Is it (accidentally?) removed or do we now use another branch for
maintenance (although I don't see any alternative)?

Regards,

-JJ

I've read the status page for py3k and stumbled upon the cleanup tasks, 
especially the version checks. I agree that calling sys.version_info[0] is not a 
smart choice.

Why not use a new variable in __init__.py, something like a boolean __is_py3k__. 
Every module which needs a choice between py2.x and 3.x can simply:

from matplotlib import __is_py3k__

and use:

if __is_py3k__:

Greetz, Tobi