Hi,
I just wanted to ask everybody to skim over the changes for PHP 5.3 we
have in CVS (especially bigger stuff like the addition/removal of an
extension etc.). Please bring up any areas you are concerned about
that we might have forgotten. However I am not interested in people
bringing up a debate again on namespace syntax or resolution orders (I
hope to have the final behavior in CVS ASAP). This is just an attempt
to ensure we do not forget something.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
PS: I know this might sound like an invitation for a flame war, it
isnt. Please keep replies as technical as possible. Thanks!
Lukas Kahwe Smith wrote:
I just wanted to ask everybody to skim over the changes for PHP 5.3 we
have in CVS (especially bigger stuff like the addition/removal of an
extension etc.). Please bring up any areas you are concerned about that
we might have forgotten. However I am not interested in people bringing
up a debate again on namespace syntax or resolution orders (I hope to
have the final behavior in CVS ASAP). This is just an attempt to ensure
we do not forget something.
There is still the problems with windows builds of PHP5.3. I've not been able
to test anything on new builds since php_interbase is not being compiled. I've
not checked what the other dozen or so extensions missing compared with
PHP5.2.x are - which is running fine.
Despite numerous requests as to why the PHP5.2.x code will not compile in 5.3
we seem to be no further forward. The Linux builds do seem to be OK, but my
main testbed is the windows stuff.
( Please - No comments about "Not needing xxx to test!" - My initial test suit
runs everything against the database - no database it fails )
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Lukas Kahwe Smith wrote:
There is still the problems with windows builds of PHP5.3. I've not been
able to test anything on new builds since php_interbase is not being
compiled. I've not checked what the other dozen or so extensions missing
compared with PHP5.2.x are - which is running fine.
You know why ibase is missing (see the firebird-php archive as well).
And I would like to know which other "dozen of extensions" are
missing.
Despite numerous requests as to why the PHP5.2.x code will not compile in
5.3 we seem to be no further forward. The Linux builds do seem to be OK, but
my main testbed is the windows stuff.
This sentence makes no sense. And we already explained hundred of
times what was used in 5.2 is not usable anymore (security,
reliability, can't be updated, no src, etc.). Please check the
archives if you need a detailed explanation.
Cheers,
Pierre
Pierre Joye wrote:
Lukas Kahwe Smith wrote:
There is still the problems with windows builds of PHP5.3. I've not been
able to test anything on new builds since php_interbase is not being
compiled. I've not checked what the other dozen or so extensions missing
compared with PHP5.2.x are - which is running fine.You know why ibase is missing (see the firebird-php archive as well).
And I would like to know which other "dozen of extensions" are
missing.
Pierre there are some 44 extensions in the 5.2.x snapshot and only 30 odd in
the 5.3.x snapshot - I don't have time to go through every one to check their
status. Is that information available somewhere?
Despite numerous requests as to why the PHP5.2.x code will not compile in
5.3 we seem to be no further forward. The Linux builds do seem to be OK, but
my main testbed is the windows stuff.This sentence makes no sense. And we already explained hundred of
times what was used in 5.2 is not usable anymore (security,
reliability, can't be updated, no src, etc.). Please check the
archives if you need a detailed explanation.
This only seems to be a problem with windows builds?
Although the other branch of this thread has brought up something that I
simply was not aware of. It may well have been thoroughly discussed and
documented, but if that is the current problem, then we can deal with it - if
someone how knows what changes are needed can point us in the right direction ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Pierre Joye wrote:
On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine lester@lsces.co.uk
wrote:Lukas Kahwe Smith wrote:
There is still the problems with windows builds of PHP5.3. I've
not been
able to test anything on new builds since php_interbase is not being
compiled. I've not checked what the other dozen or so extensions
missing
compared with PHP5.2.x are - which is running fine.
You know why ibase is missing (see the firebird-php archive as well).
And I would like to know which other "dozen of extensions" are
missing.
Pierre there are some 44 extensions in the 5.2.x snapshot and only
30 odd in the 5.3.x snapshot - I don't have time to go through every
one to check their status. Is that information available somewhere?
This is why I asked to check the NEWS file:
http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=log&pathrev=PHP_5_3
That file should list all intentional changes. If something is changed
which is not listed there, it either needs to be listed or fixed.
Despite numerous requests as to why the PHP5.2.x code will not
compile in
5.3 we seem to be no further forward. The Linux builds do seem to
be OK, but
my main testbed is the windows stuff.
This sentence makes no sense. And we already explained hundred of
times what was used in 5.2 is not usable anymore (security,
reliability, can't be updated, no src, etc.). Please check the
archives if you need a detailed explanation.
This only seems to be a problem with windows builds?
Although the other branch of this thread has brought up something
that I simply was not aware of. It may well have been thoroughly
discussed and documented, but if that is the current problem, then
we can deal with it - if someone how knows what changes are needed
can point us in the right direction ...
I just talked to Pierre and he said he is in contact with people from
Firebird to get this resolved.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
Pierre there are some 44 extensions in the 5.2.x snapshot and only 30
odd in the 5.3.x snapshot - I don't have time to go through every one
to check their status. Is that information available somewhere?This is why I asked to check the NEWS file:
http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=log&pathrev=PHP_5_3That file should list all intentional changes. If something is changed
which is not listed there, it either needs to be listed or fixed.
OK - one of the missing things here is the windows builds of the pecl code.
This used to be provided as a separate zip in the old snapshot system, and so
it made little difference if a package was core or pecl.
Is there a current windows snapshot of the pecl library, and a matching
PECL-5.3.0 to go with the alpha builds anywhere?
( A couple of the packages I'm missing are in the pecl pack on 5.2.x which is
why there was a little confusion on what was available )
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Lester Caine wrote:
Lukas Kahwe Smith wrote:
Pierre there are some 44 extensions in the 5.2.x snapshot and only 30
odd in the 5.3.x snapshot - I don't have time to go through every one
to check their status. Is that information available somewhere?This is why I asked to check the NEWS file:
http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=log&pathrev=PHP_5_3That file should list all intentional changes. If something is changed
which is not listed there, it either needs to be listed or fixed.OK - one of the missing things here is the windows builds of the pecl
code. This used to be provided as a separate zip in the old snapshot
system, and so it made little difference if a package was core or pecl.
Is there a current windows snapshot of the pecl library, and a matching
PECL-5.3.0 to go with the alpha builds anywhere?( A couple of the packages I'm missing are in the pecl pack on 5.2.x
which is why there was a little confusion on what was available )
OK going on from this.
Current windows alpha does not have
php_dba.dll
php_gmp.dll
php_mcrypt.dll
php_pspell.dll
php_snmp.dll
And I presume php_zip.dll has moved to pecl as it's now available there, but
none of them are appearing in the notes.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Current windows alpha does not have
php_mcrypt.dll
mcrypt is present (builtin)
php_dba.dll
php_gmp.dll
They will be in the next release.
php_pspell.dll
php_snmp.dll
snmp and pspell are likely to do not be present in the next release
and maybe not in the final release (windows only). The underlying
libraries are not portable enough to be used on windows and the
versions used before have critical issues (security or crashes).
And I presume php_zip.dll has moved to pecl as it's now available there, but
none of them are appearing in the notes.
zip is present too (builtin)
Cheers,
Pierre Joye napsal(a):
php_pspell.dll
php_snmp.dllsnmp and pspell are likely to do not be present in the next release
and maybe not in the final release (windows only). The underlying
libraries are not portable enough to be used on windows and the
versions used before have critical issues (security or crashes).
Would it be better to have these extension with some issues (current
state) than not to have them at all?
Regards
Jaroslav Hanslik
2008/11/10 Jaroslav Hanslík konference@kukulich.net:
Pierre Joye napsal(a):
php_pspell.dll
php_snmp.dllsnmp and pspell are likely to do not be present in the next release
and maybe not in the final release (windows only). The underlying
libraries are not portable enough to be used on windows and the
versions used before have critical issues (security or crashes).Would it be better to have these extension with some issues (current state)
than not to have them at all?
As from what I could understand from Pierre, then SNMP is dead on
Windows and have been for a very long time (for example it doesn't
even compile).
I don't remember about pspell, but I think it would make more sense to
maybe include something like enchant for spelling though.
--
Kalle Sommer Nielsen
On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen
kalle.php@gmail.com wrote:
2008/11/10 Jaroslav Hanslík konference@kukulich.net:
Pierre Joye napsal(a):
php_pspell.dll
php_snmp.dllsnmp and pspell are likely to do not be present in the next release
and maybe not in the final release (windows only). The underlying
libraries are not portable enough to be used on windows and the
versions used before have critical issues (security or crashes).Would it be better to have these extension with some issues (current state)
than not to have them at all?As from what I could understand from Pierre, then SNMP is dead on
Windows and have been for a very long time (for example it doesn't
even compile).I don't remember about pspell, but I think it would make more sense to
maybe include something like enchant for spelling though.
Enchant works but not using pspell (for the same reason than
ext/pspell does not), it works with almost any other spelling system,
on all platforms. But that's not the problem neither the solution as
enchant is not part of the core.
pspell and netsmnp libraries are not portable and can't be built on
windows. We don't feel like releasing packages with critical security
issues is a good thing to do. If we do not find a solution by the time
of 5.3-final, we can always provide an extra package with these
packages but with a (very) strong warning about using them in
production environment.
Cheers,
On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen
kalle.php@gmail.com wrote:2008/11/10 Jaroslav Hanslík konference@kukulich.net:
Pierre Joye napsal(a):
php_pspell.dll
php_snmp.dllsnmp and pspell are likely to do not be present in the next release
and maybe not in the final release (windows only). The underlying
libraries are not portable enough to be used on windows and the
versions used before have critical issues (security or crashes).Would it be better to have these extension with some issues
(current state)
than not to have them at all?As from what I could understand from Pierre, then SNMP is dead on
Windows and have been for a very long time (for example it doesn't
even compile).I don't remember about pspell, but I think it would make more sense
to
maybe include something like enchant for spelling though.Enchant works but not using pspell (for the same reason than
ext/pspell does not), it works with almost any other spelling system,
on all platforms. But that's not the problem neither the solution as
enchant is not part of the core.
Should we examine if we want to make enchant part of core? I guess you
are one of the maintainers, so the prime candidate to tell us if you
think its ready ..
pspell and netsmnp libraries are not portable and can't be built on
windows. We don't feel like releasing packages with critical security
issues is a good thing to do. If we do not find a solution by the time
of 5.3-final, we can always provide an extra package with these
packages but with a (very) strong warning about using them in
production environment.
I agree.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi,
I just wanted to ask everybody to skim over the changes for PHP 5.3 we have
in CVS (especially bigger stuff like the addition/removal of an extension
etc.). Please bring up any areas you are concerned about that we might have
forgotten. However I am not interested in people bringing up a debate again
on namespace syntax or resolution orders (I hope to have the final behavior
in CVS ASAP). This is just an attempt to ensure we do not forget something.regards,
Lukas Kahwe Smith
mls@pooteeweet.orgPS: I know this might sound like an invitation for a flame war, it isnt.
Please keep replies as technical as possible. Thanks!
- We have broken streams, currently: http://bugs.php.net/bug.php?id=46049
- We still need someone to do upgrades to new parameter-parsing api in
a) ext/mysql and ext/mysqli (I believe these are in works and will
be committed soon)
b) ext/interbase (any volunteers?)
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Alexey Zakhlestin wrote:
- We still need someone to do upgrades to new parameter-parsing api in
b) ext/interbase (any volunteers?)
Where will I find some help on actually what needs doing? I presume that the
Linux build has not been updated although I'm not actually seeing a problem at
present. Perhaps I've simply got that wrong as well :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Alexey Zakhlestin wrote:
- We still need someone to do upgrades to new parameter-parsing api in
b) ext/interbase (any volunteers?)Where will I find some help on actually what needs doing? I presume that the
Linux build has not been updated although I'm not actually seeing a problem
at present. Perhaps I've simply got that wrong as well :(
Simple instruction is here:
http://marc.info/?l=php-internals&m=121391697512351&w=2
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Lukas Kahwe Smith wrote:
Hi,
I just wanted to ask everybody to skim over the changes for PHP 5.3 we
have in CVS (especially bigger stuff like the addition/removal of an
extension etc.). Please bring up any areas you are concerned about that
we might have forgotten. However I am not interested in people bringing
up a debate again on namespace syntax or resolution orders (I hope to
have the final behavior in CVS ASAP). This is just an attempt to ensure
- Change ext/phar to be disabled by default
- Change ext/ereg to be disabled by default (scheduled to be removed in
PHP 6, iirc?) - Remove ext/mhash (replaced by ext/hash)
--Jani
- Change ext/ereg to be disabled by default (scheduled to be
removed in PHP 6, iirc?)
IIRC we are not yet in agreement on the removal. AFAIK its already an
extension in PHP6, but I am not sure if we wanted to continue with the
proposal that Andrei (IIRC) made to remove it. If we are doing to
remove it we should add E_DEPRECATED.
- Remove ext/mhash (replaced by ext/hash)
So what was the deal here? ext/hash automatically provides the ext/
mhash functions if the extension is not compiled in. So the main
reason to keep ext/mhash is just to allow if extension mhash
exists .. ? I think this is easy enough for people to fix by replacing
this check with an function_exists() check.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
- Change ext/ereg to be disabled by default (scheduled to be removed
in PHP 6, iirc?)IIRC we are not yet in agreement on the removal. AFAIK its already an
extension in PHP6, but I am not sure if we wanted to continue with the
You don't follow the CVS a lot, do you?
revision 1.2.2.2
date: 2007/10/05 15:00:05; author: jani; state: Exp; lines: +56 -0
MFH:- Moved the old regex functions to own extension: ereg
proposal that Andrei (IIRC) made to remove it. If we are doing to remove
it we should add E_DEPRECATED.
- Remove ext/mhash (replaced by ext/hash)
So what was the deal here? ext/hash automatically provides the ext/mhash
functions if the extension is not compiled in. So the main reason to
keep ext/mhash is just to allow if extension mhash exists .. ? I think
this is easy enough for people to fix by replacing this check with an
function_exists()check.
Exactly.
--Jani
Lukas Kahwe Smith wrote:
- Change ext/ereg to be disabled by default (scheduled to be
removed in PHP 6, iirc?)
IIRC we are not yet in agreement on the removal. AFAIK its already
an extension in PHP6, but I am not sure if we wanted to continue
with theYou don't follow the CVS a lot, do you?
I do, but sometimes I miss a commit.
revision 1.2.2.2
date: 2007/10/05 15:00:05; author: jani; state: Exp; lines: +56 -0
MFH:- Moved the old regex functions to own extension: ereg
Ok, so its already an extension in PHP 5.3, that does not mean that we
have scheduled its removal in PHP 6. Personally I am fine with
removing ereg, but then again I have always refrained from using ereg.
Its going to be a bit of a pain, but IIRC ereg is not going to play
well in our brave new unicode world unless someone does considerable
work on ereg ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hello Jani,
Monday, November 10, 2008, 11:41:44 AM, you wrote:
Lukas Kahwe Smith wrote:
Hi,
I just wanted to ask everybody to skim over the changes for PHP 5.3 we
have in CVS (especially bigger stuff like the addition/removal of an
extension etc.). Please bring up any areas you are concerned about that
we might have forgotten. However I am not interested in people bringing
up a debate again on namespace syntax or resolution orders (I hope to
have the final behavior in CVS ASAP). This is just an attempt to ensure
- Change ext/phar to be disabled by default
We are not disabling thois because Jani doesn't like it.- Change ext/ereg to be disabled by default (scheduled to be removed in
PHP 6, iirc?)
Do we already have plans on how and when to move this to pecl?- Remove ext/mhash (replaced by ext/hash)
Yep, should be dropped.
--Jani
Best regards,
Marcus
Marcus Boerger wrote:
Hello Jani,
Monday, November 10, 2008, 11:41:44 AM, you wrote:
Lukas Kahwe Smith wrote:
Hi,
I just wanted to ask everybody to skim over the changes for PHP 5.3 we
have in CVS (especially bigger stuff like the addition/removal of an
extension etc.). Please bring up any areas you are concerned about that
we might have forgotten. However I am not interested in people bringing
up a debate again on namespace syntax or resolution orders (I hope to
have the final behavior in CVS ASAP). This is just an attempt to ensure
- Change ext/phar to be disabled by default
We are not disabling thois because Jani doesn't like it.
Eh? It wasn't supposed to be enabled everywhere from the beginning!
Only for the RC stage. Search the mailing list. It's not about me not
liking it or not, it's about general usefulness.
--Jani
Marcus Boerger wrote:
Hello Jani,
Monday, November 10, 2008, 11:41:44 AM, you wrote:Lukas Kahwe Smith wrote:
Hi,
I just wanted to ask everybody to skim over the changes for PHP
5.3 we have in CVS (especially bigger stuff like the addition/
removal of an extension etc.). Please bring up any areas you are
concerned about that we might have forgotten. However I am not
interested in people bringing up a debate again on namespace
syntax or resolution orders (I hope to have the final behavior in
CVS ASAP). This is just an attempt to ensure
- Change ext/phar to be disabled by default
We are not disabling thois because Jani doesn't like it.Eh? It wasn't supposed to be enabled everywhere from the beginning!
Only for the RC stage. Search the mailing list. It's not about me
not liking it or not, it's about general usefulness.
No, this is just your selective interpretation of the situation. We
decided to enable it by default because if we felt its important to be
enabled by default. We left ourselves the option of not enabling it by
default (or even removing it) in case we find issues that make it
unfit to be enabled by default (or bundled).
So far it seems that Greg/Marcus/Steph have been quick to react to any
issues that have popped up. Checking the pecl and php bug tracker
seems to validate this.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Jani Taskinen wrote:
Lukas Kahwe Smith wrote:
Hi,
I just wanted to ask everybody to skim over the changes for PHP 5.3 we
have in CVS (especially bigger stuff like the addition/removal of an
extension etc.). Please bring up any areas you are concerned about
that we might have forgotten. However I am not interested in people
bringing up a debate again on namespace syntax or resolution orders (I
hope to have the final behavior in CVS ASAP). This is just an attempt
to ensure
- Change ext/phar to be disabled by default
- Change ext/ereg to be disabled by default (scheduled to be removed in
PHP 6, iirc?)- Remove ext/mhash (replaced by ext/hash)
I forgot this one:
- Output buffering rewrite MFH:
http://bugs.php.net/bug.php?id=42641&edit=1
--Jani
- Output buffering rewrite MFH: http://bugs.php.net/bug.php?id=42641&edit=1
If there is a significant show of hands of people that feel that the
code in HEAD is so much easier to maintain, that suddenly they feel
more inclined than before to actually care about bugs in output
buffering and that they will take care of any BC issues that pop up,
Johannes and I might reconsider our decision to not MFH OB.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
- Change ext/phar to be disabled by default
Is that the only case? We have a few new extensions, fileinfo is enabled
by default at the moment, hash is, sqlite3 is, ...
So the question is: What's the purpose of bundling extensions and what's
the risk? - In general I think the reason to bundle stuff is to make it
available as "default" stuff, so enabling by default makes sense. But
then we also have to enable more stuff without external dependencies
(mbstring, mysqlnd [1]) and we should consider enabling by default stuff
where header and libs are on most systems (like zlib) ... but then again
we get a really big beast as default config.
So, what's the right line?
- Change ext/ereg to be disabled by default (scheduled to be removed in
PHP 6, iirc?)
kind of related to the previous thing, we should at least deprecate it,
removing has benefits as it's often insecure to use ereg (barely anyone
is aware of \0-Byte problems ...)
- Remove ext/mhash (replaced by ext/hash)
isn't mhash just a compatibility wrapper on top of hash? Kicking that
out is bad for getting people to migrate to 5.3.
johannes
[1] Disclaimer: I'm paid by Sun/MySQL
Please bring up any areas you are concerned about that we might have
forgotten.
PHP_5_3 as of this morning does not contain that patch that makes
ArrayObject behave like an array (reset()).
Here's a test for that (I don't have php-src karma) if anyone would
care to commit it. Passes on 5.2.6, but fails on 5.3alpha3-dev
S
--TEST--
Ensure that ArrayObject acts like an array
--SKIPIF--
--FILE--
<?php
$a = new ArrayObject;
$a['foo'] = 'bar';
echo reset($a);
echo count($a);
echo current($a);
?>
--EXPECT--
bar1bar
Here's a test for that (I don't have php-src karma) if anyone would
care to commit it. Passes on 5.2.6, but fails on 5.3alpha3-dev
FWIW, I committed that patch today.
I'd like for it to pass by RC1 (-:
S