On Wed, Feb 27, 2013 at 9:06 PM, Stas Malyshev wrote:
> Hi!
>
> > May someone merge this PR (#290) as there are no arguments against it?
>
> I just outlined arguments against it in my last emails. If your email is
> not working properly and you miss some emails please check the list
> archives.
>
Hi!
> May someone merge this PR (#290) as there are no arguments against it?
I just outlined arguments against it in my last emails. If your email is
not working properly and you miss some emails please check the list
archives.
> Or do I have to wait a little bit? (How long?)
In my personal opi
May someone merge this PR (#290) as there are no arguments against it?
Or do I have to wait a little bit? (How long?)
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 25.2.2013 um 22:01 schrieb Johannes Schlüter :
> On Mon, 2013-02-25 at 20:36 +0100, Bob Weinand wrote:
>>
>> I can increase the default limit to 1000, but if it is too high it has
>> exactly no sense.
>
> Which is exactly the issue i mentioned about being a "good default"
>
>> We don't discu
On Mon, 2013-02-25 at 20:36 +0100, Bob Weinand wrote:
>
> I can increase the default limit to 1000, but if it is too high it has
> exactly no sense.
Which is exactly the issue i mentioned about being a "good default"
> We don't discuss about xDebug, but about integrating it into the
> core?
We
Forgotten to cc to internals list:
Am 25.2.2013 um 19:50 schrieb Stas Malyshev :
> Hi!
>
>> You may use recursive functions (which are limited by the memory_limit),
>> but if you use recursive magics, it's a design error. This is not the purpose
>> of magics (, call_user_func(_array)?) and simp
Hi!
> You may use recursive functions (which are limited by the memory_limit),
> but if you use recursive magics, it's a design error. This is not the purpose
> of magics (, call_user_func(_array)?) and simply an abuse of the language.
I think you are confusing magic functions with internal funct
Am 25.2.2013 um 19:10 schrieb Stas Malyshev :
> Hi!
>
>> Yes, but you can do an approximation. And in 99.999% of the cases 100
>> will be enough. I can hardly imagine a case where you need to do over
>> 100 implicit function calls. They should fit in every normal stack size of
>> servers today.
>
Am 25.2.2013 um 19:08 schrieb Stas Malyshev :
> Hi!
>
>>
>> p.s.: There is no reason why not to fix this in this way, I think,
>
> There actually is. First, any option modifying engine behavior creates a
> compatibility problem, since now the code that needs to work with it has
> to check and b
Hi!
> Yes, but you can do an approximation. And in 99.999% of the cases 100
> will be enough. I can hardly imagine a case where you need to do over
> 100 implicit function calls. They should fit in every normal stack size of
> servers today.
Depth-first search in a modest-size data structure woul
Hi!
>
> p.s.: There is no reason why not to fix this in this way, I think,
There actually is. First, any option modifying engine behavior creates a
compatibility problem, since now the code that needs to work with it has
to check and be tested for yet another variable. Second, why does it
concen
Am 25.2.2013 um 17:45 schrieb Johannes Schlüter :
> On Mon, 2013-02-25 at 16:36 +0100, Bob Weinand wrote:
>> p.s.: There is no reason why not to fix this in this way, I think, as
>> you can test at how may iterations the stack will overflow and set the
>> limit near to this maximum. Which is exact
On Mon, 2013-02-25 at 16:36 +0100, Bob Weinand wrote:
> p.s.: There is no reason why not to fix this in this way, I think, as
> you can test at how may iterations the stack will overflow and set the
> limit near to this maximum. Which is exactly what we have already
> today, only without possible c
13 matches
Mail list logo
