matplotlib-devel Mailing List for matplotlib

2010/6/15 Olle Engdegård <oen...@gm...>:
> The autoscaling might need a small fix for
>
> hist(rand(100),bins=20,histtype="step",log=1)

I just had a look at trunk (8623), and the lower y-limit looks good
now. The above problem was at rev 8475.

But an old, different, bug has turned up instead: Using "stepfilled"
you get a diagonal lower boundary:

a=[3,3,3,3,3,3,3,3,3,3,4,4,4,4,4,4,4,4,5,5,5,5,5,5,6,6,6,6]
hist(a, range=(0,10), bins=10, histtype="stepfilled", log=True)

Cheers,
Olle

On 08/03/2010 07:53 PM, Andrew Straw wrote:
> On 8/1/10 7:11 PM, Eric Firing wrote:
>> On 07/31/2010 08:51 PM, Andrew Straw wrote:
>>
>>> Hi MPL devs,
>>>
>>> I think I've fixed a long-standing issue we've had with the buildbot
>>> where sometimes a false alarm was issued when two tests stepped on each
>>> others' toes. Specifically, I've fixed up the MPL buildbot environment
>>> on the virtual machine that runs both the Python 2.4 and 2.5 tests so
>>> that these tests are run from different MPLCONFIGDIRs.
[...]
>> 2) Can the bug be closed now?
>>
>>
> Yes, I closed it.

Thank you--and more importantly, thanks for all the buildbot work.

Eric

On 8/1/10 7:11 PM, Eric Firing wrote:
> On 07/31/2010 08:51 PM, Andrew Straw wrote:
>    
>> Hi MPL devs,
>>
>> I think I've fixed a long-standing issue we've had with the buildbot
>> where sometimes a false alarm was issued when two tests stepped on each
>> others' toes. Specifically, I've fixed up the MPL buildbot environment
>> on the virtual machine that runs both the Python 2.4 and 2.5 tests so
>> that these tests are run from different MPLCONFIGDIRs.
>>      
> Andrew et al,
>
> https://sourceforge.net/tracker/?func=detail&aid=2856125&group_id=80706&atid=560720
>
> Please see my comment in the above bug ticket.  I'm curious about three
> things:
>
> 1) Would the solution I suggested in that comment also have worked?  If
> so, would it be more robust against future changes in the buildbot, or
> the creation of new buildbots?  Or was I misunderstanding where the
> buildbot code comes from, and how it works?
>    
Your comment on the tracker was:

> Having two buildbot processes
> accessing, and potentially writing to, the same cache file(s) partly
> defeats the purpose of the buildbot: testing independent builds
> independently, on a variety of systems.

The fact that we have two simultaneous build/test cycles happening on 
one test system is simply a result of the way I configured the buildbot. 
(I'm running a Python 2.4 and Python 2.5 interpreter simultaneously on 
the same machine.) I wouldn't call it a failure of the buildbot software 
at all.

The solution you proposed in the comment was close to what I 
implemented. The difference is I didn't use tempfile.mkdtemp but just 
fixed the value per buildbot slave.

> 2) Can the bug be closed now?
>
>    
Yes, I closed it.

>> So, from now on, all emails from the buildbot should be taken seriously.
>>      
> 3) What about the failure that occurred after your 8609 commit?
If you look at the log, that was because there was trouble downloading 
pygments. (I should disable networking on the build slaves, but 
haven't...) The next build didn't have that issue.

>    It
> looks like the scons build is not being run, but it's last failure (in
> November) is still triggering the email.  Correct?
>    
No, the buildbot is currently configured only to send a single email on 
the transition from OK -> failure for a given slave. So there was one 
email sent about this, but shouldn't be any more.

So, again,  we can take all emails from the buildbot seriously.