RE: [PHP-DEV] 5.2.4RC1 Released
Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: ... checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files ./configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: ... configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- 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] 5.2.4RC1 Released
Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today Ilia please can you make sure that the bug http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1 state for 5.2.4 - as it currently stands it is causing problems. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ 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] 5.2.4RC1 Released
Hello again, got it configured on Solaris with bash configure The following two things are problematic: 1) @-operator before function names does not suppress warning messages anymore? Whats wrong? I got for example messages like cannot open file... even when it was opened with @fopen(...). 2) make test is broken: [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ gmake test Build complete. Don't forget to run 'make test'. /bin/sh: syntax error at line 1: `;' unexpected gmake: [test] Error 2 (ignored) - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- 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] 5.2.4RC1 Released
On 03.08.2007 11:48, Lester Caine wrote: Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today Ilia please can you make sure that the bug http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1 state for 5.2.4 - as it currently stands it is causing problems. Lester, why don't you just try and fix it? Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). I can even tell you which lines were changed since 5_1: http://cvs.php.net/viewvc.cgi/php-src/ext/interbase/ibase_blobs.c?r1=1.13r2=1.9.2.2 -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: Ext/OpenSSL patch
Hi Stas, Thank you for catching this. I fixed it locally. Dmitry. -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 3:19 AM To: Dmitry Stogov Cc: Wez Furlong; Sara Golemon; Andi Gutmans; Zeev Suraski; internals@lists.php.net Subject: Re: Ext/OpenSSL patch Sounds good. Couple of notes: 1. Functions seem to lack prototypes except for encrypt which says: Returns an array of the fields/values of the CERT - obviously it's some mistake :) 2. openssl_encrypt says Unknown signature algorithm. when it should be encryption algorithm I guess... And the final period isn't needed I think. The same for decrypt. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_ini.h
Stanislav Malyshev schrieb: stas Thu Aug 2 23:57:21 2007 UTC Modified files: (Branch: PHP_5_2) /ZendEngine2 zend_ini.h Log: add stage for .htacces This change is great. However are there any plans to add a symbol or something else so that a PHP extension can detect the support for this feature at runtime? I see that this feature will be backported to older PHP 5 and even to PHP 4 used by linux/bsd distributions, because it is a required security fix. For extension developers this will be a problem unless there is some means of runtime detection, because the same PHP 4.4 extension is supposed to work with and without the fix (without recompilation). Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Ext/OpenSSL patch
So even Zend has abandoned PHP 6 development? :D And here I thought HEAD was meant for active development and you just MFH to any active branch were certain stuff goes.. Anyway, it's about new features, those must wait for 5.3. --Jani On Fri, 2007-08-03 at 13:43 +0400, Dmitry Stogov wrote: I won't applay it to HEAD without php-5. I need it in php-5. HEAD may wait. Thanks. Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:21 PM To: Dmitry Stogov Cc: Stanislav Malyshev; Wez Furlong; Sara Golemon; Andi Gutmans; Zeev Suraski; internals@lists.php.net Subject: Re: [PHP-DEV] RE: Ext/OpenSSL patch On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: Hi Stas, Thank you for catching this. I fixed it locally. Can you not apply the patch to HEAD already? :) Cheers, --Pierre -- 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] 5.2.4RC1 Released
Cannot reproduce this, configure went just fine on Solaris. Can you please see on which line in configure script it complains? How can I find that out? Is there a debug parameter? Config.log does not show anything. Could it be that on your solaris system the default shell in /bin/sh is bash? It's definitely not bash (cause I have to run bash manually to get a usable shell). # ls -l /bin/sh -r-xr-xr-x 4 root root 95320 Jul 30 2004 /bin/sh [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ ls -l /bin/sh lrwxrwxrwx 1 root root 13 Apr 13 10:40 /bin/sh - ../../sbin/sh [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ ls -l /sbin/sh -r-xr-xr-x 1 root root 82468 Oct 18 2006 /sbin/sh Until now, I have no error location. I think I will look into the changes in configure.in and look for test calls and try to modify them. Starting configure with sh -v did not work it only prints a few messages at beginning but then switches to another shell (???). The problem is fixed if you start configure with bash configure. But it would be good to fix this. You are right with CLI it works. But there seems to be a problem with INI parsing. The web application that produced this error was started with an overwritten error_reporting value running in Sun Java System Webserver which worked correctly with 5.2.3: Service fn=php5_execute type=magnus-internal/x-httpd-php error_reporting=2039 allow_url_include=1 This works just fine either: ./sapi/cli/php -d error_reporting=2039 -r 'error_reporting(2039); @fopen(, r); No idea how the sun webserver passes options to PHP, though. I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I think I write now a bug report and paste this mail conversation into it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Ext/OpenSSL patch
On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: I won't applay it to HEAD without php-5. I need it in php-5. HEAD may wait. We all need it to 5. But we also need it to test it before it goes to the stable branch. I would really love to get back our _development_ branch. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:07, Uwe Schindler wrote: Until now, I have no error location. I think I will look into the changes in configure.in and look for test calls and try to modify them. Thanks. Starting configure with sh -v did not work it only prints a few messages at beginning but then switches to another shell (???). The problem is fixed if you start configure with bash configure. But it would be good to fix this. Yes, I've already CCed Jani, who's responsible for this part. I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). How EXACTLY does the web-server put the value? To me it looks like you're using some global config file, so no wonder it's put globally. Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask _me_ about it. Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote: Generating files /configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ It might be the configure options macro I added..but I can't see why any 'test' calls in it wouldn't work? Anyways, to get more output from configure you can change the hashbang line in it to: #! /bin/sh -x And then run configure something like this: # ./configure 2 err Then 'err' will contain the debug output.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Ext/OpenSSL patch
On 8/3/07, Moritz Bechler [EMAIL PROTECTED] wrote: Concerning ext/openssl feature enhancements I wanted to remind of my CRL patch (#b) which could be committed to HEAD. I recently built new patches against HEAD and PHP_5_2 which can be found here: http://mbechler.eenterphace.org/php6-openssl-crl.patch http://mbechler.eenterphace.org/php5-openssl-crl.patch (unfortunatly I've somehow lost my bug password :|) By the way, it would be nice (and faster) if you can join a couple of tests and examples (with required data). it will make my work a bit easier while testing your patch. Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Ext/OpenSSL patch
Pierre wrote: Hi Dmitry, On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: -Original Message- From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 2:13 PM To: Dmitry Stogov Cc: internals@lists.php.net Subject: RE: [PHP-DEV] RE: Ext/OpenSSL patch So even Zend has abandoned PHP 6 development? :D And here I thought HEAD was meant for active development and you just MFH to any active branch were certain stuff goes.. Committing patch and then backporting it after several month is big headache for me. I belive, nobody will use it in PHP6. I'm one that will test it, as already stated. That being said, I understand your concerns but remember that we are talking about mostly binary strings operation here. The differences between 5.x and 6.x for such code are very very small (and can be completely removed by using a couple of nice #define). Anyway, I can't force you to actually use our development branch... --Pierre Concerning ext/openssl feature enhancements I wanted to remind of my CRL patch (#40046) which could be committed to HEAD. I recently built new patches against HEAD and PHP_5_2 which can be found here: http://mbechler.eenterphace.org/php6-openssl-crl.patch http://mbechler.eenterphace.org/php5-openssl-crl.patch (unfortunatly I've somehow lost my bug password :|) best regards Moritz -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:48, Uwe Schindler wrote: How EXACTLY does the web-server put the value? To me it looks like you're using some global config file, so no wonder it's put globally. It is not global. The overwritten value is set only for a specific path (you can be sure that I know how Sun Webserver works, I maintain the NSAPI module... :-) ). The changed value then corrupts the ini entry complete. I found out why this is so, so this is a _bug_. The following patch, when reverted fixes it and restores the old behaviour: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.39 .2.2.2.9pathrev=PHP_5_2 It's done to prevent overwriting settings set in httpd.conf (aka php_admin_value's). I do not know why, but it seems that this request specific code tries to overwrite the definition of the ini entry and corrupts it in a ZTS environment. After that every request this webserver handles (even when not affected by a overwritten value produces nice error messages. I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask _me_ about it. Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have? Take Apache on Windows... :) Do you mean you were able to reproduce it with Apache on Windows? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 15:48, Scott MacVicar wrote: Edin, Can you upgrade the bundled MySQL libraries so we can get #41350 fixed, the code is already there it just needs the latest libraries on Windows. We also need the latest t1lib and libtidy on Windows. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 14:12, Lester Caine wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. The main reason this problem has now become a problem is a number of long time PHP4 users who have been convinced to move to PHP5 - only to fall at the first hurdle :( Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Once it pops out as a windows build ;) -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ 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] 5.2.4RC1 Released
On 03.08.2007 17:29, Uwe Schindler wrote: I reopened the original bug reported that lead to your change. At the moment I am trying to fix that. I moved your code a few lines down in zend_alter_ini_entry but until now with no success. No, that won't work I guess. At the moment I can only think of a special hashtable storing all the values that were set during the INI_SYSTEM stage, so that users could not override them in their scripts. I suppose there is something special with error reporting that corrupts it. That special thing is in your config file =) It seems that it does not like it to be changed to ZEND_INI_SYSTEM because the @operator tries to change the value (e.g. in zend_vm_execute.h), which fails silently: This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
Hallo Jani, thanks, the configure error is gone! gmake test still fails with /bin/sh: syntax error at line 1: `;' unexpected - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 12:48 PM To: Uwe Schindler Subject: RE: [PHP-DEV] 5.2.4RC1 Released I changed one added 'test' line in acinclude.m4 and committed it..so try the latest PHP_5_2 checkout. --Jani On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote: Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: .. checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files /configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: .. configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- 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] 5.2.4RC1 Released
On 03.08.2007 14:48, Uwe Schindler wrote:
How EXACTLY does the web-server put the value?
To me it looks like you're using some global config file, so no wonder
it's put globally.
It is not global. The overwritten value is set only for a specific path
(you
can be sure that I know how Sun Webserver works, I maintain the NSAPI
module... :-) ).
The changed value then corrupts the ini entry complete. I found out why
this
is so, so this is a _bug_.
The following patch, when reverted fixes it and restores the old
behaviour:
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.
39
.2.2.2.9pathrev=PHP_5_2
It's done to prevent overwriting settings set in httpd.conf (aka
php_admin_value's).
I know how this is meant. But without the added patch, it does not corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded one),
because it modifies the ini setting in a way that affects later running
threads.
I try to find a way to reproduce it in other webservers.
This is the code that NSAPI uses to modify the INI entries:
entry-param-name is the nullterminated ini key name, entry-param-value
is the nullteminated value. This code runs on every request (like in apache
a php_(admin)_value) that needs to set some specific ini-values. The server
runs only *one* process that handles all requests in its lifetime because it
is multithreaded:
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
. It is always runned with admin privileges because SJSWS does not have
htaccess files. The big advantage to have the possibility to set ini values
is, that it is not server-wide you can change the call to PHP SAPI e.g. per
virtual server or URI path (see documentation of NSAPI).
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Edin, Can you upgrade the bundled MySQL libraries so we can get #41350 fixed, the code is already there it just needs the latest libraries on Windows. Scott Edin Kadribasic wrote: The windows build is now ready and can be downloded from: http://downloads.php.net/edink/php-5.2.4RC1-Win32.zip http://downloads.php.net/edink/php-5.2.4RC1-win32-installer.msi http://downloads.php.net/edink/pecl-5.2.4RC1-Win32.zip http://downloads.php.net/edink/php-debug-pack-5.2.4RC1-Win32.zip Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 17:50, Lester Caine wrote: Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. The main reason this problem has now become a problem is a number of long time PHP4 users who have been convinced to move to PHP5 - only to fall at the first hurdle :( It's good to hear that PHP4 users finally decided to move to PHP5. Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Once it pops out as a windows build ;) It should be already there, please check it out. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Ext/OpenSSL patch
Hi Dmitry, On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: -Original Message- From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 2:13 PM To: Dmitry Stogov Cc: internals@lists.php.net Subject: RE: [PHP-DEV] RE: Ext/OpenSSL patch So even Zend has abandoned PHP 6 development? :D And here I thought HEAD was meant for active development and you just MFH to any active branch were certain stuff goes.. Committing patch and then backporting it after several month is big headache for me. I belive, nobody will use it in PHP6. I'm one that will test it, as already stated. That being said, I understand your concerns but remember that we are talking about mostly binary strings operation here. The differences between 5.x and 6.x for such code are very very small (and can be completely removed by using a couple of nice #define). Anyway, I can't force you to actually use our development branch... --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 8/3/07, Antony Dovgal [EMAIL PROTECTED] wrote: On 03.08.2007 14:12, Lester Caine wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? Each PHP releases have RCs. Maybe this extension needs more tests (written in php) so one (for example you :) can quickly run the tests using a given RC or release. Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Meaning not the Aug 03, 2007 08:30 UTC snap but the next one :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
One down, one to go.. :) --Jani On Fri, 2007-08-03 at 14:42 +0200, Uwe Schindler wrote: Hallo Jani, thanks, the configure error is gone! gmake test still fails with /bin/sh: syntax error at line 1: `;' unexpected - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 12:48 PM To: Uwe Schindler Subject: RE: [PHP-DEV] 5.2.4RC1 Released I changed one added 'test' line in acinclude.m4 and committed it..so try the latest PHP_5_2 checkout. --Jani On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote: Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: .. checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files /configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ config.log does not show anything special: .. configure:113510: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -fPIC -DPIC conftest.cpp 15 configure:113514: $? = 0 configure:113552: checking if c++ supports -c -o file.o configure:113572: c++ -c -g -O2 -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -o out/conftest2.o conftest.cpp 15 configure:113576: $? = 0 configure:113623: checking whether the c++ linker (/usr/ccs/bin/ld) supports shared libraries configure:113709: checking dynamic linker characteristics configure:114283: checking how to hardcode library paths into programs configure:114321: checking whether stripping libraries is possible Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:37 AM To: PHP Internals Subject: [PHP-DEV] 5.2.4RC1 Released As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC1.tar.bz2 (md5sum: 43e28d2aa55b6c8bcd67da16e24b225a) Windows binaries should become available in short order as well. This release have been long in the making so the changelog is a bit intimidating, so we definitely need a lot of testing for this release. I would like to ask everyone to give this RC a shot and see how it behaves with their code and hopefully not find any regressions. If you do find any, please let us know. Now that RC1 is out, I would like to ask all developers to refrain from making any feature additions to 5.2.4 at this time and only apply bug fixes. I am hoping to have RC2 released within 2 weeks from now and if it proves to be stable move onto the final release a week from then. So, if all goes well we should have 5.2.4 out within a month or less. One exception to the rule I'd like to make known is Stas' ini system patch, which I feel we should include, but that's still being currently discussed. Aside from those, no feature additions, please. Ilia Alshanetsky -- 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] 5.2.4RC1 Released
This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. The problem with the original fix of antony was the same: The first time any thread started to modify any INI entry it was marked as admin-only for the whole PHP server until a restart and it stayed in that state because the flag was changed *before* the hash table was replicated. This is a second bug. So at least the lines of antony must moved a few lines down in code... I attached a patch. This patch must be applied in all cases. A second thing is to remove breakage of the @ operator. Oh I forgot, this does not help, too. Because the ADMIN-only status given by antonys patch (change of ini_entry-modifiable) is not rolled back after request shutdown. For the Apache-Not-Multithreaded people a description of the problem: An Apache server administrator has 2 virtual servers: * One with the original php.ini configuration and no php_admin_values. * One with a modified value that is set by php_admin_value. The setting is overwritten on the first request of the second virtual server. This is ok, because the value is restored after the request finishes. But the problem is that Antonys patch marked the flag as admin only, which is not reverted at end of request. The first virtual server without the php_admin_value will also have the ini-setting marked as ADMIN only until end of time :( Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote: This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Unicode-safe extensions
Please forgive my ignorance, as I am relatively new to PHP extension building. Is there a document published anywhere that describes how to make extensions unicode safe for php6? Thanks! -- Jordan CM Wambaugh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.
Constantin B wrote: Hello, i'm not sure its the right place to post this message, so redirect me if i'm wrong. Here the problematic : We are alot running php across multiple backend servers and we all know that we need to syncronise the php sources usualy we do that with rsync , some of us run all backends on an NFS feed. - the usual problem is that the developpers like to see their changes in live and we dont want to let them touch the holly rsync script. Here the idea : if we could have an option in php.ini or a new wrapper localcache:/ we could get all require / include / require_once / include_once functions to make a local copy of needed files then require / include them as usualy. here an exemple : require(/path/to/file.php); // the /path/to/file.php is on an nfs mount. require should : 1 : check in /localcopy/path/to/file.php if it exist 2 : then if its not too old // we can define what this means later // it just require it as now 3 : if the file does not exist or if its too old we refresh it from the /path/to/file.php and require it . result : 1:this will lead all scripts run unmodified but from /localcopy/ 2: the nfs is not loaded at all and wont be a bottle neck 3: developpers can change their files and dont need to access the holly rsync 4: all the backend servers auto syncronise and keep in sync. We could imagine not to fetch the files from the nfs but by http also . (at step3 ) this remove the need of nfs at all. This would allow us to run large backends without the syncronisation issue . And would be a huge perf boost over nfs. I dont think it will also disturb opcode caches like apc as if we do it early it will not notice that the file was refreshed from remote. Its just an idea but i'm sure it can be realy usefull for big farms. This doesn't sound like something that should be part of PHP at all. This is a generic file system caching mechanism which can be implemented using FUSE. There are even implementations out there of an rsyncfs which pretty much does exactly what you are looking for. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote:
This's a special case and it's really great you noticed it in RC..
We need a workaround for this special case, as if we make all INI
directives set
using php_admin_value non-changeable, we break the @ thing.
So we either need to change the @ not to use zend_alter_ini_entry,
or make
an
exception in that function, which I believe would be a hack.
Thats correct. An idea would be to make the @ operator only change
EG(error_reporting) without changing the whole ini-entry by
alter_ini_entry
(which is a big slowdown...).
The problem with that fix that a crash would potentially leave the
error blocking on, and INI clean up will not reset it.
The problem with the original fix of antony was the same: The first time
any
thread started to modify any INI entry it was marked as admin-only for
the
whole PHP server until a restart and it stayed in that state because the
flag was changed *before* the hash table was replicated. This is a second
bug. So at least the lines of antony must moved a few lines down in
code...
I attached a patch. This patch must be applied in all cases. A second thing
is to remove breakage of the @ operator.
Uwe
Index: zend_ini.c
===
RCS file: /repository/ZendEngine2/zend_ini.c,v
retrieving revision 1.39.2.2.2.10
diff -u -r1.39.2.2.2.10 zend_ini.c
--- zend_ini.c 17 Jun 2007 14:31:12 - 1.39.2.2.2.10
+++ zend_ini.c 3 Aug 2007 14:46:30 -
@@ -243,10 +243,6 @@
return FAILURE;
}
- if (stage == ZEND_INI_STAGE_ACTIVATE modify_type == ZEND_INI_SYSTEM)
{
- ini_entry-modifiable = ZEND_INI_SYSTEM;
- }
-
if (!(ini_entry-modifiable modify_type)) {
return FAILURE;
}
@@ -264,6 +260,10 @@
zend_hash_add(EG(modified_ini_directives), name, name_length,
ini_entry, sizeof(zend_ini_entry*), NULL);
}
+ if (stage == ZEND_INI_STAGE_ACTIVATE modify_type == ZEND_INI_SYSTEM)
{
+ ini_entry-modifiable = ZEND_INI_SYSTEM;
+ }
+
duplicate = estrndup(new_value, new_value_length);
if (!ini_entry-on_modify
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
I reopened the original bug reported that lead to your change.
At the moment I am trying to fix that. I moved your code a few lines down in
zend_alter_ini_entry but until now with no success.
I suppose there is something special with error reporting that corrupts it.
It seems that it does not like it to be changed to ZEND_INI_SYSTEM because
the @operator tries to change the value (e.g. in zend_vm_execute.h), which
fails silently:
static int ZEND_BEGIN_SILENCE_SPEC_HANDLER(ZEND_OPCODE_HANDLER_ARGS)
{
zend_op *opline = EX(opline);
Z_LVAL(EX_T(opline-result.u.var).tmp_var) = EG(error_reporting);
Z_TYPE(EX_T(opline-result.u.var).tmp_var) = IS_LONG; /* shouldn't
be necessary */
if (EX(old_error_reporting) == NULL) {
EX(old_error_reporting) =
EX_T(opline-result.u.var).tmp_var;
}
if (EG(error_reporting)) {
zend_alter_ini_entry(error_reporting,
sizeof(error_reporting), 0, 1, ZEND_INI_USER, ZEND_INI_STAGE_RUNTIME);
}
ZEND_VM_NEXT_OPCODE();
}
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Friday, August 03, 2007 3:15 PM
To: Uwe Schindler
Cc: 'Ilia Alshanetsky'; 'PHP Internals'
Subject: Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 16:04, Uwe Schindler wrote:
I know how this is meant. But without the added patch, it does not
corrupt
error_reporting. The problem is that your patch is not compatible to a
webserver that runs more than one request per process (a multithreaded
one),
because it modifies the ini setting in a way that affects later running
threads.
Ok, I see.
Please fill a bug report and assign it to me, I'll deal with it.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-safe extensions
Jordan Wambaugh schrieb: Is there a document published anywhere that describes how to make extensions unicode safe for php6? http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE?view=markup http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE-UPGRADES?view=markup -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.
There is nothing simple about it when it comes to a portable implementation across all platforms which is what it would have to be if it was in PHP. In your case, you don't need it to be portable, you just need it to work on your configuration, and there are all sorts of ways you can solve it without changing PHP. For example, even without any fancy file system layers, a simple cron job that checks the local files against the NFS/rsync/remote copy every couple of minutes and updates the files atomically would solve your problem as well. Adding a complicated caching layer in PHP just so you don't need to write a little cronjob script makes no sense to me. -Rasmus Constantin B wrote: I was thinking that portable and very simple implementation in php would be much more used in real world than these experimental too abstract implementations. but i guess i'm wrong. 2007/8/3, Rasmus Lerdorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Constantin B wrote: Hello, i'm not sure its the right place to post this message, so redirect me if i'm wrong. Here the problematic : We are alot running php across multiple backend servers and we all know that we need to syncronise the php sources usualy we do that with rsync , some of us run all backends on an NFS feed. - the usual problem is that the developpers like to see their changes in live and we dont want to let them touch the holly rsync script. Here the idea : if we could have an option in php.ini or a new wrapper localcache:/ we could get all require / include / require_once / include_once functions to make a local copy of needed files then require / include them as usualy. here an exemple : require(/path/to/file.php); // the /path/to/file.php is on an nfs mount. require should : 1 : check in /localcopy/path/to/file.php if it exist 2 : then if its not too old // we can define what this means later // it just require it as now 3 : if the file does not exist or if its too old we refresh it from the /path/to/file.php and require it . result : 1:this will lead all scripts run unmodified but from /localcopy/ 2: the nfs is not loaded at all and wont be a bottle neck 3: developpers can change their files and dont need to access the holly rsync 4: all the backend servers auto syncronise and keep in sync. We could imagine not to fetch the files from the nfs but by http also . (at step3 ) this remove the need of nfs at all. This would allow us to run large backends without the syncronisation issue . And would be a huge perf boost over nfs. I dont think it will also disturb opcode caches like apc as if we do it early it will not notice that the file was refreshed from remote. Its just an idea but i'm sure it can be realy usefull for big farms. This doesn't sound like something that should be part of PHP at all. This is a generic file system caching mechanism which can be implemented using FUSE. There are even implementations out there of an rsyncfs which pretty much does exactly what you are looking for. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unicode-safe extensions
On Friday 03 August 2007, Sebastian Bergmann wrote: Jordan Wambaugh schrieb: Is there a document published anywhere that describes how to make extensions unicode safe for php6? http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE?view=markup http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE-UPGRADES?view=markup -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 Thanks sebastian. -- Jordan CM Wambaugh -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.
I was thinking that portable and very simple implementation in php would be much more used in real world than these experimental too abstract implementations. but i guess i'm wrong. 2007/8/3, Rasmus Lerdorf [EMAIL PROTECTED]: Constantin B wrote: Hello, i'm not sure its the right place to post this message, so redirect me if i'm wrong. Here the problematic : We are alot running php across multiple backend servers and we all know that we need to syncronise the php sources usualy we do that with rsync , some of us run all backends on an NFS feed. - the usual problem is that the developpers like to see their changes in live and we dont want to let them touch the holly rsync script. Here the idea : if we could have an option in php.ini or a new wrapper localcache:/ we could get all require / include / require_once / include_once functions to make a local copy of needed files then require / include them as usualy. here an exemple : require(/path/to/file.php); // the /path/to/file.php is on an nfs mount. require should : 1 : check in /localcopy/path/to/file.php if it exist 2 : then if its not too old // we can define what this means later // it just require it as now 3 : if the file does not exist or if its too old we refresh it from the /path/to/file.php and require it . result : 1:this will lead all scripts run unmodified but from /localcopy/ 2: the nfs is not loaded at all and wont be a bottle neck 3: developpers can change their files and dont need to access the holly rsync 4: all the backend servers auto syncronise and keep in sync. We could imagine not to fetch the files from the nfs but by http also . (at step3 ) this remove the need of nfs at all. This would allow us to run large backends without the syncronisation issue . And would be a huge perf boost over nfs. I dont think it will also disturb opcode caches like apc as if we do it early it will not notice that the file was refreshed from remote. Its just an idea but i'm sure it can be realy usefull for big farms. This doesn't sound like something that should be part of PHP at all. This is a generic file system caching mechanism which can be implemented using FUSE. There are even implementations out there of an rsyncfs which pretty much does exactly what you are looking for. -Rasmus
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 11:48, Lester Caine wrote: Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today Ilia please can you make sure that the bug http://bugs.php.net/bug.php?id=41429 is at least rolled back to the 5.2.1 state for 5.2.4 - as it currently stands it is causing problems. Lester, why don't you just try and fix it? Not yet been able to BUILD my own copy of PHP on windows and I don't have time as I am still TESTING 5.2.3!!! Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? There may be some subtle reason why this has been changed and OUR current fix is to load a copy of the 5.2.1 version which fixes the bug - so until someone explains why it was changed then reverting works fine. I had to give up switching to 5.2 as I did not have the time to fix all the problems that it was throwing up. 5.1.6 has been running fine in production! I created some time to work through all the problems and I now have a working 5.2.3 installation - with some hacks to get round this bug, and now I need to spend time with 5.2.4RC1 WHEN the windows build is up. I can even tell you which lines were changed since 5_1: http://cvs.php.net/viewvc.cgi/php-src/ext/interbase/ibase_blobs.c?r1=1.13r2=1.9.2.2 Then it should be possible for someone who HAS commit rights to actually make it work? Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ 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] RE: Ext/OpenSSL patch
-Original Message- From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 2:13 PM To: Dmitry Stogov Cc: internals@lists.php.net Subject: RE: [PHP-DEV] RE: Ext/OpenSSL patch So even Zend has abandoned PHP 6 development? :D And here I thought HEAD was meant for active development and you just MFH to any active branch were certain stuff goes.. Committing patch and then backporting it after several month is big headache for me. I belive, nobody will use it in PHP6. Dmitry. Anyway, it's about new features, those must wait for 5.3. --Jani On Fri, 2007-08-03 at 13:43 +0400, Dmitry Stogov wrote: I won't applay it to HEAD without php-5. I need it in php-5. HEAD may wait. Thanks. Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:21 PM To: Dmitry Stogov Cc: Stanislav Malyshev; Wez Furlong; Sara Golemon; Andi Gutmans; Zeev Suraski; internals@lists.php.net Subject: Re: [PHP-DEV] RE: Ext/OpenSSL patch On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: Hi Stas, Thank you for catching this. I fixed it locally. Can you not apply the patch to HEAD already? :) Cheers, --Pierre -- 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 14:12, Lester Caine wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. There may be some subtle reason why this has been changed and OUR current fix is to load a copy of the 5.2.1 version which fixes the bug - so until someone explains why it was changed then reverting works fine. I had to give up switching to 5.2 as I did not have the time to fix all the problems that it was throwing up. What kind of problems? Then it should be possible for someone who HAS commit rights to actually make it work? Yes, if only this somebody has Windows build env, Interbase and will to help us. Unfortunately we don't have such people in PHP community. Edin and Pierre are two people doing windows builds, but none of them use Interbase as far as I know. I must also note that you don't have to have commit rights to cook a patch and send it to the list. Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Ext/OpenSSL patch
[EMAIL PROTECTED] wrote: On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: I won't applay it to HEAD without php-5. I need it in php-5. HEAD may wait. We all need it to 5. But we also need it to test it before it goes to the stable branch. I would really love to get back our _development_ branch. --Pierre We have a development branch: HEAD... Why don't you want Dmitry to commit it to HEAD? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_ini.h
I see that this feature will be backported to older PHP 5 and even to PHP 4 used by linux/bsd distributions, because it is a required security BTW: I plan to merge it in 4.4 tree, but since there's no 4.4 release planned soon AFAIK I want to hold for a bit to see if 5.2 testing produces any issues since we're having 5.2.4 release cycle now. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 10:32, Uwe Schindler wrote: Configuring on Solaris (2.10) no longer works, ist the old problem with test that is more strict on solaris: ... checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no Generating files ./configure: test: argument expected [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ Cannot reproduce this, configure went just fine on Solaris. Can you please see on which line in configure script it complains? The following two things are problematic: 1) @-operator before function names does not suppress warning messages anymore? Whats wrong? I got for example messages like cannot open file... even when it was opened with @fopen(...). Not reproducible either. ./sapi/cli/php -r 'fopen(a, r);' Warning: fopen(a): failed to open stream: No such file or directory in Command line code on line 1 ./sapi/cli/php -r '@fopen(a, r);' silence 2) make test is broken: [EMAIL PROTECTED]:~/install/php-5.2.4RC1$ gmake test Build complete. Don't forget to run 'make test'. /bin/sh: syntax error at line 1: `;' unexpected gmake: [test] Error 2 (ignored) Confirmed, Jani's configure.in tweaks do not work with broken shell on Solaris. Jani, please take a look at it, it complains each time I try to use $(PHP_TEST_SHARED_EXTENSIONS). -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 10:32, Uwe Schindler wrote:
Configuring on Solaris (2.10) no longer works, ist the old problem with
test that is more strict on solaris:
...
checking dynamic linker characteristics... solaris2.10 ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
Generating files
./configure: test: argument expected
[EMAIL PROTECTED]:~/install/php-5.2.4RC1$
Cannot reproduce this, configure went just fine on Solaris.
Can you please see on which line in configure script it complains?
How can I find that out? Is there a debug parameter? Config.log does not
show anything.
Could it be that on your solaris system the default shell in /bin/sh is
bash?
The following two things are problematic:
1) @-operator before function names does not suppress warning messages
anymore? Whats wrong?
I got for example messages like cannot open file... even when it was
opened with @fopen(...).
Not reproducible either.
./sapi/cli/php -r 'fopen(a, r);'
Warning: fopen(a): failed to open stream: No such file or directory in
Command line code on line 1
./sapi/cli/php -r '@fopen(a, r);'
silence
You are right with CLI it works. But there seems to be a problem with INI
parsing. The web application that produced this error was started with an
overwritten error_reporting value running in Sun Java System Webserver
which worked correctly with 5.2.3:
Service fn=php5_execute type=magnus-internal/x-httpd-php
error_reporting=2039 allow_url_include=1
Removing the error_reporting fixed the problem. Was there a change somewhere
that error_reporting with 2039 set by...
if (zend_alter_ini_entry(entry-param-name, strlen(entry-param-name)+1,
entry-param-value, strlen(entry-param-value),
PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE)==FAILURE) {
log_error(LOG_WARN, pblock_findval(fn, NSG(pb)), NSG(sn), NSG(rq),
Cannot change php.ini key \%s\ to \%s\, entry-param-name,
entry-param-value);
}
...may not work? Just for interest, I am sure that this NSAPI option was not
correct because it was a relict from former days.
I removed the wrong error reporting now, but it is interesting that the same
value worked before.
Uwe
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: Ext/OpenSSL patch
On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: Hi Stas, Thank you for catching this. I fixed it locally. Can you not apply the patch to HEAD already? :) Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 13:10, Uwe Schindler wrote: Cannot reproduce this, configure went just fine on Solaris. Can you please see on which line in configure script it complains? How can I find that out? Is there a debug parameter? Config.log does not show anything. Could it be that on your solaris system the default shell in /bin/sh is bash? It's definitely not bash (cause I have to run bash manually to get a usable shell). # ls -l /bin/sh -r-xr-xr-x 4 root root 95320 Jul 30 2004 /bin/sh You are right with CLI it works. But there seems to be a problem with INI parsing. The web application that produced this error was started with an overwritten error_reporting value running in Sun Java System Webserver which worked correctly with 5.2.3: Service fn=php5_execute type=magnus-internal/x-httpd-php error_reporting=2039 allow_url_include=1 This works just fine either: ./sapi/cli/php -d error_reporting=2039 -r 'error_reporting(2039); @fopen(, r); No idea how the sun webserver passes options to PHP, though. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Ext/OpenSSL patch
I won't applay it to HEAD without php-5. I need it in php-5. HEAD may wait. Thanks. Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 1:21 PM To: Dmitry Stogov Cc: Stanislav Malyshev; Wez Furlong; Sara Golemon; Andi Gutmans; Zeev Suraski; internals@lists.php.net Subject: Re: [PHP-DEV] RE: Ext/OpenSSL patch On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: Hi Stas, Thank you for catching this. I fixed it locally. Can you not apply the patch to HEAD already? :) Cheers, --Pierre -- 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: Ext/OpenSSL patch
On 8/3/07, Sara Golemon [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: I won't applay it to HEAD without php-5. I need it in php-5. HEAD may wait. We all need it to 5. But we also need it to test it before it goes to the stable branch. I would really love to get back our _development_ branch. --Pierre We have a development branch: HEAD... Why don't you want Dmitry to commit it to HEAD? You mis read the thread. I want him to commit to HEAD, he does not want to. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 5.2.4RC1 Released
I looked into it: The problem seems to be ZTS specific. What we have: * First, the value looks correct in phpinfo(). * Second setting the value to 6039 (which is the default from php.ini) produces now a lot of _more_ and very strange error messages when running PHP scripts. It seems that the webserver puts the value somewhere to a global place because after that *ALL* PHP scripts print very strange things (even those where this value is not explicitely set). How EXACTLY does the web-server put the value? To me it looks like you're using some global config file, so no wonder it's put globally. It is not global. The overwritten value is set only for a specific path (you can be sure that I know how Sun Webserver works, I maintain the NSAPI module... :-) ). The changed value then corrupts the ini entry complete. I found out why this is so, so this is a _bug_. The following patch, when reverted fixes it and restores the old behaviour: http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_ini.c?r1=1.39.2.2.2.8r2=1.39 .2.2.2.9pathrev=PHP_5_2 I do not know why, but it seems that this request specific code tries to overwrite the definition of the ini entry and corrupts it in a ZTS environment. After that every request this webserver handles (even when not affected by a overwritten value produces nice error messages. Could it be that there happened a ZTS regression when updating the ini scanner? In 5.2.3 it worked correctly. I don't know what exactly is the problem and how to reproduce it, so it makes little sense to ask _me_ about it. Do you have a short reproduce case that doesn't require Solaris, Sun Web server and other stuff we don't have? Take Apache on Windows... :) I doid not want to ask you alone, the mail was to [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_ini.h
However are there any plans to add a symbol or something else so that a PHP extension can detect the support for this feature at runtime? Hmm... I'm not sure how to do it best for the extension. I checked core extensions and they don't use INI stages in a way that this change can break them, and if an extension would use new stage, it still would load with older PHP - even though the check for the new stage won't ever work, of course. If there's an extension which uses INI_STAGE_ACTIVATE and needs to support new htaccess stage, it can be fixed in source so check for this stage too - but I didn't see such extensions yet. Now, if you do need to detect if the functionality at runtime and do something meaningful basing on its presence or absence - I'm not sure how to do it. Any ideas? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.
Hi Constantin, That is quite a difficult setup you have there. You should have a look if there is not a simpler way to accomplish whatever this setup is for. That said, you should have a look at DRBD (http://www.drbd.org), which should be able to solve your problems. It detects file changes on a low level and synchronizes it to other systems. Setting up DRBD isn't an easy task though, but hard problems usually have hard solutions ;). Good luck, Arnold Rasmus Lerdorf wrote: There is nothing simple about it when it comes to a portable implementation across all platforms which is what it would have to be if it was in PHP. In your case, you don't need it to be portable, you just need it to work on your configuration, and there are all sorts of ways you can solve it without changing PHP. For example, even without any fancy file system layers, a simple cron job that checks the local files against the NFS/rsync/remote copy every couple of minutes and updates the files atomically would solve your problem as well. Adding a complicated caching layer in PHP just so you don't need to write a little cronjob script makes no sense to me. -Rasmus Constantin B wrote: I was thinking that portable and very simple implementation in php would be much more used in real world than these experimental too abstract implementations. but i guess i'm wrong. 2007/8/3, Rasmus Lerdorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Constantin B wrote: Hello, i'm not sure its the right place to post this message, so redirect me if i'm wrong. Here the problematic : We are alot running php across multiple backend servers and we all know that we need to syncronise the php sources usualy we do that with rsync , some of us run all backends on an NFS feed. - the usual problem is that the developpers like to see their changes in live and we dont want to let them touch the holly rsync script. Here the idea : if we could have an option in php.ini or a new wrapper localcache:/ we could get all require / include / require_once / include_once functions to make a local copy of needed files then require / include them as usualy. here an exemple : require(/path/to/file.php); // the /path/to/file.php is on an nfs mount. require should : 1 : check in /localcopy/path/to/file.php if it exist 2 : then if its not too old // we can define what this means later // it just require it as now 3 : if the file does not exist or if its too old we refresh it from the /path/to/file.php and require it . result : 1:this will lead all scripts run unmodified but from /localcopy/ 2: the nfs is not loaded at all and wont be a bottle neck 3: developpers can change their files and dont need to access the holly rsync 4: all the backend servers auto syncronise and keep in sync. We could imagine not to fetch the files from the nfs but by http also . (at step3 ) this remove the need of nfs at all. This would allow us to run large backends without the syncronisation issue . And would be a huge perf boost over nfs. I dont think it will also disturb opcode caches like apc as if we do it early it will not notice that the file was refreshed from remote. Its just an idea but i'm sure it can be realy usefull for big farms. This doesn't sound like something that should be part of PHP at all. This is a generic file system caching mechanism which can be implemented using FUSE. There are even implementations out there of an rsyncfs which pretty much does exactly what you are looking for. -Rasmus
RE: [PHP-DEV] 5.2.4RC1 Released
On 3-Aug-07, at 9:51 AM, Uwe Schindler wrote: This's a special case and it's really great you noticed it in RC.. We need a workaround for this special case, as if we make all INI directives set using php_admin_value non-changeable, we break the @ thing. So we either need to change the @ not to use zend_alter_ini_entry, or make an exception in that function, which I believe would be a hack. Thats correct. An idea would be to make the @ operator only change EG(error_reporting) without changing the whole ini-entry by alter_ini_entry (which is a big slowdown...). The problem with that fix that a crash would potentially leave the error blocking on, and INI clean up will not reset it. The problem with the original fix of antony was the same: The first time any thread started to modify any INI entry it was marked as admin-only for the whole PHP server until a restart and it stayed in that state because the flag was changed *before* the hash table was replicated. This is a second bug. So at least the lines of antony must moved a few lines down in code... Uwe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Feature request : Self caching of .php files for wide multi backend setups.
Hello, i'm not sure its the right place to post this message, so redirect me if i'm wrong. Here the problematic : We are alot running php across multiple backend servers and we all know that we need to syncronise the php sources usualy we do that with rsync , some of us run all backends on an NFS feed. - the usual problem is that the developpers like to see their changes in live and we dont want to let them touch the holly rsync script. Here the idea : if we could have an option in php.ini or a new wrapper localcache:/ we could get all require / include / require_once / include_once functions to make a local copy of needed files then require / include them as usualy. here an exemple : require(/path/to/file.php); // the /path/to/file.php is on an nfs mount. require should : 1 : check in /localcopy/path/to/file.php if it exist 2 : then if its not too old // we can define what this means later // it just require it as now 3 : if the file does not exist or if its too old we refresh it from the /path/to/file.php and require it . result : 1:this will lead all scripts run unmodified but from /localcopy/ 2: the nfs is not loaded at all and wont be a bottle neck 3: developpers can change their files and dont need to access the holly rsync 4: all the backend servers auto syncronise and keep in sync. We could imagine not to fetch the files from the nfs but by http also . (at step3 ) this remove the need of nfs at all. This would allow us to run large backends without the syncronisation issue . And would be a huge perf boost over nfs. I dont think it will also disturb opcode caches like apc as if we do it early it will not notice that the file was refreshed from remote. Its just an idea but i'm sure it can be realy usefull for big farms. Cb
Re: [PHP-DEV] 5.2.4RC1 Released
On 03.08.2007 16:04, Uwe Schindler wrote: I know how this is meant. But without the added patch, it does not corrupt error_reporting. The problem is that your patch is not compatible to a webserver that runs more than one request per process (a multithreaded one), because it modifies the ini setting in a way that affects later running threads. Ok, I see. Please fill a bug report and assign it to me, I'll deal with it. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_ini.h
On Fri, 3 Aug 2007, Stanislav Malyshev wrote: I see that this feature will be backported to older PHP 5 and even to PHP 4 used by linux/bsd distributions, because it is a required security BTW: I plan to merge it in 4.4 tree, but since there's no 4.4 release planned soon AFAIK I want to hold for a bit to see if 5.2 testing produces any issues since we're having 5.2.4 release cycle now. Yeah, that seems like a proper way. If this turns out to not cause problems merge it to 4.4 and make a release. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 17:50, Lester Caine wrote: Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). So even if somebody did run the tests against an RC, he/she didn't tell a word to us. The main reason this problem has now become a problem is a number of long time PHP4 users who have been convinced to move to PHP5 - only to fall at the first hurdle :( It's good to hear that PHP4 users finally decided to move to PHP5. I still have a couple of problems to investigate, but I'm sure that they are just the differences in the much improved version of php_interbase that is shipped with PHP5. A lot of the good stuff was never ported back :( Currently the php_interbase driver is almost unusable in PHP5.2 as shipped, but the 5.2.1 copy works fine. Try the very next snapshot, I applied a patch after a discussion with Marcus. Once it pops out as a windows build ;) It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ 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] 5.2.4RC1 Released
On 03.08.2007 21:45, Lester Caine wrote: It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. Does this mean you've tested it and it works fine now? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Hi, Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC1 was released today and the sources for the release can be found here: Not sure if it'a bug... a broken script in PHP 5.2.4RC1 halts execution because of memory limit: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 24 bytes) in /foo/bar.php on line 88 while 5.2.3 was stopping with: Fatal error: Nesting level too deep - recursive dependency? in /foo/bar.php on line 41 Best regards -- Matteo Beccati Openads - http://www.openads.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). I do (btw, I'm the maintainer of PEAR::MDB2, including the ibase driver), and I know a lot of people using Firebird/Interbase. Unfortunately, since PDO_Firebird is completely broken [1] and Ard isn't active anymore, the only option left is using the current php_interbase extension. So even if somebody did run the tests against an RC, he/she didn't tell a word to us. I left a message on the open bug report. I thought the bug tracker was the best place to confirm such issues... Try the very next snapshot, I applied a patch after a discussion with Marcus. the latest snapshot works for me, many thanks! Best regards, -- Lorenzo Alberton http://pear.php.net/user/quipo [1] http://www.alberton.info/php_pdo_firebird_status.html Quipo Free Internet: sicuro e veloce senza costi di attivazione e senza canone, 2 e-mail da 25 Mb, 150 Mb di spazio web e molto di più! Registrati gratis: http://www.quipo.it -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Antony Dovgal wrote: On 03.08.2007 21:45, Lester Caine wrote: It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. Does this mean you've tested it and it works fine now? Yep - all the combinations that are failing on 5.2.3 are working fine on the snapshot, and the debugger is showing '0x000f0123' instead of the incorrect '0x %i' And my site stuff is all working as I expect. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ 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] 5.2.4RC1 Released
Lorenzo Alberton wrote: Antony Dovgal wrote: Blindly reverting something is no fix, those changes were done for a good reason, even though Marcus didn't test them very good (but that's what RCs are for, isn't it?). Obviously they were not tested at all? I don't know of any people using Interbase except for you and Ard (who maintains all interbase extensions). I do (btw, I'm the maintainer of PEAR::MDB2, including the ibase driver), and I know a lot of people using Firebird/Interbase. Unfortunately, since PDO_Firebird is completely broken [1] and Ard isn't active anymore, the only option left is using the current php_interbase extension. Ard was amongst the list of people who could not see any need to develop a second driver since the php_interbase one IS working fine. It would be nice to build a Firebird version against the modern client, and do away with the need to build a legacy client to allow it to work. That IS in the pipeline, but as yet no-one who uses Firebird/PHP in production has seen any need to spend time on a more limited PDO driver ;) Ard had built a lot of capability into the driver, and has added all the hooks for an fbird port already for a split, which is probably now due given the extensive work Firebird has received in the version 2 builds, and the new service facilities that it would be nice to support directly. But even the existing php_interbase handles FB2.x without a problem. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ 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] 5.2.4RC1 Released
On 03.08.2007 23:11, Lester Caine wrote: Antony Dovgal wrote: On 03.08.2007 21:45, Lester Caine wrote: It should be already there, please check it out. OK - Thanks Antony - that is looking fine. I'm happier now to move it to a production machine and see what the results are with a bit of load. Does this mean you've tested it and it works fine now? Yep - all the combinations that are failing on 5.2.3 are working fine on the snapshot, and the debugger is showing '0x000f0123' instead of the incorrect '0x %i' And my site stuff is all working as I expect. Great, thanks for your feedback! -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Hi Lester, On 8/3/07, Lester Caine [EMAIL PROTECTED] wrote: Ard was amongst the list of people who could not see any need to develop a second driver since the php_interbase one IS working fine. It would be nice to build a Firebird version against the modern client, and do away with the need to build a legacy client to allow it to work. That IS in the pipeline, but as yet no-one who uses Firebird/PHP in production has seen any need to spend time on a more limited PDO driver ;) Ard had built a lot of capability into the driver, and has added all the hooks for an fbird port already for a split, which is probably now due given the extensive work Firebird has received in the version 2 builds, and the new service facilities that it would be nice to support directly. But even the existing php_interbase handles FB2.x without a problem. That's nice and I'm sure Ard's work is highly appreciated by the firebird users. But I completely disagree with this strategy (mysql follows it too). In the long run you will simply loose more php market in favour of databases with good PDO support. I'm not saying that PDO is perfect (it is not), but pdo adoptions is growing and to be supported by PDO becomes more and more a must. I would to see more databases developers helping the PDO developers to improve it, to add what they need to write good drivers. It will be all benefits for the PHP users and for the DB developers (if they want more customers/users). /utopia --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Lester Caine wrote: I keep being told that the PDO drivers can be extended to include all of the things already available in the native driver, but the second you do that they become incompatible, so in addition to the PDO driver you need to also run the native driver simply to provide the areas NOT covered by PDO. We need a generic framework that addresses the real problems not one that creates an artificial lowest common denominator strangle hold :( PDO could evolve into that, but not with it's current restrictions. Hi Lester, Can you list the current restrictions as you see them? Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_ini.h
Hello, new stage won't ever work, of course. If there's an extension which uses INI_STAGE_ACTIVATE and needs to support new htaccess stage, it can be fixed in source so check for this stage too - but I didn't see such extensions yet. Well I actually know such an extension ;) It is called Suhosin. Well but that support was broken anyway. The sense of the INI_STAGE_ACTIVATE check was to give the admin the possibility to forbid groups of INI_PERDIR to be configured by htaccess. (without setting a default with php_admin_value in httpd.conf for all that should not be under user control.) Actually before your commit that of course never worked correctly and broke INI_PERDIR completely. Now with the new commit I can implement it correctly. However the problem stays that actual binary compatibility is not broken by the check but any extension relying on the new feature might not work correctly. However I think for my purposes I can simply define the INI_STAGE_HTACCESS constant if it does not exist and simply tell everyone to upgrade to a bugfixed version. Haha. Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC1 Released
Hi Lester, On 8/3/07, Lester Caine [EMAIL PROTECTED] wrote: Sorry Pierre I have to disagree there. Most flexible projects are built on ADOdb, and while you CAN use PDO as an alternative driver, for the best performance the raw drivers are preferable. I don't see anything to replace the SQL handling that ADOdb provides although the ADOdbLite does work well if you do not want a fully featured interface and can do without some of the more advanced SQL code. Sorry, I was not clear enough. I did not say that PDO is perfect or can replace MDB2 or ADODb, it is not its goal. Being able to build a project for ANY database is nice to have but requires you manage the SQL as well as the data, and if you are not building a generic project then you don't need a generic driver. A common base is already a (very) good start. We obviously need more and it is unclear how far PHP should go (talking about internals only here). I keep being told that the PDO drivers can be extended to include all of the things already available in the native driver, but the second you do that they become incompatible, so in addition to the PDO driver you need to also run the native driver simply to provide the areas NOT covered by PDO. We need a generic framework that addresses the real problems not one that creates an artificial lowest common denominator strangle hold :( PDO could evolve into that, but not with it's current restrictions. And what do you suggest to improve this situation? One of my suggestions is to have more DB developers (as in DB internals, if I can say so :) involved. Oracle and IBM (to name the largest and most active) understood that and actively participate. I'm not saying that you do nothing, but I'm not sure that complaining about the bad state of pdo_firebird is really helpful. Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: Ext/OpenSSL patch
Ok. :) I will do it on next week. Dmitry. -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Friday, August 03, 2007 8:45 PM To: Sara Golemon Cc: Dmitry Stogov; Stanislav Malyshev; Wez Furlong; Andi Gutmans; Zeev Suraski; internals@lists.php.net Subject: Re: [PHP-DEV] RE: Ext/OpenSSL patch On 8/3/07, Sara Golemon [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: On 8/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote: I won't applay it to HEAD without php-5. I need it in php-5. HEAD may wait. We all need it to 5. But we also need it to test it before it goes to the stable branch. I would really love to get back our _development_ branch. --Pierre We have a development branch: HEAD... Why don't you want Dmitry to commit it to HEAD? You mis read the thread. I want him to commit to HEAD, he does not want to. --Pierre -- 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
