[matplotlib-devel] Question about (local) developement workflow

[Maximilian Trescher]

Hi,

i have a question about my personal developement workflow. I wanted to
fix a bug in matplotlib, therefore i checked out the repository.

Then i have to "install" matplotlib (with setupy.py build, setup.py
install). But every time i chenged something, i have to reinstall mpl to
test my changes.

I could make my changes directly in site-packages/matplotlib, but then
it's not version-controlled and the changes must be transferred back.

This workflow seems to be suboptimal, do i miss something?

Thanks,
Maximilian



signature.asc
Description: OpenPGP digital signature
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] github devel question

[Jouni K . Seppänen]

Benjamin Root  writes:

> I am having difficulty completing a pull request that I opened.  When I try
> to merge the changes to upstream, they get rejected.  I can merge it back to
> my own master, and can even push it up to my github repo's master, but not
> matplotlib's master.

If you're following the merge instructions at
 and getting the merge rejected,
that's likely because your master branch is not up to date. The
instructions start with "git checkout master", but that assumes your
master is the same as matplotlib's master. If that is not the case, you
should first pull from matplotlib into your master - something like

git remote add upstream g...@github.com:matplotlib/matplotlib.git
git checkout master
git pull --ff-only upstream master

The "remote add" is necessary only once, and it gives the name
"upstream" to the matplotlib central repository (and you have probably
already done it already if you're trying to push into the repository).
Then you checkout your master branch and pull into it from upstream. The
--ff-only flag makes sure that you get an error if you have accidentally
left something on your master that is not in upstream, possibly from
your earlier merge attempts. If you do get that error, the way to clear
it is

git reset --hard upstream/master

but beware that it discards any local changes (so always commit your own
changes on feature branches, not master). (If your changes are
something that you want to save, put them on a new branch first with
"git checkout -b important-local-changes; git commit -a", and then
checkout master again and reset it to upstream/master.)

Then, once your master is up to date, you can merge the pull request and
push to upstream.

> I have tried rebasing my
> branches, but that doesn't seem to solve the problem.

Rebasing branches that you have already pushed somewhere is to be
avoided - if you rebase your feature branch, I don't think e.g. github
will know that the pull request got merged.

> I am thoroughly confused.  Anybody has ideas?  Should I dump my repos and
> start fresh?

No, absolutely not. This is likely just a matter of merging into an
up-to-date master branch.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Michael Droettboom]

On 02/26/2011 02:37 AM, Eric Firing wrote:
> On 02/25/2011 04:54 PM, Benjamin Root wrote:
>>
>> On Fri, Feb 25, 2011 at 8:01 PM, John Hunter> >  wrote:
>>
>>
>>
>>
>>
>>  On Feb 25, 2011, at 7:00 PM, Christoph Gohlke>  >  wrote:
>>
>>   >  Are PIL and PyGTK holding back matplotlib for Python 3
>>
>>  Not at all. Both are optional dependencies. Mpl's hard external
>>  dependencies are python, zlib, libpng, freetype and numpy.  With
>>  those you get the agg, pdf, ps and svg backends.   Various GUI
>>  tooolkits are optional, as is PIL, which provides some image reading
>>  capabilities and image comparisons for the unit tests.
>>
>>
>> While the GUI toolkits are optional, practically speaking, they are a
>> requirement for many (if not most) users.
>>
>> The damn-ing part about the backends is that many users use only one of
>> the GUI backends, and if that one is broken for them, they believe that
>> matplotlib is completely broken.  (Evidence: the user who complained
>> that matplotlib was not designed correctly when it turned out that the
>> macosx backend didn't support (non-?)interactive mode).
>>
>> PyGTK not being updated for py3k is a heart-breaker for me.  I don't
>> want to even imagine what sort of pain in the butt it is going to be to
>> program using PyGObject introspection (yeah, that sounds like fun...).
> It's not clear to me how bad it will be to handle this in the mpl
> backend.  This page
> (http://live.gnome.org/PyGObject/IntrospectionPorting) suggests it might
> be quite easy, and might not require extensive code change.  I think the
> idea is not so much that the bindings offer a different API but that
> their implementation is different, they are imported differently, and
> the constants are different.  Unfortunately, the python-gobject package
> on Ubuntu 10.10 seems to be broken; the example that comes with it won't
> run.
>
That's right -- the changes should be minimal.  The GObject 
introspection version is not meant to require the user to perform manual 
object introspection.  The difference is that rather than generating 
bindings at compile-time (like the old pygtk), the method lookup and 
resolution happens at run-time (much like Python objects already work).  
The advantage is there is less of a compilation dependency between the 
version of pygtk and gtk+, and it should be much easier to get Python 
access to any library based on GObject.
> In any case it appears that with the exception of Tkinter, it may take a
> long time before interactive mpl backends can be used with py3k.
The Qt4Agg backend is also working (with the exception of the Qt form 
layout stuff) under Python 3.x.

But gtk and cairo will have to wait until the bindings settle down, fltk 
and Qt 3.x can probably be safely deprecated, and wxPython seems to be 
in Python 3.x limbo.

Mike
> Eric
>
>> Ben Root
>>
> --
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Michiel de Hoon]

> In any case it appears that with the exception of Tkinter, it may take a 
> long time before interactive mpl backends can be used with py3k.

The MacOSX backend has already been ported to Py3k (at least the C part of it, 
which is the largest and most difficult part of it), though I won't be able to 
test it until the rest of matplotlib has been ported.

> The damn-ing part about the backends is that many users use only one of
> the GUI backends, and if that one is broken for them, they believe that
> matplotlib is completely broken.  (Evidence: the user who complained
> that matplotlib was not designed correctly when it turned out that the
> macosx backend didn't support (non-?)interactive mode).

Sometimes I wonder if it is better to retire the MacOSX backend. When it was 
first introduced, it was much faster (depending on what you wanted to draw) 
because of how its event loop is organized. By now the other backends use the 
same event loop strategy, and as far as I know there is no significant 
difference in speed compared to e.g. the TkAgg backend. The remaining advantage 
of the MacOSX backend is that it does not rely on other toolkits, and therefore 
it is easier to compile and use if something changes (e.g., when a new version 
of OS X comes out, or when compiling for 64-bits, or when Py3K comes out). 
Still, it needs some maintenance work, and it is hard to keep up.
Opinions, anybody?

--Michiel.




  

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Michael Droettboom]

On 02/25/2011 08:00 PM, Christoph Gohlke wrote:
>
> On 2/25/2011 4:03 PM, Benjamin Root wrote:
>>
>> On Fri, Feb 25, 2011 at 5:11 PM, Paul Ivanov> >  wrote:
>>
>>  Fernando Garcia Bermudez, on 2011-02-03 09:14,  wrote:
>>  >   On Thu, Feb 3, 2011 at 06:05, Michael Droettboom>  >  wrote:
>>  >   >  On 02/03/2011 07:48 AM, Darren Dale wrote:
>>  >   >>  On Thu, Feb 3, 2011 at 12:12 AM, Fernando Garcia Bermudez
>>  >   >>  mailto:mov...@gmail.com>>   wrote:
>>  >   >>
>>  >   >>>  Before continuing the debug process, though, I wanted to check
>>  with
>>  >   >>>  someone knowledgeable of this branch regarding its current
>>  status. Is
>>  >   >>>  it possible to compile matplotlib on python3?
>>  >   >>>
>>  >   >>  Mike D. did some initial work for py3 support a while back. I 
>> don't
>>  >   >>  know what platform he was working on, but he was able to 
>> produce a
>>  >   >>  simple plot, maybe running the simple_plot demo.
>>  >   >>
>>  >   >  I was working on Linux (RHEL5), and never got past that platform.
>>  >
>>  >   I'll stay on the lookout for the github py3k branch and will do as
>>  >   suggested. Thanks for the update.
>>  >
>>
>>  By the way, there was a recent poll on python.org
>>    for packages
>>  where users desire Python 3 support.
>>
>>  Here are the top 10:
>>
>>  Votes | Package
>>  --+
>>837  | Django
>>454  | wxPython
>>406  | scipy
>>364  | matplotlib
>>327  | PIL
>>266  | py2exe
>>185  | Twisted
>>179  | PyGTK
>>135  | Pygame
>>94  | web2py
>>
>>  http://python.org/3kpoll
>>
>>  best,
>>  --
>>  Paul Ivanov
>>  314 address only used for lists,  off-list direct email at:
>>  http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>>
>>
>>
>> Which just goes to show that some people don't understand
>> dependencies... (PIL and PyGTK are needed by matplotllib to be fully
>> py3k compatible).  Hopefully this will light a fire for them as well.
>>
>> Ben Root
>>
>
> Are PIL and PyGTK holding back matplotlib for Python 3?
PIL is  used for the regression test framework, but it should be 
possible to remove that dependency there by using our own png loading code.

PyGTK is optional, of course, and users can use another GUI backend 
until the pygtk bindings catch up.
> Are there plans for matplotlib to drop Python 2.4 and 2.5? This would
> make porting to Python 3 much easier.
Yes.  The minimum version for this Python 3.x compatibility work is 
Python 2.6.  Anything earlier is just insane ;)

Mike
>
> Christoph
>
> --
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Question about (local) developement workflow

[Michael Droettboom]

It sounds like you're doing it right.  Make changes to the source 
directory, compile, then test.  There are some ways to streamline this.  
One is to leave a terminal window or tab open just for compiling -- then 
each compile is just a matter of "up arrow, Enter".


As an emacs user, I use the "compile" command.  You can replace the 
default command that it runs ("make") to ("python setup.py install").  I 
then bind F5 to "recompile" which saves all of my unsaved buffers, and 
then reinstalls.  I suspect most other programmer's editors and IDEs 
have a similar feature.


Mike

On 02/26/2011 06:31 AM, Maximilian Trescher wrote:

Hi,

i have a question about my personal developement workflow. I wanted to
fix a bug in matplotlib, therefore i checked out the repository.

Then i have to "install" matplotlib (with setupy.py build, setup.py
install). But every time i chenged something, i have to reinstall mpl to
test my changes.

I could make my changes directly in site-packages/matplotlib, but then
it's not version-controlled and the changes must be transferred back.

This workflow seems to be suboptimal, do i miss something?

Thanks,
Maximilian



--
Free Software Download: Index, Search&  Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev


___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Question about (local) developement workflow

[Jouni K . Seppänen]

Maximilian Trescher  writes:

> Then i have to "install" matplotlib (with setupy.py build, setup.py
> install). But every time i chenged something, i have to reinstall mpl to
> test my changes.

Unless you have something against setuptools (many people do):

python setupegg.py develop

This makes some kind of link in your site packages that points to your
development directory, so restarting python is enough for python-level
changes (or, presumably, reloading the relevant modules, but I have
never understood how to do that reliably). If you change extension code,
you'll naturally have to recompile with the same "develop" command.

-- 
Jouni K. Seppänen
http://www.iki.fi/jks


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Jeff Whitaker]

On 2/26/11 5:30 AM, Michiel de Hoon wrote:
>> In any case it appears that with the exception of Tkinter, it may take a
>> long time before interactive mpl backends can be used with py3k.
> The MacOSX backend has already been ported to Py3k (at least the C part of 
> it, which is the largest and most difficult part of it), though I won't be 
> able to test it until the rest of matplotlib has been ported.
>
>> The damn-ing part about the backends is that many users use only one of
>> the GUI backends, and if that one is broken for them, they believe that
>> matplotlib is completely broken.  (Evidence: the user who complained
>> that matplotlib was not designed correctly when it turned out that the
>> macosx backend didn't support (non-?)interactive mode).
> Sometimes I wonder if it is better to retire the MacOSX backend. When it was 
> first introduced, it was much faster (depending on what you wanted to draw) 
> because of how its event loop is organized. By now the other backends use the 
> same event loop strategy, and as far as I know there is no significant 
> difference in speed compared to e.g. the TkAgg backend. The remaining 
> advantage of the MacOSX backend is that it does not rely on other toolkits, 
> and therefore it is easier to compile and use if something changes (e.g., 
> when a new version of OS X comes out, or when compiling for 64-bits, or when 
> Py3K comes out).

Michiel

I use the macos x backend almost exclusively, for this reason.  It just 
works!

It also supports more output formats than TkAgg.

-Jeff

>   Still, it needs some maintenance work, and it is hard to keep up.
> Opinions, anybody?
>
> --Michiel.
>
>
>
>
>
>
> --
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Pauli Virtanen]

On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
[clip]
> Yes.  The minimum version for this Python 3.x compatibility work is
> Python 2.6.  Anything earlier is just insane ;)

Out of curiosity: did you consider using a single source tree for Python 
2.x and 3.x, rather than a separate branch; providing Python 3 support by 
running 2to3 on build stage and #ifdef's + compatibility headers in C 
code? 

This approach allowed Numpy to support Pythons down to 2.4 with little 
extra work, and requires manual Python 3 specific fixes only when 
something breaks (which does not seem to occur often in practice).

-- 
Pauli Virtanen


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Darren Dale]

On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen  wrote:
> On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
> [clip]
>> Yes.  The minimum version for this Python 3.x compatibility work is
>> Python 2.6.  Anything earlier is just insane ;)
>
> Out of curiosity: did you consider using a single source tree for Python
> 2.x and 3.x, rather than a separate branch; providing Python 3 support by
> running 2to3 on build stage and #ifdef's + compatibility headers in C
> code?
>
> This approach allowed Numpy to support Pythons down to 2.4 with little
> extra work, and requires manual Python 3 specific fixes only when
> something breaks (which does not seem to occur often in practice).

At some point, it will make sense to discontinue support for
<=python-2.5 (maybe even 2.6). I have used numpy's 2to3 for my
quantities project (admittedly a *much* smaller project with *much*
smaller exposure), but recently dropped backwards compatibility and
now 2.6-3.2 are supported in a single branch without use of 2to3. I
prefer this approach, it seems to be working out without too much
trouble so far.

Darren

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Question about (local) developement workflow

[Benjamin Root]

On Saturday, February 26, 2011, Jouni K. Seppänen  wrote:
> Maximilian Trescher  writes:
>
>> Then i have to "install" matplotlib (with setupy.py build, setup.py
>> install). But every time i chenged something, i have to reinstall mpl to
>> test my changes.
>
> Unless you have something against setuptools (many people do):
>
> python setupegg.py develop
>
> This makes some kind of link in your site packages that points to your
> development directory, so restarting python is enough for python-level
> changes (or, presumably, reloading the relevant modules, but I have
> never understood how to do that reliably). If you change extension code,
> you'll naturally have to recompile with the same "develop" command.
>
> --
> Jouni K. Seppänen
> http://www.iki.fi/jks
>


Even easier is

python setupegg.py develop --user

Which doesn't require sudo and is perfect for multiple-user systems.
I use for myself all the time.


Ben Root

>
> --
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Question about (local) developement workflow

[Maximilian Trescher]

> Even easier is
> 
> python setupegg.py develop --user
> 
> Which doesn't require sudo and is perfect for multiple-user systems.
> I use for myself all the time.

I installed the matplotlib developement version in a virtual
environement, where you can install every package as user. Anyway,
thanks for the tip.

maximilian



signature.asc
Description: OpenPGP digital signature
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Eric Firing]

On 02/26/2011 02:30 AM, Michiel de Hoon wrote:
>> In any case it appears that with the exception of Tkinter, it may take a
>> long time before interactive mpl backends can be used with py3k.
>
> The MacOSX backend has already been ported to Py3k (at least the C part of 
> it, which is the largest and most difficult part of it), though I won't be 
> able to test it until the rest of matplotlib has been ported.
>
>> The damn-ing part about the backends is that many users use only one of
>> the GUI backends, and if that one is broken for them, they believe that
>> matplotlib is completely broken.  (Evidence: the user who complained
>> that matplotlib was not designed correctly when it turned out that the
>> macosx backend didn't support (non-?)interactive mode).
>
> Sometimes I wonder if it is better to retire the MacOSX backend. When it was 
> first introduced, it was much faster (depending on what you wanted to draw) 
> because of how its event loop is organized. By now the other backends use the 
> same event loop strategy, and as far as I know there is no significant 
> difference in speed compared to e.g. the TkAgg backend. The remaining 
> advantage of the MacOSX backend is that it does not rely on other toolkits, 
> and therefore it is easier to compile and use if something changes (e.g., 
> when a new version of OS X comes out, or when compiling for 64-bits, or when 
> Py3K comes out). Still, it needs some maintenance work, and it is hard to 
> keep up.
> Opinions, anybody?

Michiel,

I don't have a mac, so I can't say yes or no based on my own usage. 
Your efforts in writing and maintaining that backend are appreciated, 
though.

What about the non-interactive mode behavior--is it hard to make the 
MaxOSX backend behave like the others in that respect?  From the general 
developer standpoint, I don't like divergence in behavior among the 
backends.  (I don't even like the way QT4agg seems to be diverging.)

Eric

>
> --Michiel.


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Matthew Brett]

Hi,

On Sat, Feb 26, 2011 at 4:30 AM, Michiel de Hoon  wrote:
>> In any case it appears that with the exception of Tkinter, it may take a
>> long time before interactive mpl backends can be used with py3k.
>
> The MacOSX backend has already been ported to Py3k (at least the C part of 
> it, which is the largest and most difficult part of it), though I won't be 
> able to test it until the rest of matplotlib has been ported.
>
>> The damn-ing part about the backends is that many users use only one of
>> the GUI backends, and if that one is broken for them, they believe that
>> matplotlib is completely broken.  (Evidence: the user who complained
>> that matplotlib was not designed correctly when it turned out that the
>> macosx backend didn't support (non-?)interactive mode).
>
> Sometimes I wonder if it is better to retire the MacOSX backend. When it was 
> first introduced, it was much faster (depending on what you wanted to draw) 
> because of how its event loop is organized. By now the other backends use the 
> same event loop strategy, and as far as I know there is no significant 
> difference in speed compared to e.g. the TkAgg backend. The remaining 
> advantage of the MacOSX backend is that it does not rely on other toolkits, 
> and therefore it is easier to compile and use if something changes (e.g., 
> when a new version of OS X comes out, or when compiling for 64-bits, or when 
> Py3K comes out). Still, it needs some maintenance work, and it is hard to 
> keep up.
> Opinions, anybody?

Seconding Jeff - I use the MacOSX backend too - was very grateful not
to have to install the other toolkits or suffer ugliness.  So, I'm
also grateful...

Best,

Matthew

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Benjamin Root]

On Sat, Feb 26, 2011 at 8:51 AM, Darren Dale  wrote:

> On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen  wrote:
> > On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
> > [clip]
> >> Yes.  The minimum version for this Python 3.x compatibility work is
> >> Python 2.6.  Anything earlier is just insane ;)
> >
> > Out of curiosity: did you consider using a single source tree for Python
> > 2.x and 3.x, rather than a separate branch; providing Python 3 support by
> > running 2to3 on build stage and #ifdef's + compatibility headers in C
> > code?
> >
> > This approach allowed Numpy to support Pythons down to 2.4 with little
> > extra work, and requires manual Python 3 specific fixes only when
> > something breaks (which does not seem to occur often in practice).
>
> At some point, it will make sense to discontinue support for
> <=python-2.5 (maybe even 2.6). I have used numpy's 2to3 for my
> quantities project (admittedly a *much* smaller project with *much*
> smaller exposure), but recently dropped backwards compatibility and
> now 2.6-3.2 are supported in a single branch without use of 2to3. I
> prefer this approach, it seems to be working out without too much
> trouble so far.
>
> Darren
>
>
My personal rule-of-thumb for what to support for scientific packages is
whichever version of python is in the latest RHEL.  Python 2.6 is in RHEL6,
so I feel that is a reasonable minimum.  Supporting python 2.4 (from RHEL5)
is probably too onerous at this point.

Ben Root
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Eric Firing]

On 02/26/2011 04:51 AM, Darren Dale wrote:
> On Sat, Feb 26, 2011 at 9:23 AM, Pauli Virtanen  wrote:
>> On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
>> [clip]
>>> Yes.  The minimum version for this Python 3.x compatibility work is
>>> Python 2.6.  Anything earlier is just insane ;)
>>
>> Out of curiosity: did you consider using a single source tree for Python
>> 2.x and 3.x, rather than a separate branch; providing Python 3 support by
>> running 2to3 on build stage and #ifdef's + compatibility headers in C
>> code?
>>
>> This approach allowed Numpy to support Pythons down to 2.4 with little
>> extra work, and requires manual Python 3 specific fixes only when
>> something breaks (which does not seem to occur often in practice).
>
> At some point, it will make sense to discontinue support for
> <=python-2.5 (maybe even 2.6). I have used numpy's 2to3 for my
> quantities project (admittedly a *much* smaller project with *much*
> smaller exposure), but recently dropped backwards compatibility and
> now 2.6-3.2 are supported in a single branch without use of 2to3. I
> prefer this approach, it seems to be working out without too much
> trouble so far.
>
> Darren
>

Supporting earlier versions is nice--I work with many machines running 
2.5, and keep mpl up to date on several of them, but thankfully I have 
nothing still stuck on 2.4--but for mpl, now that we have a pretty good 
1.x version, I don't think it would be too hard on users if we made a 
last release supporting earlier pythons and then dropped support for 
them in subsequent releases.  It would not mean people with earlier 
pythons couldn't run mpl, it would just mean they would get no new 
improvements, and no new bug fixes unless someone stepped forward to 
maintain the old branch.

Dropping 2.6 any time soon would be too drastic for my liking, though. 
It would require that any development work done on recent ubuntu 
systems, for example, would require first installing a non-default 
version of python.  So, I hope the py3k work can result in a 2.6-and-up 
codebase--is that the present goal?  Those of us developing on 2.6 will 
need to learn exactly how to avoid breaking 3.1 compatibility.

Eric

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Matthew Brett]

Hi,

On Sat, Feb 26, 2011 at 6:23 AM, Pauli Virtanen  wrote:
> On Sat, 26 Feb 2011 07:29:55 -0500, Michael Droettboom wrote:
> [clip]
>> Yes.  The minimum version for this Python 3.x compatibility work is
>> Python 2.6.  Anything earlier is just insane ;)
>
> Out of curiosity: did you consider using a single source tree for Python
> 2.x and 3.x, rather than a separate branch; providing Python 3 support by
> running 2to3 on build stage and #ifdef's + compatibility headers in C
> code?
>
> This approach allowed Numpy to support Pythons down to 2.4 with little
> extra work, and requires manual Python 3 specific fixes only when
> something breaks (which does not seem to occur often in practice).

I haven't done any Py3k porting.

I saw you (Pauli) doing the numpy and scipy ports using the same
codebase / 2to3 strategy, and that you were pleased with the results
(and it worked...).

IIRC the nose testing framework had a py3k branch that got very stale,
and they finally got there by dumping the py3k branch and using 2to3
on the same source tree.

See you,

Matthew

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Darren Dale]

On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing  wrote:
> On 02/16/2011 08:38 AM, Darren Dale wrote:
>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez  
>> wrote:
>>> are you guys planning on transfering the old bugs to github?
>>
>> Probably at some point.
>>
>>> As I
>>> mentioned, I have code lying around for the upload (and to download
>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>>> offline til Monday (conference trip), but if someone pings me on my
>>> Berkeley email address, which I monitor even while traveling, I'll be
>>> happy to help out.
>>
>> Thanks, that would be very helpful. I'll follow up once I figure out
>> how to extract the information from sourceforge.
>
> Darren,
>
> Just a heads-up on that: In November the tracker was heavily spammed.
> Recently I marked a few hundred items with the "delete" disposition, but
> I don't think that actually gets rid of them.  If it doesn't, then maybe
> they can be filtered out during the transfer.

We have some additional spam that needs to be deleted. How did you do
it? When I try to delete several at once (mass change), I get an error
message: "XSRF Attempt Detected!"

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Eric Firing]

On 02/26/2011 09:26 AM, Darren Dale wrote:
> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing  wrote:
>> On 02/16/2011 08:38 AM, Darren Dale wrote:
>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez
>>> wrote:
 are you guys planning on transfering the old bugs to github?
>>>
>>> Probably at some point.
>>>
 As I
 mentioned, I have code lying around for the upload (and to download
 from launchpad, but that's irrelevant here).  I'm going to be mosly
 offline til Monday (conference trip), but if someone pings me on my
 Berkeley email address, which I monitor even while traveling, I'll be
 happy to help out.
>>>
>>> Thanks, that would be very helpful. I'll follow up once I figure out
>>> how to extract the information from sourceforge.
>>
>> Darren,
>>
>> Just a heads-up on that: In November the tracker was heavily spammed.
>> Recently I marked a few hundred items with the "delete" disposition, but
>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>> they can be filtered out during the transfer.
>
> We have some additional spam that needs to be deleted. How did you do
> it? When I try to delete several at once (mass change), I get an error
> message: "XSRF Attempt Detected!"
>

I made the tracker display the maximum number of entries per page, then 
clicked "check all", then "mass update" with "delete", and it marked 
them as "deleted"--but they never get deleted.  They are still there, 
but marked "deleted". It sounds like that is the same as what you tried, 
so I don't know why you are getting that error message.

Which tracker category is showing the new spam?

Eric

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Darren Dale]

On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing  wrote:
> On 02/26/2011 09:26 AM, Darren Dale wrote:
>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing  wrote:
>>> On 02/16/2011 08:38 AM, Darren Dale wrote:
 On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez    
 wrote:
> are you guys planning on transfering the old bugs to github?

 Probably at some point.

> As I
> mentioned, I have code lying around for the upload (and to download
> from launchpad, but that's irrelevant here).  I'm going to be mosly
> offline til Monday (conference trip), but if someone pings me on my
> Berkeley email address, which I monitor even while traveling, I'll be
> happy to help out.

 Thanks, that would be very helpful. I'll follow up once I figure out
 how to extract the information from sourceforge.
>>>
>>> Darren,
>>>
>>> Just a heads-up on that: In November the tracker was heavily spammed.
>>> Recently I marked a few hundred items with the "delete" disposition, but
>>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>>> they can be filtered out during the transfer.
>>
>> We have some additional spam that needs to be deleted. How did you do
>> it? When I try to delete several at once (mass change), I get an error
>> message: "XSRF Attempt Detected!"
>>
>
> I made the tracker display the maximum number of entries per page, then
> clicked "check all", then "mass update" with "delete", and it marked
> them as "deleted"--but they never get deleted.  They are still there,
> but marked "deleted". It sounds like that is the same as what you tried,
> so I don't know why you are getting that error message.
>
> Which tracker category is showing the new spam?

The Feature Requests. I was not able to mark the spam as deleted, but
I filtered it out in the conversion.

The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewedeThe tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues/issues at The tracker export
xml file and conversion script are up at
https://github.com/darrendale/mpl-issues/issues . Devs, please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Darren Dale]

On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale  wrote:
> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing  wrote:
>> On 02/26/2011 09:26 AM, Darren Dale wrote:
>>> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing  wrote:
 On 02/16/2011 08:38 AM, Darren Dale wrote:
> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez    
> wrote:
>> are you guys planning on transfering the old bugs to github?
>
> Probably at some point.
>
>> As I
>> mentioned, I have code lying around for the upload (and to download
>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>> offline til Monday (conference trip), but if someone pings me on my
>> Berkeley email address, which I monitor even while traveling, I'll be
>> happy to help out.
>
> Thanks, that would be very helpful. I'll follow up once I figure out
> how to extract the information from sourceforge.

 Darren,

 Just a heads-up on that: In November the tracker was heavily spammed.
 Recently I marked a few hundred items with the "delete" disposition, but
 I don't think that actually gets rid of them.  If it doesn't, then maybe
 they can be filtered out during the transfer.
>>>
>>> We have some additional spam that needs to be deleted. How did you do
>>> it? When I try to delete several at once (mass change), I get an error
>>> message: "XSRF Attempt Detected!"
>>>
>>
>> I made the tracker display the maximum number of entries per page, then
>> clicked "check all", then "mass update" with "delete", and it marked
>> them as "deleted"--but they never get deleted.  They are still there,
>> but marked "deleted". It sounds like that is the same as what you tried,
>> so I don't know why you are getting that error message.
>>
>> Which tracker category is showing the new spam?
>
> The Feature Requests. I was not able to mark the spam as deleted, but
> I filtered it out in the conversion.

Let me try again:

The tracker export xml file and conversion script are up at
https://github.com/darrendale/mpl-issues , and the issues can be
previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
please have a
look. I only imported the open issues, including bugs, patches,
feature requests and support requests. If we decide to use the github
tracker, we can tell sourceforge we have relocated the project, and
the project will remain intact and archived. I don't know if that
would mean that we can no longer host the homepage at sourceforge.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Darren Dale]

On Sat, Feb 26, 2011 at 1:22 PM, Eric Firing  wrote:
> Dropping 2.6 any time soon would be too drastic for my liking, though.
> It would require that any development work done on recent ubuntu
> systems, for example, would require first installing a non-default
> version of python.  So, I hope the py3k work can result in a 2.6-and-up
> codebase--is that the present goal?

Yes, it is.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Eric Firing]

On 02/26/2011 10:54 AM, Darren Dale wrote:
> On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale  wrote:
>> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing  wrote:
>>> On 02/26/2011 09:26 AM, Darren Dale wrote:
 On Wed, Feb 16, 2011 at 2:19 PM, Eric Firingwrote:
> On 02/16/2011 08:38 AM, Darren Dale wrote:
>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez   
>>wrote:
>>> are you guys planning on transfering the old bugs to github?
>>
>> Probably at some point.
>>
>>> As I
>>> mentioned, I have code lying around for the upload (and to download
>>> from launchpad, but that's irrelevant here).  I'm going to be mosly
>>> offline til Monday (conference trip), but if someone pings me on my
>>> Berkeley email address, which I monitor even while traveling, I'll be
>>> happy to help out.
>>
>> Thanks, that would be very helpful. I'll follow up once I figure out
>> how to extract the information from sourceforge.
>
> Darren,
>
> Just a heads-up on that: In November the tracker was heavily spammed.
> Recently I marked a few hundred items with the "delete" disposition, but
> I don't think that actually gets rid of them.  If it doesn't, then maybe
> they can be filtered out during the transfer.

 We have some additional spam that needs to be deleted. How did you do
 it? When I try to delete several at once (mass change), I get an error
 message: "XSRF Attempt Detected!"

>>>
>>> I made the tracker display the maximum number of entries per page, then
>>> clicked "check all", then "mass update" with "delete", and it marked
>>> them as "deleted"--but they never get deleted.  They are still there,
>>> but marked "deleted". It sounds like that is the same as what you tried,
>>> so I don't know why you are getting that error message.
>>>
>>> Which tracker category is showing the new spam?
>>
>> The Feature Requests. I was not able to mark the spam as deleted, but
>> I filtered it out in the conversion.
>
> Let me try again:
>
> The tracker export xml file and conversion script are up at
> https://github.com/darrendale/mpl-issues , and the issues can be
> previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
> please have a
> look. I only imported the open issues, including bugs, patches,
> feature requests and support requests. If we decide to use the github
> tracker, we can tell sourceforge we have relocated the project, and
> the project will remain intact and archived. I don't know if that
> would mean that we can no longer host the homepage at sourceforge.

The submitter info is lost?
And when it was originally submitted?
If yes to either, then I think that we should not transfer these from 
sourceforge, but deal with them there.
Overall, the tracking interface on github looks so bad that I can't see 
why we would want to move.  Sourceforge is slow, but at least the 
tracker has the right sort of functionality: the ability to scan a lot 
of info on one screen, the ability to categorize, attach files, assign, 
etc.  Maybe some of this is available but not evident in the github 
tracker, but what I see is not encouraging.

Mpl historically has not done well in using the tracker.  I hope that 
eventually we can transition to a tool that will help us do better, not 
worse.

Eric

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Benjamin Root]

On Sat, Feb 26, 2011 at 4:58 PM, Eric Firing  wrote:

> On 02/26/2011 10:54 AM, Darren Dale wrote:
> > On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale  wrote:
> >> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing
>  wrote:
> >>> On 02/26/2011 09:26 AM, Darren Dale wrote:
>  On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing
>  wrote:
> > On 02/16/2011 08:38 AM, Darren Dale wrote:
> >> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez gmail.com>  wrote:
> >>> are you guys planning on transfering the old bugs to github?
> >>
> >> Probably at some point.
> >>
> >>> As I
> >>> mentioned, I have code lying around for the upload (and to download
> >>> from launchpad, but that's irrelevant here).  I'm going to be mosly
> >>> offline til Monday (conference trip), but if someone pings me on my
> >>> Berkeley email address, which I monitor even while traveling, I'll
> be
> >>> happy to help out.
> >>
> >> Thanks, that would be very helpful. I'll follow up once I figure out
> >> how to extract the information from sourceforge.
> >
> > Darren,
> >
> > Just a heads-up on that: In November the tracker was heavily spammed.
> > Recently I marked a few hundred items with the "delete" disposition,
> but
> > I don't think that actually gets rid of them.  If it doesn't, then
> maybe
> > they can be filtered out during the transfer.
> 
>  We have some additional spam that needs to be deleted. How did you do
>  it? When I try to delete several at once (mass change), I get an error
>  message: "XSRF Attempt Detected!"
> 
> >>>
> >>> I made the tracker display the maximum number of entries per page, then
> >>> clicked "check all", then "mass update" with "delete", and it marked
> >>> them as "deleted"--but they never get deleted.  They are still there,
> >>> but marked "deleted". It sounds like that is the same as what you
> tried,
> >>> so I don't know why you are getting that error message.
> >>>
> >>> Which tracker category is showing the new spam?
> >>
> >> The Feature Requests. I was not able to mark the spam as deleted, but
> >> I filtered it out in the conversion.
> >
> > Let me try again:
> >
> > The tracker export xml file and conversion script are up at
> > https://github.com/darrendale/mpl-issues , and the issues can be
> > previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
> > please have a
> > look. I only imported the open issues, including bugs, patches,
> > feature requests and support requests. If we decide to use the github
> > tracker, we can tell sourceforge we have relocated the project, and
> > the project will remain intact and archived. I don't know if that
> > would mean that we can no longer host the homepage at sourceforge.
>
> The submitter info is lost?
> And when it was originally submitted?
> If yes to either, then I think that we should not transfer these from
> sourceforge, but deal with them there.
> Overall, the tracking interface on github looks so bad that I can't see
> why we would want to move.  Sourceforge is slow, but at least the
> tracker has the right sort of functionality: the ability to scan a lot
> of info on one screen, the ability to categorize, attach files, assign,
> etc.  Maybe some of this is available but not evident in the github
> tracker, but what I see is not encouraging.
>
> Mpl historically has not done well in using the tracker.  I hope that
> eventually we can transition to a tool that will help us do better, not
> worse.
>
> Eric
>
>
Ditto on this.  Github has been a wonderful tool for *developers*, but for
users of projects, I haven't seen the amount of sophistication and polish
that sourceforge has.

I am personally fine with continuing to use sourceforge for the tracker (I
know I need to catch up on bugs there...).  My main concern, though, is
having two active issue trackers -- one on sourceforge and one on github.

Ben Root
--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Darren Dale]

On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing  wrote:
> On 02/26/2011 10:54 AM, Darren Dale wrote:
>> On Sat, Feb 26, 2011 at 3:52 PM, Darren Dale  wrote:
>>> On Sat, Feb 26, 2011 at 2:52 PM, Eric Firing  wrote:
 On 02/26/2011 09:26 AM, Darren Dale wrote:
> On Wed, Feb 16, 2011 at 2:19 PM, Eric Firing    wrote:
>> On 02/16/2011 08:38 AM, Darren Dale wrote:
>>> On Wed, Feb 16, 2011 at 12:39 PM, Fernando Perez  
>>>     wrote:
 are you guys planning on transfering the old bugs to github?
>>>
>>> Probably at some point.
>>>
 As I
 mentioned, I have code lying around for the upload (and to download
 from launchpad, but that's irrelevant here).  I'm going to be mosly
 offline til Monday (conference trip), but if someone pings me on my
 Berkeley email address, which I monitor even while traveling, I'll be
 happy to help out.
>>>
>>> Thanks, that would be very helpful. I'll follow up once I figure out
>>> how to extract the information from sourceforge.
>>
>> Darren,
>>
>> Just a heads-up on that: In November the tracker was heavily spammed.
>> Recently I marked a few hundred items with the "delete" disposition, but
>> I don't think that actually gets rid of them.  If it doesn't, then maybe
>> they can be filtered out during the transfer.
>
> We have some additional spam that needs to be deleted. How did you do
> it? When I try to delete several at once (mass change), I get an error
> message: "XSRF Attempt Detected!"
>

 I made the tracker display the maximum number of entries per page, then
 clicked "check all", then "mass update" with "delete", and it marked
 them as "deleted"--but they never get deleted.  They are still there,
 but marked "deleted". It sounds like that is the same as what you tried,
 so I don't know why you are getting that error message.

 Which tracker category is showing the new spam?
>>>
>>> The Feature Requests. I was not able to mark the spam as deleted, but
>>> I filtered it out in the conversion.
>>
>> Let me try again:
>>
>> The tracker export xml file and conversion script are up at
>> https://github.com/darrendale/mpl-issues , and the issues can be
>> previewed at https://github.com/darrendale/mpl-issues/issues . Devs,
>> please have a
>> look. I only imported the open issues, including bugs, patches,
>> feature requests and support requests. If we decide to use the github
>> tracker, we can tell sourceforge we have relocated the project, and
>> the project will remain intact and archived. I don't know if that
>> would mean that we can no longer host the homepage at sourceforge.
>
> The submitter info is lost?
> And when it was originally submitted?

No, I can improve it so this information is included.

> If yes to either, then I think that we should not transfer these from
> sourceforge, but deal with them there.

Each issue has a hyperlink to the report at sourceforge.

> Overall, the tracking interface on github looks so bad that I can't see
> why we would want to move.  Sourceforge is slow, but at least the
> tracker has the right sort of functionality: the ability to scan a lot
> of info on one screen, the ability to categorize, attach files, assign,
> etc.  Maybe some of this is available but not evident in the github
> tracker, but what I see is not encouraging.

I agree that the github interface is not great. The github devs seem
to know that everybody complains about it.

There are some good things about it though. Labels, the ability to
link between an issue and the commits that resolve it, the ability for
people to provide feedback on what issues are important to them.

> Mpl historically has not done well in using the tracker.  I hope that
> eventually we can transition to a tool that will help us do better, not
> worse.

I disagree that we would do worse with the github tracker.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Darren Dale]

On Sat, Feb 26, 2011 at 6:15 PM, Benjamin Root  wrote:
> Github has been a wonderful tool for *developers*, but for
> users of projects, I haven't seen the amount of sophistication and polish
> that sourceforge has.
>
> I am personally fine with continuing to use sourceforge for the tracker (I
> know I need to catch up on bugs there...).  My main concern, though, is
> having two active issue trackers -- one on sourceforge and one on github.

The one at github can be easily disabled.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Fernando Perez]

On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale  wrote:
>
> I agree that the github interface is not great. The github devs seem
> to know that everybody complains about it.

Yup.  I hold on to the hope that, because it's so egregiously,
painfully broken and braindead and it stands out so badly in
comparison to the rest of github (which is brilliant), that it won't
be too long before this improves. Granted, we can't know what's on
their internal todo list, but those guys are obviously good and listen
to feedback (from what I've seen elsewhere on the site), and their bug
tracker has become something of a laughing stock, so I can only
imagine that they're actually working on it.

In the meantime, Min recently pointed out this interesting alternative:

http://githubissues.heroku.com/#darrendale/mpl-issues

You can point it to any repository you want, and it makes interacting
with the issue list far, far saner than via github itself.

We're using now that interface ourselves for IPython:

http://githubissues.heroku.com/#ipython/ipython

and I have to say that I like it quite a bit.  For those on OSX, this
can even be installed to run locally, with the feel of a native app
(it's still a webkit app, but it launches like a local app).

Something to keep in mind as you make the decision...

In the end, in IPython we decided to move to github in order to
benefit from the close integration between pull requests, bugs and
commits.  Pull requests automatically create an issue, one can close
bugs automatically from the commit message, etc.  I figured these
things would be nice to have for an everyday workflow, and that
eventually github itself would improve its native bug system.

Cheers,

f

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Eric Firing]

On 02/26/2011 01:44 PM, Fernando Perez wrote:
> On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale  wrote:
>>
>> I agree that the github interface is not great. The github devs seem
>> to know that everybody complains about it.
>
> Yup.  I hold on to the hope that, because it's so egregiously,
> painfully broken and braindead and it stands out so badly in
> comparison to the rest of github (which is brilliant), that it won't
> be too long before this improves. Granted, we can't know what's on
> their internal todo list, but those guys are obviously good and listen
> to feedback (from what I've seen elsewhere on the site), and their bug
> tracker has become something of a laughing stock, so I can only
> imagine that they're actually working on it.
>
> In the meantime, Min recently pointed out this interesting alternative:
>
> http://githubissues.heroku.com/#darrendale/mpl-issues

It is impressive, and improves some aspects, but I don't see that it 
makes the github tracker usable for new tickets.  I don't see any 
facility for attaching a file--is this correct?  We really want users 
with problems and suggestions to attach minimal example files, patches, 
whatever--as downloadable files, not pasted into the comment box.

My inclination would be to keep using the SF tracker exclusively until 
the github tracker improves substantially, and then switch.

Eric

>
> You can point it to any repository you want, and it makes interacting
> with the issue list far, far saner than via github itself.
>
> We're using now that interface ourselves for IPython:
>
> http://githubissues.heroku.com/#ipython/ipython
>
> and I have to say that I like it quite a bit.  For those on OSX, this
> can even be installed to run locally, with the feel of a native app
> (it's still a webkit app, but it launches like a local app).
>
> Something to keep in mind as you make the decision...
>
> In the end, in IPython we decided to move to github in order to
> benefit from the close integration between pull requests, bugs and
> commits.  Pull requests automatically create an issue, one can close
> bugs automatically from the commit message, etc.  I figured these
> things would be nice to have for an everyday workflow, and that
> eventually github itself would improve its native bug system.
>
> Cheers,
>
> f
>
> --
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Michiel de Hoon]

--- On Sat, 2/26/11, Eric Firing  wrote:
> What about the non-interactive mode behavior--is it hard to
> make the  MaxOSX backend behave like the others in that
> respect?
I agree that this should be done, but I just haven't found the time to look at 
it (recently I have been looking at getting animations to work with the MacOSX 
backend). Probably it is not all that hard, and I would welcome contributions 
from other developers who use the MacOSX backend to get the non-interactive 
mode behavior consistent with the other backends.

On a related note, something I found confusing for new matplotlib users is that 
after first installing it, matplotlib is non-interactive by default. After 
installing matplotlib, I think users should be able to try it out and make some 
simple plots that appear on the screen without having to find out about 
interactive behavior and edit matplotlibrc. Especially people that are new to 
programming or to Python may be disappointed if their first plotting attempts 
don't seem to produce a figure.

--Michiel.


  

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] git migration this weekend

[Fernando Perez]

On Sat, Feb 26, 2011 at 6:14 PM, Eric Firing  wrote:
> It is impressive, and improves some aspects, but I don't see that it
> makes the github tracker usable for new tickets.  I don't see any
> facility for attaching a file--is this correct?  We really want users
> with problems and suggestions to attach minimal example files, patches,
> whatever--as downloadable files, not pasted into the comment box.

No, that's a current limitation of the github tracker.  As a poor
man's attachment system, github does have the gist system:

https://gist.github.com/

that makes it easy to drop any file (small or large) and have it
permanently stored on GH with a stable url.

But I agree that the tracker should have proper file attachments
built-in, using gist is just a workaround, and one most people won't
necessarily know about gist or think of it as a way to attach files to
the tracker.

> My inclination would be to keep using the SF tracker exclusively until
> the github tracker improves substantially, and then switch.

Since we did switch for ipython, here's me keeping my fingers
painfully crossed for that day to come earlier rather than later...

Cheers,

f

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] What's the status of the py3k branch?

[Eric Firing]

On 02/26/2011 04:25 PM, Michiel de Hoon wrote:
> --- On Sat, 2/26/11, Eric Firing  wrote:
>> What about the non-interactive mode behavior--is it hard to
>> make the  MaxOSX backend behave like the others in that
>> respect?
> I agree that this should be done, but I just haven't found the time to look 
> at it (recently I have been looking at getting animations to work with the 
> MacOSX backend). Probably it is not all that hard, and I would welcome 
> contributions from other developers who use the MacOSX backend to get the 
> non-interactive mode behavior consistent with the other backends.
>
> On a related note, something I found confusing for new matplotlib users is 
> that after first installing it, matplotlib is non-interactive by default. 
> After installing matplotlib, I think users should be able to try it out and 
> make some simple plots that appear on the screen without having to find out 
> about interactive behavior and edit matplotlibrc. Especially people that are 
> new to programming or to Python may be disappointed if their first plotting 
> attempts don't seem to produce a figure.

That's a good point.  Until fairly recently, interactive behavior worked 
across backends only via ipython magic, so I think the non-interactive 
default had a solid historical rationale.  Now, however, we could 
probably make interactive mode the startup default for interactive 
backends without causing any problems.  I agree that this would be more 
intuitive and more familiar to people coming from matlab.

Eric

>
> --Michiel.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel