PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (629 total including feature requests)
===[*Compile Issues]==
43389 Open configure ignoring --without-cdb flag
PHP 6 Bug Database summary - http://bugs.php.net
Num Status Summary (65 total including feature requests)
===[*General Issues]==
26771 Suspended register_tick_funtions crash under threaded webservers
43884 Open Object model
I found out the hard way that phpize won't build some extensions like
ext/openssl because they have no config.m4, only a config0.m4. I could not
find a reason why this shouldn't work and propose the patch below for phpize
to support config0.m4 as well as config9.m4.
This will generate a
On 21.01.2008 14:06, Lucas Nealan wrote:
I found out the hard way that phpize won't build some extensions like
ext/openssl because they have no config.m4, only a config0.m4. I could not
find a reason why this shouldn't work and propose the patch below for phpize
to support config0.m4 as well
On Jan 18, 2008 10:07 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi all!
I remember the topic of 'nowdocs' (if you don't remember what it is,
read on) was already discussed, but nothing really happened about it.
For those who just recently woke up from cryogenic sleep :), nowdocs
are
On Jan 21, 2008 2:24 PM, Hannes Magnusson [EMAIL PROTECTED] wrote:
Any objections to this?
No. +1 from me.
+1
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
6 reasons why we must to get rid of The Switch ASAP
1) it gives users false sense of compatibility when no compatibility is even
planned;
2) it's supposed to mean compatibility, but can be changed only in php.ini,
which
means users would
6 reasons why we must to get rid of The Switch ASAP
Couldn't agree more!
Regards
Marco
On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
2) it's supposed to mean compatibility, but can be changed only in
php.ini, which
means users would still have to maintain 2 versions of their software:
one for On and second for Off.
I think this is the biggest issue for anyone writing
On 21 Jan 2008, at 13:24, Hannes Magnusson wrote:
On Jan 18, 2008 10:07 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi all!
I remember the topic of 'nowdocs' (if you don't remember what it is,
read on) was already discussed, but nothing really happened about it.
For those who just
Forgot to CC list.
Original Message
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch
ASAP
Date: Mon, 21 Jan 2008 10:07:43 -0600
From: Jeremy Privett [EMAIL PROTECTED]
Organization: Omega Vortex Corporation
To: Antony Dovgal [EMAIL PROTECTED]
Forgot to CC list again.
Just not my day.
Original Message
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch
ASAP
Date: Mon, 21 Jan 2008 10:11:32 -0600
From: Jeremy Privett [EMAIL PROTECTED]
Organization: Omega Vortex Corporation
To: Geoffrey
On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
3) 2+ bigger codebase [1] (with lots of duplicates because we have to
do
same things in native and unicode modes);
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support — Unicode is only suitable for
Tomas Kuliavas wrote:
On 21 Jan 2008, at 14:38, Antony Dovgal wrote:
3) 2+ bigger codebase [1] (with lots of duplicates because we have to
do
same things in native and unicode modes);
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support
3) 2+ bigger codebase [1] (with lots of duplicates because we have to
do
same things in native and unicode modes);
From the cross-reference I assume you mean PHP's codebase. We still
need binary string support — Unicode is only suitable for textual
content. Images, for example, are binary
Hello Antony,
+1 + thanks, it is simply a ppain in th eass to develop with
7) It alone is responsible for at least 10% slowdown.
marcus
Monday, January 21, 2008, 3:38:00 PM, you wrote:
6 reasons why we must to get rid of The Switch ASAP
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user? Only bad in-house
apps are written for one
Tomas Kuliavas schreef:
me, I'm all for dropping unicode.semantics - Antony makes strong points
and it can only help the quality of the product if exceptions and switchable
functionality is kept to a minimum. from a developers POV the same is true,
additionally 'forcing' unicode on the
Hello Tomas,
you're point being? Without the requested change here you would have one
more version, resulting in PHP 5.*, PHP 6.*-unicode, PHP6.*-native.
marcus
Monday, January 21, 2008, 6:22:32 PM, you wrote:
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would
simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user? Only bad in-house
apps are written for
Hi,
The attached patch (for PHP_5_3) implements the segmented argument_stack
that has the following advantages:
1) It fixes #43426 and other crashes which occur because of stack
reallocation.
2) The whole stack is never reallocated. So we don't have penalties
because of the while stack
Tomas Kuliavas wrote:
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would
simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end user?
On 21 Jan 2008, at 19:38, Tomas Kuliavas wrote:
5) this is yet another reincarnation of ze1_compatibility switch.
Which is the worst mistake ever imo - If you wanted PHP 4 you would
simply
use PHP 4. Now if you want PHP 5 just damn use PHP 5.
And if you don't control PHP version used by end
On Mon, 21 Jan 2008, Antony Dovgal wrote:
6 reasons why we must to get rid of The Switch ASAP
Amen!
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 22.01.2008 01:07, Lucas Nealan wrote:
There is only one extension with config9.m4, the recode extension and it
appears to be using this expressly outside of the context of phpize however
it is not problematic to include this. The other four extensions only have a
config0.m4. Do we prefer to
Hi Dmitry,
The patch looks fine. Although it wastes a bit more memory than the current
implementation, I think it's ok. It also has some memory fragmentation,
which shouldn't be an issue (we don't have functions with 100 arguments :P).
As a side note, I think the following code could be
Zitat von Antony Dovgal [EMAIL PROTECTED]:
6 reasons why we must to get rid of The Switch ASAP
Having maintained a huge Unicode compatible codebase in PHP4 for the
last few years, I know which PITA it already is today, having to
consider the availability of mbstring and iconv, or dealing
Hi,
I agree that having such a switch is not going to be a good strategy. The main
reason is the headache application authors are going to have with compatibility
especially when it comes to hosted pre-configured environments and/or dedicated
servers that run more than one application.
I
Hi Andi,
As we have discussed in the past the migration path may be extremely hard
moving from PHP 5 to PHP 6. Therefore the community has to come together
and really invest in the migration path more than we have in the past
(like we did from version 2 to 3). This means that during the
On 1/21/08 2:33 PM, Antony Dovgal [EMAIL PROTECTED] wrote:
On 22.01.2008 01:07, Lucas Nealan wrote:
There is only one extension with config9.m4, the recode extension and it
appears to be using this expressly outside of the context of phpize however
it is not problematic to include this. The
'Unicode strings would be explicit' is one thing, a Unicode mode that
messes up existing code is quite another. So you're looking at keeping
the support dual but changing the userland approach to it, did I hear
you right?
I think the idea was no php.ini switch, but the question what foo
+1, using 'END' as the syntax.
The ~ version to me implies some kind of bit-flipping operation,
whereas the single quotes remind us that interpolation doesn't happen.
--Wez.
On Jan 18, 2008, at 4:07 PM, Stanislav Malyshev wrote:
Hi all!
I remember the topic of 'nowdocs' (if you don't
I think the idea was no php.ini switch, but the question what foo
should produce - IS_UNICODE or IS_STRING is still open for consideration.
foo alone should produce IS_STRING. The real question IMHO is how far back
do you backport tolerance for a unicode cast.
- Steph
--
PHP Internals -
I see I may not have been clear in my previous email.
Indeed as Stas mentioned I agree we should not have a php.ini switch, i.e.
unicode.semantics goes away.
At the same time I propose:
a) We invest considerable energy in figuring out and documenting the migration
path.
b) We build automated
On Jan 21, 2008, at 7:14 PM, Andi Gutmans wrote:
I see I may not have been clear in my previous email.
Indeed as Stas mentioned I agree we should not have a php.ini
switch, i.e. unicode.semantics goes away.
At the same time I propose:
a) We invest considerable energy in figuring out and
Antony Dovgal wrote:
6 reasons why we must to get rid of The Switch ASAP
1) it gives users false sense of compatibility when no compatibility is even
planned;
2) it's supposed to mean compatibility, but can be changed only in php.ini, which
As for PHP 6 generally: there needs to be a solid migration path,
such as forwards-compatible syntax introduced to PHP 5. MediaWiki
has extensive support for unicode in PHP 5, including a pure PHP
implementation of NFC, cross-script and confusable character
checks, extensive parsing of
Without repeating too much of what has already been said, phpBB3 runs
with its own normalizer (NF[CD]K?) and a full implementation of case
folding along with all sorts of other goodies. For us, it would be best
if semantics were off. Then we could trivially determine whether or not
we should
See below:
-Original Message-
From: Andrei Zmievski [mailto:[EMAIL PROTECTED]
Sent: Monday, January 21, 2008 8:23 PM
To: Andi Gutmans
Cc: Steph Fox; Stas Malyshev; Antony Dovgal; internals@lists.php.net
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch
ASAP
2008/1/21, Antony Dovgal [EMAIL PROTECTED]:
6) we need to remove the switch ASAP
Yes :) I urge you to do this, the introduction of this setting is
probably the worst design mistake in PHP history after safe_mode and
register_globals .
Please withdrawn this insanity before it is too late, if
On 22.01.2008, at 04:14, Andi Gutmans wrote:
I don't think this affects PHP 5.3 (http://wiki.pooteeweet.org/PhP53VoteResult
) which I believe we're making good progress on. It allows us to get
some of those features out earlier including things like namespaces
which the various framework
41 matches
Mail list logo
