Hello all,
As some of you may have noticed the 5.3 todo list [1] has been
reworked a bit. There is now a list for alpha1 and some more items for
alpha2. As previously announced Lukas and I are allowing low risk
self contained work to continue until alpha2 on a case by case basis.
However there are even still a few items that did not make it in for
the alpha1 feature freeze that we have permitted to be worked on over
the course of this weekend. Or just general bug fixing items we need
to have done before alpha1 release (planned for July 31st):
- various string optimization patches from Matt (Scott)
- various ZE optimization patches from Matt (Dmitry)
- add tests for fileinfo (note fileinfo is now bundled and enabled by
default just as mimemagic was before PHP 5.2) (Derick) - add openssl_parse_csr (Pierre)
- "OpenLDAP C API cleanup patch" and pat44 "LDAP control
support" (Pierre) - Zend Signal Handling (Dmitry)
- add array_replace[_recursive] (diff, phpt) (Johannes)
- prepare windows build infrastructure (Pierre, Rob, Liz)
- make parent::/self:: forwarding (Dmitry)
- make ming compile with libming 0.3 and up (Frank)
- unix path separators in spl (Marcus)
- add Christians Reflection patch for closures (Marcus)
@Marcus: Can you handle 11) and 12)?
Let us know if we are missing anything from this list ASAP!
Then a couple questions that need to be answered and quickly resolved:
- undeprecate ticks: as long as we have no replacement for the signal
handling we shouldn't deprecate the only way to do that. - drop __toString() from Closures
- Do not include 3xx http codes in the fopen wrapper
Again a general request to the developer and user community at large:
Please concentrate on finding&fixing bugs instead of functional changes
(including arginfo and parameter_parsing) and to make sure we have all
changes covered in the wiki [2] so they can be added to release notes
and the documentation.
Lukas and Johannes
[1] http://wiki.php.net/todo/php53
[2] http://wiki.php.net/doc/scratchpad/upgrade/53
Again a general request to the developer and user community at large:
Please concentrate on finding&fixing bugs instead of functional
changes
(including arginfo and parameter_parsing) and to make sure we have all
changes covered in the wiki [2] so they can be added to release notes
and the documentation.
Speaking of which, just going through the open 5.3 bugs that have not
been assigned to a developer I see the following ones as looking to be
important to be dealt with:
http://bugs.php.net/bug.php?id=45044 (relative paths not resolved
correctly)
http://bugs.php.net/bug.php?id=43695 (Asynchronous socket connection
timing issue)
http://bugs.php.net/bug.php?id=45384 (parse_ini_file will result in
parse error with no trailing newline)
http://bugs.php.net/bug.php?id=45392 (ob_start()/ob_end_clean() and
memory_limit)
http://bugs.php.net/bug.php?id=44842 (parse_ini_file keys that start/
end with underscore)
http://bugs.php.net/bug.php?id=45288 (set_include_path() functionality
broken)
http://bugs.php.net/bug.php?id=45608 (closures don't work in static
methods)
The rest are either assigned or PDO bugs (again, we really really
really need someone that looks after PDO).
Of course there are also still tons of open 5.2 bugs [1] :(
regards,
Lukas Kahwe Smith
smith@pooteeweet.org
On Saturday 26 July 2008 13:57:45 Lukas Kahwe Smith wrote:
Again a general request to the developer and user community at large:
Please concentrate on finding&fixing bugs instead of functional
changes
(including arginfo and parameter_parsing) and to make sure we have all
changes covered in the wiki [2] so they can be added to release notes
and the documentation.Speaking of which, just going through the open 5.3 bugs that have not
been assigned to a developer I see the following ones as looking to be
important to be dealt with:
http://bugs.php.net/bug.php?id=45044 (relative paths not resolved
correctly)
http://bugs.php.net/bug.php?id=43695 (Asynchronous socket connection
timing issue)
http://bugs.php.net/bug.php?id=45384 (parse_ini_file will result in
parse error with no trailing newline)
http://bugs.php.net/bug.php?id=45392 (ob_start()/ob_end_clean() and
memory_limit)
http://bugs.php.net/bug.php?id=44842 (parse_ini_file keys that start/
end with underscore)
http://bugs.php.net/bug.php?id=45288 (set_include_path() functionality
broken)
http://bugs.php.net/bug.php?id=45608 (closures don't work in static
methods)The rest are either assigned or PDO bugs (again, we really really
really need someone that looks after PDO).Of course there are also still tons of open 5.2 bugs [1] :(
regards,
Lukas Kahwe Smith
smith@pooteeweet.org[1]
http://bugs.php.net/search.php?cmd=display&status=Open&search_for=&php_os=&boolean=1&author_email=&bug_age=0&by=&order_by=id&direction=ASC&phpver=5.2&limit=30&assign=&begin=0
Hi,
For "closures don't work in static methods" (45608), this is because a closure
declared in a static method will always be called statically.
The example given in the report works if the closure is explicitly declared as
static, but as shown by the bug report it may be better to implicitly inherit
the ACC_STATIC flag of the declaring method. It seems that Christian planed
to add this to his patch but it has never be included.
This could be as simple as this:
http://arnaud.lb.s3.amazonaws.com/closure_static.patch
For "relative paths not resolved correctly" (45044) I added a comment on the
report about the cause of the bug, but I don't know what is the better way to
fix that.
Regards,
Arnaud
Hello,
On Saturday 26 July 2008 13:57:45 Lukas Kahwe Smith wrote:
Again a general request to the developer and user community at
large:
Please concentrate on finding&fixing bugs instead of functional
changes
(including arginfo and parameter_parsing) and to make sure we
have all
changes covered in the wiki [2] so they can be added to release
notes
and the documentation.Speaking of which, just going through the open 5.3 bugs that have not
been assigned to a developer I see the following ones as looking
to be
important to be dealt with:
http://bugs.php.net/bug.php?id=45044 (relative paths not resolved
correctly)
http://bugs.php.net/bug.php?id=43695 (Asynchronous socket connection
timing issue)
http://bugs.php.net/bug.php?id=45384 (parse_ini_file will result in
parse error with no trailing newline)
http://bugs.php.net/bug.php?id=45392 (ob_start()/ob_end_clean() and
memory_limit)
I have just taken a look at this bug, and the problems seems to be in
php_request_shutdown function from main/main.c. It just executes
buffers flush no matter what outcome of the script was (I mean error/
success) (somewhere around line 1495):
zend_try {
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1)
TSRMLS_CC);
} zend_end_try();
It can be avoided by adding if-stmt checking if there was an error:
if (!PG(last_error_message) || !(PG(last_error_type) & E_ERROR)) {
zend_try {
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1)
TSRMLS_CC);
} zend_end_try();
}
I am not sure if it is the right solution, or if it does not
introduce any other problems I am not aware of (I have done "make
test" and haven;t noticed anything strange.)
Cheers
Michal
http://bugs.php.net/bug.php?id=44842 (parse_ini_file keys that start/
end with underscore)
http://bugs.php.net/bug.php?id=45288 (set_include_path()
functionality
broken)
http://bugs.php.net/bug.php?id=45608 (closures don't work in static
methods)The rest are either assigned or PDO bugs (again, we really really
really need someone that looks after PDO).Of course there are also still tons of open 5.2 bugs [1] :(
regards,
Lukas Kahwe Smith
smith@pooteeweet.org[1]
http://bugs.php.net/search.php?
cmd=display&status=Open&search_for=&php_os=&boolean=1&author_email=&bu
g_age=0&by=&order_by=id&direction=ASC&phpver=5.2&limit=30&assign=&begi
n=0Hi,
For "closures don't work in static methods" (45608), this is
because a closure
declared in a static method will always be called statically.The example given in the report works if the closure is explicitly
declared as
static, but as shown by the bug report it may be better to
implicitly inherit
the ACC_STATIC flag of the declaring method. It seems that
Christian planed
to add this to his patch but it has never be included.This could be as simple as this:
http://arnaud.lb.s3.amazonaws.com/closure_static.patchFor "relative paths not resolved correctly" (45044) I added a
comment on the
report about the cause of the bug, but I don't know what is the
better way to
fix that.Regards,
Arnaud
hi!
Of course there are also still tons of open 5.2 bugs [1] :(
What would be nice is to sort out platform specific bugs (5.2 or 5.3).
There is many "windows" bugs that are not Windows specific, they
should be "*" (all OSes). Once they are sorted out, we can more easily
focus on a given platform (windows in my case).
Cheers,
Pierre
- undeprecate ticks: as long as we have no replacement for the signal
handling we shouldn't deprecate the only way to do that.
So currently the deprecation warning reads that the feature will be
removed in PHP 6. We could also tone down the message to not mention a
specific PHP version for removal. Derick, Marcus, Jani etc have all
said that they have seen reports of serious issues aka crashes with
ticks. Tony says he is using tick's and we do not have a replacement
to offer. But given the fact that even Tony did not come out to say
that he knows how to fix ticks, it seems like the best compromise is
to deprecate ticks with a message that it could get removed in any
minor version release with or without a replacement, but it will kept
for now.
- drop __toString() from Closures
- Do not include 3xx http codes in the fopen wrapper change
Can we get a quick in formal vote on each of the above items?
regards,
Lukas Kahwe Smith
smith@pooteeweet.org
- undeprecate ticks: as long as we have no replacement for the signal
handling we shouldn't deprecate the only way to do that.crashes with ticks. Tony says he is using tick's and we do not have
a replacement to offer. But given the fact that even Tony did not
come out to say that he knows how to fix ticks, it seems like the
best compromise is to deprecate ticks with a message that it could
get removed in any minor version release with or without a
replacement, but it will kept for now.
+1
- drop __toString() from Closures
+1
- Do not include 3xx http codes in the fopen wrapper change
+1
regards,
Lukas Kahwe Smith
mls@pooteeweet.org