Hello all,
Just wanted to get a status update on the work going on:
- Eric and Nathan are working on new php.ini files and I guess they
will soon post their proposals to the list - @Steph: have you begun work on the Upgrading Guide? I would really
like to have something for beta1. The scratchpad should make it
possible to get something going quickly - @Scott: you are working on getting the dns* functions to work on
other platforms? - @Marcus: where do you see your closures RFC going?
- @Derick: whats the state of the "call_user_func segfault"?
- so are we disabling
dl()
for 5.3.0? the PHP 6.0.0 plan reads that
dl()
should be enabled and SAPI's that support it can enable it
explicitly. - @Pierre: what about bundling ext/enchant as an ext/pspell replacement?
- @Pierre: anything on the windows side we need to worry about?
- Ettienne/Lars/Guilherme: whats the status of spl_object_id()/
spl_object_hash()
? - Whats the status of the __invoke() thread (i did not follow it and
havent had time to catch up)? - I guess we are not going to deal with "foo.php?a.b.c = 10" in 5.3.0
(should we put something on the 6.0 todo list for this?) - not sure where this item on the todo list came from: Fix static
build of extension when static is the default and –enable-snapshot-
build is used - not sure where this item on the todo list came from: Improve the
build script to ease the parsing of the output and QA - @Felix/Derick: is fileinfo going to get more tests before beta1?
- First line of included files not output if they begin with #
- Defining namespaced constant using
define()
defines CASE SENSITIVE
namespace - make all extensions use php implementation of getenv (Pierre)
- any bugs we should be aware of that need special attention from the
RM's?
Again the plan is to release beta1 next week, which means we want to
freeze function changes either this Friday or next Monday. Not a lot
of time ..
regards,
Johannes and Lukas
- @Derick: whats the state of the "call_user_func segfault"?
Dmitry doesn't want to fix it basically because it could break
debuggers. IMO that's a secondary thing, and we should fix things
properly without PHP making segfaults. This is however a PHP 5.2 issue.
- @Felix/Derick: is fileinfo going to get more tests before beta1?
I've no time to do so before beta1, going on a little holiday from
Wed->Sun.
regards,
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: derickrethans
Hello all,
Just wanted to get a status update on the work going on:
- Ettienne/Lars/Guilherme: whats the status of
spl_object_id()/spl_object_hash()?
Lars has an working patch and I'm waiting him to send me to apply and
do some tests.
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil
- @Steph: have you begun work on the Upgrading Guide? I would really like to
have something for beta1. The scratchpad should make it possible to get
something going quickly
Jakub had a docsprint last week and documented bunch of things, its
probably worth browsing the docs to get inspiration.
- I guess we are not going to deal with "foo.php?a.b.c = 10" in 5.3.0
(should we put something on the 6.0 todo list for this?)
I thought this was fixed in HEAD already?
I vaguely recall seeing Ilia commit a patch for this long long long
long timeago to produce $_GET["a_b_c"] and $_GET["a.b.c"]..
I would love to get that merged.
- not sure where this item on the todo list came from: Improve the build
script to ease the parsing of the output and QA
Zoe had some changes to run-tests I think..
- First line of included files not output if they begin with #
http://news.php.net/php.zend-engine.cvs/7319 ?
- any bugs we should be aware of that need special attention from the RM's?
Why did the LFS patch never get committed?
-Hannes
Why did the LFS patch never get committed?
LFS = large file support?
AFAIK there is no patch to commit at this point.
regards,
Lukas
Why did the LFS patch never get committed?
LFS = large file support?
AFAIK there is no patch to commit at this point.
http://php.markmail.org/message/rhqy2wu5eu5253fm
-Hannes
Why did the LFS patch never get committed?
LFS = large file support?
AFAIK there is no patch to commit at this point.
There are problems with this: If PHP is compiled with LFS support other
libraries, where we exchange stat pointers and similar stuff, have to be
compiled with LFS, too. This affects the Apache SAPIs for instance. So
we get some trouble there.
I'm fine with using proper types, like off_t in PHP but I won't set
-D_LARGEFILE_SOURCE and friends by default. If people want it they might
set it themselves, if distributors use LFS apache and other libs they
can set it (and be responsible), too, but, in my opinion, this is not to
be set by default.
Additionally I think it's less an issue than 5 years ago: 64bit systems
should be the default by now and I assume it's some time till people
want to handle files in the exabyte range with PHP (but who needs more
than 64k?) :-)
johannes
- First line of included files not output if they begin with #
A patch for this already went in on Friday.
Ilia Alshanetsky
- First line of included files not output if they begin with #
A patch for this already went in on Friday.
was this the one where Nuno raised some BC concerns?
regards,
Lukas
- First line of included files not output if they begin with #
A patch for this already went in on Friday.
was this the one where Nuno raised some BC concerns?
That was the original patch, the latest one restores the behavior to
that one of earlier PHP's whereby the code is only used for the
primary file on php-cli SAPI.
Ilia Alshanetsky