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<aparac...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
