Rasmus Lerdorf wrote:
The other way to solve this would be to make max_input_vars PHP_INI_ALL
and then just let people ini_set() their way around the limit.
That's probably going to confuse people if it doesn't change the HTTP
request parsing limit too, IMHO. And I'm not sure that's something
Hi!
That's probably going to confuse people if it doesn't change the HTTP
request parsing limit too, IMHO. And I'm not sure that's something we
necessarily want.
Err, how you can change it after HTTP request has already been parsed?
--
Stanislav Malyshev, Software Architect
SugarCRM:
On 03/14/2012 02:40 PM, Ryan McCue wrote:
Rasmus Lerdorf wrote:
The other way to solve this would be to make max_input_vars PHP_INI_ALL
and then just let people ini_set() their way around the limit.
That's probably going to confuse people if it doesn't change the HTTP
request parsing limit
Stas Malyshev wrote:
Hi!
That's probably going to confuse people if it doesn't change the HTTP
request parsing limit too, IMHO. And I'm not sure that's something we
necessarily want.
Err, how you can change it after HTTP request has already been parsed?
I'm not arguing that it should, I'm
Hi list,
i'm new on the list so im sorry if this problem has been already discussed.
I have an Apache module that, in translate_name hook, sets PHP ini values at
runtime with zend_alter_ini_entry() (mod_php).
The systems used for tests is a debian lenny, with php5.3.3 manually compiled
from
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
**foreach($a as $key = $val) {
** $a[$key] =
On Thu, March 15, 2012 9:21 am, Klaus Silveira wrote:
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
**foreach($a as $key
On Thu, Mar 15, 2012 at 3:21 PM, Klaus Silveira klaussilve...@php.net wrote:
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
On Wed, March 14, 2012 12:09 pm, Ferenc Kovacs wrote:
On Mon, Jul 25, 2011 at 12:34 PM, Richard Quadling
rquadl...@gmail.comwrote:
On 23 July 2011 23:29, Ferenc Kovacs tyr...@gmail.com wrote:
I would propose that the defaul values(PHP_INI_ENTRY_*) and the
php.ini-production should be keep
On Thu, March 15, 2012 5:01 am, Ryan McCue wrote:
I'm not arguing that it should, I'm saying that in the INI it refers
to
the HTTP arguments, while in the code (via ini_set) it would not
affect
this. I think that could be confusing for users who don't realise the
script is only loaded after
2012/3/15 Nikita Popov nikita@googlemail.com:
If I am understanding the text correctly it is saying that
$f1 = f1();
$f2 = f2($f1);
$f3 = f3($f2);
is using more memory than
$f3 = f3(f2(f1()));
For me this doesn't make any sense. In the latter case PHP will also
create
Just to elaborate on what Patrick said, in the first case the variables are
temporary, where in the second they persist even after you finish your
loop. So even after the foreach is finished, the $f1, $f2, and $f3
variables are still storing data- even though it is no longer needed.
In order to
Hi!
If I am understanding the text correctly it is saying that
$f1 = f1();
$f2 = f2($f1);
$f3 = f3($f2);
is using more memory than
$f3 = f3(f2(f1()));
Short answer: it doesn't matter, use either as you wish.
Long answer: Technically, the former also uses hash buckets to
On Thu, Mar 15, 2012 at 5:22 PM, Patrick ALLAERT patrickalla...@php.net wrote:
2012/3/15 Nikita Popov nikita@googlemail.com:
If I am understanding the text correctly it is saying that
$f1 = f1();
$f2 = f2($f1);
$f3 = f3($f2);
is using more memory than
$f3 = f3(f2(f1()));
On Thu, Mar 15, 2012 at 4:54 PM, Nikita Popov nikita@googlemail.com wrote:
On Thu, Mar 15, 2012 at 5:22 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
2012/3/15 Nikita Popov nikita@googlemail.com:
If I am understanding the text correctly it is saying that
$f1 = f1();
$f2 =
On Thu, Mar 15, 2012 at 5:39 PM, Paul Dragoonis dragoo...@gmail.com wrote:
On Thu, Mar 15, 2012 at 4:54 PM, Nikita Popov nikita@googlemail.com
wrote:
On Thu, Mar 15, 2012 at 5:22 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
2012/3/15 Nikita Popov nikita@googlemail.com:
If I am
PHP Internals folks--
My name is Eric Stenson, and I'm a developer at Microsoft working on IIS.
I've been given the task of upgrading our php_wincache extension to work
on PHP5.4, and I've run into a problem.
The problem I'm running into is the php_cgi!main() on PHP5.4 has changed
behavior.
Am 15.03.2012 18:41, schrieb Paul Dragoonis:
I don't really know when PHP frees temporary variables, but my guess
was that they are freed when the scope is left.
Each variable has a refcount, then that hits 0 it can be freed up.
To add to that. A zval will have a refcount, so if you do $a
The $b on this example would be freed as it is in the function's scope, and
not the global scope. The exception to this would be a static variable
within a function, which would persist for future use within the function.
Class properties on the other hand will persist until the object is
thanks
exactly what i assumed, but better to be sure instead
wasting somewhere ressources without need :-)
Am 15.03.2012 20:10, schrieb Michael Stowe:
The $b on this example would be freed as it is in the function's scope, and
not the global scope. The exception to this would be a static
Hi,
I am sorry. I was ill in the last days and we some
implementations were just finished. We have to
delay the migration till Sunday 15. I am working
workflow FAQ atm.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 15 Mar 2012 19:56:11 +0100, Eric Stenson erics...@microsoft.com
wrote:
The problem I'm running into is the php_cgi!main() on PHP5.4 has changed
behavior. The php_cgi!main() function is seeing us return a
ZEND_HANDLE_STREAM,
and it's assuming that the
On 2012-03-15, David Soria Parra d...@php.net wrote:
Hi,
I am sorry. I was ill in the last days and we some
implementations were just finished. We have to
delay the migration till Sunday 15. I am working
workflow FAQ atm.
oh god, that's a mess. It's Sunday 18.
--
PHP Internals - PHP
Lester Caine les...@lsces.co.uk writes:
jeremiah.do...@gmail.com wrote:
I hope that clarifies things a bit. It definitely doesn't make grokking
things a whole lot easier, and it is certainly *possible* to follow a
very svnish workflow using git (and may sometimes make sense to,
although I
24 matches
Mail list logo
