Hi,
Work is still going on to finalize the namespace changes. I am not
sure when this will be done, I am sort of hoping Monday. Then we can
freeze Tuesday and release on Thursday if all goes well.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Work is still going on to finalize the namespace changes. I am not
sure when this will be done, I am sort of hoping Monday. Then we can
freeze Tuesday and release on Thursday if all goes well.
The good news, namespace changes are now finished ahead of alpha3.
Documentation is also going to be available soon.
Now for the bad, I have continued the trend of being too optimistic
for the alpha3 release date, which is now set for Tuesday December
2nd. Freeze is therefore on the 28th, packaging will happen sometime
on December 1st, allowing a period for important last minute fixes as
well as build related work.
Until then please all make sure that you get whatever you can ready.
Since we hope this will be our last alpha, it also means that this
release will also mark the end for feature additions in self contained
parts of the code. That being said I already know of a few items that
I know will not make it into alpha3 that we might see before beta1. If
you are unsure if your stuff is in this mental list, please let me or
Johannes know just to make sure.
But if you have not gotten in contact with one of the RM's about your
stuff yet, then its unlikely that we will consider it after beta1. Not
because we are mean or because we do not realize that many of you only
have your spare time to work on stuff, just because we really really
have to get 5.3 out the door some day and guess what .. it looks like
we will not even have a beta out this year! So think about it .. at
least 2 beta's, 2-4 RC's and yeah .. it even looks optimistic to go
stable in Q1 2009. Again this is open source, so the only people we do
not have to release on a specific date, I just feel bad for all the
work people have put into code months ago that is not getting released
for so long.
Anyways, a few items from the top of my head that I know people were
talking about:
- rounding patch
- stream's issues that Greg found and Arnaud recently commented on as
well as other streams issues - openssl patches
- gd work
- mysqlnd async stuff ready?
- interbase ready on windows?
Independent of that I need someone to handle the move of ext/mhash to
PECL.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
Work is still going on to finalize the namespace changes. I am not
sure when this will be done, I am sort of hoping Monday. Then we can
freeze Tuesday and release on Thursday if all goes well.The good news, namespace changes are now finished ahead of alpha3.
Documentation is also going to be available soon.Now for the bad, I have continued the trend of being too optimistic for
the alpha3 release date, which is now set for Tuesday December 2nd.
Freeze is therefore on the 28th, packaging will happen sometime on
December 1st, allowing a period for important last minute fixes as well
as build related work.Until then please all make sure that you get whatever you can ready.
Since we hope this will be our last alpha, it also means that this
release will also mark the end for feature additions in self contained
parts of the code. That being said I already know of a few items that I
know will not make it into alpha3 that we might see before beta1. If you
are unsure if your stuff is in this mental list, please let me or
Johannes know just to make sure.But if you have not gotten in contact with one of the RM's about your
stuff yet, then its unlikely that we will consider it after beta1. Not
because we are mean or because we do not realize that many of you only
have your spare time to work on stuff, just because we really really
have to get 5.3 out the door some day and guess what .. it looks like we
will not even have a beta out this year! So think about it .. at least 2
beta's, 2-4 RC's and yeah .. it even looks optimistic to go stable in Q1
- Again this is open source, so the only people we do not have to
release on a specific date, I just feel bad for all the work people have
put into code months ago that is not getting released for so long.Anyways, a few items from the top of my head that I know people were
talking about:
- rounding patch
- stream's issues that Greg found and Arnaud recently commented on as
well as other streams issues- openssl patches
- gd work
- mysqlnd async stuff ready?
- interbase ready on windows?
Independent of that I need someone to handle the move of ext/mhash to PECL.
Why not just delete the extension? There isn't anything valuable in
there as it just wraps around hash now, it is literally an empty module
and a configure script.
Scott
Independent of that I need someone to handle the move of ext/mhash
to PECL.Why not just delete the extension? There isn't anything valuable in
there as it just wraps around hash now, it is literally an empty
module
and a configure script.
Well, in that case we might want to drop a pre-wrap-around-ext/hash
version into PECL ..
Something to make it possible to get BC without having to code a line
of C ..
Then again, we maintain BC aside from this single call to determine if
the extension is loaded, so I guess yeah .. lets just remove it .. we
are expecting people to update their code.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
Then again, we maintain BC aside from this single call to determine if
the extension is loaded, so I guess yeah .. lets just remove it .. we
are expecting people to update their code.
If we have function-level BC - why not just add stub extension with
dependency on hash?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
why not have a secondary extension definition in ext/hash?
Wednesday, November 26, 2008, 7:06:03 PM, you wrote:
Hi!
Then again, we maintain BC aside from this single call to determine if
the extension is loaded, so I guess yeah .. lets just remove it .. we
are expecting people to update their code.
If we have function-level BC - why not just add stub extension with
dependency on hash?Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Best regards,
Marcus
Hi!
why not have a secondary extension definition in ext/hash?
Would be fine too, if loading can handle that correctly.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
why not have a secondary extension definition in ext/hash?
Would be fine too, if loading can handle that correctly.
Don't we do that already?
What exactly was the vote from last week about? I thought it was about
removing that stub.
-Hannes
Hello Stanislav,
why not have a secondary extension definition in ext/hash?
Wednesday, November 26, 2008, 7:06:03 PM, you wrote:
Hi!
Then again, we maintain BC aside from this single call to
determine if
the extension is loaded, so I guess yeah .. lets just remove it ..
we
are expecting people to update their code.If we have function-level BC - why not just add stub extension with
dependency on hash.
I looked at this but php.h would want to include a mhash header file,
at least I think that's what it was from memory.
Scott
Hello Scott,
Wednesday, November 26, 2008, 8:33:59 PM, you wrote:
Hello Stanislav,
why not have a secondary extension definition in ext/hash?
Wednesday, November 26, 2008, 7:06:03 PM, you wrote:
Hi!
Then again, we maintain BC aside from this single call to
determine if
the extension is loaded, so I guess yeah .. lets just remove it ..
we
are expecting people to update their code.If we have function-level BC - why not just add stub extension with
dependency on hash.
I looked at this but php.h would want to include a mhash header file,
at least I think that's what it was from memory.
That's one solution, the other is to reqister that stub extension from
MINIT of the hash extension and be done (can all be done in hash.c).
Best regards,
Marcus
Hi!
That's one solution, the other is to reqister that stub extension from
MINIT of the hash extension and be done (can all be done in hash.c).
It was what we decided weeks ago already. I'mm not sure why it is not done yet.
Cheers,
Pierre
Hi Marcus,
Hello Scott,
Wednesday, November 26, 2008, 8:33:59 PM, you wrote:
Hello Stanislav,
why not have a secondary extension definition in ext/hash?
Wednesday, November 26, 2008, 7:06:03 PM, you wrote:
Hi!
Then again, we maintain BC aside from this single call to
determine if
the extension is loaded, so I guess yeah .. lets just remove it ..
we
are expecting people to update their code.If we have function-level BC - why not just add stub extension with
dependency on hash.I looked at this but php.h would want to include a mhash header file,
at least I think that's what it was from memory.That's one solution, the other is to reqister that stub extension from
MINIT of the hash extension and be done (can all be done in hash.c).
I've committed this now.
Scott
Work is still going on to finalize the namespace changes. I am not sure
when this will be done, I am sort of hoping Monday. Then we can freeze
Tuesday and release on Thursday if all goes well.The good news, namespace changes are now finished ahead of alpha3.
Documentation is also going to be available soon.Now for the bad, I have continued the trend of being too optimistic for the
alpha3 release date, which is now set for Tuesday December 2nd. Freeze is
therefore on the 28th, packaging will happen sometime on December 1st,
allowing a period for important last minute fixes as well as build related
work.Until then please all make sure that you get whatever you can ready. Since
we hope this will be our last alpha, it also means that this release will
also mark the end for feature additions in self contained parts of the code.
That being said I already know of a few items that I know will not make it
into alpha3 that we might see before beta1. If you are unsure if your stuff
is in this mental list, please let me or Johannes know just to make sure.But if you have not gotten in contact with one of the RM's about your stuff
yet, then its unlikely that we will consider it after beta1. Not because we
are mean or because we do not realize that many of you only have your spare
time to work on stuff, just because we really really have to get 5.3 out the
door some day and guess what .. it looks like we will not even have a beta
out this year! So think about it .. at least 2 beta's, 2-4 RC's and yeah ..
it even looks optimistic to go stable in Q1 2009. Again this is open source,
so the only people we do not have to release on a specific date, I just feel
bad for all the work people have put into code months ago that is not
getting released for so long.Anyways, a few items from the top of my head that I know people were talking
about:
- rounding patch
- stream's issues that Greg found and Arnaud recently commented on as well
as other streams issues- openssl patches
- gd work
- mysqlnd async stuff ready?
- interbase ready on windows?
Independent of that I need someone to handle the move of ext/mhash to PECL.
Following files are still not "converted" to the new parameter parsing API:
- ext/interbase/ibase_blobs.c
- ext/interbase/ibase_query.c
- ext/mysql/php_mysql.c
- ext/mysqli/mysqli_embedded.c
I guess, patch for those still sits on someones ToDo list
Can we have this converted before alpha3, please?
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
Following files are still not "converted" to the new parameter parsing API:
- ext/mysql/php_mysql.c
That's mostly done, some small issues left, will commit before alpha ...
- ext/mysqli/mysqli_embedded.c
That's not done yet, but only 2 or 3 places to change. Will do that,
too.
johannes
Em Qua, 2008-11-26 às 19:36 +0300, Alexey Zakhlestin escreveu:
Work is still going on to finalize the namespace changes. I am not sure
when this will be done, I am sort of hoping Monday. Then we can freeze
Tuesday and release on Thursday if all goes well.The good news, namespace changes are now finished ahead of alpha3.
Documentation is also going to be available soon.Now for the bad, I have continued the trend of being too optimistic for the
alpha3 release date, which is now set for Tuesday December 2nd. Freeze is
therefore on the 28th, packaging will happen sometime on December 1st,
allowing a period for important last minute fixes as well as build related
work.Until then please all make sure that you get whatever you can ready. Since
we hope this will be our last alpha, it also means that this release will
also mark the end for feature additions in self contained parts of the code.
That being said I already know of a few items that I know will not make it
into alpha3 that we might see before beta1. If you are unsure if your stuff
is in this mental list, please let me or Johannes know just to make sure.But if you have not gotten in contact with one of the RM's about your stuff
yet, then its unlikely that we will consider it after beta1. Not because we
are mean or because we do not realize that many of you only have your spare
time to work on stuff, just because we really really have to get 5.3 out the
door some day and guess what .. it looks like we will not even have a beta
out this year! So think about it .. at least 2 beta's, 2-4 RC's and yeah ..
it even looks optimistic to go stable in Q1 2009. Again this is open source,
so the only people we do not have to release on a specific date, I just feel
bad for all the work people have put into code months ago that is not
getting released for so long.Anyways, a few items from the top of my head that I know people were talking
about:
- rounding patch
- stream's issues that Greg found and Arnaud recently commented on as well
as other streams issues- openssl patches
- gd work
- mysqlnd async stuff ready?
- interbase ready on windows?
Independent of that I need someone to handle the move of ext/mhash to PECL.
Following files are still not "converted" to the new parameter parsing API:
- ext/interbase/ibase_blobs.c
- ext/interbase/ibase_query.c
- ext/mysql/php_mysql.c
- ext/mysqli/mysqli_embedded.c
I'll change the leftover of ibase stuff.
--
Regards,
Felipe Pena
Hi Lukas,
First of all, @all: http://wiki.php.net/rfc/rounding - I didn't have
time to update it yet but the basically nothing has changed except for
implementation details wrt. FPU precision. For FPU precision
explanations see (*).
Anyways, a few items from the top of my head that I know people were
talking about:
- rounding patch
I've split the patch in two parts:
(1) Make the Zend Engine always use double FPU precision on x87
platforms (creates zend_float.h, defines certain macros, uses those
macros in zend_strtod.c and zend_operators.c), include the correct
configure checks that detect the switching method. zend_float.h is
basically a copy of my xpfpa.h from (*) where I put in the research on
the behaviour of different platforms and compiler versions.
(2) Modify round()
behaviour as described in the RFC (that also uses the
x87 FPU precision switch). The second part will only compile if the
first part was applied.
It is basically the same patch as I have already posted to this list -
just with a few cleanups. Here are the basic changes to the previous
patch versions:
a) Added Zend/tests/fpu_prec_001.phpt which tests for double precision.
With single, double-extended or quad precision, it will fail.
b) @Macrus: I've thought about your points wrt. cross-compilation and
I am now certain that if the configure test scripts compile & link,
the code will also work - so there is no need to execute it. I've
thus changed AC_TRY_RUN to AC_LINK_IFELSE.
c) Added
ext/standard/tests/math/round_{prerounding,large_exp,modes}.phpt
which check for the new behaviour of round()
.
d) Some minor cleanups to the FPU macros and configure checks.
Anyway, here are the patches, please remember that 1+3 test files are
added with the patches:
PHP 5.3, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-fpu.patch
PHP 5.3, round()
behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-round.patch
PHP 6, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-fpu.patch
PHP 6, round()
behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-round.patch
(*) http://www.christian-seiler.de/projekte/fpmath/
Regards,
Christian
PHP 5.3, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-fpu.patchPHP 5.3,
round()
behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-round.patchPHP 6, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-fpu.patchPHP 6,
round()
behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-round.patch
can someone with ZE karma handle commiting these patches?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
PHP 5.3, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-fpu.patchPHP 5.3,
round()
behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php53-round.patchPHP 6, ZE2 FPU precision:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-fpu.patchPHP 6,
round()
behaviour:
http://www.christian-seiler.de/temp/php/2008-11-28-fpu+rounding/php6-round.patch
I have given you ZE karma. Please commit this yourself no later than
Tuesday evening!
Oh and yes .. this means alpha3 is posponed until Thursday :(
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi,
I have given you ZE karma. Please commit this yourself no later than
Tuesday evening!
Thanks & done.
Regards,
Christian
Hi,
I have given you ZE karma. Please commit this yourself no later than
Tuesday evening!Thanks & done.
Thanks to you! =)
--
Wbr,
Antony Dovgal