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
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
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
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
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,
Attached is a
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
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 behavior of output buffering a
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
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
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
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
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
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
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
completely sure about this fix, so
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
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?
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.
Any
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 now
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
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 VC9
21 matches
Mail list logo
