pychecker-list

[PyChecker-list] buildbots

[Thomas V. S. <th...@ap...>]

I haven't fixed anything in pychecker lately because I have a known bug
I want to fix, and before I did so I wanted to set up some buildbots.

Ok, well, that part of the yak shave has started, so I give to you:

http://build.fluendo.com:8200/

There's 5 builders right now.  It's not super-useful yet since:

- you don't obviously see what python version they run
- we don't cover all python versions yet

However, I have some other scripts that set up different python
versions, and then I will add some builders for all useful python
versions.

After that, I still need to integrate with cvs hooks to send out mails
and trigger builds.

And after that, I can fix the actual darn bug I have on my plate :)

Enjoy,

Thomas

-- 
I willed myself to become a machine whose product was distance.
--
savon - Saving your work to svn
https://apestaart.org/thomas/trac/

Re: [PyChecker-list] buildbots

[Thomas V. S. <th...@ap...>]

Hi,

some followup:

> There's 5 builders right now.  It's not super-useful yet since:
> 
> - you don't obviously see what python version they run
> - we don't cover all python versions yet

Ok, I set up my jhbuild build scripts to build 3 python versions on one
of the slaves (2.3, 2.4, 2.5)

I still need to set up a 2.6 one somewhere.

> After that, I still need to integrate with cvs hooks to send out mails
> and trigger builds.

This still needs doing.  On the plus side, it seems anoncvs on sf now
syncs immediately, so that's good.

Additionally, I wrote a quick parser for the TESTS FAILED: line at the
end, so the builders report how many tests failed.  This should make it
easier to track when we actually go back to fixing those failures and
make sure we fix them across all python versions.

Suggestions welcome!
Thomas

-- 
too tired to eat
too hungry to sleep
--
MOAP - Maintaining your projects since 2006
https://apestaart.org/moap/trac/

Re: [PyChecker-list] buildbots

[Thomas V. S. <th...@ap...>]

Hi,

(starts feeling like an echo in here :))

> Ok, I set up my jhbuild build scripts to build 3 python versions on one
> of the slaves (2.3, 2.4, 2.5)
> 
> I still need to set up a 2.6 one somewhere.

Done now.

> > After that, I still need to integrate with cvs hooks to send out mails
> > and trigger builds.

Done too.  Also, fixed a small bug where test runs on the same machine
overwrote the other tests.  Now I seem to get consistent build results,
and here are the scores:

2.6: 16 failures
2.5: 12 failures
2.4: 6 failures
2.3: 8 failures

I'm thinking atm it would be nice to make a test matrix, but since the
goal is to fix all tests, then keep them fixed, this may not be so
useful.

Thomas

-- 
Be a blanket for my bones
be a place that I call home
--
savon - Saving your work to svn
https://apestaart.org/thomas/trac/

Re: [PyChecker-list] buildbots

[Thomas V. S. <th...@ap...>]

Continuing on my cleanup path...

> 2.6: 16 failures
> 2.5: 12 failures
> 2.4: 6 failures
> 2.3: 8 failures

What I'm focussing on so far is to bring all python versions on par with
the one with the lowest failures, 2.4

I've first brought back 2.6 to the same failures as 2.5; basically, all
new failures were due to the way BUILD_MAP has changed and can now take
a numeric argument to presize the dict.  This argument however is not
the number of items to consume from the stack.

Fixing that bug in pychecker made failures for 2.6 the same as for 2.5

As for between 2.5 and 2.4, I'm going over each of them and figuring out
what happened.  A few have been fixed simply because Python 2.5
introduced code generator optimizations that optimize the problematic
code away before pychecker has a change to get at it; examples:

55555 % 1 gets replaced with the constant 1
~~(10) (double negation) gets replaced with 10

Since pychecker has no way of knowing what the code was like before it
got constified, there's no way to warn about it afaict.  (Please correct
me if I'm wrong here).  So in those cases, I created a new expected
results file, removing the warnings.

At least one of the differences I will need more help on, but for now
the score is:

2.6/2.5: 9
2.4: 6
2.3: 8

I have to say I feel a lot more comfortable changing tricky python code
with these buildbots around to check all python versions for me...

Thomas

-- 
P.S. You rock my world
--
savon - Saving your work to svn
https://apestaart.org/thomas/trac/

Re: [PyChecker-list] buildbots

[Barry S. <ba...@ba...>]

Are you still planning to work on pychecker and fix problems?

I have some patches for pychecker on 2.6 but I need help to understand
how to fix some harder problems.

It seems that the python compiled code has changed in ways that trip up
pychecker. For example the code to figure out error in the use of format
strings reports warning show some perfectly good code. (No I cannot break
it in a small example - only in huge examples that I cannot make public).

Barry


On 30 Sep 2009, at 15:37, Thomas Vander Stichele wrote:

> Continuing on my cleanup path...
> 
>> 2.6: 16 failures
>> 2.5: 12 failures
>> 2.4: 6 failures
>> 2.3: 8 failures
> 
> What I'm focussing on so far is to bring all python versions on par with
> the one with the lowest failures, 2.4
> 
> I've first brought back 2.6 to the same failures as 2.5; basically, all
> new failures were due to the way BUILD_MAP has changed and can now take
> a numeric argument to presize the dict.  This argument however is not
> the number of items to consume from the stack.
> 
> Fixing that bug in pychecker made failures for 2.6 the same as for 2.5
> 
> As for between 2.5 and 2.4, I'm going over each of them and figuring out
> what happened.  A few have been fixed simply because Python 2.5
> introduced code generator optimizations that optimize the problematic
> code away before pychecker has a change to get at it; examples:
> 
> 55555 % 1 gets replaced with the constant 1
> ~~(10) (double negation) gets replaced with 10
> 
> Since pychecker has no way of knowing what the code was like before it
> got constified, there's no way to warn about it afaict.  (Please correct
> me if I'm wrong here).  So in those cases, I created a new expected
> results file, removing the warnings.
> 
> At least one of the differences I will need more help on, but for now
> the score is:
> 
> 2.6/2.5: 9
> 2.4: 6
> 2.3: 8
> 
> I have to say I feel a lot more comfortable changing tricky python code
> with these buildbots around to check all python versions for me...
> 
> Thomas
> 
> -- 
> P.S. You rock my world
> --
> savon - Saving your work to svn
> https://apestaart.org/thomas/trac/
> 
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> PyChecker-list mailing list
> PyC...@li...
> https://lists.sourceforge.net/lists/listinfo/pychecker-list

Re: [PyChecker-list] buildbots

[Thomas V. S. <th...@ap...>]

Hi Barry,

> Are you still planning to work on pychecker and fix problems?

I never plan, it happens when I get in the mood or run into some bug.

> I have some patches for pychecker on 2.6 but I need help to understand
> how to fix some harder problems.

Ok, feel free to share.

> It seems that the python compiled code has changed in ways that trip up
> pychecker. For example the code to figure out error in the use of format
> strings reports warning show some perfectly good code. (No I cannot break
> it in a small example - only in huge examples that I cannot make public).

Hm, that's going to be hard to figure out then if we can't make it
reproducable.  Can you share the code with me for example ?

Thomas

-- 
Can we, like, have a dude conversation ?
I'm begging here !
--
Flumotion - the only way to stream!
http://www.flumotion.net/

Re: [PyChecker-list] buildbots

[Barry S. <ba...@ba...>]

On 25 Apr 2010, at 18:49, Thomas Vander Stichele wrote:

> Hi Barry,
> 
>> Are you still planning to work on pychecker and fix problems?
> 
> I never plan, it happens when I get in the mood or run into some bug.
> 
>> I have some patches for pychecker on 2.6 but I need help to understand
>> how to fix some harder problems.
> 
> Ok, feel free to share.

I'll prep a set of patches for the problems I have already fixed and post
here.

> 
>> It seems that the python compiled code has changed in ways that trip up
>> pychecker. For example the code to figure out error in the use of format
>> strings reports warning show some perfectly good code. (No I cannot break
>> it in a small example - only in huge examples that I cannot make public).
> 
> Hm, that's going to be hard to figure out then if we can't make it
> reproducable.  Can you share the code with me for example ?

I cannot share the code, its (1) big and (2) my boss will not allow it
to be published.

I have been instrumenting the pychecker code to find out where the
format string bug is. I have it isolated to a single function. I can share
my debugging and hope that together we can figure out what to change.

Barry