RE: [PHP-DEV] FW: Help needed in benchmarking memory patch

Probably this patch is proper. I'll test it today-tomorrow. Thanks. Dmitry. > -Original Message- > From: Michael Vergoz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 11, 2006 10:33 PM > To: Andi Gutmans; 'Dmitry Stogov'; 'PHPdev' > Subject: Re: [PHP-DEV] FW: Help needed in benchmarking

Re: [PHP-DEV] Re: TextIterator changes

I think I'm done with TextIterator for now. Feel free to play with it. :) -Andrei On Jun 25, 2006, at 11:15 PM, Soenke Ruempler wrote: Michael Wallner wrote on Friday, June 23, 2006 11:27 PM: Andrei Zmievski wrote: TextIterator does not implement Iterator interfa

Re: [PHP-DEV] Re: More valuable error message handling

Marcus Boerger wrote: Hello Michael, yep, here too. track_errors is an optimizations when you don't want to debug but simply use your app. thats why i said that i would like to atleast be able to get the last error without having to mess/check track_errors ini setting. i think this is an a

RE: [PHP-DEV] [PATCH] array_fill: Allow an array to specify keys

I don't have a problem with the functionality and the patch doesn't seem problematic. I do question though whether we want to add this to array_fill()? Not sure if that parameter overloading is very intuitive as it doesn't just add one parameter. What do others think? Would you prefer an array_fill

RE: [PHP-DEV] More valuable error message handling

I definitely think that for production apps we should be able to turn this off. It could significantly slow down apps. > -Original Message- > From: Michael Wallner [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 11, 2006 3:35 AM > To: internals@lists.php.net > Subject: [PHP-DEV] More val

Re: [PHP-DEV] FW: Help needed in benchmarking memory patch

Here is a small patch allowing to correct the small leak. This one will have to be merge with that of Michael - (its patch is correct and does not contain any leak (I were not clear in my last mail) - thus +1) http://badcode.be/~descript/PHP/PHP_5_2-php-main.diff Michael Vergoz - Original

Re: [PHP-DEV] [PATCH] array_fill: Allow an array to specify keys

Hello Matt, Tuesday, July 11, 2006, 10:54:05 AM, you wrote: > Hi Marcus, > I'm replying again for clarification about the patch. When you first > replied and said it looked OK, you mentioned "once we agree to this," which > I assumed meant it could be used/committed. I saw array.c hasn't been

Re: [PHP-DEV] Re: More valuable error message handling

Hello Michael, yep, here too. track_errors is an optimizations when you don't want to debug but simply use your app. best regards marcus Tuesday, July 11, 2006, 5:21:09 PM, you wrote: > Antony Dovgal wrote: >> On 11.07.2006 14:38, Lukas Smith wrote: >>> Michael Wallner wrote: >>> - error

Re: [PHP-DEV] FW: Help needed in benchmarking memory patch

Salut Andi & Dmitry, If you have errors in your script you have a leak in PG(last_error_message) & PG(last_error_file) because of php_error_cb() which allocates via strdup() these two variables. It should be noted also that these variables are not given with NULL after their freed in php_error

RE: [PHP-DEV] FW: Help needed in benchmarking memory patch

Are you sure this isn't because the IIS thread is still running? One thread handles multiple requests. > -Original Message- > From: Michael Vergoz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 11, 2006 10:33 AM > To: Dmitry Stogov; 'Andi Gutmans'; PHPdev > Subject: Re: [PHP-DEV] FW: He

Re: [PHP-DEV] FW: Help needed in benchmarking memory patch

In fact I had found some leaks it would seem that ts_free_thread() after php_request_shutdown() solves all the problem. I am checking if it's bad but if not the case the SAPI ISAPI should have a small modification. mv- - Original Message - From: "Dmitry Stogov" <[EMAIL PROTECTED]> To:

Re: [PHP-DEV] Re: More valuable error message handling

Hi Mike For me +1 :) I just have to look at something because i found a mem-leak where you patch (near) I will write a mail soon Mv- -Original Message - From: "Michael Wallner" <[EMAIL PROTECTED]> To: Sent: Tuesday, July 11, 2006 4:53 PM Subject: [PHP-DEV] Re: More valuable error m

[PHP-DEV] RE : Extending include path to support stream wrappers

Greg Beaver wrote : > Allowing stream wrappers in include_path will open a potentially gigantic > security hole, making sure that it is closed will be a huge challenge, and > introduce a bit of overhead. I don't understand where the security hole would be. I see the stream wrappers as virtual d

Re: [PHP-DEV] Re: More valuable error message handling

Antony Dovgal wrote: On 11.07.2006 14:38, Lukas Smith wrote: Michael Wallner wrote: - error_get_last() Get the last error message. my wish would be that this one should work even if track_errors is not enabled. Yes, these functions should not depend on any INI directives. I'm with Ilia

[PHP-DEV] RE : Extending include path to support stream wrappers

Thanks for your answer, I have been searching for an alternate way for more than one month now but I still don't see any way to resolve the problem of relative includes in packaged files. The goal, here, is to package an existing software with as few modifications as possible. It is the only w

[PHP-DEV] Re: More valuable error message handling

I wrote: I therefore propose some new functionality with possibly this 3 new functions: - error_get_last() Get the last error message. - error_get_all() Get an array of all occurred errors. - error_clear_all() Reset error stack. Patch against 5_2: http://dev.iworks.at/PATCHES/errorstack.dif

[PHP-DEV] Re: Extending include path to support stream wrappers

But, once again, may I humbly ask you to focus on my primary question, instead of arguing about a potential alternative to PHAR. And I also repeat that my question is of great interest for PHAR too. I think it's an interresting, yet ultimately inefficient idea. I would recommend that if you *re

[PHP-DEV] Re: Extending include path to support stream wrappers

LAUPRETRE François (P) wrote: > Hello, > > I am currently implementing a packaging tool in PHP. If you know PHAR, it is > the same kind of tool, which allows to implement a virtual file tree in a > single physical file. > > In such a tool, every file path becomes a 'stream-wrapped' path and t

RE: [PHP-DEV] FW: Help needed in benchmarking memory patch

Hi Michael, The patch was tested in ZTS mode too. What SAPI you are talking about? (I would like to reproduce the problem). Thanks. Dmitry. > -Original Message- > From: Michael Vergoz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 11, 2006 1:22 PM > To: Andi Gutmans; internals@lists.p

Re: [PHP-DEV] Re: More valuable error message handling

On 11.07.2006 14:38, Lukas Smith wrote: Michael Wallner wrote: - error_get_last() Get the last error message. my wish would be that this one should work even if track_errors is not enabled. Yes, these functions should not depend on any INI directives. -- Wbr, Antony Dovgal -- PHP Inter

[PHP-DEV] Re: More valuable error message handling

Michael Wallner wrote: - error_get_last() Get the last error message. my wish would be that this one should work even if track_errors is not enabled. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] More valuable error message handling

Hi, I think many people agree that PHPs means for a developer to get the last error message(s) are way suboptimal. INI(track_errors) and $php_errormsg or hacking some error handler magic are--despite sep. extension facilities--the only one that come to mind, both cumbersome and unintuitive. I

Re: [PHP-DEV] FW: Help needed in benchmarking memory patch

Hi aAndy We didn't find a material difference between malloc() and mmap() though, most probably because malloc() at these sizes actually calls mmap(). You can have good difference with the mremap() of Linux because it directly changes the vector into memory without recopying these data. -- Be

Re: [PHP-DEV] [PATCH] array_fill: Allow an array to specify keys

Hi Marcus, I'm replying again for clarification about the patch. When you first replied and said it looked OK, you mentioned "once we agree to this," which I assumed meant it could be used/committed. I saw array.c hasn't been changed in CVS (though I don't know when that would happen anyway), so

Re: [PHP-DEV] RE : Extending include path to support stream wrappers

On 7/11/06, Robin Ericsson <[EMAIL PROTECTED]> wrote: On 7/11/06, Pierre <[EMAIL PROTECTED]> wrote: > On 7/11/06, LAUPRETRE François (P) <[EMAIL PROTECTED]> wrote: > > Maybe. But I couldn't find any documentation about it and its features. And its > > 'Download latest' link is broken. I had to d

Re: [PHP-DEV] RE : Extending include path to support stream wrappers

On 7/11/06, Pierre <[EMAIL PROTECTED]> wrote: On 7/11/06, LAUPRETRE François (P) <[EMAIL PROTECTED]> wrote: > Maybe. But I couldn't find any documentation about it and its features. And its > 'Download latest' link is broken. I had to download the C source code from CVS. It is not broken, ther

[PHP-DEV] CVS Account Request: thorstenr

My PEAR proposal "NTLMProxy" was accepted so I need a CVS account. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RE : Extending include path to support stream wrappers

On 7/11/06, LAUPRETRE François (P) <[EMAIL PROTECTED]> wrote: Marcus Boerger wrote : > have you ever looked at pecl/phar? It can do that already. Maybe. But I couldn't find any documentation about it and its features. And its 'Download latest' link is broken. I had to download the C source code

[PHP-DEV] RE : Extending include path to support stream wrappers

Marcus Boerger wrote : > have you ever looked at pecl/phar? It can do that already. Maybe. But I couldn't find any documentation about it and its features. And its 'Download latest' link is broken. I had to download the C source code from CVS. But, once again, may I humbly ask you to focus on my