Hi,
This is just a reminder from your friendly co-RMs that the PHP 5.3
feature freeze is rapidly approaching:
http://wiki.php.net/todo/php53
As you can see there are still a bunch of open topics. For the very
important ones we have tried to contact the authors and work out a
schedule to get them done. If there is anything missing on this list
please make sure to let us know ASAP (or forever hold your peace).
Please try to get your items done today or over the course of tomorrow
(we are not giving a specific timezone, but try for sooner rather than
later ..). Once we have reached the 25th, we will start being a bit
more strict, so again please make sure we know about the things you
want to do (this includes bug fixes - which we might deem feature
changes) so that things will go smoothly for an alpha1 on the 31st.
Thank you all for the work that has been done in the past weeks.
Things are shaping up nicely. My main worry point atm is that we are
not sure about the status of re2c.
regards,
Johannes and Lukas
Hi Lukas, all,
Don't know if my two Zend-related patches can be used, or how much time
there is to add them (after alpha 1...?). Waiting to hear about "No runtime
fetching of built-in global constants." And the second, "Some string
changes/optimizations," I'm sure it's fine to update the syntax highlighting
and remove the duplicate NOWDOC-related things (pretty trivial). Just
wondering if the removal of the INIT_STRING opcode is acceptable.
Otherwise... 1) As far as any of those re2c issues, I don't know about
fixing them, and the few extra scanner tweaks/optimizations I said I had in
mind can be done anytime. 2) There's a small bug (forever?) with handling
of numeric string array keys (of LONG_MAX/LONG_MIN). Simple, will fix next,
since you mentioned bugs. 3) The change that was made to the DVAL_TO_LVAL()
macro, which I think should be reverted. Will send a follow-up reminder in
a minute about that.
Finally, there are a couple small things I had in mind for a while to send
along sometime for opinions (haven't done any yet):
*) Some consistency updates for formatted print (printf) stuff -- userland
function and internal. Been a long time since I looked at any of it, so not
sure about specifics!
*) A small heredoc syntax addition after seeing an old feature request.
*) Fix for old behavior/bug with preg_replace()
and /e modifier where it
causes weird escaping of quotes. Though this could mess up people that are
using their own workaround as I would have, unless it's a flag/option.
I know it may be too late for these things :*/, but just wanted to mention
them, and I'd still send them to the list if done... I wouldn't consider
them major or dangerous.
Thanks Johannes and Lukas!
- Matt
----- Original Message -----
From: "Lukas Kahwe Smith"
Sent: Wednesday, July 23, 2008
Hi,
This is just a reminder from your friendly co-RMs that the PHP 5.3
feature freeze is rapidly approaching:
http://wiki.php.net/todo/php53As you can see there are still a bunch of open topics. For the very
important ones we have tried to contact the authors and work out a
schedule to get them done. If there is anything missing on this list
please make sure to let us know ASAP (or forever hold your peace).Please try to get your items done today or over the course of tomorrow
(we are not giving a specific timezone, but try for sooner rather than
later ..). Once we have reached the 25th, we will start being a bit
more strict, so again please make sure we know about the things you
want to do (this includes bug fixes - which we might deem feature
changes) so that things will go smoothly for an alpha1 on the 31st.Thank you all for the work that has been done in the past weeks.
Things are shaping up nicely. My main worry point atm is that we are
not sure about the status of re2c.regards,
Johannes and Lukas
Hello Lukas,
Wednesday, July 23, 2008, 1:26:00 PM, you wrote:
Hi,
This is just a reminder from your friendly co-RMs that the PHP 5.3
feature freeze is rapidly approaching:
http://wiki.php.net/todo/php53
As you can see there are still a bunch of open topics. For the very
important ones we have tried to contact the authors and work out a
schedule to get them done. If there is anything missing on this list
please make sure to let us know ASAP (or forever hold your peace).
Please try to get your items done today or over the course of tomorrow
(we are not giving a specific timezone, but try for sooner rather than
later ..). Once we have reached the 25th, we will start being a bit
more strict, so again please make sure we know about the things you
want to do (this includes bug fixes - which we might deem feature
changes) so that things will go smoothly for an alpha1 on the 31st.
Thank you all for the work that has been done in the past weeks.
Things are shaping up nicely. My main worry point atm is that we are
not sure about the status of re2c.
After alpha1 I will release a new re2c version: 0.14.0.
I also have to do a few internal API changes:
-
exception handling, two new functions and a modified one plus a structure
change. All of these changes deal with mem leaks in exception handling.
However I haven't fixed all issues yet. -
changing the error mode needs to be changed as well. Right now a function
that uses this and calls a function that uses this as well will have
wrong error handling mode after the inner call returns.
And then there are these:
-
should we finally change:
typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args, zend_hash_key *hash_key);
to
typedef int (*apply_func_args_t)(void *pDest TSRMLS_DC, int num_args, va_list args, zend_hash_key *hash_key);
so that we can drop a bunch of TSRMLS_FETCH()'es. -
should we use the alpha time to constify our c level API? I recently came
across this while building PHP on another machine with C++ extensions and
it is a major pain in the ass. Basically we have to disallow any help the
compiler could give us. We might even find one or the other reall error
doing so.
Best regards,
Marcus
Marcus Boerger wrote:
should we use the alpha time to constify our c level API?
Sounds like a good idea.
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
Em Qua, 2008-07-23 às 18:52 +0200, Marcus Boerger escreveu:
And then there are these:
- should we finally change:
typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args, zend_hash_key *hash_key);
to
typedef int (*apply_func_args_t)(void *pDest TSRMLS_DC, int num_args, va_list args, zend_hash_key *hash_key);
so that we can drop a bunch of TSRMLS_FETCH()'es.
Would it be like that?
http://felipe.ath.cx/diff/zend_hash_apply_with_arguments.diff
--
Regards,
Felipe Pena.
Hello Felipe,
awesome!!!! Just commit.
marcus
Thursday, July 24, 2008, 5:08:03 PM, you wrote:
Em Qua, 2008-07-23 às 18:52 +0200, Marcus Boerger escreveu:
And then there are these:
- should we finally change:
typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args, zend_hash_key *hash_key);
to
typedef int (*apply_func_args_t)(void *pDest TSRMLS_DC, int num_args, va_list args, zend_hash_key *hash_key);
so that we can drop a bunch of TSRMLS_FETCH()'es.
Would it be like that?
http://felipe.ath.cx/diff/zend_hash_apply_with_arguments.diff
--
Regards,
Felipe Pena.
Best regards,
Marcus