Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60613
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
Message-ID: <4FB8B927.9070602@gmail.com>
Date: Sun, 20 May 2012 10:28:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Felipe Pena <felipensp@gmail.com>, internals@lists.php.net, 
 "qa >> PHP QA" <php-qa@lists.php.net>
References: <4FB4E844.2070305@gmail.com> <CA+5g0SL5xkd7EOY5FJ6m=aa7_KERLQUKEL=T5axN0OMOe2GRzg@mail.gmail.com>
In-Reply-To: <CA+5g0SL5xkd7EOY5FJ6m=aa7_KERLQUKEL=T5axN0OMOe2GRzg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-QA] Parallel run-tests
From: aparachic@gmail.com (zoe slattery)

On 19/05/2012 22:33, Felipe Pena wrote:
> Hi Zoe,
>
> great work on this new run-tests! :D
>
> I was testing it and noticed a problem when running using the following command:
> $ ~/dev/php5_4/sapi/cli/php run-tests.php  -z 8 -p
> ~/dev/php5_4/sapi/cli/php ~/dev/php5_4/
>
> It shows the PHP messages:
> [...]
> Fatal error: Call to undefined function gzencode() in
> /home/felipe/dev/phpruntests/src/testcase/sections/configurationsections/rtGzipPostSection.php
> on line 23
> [...]
Thanks for that - couple of questions:

1) Is your ~/dev/php5_4/sapi/cli/php  built --with-zlib?
2) This test uses the php-cgi, are you setting it with an env variable? 
Or relying on run-tests.php to find it (it should do that)

Even if it is missing zlib function that is causing the initial error, 
this should be caught by a SKIPIF section. There is only one test (as 
far as I know) that uses GZIP_POST, this is ext/soap/tests/server019.phpt.

Would you be able to run that test on its own and send me the output? I 
think this should do it:

~/dev/php5_4/sapi/cli/php run-tests.php -p ~/dev/php5_4/sapi/cli/php ~/dev/php5_4/ -vvv ~/dev/php5_4/ext/soap/tests/server019.php

  
Thanks, Zoe


> Notice: Undefined offset: 0 in
> /home/felipe/dev/phpruntests/src/testcase/rtTestDifference.php on line
> 91
> Fatal error: Allowed memory size of 134217728 bytes exhausted at
> /home/felipe/dev/php5_4/Zend/zend_hash.c:330 (tried to allocate 81
> bytes) in /home/felipe/dev/phpruntests/src/testcase/rtPhpTestFile.php
> on line 108
> /home/felipe/dev/php5_4/Zend/zend_hash.c(551) : ht=0x7f96e6356a50 is
> inconsistent
> [...]
> Fatal error: Allowed memory size of 134217728 bytes exhausted at
> ext/standard/var_unserializer.re:290 (tried to allocate 32 bytes) in
> /home/felipe/dev/phpruntests/src/taskScheduler/rtTaskSchedulerFile.php
> on line 183
>
>
>
> 2012/5/17 zoe slattery<aparachic@gmail.com>:
>> Hi
>>
>> Over the past couple of weeks I have updated the parallel run-tests (fixed a
>> couple of minor bugs in the PHP code and the build.xml), it's now almost at
>> the point where I could go ahead and implement the last pieces.  Here is a
>> summary and a few questions:
>>
>> 1. In rebasing the code the the dev't stream I found a number of tests with
>> non-standard sections. My code checks test case structure and objects to
>> anything non-standard, the current run-tests.php mainly ignores this kind of
>> thing. I fixed up about 15 of these tests (see #62022) already - I'll fix
>> the rest if there are no objections - I will open another bug report first.
>>
>> 2. If there is agreement to use this code it would make sense to replace
>>   the existing run-tests code with it, or rather,  it would make no sense to
>> try and maintain both versions. The new code is OO PHP, it's in
>> http://git.php.net/repository/phpruntests.git, is there any problem with it
>> staying there long term and maybe copying a run-tests.phar into the PHP
>> source directory? I have no idea what the right answer is, suggestions
>> welcome.
>>
>> 3. I ran a couple of small tests on my dual core Mac yesterday. For a
>> standard set of tests, the parallel code ran in 207 seconds, sequential in
>> 293 seconds and the standard run-tests.php took 298 seconds. This is an
>> improvement but I suspect we could still do better by looking at the
>> scheduling algorithm.
>> At the moment it's very simple, we just assemble a list of directories with
>> tests in and hand them out to processors till everything is done. Being able
>> to handle tests that must be run in sequence (mysql, mysqli) will mean
>> making some changes to this. So, perhaps we give an explicit list to p1 and
>> let the scheduler distribute the rest of the tests? Or maybe we should have
>> a 'process map' for all tests for extensions that are build by default?
>> Again, suggestions welcome.
>>
>> 4. REDIRECTTEST still needs to be implemented, I understand how it works and
>> this isn't (afaict) a major issue.
>>
>> 5. Testing. I'm able to do basic testing on Mac OSX  and Linux. I really
>> need access to an 8 way Linux system, or someone who has access and would be
>> interested in looking at performance? Any volunteers? This is probably the
>> most interesting part of the project :-)
>>
>> 6. Windows. I'm not in a position to do anything much with Windows except
>> some very basic checks to make sure that the sequential version runs. The
>> parallel code won't work because we used pcntl(), however I know that Stefan
>> and George were keen to design the code so that a Windows solution could be
>> implemented if anyone thought of one. If anyone wants to pick up this aspect
>> I'd be happy to get them started.
>>
>> Zoe
>>
>> --
>> PHP Quality Assurance Mailing List<http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>