FAQ
Hi,

The second beta for 5.6.0 was just released and can be downloaded from:

     http://qa.php.net/

The Windows binaries are available at

     http://windows.php.net/qa/

This release includes a couple of new features, such as:

    - Watchpoint support for phpdbg
    - A new fetching mode to mysqlnd which uses less memory but implies more
    memory copy

Please test it carefully, and report any bugs in the bug system.
Beta 3 will be tagged on Tuesday 13th and release on Thursday 15th.

Regards,
     Julien Pauli and Ferenc Kovacs

Search Discussions

  • Ferenc Kovacs at May 2, 2014 at 4:11 pm

    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
  • Ferenc Kovacs at May 2, 2014 at 4:28 pm

    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
  • Jan Ehrhardt at May 2, 2014 at 4:39 pm
    Ferenc Kovacs in php.internals (Fri, 2 May 2014 18:28:12 +0200):
    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.
    You can add xcache and qb to the list. QB is a Pecl extension nowadays
    and xcache probably never will be.

    Jan
  • Bob Weinand at May 2, 2014 at 4:48 pm

    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.

    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…

    Bob




    Bob
  • Ferenc Kovacs at May 2, 2014 at 5:02 pm

    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.
    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
  • Bob Weinand at May 2, 2014 at 5:14 pm

    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>:
    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.

    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
    Yeah, I agree. But it finally was relatively late when I saw that bug.
    And I knew PHP 5.6 bids now the possibility to fix the bug, so why not.

    Also I think that fix was a good idea as it's at the same time a nice refactor
    of some hackish things for constant keys.

    I hope we can now agree that it wasn't a so bad idea...
    Bob
  • Jan Ehrhardt at May 2, 2014 at 5:17 pm
    Ferenc Kovacs in php.internals (Fri, 2 May 2014 19:02:13 +0200):
    On Fri, May 2, 2014 at 6:48 PM, Bob Weinand wrote:
    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
    At least 14 extensions will have to adjust their code and differentiate
    between pre and post 5.6.
    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).
    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.

    Jan
  • Nikita Popov at May 2, 2014 at 5:56 pm

    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):
    On Fri, May 2, 2014 at 6:48 PM, Bob Weinand wrote:
    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
    At least 14 extensions will have to adjust their code and differentiate
    between pre and post 5.6.
    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).
    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.
    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
  • Ferenc Kovacs at May 2, 2014 at 7:30 pm

    On Fri, May 2, 2014 at 7:56 PM, Nikita Popov wrote:
    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):
    On Fri, May 2, 2014 at 6:48 PM, Bob Weinand wrote:
    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
    At least 14 extensions will have to adjust their code and differentiate
    between pre and post 5.6.
    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).
    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.
    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
    To quote the releaseprocess rfc: "ABI and API can be broken (internals),
    src compatibility should be kept if possible, while breakages are allowed",
    and imo nobody said here that we can't change internal API, but we were
    talking about whether or not it worth or is the API change mandatory for
    the bugfix which introduced it.
    About the zend_is_true change, I think that the problem is that people
    don't really care about changes like that as long as it goes to master, and
    we always (since from like 5.4) end up branching from master, with all the
    changes in it.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Jan Ehrhardt at May 2, 2014 at 4:50 pm
    Ferenc Kovacs in php.internals (Fri, 2 May 2014 18:28:12 +0200):
    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.
    The hammer on the nail. I will not promote beta2 on Apachelounge because
    of these BC breaks.

    Jan
  • Bob Weinand at May 2, 2014 at 4:38 pm

    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).

    This at least ensures that you notice the problem. And prevents other
    people complaining about a bug you maybe don't find so easily.

    I just did what seemed the most sensible thing to me.

    Bob
  • Hannes Magnusson at May 2, 2014 at 6:50 pm

    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).
    Fair enough.
    Can you please fix the language in the upgrading file though?
    This is very disrespectful and I shouldn't have to read internal
    argument you have with someone in upgrade documentations.

    This at least ensures that you notice the problem. And prevents other
    people complaining about a bug you maybe don't find so easily.

    I think the value needs to be modified - for the same reason as you renamed it.

    Who knows, maybe someone has #ifndef..#define is_constant_array .. as
    it was a new addition at some point.

    Now that code will kick in again and cause you whatever subtle issues
    you are indicating as the reason for the rename.

    -Hannes
  • Pierre Joye at May 2, 2014 at 9:27 pm
    hi Bob,
    On Fri, May 2, 2014 at 6:38 PM, 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.
    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?
    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).

    This at least ensures that you notice the problem. And prevents other
    people complaining about a bug you maybe don't find so easily.

    I just did what seemed the most sensible thing to me.
    It is, there is only little gain to remove it just to remove it.

    Either way I am fine with the changes, but other may not.

    ps: there is no need to get such bad wording to discuss technical
    issues. There are people here actually doing the job, and doing it
    great. A bit of respect would be more than welcome. Bob is one of
    them.

    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Bob Weinand at May 2, 2014 at 10:32 pm

    Am 2.5.2014 um 23:27 schrieb Pierre Joye <pierre.php@gmail.com>:
    hi Bob,
    On Fri, May 2, 2014 at 6:38 PM, 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.
    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?
    It isn't the same. IS_CONSTANT_ARRAY is using zvalue_value.ht and
    IS_CONSTANT_AST is using zvalue_value.ast.
    If I'd made them an alias, that'd be totally confusing.

    It's just IS_CONSTANT_ARRAY which could disappear as it isn't needed anymore
    and IS_CONSTANT_AST now used the free gap there.

    It really should break the extensions there just as a hint to the maintainer that they
    need an update.
    Also if these extensions all needed to handle IS_CONSTANT_ARRAY, they probably
    will need a specific handling for IS_CONSTANT_AST, too.

    If I hadn't removed the IS_CONSTANT_ARRAY, people might only notice the bug
    (which appears due to inexistent IS_CONSTANT_AST handling) at PHP run-time,
    maybe only after 5.6 release. This removal sets a clear signal that these extensions
    need some update. It's at the same time the easiest to debug for maintainers when
    they get an error when compiling the extension...
    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).

    This at least ensures that you notice the problem. And prevents other
    people complaining about a bug you maybe don't find so easily.

    I just did what seemed the most sensible thing to me.
    It is, there is only little gain to remove it just to remove it.

    Either way I am fine with the changes, but other may not.

    ps: there is no need to get such bad wording to discuss technical
    issues. There are people here actually doing the job, and doing it
    great. A bit of respect would be more than welcome. Bob is one of
    them.

    --
    Pierre

    @pierrejoye | http://www.libgd.org
    Thank you for the kind words :-)

    Bob

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 2, '14 at 7:36a
activeMay 2, '14 at 10:32p
posts15
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase