Hi!
The problem is that the loading/unloading of the scanner and parser can
be significant overhead, and by cramming all code into a single file,
can result in a 10%-30% performance improvement over code in separate
files, even with an opcode cache. This has been verified independently
Not on
Hi!
So I ask you all to review the RFC and provide feedback. If you feel
Here's my feedback on the RFC.
1. The RFC seems to assume or imply that PHP programmers have extensive
C++ experience. IMHO it is not true for the majority of PHP programmers.
2. Phar has nothing to do with file conca
Hi,
Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for
PHP_5_3. I don't know output buffering part very well, and I'm not
completely sure about this fix, so please review it.
The patch changes behavior of output buffering a bit. In case of fatal
error all output buffers opene
IIRC, there was some sort of OB rewrite done in HEAD..is this bug only
present in PHP_5_3? If so, I'd say the OB rewrite should be done in
PHP_5_3 already..
--Jani
Dmitry Stogov wrote:
Hi,
Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for
PHP_5_3. I don't know output b
Jani Taskinen wrote:
> IIRC, there was some sort of OB rewrite done in HEAD..is this bug only
> present in PHP_5_3? If so, I'd say the OB rewrite should be done in
> PHP_5_3 already..
The bug occurs in both 5.3 and HEAD.
Thanks. Dmitry.
> --Jani
>
>
> Dmitry Stogov wrote:
>> Hi,
>>
>> Attach
Dmitry Stogov wrote:
Hi,
Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for
PHP_5_3. I don't know output buffering part very well, and I'm not
completely sure about this fix, so please review it.
The patch changes behavior of output buffering a bit. In case of fatal
error a
Jani Taskinen wrote:
>>> Dmitry Stogov wrote:
Hi,
Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for
PHP_5_3. I don't know output buffering part very well, and I'm not
completely sure about this fix, so please review it.
The patch changes be
Hello Stanislav,
Tuesday, September 2, 2008, 9:51:38 AM, you wrote:
> Hi!
>> The problem is that the loading/unloading of the scanner and parser can
>> be significant overhead, and by cramming all code into a single file,
>> can result in a 10%-30% performance improvement over code in separate
>
Hello Stanislav,
Tuesday, September 2, 2008, 9:58:15 AM, you wrote:
> Hi!
>> So I ask you all to review the RFC and provide feedback. If you feel
> Here's my feedback on the RFC.
> 1. The RFC seems to assume or imply that PHP programmers have extensive
> C++ experience. IMHO it is not true f
On Mon Aug 25 06:28 PM, steve wrote:
Has anyone had success compiling PHP with LLVM?
I haven't tried it, here is a good summary:
http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf
In short, it is 'slower' but that seems to be without any caching of the
"bytecode"
So yes, we were abl
Hi!
I am sorry but I absolutely fail to see how the following is in any way
whatsoever unclear:
This is clear, I understand that and think it is completely wrong and
misguided, for reasons I described in my last email. What I did not
understand is what code you wanted to allow outside namesp
Hi!
My guess is that it allows for development with heavy __autload usage and
then doing deployment based on static analysis where each target page
results in one large php file generated from that analysis. So there won't
be any overhead and each script target would be a single target of its ow
I've been debugging a case where a PHP installation doesn't have
DOMDocument->loadHTML, but phpinfo reports that HTML is enabled (the
normal reason why loadHTML would not be available) and that the API
version of 20031129. Is there any other way to check for the
compile-time constant LIBXML_HTML_EN
On 02.09.2008 21:40, Edward Z. Yang wrote:
I've been debugging a case where a PHP installation doesn't have
DOMDocument->loadHTML, but phpinfo reports that HTML is enabled
Ugh? It's the same #ifdef.
Is there any other way to check for the
compile-time constant LIBXML_HTML_ENABLED
What do yo
Antony Dovgal wrote:
> And even if there are, I don't believe they are on our side, since it's
> the same #ifdef used in two different places, no chance to get different
> values.
Yep. I did more source diving and this should not be possible. Which
means that whoever deployed this PHP (i.e. the ho
Hi!
Wasn't it you who said it is all about simple replacement?
In current model, yes. With nesting in hierarchy, it ceases to be so,
that's exactly my point.
However, you always said we shouldn't compare PHP features to other
languages and that for that reason we should not worry about the
Hello!
Johannes has packed PHP 5.3.0alpha2 yesterday, which you can find here:
http://downloads.php.net/johannes/
Windows binaries (optimized for various versions of Windows) are
available from the new website dedicated to PHP's windows binaries:
http://windows.php.net/downloads.php
Please t
Hi,
On Tuesday 02 September 2008 12:15:02 Dmitry Stogov wrote:
>
> Jani Taskinen wrote:
> >>> Dmitry Stogov wrote:
> Hi,
>
> Attached is a proposed fix for http://bugs.php.net/bug.php?id=45392 for
> PHP_5_3. I don't know output buffering part very well, and I'm not
> comp
On 03.09.2008, at 00:27, Lukas Kahwe Smith wrote:
Hello!
Johannes has packed PHP 5.3.0alpha2 yesterday, which you can find
here:
http://downloads.php.net/johannes/
Windows binaries (optimized for various versions of Windows) are
available from the new website dedicated to PHP's windows b
Hi!
I forgot to reply to Stas' message yesterday, sorry... But, there is no
change in behavior here either as far as I know. For the code Stas quoted,
with static vars (if that's what was being referred to), there's definitely
not been a change (though its parser code was tweaked a bit), and t
Hi All,
Attached and uploaded [1] is a patch to add the OpenSSL random pseudo
byte function, at the moment it will return FALSE if the bytes aren't
considered cryptographically strong, I am however considering making
this parameter controlled.
Any objections to me applying this to 5.3?
S
2008/9/2 Scott MacVicar <[EMAIL PROTECTED]>:
> Hi All,
>
> Attached and uploaded [1] is a patch to add the OpenSSL random pseudo byte
> function, at the moment it will return FALSE if the bytes aren't considered
> cryptographically strong, I am however considering making this parameter
> controlled
On 3 Sep 2008, at 03:33, David Coallier wrote:
2008/9/2 Scott MacVicar <[EMAIL PROTECTED]>:
Hi All,
Attached and uploaded [1] is a patch to add the OpenSSL random
pseudo byte
function, at the moment it will return FALSE if the bytes aren't
considered
cryptographically strong, I am however
>
> This function has been in OpenSSL for 8 years and supported by every version
> since 0.9.5. It's literally just exposing the API, it's safe for inclusion
> in 5.3 in my opinion.
>
I didn't express myself very clearly. What I meant is that we should
probably add that switch for the return right
Hi all,
I'm trying to debug my extension.It says that PHP is built with debug flag,
but my not my extenison. I used --enable-debug for PHP build. But, in the
extension I wrote I can't find any configure option associated with debug in
./configure --help. I tried using the options --enable-debug an
Zitat von Lukas Kahwe Smith <[EMAIL PROTECTED]>:
Windows binaries (optimized for various versions of Windows) are
available from the new website dedicated to PHP's windows binaries:
http://windows.php.net/downloads.php
Looks like the file descriptions are wrong. The non-TS
"PHP 5.3.0alpha2 V
Mangol Smith wrote:
I'm trying to debug my extension.It says that PHP is built with debug flag,
but my not my extenison. I used --enable-debug for PHP build. But, in the
extension I wrote I can't find any configure option associated with debug in
./configure --help. I tried using the options --en
27 matches
Mail list logo
