5.2.4RC1 Released

Edin Kadribasic

19 years ago

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGsqgAoL7jghV9D6gRAlHnAJ4zqzKikiBgffzvQBQqLBsASJoa3wCgy+fR
bSR1MvfCW25LqASgYiELIpo=
=j3j0
-----END PGP SIGNATURE-----

Scott MacVicar

19 years ago

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:

Antony Dovgal

19 years ago

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

Uwe Schindler

19 years ago

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
pangaeaw@pansrv1:~/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 1>&5
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 1>&5
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
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

Antony Dovgal

19 years ago

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
> pangaeaw@pansrv1:~/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("aaaaa", "r");'

Warning: fopen(aaaaa): failed to open stream: No such file or directory in Command line code on line 1
./sapi/cli/php -r '@fopen("aaaaa", "r");'
<silence>

> 2) make test is broken:
> pangaeaw@pansrv1:~/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

Uwe Schindler

19 years ago

> 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
> > pangaeaw@pansrv1:~/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("aaaaa", "r");'
>
> Warning: fopen(aaaaa): failed to open stream: No such file or directory in
> Command line code on line 1
> ./sapi/cli/php -r '@fopen("aaaaa", "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

Antony Dovgal

19 years ago

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("aaaa", "r");

No idea how the sun webserver passes options to PHP, though.

--
Wbr,
Antony Dovgal

Uwe Schindler

19 years ago

> >> 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

pangaeaw@pansrv1:~/install/php-5.2.4RC1$ ls -l /bin/sh
lrwxrwxrwx   1 root     root          13 Apr 13 10:40 /bin/sh ->
../../sbin/sh
pangaeaw@pansrv1:~/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("aaaa", "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.

Antony Dovgal

19 years ago

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

Uwe Schindler

19 years ago

> > 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.8&r2=1.39
.2.2.2.9&pathrev=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 internals@.

Antony Dovgal

19 years ago

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.8&r2=1.39
> .2.2.2.9&pathrev=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

Uwe Schindler

19 years ago

> 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.8&r2=1.
> 39
> > .2.2.2.9&pathrev=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

Jani Taskinen

19 years ago

On Fri, 2007-08-03 at 08:32 +0200, Uwe Schindler wrote:

> Generating files
> /configure: test: argument expected
> pangaeaw@pansrv1:~/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

Uwe Schindler

19 years ago

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:
pangaeaw@pansrv1:~/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
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

Lester Caine

19 years ago

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

Antony Dovgal

19 years ago

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.13&r2=1.9.2.2

--
Wbr,
Antony Dovgal

Lester Caine

19 years ago

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.13&r2=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

Antony Dovgal

19 years ago

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

Pierre Joye

19 years ago

On 8/3/07, Antony Dovgal <antony@zend.com> 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

Lester Caine

19 years ago

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

Antony Dovgal

19 years ago

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

Lester Caine

19 years ago

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

Antony Dovgal

19 years ago

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

Lester Caine

19 years ago

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 '0x0000000f00000123' 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

Lorenzo Alberton

19 years ago

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

Lester Caine

19 years ago

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

Pierre Joye

19 years ago

Hi Lester,

On 8/3/07, Lester Caine <lester@lsces.co.uk> 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

Lester Caine

19 years ago

Pierre wrote:

> Hi Lester,
>
> On 8/3/07, Lester Caine <lester@lsces.co.uk> 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>

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. 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.

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.

--
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

Christopher Jones

19 years ago

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: christopher.jones@oracle.com    Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/   Free PHP Book: http://tinyurl.com/f8jad

Pierre Joye

19 years ago

Hi Lester,

On 8/3/07, Lester Caine <lester@lsces.co.uk> 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

Jordan Wambaugh

19 years ago

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

Sebastian Bergmann

19 years ago

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

Jordan Wambaugh

19 years ago

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

Matteo Beccati

19 years ago

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

5.2.4RC1 Released

Ilia A.

Edin Kadribasic

Scott MacVicar

Antony Dovgal

Uwe Schindler

Antony Dovgal

Uwe Schindler

Antony Dovgal

Uwe Schindler

Antony Dovgal

Uwe Schindler

Antony Dovgal

Uwe Schindler

Jani Taskinen

Uwe Schindler

Lester Caine

Antony Dovgal

Lester Caine

Antony Dovgal

Pierre Joye

Lester Caine

Antony Dovgal

Lester Caine

Antony Dovgal

Lester Caine

Lorenzo Alberton

Lester Caine

Pierre Joye

Lester Caine

Christopher Jones

Pierre Joye

Jordan Wambaugh

Sebastian Bergmann

Jordan Wambaugh

Matteo Beccati