Re: [PHP-DEV] PHP 5.3.0RC4
Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
On 21.06.2009, at 09:51, Lester Caine wrote: Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( Actually E_DEPRECATED is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
Lukas Kahwe Smith wrote: On 21.06.2009, at 09:51, Lester Caine wrote: Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( Actually E_DEPRECATED is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. On a production site - probably - but I see no reason to disable it on the development sites. It's all to easy to grab a bit of code and drop it in, forgetting that it's now on the 'deprecated' list. I avoid libraries that throw errors and will only work with 'display_errors=off'. If I need to use them then I will fix any errors even if 'non-fatal' before using the code in production! So before PHP5.3 is acceptable for production, any warning needs to be addressed - at least in my book. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
On 21.06.2009, at 10:24, Lester Caine wrote: Lukas Kahwe Smith wrote: On 21.06.2009, at 09:51, Lester Caine wrote: Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( Actually E_DEPRECATED is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. On a production site - probably - but I see no reason to disable it on the development sites. It's all to easy to grab a bit of code and drop it in, forgetting that it's now on the 'deprecated' list. I avoid libraries that throw errors and will only work with 'display_errors=off'. If I need to use them then I will fix any errors even if 'non-fatal' before using the code in production! So before PHP5.3 is acceptable for production, any warning needs to be addressed - at least in my book. There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its your call, but its not what we suggest. But overall there is always room for doc improvements (feel free to help out), but in the end you need to know the code or familiarize yourself with the code if you want to fix it, though per se .. there is nothing broken with the code in the current version of PHP. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
On 21.06.2009, at 10:29, Lukas Kahwe Smith wrote: On 21.06.2009, at 10:24, Lester Caine wrote: Lukas Kahwe Smith wrote: On 21.06.2009, at 09:51, Lester Caine wrote: Johannes Schlüter wrote: On Sat, 2009-06-20 at 07:49 +0100, Lester Caine wrote: While I know that ... - All ereg functions are deprecated and emit E_DEPRECATED errors. Use PCRE (preg_*()) instead. ... is accurate, I think a little more detail would help here, since many of us probably did not know that 'split' was an ereg function - for instance? hm, the las version on the wiki listed them ... In general: I'd like if people could come up with more details and add them to the docs. (See Rasmus's mail) So that this file is as short as i makes sense so people have a chance to be aware of as much contents as possible - and isn't scared away. I was probably looking more for pointers to some extra information. Part of the problem here is that the warnings are being thrown in code that *I* did not write, so then one either has to search for updated versions of a library or work out how to fix them yourself - where I'd 'borrowed' the code originally. Simply hiding E_DEPRECATED is likely to lead to even bigger blowups later? :( Actually E_DEPRECATED is only something you should enable temporarily. Then you can alert either your own team, or the project who's code you are using and move on. It simply tells you that the code will break with the next major version. This is not an end of world fatal error. On a production site - probably - but I see no reason to disable it on the development sites. It's all to easy to grab a bit of code and drop it in, forgetting that it's now on the 'deprecated' list. I avoid libraries that throw errors and will only work with 'display_errors=off'. If I need to use them then I will fix any errors even if 'non-fatal' before using the code in production! So before PHP5.3 is acceptable for production, any warning needs to be addressed - at least in my book. There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its your call, but its not what we suggest. But overall there is always room for doc improvements (feel free to help out), but in the end you need to know the code or familiarize yourself with the code if you want to fix it, though per se .. there is nothing broken with the code in the current version of PHP. Ok, guess I am wrong here. Its part of E_ALL as I suggested it when I proposed E_DEPRECATED initially. Since it seems I was the only one that considered not including it in E_ALL. That being said, for development we currently suggest: error_reporting = E_ALL | E_STRICT And for production: error_reporting = E_ALL ~E_DEPRECATED So I guess we are pushing people towards fixing deprecation issues a bit more forcefully than I thought. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for a doc push
Hi Guys and gals, in the old days we had a very close tie between the code and the documentation. As the project has grown the two have drifted apart. I think this is mostly because the phpdoc team has done an amazing job keeping up with the code changes and writing awesome documentation. This has made us a bit lazy and complacent. I would like to encourage everyone on this list to spend a little bit of time looking at the parts of the documentation that cover things you are familiar with. Or even just going through some of the doc bugs and helping out in general. This reminded me that a while ago I made some opcode documentation available in the form of a set of charts written by Andy Wharmby (http://www.zapt.info/PHPOpcodes_Sep2008.odp) and some opcode samples (http://www.zapt.info/opcodes.html) from the IBM Japan team. I don't think either of these ever made it the PHP docs and as they are still on my personal website and they are somewhat at risk :-/ I heard recently that people were using them (http://tr.im/phpcompilerinternals) so I'd like to put them somewhere more permanent. My current plan is to move them both to sp1.php.net. Does anyone object? Or better still would anyone be willing to integrate them with the PHP docs? Zoe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Results of running the entire testsuite with valgrind
I ran the entire PHP testsuite (as compiled on my system) under valgrind for Darwin and came up with quite a mess of leaks and a couple of crashes. The results file is quite ginormous, so I uploaded it to my site for the morbidly curious to have a look at: http://darkrainfall.org/php_test_results_valgrind.txt Some caveats about these results: - Darwin's valgrind doesn't support the symlink() syscall, so all tests using symlink() broke. - I didn't provide the proper environment variables for MySQL to connect, so all those tests broke too. - There seem to be several valgrind-caught bugs in OpenSSL 0.9.8k that aren't caught by valgrind's suppression files or OpenSSL's PURIFY flag, so you'll have to wade through those pointless warnings. - Two tests crashed HARD when run (with or without valgrind): ext/standard/tests/strings/str_pad_variation5.phpt (SIGBUS on NULL pointer) tests/output/ob_011.mem (SIGSEGV on unmapped non-NULL pointer) -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC4
Lukas Kahwe Smith wrote: There is a reason why E_DEPRECATED isn't part of E_ALL. Anyways, its your call, but its not what we suggest. But overall there is always room for doc improvements (feel free to help out), but in the end you need to know the code or familiarize yourself with the code if you want to fix it, though per se .. there is nothing broken with the code in the current version of PHP. Ok, guess I am wrong here. Its part of E_ALL as I suggested it when I proposed E_DEPRECATED initially. Since it seems I was the only one that considered not including it in E_ALL. That being said, for development we currently suggest: error_reporting = E_ALL | E_STRICT And for production: error_reporting = E_ALL ~E_DEPRECATED So I guess we are pushing people towards fixing deprecation issues a bit more forcefully than I thought. I must say that is does annoy me when I download a PHP package to have a look at, and since my systems all run with display_errors=on, these packages are somewhat unusable because of various warning messages. Ignoring messages like these is simply pointless - they should be handled and cleared up - which is why SOME of the decisions on what will be removed causes a lot of agro to which Just switch it off! is NOT an adequate response? We ARE expected to fix these things since that is what the people who pushed the changes through expect to happen anyway so that they can be removed quicker? :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for a doc push
2009/6/19 Rasmus Lerdorf ras...@lerdorf.com: Guys and gals, in the old days we had a very close tie between the code and the documentation. As the project has grown the two have drifted apart. I think this is mostly because the phpdoc team has done an amazing job keeping up with the code changes and writing awesome documentation. This has made us a bit lazy and complacent. I would like to encourage everyone on this list to spend a little bit of time looking at the parts of the documentation that cover things you are familiar with. Or even just going through some of the doc bugs and helping out in general. I just committed the initial migration guide for 5.3.0: http://news.php.net/php.doc.cvs/4177 Its still very raw and basiclly just a convertion of the UPGRADING file into docbook xml, if anyone find any missing things, or other changes then let them be committed so its ready for the gold release :) Personally I am going to try to make one doc commit per day for the next little while. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- regrads, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for a doc push
On Jun 21, 2009, at 6:23 AM, zoe wrote: Guys and gals, in the old days we had a very close tie between the code and the documentation. As the project has grown the two have drifted apart. I think this is mostly because the phpdoc team has done an amazing job keeping up with the code changes and writing awesome documentation. This has made us a bit lazy and complacent. I would like to encourage everyone on this list to spend a little bit of time looking at the parts of the documentation that cover things you are familiar with. Or even just going through some of the doc bugs and helping out in general. This reminded me that a while ago I made some opcode documentation available in the form of a set of charts written by Andy Wharmby (http://www.zapt.info/PHPOpcodes_Sep2008.odp ) and some opcode samples (http://www.zapt.info/opcodes.html) from the IBM Japan team. I don't think either of these ever made it the PHP docs and as they are still on my personal website and they are somewhat at risk :-/ I heard recently that people were using them (http://tr.im/phpcompilerinternals ) so I'd like to put them somewhere more permanent. My current plan is to move them both to sp1.php.net. Does anyone object? Or better still would anyone be willing to integrate them with the PHP docs? Zoe, have a look at http://news.php.net/php.doc.cvs/4180 :). I don't have anything that can read that ODP file you linked (at least, not in any useful sense), but the opcodes.html file is all there. With any luck, someone else will come along and clean it up a bit, and/or expand on it. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call for a doc push
Gwynne Raskind wrote: On Jun 21, 2009, at 6:23 AM, zoe wrote: Guys and gals, in the old days we had a very close tie between the code and the documentation. As the project has grown the two have drifted apart. I think this is mostly because the phpdoc team has done an amazing job keeping up with the code changes and writing awesome documentation. This has made us a bit lazy and complacent. I would like to encourage everyone on this list to spend a little bit of time looking at the parts of the documentation that cover things you are familiar with. Or even just going through some of the doc bugs and helping out in general. This reminded me that a while ago I made some opcode documentation available in the form of a set of charts written by Andy Wharmby (http://www.zapt.info/PHPOpcodes_Sep2008.odp) and some opcode samples (http://www.zapt.info/opcodes.html) from the IBM Japan team. I don't think either of these ever made it the PHP docs and as they are still on my personal website and they are somewhat at risk :-/ I heard recently that people were using them (http://tr.im/phpcompilerinternals) so I'd like to put them somewhere more permanent. My current plan is to move them both to sp1.php.net. Does anyone object? Or better still would anyone be willing to integrate them with the PHP docs? Zoe, have a look at http://news.php.net/php.doc.cvs/4180 :). I don't have anything that can read that ODP file you linked (at least, not in any useful sense), but the opcodes.html file is all there. With any luck, someone else will come along and clean it up a bit, and/or expand on it. http://enquirysolve.co.uk/fisheye/view_image.php?image_id=3790 Is the Opcode paper as a PDF, but it's simply an OpenOffice presentation so doesn't need anything 'expensive' to read and edit it. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: phpruntests /code-samples arrayTest.php
Hi Georg,
I notice this commit that looks like a benchmark. I'm trying to figure
out if the new run-tests rewrite overlaps with the benchmarks GSoC
project (you might not have been aware since we have the discussions
on php-qa). I wouldn't mind hearing your thoughts so that we avoid
duplicated effort.
Thanks,
Paul
On Sun, Jun 21, 2009 at 6:30 PM, Georg Gradwohlg...@php.net wrote:
g2 Sun Jun 21 17:30:46 2009 UTC
Added files:
/phpruntests/code-samples arrayTest.php
Log:
phpruntests - add arrayTest (spl-performace-test)
http://cvs.php.net/viewvc.cgi/phpruntests/code-samples/arrayTest.php?view=markuprev=1.1
Index: phpruntests/code-samples/arrayTest.php
+++ phpruntests/code-samples/arrayTest.php
?php
$size = isset($argv[1]) ? $argv[1] : 9;
// create array
$testArray = array();
for ($i=0; $i$size; $i++) {
$testArray[$i] = rand(0,9);
}
print size:\t$size\n;
flush();
// loop
$s = microtime(true);
for ($i=0; $i$size; $i++) {
if (isset($testArray[$i])) {
if ($i%2 == 0) {
$testArray[$i] = 'G';
}
}
}
$e = microtime(true);
$tl = round($e-$s, 5);
print loop:\t$tl sec (100%)\n;
flush();
// iterator
$s = microtime(true);
$testObject = new ArrayObject($testArray);
$iterator = $testObject-getIterator();
while ($iterator-valid()) {
if ($iterator-key()%2 == 0) {
$testObject[$iterator-current()] = 'G';
}
$iterator-next();
}
$e = microtime(true);
$ti = round($e-$s, 5);
$diff = round($ti/$tl*100, 0);
print spl:\t$ti sec ($diff%)\n;
print DIFF:\t.($ti-$tl). sec\n;
flush();
?
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: phpruntests /code-samples arrayTest.php
Hi Paul, thanks for the notice. To cut a long story short: we've discussed the use of the SPL-File-Iterator in the runtests-project. So I created a very simple test which passes through an array to compare the performance of the spl-iterator to a for-loop. So I think this is no overlap with the benchmark-project, it's just a small helper to alleviate our decision. Zoe, Stefan - as always - please feel free to correct my in any way. ;) But you're might interested in the results: PHP 5.3.0RC2 (cli) g2-mbp:code-samples g2$ php arrayTest.php size: loop:0.00361 sec (100%) spl: 0.02502 sec (693%) DIFF:0.02141 sec PHP 5.2.8 (cli) g2-mbp:code-samples g2$ php arrayTest.php size: loop:0.00489 sec (100%) spl: 0.76226 sec (15588%) DIFF:0.75737 sec best regards, georg Am 21.06.09 20:49 schrieb Paul Biggar unter paul.big...@gmail.com: Hi Georg, I notice this commit that looks like a benchmark. I'm trying to figure out if the new run-tests rewrite overlaps with the benchmarks GSoC project (you might not have been aware since we have the discussions on php-qa). I wouldn't mind hearing your thoughts so that we avoid duplicated effort. Thanks, Paul -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: phpruntests /code-samples arrayTest.php
Hi Georg, Thanks for the quick reply. On Sun, Jun 21, 2009 at 8:22 PM, Georg Gradwohlgeorg.gradw...@gmail.com wrote: thanks for the notice. To cut a long story short: we've discussed the use of the SPL-File-Iterator in the runtests-project. So I created a very simple test which passes through an array to compare the performance of the spl-iterator to a for-loop. So I think this is no overlap with the benchmark-project, it's just a small helper to alleviate our decision. Ah ok, I can see that. Thanks. FWIW, I consider the benchmarks to be a subproject of the run-tests framework, at least in the long run. PHP 5.3.0RC2 (cli) g2-mbp:code-samples g2$ php arrayTest.php size: loop: 0.00361 sec (100%) spl: 0.02502 sec (693%) DIFF: 0.02141 sec PHP 5.2.8 (cli) g2-mbp:code-samples g2$ php arrayTest.php size: loop: 0.00489 sec (100%) spl: 0.76226 sec (15588%) DIFF: 0.75737 sec That is interesting. Alexander is making a place for microbenchmarks, so we might copy this at some point. Thanks, Paul Am 21.06.09 20:49 schrieb Paul Biggar unter paul.big...@gmail.com: Hi Georg, I notice this commit that looks like a benchmark. I'm trying to figure out if the new run-tests rewrite overlaps with the benchmarks GSoC project (you might not have been aware since we have the discussions on php-qa). I wouldn't mind hearing your thoughts so that we avoid duplicated effort. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3.0 stable release
Hi, It looks like nothing critical has popped up since RC4. So it looks like we will be sending the final stable release to the mirrors next Wednesday and announce the release on Thursday barring any critical issues emerging in the next days. In the mean time test test test. If issues are found/fixed please send the patches to internals for review. Based on the importance and risk of the patch will then be applied, however the next 2 days should really be focused on testing to make sure we do not have critical issues, minor issues can always be fixed in 5.3.1 and we better release with known minor issues than big unknown issues caused by a last minute fix. Another focus area should be the migration guide and other documentation updates: http://docs.php.net/migration53 regards, Johannes and Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.3.0 stable release
Hi, It looks like nothing critical has popped up since RC4. So it looks like we will be sending the final stable release to the mirrors next Wednesday and announce the release on Thursday barring any critical issues emerging in the next days. In the mean time test test test. If issues are found/fixed please send the patches to internals for review. Based on the importance and risk of the patch will then be applied, however the next 2 days should really be focused on testing to make sure we do not have critical issues, minor issues can always be fixed in 5.3.1 and we better release with known minor issues than big unknown issues caused by a last minute fix. Another focus area should be the migration guide and other documentation updates: http://docs.php.net/migration53 regards, Johannes and Lukas Johannes and Lukas, Did you hear about crashes under Solaris and MacOSX, and compiler failures under all *BSD systems? They were posted against RC3 and the problems are still the same in RC4. Affected systems: Solaris 8, FreeBSD 6, NetBSD 3, OpenBSD 4, MacOSX/Darwin (unknown, per http://darkrainfall.org/php_test_results_valgrind.txt) As the VERY least, you may want to mention gcc version that the sources are compatible with and platforms the resulted binaries won't run. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
