Hi,
On Thu, 2008-03-06 at 20:43 -0600, Gregory Beaver wrote:
Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.
Yes, that's what I'd like, too. Te problem there is that developers
using CVS checkouts should get a CVS checkout f
i just hope the issue described in
http://www.mail-archive.com/internals@lists.php.net/msg32601.html will
be resolved before 5.3 is out. it is the only problem that breaks
opcode cacher support as far as i can see by now. e.g.: with this
problem fixed, all test cases will pass when XCache is
On 07.03.2008 05:43, Gregory Beaver wrote:
Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.
I'm not sure it's good idea.
IMO it should go trough much more thorough testing to be included into the core.
And I'm still not
On 3/7/08, Antony Dovgal [EMAIL PROTECTED] wrote:
On 07.03.2008 05:43, Gregory Beaver wrote:
Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.
I'm not sure it's good idea.
IMO it should go trough much more thorough
On 07.03.2008 12:32, Alexey Zakhlestin wrote:
I'm not sure it's good idea.
IMO it should go trough much more thorough testing to be included into the
core.
And I'm still not convinced we should include any PECL extensions in the
core,
I believe it should go the other way round.
it
Hi,
The attached patch for PHP_5_3 is going to provide general solution to
control some aspects of PHP compilation. It is absolutely necessary for
all opcode caches to make cached scripts work exactly in the same way as
non-cached.
The problem occurs because early binding of inherited classes is
On Fri, 7 Mar 2008, Dmitry Stogov wrote:
The attached patch for PHP_5_3 is going to provide general solution to
control some aspects of PHP compilation. It is absolutely necessary for
all opcode caches to make cached scripts work exactly in the same way as
non-cached.
There's no attached
The patch for this issue is sent to @internals.
It will be probably commited on next week.
Please try to play with it.
Thanks. Dmitry,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
phpxcache
Sent: Friday, March 07, 2008 12:27 PM
To: Johannes
gotcha, i'll check it within 24hours
thanks for your great work
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Tony,
Well, lets make it convenient then.
Including everything into the core is not a solution.
You seem to have missed an entire thread on the subject, along with the
conclusion that the mechanisms for really doing a good job on this can't
sanely be in place before 5.3.0 is released.
On 07.03.2008 16:09, Steph Fox wrote:
Hi Tony,
Well, lets make it convenient then.
Including everything into the core is not a solution.
You seem to have missed an entire thread on the subject, along with the
conclusion that the mechanisms for really doing a good job on this can't
The very same could be said about phar.
It's going through a final wave of intensive development that *adds* to
existing features; the core functionality's solid, and has been for some
time. Given the end of April 'freeze', we're at least 2 months away from a
5.3 release. Assuming Greg's
Antony Dovgal wrote:
On 07.03.2008 05:43, Gregory Beaver wrote:
Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.
I'm not sure it's good idea.
IMO it should go trough much more thorough testing to be included into the
On 07.03.2008 18:15, Gregory Beaver wrote:
I wholeheartedly agree that phar needs more testing. I also think some
other areas of php could have used more testing
Undoubtedly.
And I'm still not convinced we should include any PECL extensions in the
core,
I believe it should go the other
Hello,
no reply means no! don't touch. ?
Thanks.
2008/3/3, Felipe Pena [EMAIL PROTECTED]:
Hello developers,
I made a patch for the bug#39018:
$x = 'test';
@$x[4] == 'a';
(@$x[4]) == 'a';
(@($x[4])) == 'a';
@($x[4]) == 'a';
$foo = 'test'; $x = @$foo[6];
Actually, all cases
It means You didn't commit, nobody cares.
Read: Just commit..that'll wake them up. ;)
--Jani
On Fri, 2008-03-07 at 12:43 -0300, Felipe Pena wrote:
Hello,
no reply means no! don't touch. ?
Thanks.
2008/3/3, Felipe Pena [EMAIL PROTECTED]:
Hello developers,
I made a patch for
Hi!
I wonder - is there a reason why short_open_tag config value is per-dir
and not PHP_INI_ALL? After all, as I understand, it is private for each
compilation. So suppose you preferred it generally off (you do XML,
etc.) but you have some files in your app where you want it on - would
there
Hi!
no reply means no! don't touch. ?
Usually it means doesn't look bad enough to cry out right now, need
time to figure it out :)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime
Hi Stas,
Am Freitag, den 07.03.2008, 12:45 -0800 schrieb Stanislav Malyshev:
[...]
I wonder - is there a reason why short_open_tag config value is per-dir
and not PHP_INI_ALL? After all, as I understand, it is private for each
compilation. So suppose you preferred it generally off (you do
Hello Philip,
first of all I filled in the application after I informed the people
running the program. As soon as we get approved you will hear more from
me. Until then I am happy that you do all this work and collect ideas.
marcus
Tuesday, March 4, 2008, 11:17:45 PM, you wrote:
The
Hi,
When I posted yesterday's patch to add stream support to include_path
(http://news.php.net/php.internals/36031) I mentioned that I suspected
benchmarking would reveal it to be slow. My primary goal is to provide
no impact on current users who are using a traditional include_path,
with a
Hi,
php_resolve_path does not exit if passed a stream wrapper, but instead
tries to find it in include_path. This can cause really weird error
messages and breaks pecl/phar completely (and probably other stream
wrappers), so I added stream wrapper detection to the exit shunt in the
start of
On 3/8/08, Gregory Beaver [EMAIL PROTECTED] wrote:
Hi,
When I posted yesterday's patch to add stream support to include_path
(http://news.php.net/php.internals/36031) I mentioned that I suspected
benchmarking would reveal it to be slow. My primary goal is to provide
no impact on current
I'm not sure if this is the right list, because well, it isn't Internal to PHP
and isn't it helping with PHP in any way. Regardless, I've been searching for
many of hours and I would like an answer. (PS: There aren't very many people
outside of this list who knows the answer to my question
24 matches
Mail list logo
