On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen wrote:
> Hi
>
> 2013/4/12 Pierre Joye :
> > On Thu, Apr 11, 2013 at 11:17 PM, Pierrick Charron
> wrote:
> >> Including 5.3 and 5.4 ??
>
> If removed in 5.3 and 5.4, theres no need for the constant anymore.
>
Right :-)
I agree with Pierre as
On Fri, Apr 12, 2013 at 4:00 PM, Julien Pauli wrote:
> On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen wrote:
>
>> Hi
>>
>> 2013/4/12 Pierre Joye :
>> > On Thu, Apr 11, 2013 at 11:17 PM, Pierrick Charron
>> wrote:
>> >> Including 5.3 and 5.4 ??
>>
>> If removed in 5.3 and 5.4, theres no ne
On Fri, 2013-04-12 at 10:00 +0200, Julien Pauli wrote:
> On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen wrote:
>
> > Hi
> >
> > 2013/4/12 Pierre Joye :
> > > On Thu, Apr 11, 2013 at 11:17 PM, Pierrick Charron
> > wrote:
> > >> Including 5.3 and 5.4 ??
> >
> > If removed in 5.3 and 5.4, th
On Fri, Apr 12, 2013 at 10:07 AM, Johannes Schlüter
wrote:
> On Fri, 2013-04-12 at 10:00 +0200, Julien Pauli wrote:
>> On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen wrote:
>>
>> > Hi
>> >
>> > 2013/4/12 Pierre Joye :
>> > > On Thu, Apr 11, 2013 at 11:17 PM, Pierrick Charron
>> > wrote:
>
On Wed, Apr 10, 2013 at 7:14 PM, Dmitry Stogov wrote:
> Hi,
>
> 1) I didn't get why do we need fprintf("Loaded/Unloaded extension"). It'll
> break all the tests in DEBUG mode
>
> 2) zend_error() may work through SAPI handler (e.g. for FastCGI sapi it
> may try to send error message to WebServer w
On Fri, Apr 12, 2013 at 10:53 AM, Julien Pauli wrote:
> On Wed, Apr 10, 2013 at 7:14 PM, Dmitry Stogov wrote:
>
> > Hi,
> >
> > 1) I didn't get why do we need fprintf("Loaded/Unloaded extension").
> It'll
> > break all the tests in DEBUG mode
> >
> > 2) zend_error() may work through SAPI handler
hi Dmitry,
Is there any reason for:
http://lxr.php.net/xref/PHP_5_5/ext/opcache/shared_alloc_win32.c#260
Is it a mistake as it Should PROCESSOR_ARCHITECTURE_AMD64 or
PROCESSOR_ARCHITECTURE_INTEL? Or is x64 actually not supported? If
yes, what are the reasons?
Thanks!
Cheers,
--
Pierre
@pierre
+1
On 12 April 2013 04:07, Johannes Schlüter wrote:
> On Fri, 2013-04-12 at 10:00 +0200, Julien Pauli wrote:
> > On Fri, Apr 12, 2013 at 1:34 AM, Kalle Sommer Nielsen
> wrote:
> >
> > > Hi
> > >
> > > 2013/4/12 Pierre Joye :
> > > > On Thu, Apr 11, 2013 at 11:17 PM, Pierrick Charron <
> pierr..
On 2013-04-12, Johannes Schl�ter wrote:
> 5.3 users might depend on some part of the behavior and have learned to
> live with bugs. We shouldn't kick "features" at this stage.
curlwrappers should definatly stay in 5.3 and 5.4. I have no problem
with having them removed in 5.5 (with an RFC) but I
On Fri, Apr 12, 2013 at 4:09 PM, David Soria Parra wrote:
> On 2013-04-12, Johannes Schlüter wrote:
> > 5.3 users might depend on some part of the behavior and have learned to
> > live with bugs. We shouldn't kick "features" at this stage.
>
> curlwrappers should definatly stay in 5.3 and 5.4. I
Pierre Joye in php.internals (Fri, 12 Apr 2013 14:31:38 +0200):
>Is there any reason for:
>http://lxr.php.net/xref/PHP_5_5/ext/opcache/shared_alloc_win32.c#260
>
>Is it a mistake as it Should PROCESSOR_ARCHITECTURE_AMD64 or
>PROCESSOR_ARCHITECTURE_INTEL? Or is x64 actually not supported? If
>yes, w
Hi!
> 5.3 users might depend on some part of the behavior and have learned to
> live with bugs. We shouldn't kick "features" at this stage.
I agree, for 5.4 too. We had it for a long time, and however buggy or
broken it is, there might be people that use it, and stable version
implies promise the
Hi!
> I don't think this is a safe optimization. In the following case it would
> output 'b' and not 'a' which is the correct result:
>
> a.php:
> define('FOO', 'a');
> include('b.php');
> ?>
>
> b.php:
> define('FOO', 'b');
> echo FOO;
> ?>
>
> It is certainly not likely for a constant to be
On Fri, Apr 12, 2013 at 2:00 PM, Stas Malyshev wrote:
> Hi!
>
>> 5.3 users might depend on some part of the behavior and have learned to
>> live with bugs. We shouldn't kick "features" at this stage.
>
> I agree, for 5.4 too. We had it for a long time, and however buggy or
> broken it is, there mi
Hi!
> I don't know who suggested getting rid of it in 5.3 or 5.4, that is
> ofcourse seriously stupid thing to do.
> The original request was to kill it dead in 5.5, and remove the
> constant again from 5.3 and 5.4.
OK, I agree with that. I think origination of this was Pierre's comment
to apply
Hi!
> I may commit it into master and pecl, but it means that pecl branch is
> going to be ahead of PHP-5.5.
In general, I think there's no harm in trying out new stuff on PECL -
and marking those as alpha/beta initially - pecl has a mechanism to
choose if you want only stable or also bleeding ed
16 matches
Mail list logo
