Hi Laruence,
Thank you for sending this.
I'm not sure if the patch is completely correct.
With the patch all the threads share the single copy of
script_encoding_list and when one thread terminates it calls
compiler_globals_dtor() and frees the script_encoding_list. But other
threads still ke
On 04 May 2012, at 21:46, Hannes Magnusson wrote:
> On Fri, May 4, 2012 at 8:30 PM, Scott MacVicar wrote:
>> This caused a few bugs for us / confusion. The final keyword is accepted
>> inside a trait but it the class also defines a method without the final
>> keyword this takes precedence.
Th
>
>
> Hmm I'd never really thought about that before. But now that you mention
> it, that does sound like a problem. Honestly, I can see no value in
> maintaining a different "standard" for what constitutes a set or not-set
> variable depending on the function. While I understand Pierre's point
On Fri, May 4, 2012 at 7:01 AM, C.Koy wrote:
> On 5/2/2012 10:03 PM, Galen Wright-Watson wrote:
>
>> On Wed, May 2, 2012 at 5:23 AM, C.Koy wrote:
>>
>> On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
>>>
>>> On Thu, Apr 26, 2012 at 3:45 AM, C.Koy wrote:
As of 5.3.0 this bug does n
On Fri, May 4, 2012 at 1:27 PM, Ferenc Kovacs wrote:
>
>> I've been following the debate and I'm still a bit unclear as to what the
>> benefit would be to allowing non-variables in isset(). I mean, as was
>> stated earlier, expressions are neither "set" nor "unset". Furthermore,
>> if
>> you we
>
>
> I've been following the debate and I'm still a bit unclear as to what the
> benefit would be to allowing non-variables in isset(). I mean, as was
> stated earlier, expressions are neither "set" nor "unset". Furthermore, if
> you were to assign a variable to any valid expression (empty or ot
On Fri, May 4, 2012 at 8:30 PM, Scott MacVicar wrote:
> This caused a few bugs for us / confusion. The final keyword is accepted
> inside a trait but it the class also defines a method without the final
> keyword this takes precedence.
>
it also ignores visibility abstract and static..
I thoug
On Fri, May 4, 2012 at 11:48 AM, Richard Lynch wrote:
> On Wed, May 2, 2012 4:43 am, Pierre Joye wrote:
> >>> empty() on the other hand, tests if something is empty, and only if
> >>> it
> >>> is empty. The result of an expression can be empty.
> >>>
> >>
> >> an expression can also have a value
On Wed, May 2, 2012 4:43 am, Pierre Joye wrote:
>>> empty() on the other hand, tests if something is empty, and only if
>>> it
>>> is empty. The result of an expression can be empty.
>>>
>>
>> an expression can also have a value of null.
>
> And NULL is empty. No issue here.
Expressions can also r
This caused a few bugs for us / confusion. The final keyword is accepted inside
a trait but it the class also defines a method without the final keyword this
takes precedence.
Two solutions:
Enforce final when a trait defines -
https://whisky.macvicar.net/patches/0001-If-a-trait-declares-a-meth
On 5/2/2012 10:03 PM, Galen Wright-Watson wrote:
On Wed, May 2, 2012 at 5:23 AM, C.Koy wrote:
On 5/1/2012 9:11 PM, Galen Wright-Watson wrote:
On Thu, Apr 26, 2012 at 3:45 AM, C.Koy wrote:
As of 5.3.0 this bug does not exist for function names. Only classes and
interfaces.
Turns out
Hi Everyone
>> So, I think we're back to "urban legend" territory.
I've updated the documentation for readfile() to help send more people
down the path of checking for output buffering, and disabling that
rather than contriving loops with fread().
http://docs.php.net/readfile
paul
--
Paul
On Tue, May 1, 2012 at 8:44 PM, Paul Reinheimer wrote:
> Hi,
>
>> It sounds like it. In that case the memory spike is happening in the output
>> buffer, where the file is streamed into by readfile() in 8K chunks until the
>> output buffer explodes. :-)
>>
>> So, I think we're back to "urban legen
13 matches
Mail list logo
