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
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: [
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 S
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
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 wan
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 o
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 is
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
[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 _develo
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, a
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/R
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 with
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
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://
> > > >> 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
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 righ
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 rsy
> > 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
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
> 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
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 lik
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
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
>
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
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
> 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 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-o
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/
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
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
> >
>
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
> -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
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
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 ex
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 w
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 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
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
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 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
> 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
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
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
--
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(.
67 matches
Mail list logo
