Hi,
Today we will package and tag PHP 5.3 alpha3.
Any commits to the 5.3 branch today should be first ok'ed by Johannes.
For windows build fixes Pierre should be kept in the loop.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To
On Mon, Nov 10, 2008 at 10:41 AM, Lukas Kahwe Smith [EMAIL PROTECTED] 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
Lukas Kahwe Smith wrote:
On 10.11.2008, at 11:41, Jani Taskinen wrote:
2. 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
On Mon, 2008-11-10 at 12:41 +0200, Jani Taskinen wrote:
1. 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
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:
-Original Message-
From: Lester Caine [mailto:[EMAIL PROTECTED]
Sent: 10 November 2008 08:23
To: PHP internals
Subject: Re: [PHP-DEV] alpha3 or forever hold your peace
Lukas Kahwe Smith wrote:
I just wanted to ask everybody to skim over the changes for
PHP 5.3 we
have
Pierre Joye napsal(a):
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
2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]:
Pierre Joye napsal(a):
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
Kalle Sommer Nielsen wrote:
2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]:
Pierre Joye napsal(a):
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
On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen
[EMAIL PROTECTED] wrote:
2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]:
Pierre Joye napsal(a):
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
On 10.11.2008, at 16:06, Pierre Joye wrote:
On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen
[EMAIL PROTECTED] wrote:
2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]:
Pierre Joye napsal(a):
php_pspell.dll
php_snmp.dll
snmp and pspell are likely to do not be present in the next release
On 10.11.2008, at 12:27, Jani Taskinen wrote:
4. Output buffering rewrite MFH: http://bugs.php.net/bug.php?id=42641edit=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
On 10.11.2008, at 12:04, Jani Taskinen wrote:
Lukas Kahwe Smith wrote:
On 10.11.2008, at 11:41, Jani Taskinen wrote:
2. 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
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
Johannes Schlüter wrote:
On Mon, 2008-11-10 at 12:41 +0200, Jani Taskinen wrote:
1. 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
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.
On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED] 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
Pierre Joye wrote:
On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED] 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
On 10.11.2008, at 11:42, Lester Caine wrote:
Pierre Joye wrote:
On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED]
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
internals
Subject: Re: [PHP-DEV] alpha3 or forever hold your peace
Jared Williams wrote:
APC is another missing extension.
apc is in pecl - so would be provided with the PECL binary.
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/lsces/wiki/?page
On Mon, Nov 10, 2008 at 1:21 PM, Lester Caine [EMAIL PROTECTED] wrote:
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
-Original Message-
From: Pierre Joye [mailto:[EMAIL PROTECTED]
Sent: 10 November 2008 15:46
To: Jared Williams
Cc: Lester Caine; PHP internals
Subject: Re: [PHP-DEV] alpha3 or forever hold your peace
On Mon, Nov 10, 2008 at 4:43 PM, Jared Williams
[EMAIL PROTECTED] wrote
On Mon, Nov 10, 2008 at 1:18 PM, Lester Caine [EMAIL PROTECTED] wrote:
Alexey Zakhlestin wrote:
2) 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
Pierre Joye wrote:
pecl4win is dead and will not be restored anymore. In the next weeks,
pecl.php.net will provide the DLLs based on releases instead of random
snapshots, for each active branches (5.2, 5.3 and HEAD).
Does this mean we will have the same problem with pecl that we currently have
On Mon, Nov 10, 2008 at 18:06, Lester Caine [EMAIL PROTECTED] wrote:
Pierre Joye wrote:
pecl4win is dead and will not be restored anymore. In the next weeks,
pecl.php.net will provide the DLLs based on releases instead of random
snapshots, for each active branches (5.2, 5.3 and HEAD).
Does
On 10.11.2008, at 11:41, Jani Taskinen wrote:
2. 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
On Mon, Nov 10, 2008 at 4:43 PM, Jared Williams
[EMAIL PROTECTED] wrote:
But where?
pecl4win.php.net hasn't compiled APC since January, and certainly nothing
for 5.3
pecl4win is dead and will not be restored anymore. In the next weeks,
pecl.php.net will provide the DLLs based on releases
On 10.11.2008, at 12:06, Jani Taskinen wrote:
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/
Hannes Magnusson wrote:
On Mon, Nov 10, 2008 at 18:06, Lester Caine [EMAIL PROTECTED] wrote:
Pierre Joye wrote:
pecl4win is dead and will not be restored anymore. In the next weeks,
pecl.php.net will provide the DLLs based on releases instead of random
snapshots, for each active branches (5.2,
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
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
Alexey Zakhlestin wrote:
2) 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
On Fri, 2008-11-07 at 09:57 +0100, Pierre Joye wrote:
It is why alpha releases are for. If we don't merge it we should
simply drop it in HEAD and forget it. This code has been there for
years now, it is time to bring it to a stable branch. The same applies
for other code in HEAD not having
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
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
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:
Pierre Joye napsal(a):
On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen
[EMAIL PROTECTED] wrote:
2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]:
Pierre Joye napsal(a):
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
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
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
On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hi,
This are tentatively looking like alpha3 could hit on November 18th.
So everybody please try to get whatever you are working on ready to be
finished and committed by no later than 13th. So that packaging can happen
hi!
On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson
[EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hi,
This are tentatively looking like alpha3 could hit on November 18th.
So everybody please try to get whatever you are working on ready to
On 07.11.2008, at 09:30, Pierre Joye wrote:
hi!
On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson
[EMAIL PROTECTED] wrote:
On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith
[EMAIL PROTECTED] wrote:
Hi,
This are tentatively looking like alpha3 could hit on November 18th.
So everybody please
hi,
On Fri, Nov 7, 2008 at 9:51 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
To quote myself on this topic:
These are all convincing arguments to have done this earlier. But Johannes
and I are a bit worried, that this code did not see that much testing since
it was checked in to HEAD quite
Hi,
This are tentatively looking like alpha3 could hit on November 18th.
So everybody please try to get whatever you are working on ready to be
finished and committed by no later than 13th. So that packaging can
happen on a stable tree on the 17th.
regards,
Lukas Kahwe Smith
[EMAIL
2008/9/29 jvlad [EMAIL PROTECTED]
So as prevoius speaker suggested, and I personaly got to conclusion
in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
Will _you_ write such code? No. Will anybody from this list write such
code?
You may want to write
$a
In response to Larry Garfield's comment that [t]here's nothing
familiar about :: to 99.99% of PHP developers who haven't already
been playing with the alphas I'd like to point out that since PHP
5.1, the double colon is effectively used as a namespace operator by
extensions, in the sense that
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED] wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3 branch,
this is going to happen sooner or later. I found that :: just causes to many
questions when used in namespaces. Using
Hi,
Ok before we all go crazy with the NS separator debate, some reading
(which also links to a few interesting posts/sites):
http://marc.info/?l=php-internalsm=113313170231815w=2
http://marc.info/?l=php-internalsm=113345477123705w=2
http://marc.info/?l=php-internalsm=117742643931293w=2
I
2008/9/29 Jordi Boggiano [EMAIL PROTECTED]
On Mon, Sep 29, 2008 at 12:21 AM, Ryan Panning [EMAIL PROTECTED] wrote:
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3
branch,
this is going to happen sooner or later. I found that :: just causes
I thought that : was rejected because of the terniary operator? I'm not
going to search now for the discussion but for sure there were serious
objections against : , otherwise it would be natural to use it. How you
propose to handle the ambiguities like:
?
print
+1 for : from me.
Ternary. Operator. Trouble.
Otherwise it'd get my vote too.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote:
So as prevoius speaker suggested, and I personaly got to conclusion in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Monday 29 September 2008 18:35:45 Stefan Walk napisał(a):
On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote:
So as prevoius speaker suggested, and I personaly got to conclusion in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
Will _you_ write such code? No.
On 9/29/08, Stefan Walk [EMAIL PROTECTED] wrote:
So as prevoius speaker suggested, and I personaly got to conclusion in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
It's only a problem when you use fully qualified names inside a
ternary operation, and can easily be
So as prevoius speaker suggested, and I personaly got to conclusion in
other thread that : is ideal. Short, isn't taken.
$a = $b?A:B:C:D;
Will _you_ write such code? No. Will anybody from this list write such
code?
You may want to write
$a = $b?A:B:C
and how would php compiler
On Mon, 2008-09-29 at 19:24 +0200, Janusz Lewandowski wrote:
Monday 29 September 2008 18:35:45 Stefan Walk napisał(a):
On Monday 29 September 2008 18:05:48 Arvids Godjuks wrote:
So as prevoius speaker suggested, and I personaly got to conclusion in
other thread that : is ideal. Short,
On Mon, 29 Sep 2008 19:30:00 +0300, Vesselin Kenashkov [EMAIL PROTECTED]
wrote:
My proposal is (if possible/reasonable/performance wise of course) to have
a
fatal error thrown when during the parse time the engine discovers
duplicates like the one described above. What is the point to name
Le lundi 29 septembre 2008 à 13:48 -0500, Larry Garfield a écrit :
On Mon, 29 Sep 2008 19:30:00 +0300, Vesselin Kenashkov [EMAIL PROTECTED]
wrote:
My proposal is (if possible/reasonable/performance wise of course) to have
a
fatal error thrown when during the parse time the engine
Hi Greg,
The patch I posted here:
http://pear.php.net/~greg/ns.element.patch.txt
does exactly what you are talking about. For some reason, some people
find this too difficult to digest. I've already expressed my opinion on
the matter (after all, I did spend almost a week developing the
+1, or: Do, or do not. There is no 'try.'
- David
On 28.09.2008, at 16:29, Steph Fox wrote:
Hi Greg,
The patch I posted here:
http://pear.php.net/~greg/ns.element.patch.txt
does exactly what you are talking about. For some reason, some
people
find this too difficult to digest. I've
Steph Fox wrote:
I don't want to see that whole ns separator debate all over again any
more than you do, but I really don't see a good way to avoid it... sorry.
+1, I second this completely
From someone who *was* using namespaces developing against the 5.3
branch, this is going to happen
On Sat, Sep 27, 2008 at 8:10 AM, Greg Beaver [EMAIL PROTECTED] wrote:
I have to respectfully disagree with both of you:
Stas: choosing an imperfect solution when a better one already exists is
just plain stupid, and isn't what you want *or* what you suggested - the
solution you, Liz, Marcus
I would definitely have to agree. I would much prefer to have a minimal
solution implemented and then to iterate over it in the future than to try
to figure out the perfect implementation the first time.
Just from watching where the thread about namespaces has gone, I would
definitely have to say
Hi Greg,
Steph: the limited solution proposed by Stas and company (removing
functions [and I would add constants]/fixing name resolution) *is* a
basic solution that can be expanded on. I outlined the steps in my
reply. It's the best solution to the problem, not an imperfect one. A
namespace
Adding support for functions, constants and even variables is actually
quite do-able with the solution I suggested (different separator between
namespace name and function/constant/variable name) and can be added
easily.
Adding support for functions, constants and even variables is actually
jvlad wrote:
Adding support for functions, constants and even variables is actually
quite do-able with the solution I suggested (different separator between
namespace name and function/constant/variable name) and can be added
easily.
Adding support for functions, constants and even
Hi,
We are not yet ready to schedule alpha3, but I am hoping we can do it
in the first half of October. This is just a heads up to tell
everybody that yes there will be an alpha3 and a general timeframe.
This is not an invitation to go crazy and start committing features at
all. If you
Hey Lukas, Johannes, all...
We are not yet ready to schedule alpha3, but I am hoping we can do it in
the first half of October. This is just a heads up to tell everybody that
yes there will be an alpha3 and a general timeframe.
This is not an invitation to go crazy and start committing
Hi!
Does that mean we can drop namespace support until 6.0?
Please?
Rationale:
1) It's uber-contentious, and all the good stuff's only just starting to
turn up that would allow sane design decisions
I don't know what uber-contentios means, but no solution is going to
satisfy 100% of
Oh Stas, we have to fall out now!
Imperfect solution is much better than perpetual absence of any solution.
See, I'm not sure I agree with that.
I think 'imperfect but basic solution that can be expanded on' would be a
better approach than trying to do it all in one hit.
And I still think
Hi!
And I still think putting it off to PHP 6 would be a smart move. It's
the major thing that's holding up 5.3.
Nothing is holding anything. Lukas has release schedule, and namespace
implementation will fit it.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
Steph Fox wrote:
Oh Stas, we have to fall out now!
Imperfect solution is much better than perpetual absence of any solution.
See, I'm not sure I agree with that.
I think 'imperfect but basic solution that can be expanded on' would be
a better approach than trying to do it all in one
72 matches
Mail list logo
