Add new PEAR package:
http://pear.php.net/pepr/pepr-proposal-show.php?id=426
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
to standardize the php code
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Naïve. Most core developers will spend their time and energy on PHP 6, and
you will quickly see non-Unicode features being added to PHP 6 and not other
versions. It's always been like that in PHP's history.
Andi
> -Original Message-
> From: Steph Fox [mailto:[EMAIL PROTECTED]
> Sent: Wed
Hello!
A gcov test run has just been finished on the PHP_5_2 branch.
You can view the make log here: http://gcov.php.net/PHP_5_2/make.log.php
You can watch the test results: http://gcov.php.net/PHP_5_2/run-tests.log.php
And you can watch gcov results: http://gcov.php.net/PHP_5_2/lcov/index.php
Can anyone explain to me why it would be such a big problem to support PHP 6
and PHP 5 alongside one another? With PHP 6 effectively being a
Unicode-supporting version of PHP 5?
Or am I being weird and naive here?
- Steph
As Andrei knows, I believe that not allowing to tune this on a per vi
Andrei Zmievski wrote:
> 1. ZEND_INI_SYSTEM and make people run two copies of Apache if they
> want
> both modes. This is architecturally more simple and more robust, I
> believe.
> 2. ZEND_INI_PERDIR and let people switch modes as described above. This
> is a lot of work and will probably res
I think making it INI_PERDIR would mean a lot of headache and overcomplicated
code in the engine and the extensions that modify its behaviour (like APC).
i don't guess so. it's sure need upgrade but easy to implement, simply
put unicode.semantics into entry key, and hash/search by the key.
--
P
Hello Andrei,
we have already a freaking complexapi to deal with and on the other hand
we have fastcgisupport. What we should imo do is trying to drop complexity
of our api and not increase it to an unhandable extreme and instead promote
usage of fastcgi. My 2c.
best regards
marcus
Wednesday,
Stanislav Malyshev wrote:
>> I suggest to first make the theoreticaly decision that we prefer to support
>> this on a per-request if it's feasible. When I say feasible it means with
>>
> Per-request is very problematic with regard to bytecode caches, for
> obvious reasons. However, per-virtual-d
> I suggest to first make the theoreticaly decision that we prefer to support
> this on a per-request if it's feasible. When I say feasible it means with
>
Per-request is very problematic with regard to bytecode caches, for
obvious reasons. However, per-virtual-dir may work for this, i.e. if
ea
On 06/09/06, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Well to me its still not clear how much code will remain working with
PHP6 given the confusing situation about E_STRICT, deprecation, OO
purity-changes.
Maybe its more feasible to work on making it easier for people to run
different PHP
On 6-Sep-06, at 3:48 PM, Lukas Kahwe Smith wrote:
boots wrote:
Well, with unicode semantics enabled, many PHP applications that
have not been designed with PHP6+unicode in mind are likely to
break. On the other hand when semantics are off, those
applications may work just fine. The ot
boots wrote:
Well, with unicode semantics enabled, many PHP applications that have
not been designed with PHP6+unicode in mind are likely to break. On
the other hand when semantics are off, those applications may work
just fine. The other reason could be that unicode enabled PHP will be
n
Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
On 6-Sep-06, at 2:28 PM, M. Sokolewicz wrote:
> Ilia Alshanetsky wrote:
>
>> From a technical perspective it makes sense to keep it php.ini
>> only setting or as Sara insists (STARTUP phase only). However,
>> from a user (hosting companies) perspe
As Andrei knows, I believe that not allowing to tune this on a per virtual
host basis, is going to make life very hard for our users. A huge part of
our users are hosting providers, or companies running multiple applications
on the same machine. Probably a majority do not own dedicated boxes. This
Richard Quadling wrote:
> I agree on this. From my reading of some the issues around unicode you are
> far better off simply saying PHP6 is unicode only. A lot of scripts that
You didn't address the point of people who don't need Unicode but need
the fast possible version (because slower running t
On 06/09/06, M. Sokolewicz <[EMAIL PROTECTED]> wrote:
My personal opinion, as humble as it may be, is that it's pure bullshit
to even give the chance of disabling it. WHY in hell's name would you
want to give hoster's the choice? I can see a part of the hosts
disabling it to "give an easy transi
On 6-Sep-06, at 2:28 PM, M. Sokolewicz wrote:
Ilia Alshanetsky wrote:
From a technical perspective it makes sense to keep it php.ini
only setting or as Sara insists (STARTUP phase only). However,
from a user (hosting companies) perspective it adds a fair degree
of complexity to their
As I said, I think we should keep status quo for now and not change the
static linking that we've done for the past few years. I thought my previous
email was clear.
> -Original Message-
> From: Rob Richards [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 06, 2006 3:21 AM
> To: An
Ilia Alshanetsky wrote:
From a technical perspective it makes sense to keep it php.ini only
setting or as Sara insists (STARTUP phase only). However, from a user
(hosting companies) perspective it adds a fair degree of complexity to
their setup, which would probably mean one php6 instance
Hello,
On 9/6/06, Andrei Zmievski <[EMAIL PROTECTED]> wrote:
1. ZEND_INI_SYSTEM and make people run two copies of Apache if they
want both modes. This is architecturally more simple and more robust, I
believe.
I believe that too. It is not only more robust but will also ease your/our life.
From a technical perspective it makes sense to keep it php.ini only
setting or as Sara insists (STARTUP phase only). However, from a user
(hosting companies) perspective it adds a fair degree of complexity
to their setup, which would probably mean one php6 instance will need
to run as CGI o
thats seksi nice work ;-)
On 9/6/06, Nuno Lopes <[EMAIL PROTECTED]> wrote:
Hello,
I've made a somewhat simple script that is capable of running a few
diagnostic tests on zend_parse_parameters() usage. This tests include
reports from possible segfaults to possible optimizations.
The script stil
I was thinking in integrating it in http://gcov.php.net, as soon as the new
website is ready and on-line, but I can put this text-only version in that
dir (or maybe in scripts/dev).
Nuno
- Original Message -
Excellent. Can you check that into CVS? Maybe in scripts/ ?
-Andrei
On Se
Excellent. Can you check that into CVS? Maybe in scripts/ ?
-Andrei
On Sep 6, 2006, at 9:59 AM, Nuno Lopes wrote:
Hello,
I've made a somewhat simple script that is capable of running a few
diagnostic tests on zend_parse_parameters() usage. This tests include
reports from possible segfault
On Wed, 6 Sep 2006, Michael Wallner wrote:
> Andrei Zmievski wrote:
>
> > 1. ZEND_INI_SYSTEM and make people run two copies of Apache if they want
> > both modes. This is architecturally more simple and more robust, I believe.
> > 2. ZEND_INI_PERDIR and let people switch modes as described above.
Hello,
I've made a somewhat simple script that is capable of running a few
diagnostic tests on zend_parse_parameters() usage. This tests include
reports from possible segfaults to possible optimizations.
The script still needs a lot of tweaking, but is already capable of spotting
some real b
On 06.09.2006 20:39, Andrei Zmievski wrote:
We really need to settle on whether we want unicode.semantics to be
changeable at runtime or not. During early development it was
ZEND_INI_PERDIR, meaning that it could be changed in .htaccess and
VirtualHost blocks. However, the infrastructure to s
Andrei Zmievski wrote:
> 1. ZEND_INI_SYSTEM and make people run two copies of Apache if they want
> both modes. This is architecturally more simple and more robust, I believe.
> 2. ZEND_INI_PERDIR and let people switch modes as described above. This
> is a lot of work and will probably result in q
> 1. ZEND_INI_SYSTEM and make people run two copies of Apache if they want
> both modes. This is architecturally more simple and more robust, I believe.
> 2. ZEND_INI_PERDIR and let people switch modes as described above. This
> is a lot of work and will probably result in quite a few edge cases
>
Andrei Zmievski wrote:
>> - mb_output_handler: obsolete?
>> - ob_iconvhandler: obsolete?
>
> While unicode.output_encoding does obsolete these handlers, it is only
> turned on when unicode.semantics=on. I think we need to keep these for
> those who will not turn on the Unicode mode.
Ah,
We really need to settle on whether we want unicode.semantics to be
changeable at runtime or not. During early development it was
ZEND_INI_PERDIR, meaning that it could be changed in .htaccess and
VirtualHost blocks. However, the infrastructure to support this
flexibility was deemed too complic
- mb_output_handler: obsolete?
- ob_iconvhandler: obsolete?
While unicode.output_encoding does obsolete these handlers, it is only
turned on when unicode.semantics=on. I think we need to keep these for
those who will not turn on the Unicode mode.
-Andrei
--
PHP Internals -
Uh, yea I have been proposing a change (first made on 8/10, but had been
waiting for the 4.4 and 5.1 releases to be finished).
.oO(Would have been nice is people mentioned any objections/issues way
back then)
http://news.php.net/php.internals/25300
So you really think that making registry c
34 matches
Mail list logo
