[PHP-INTERNALS] PHP 5.6.0beta2 Released for Testing!

On Fri, May 2, 2014 at 5:52 PM, Hannes Magnusson wrote:
please


l. Removal of IS_CONSTANT_ARRAY and IS_CONSTANT_INDEX hack

These two #defines disappeared. Instead we have now IS_CONSTANT_AST which
covers also the functionality IS_CONSTANT_ARRAY bid and furthermore the
hack for marking zvals as constant index with IS_CONSTANT_INDEX is now
superfluous and so removed.
Please note that IS_CONSTANT_AST now has the same value than
IS_CONSTANT_ARRAY had.


Could someone be.. like just a tiny littlebit more professional then
to shit over other people work in the upgrading notes?
This is not the place for to show off how much better you are then
everyone else.

And why does it have to be renamed anyway? It has the same value. Does
the same thing. It just got renamed to piss over people?

-Hannes

--
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

On Fri, May 2, 2014 at 6:11 PM, Ferenc Kovacs wrote:

moving the discussion to internals@, CCing Bob, as he is the author of
the change.
To my understanding this change was made to fix
https://bugs.php.net/bug.php?id=66015
I was aware that it is a BC break, but I didn't realized that it will
affect other extensions before the first report from the wincache dev
arrived.
Not sure if removing this #defines is really neccessary to fix the bug
mentioned above.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Am 2.5.2014 um 18:28 schrieb Ferenc Kovacs <tyra3l@gmail.com>:
from a quick search search on lxr.php.net the following extensions are
using IS_CONSTANT_ARRAY or IS_CONSTANT_INDEX

- PHK
- Parse_Tree
- automap
- bcompiler
- hidef
- AOP
- yaf
- APC
- ZendOpcache
- APCu
- vld
- WinCache

and probably a couple of other exts which isn't on lxr.
whats even more interesting is that ext/opcache still referencing both of
those, so it isn't even cleaned up from php-src.
what is the current workflow for opcache these days? I know that they have
their own repo, and they are merging from there to php-src.git and that
they are also maintain compatibility with lower versions for installing
opcache via pecl, so maybe it is normal to have those references?

personally I think that compatibility with already existing extensions is
pretty important, because that is a major reason which holds back people
from upgrading to new php versions early.
so internal API breaks like that should happen early in the development
process, have a clear communication and should be always for a good reason.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Fri, May 2, 2014 at 6:48 PM, Bob Weinand wrote:

Am 2.5.2014 um 18:28 schrieb Ferenc Kovacs <tyra3l@gmail.com>:

On Fri, May 2, 2014 at 6:11 PM, Ferenc Kovacs wrote:

On Fri, May 2, 2014 at 5:52 PM, Hannes Magnusson wrote:

On Fri, May 2, 2014 at 6:17 AM, Jan Ehrhardt wrote:

Ferenc Kovacs in php.qa (Fri, 2 May 2014 12:42:55 +0200):

ext\apcu\apc_bin.c(238) : error C2065: 'IS_CONSTANT_ARRAY' :

undeclared

identifier


Afair this was mentioned in UPGRADING.INTERNALS, if I remember wrong

please

open a bugreport.


Might be that it is mentioned there (did not check yet), but to an
innocent bystander it looks like a BC break between beta1 and beta2.




l. Removal of IS_CONSTANT_ARRAY and IS_CONSTANT_INDEX hack

These two #defines disappeared. Instead we have now IS_CONSTANT_AST
which
covers also the functionality IS_CONSTANT_ARRAY bid and furthermore the
hack for marking zvals as constant index with IS_CONSTANT_INDEX is now
superfluous and so removed.
Please note that IS_CONSTANT_AST now has the same value than
IS_CONSTANT_ARRAY had.


Could someone be.. like just a tiny littlebit more professional then
to shit over other people work in the upgrading notes?
This is not the place for to show off how much better you are then
everyone else.

And why does it have to be renamed anyway? It has the same value. Does
the same thing. It just got renamed to piss over people?

-Hannes

--
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php


moving the discussion to internals@, CCing Bob, as he is the author of
the change.
To my understanding this change was made to fix
https://bugs.php.net/bug.php?id=66015
I was aware that it is a BC break, but I didn't realized that it will
affect other extensions before the first report from the wincache dev
arrived.
Not sure if removing this #defines is really neccessary to fix the bug
mentioned above.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu


from a quick search search on lxr.php.net the following extensions are
using IS_CONSTANT_ARRAY or IS_CONSTANT_INDEX

- PHK
- Parse_Tree
- automap
- bcompiler
- hidef
- AOP
- yaf
- APC
- ZendOpcache
- APCu
- vld
- WinCache


and probably a couple of other exts which isn't on lxr.
whats even more interesting is that ext/opcache still referencing both of
those, so it isn't even cleaned up from php-src.
what is the current workflow for opcache these days? I know that they have
their own repo, and they are merging from there to php-src.git and that
they are also maintain compatibility with lower versions for installing
opcache via pecl, so maybe it is normal to have those references?

personally I think that compatibility with already existing extensions is
pretty important, because that is a major reason which holds back people
from upgrading to new php versions early.
so internal API breaks like that should happen early in the development
process, have a clear communication and should be always for a good reason.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu


At the time when doing this change, I had fixed all the bundled extensions.

So, e.g. opcache shouldn't be a problem.

Am 2.5.2014 um 19:02 schrieb Ferenc Kovacs <tyra3l@gmail.com>:
On Fri, May 2, 2014 at 6:48 PM, Bob Weinand wrote:
Am 2.5.2014 um 18:28 schrieb Ferenc Kovacs <tyra3l@gmail.com>:
At the time when doing this change, I had fixed all the bundled extensions.

So, e.g. opcache shouldn't be a problem.

my bad, on a closer look, I can see that in ext/opcache it is conditional:
#if ZEND_EXTENSION_API_NO <= PHP_5_5_API_NO
case IS_CONSTANT_ARRAY:
#endif

Actually, I made the commit beginning of April, I think that are nearly
three months time to fix the extensions. I doubt that isn't enough…

maybe, I just wish this could have happened a bit earlier in the process, and if we could have communicated it better (instead of waiting for the first ext dev to complain).

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Fri, May 2, 2014 at 7:17 PM, Jan Ehrhardt wrote:

Ferenc Kovacs in php.internals (Fri, 2 May 2014 19:02:13 +0200):
extensions.
At least 14 extensions will have to adjust their code and differentiate
between pre and post 5.6.
Even with excellent communication it is hard to reach every dev. Xcache
is one example of an extension with little connections to the PHP
community. I think it will take a consirable time before Xcache is fit
for 5.6. there may be many more extensions out there that suddenly will
break.

This will be a real hindrance to the acceptance of 5.6.

On Fri, May 2, 2014 at 7:56 PM, Nikita Popov wrote:
conditional:
nearly
process,
I feel like this issue is being taken somewhat out of proportions.

PHP does not provide binary or extension source compatibility between minor
versions. The API stays mostly the same, but there are always a few
breakages to extensions. For example PHP 5.6 (unnecessarily) changed the
signature of the zend_is_true function - *that* a change that will require
changes to many extensions (grumble, grumble :)

The IS_CONSTANT_ARRAY change on the other hand is constrained to very few,
low-level Zend extensions (like bytecode caches or debuggers), which
operate directly on VM oplines. The breakages between versions are usually
a lot larger in this area than in the other, "normal" parts of the API.
People writing this kind of extension are aware of that and used to it.
Expecting the opcache source for 5.5 to be compatible with the 5.6 executor
would be pretty crazy.

Nikita

Am 2.5.2014 um 18:11 schrieb Ferenc Kovacs <tyra3l@gmail.com>:
moving the discussion to internals@, CCing Bob, as he is the author of the
change.
To my understanding this change was made to fix
https://bugs.php.net/bug.php?id=66015
I was aware that it is a BC break, but I didn't realized that it will
affect other extensions before the first report from the wincache dev
arrived.
Not sure if removing this #defines is really neccessary to fix the bug
mentioned above.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

On Fri, May 2, 2014 at 9:38 AM, Bob Weinand wrote:
Am 2.5.2014 um 18:11 schrieb Ferenc Kovacs <tyra3l@gmail.com>:

On Fri, May 2, 2014 at 5:52 PM, Hannes Magnusson wrote:

On Fri, May 2, 2014 at 6:17 AM, Jan Ehrhardt wrote:

Ferenc Kovacs in php.qa (Fri, 2 May 2014 12:42:55 +0200):

ext\apcu\apc_bin.c(238) : error C2065: 'IS_CONSTANT_ARRAY' : undeclared
identifier


Afair this was mentioned in UPGRADING.INTERNALS, if I remember wrong

please

open a bugreport.


Might be that it is mentioned there (did not check yet), but to an
innocent bystander it looks like a BC break between beta1 and beta2.




l. Removal of IS_CONSTANT_ARRAY and IS_CONSTANT_INDEX hack

These two #defines disappeared. Instead we have now IS_CONSTANT_AST which
covers also the functionality IS_CONSTANT_ARRAY bid and furthermore the
hack for marking zvals as constant index with IS_CONSTANT_INDEX is now
superfluous and so removed.
Please note that IS_CONSTANT_AST now has the same value than
IS_CONSTANT_ARRAY had.


Could someone be.. like just a tiny littlebit more professional then
to shit over other people work in the upgrading notes?
This is not the place for to show off how much better you are then
everyone else.

And why does it have to be renamed anyway? It has the same value. Does
the same thing. It just got renamed to piss over people?

-Hannes

--
PHP Quality Assurance Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php


moving the discussion to internals@, CCing Bob, as he is the author of the
change.
To my understanding this change was made to fix
https://bugs.php.net/bug.php?id=66015
I was aware that it is a BC break, but I didn't realized that it will
affect other extensions before the first report from the wincache dev
arrived.
Not sure if removing this #defines is really neccessary to fix the bug
mentioned above.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu


It maybe does the same thing, but it needs other handling.
(IS_CONSTANT_AST in reality covers also many other cases, not
just arrays).

If I hadn't renamed the constant, it might eventually still compile fine,
but the program would get crashes you don't notice when not testing
a very specific subset of the language in combination with the AST.
(In reality the AST is more an addition and now when fixing bug 66015
much later, IS_CONSTANT_AST became superfluous and so was removed).

Am 2.5.2014 um 23:27 schrieb Pierre Joye <pierre.php@gmail.com>:
hi Bob,
As I do not mind API changes between two x.y versions (it is allowed),
I wonder why removing it is a good thing. Given that IS_CONSTANT_AST
and IS_CONSTANT_ARRAY have the same values, the behaviors are the
same. Keeping the old and document it as alias.Or am I missing
something?