Testing 1,2,3

The mailing lists have been down for a few days, and this is a test.

Charlie

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Introduction

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

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

Re: Introduction

>>>>> "Greg" == Greg Willden <gregwillden@...> writes:

    Greg> Hi All, I'm a longtime Matlab user.  I've been using Python
    Greg> for a year or two and have begun using
    Greg> Matplotlib/Numpy/Scipy.  I have a patch for specgram() that
    Greg> will plot the spectrogram with the positive and negative
    Greg> frequencies flipped (fftshift).  This is the way that you
    Greg> would examine the complex data coming out of a receiver.

    Greg> What is the prefered method for submitting patches?  I
    Greg> didn't find any information on the website.

The best way is to add them as patches to the sf site and then post
here with a link to the patch (and attach the patch if possible).  I
tend to monitor this list much more closely, but it is nice to have it
on the sf site if it falls between the cracks because it is easier for
someone to pick it up later.  If you get no action in a week or two,
ping us again.

    Greg> Also, I would like to add support for more window functions
    Greg> in specgram().  I see three options for doing this: a) Add
    Greg> the window functions directly ( drawback: code duplication)
    Greg> b) Add wrappers for the window functions in SciPy (drawback:
    Greg> additional dependencies?)  

We are trying to move away from adding our own numerical code and have
this go into numpy/scipy.  I suggest adding a docstring saying,
additional window functions a,b and c are available in
somepackage.somemodule

    Greg> c) Modify specgram so that if it
    Greg> receives an array as the window parameter it checks its
    Greg> length and then applies it as a window.  If the window
    Greg> parameter is not an array then it treats it as a function
    Greg> (current behaviour)

This is fine -- I suggest using the matplotlib.cookbook.iterable
function or the python builtin callable function to do the check.
Whatever changes you make for specgram should also be ported into psd,
csd and cohere.

Thanks,
JDH

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

mpl on AIX

matplotlib-0.87.6 works fine on AIX 5.1, with gcc 3.2.2 and python 2.5 .
I've not compiled it with GTK or TK support but the Agg backend works.

Would it be possible for a developer to modify the code to include AIX
in the supported OS list? I always have change this structure in
setupext.py manually:

basedir = {
    'win32'  : ['win32_static',],
    'linux2' : ['/usr/local', '/usr',],
    'linux'  : ['/usr/local', '/usr',],
    'cygwin' : ['/usr/local', '/usr',],
    'darwin' : ['/sw/lib/freetype2', '/sw/lib/freetype219',
'/usr/local',
                '/usr', '/sw'],
    'freebsd4' : ['/usr/local', '/usr'],
    'freebsd5' : ['/usr/local', '/usr'],
    'freebsd6' : ['/usr/local', '/usr'],
    'sunos5' : [os.getenv('MPLIB_BASE') or '/usr/local',],
    'gnukfreebsd5' : ['/usr/local', '/usr'],
    'gnukfreebsd6' : ['/usr/local', '/usr'],
}

To add the entry:

    'aix5' : [/usr/local],

Thanks for making this wonderful library available!
Mike.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: Introduction

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

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

Re: Introduction

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

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

Re: Please forward the to matplotlib-devel

Forwarded as requested....

On 10/8/06, Gael Varoquaux <gael.varoquaux@...> wrote:
> My apologies, I cannot post to any SF mailing lists currently. Could one
> of you (whoever sees this first) forward this message to matplotlib-dev,
> I can still receive post coming from there.
>
> I am really sorry to ask you such a service.
>
> Thanks a lot,
>
> Gaël
>
> From: Gael Varoquaux <gael_dot_varoquaux_at_normalesup_dot_org>
> To: Matplotlib-devel <matplotlib-devel_at_lists_dot_sourceforge_dot_net>
> Subject: Good method for updating an imshow plot
>
> Hi,
>
> This does not belong to the devel mailing list, but to the users, but I
> cannon subscribe to the users, as my SMTP is black listed by SpamCop
> (screw them, the server isn't sending a single spam).
>
> My question is: what is the correct way to plot a matrix with an imshow,
> and then update this matrix on the plot. I am more interested by the mpl
> way of doing this, rather than the pylab way. The idea would be to
> replace the following pylab commands by something cleaner that would
> involve recreating axes:
>
> imshow(z1)
> clf()
> imshow(z2)
>
> Cheers,
>
>
> Gaël
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

marker color handling

Hi Eric, hi everybody,

I just noticed that you, Eric, have committed r2799 to SVN which partly
reverts my commit r2790.

I understand that, obviously, the changes that I introduced are more
controversial than I would have expected, so we should try to reach an
agreement.

Was your objection generally about my patch or just about some detail? I
know that the patch might have broken a bit of compatibility, but since
the old logic was inconsistent and hard to understand, I figured that a
cleaner and simpler logic would justify a some possible break of
compatibility.

If you disagree with some change in principle, I would like to know your
objection. If there simply was a bug introduced by the change, I
appologize and hope I can fix it.

In any case, I have to point out that the current state of the SVN code
after the partial reversion of my commit is not self-consistent: My
commit changed several files besides axes.py - only reverting this one
file is bound to cause problems.

Greetings,
Norbert

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: marker color handling

Norbert,

Your 2790 patch seems to have completely wiped out the handling of 
marker colors in the simple case "N.plot(N.random.random(1000),'r.')", 
as noted by Stefan Van der Walt in a message yesterday to the matplotlib 
users list.  I presume you are monitoring that list, and saw his message 
and my reply in which I noted that I was reverting the changes to 
axes.py.  I looked at the changes to axes.py, and it appeared that you 
had simply forgotten the marker color handling; otherwise, the changes 
appeared to be code rearrangements, not API changes that would interact 
with other files, so I thought that reverting that file alone would 
work--that is, restore basic functionality to the svn version.  My 
original thought was to wait and let you fix it, and evidently I should 
have, but I decided it would be better not to leave svn without the 
marker color functionality in the interim, and I had no way of knowing 
whether you would be able to get to it right away.  In any case, I made 
the change, verified that it did restore marker color handling, 
committed it to svn, and left it at that.

Of course I was too hasty, and neglected to look at the patch as a 
whole; now I see that you were trying to shift the setting of marker 
colors out of axes.py and into lines.py.  I still don't know why 
Stefan's simple example was broken, and I don't have time now to 
understand your patch properly, though I wish I did.  I certainly don't 
object to the idea of trying to make the code cleaner and easier to follow.

So: please either restore your patch with additional changes to fix the 
problem Stefan found, or revert all of it cleanly until this can be 
sorted out.

If you think there might be incompatibilities introduced by your patch, 
then it would be good to know what they are.

Sorry to have made the situation more confusing than necessary.

Eric

Norbert Nemec wrote:
> Hi Eric, hi everybody,
> 
> I just noticed that you, Eric, have committed r2799 to SVN which partly
> reverts my commit r2790.
> 
> I understand that, obviously, the changes that I introduced are more
> controversial than I would have expected, so we should try to reach an
> agreement.
> 
> Was your objection generally about my patch or just about some detail? I
> know that the patch might have broken a bit of compatibility, but since
> the old logic was inconsistent and hard to understand, I figured that a
> cleaner and simpler logic would justify a some possible break of
> compatibility.
> 
> If you disagree with some change in principle, I would like to know your
> objection. If there simply was a bug introduced by the change, I
> appologize and hope I can fix it.
> 
> In any case, I have to point out that the current state of the SVN code
> after the partial reversion of my commit is not self-consistent: My
> commit changed several files besides axes.py - only reverting this one
> file is bound to cause problems.
> 
> Greetings,
> Norbert

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: marker color handling

>>>>> "Eric" == Eric Firing <efiring@...> writes:

    Eric> So: please either restore your patch with additional changes
    Eric> to fix the problem Stefan found, or revert all of it cleanly
    Eric> until this can be sorted out.

Norbert -- can you describe briefly the inconsistencies in the format
arg color handling you were trying to address in your patch?  I see
this --
http://sourceforge.net/tracker/index.php?func=detail&aid=1504387&group_id=80706&atid=560722
-- but not much detail about the problems the changes fix.  

Also, for all developers, when making API changes

  * post here with a brief descriptions of changes and rationale

  * make a note in API_CHANGES

  * run backend_driver.py.  It is a good habit to not only run the
    script to make sure no exceptions are raised, but also to view
    the output PNG etc files in your favorite image viewer to make
    sure the output is correct

Thanks!
JDH

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV