Re: [matplotlib-devel] path simplification with nan (or move_to)

2008-10-09 Thread Michael Droettboom
Michael Droettboom wrote:
> John Hunter wrote:
>   
>> In unrelated news, I am not in favor of the recent change to warn on
>> non-GUI backends when "show" is called.  I realize this may sometimes
>> cause head-scratching behavior for some users who call show and no
>> figure pops up, but I think this must be pretty rare.  99% of users
>> have a matplotlibrc which defines a GUI default.  AFAIK, the only
>> exceptions to this are 1) when the user has changed the rc (power
>> user, needs no protection) or 2) no GUI was available at build time
>> and the image backend was the default backend chosen (warning more
>> appropriate at build time).  If I am missing a use case, let me know.
>>   
>> 
> The motivation was when a popular Linux distribution misconfigured the 
> default to the Agg backend:
>
> https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/278764
>
> This warning was meant as future insurance against this happening -- and 
> hoping that if the packagers don't make a GUI backend the default (in an 
> attempt to reduce dependencies), that they at least would include the 
> warning patch so that users aren't left feeling that matplotlib is "broken".
>
> But we can't prevent all downstream packaging errors, so maybe this 
> patch doesn't belong in trunk. ;)
>   
>> I like the design where the same script can be used to either generate
>> a UI figure or hardcopy depending on an rc settng or a command flag
>> (eg backend driver) and would rather not do the warning.  This has
>> been a very infrequent problem for users over the years (a few times
>> at most?) so I am not sure that the annoyance of the warning is
>> justified.
>>   
>> 
> Perhaps the warning could only be emitted when running inside an 
> interactive console (ipython or standard python) -- if that's possible.  
> Alternatively, "ipython -pylab" could warn on startup if the backend is 
> non-GUI (and that change would probably live in ipython).
I have modified the code to only do this when show() is called directly 
from the python or ipython console.  Calling show() from a script will 
not emit this warning.

If that's still too noisy, I'm happy to revert the whole thing.

Mike

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] path simplification with nan (or move_to)

2008-10-09 Thread John Hunter
On Thu, Oct 9, 2008 at 6:14 AM, Michael Droettboom <[EMAIL PROTECTED]> wrote:

>> If  2) in the choices above is the case you are concerned about, and
>> you want this warning feature in this case, we can add an rc param
>> which is autoset at build time, something like "show.warn =
>> True|False" since the build script is setting the default image
>> backend and can set "show.warn = True" when it sets an image backend
>> by default, otherwise False.
>>
>
> I intended the warning to warn against misconfiguration, so one shouldn't
> have to explicitly configure anything to get it... ;)

This is mostly academic, since I am happy with your latest changes
because I can run backend driver or do

 > python somefile.py -dAgg

and get no warning.

But  I wasn't suggesting explicit configuration by the user.  At
build time, mpl looks for a functioning backend in setup.py and if it
fails to find one, sets Agg and creates the default matplotlibrc from
matplotlibrc.template.  In the case where a no GUI was detected, the
build script could also set a rc warn-on-show flag.  The ubuntu
packager, who probably built mpl in an environment with no X11 and got
no functioning GUI, would get a rc file with backend Agg and the
warn-on-show flag set.

But I think we can leave things as they are.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] path simplification with nan (or move_to)

2008-10-09 Thread Michael Droettboom
John Hunter wrote:
> On Wed, Oct 8, 2008 at 8:40 PM, Eric Firing <[EMAIL PROTECTED]> wrote:
>   
>> Thanks for doing this--it has already helped me in my testing of the
>> gappy-path simplification support, which I have now committed.  As you
>> suggested earlier, I included in path.py a check for a compatible codes
>> array.
>>
>> The agg limit still can be a problem.  It looks like chunking could be added
>> easily by making the backend_agg draw_path a python method calling the
>> renderer method; if the path length exceeds some threshold, then subpaths
>> would be generated and passed to the renderer method.
>> 
>
> In unrelated news, I am not in favor of the recent change to warn on
> non-GUI backends when "show" is called.  I realize this may sometimes
> cause head-scratching behavior for some users who call show and no
> figure pops up, but I think this must be pretty rare.  99% of users
> have a matplotlibrc which defines a GUI default.  AFAIK, the only
> exceptions to this are 1) when the user has changed the rc (power
> user, needs no protection) or 2) no GUI was available at build time
> and the image backend was the default backend chosen (warning more
> appropriate at build time).  If I am missing a use case, let me know.
>   
The motivation was when a popular Linux distribution misconfigured the 
default to the Agg backend:

https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/278764

This warning was meant as future insurance against this happening -- and 
hoping that if the packagers don't make a GUI backend the default (in an 
attempt to reduce dependencies), that they at least would include the 
warning patch so that users aren't left feeling that matplotlib is "broken".

But we can't prevent all downstream packaging errors, so maybe this 
patch doesn't belong in trunk. ;)
> I like the design where the same script can be used to either generate
> a UI figure or hardcopy depending on an rc settng or a command flag
> (eg backend driver) and would rather not do the warning.  This has
> been a very infrequent problem for users over the years (a few times
> at most?) so I am not sure that the annoyance of the warning is
> justified.
>   
Perhaps the warning could only be emitted when running inside an 
interactive console (ipython or standard python) -- if that's possible.  
Alternatively, "ipython -pylab" could warn on startup if the backend is 
non-GUI (and that change would probably live in ipython).
> If  2) in the choices above is the case you are concerned about, and
> you want this warning feature in this case, we can add an rc param
> which is autoset at build time, something like "show.warn =
> True|False" since the build script is setting the default image
> backend and can set "show.warn = True" when it sets an image backend
> by default, otherwise False.
>   
I intended the warning to warn against misconfiguration, so one 
shouldn't have to explicitly configure anything to get it... ;)

Mike

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] Patch for scatter plot legend enhancement

2008-10-09 Thread John Hunter
On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
> Ah, that makes more sense Jae-Joon - thanks!

Jae-Joon -- could you handle this patch submission?

Thanks,
JDH

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] Patch for scatter plot legend enhancement

2008-10-09 Thread Jae-Joon Lee
Okay.
I may work on it sometime tomorrow or during the weekends.

Regards,

-JJ


On Thu, Oct 9, 2008 at 12:54 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote:
>> Ah, that makes more sense Jae-Joon - thanks!
>
> Jae-Joon -- could you handle this patch submission?
>
> Thanks,
> JDH
>

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] scatter and alpha settings

2008-10-09 Thread Eric Firing
Gregor Thalhammer wrote:
> Dear developers,
> 
> in matplotlib 0.98.3 I discoverd that in scatter individual alpha 
> settings (by giving a list of rgba values) are ignered. Here an example 
> that show this behaviour: All points show the same alpha value as given 
> by the alpha keyword argument. (Omitting it equals to the setting alpha=1).
> 
> 
> from pylab import *
> 
> x = [1,2,3]
> y = [1,2,3]
> 
> c = [[1,0,0, 0.0],
>  [1,0,0, 0.5],
>  [1,0,0, 1.0]]
> 
> gca()
> cla()
> scatter(x,y, c=c, s = 200, alpha = 0.5)
> draw()
> show()
> 
> 
> I had a look at the sources. In axes.py/scatter I simply removed the line
> 
> collection.set_alpha(alpha)

You are correct that there is a bug, in that the alpha in rgba arrays is 
  always overridden, but removing that line is not the solution.  I will 
try to fix it in the next few days.  I think the intention was that 
alpha=None would be used to mean "don't disturb existing alpha in an 
rgba array; but use alpha=1 if color comes in as other than rgba", but 
this has not been propagated uniformly.  Small changes in quite a few 
places may be needed.

Eric

> 
> The recent svn version also contains this line.
> With this change it worked as expected, also e.g. for the case of a 
> single color for all points,
> 
> scatter(x,y, c = 'r', alpha = 0.5)
> 
> Gregor

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel