[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (75 total -- which includes 32 feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers ===[Apache related]=== 47061 Open User not logged under Apache ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = On ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[Class/Object related]= 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[COM related]== 45836 Open cannot use com 46909 Open COM object not allowing calls to methods ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 ===[Date/time related] 46948 Assigned ext/date/lib/parse_tz.c:99: Memory leak: buffer ===[Filesystem function related]== 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 46688 Open Return values differ from 5.3 and are also inconsistent 46689 Open Downcoded notices suggest unfinished code in file system? ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[mbstring related]= 44868 Open Replaces UTF-8 symbol with incorrect symbol ===[mcrypt related]=== 46834 Assigned Range of mcrypt functions fail on PHP 6.0 ===[MySQL related] 44076 Open mysql_result returns nothing with blob 45246 Open make error after ./configure --with-mysql ===[ODBC related]= 39756 Open Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Assigned openssl_pkey_get_public() fails when given a private key ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Regexps related]== 44923 Open ereg functions are not unicode aware: provide wrapper functions in PCRE ===[Reproducible crash]=== 45107 Open setting ext_dir to ./ (and other ini settings) causes apache crash ===[Scripting Engine problem]= 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe 47154 Open Object properties unset after setting. ===[Session related]== 44860 Open session_encode() fails for php_binary serializer ===[Strings related]== 45566 Open Strict comparision on $_SERVER values fail ===[Unicode Engine related]=== 45087 Open Illegal or truncated character in input 47155 Open PHP 6.0 decodes base64 into incorrect uft-8 string 47164 Assigned uncomfortable (binary)char() append to binary string ===[URL related]== 45602 Open urlencode/urldecode should use ASCII encoding ===[XSLT related]= 38218 Assigned php:functionString tries to access objects with their names in lowercase
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/stan ... Deprecate ticks, pcntl_signal affected?
On Mon, Feb 23, 2009 at 12:23, James Dempster letss...@gmail.com wrote: 2008/7/28 Antony Dovgal t...@daylessday.org On 26.07.2008 02:48, Markus Fischer wrote: Hi, [CCing interested parties based on the last mail exchange on this topic] will the deprecation of ticks affect the usage of pcntl_signal? The manual says [1] ... As of PHP 4.3.0 PCNTL uses ticks as the signal handle callback mechanism Current practice requires to declare(ticks = 1); for pcntl_signal to work. No ticks, no signal handling? That's right. That's exactly why I don't see how we can deprecate ticks without introducing a replacement. What was the outcome of this? http://php.markmail.org/message/qxjxtmm77odcnqhy I think these functions are also documented already. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
Ronald Chmara wrote: On Feb 21, 2009, at 10:55 PM, shire wrote: Hi Ronald, Ronald Chmara wrote: Wait... so if I understand this right, let's envision a code base where, per some random page load, 70 functions are actually called, but, oh, 7,000, or even 700,000, are being included for whatever reason? The speed optimization is in *not* copying a massive amount of things that weren't even needed, or used, in the first place? Essentially, yes, this is probably best summed up by the 80/20 rule where we only use 20% of the code etc... Well, I can see 80% actually *used* code, with 20% in there by accident but 80% unused code? eep! ack! Call the villagers and get the torches and pitchforks!... I should probably be more specific, it's not that you *don't* use the other 80% it's that you use 20% of the code 80% of the time: http://en.wikipedia.org/wiki/Pareto_principle Of course I'm abusing this slightly, but this is the *basic* idea, and it's not based on actual usage statistics. In reality you probably use all 100% of your code in smaller chunks depending on the request. As an illustrative example, if you have HTTP requests for setting, retrieving, deleting items in a database which is supported by corresponding functions. In each request you'll only use one of these functions (30%), but you'll still need to load the entire file/class. The goal of lazy loading is to optimize this and similar situations so you don't have to re-organize your code into unfeasibly small files, or in other ways that might inhibit productivity. One thing I see as quite a beneficial future outcome of your work is the ability to further profile code, and be able to seek out code that marks massive amounts of functions as available without actually ever using them. I think this would be better instrumented through tools actually designed to do this sort of profiling, specifically XDebug, or tools like inclued are very useful. http://pecl.php.net/package/xdebug http://pecl.php.net/package/inclued It's actually likely that only a fraction of the code at Facebook will be used in a request, hence the need for lazy loading. Ouch. Seriously. I can't tell you how to build your code, but I think you might seriously benefit from: Does that make sense? Or did you try it already? :) I'd rather not enter into a public discussion of Facebook's current optimization tactics outside of this patch, but suffice to say we have implemented many optimization techniques, both in PHP code and Internals, many of which we have and will continue to contribute back to the community. Lazy Loading has been a very necessary and optimal solution to this one aspect of our scalability, thus allowing our engineers to focus more of their time and energy on creating new and exciting features for Facebook. Thanks, -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zend_call_method() - support for up to 4 parameters
Hello Pierre, Saturday, February 21, 2009, 2:46:01 PM, you wrote: On Sat, Feb 21, 2009 at 1:05 PM, Marcus Boerger he...@php.net wrote: Hello Pierre, Thursday, February 19, 2009, 12:22:41 PM, you wrote: hi, On Thu, Feb 19, 2009 at 11:57 AM, Johannes Schlüter johan...@php.net wrote: ps. I'm aware of the fact that we added some specific APIs in special cases in bug fix releases before, but there's a difference between adding APIs and breaking the ABI of existing, used, stuff. Exactly. To summarize: x.y.z to x.y.z+1: ABI and API must be 100% compatible x.y.z to x.y+1.z: ABI can be broken (need a recompilation), API must be 100% compatible x.y.z to x+1.y.z: party time ;) That's completely untrue. In your mind maybe, but if we do not follow these simple rules then we have a serious problem. What we ensure is that function f introduced in x.y.z stays in all verisons x.y.z+n and keeps its exact semantics. We have been wrong in the past and changed API between minor version, it was a major mistake. In the meantime, we have tried to do not do it again. x.y.z and x.y.y+1 has not only have to keep the same sematic, behaviors but also the same signatures as well as a binary compatibility. One bad example was a change we made in 5.2.x making it incompatible with previous versions, there was no version id chante and it was a pain to change the extensions to be compatible with the full 5.2.x serie. The worst is that I can't even figure out when it happens without looking at the code (maybe 5.2.5? :) What we did not ensure ever, is that version x.y.z+1 does not come with a function g that did not exist in x.y.z. That's no problem, as long as the x.y.z+1 API is 100% compatible with x.y.y. New functions do not break existing functions signature or behaviors, obviously. Same obviously applies to consts and yes macros, which have nothing to do abi or api. And actually abi has nothing to do with the whole discussion. The ABI influences how a binary gets layout, ABI has to do with the discussions as a given binary has to work across the same minor versions. It causes the same problem but with different origins. and in that way determines how a user of said binary can access the API elements (consts, function, classes,...). This obviously affects DLLs on windows and shared objects on *nix. Either way, adding more macros and new functions is fine, as lone as we do not change any existing function protocol. Exactly what I said. New functions do not break the API and it is possible to modify a struct without breaking existing binary compatibility. And so what are you writing here? I explained to him the exact terms under which he can add the function. And his patch actually followed these terms as far as I could see. The new patch is clean enough to me and doesn't change the API. Whether the ABI changes depends on the compilers and linkers. My comment was a general comment on what should be the policy, not specifically about this patch :) All in all it seems that you are saying the same than I did, only with different wording :) erm, oh right :-) Cheers, Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] How to contribute a new extension?
Hi, I'm one of the developers in the SELinux. I have an extension of PHP to provide interfaces to communicate with SELinux, and would like to propose them to the official PHP. Now I'm looking for informations about steps to propose a new extension. Could someone point to me? I could not find introductions to submit patches. :( The following pages show specifications and implementations that I would like to propose: http://code.google.com/p/sepgsql/wiki/Memo_PHP_SELinux http://code.google.com/p/sepgsql/source/browse/misc/php-selinux/ But I'm not clear for what should I do in the next. - What is the correct list to submit a patch? - What base version of PHP should I make a patch toward? - What facilities are necessary except for the code? (I guess documentation and testcases are required.) - Who can admit the patch inclusion? Sorry, I'm not good at development cycle in this community... Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute a new extension?
Hello KaiGai, Tuesday, February 24, 2009, 6:11:02 AM, you wrote: Hi, I'm one of the developers in the SELinux. I have an extension of PHP to provide interfaces to communicate with SELinux, and would like to propose them to the official PHP. Now I'm looking for informations about steps to propose a new extension. Could someone point to me? I could not find introductions to submit patches. :( The following pages show specifications and implementations that I would like to propose: http://code.google.com/p/sepgsql/wiki/Memo_PHP_SELinux http://code.google.com/p/sepgsql/source/browse/misc/php-selinux/ But I'm not clear for what should I do in the next. - What is the correct list to submit a patch? - What base version of PHP should I make a patch toward? - What facilities are necessary except for the code? (I guess documentation and testcases are required.) - Who can admit the patch inclusion? Sorry, I'm not good at development cycle in this community... Nice. Now to get your work into PHP you need to propose it to PELC (PHP Extension Community Library). To do so follow here: http://pecl.php.net/account-request.php Normally those extensions are developed with the their source in th epecl repository, thus you need a CVS account. Also note that we have restrictions on the possible licenses. marcus Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute a new extension?
Marcus Boerger wrote: Hello KaiGai, Tuesday, February 24, 2009, 6:11:02 AM, you wrote: Hi, I'm one of the developers in the SELinux. I have an extension of PHP to provide interfaces to communicate with SELinux, and would like to propose them to the official PHP. Now I'm looking for informations about steps to propose a new extension. Could someone point to me? I could not find introductions to submit patches. :( The following pages show specifications and implementations that I would like to propose: http://code.google.com/p/sepgsql/wiki/Memo_PHP_SELinux http://code.google.com/p/sepgsql/source/browse/misc/php-selinux/ But I'm not clear for what should I do in the next. - What is the correct list to submit a patch? - What base version of PHP should I make a patch toward? - What facilities are necessary except for the code? (I guess documentation and testcases are required.) - Who can admit the patch inclusion? Sorry, I'm not good at development cycle in this community... Nice. Now to get your work into PHP you need to propose it to PELC (PHP Extension Community Library). To do so follow here: http://pecl.php.net/account-request.php Marcus, Thanks for your information. I'll get a start from announcement of SELinux extensions on the pecl-dev list. I guess the module name of selinux will be acceptable for people. Normally those extensions are developed with the their source in th epecl repository, thus you need a CVS account. Also note that we have restrictions on the possible licenses. I've not determined the license of the extension, so we can choose the most preferable one (PHP license 3.0). Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Don't compress empty output with zlib
CC'ed authors of zlib.c
Could this patch be applied to PHP_5_2 and further?
Index: ext/zlib/zlib.c
===
RCS file: /repository/php-src/ext/zlib/zlib.c,v
retrieving revision 1.183.2.6.2.8
diff -u -r1.183.2.6.2.8 zlib.c
--- ext/zlib/zlib.c 31 Dec 2008 11:17:47 - 1.183.2.6.2.8
+++ ext/zlib/zlib.c 17 Feb 2009 22:13:40 -
@@ -979,7 +979,7 @@
{
zend_bool do_start, do_end;
- if (!ZLIBG(output_compression)) {
+ if (!ZLIBG(output_compression) || SG(sapi_headers).http_response_code
== 304) {
*handled_output = NULL;
} else {
do_start = (mode PHP_OUTPUT_HANDLER_START ? 1 : 0);
Cheers,
Edward
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
