On 07.03.2008 02:18, Andi Gutmans wrote:
>> I'd like to ask to re-consider dropping ze1_compatibility_mode and
>> finally drop it in 5.3.
>> It just doesn't work, so there is no point to keep it.
>
> Yes I think it makes sense.
> Do we just document it in the UPGRADING doc or for 5.3 raise an E_ER
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 enable
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 con
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 tho
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 r
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 n
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. The
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'
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 incl
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 t
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 o
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];
>
> Actual
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
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 Runtim
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 Googl
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 secon
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 php_r
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
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 anywa
25 matches
Mail list logo
