Hi!
As much as I agree on the interface part, changing my sentence from
containing 'interface' to 'protocol' makes it even a bug today. And that
by the way was the purpose of my mail.
I think it is not right to call it a "bug", since it works exactly as it
was intended and designed to work. I
Hi!
# php -n -r 'for($i=0;$i<10;$i++) { for($args="",$j=0;$j<75;$j++) $args
.= "a=$j&"; unset($args); echo memory_get_usage()."\n"; }'
55872
56100
56172
56240
56304
56364
56420
56420
56420
56420
This looks like cache filling up, not a leak. Unless it doesn't stop at
some boundary.
--
Stanisl
Manuel Mausz wrote:
Rasmus Lerdorf wrote:
Note that you don't actually need to send the request. It looks like
repeatedly doing:
$ch = curl_init();
curl_setopt($ch, CURLOPT_POSTFIELDS, $args);
curl_close($ch);
Is enough to do it. Still looking at the code. Seems like
zend_llist_clean(&ch->t
Rasmus Lerdorf wrote:
> Note that you don't actually need to send the request. It looks like
> repeatedly doing:
>
> $ch = curl_init();
> curl_setopt($ch, CURLOPT_POSTFIELDS, $args);
> curl_close($ch);
>
> Is enough to do it. Still looking at the code. Seems like
> zend_llist_clean(&ch->to_fre
Cristian Rodríguez wrote:
Rasmus Lerdorf escribió:
Can someone spot why this code
(tested in both 5.2.5 and 5.3)
outputs:
for me
start 120400
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
POST 124968
POST 125928
POST 126608
P
Rasmus Lerdorf escribió:
Can someone spot why this code
(tested in both 5.2.5 and 5.3)
outputs:
for me
start 120400
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
GET 122624
POST 124968
POST 125928
POST 126608
POST 127272
POST 127920
POST
Hello Stanislav,
Sunday, May 18, 2008, 9:01:36 PM, you wrote:
> Hi!
>> declared and part of an interface. Removing it means changing the
>> interface means breaking inheritance. So making this possible is a bug in
>> the engine. End of the story.
> Or that makes interface variables make much le
Hannes Magnusson wrote:
> On Sun, May 18, 2008 at 8:14 PM, David Soria Parra <[EMAIL PROTECTED]> wrote:
>> Hannes Magnusson wrote:
>>> On Sun, May 18, 2008 at 7:15 PM, David Soria Parra <[EMAIL PROTECTED]>
>>> wrote:
dsp Sun May 18 17:15:08 2008 UTC
Modified files:
On Sun, May 18, 2008 at 8:14 PM, David Soria Parra <[EMAIL PROTECTED]> wrote:
> Hannes Magnusson wrote:
>> On Sun, May 18, 2008 at 7:15 PM, David Soria Parra <[EMAIL PROTECTED]> wrote:
>>> dsp Sun May 18 17:15:08 2008 UTC
>>>
>>> Modified files:
>>>/php-src/ext/mcrypt mcrypt.c
>>>
Hi!
declared and part of an interface. Removing it means changing the
interface means breaking inheritance. So making this possible is a bug in
the engine. End of the story.
Or that makes interface variables make much less sense than initially
thought :)
--
Stanislav Malyshev, Zend Software
Hi!
Just to make this clear once and for ever. If unset() deletes the property then:
But that's what unset does right now in any context. It deletes the
variable given as its argument. Changing this may have a lot of
unexpected effects.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL
Hello Christian,
Sunday, May 18, 2008, 7:16:55 PM, you wrote:
> Hi Marcus,
> Am 18.05.2008 um 18:41 schrieb Marcus Boerger:
>> Just to make this clear once and for ever. If unset() deletes the
>> property then:
>> a) it would break inheritance
>> b) accomplish nothing, as the next access would
Hi Marcus,
Am 18.05.2008 um 18:41 schrieb Marcus Boerger:
Just to make this clear once and for ever. If unset() deletes the
property then:
a) it would break inheritance
b) accomplish nothing, as the next access would simply recreate it
Ok, you don't want this thread to die, so here we go: Yo
Hello Christian,
Sunday, May 18, 2008, 1:30:08 PM, you wrote:
> Hi Marcus,
> Am 18.05.2008 um 13:20 schrieb Marcus Boerger:
>> Not allowing unset() is the bug. Having unset delete the property
>> would be
>> the error. As long as the property still exists with value NULL all is
>> fine.
> I t
Hi all,
On Wed, 2008-05-14 at 13:59 +0100, "Steph Fox" wrote:
I wrote a macro to allow us to use the same code for the extension in
both
branches, but it occurs to me that the zstr union definition might change
or
even disappear when PHP 6 becomes Unicode-only. Is that likely? I don't
know. S
Hi Marcus,
Am 18.05.2008 um 13:20 schrieb Marcus Boerger:
Not allowing unset() is the bug. Having unset delete the property
would be
the error. As long as the property still exists with value NULL all is
fine.
I think unset($foo->bar) should unset while $foo->bar = null should
set to null
Hello Christian,
Wednesday, May 14, 2008, 10:57:24 AM, you wrote:
> Am 14.05.2008 um 02:06 schrieb Marcus Boerger:
>>> So you are saying that
>>>$o_Foo->bar = array(42);
>>> is ok when the class "expects" a string but
>>>unset($o_Foo->bar);
>>> or (as as slight variation)
>>>
Hello Gregory,
aren't we simply using streams here only? If so we can still build phar
statically with I'd prefer very much. And the streams stuff would be found
if present. The optional dependency would then ensure correct load order.
marcus
Friday, May 16, 2008, 2:05:35 AM, you wrote:
> Hi,
18 matches
Mail list logo
