On 04.08.2007 10:42, Lester Caine wrote:
> 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.
See the other post. I am not 'complaining' about the fact that no one is
willing to spend unpaid time on pdo_firebird, just
Hi Lester,
On 8/4/07, Lester Caine <[EMAIL PROTECTED]> wrote:
> Pierre wrote:
> > 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
Pierre wrote:
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.
And IBM have a commercial intere
Christopher Jones wrote:
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
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
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 are
Pierre wrote:
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
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 ne
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 loa
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 Inte
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 i
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
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 exha
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?
--
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 u
> > > >> 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 z
> > 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
> 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 ne
n, 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,
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
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 t
> 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
>
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
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
chindler
> [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
> >
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 sett
CTED]
> 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
> 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
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 -
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.z
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 Webserv
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 t
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 t
> > 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 scr
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
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
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 curre
> >> 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 sh
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 syst
> 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...
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 whe
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 caus
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
--
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.4RC
PI 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
-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
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 bee
47 matches
Mail list logo
