Re: [PHP-DEV] New INIs, Round Three
2009/2/25 Richard Quadling rquadl...@googlemail.com: 2009/2/22 Eric Stewart ericleestew...@gmail.com: I made the following changes to the new INIs based on feedback mostly from this list. Here are the changes. 1. Changed production value of error_reporting to E_ALL ~E_DEPRECATED. 2. extension_dir is now commented in both INIs. 3. enable_dl is now set to Off in both INIs. This was not added to the Quick Reference section as PHP NEWS has this value now changed to Off as of 5.3. 4. Changed doc references that had us2.php.net to www.php.net. 5. Changed point 6 in the About php.ini section from: ; 6. Windows directory (C:\windows or C:\winnt), or --with-config-file-path ; compile time option. to: ; 6. The directory from the --with-config-file-path compile time option, or the ; Windows directory (C:\windows or C:\winnt) 6. Changed comments about Dynamic Extensions to include the addition of paths. The new comment regarding this now reads: ; If you wish to have an extension loaded automatically, use the following ; syntax: ; ; extension=modulename.extension ; ; For example, on Windows: ; ; extension=msql.dll ; ; ... or under UNIX: ; ; extension=msql.so ; ; ... or with a path: ; ; extension=/path/to/extension/msql.so ; ; If you only provide the name of the extension, PHP will look for it in it's ; default extension directory. 7. A few small grammatical and spelling mistakes have been fixed. 8. On a vote of 10 to 1. The production INI value for allow_call_time_pass_reference is now set to Off (Issue Warnings). That's all the changes made this round. You can view the revised versions at: http://wiki.php.net/rfc/newinis Please let me know if there are any other adjustments we need to make. From the looks of things, I think we are getting close to moving this RFC from Active to Accepted. So let me know what you think. Eric Lee Stewart Should extension inter-dependency of extensions be shown in the INI file. For example, mbstring must be loaded before exif and mailparse, and bz2 before bcompiler, as well as pdo before the pdo_ ; extension = php_mbstring.dll ; extension = php_exif.dll ; Requires php_mbstring.dll to be loaded before this extension ; extension = php_mailparse.dll ; Requires php_mbstring.dll to be loaded before this extension ; extension = php_bz2.dll ; extension = php_bcompiler.dll ; Requires php_bz2.dll to be loaded before this extension Also, some extensions require external libraries ... ; extension = php_ibm_db2.dll ; Requires external libraries ; extension = php_ifx.dll ; Requires external libraries ; extension = php_ingres2.dll ; Requires external libraries ; extension = php_maxdb.dll ; Requires external libraries ; extension = php_mcve.dll ; Requires external libraries ; extension = php_netools.dll ; Requires external libraries ; extension = php_oci8.dll ; Requires external libraries ; extension = php_openssl.dll ; Requires external libraries ; extension = php_oracle.dll ; Requires external libraries ; extension = php_pdo_ibm.dll ; Requires external libraries ; extension = php_pdo_informix.dll ; Requires external libraries ; extension = php_pdo_oci.dll ; Requires external libraries ; extension = php_pdo_oci8.dll ; Requires external libraries ; extension = php_pdo_pgsql.dll ; Requires external libraries ; extension = php_pdo_sqlite_external.dll ; Requires external libraries ; extension = php_pgsql.dll ; Requires external libraries ; extension = php_ssh2.dll ; Requires external libraries ; extension = php_sybase_ct.dll ; Requires external libraries ; extension = php_iisfunc.dll ; Requires external services ; extension = php_sam.dll ; Requires external services Whilst PHP4 is still present, there are some extensions which are available, but not for PHP5+ ; extension = php_db.dll ; Not available for PHP5+ ; extension = php_domxml.dll ; Not available for PHP5+ Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar update
Hello Greg, I have an AIX PPC 64 bits, IBM XL C/C++ compiler, which I can run the tests. Is it of any interest ? I read you tested on a PPC 64 already but as far as i understand you used a GNU compiler. Regards, Igor Feghali. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On Thu, Feb 26, 2009 at 1:58 PM, Rodrigo Saboya rodrigo.sab...@bolsademulher.com wrote: snip For the average PHP programmer, the language will simply get faster. That can't be bad in any way. It doesn't encourage you to write bad code, it just doesn't kick you in the nuts when you do. It's probably also worth noting that in a lot of cases, you really *won't* use a lot of what you load, at least initially. If you're working in an OOP fashion, for example, you won't use every method at once on an object, but you're still going to have to pull the whole object in to use it. If you're writing functional code, the same applies: there will often be some generic parts of stuff that you won't use for *every* request that you still won't split out into a seperate file simply because they are *often* used.. I think I'd have to guess that around 40% of the code I load gets used on a single request, but that is because of the aforementioned problem of using classes. It's not that big a worry to me, because I use APC to lessen the hit, and thankfully(? :)) I don't have thousands of r/s, just a few hundred. Seems like a good change to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Moriyoshi, Well, the only thing we could do at this point is to re-tag the release with the change delaying the release by a week. You know where I stand on the matter of the code default value, but if there is a consensus on internal that this change needs to happen, then this can definitely be done. However, looking at the past discussion on internals between Andrei and yourself I don't see anyone objecting to the current implementation, so I see no issue with proceeding as is. Let's reach a conclusion by end of day (EST time) so release can either be made or delayed. On 25-Feb-09, at 11:29 PM, Moriyoshi Koizumi wrote: In addition, I didn't insist that the whole thing should be reverted. I just argue about the default value. Moriyoshi On Thu, Feb 26, 2009 at 1:27 PM, Moriyoshi Koizumi m...@mozo.jp wrote: The issue is not whether it is valid or not. Andrei's patch broke the backwards compatibility that affects real-world applications and thus cannot be regarded as an improvement. Moriyoshi On Thu, Feb 26, 2009 at 11:51 AM, Ilia Alshanetsky i...@prohost.org wrote: Moriyoshi, My opinion is that the current implementation is valid, which is why Andrei's patch was accepted in the first place. On 25-Feb-09, at 9:34 PM, Moriyoshi Koizumi wrote: Ilia, We didn't resolve the array_unique() issue yet. Please take this into account. Moriyoshi 2009/2/25 Ilia Alshanetsky il...@php.net: iliaa Wed Feb 25 14:56:51 2009 UTC Modified files: (Branch: PHP_5_2) /php-srcconfigure.in NEWS /php-src/main php_version.h Log: 5.2.9 -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
shire wrote: http://tekrat.com/downloads/bits/apc_lazy_php53.patch You should be able to apply the above patch to the latest PHP_5_3 branch, and recompile the latest APC CVS against it. Two ini settings enable/display lazy loading: apc.lazy_functions=On/Off apc.lazy_classes=On/OFf Awesome! Alternative implementations would include replacing the function entries with an internal function that would load the opcodes when called, however I found this implementation to be problematic, still requires changes to PHP, and would also require inserting entries into the function/class tables which itself ends up being an expensive task for extremely large codebases. I still haven't given up on the executor hooks. But can't argue with code that works (yes, it works for most of my tests). I should finish up the RO patches in place so that we can catch stuff being overwritten in shm without locks - reflection, xdebug and suhosin looks like potential culprits here. Cheers, Gopal -- If I learn from my mistakes, pretty soon I'll know everything -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
On 26.02.2009 17:19, Ilia Alshanetsky wrote: Let's reach a conclusion by end of day (EST time) so release can either be made or delayed. +0 Just go ahead and release it. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
2009/2/26 Ilia Alshanetsky i...@prohost.org: Let's reach a conclusion by end of day (EST time) so release can either be made or delayed. +0 aswell, lets just release it -- Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
Gopal V wrote: shire wrote: http://tekrat.com/downloads/bits/apc_lazy_php53.patch You should be able to apply the above patch to the latest PHP_5_3 branch, and recompile the latest APC CVS against it. Two ini settings enable/display lazy loading: apc.lazy_functions=On/Off apc.lazy_classes=On/OFf Awesome! Yup, I am all for the lazy loading patch as well. I don't think people really realize how much code they load that is never run. Especially all the folks with massive front controllers. Alternative implementations would include replacing the function entries with an internal function that would load the opcodes when called, however I found this implementation to be problematic, still requires changes to PHP, and would also require inserting entries into the function/class tables which itself ends up being an expensive task for extremely large codebases. I still haven't given up on the executor hooks. But can't argue with code that works (yes, it works for most of my tests). I should finish up the RO patches in place so that we can catch stuff being overwritten in shm without locks - reflection, xdebug and suhosin looks like potential culprits here. I wouldn't worry about xdebug at all. We should probably just turn off the opcode cache part when xdebug is active if it is a problem. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar update
While trying to perform phar testing on the system previously mentioned by me, I couldn't manage to get php5.3-200902261130 to compile with IBM CC. First 3 lines of error: /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 976.3: 1506-046 (S) Syntax error. /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 1027.3: 1506-046 (S) Syntax error. /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 1137.8: 1506-166 (S) Definition of function BOOL requires parentheses. It seems that BOOL isn't getting defined. Can someone please help me ? Thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar update
Igor Feghali wrote: While trying to perform phar testing on the system previously mentioned by me, I couldn't manage to get php5.3-200902261130 to compile with IBM CC. First 3 lines of error: /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 976.3: 1506-046 (S) Syntax error. /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 1027.3: 1506-046 (S) Syntax error. /tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h, line 1137.8: 1506-166 (S) Definition of function BOOL requires parentheses. It seems that BOOL isn't getting defined. Can someone please help me ? It's a bug in PCRE that has been reported, can't find the bug report just now though, you can fix it with a compiler define for using ANSI C. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
So, in what point do you guys think of this change as valid? Moriyoshi On Thu, Feb 26, 2009 at 11:36 PM, Antony Dovgal t...@daylessday.org wrote: On 26.02.2009 17:19, Ilia Alshanetsky wrote: Let's reach a conclusion by end of day (EST time) so release can either be made or delayed. +0 Just go ahead and release it. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List 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
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi m...@mozo.jp wrote: So, in what point do you guys think of this change as valid? Moriyoshi Is there any known examples of code broken by this, or is it a more academic than practical problem? snip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Robin Burchell wrote:
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi m...@mozo.jp wrote:
So, in what point do you guys think of this change as valid?
Moriyoshi
Is there any known examples of code broken by this, or is it a more
academic than practical problem?
snip
That's indeed a practical problem.
1. array_unique() has never been supposed to handle values other than
strings. That's how bug #10658 is handled.
http://bugs.php.net/10658
See also:
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16view=markup
2. the results are inconsistent between SORT_STRING and SORT_REGULAR
when the items are a mixture of different types.
?php
$objs = array(
0x10,
16,
true,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
$objs = array(
0x10,
true,
16,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I could hardly imagine what would show up. Do you?
array(1) {
[0]=
string(4) 0x10
}
array(4) {
[0]=
string(4) 0x10
[1]=
int(16)
[2]=
bool(true)
[3]=
string(4) true
}
array(2) {
[0]=
string(4) 0x10
[3]=
string(4) true
}
array(4) {
[0]=
string(4) 0x10
[1]=
bool(true)
[2]=
int(16)
[3]=
string(4) true
}
3. the result can be unreasonable even with SORT_REGULAR
As the equality of the object is only determined by member-wise
comparison, there must be cases where the behavior is not acceptable:
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
};
$objs = array(
new Foo(1), new Foo(2e0), new Foo(2), new Foo(3)
);
var_dump(array_unique($objs, SORT_REGULAR));
?
This yields:
array(3) {
[0]=
object(Foo)#1 (1) {
[a]=
int(1)
}
[1]=
object(Foo)#2 (1) {
[a]=
string(3) 2e0
}
[3]=
object(Foo)#4 (1) {
[a]=
int(3)
}
}
while the second item is semantically not expected to be equal to the third.
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
Rasmus Lerdorf wrote: Gopal V wrote: shire wrote: http://tekrat.com/downloads/bits/apc_lazy_php53.patch You should be able to apply the above patch to the latest PHP_5_3 branch, and recompile the latest APC CVS against it. Two ini settings enable/display lazy loading: apc.lazy_functions=On/Off apc.lazy_classes=On/OFf Awesome! Yup, I am all for the lazy loading patch as well. I don't think people really realize how much code they load that is never run. Especially all the folks with massive front controllers. Thanks, I would be interested in hearing how successful it is on different setups just to validate it. I'll start making some more cleanups to the patches and more optimizations in the next month or two so hopefully we'll see some additional improvements in the code and performance. Alternative implementations would include replacing the function entries with an internal function that would load the opcodes when called, however I found this implementation to be problematic, still requires changes to PHP, and would also require inserting entries into the function/class tables which itself ends up being an expensive task for extremely large codebases. I still haven't given up on the executor hooks. But can't argue with code that works (yes, it works for most of my tests). By executor hooks do you mean actually the executor hooks in Zend, or replacing a stub in the function table like I described? I like the idea of stubbing out function table entries, but I think this makes it difficult to avoid the costs of updating the function table, I'm hoping that I can make some optimizations that cut this down so I guess we'll see in a while if I'm able to do that as it might shed some light on how much we can gain by going one way or the other etc. If you're thinking of something else (I know we discussed this before, but maybe I misunderstood), I'd like to hear the details. ;-) I should finish up the RO patches in place so that we can catch stuff being overwritten in shm without locks - reflection, xdebug and suhosin looks like potential culprits here. I thought this was awesome when I read your blog post, should be great! I wouldn't worry about xdebug at all. We should probably just turn off the opcode cache part when xdebug is active if it is a problem. I agree for the general case, in our development environment though this might cause some pains. But we could always start there and see how it goes. I agree that Xdebug isn't really a use case we always need to optimize for. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
Rasmus Lerdorf wrote: shire wrote: I agree for the general case, in our development environment though this might cause some pains. But we could always start there and see how it goes. I agree that Xdebug isn't really a use case we always need to optimize for. Is it ever a case we need to optimize for? If you are running xdebug, you aren't worried about execution speed. You certainly aren't going to be running your PHP under xdebug in any sort of production environment. I agree I don't see a case for ever using XDebug in a production environment with APC (unless you're providing some sort of developer service, and even then). Obivously the user cache needs to function as you could be debugging something related. In our development environment I'm just not sure how much additional time this will cost us in addition to xdebug. I believe it takes 6 seconds (roughly there might be other crud going on there) for us to compile all the code into opcodes for execution, so tacking this on to xdebug might cause some headaches for developers. But like I said, I think this case is pretty extraordinary, so for the sake of getting this great feture in if we need to disable this then I think I'm fine with figuring out some other solution to it should it actually be a problem at a later date. Even if I can disable this in APC then that might be enough to work around it. -shire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
On Fri, Feb 27, 2009 at 3:58 AM, Moriyoshi Koizumi m...@mozo.jp wrote:
1. array_unique() has never been supposed to handle values other than
strings. That's how bug #10658 is handled.
That's not what I really wanted to mean. I should have said not
supposed to handle values other than scalars.
Moriyoshi
http://bugs.php.net/10658
See also:
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16view=markup
2. the results are inconsistent between SORT_STRING and SORT_REGULAR
when the items are a mixture of different types.
?php
$objs = array(
0x10,
16,
true,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
$objs = array(
0x10,
true,
16,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I could hardly imagine what would show up. Do you?
array(1) {
[0]=
string(4) 0x10
}
array(4) {
[0]=
string(4) 0x10
[1]=
int(16)
[2]=
bool(true)
[3]=
string(4) true
}
array(2) {
[0]=
string(4) 0x10
[3]=
string(4) true
}
array(4) {
[0]=
string(4) 0x10
[1]=
bool(true)
[2]=
int(16)
[3]=
string(4) true
}
3. the result can be unreasonable even with SORT_REGULAR
As the equality of the object is only determined by member-wise
comparison, there must be cases where the behavior is not acceptable:
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
};
$objs = array(
new Foo(1), new Foo(2e0), new Foo(2), new Foo(3)
);
var_dump(array_unique($objs, SORT_REGULAR));
?
This yields:
array(3) {
[0]=
object(Foo)#1 (1) {
[a]=
int(1)
}
[1]=
object(Foo)#2 (1) {
[a]=
string(3) 2e0
}
[3]=
object(Foo)#4 (1) {
[a]=
int(3)
}
}
while the second item is semantically not expected to be equal to the third.
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [APC-DEV] [RFC] APC/PHP Lazy Loading
shire wrote: I agree for the general case, in our development environment though this might cause some pains. But we could always start there and see how it goes. I agree that Xdebug isn't really a use case we always need to optimize for. Is it ever a case we need to optimize for? If you are running xdebug, you aren't worried about execution speed. You certainly aren't going to be running your PHP under xdebug in any sort of production environment. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Class names (with regard to autoload)
Hi all,
I've been playing around with autoload lately, and specifically using
autoload to load classes which may be in subdirectories. I came up
with the following test script:
?php
function __autoload($sName)
{
echo autoloading . $sName . \n;
}
$s = Foo.Bar;
$a = new $s();
$b = new Foo.Bar();
?
The first line demonstrates what I'm after (autoloading Foo.Bar),
and the second seems to give a bit of an odd/incorrect (in these
circumstances) result(__autoload is invoked with Foo).
Is it possible to reconcile this behaviour to be a bit more
consistant, and provide the behaviour I'm after?
I'm willing to try provide a patch, if someone would be kind enough to
direct me to the part(s) of the engine I'd need to look at.
Thanks,
Robin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class names (with regard to autoload)
I doubt you'll find a patch to it.
Mainly, the patch will be against this principle:
?php
define('Part', 'Foo');
define('SubPart', 'Bar');
class FooBar {
// ...
}
$fb = new Part.SubPart();
Regards,
On Thu, Feb 26, 2009 at 5:27 PM, Robin Burchell virot...@viroteck.net wrote:
Hi all,
I've been playing around with autoload lately, and specifically using
autoload to load classes which may be in subdirectories. I came up
with the following test script:
?php
function __autoload($sName)
{
echo autoloading . $sName . \n;
}
$s = Foo.Bar;
$a = new $s();
$b = new Foo.Bar();
?
The first line demonstrates what I'm after (autoloading Foo.Bar),
and the second seems to give a bit of an odd/incorrect (in these
circumstances) result(__autoload is invoked with Foo).
Is it possible to reconcile this behaviour to be a bit more
consistant, and provide the behaviour I'm after?
I'm willing to try provide a patch, if someone would be kind enough to
direct me to the part(s) of the engine I'd need to look at.
Thanks,
Robin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermebla...@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class names (with regard to autoload)
2009/2/26 Robin Burchell virot...@viroteck.net
Hi all,
I've been playing around with autoload lately, and specifically using
autoload to load classes which may be in subdirectories. I came up
with the following test script:
?php
function __autoload($sName)
{
echo autoloading . $sName . \n;
}
$s = Foo.Bar;
$a = new $s();
$b = new Foo.Bar();
?
The first line demonstrates what I'm after (autoloading Foo.Bar),
and the second seems to give a bit of an odd/incorrect (in these
circumstances) result(__autoload is invoked with Foo).
Is it possible to reconcile this behaviour to be a bit more
consistant, and provide the behaviour I'm after?
I'm willing to try provide a patch, if someone would be kind enough to
direct me to the part(s) of the engine I'd need to look at.
The concatenation operator (.) is not valid in a class name. Use an
underscore and you'll be able to get the behaviour you want.
-Stuart
--
http://stut.net/
Re: [PHP-DEV] Class names (with regard to autoload)
On Thu, Feb 26, 2009 at 8:48 PM, Guilherme Blanco
guilhermebla...@gmail.com wrote:
I doubt you'll find a patch to it.
Mainly, the patch will be against this principle:
snip
Hmm, that wouldn't actually have an impact, as (at least, what I'm
aiming for/wanting to do) is not to introduce periods as valid in
actual class names, but to allow them to be used for autoloading - so
I can have something like this (abbreviated terribly, apologies):
function __autoload($sFoo)
{
include(str_replace(., /, $sFoo));
}
.. so, your example would expand to Foo.Bar, which given that periods
aren't allowed in a class name doesn't exist as a class, and won't
work. Unless I'm missing something?
Actually, I don't believe that expanding is even done - i.e. it
doesn't respect defines there
Seems that way on testing, too:
class FooBar
{
// ...
}
define('Part', 'Foo');
define('SubPart', 'Bar');
$fb = new Part.SubPart();
gives: Fatal error: Class 'Part' not found
.. but that part of things is a going off on a bit of a tangent.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class names (with regard to autoload)
I think what you're doing is effectively the same as doing:
$fb = new Part .''. SubPart();
So basically concatenating a new instance of Part, with the results
from the function SubPart. Try defining Part as a class and see what
error you get. If I'm right, you'll get an undefined function error.
2009/2/26 Robin Burchell virot...@viroteck.net:
On Thu, Feb 26, 2009 at 8:48 PM, Guilherme Blanco
guilhermebla...@gmail.com wrote:
I doubt you'll find a patch to it.
Mainly, the patch will be against this principle:
snip
Hmm, that wouldn't actually have an impact, as (at least, what I'm
aiming for/wanting to do) is not to introduce periods as valid in
actual class names, but to allow them to be used for autoloading - so
I can have something like this (abbreviated terribly, apologies):
function __autoload($sFoo)
{
include(str_replace(., /, $sFoo));
}
.. so, your example would expand to Foo.Bar, which given that periods
aren't allowed in a class name doesn't exist as a class, and won't
work. Unless I'm missing something?
Actually, I don't believe that expanding is even done - i.e. it
doesn't respect defines there
Seems that way on testing, too:
class FooBar
{
// ...
}
define('Part', 'Foo');
define('SubPart', 'Bar');
$fb = new Part.SubPart();
gives: Fatal error: Class 'Part' not found
.. but that part of things is a going off on a bit of a tangent.
--
PHP Internals - PHP Runtime Development Mailing List
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
[PHP-DEV] add scream feature to core
Hi, What's about adding what screan (http://pecl.php.net/scream) to the standard PHP? Everyone needs it and it should be possible to do that without having to install an extension. Comments/objections? Cheers -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
Moriyoshi,
First of thank you for taking the time to provide examples regarding
the issues you are demonstrating. I've looked at a number of different
applications and have not found a functionality breakage due to this
change. While your example does show a change, I am not convinced
(sorry) that it is an adverse one, type-different comparison is always
tricky and not entirely reliable and I think demonstrates more of a
corner-case situation.
I think our best option at this time is to release 5.2.9 as quickly as
possible as it introduces a number of crucial fixes and if your
comments are validated via user feedback we can adjust the values with
5.2.10 that can be repackaged fairly rapidly. IMHO the current
functionality is desired and is acceptable.
Ilia Alshanetsky
On 26-Feb-09, at 1:58 PM, Moriyoshi Koizumi wrote:
Robin Burchell wrote:
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi m...@mozo.jp
wrote:
So, in what point do you guys think of this change as valid?
Moriyoshi
Is there any known examples of code broken by this, or is it a more
academic than practical problem?
snip
That's indeed a practical problem.
1. array_unique() has never been supposed to handle values other than
strings. That's how bug #10658 is handled.
http://bugs.php.net/10658
See also:
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16view=markup
2. the results are inconsistent between SORT_STRING and SORT_REGULAR
when the items are a mixture of different types.
?php
$objs = array(
0x10,
16,
true,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
$objs = array(
0x10,
true,
16,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I could hardly imagine what would show up. Do you?
array(1) {
[0]=
string(4) 0x10
}
array(4) {
[0]=
string(4) 0x10
[1]=
int(16)
[2]=
bool(true)
[3]=
string(4) true
}
array(2) {
[0]=
string(4) 0x10
[3]=
string(4) true
}
array(4) {
[0]=
string(4) 0x10
[1]=
bool(true)
[2]=
int(16)
[3]=
string(4) true
}
3. the result can be unreasonable even with SORT_REGULAR
As the equality of the object is only determined by member-wise
comparison, there must be cases where the behavior is not acceptable:
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
};
$objs = array(
new Foo(1), new Foo(2e0), new Foo(2), new Foo(3)
);
var_dump(array_unique($objs, SORT_REGULAR));
?
This yields:
array(3) {
[0]=
object(Foo)#1 (1) {
[a]=
int(1)
}
[1]=
object(Foo)#2 (1) {
[a]=
string(3) 2e0
}
[3]=
object(Foo)#4 (1) {
[a]=
int(3)
}
}
while the second item is semantically not expected to be equal to
the third.
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
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
Re: [PHP-DEV] add scream feature to core
While a very useful feature, I think people who need it definitely will have the ability to run 2-3 commands that it takes to install a PECL extension. Ilia Alshanetsky On 26-Feb-09, at 6:28 PM, Pierre Joye wrote: Hi, What's about adding what screan (http://pecl.php.net/scream) to the standard PHP? Everyone needs it and it should be possible to do that without having to install an extension. Comments/objections? Cheers -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List 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
Re: [PHP-DEV] add scream feature to core
2009/2/26 Ilia Alshanetsky i...@prohost.org: While a very useful feature, I think people who need it definitely will have the ability to run 2-3 commands that it takes to install a PECL extension. Ilia Alshanetsky On 26-Feb-09, at 6:28 PM, Pierre Joye wrote: Hi, What's about adding what screan (http://pecl.php.net/scream) to the standard PHP? Everyone needs it and it should be possible to do that without having to install an extension. Comments/objections? Cheers -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List 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 Ilia, but us poor, useless, can't compile a shopping list, windows users need binaries. So making it core would be nice. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Anyone got 10 mins to check out http://bugs.php.net/bug.php?id=47493 for me?
Hi. Can anyone take a look at http://bugs.php.net/bug.php?id=47493 and tell me if I'm on the right track with this? Regards, Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] add scream feature to core
Compile a shopping list? How frequently are you deploying PHP? ;-) Even if you need to compile 4-5 PECL extensions its probably something you do only every few months anyway. We used to have PECL win32 binaries, I don't see them on windows.php.net, but perhaps they are else where. Based on your argument we may as well drop PECL and put all extensions into core. Ilia Alshanetsky On 26-Feb-09, at 6:40 PM, Richard Quadling wrote: Ilia, but us poor, useless, can't compile a shopping list, windows users need binaries. So making it core would be nice. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] add scream feature to core
On Fri, Feb 27, 2009 at 1:16 AM, Ilia Alshanetsky i...@prohost.org wrote: Compile a shopping list? How frequently are you deploying PHP? ;-) Even if you need to compile 4-5 PECL extensions its probably something you do only every few months anyway. We used to have PECL win32 binaries, I don't see them on windows.php.net, but perhaps they are else where. Based on your argument we may as well drop PECL and put all extensions into core. I can provide a bin for this one, that's no issue. As having this feature in the core is a non issue as well (not as an extension but in the engine). -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Anyone got 10 mins to check out http://bugs.php.net/bug.php?id=47493 for me?
Hi! I don't see any problem here - as it wouldn't have an collusion to any in-the-past-written-code. Am 27.02.2009 um 00:42 schrieb Richard Quadling rquadl...@googlemail.com : Hi. Can anyone take a look at http://bugs.php.net/bug.php?id=47493 and tell me if I'm on the right track with this? Regards, Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List 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
[PHP-DEV] PHP 5.2.9 Released!
The PHP development team would like to announce the immediate availability of PHP 5.2.9. This release focuses on improving the stability of the PHP 5.2.x branch with over 50 bug fixes, several of which are security related. All users of PHP are encouraged to upgrade to this release. Security Enhancements and Fixes in PHP 5.2.9: Fixed security issue in imagerotate(), background colour isn't validated correctly with a non truecolour image. Reported by Hamid Ebadi, APA Laboratory (Fixes CVE-2008-5498). (Scott) Fixed a crash on extract in zip when files or directories entry names contain a relative path. (Pierre) Fixed explode() behavior with empty string to respect negative limit. (Shire) Fixed a segfault when malformed string is passed to json_decode(). (Scott) Key enhancements in PHP 5.2.9 include: Added optional sorting type flag parameter to array_unique(). Default is SORT_REGULAR. (Andrei) Fixed bug #45996 (libxml2 2.7 causes breakage with character data in xml_parse()). (Rob) A number of fixes in the mbstring extension (Moriyoshi) Fixed bug #44336 (Improve pcre UTF-8 string matching performance). (frode at coretrek dot com, Nuno) Fixed bug #46699 (xml_parse crash when parser is namespace aware). (Rob) Fixed bug #46748 (Segfault when an SSL error has more than one error). (Scott) Fixed bug #46889 (Memory leak in strtotime()). (Derick) Fixed bug #47049 (SoapClient::__soapCall causes a segmentation fault). (Dmitry) Fixed bug #47165 (Possible memory corruption when passing return value by reference). (Dmitry) Fixed bug #47282 (FILTER_VALIDATE_EMAIL is marking valid email addresses as invalid). (Ilia) Fixed bug #47422 (modulus operator returns incorrect results on 64 bit linux). (Matt) Over 50 bug fixes. Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] APC/PHP Lazy Loading
On Feb 26, 2009, at 5:58 AM, Rodrigo Saboya wrote: Ronald, I think you are overreacting a little bit. It may be that proper written could would get no benefit from this patch since it would not load unneeded code and this patch ends up speeding up environments where such correct loading isn't done. I don't think that's a reason to disqualify a feature that brings benefits with no significant drawbacks. For the average PHP programmer, the language will simply get faster. That can't be bad in any way. It doesn't encourage you to write bad code, it just doesn't kick you in the nuts when you do. Sold. (The best arguments are always the short ones). As I said: I'm trying to raise a token flag of discussion/ resistance, but nobody in the discussion seems to have found any really important downsides, yet, with only me raising *any* sort of flag (though I admit it's not much of one). :) -Bop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS configure.in /main php_version.h
I'm just wondering why you appreciate the new behavior. Are there
still any positive reasons to incorporate the change? Could anyone
provide some example that the new behavior works better than the
original?
By the way, I noticed that SORT_REGULAR behaves differently than
SORT_STRING if the items are all strings.
?php
$objs = array(
0x1,
1,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
Furthermore, the code that depends on __toString() also won't work
properly anymore. It's pretty much possible that an user uses the
function for semantic comparison.
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
function __toString() {
return 1;
}
}
$objs = array(new Foo(1), new Foo(2), new Foo(3));
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I think it's where the word BC break is appropriate to describe these
situations.
Moriyoshi
On Fri, Feb 27, 2009 at 8:30 AM, Ilia Alshanetsky i...@prohost.org wrote:
Moriyoshi,
First of thank you for taking the time to provide examples regarding the
issues you are demonstrating. I've looked at a number of different
applications and have not found a functionality breakage due to this change.
While your example does show a change, I am not convinced (sorry) that it is
an adverse one, type-different comparison is always tricky and not entirely
reliable and I think demonstrates more of a corner-case situation.
I think our best option at this time is to release 5.2.9 as quickly as
possible as it introduces a number of crucial fixes and if your comments are
validated via user feedback we can adjust the values with 5.2.10 that can be
repackaged fairly rapidly. IMHO the current functionality is desired and is
acceptable.
Ilia Alshanetsky
On 26-Feb-09, at 1:58 PM, Moriyoshi Koizumi wrote:
Robin Burchell wrote:
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi m...@mozo.jp wrote:
So, in what point do you guys think of this change as valid?
Moriyoshi
Is there any known examples of code broken by this, or is it a more
academic than practical problem?
snip
That's indeed a practical problem.
1. array_unique() has never been supposed to handle values other than
strings. That's how bug #10658 is handled.
http://bugs.php.net/10658
See also:
http://cvs.php.net/viewvc.cgi/phpdoc/en/reference/array/functions/array-unique.xml?revision=1.16view=markup
2. the results are inconsistent between SORT_STRING and SORT_REGULAR
when the items are a mixture of different types.
?php
$objs = array(
0x10,
16,
true,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
$objs = array(
0x10,
true,
16,
true,
);
var_dump(array_unique($objs, SORT_REGULAR));
var_dump(array_unique($objs, SORT_STRING));
?
I could hardly imagine what would show up. Do you?
array(1) {
[0]=
string(4) 0x10
}
array(4) {
[0]=
string(4) 0x10
[1]=
int(16)
[2]=
bool(true)
[3]=
string(4) true
}
array(2) {
[0]=
string(4) 0x10
[3]=
string(4) true
}
array(4) {
[0]=
string(4) 0x10
[1]=
bool(true)
[2]=
int(16)
[3]=
string(4) true
}
3. the result can be unreasonable even with SORT_REGULAR
As the equality of the object is only determined by member-wise
comparison, there must be cases where the behavior is not acceptable:
?php
class Foo {
public $a;
function __construct($a) {
$this-a = $a;
}
};
$objs = array(
new Foo(1), new Foo(2e0), new Foo(2), new Foo(3)
);
var_dump(array_unique($objs, SORT_REGULAR));
?
This yields:
array(3) {
[0]=
object(Foo)#1 (1) {
[a]=
int(1)
}
[1]=
object(Foo)#2 (1) {
[a]=
string(3) 2e0
}
[3]=
object(Foo)#4 (1) {
[a]=
int(3)
}
}
while the second item is semantically not expected to be equal to the
third.
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
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
[PHP-DEV] Re: add scream feature to core
Pierre Joye wrote: Hi, What's about adding what screan (http://pecl.php.net/scream) to the standard PHP? Everyone needs it and it should be possible to do that without having to install an extension. Comments/objections? If it can be done easily and unobtrusively to existing code, this would be useful to me for those hard-to-catch bugs in old code. Of course, I am one of the people Ilia is referring to who can do a 3-4 second pecl install pretty easily, so I don't have a strong stake in the debate either way :) Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: add scream feature to core
On Feb 26, 2009, at 7:21 PM, Greg Beaver wrote: Pierre Joye wrote: Hi, What's about adding what screan (http://pecl.php.net/scream) to the standard PHP? Everyone needs it and it should be possible to do that without having to install an extension. Comments/objections? If it can be done easily and unobtrusively to existing code, this would be useful to me for those hard-to-catch bugs in old code. Of course, I am one of the people Ilia is referring to who can do a 3-4 second pecl install pretty easily, so I don't have a strong stake in the debate either way :) I'd rather see this as part of E_ALL, or maybe E_NOSUPPRESS (or something that sounds better). As far as the former, (E_ALL), I'd kind of actually hope that it gave me *ALL*, not just *ALL (...except suppressed errors)*. Actually, I've assumed it would. That being said, I: a) Don't mind typing a few lines to install something b) Wonder why ALL would be a limited subset of errors, with @ errors ignored. -Bop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] add scream feature to core
So, my understanding of the shut-up operator was that it temporarily set error_reporting to zero, so you could define a custom error handler that would do the equivalent simply by not honoring error_reporting = 0. Something that would be more useful, and that I don't think is implementable in PHP, would be a wrapper around all user error handlers, since userland code can override the current error handler. Cheers, Edward -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class names (with regard to autoload)
Le jeudi 26 février 2009 à 20:27 +, Robin Burchell a écrit :
I've been playing around with autoload lately, and specifically using
autoload to load classes which may be in subdirectories. I came up
with the following test script:
The best solution for you is to wait for PHP 5.3.0, then use:
function __autoload($class) {
$path = CLASSES_DIR . '/' . str_replace($class, '\\', '/', $class) .
'.class.php';
include($path);
}
Namespaces are probably the best way to achieve this (apart from using
_).
Mark
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
