Re: [PHP-DEV] New optimization idea; was: No runtime fetching of built-in global constants
Hi Matt,
It would be nice if scanner check for "#!" at start of file and skip the
whole first line if found. Nothing else.
Of curse it won't save syscall itself.
Now shebang line is checked (in CGI SAPI code) before call to compiler
and in case of scanner modification this code might be removed.
So with opcode caches, which override the compiler routine, this syscall
will be saved.
I'll review your constant notes/patches later today.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: "Dmitry Stogov"
Sent: Sunday, July 27, 2008
Hi Matt,
At first as you are a scanner expert, I would like you to look into
another optimization idea.
Probably for historical reason PHP supports shebang lines
(#! /usr/bin/php) on top of php files. Especially to handle them PHP
(CGI/FastCGI/CLI) opens file and check for it. So even with opcode
caches FastCGI PHP does open syscall for the requested script, however
with opcode caches it's absolutely useless.
In case PHP scanner will handle shebang lines itself, we will able to
save this syscall.
Sorry, but now I'm the one who's confused here, since I have no idea what
I'm supposed to look into exactly. :-/ I know about shebang lines, and I
know there's a check in the scanner now to skip over it (must have been
somewhere else with flex...). PHP itself doesn't "use" the shebang, does
it? I don't have much knowledge of *nix system stuff, but I thought the
shebang is for the OS to use when asked to run an executable script...
So I don't understand what could be changed in the scanner to save the open
syscall -- since if the scanner is called, the file has already been opened,
right? Again, sorry, but I'll need more explanation. :-)
I never had time and enough flex/re2c knowledge to implement this idea
myself. May be you'll able to look into the problem. In case you find a
simple solution we will able to do it in php-5.3.
Most PHP hosters and large sites use FastCGI with opcode caches (it is
also the primary way for MS Windows users), so this optimization is
really important.
[see below]
Yes, more reply below...
Matt Wilmas wrote:
Hi Dmitry,
I saw that you commited this patch, with the addition of only replacing
persistent constants (just mentioning for others on the list). The
attached
patches have a few tweaks:
The main thing I noticed is that if "something" creates a persistent,
case-INsensitive constant (any of those in "standard" PHP, besides
TRUE/FALSE/NULL?), it could still wrongly be substituted. My change
eliminates that possibility.
After yesterday's subbotnik I'm so stupid so cannot understand simple
tings. :)
Could you point me into the exact part of the patch.
Sure, I'll explain more. If something (extension, etc...) creates a
persistent constant "foo" and it does NOT have the CONST_CS flag, and
capital "FOO" or whatever is used in a script (and a case-sensitive version
doesn't exist, of course), it will be lowercased, as you know, and "foo"
will be found, but that can't be used since a case-sensitive version may be
defined later (TRUE/FALSE/NULL are exceptions, but OK to do since they have
CONST_CT_SUBST). Current zend_get_ct_const() behavior after finding
case-insensitive "foo":
if ((c->flags & CONST_CS) && ...) {
efree(lookup_name);
return NULL; /* Doesn't fail for "foo" since CONST_CS isn't
set... */
.
if (c->flags & CONST_CT_SUBST) {
return c; /* This doesn't happen since CONST_CT_SUBST isn't set... */
}
if ((c->flags & CONST_PERSISTENT) &&
...) {
return c; /* This DOES happen since CONST_PERSISTENT is set */
}
The last part is the problem, of course. Substitution should only be done
for ones that have:
CONST_CT_SUBST
or
CONST_PERSISTENT and whose case matches that used in the script (CONST_CS or
lowercase is used, e.g. "foo" in script is OK, not "FOO" or "Foo")
(BTW, that also implies that CT_SUBST is only useful for case-insensitive
constants (like T/F/N) and if something sets it with (CS | PERSISTENT), it
doesn't really do anything -- except not allow it to be used in "const ..."
declarations. :-P Though that could be desired, by something, and/or to
also have substitution even in a namespace.)
With my change, after finding case-insensitive "foo":
if ((c->flags & CONST_CT_SUBST) && !(c->flags & CONST_CS)) {
efree(lookup_name);
return c; /* Happens for TRUE/FALSE/NULL */
}
}
efree(lookup_name);
return NULL; /* Happens for "foo" before persistent check */
Hope that wasn't TOO verbose. :-O I just swapped the logic (succeed vs
fail) of that top part so the else { } block could be removed.
Checking Z_TYPE(c->value) != IS_CONSTANT[_ARRAY] isn't needed with the
persistent check now, is it?
I think you are right, but it's better to have this checks, because
nobody prohibit to create array constants in extensions.
OK. :-)
From orginal patch (zend_constants.c part), the memcmp(
[PHP-DEV] Re: New optimization idea; was: No runtime fetching of built-in global constants
Hi! Probably for historical reason PHP supports shebang lines (#! /usr/bin/php) on top of php files. Especially to handle them PHP (CGI/FastCGI/CLI) opens file and check for it. So even with opcode caches FastCGI PHP does open syscall for the requested script, however with opcode caches it's absolutely useless. In case PHP scanner will handle shebang lines itself, we will able to save this syscall. But for most cases you'd just do cgi.check_shebang_line=0 in php.ini and that should solve the problem, not? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New optimization idea; was: No runtime fetching of built-in global constants
I'm not Matt, but I'll try to answer :) Actually the new re2c scanner already handles the shebang thing, so I think you can safely remove the explicit support for it in CGI. We had to had that because CLI doesn't explicitly support the shebang line. Nuno P.S.: now it makes sense why we never found the code in the flex scanner that handled the shebang line :P On Sun, Jul 27, 2008 at 11:56, Dmitry Stogov <[EMAIL PROTECTED]> wrote: > Hi Matt, > > At first as you are a scanner expert, I would like you to look into another > optimization idea. > > Probably for historical reason PHP supports shebang lines > (#! /usr/bin/php) on top of php files. Especially to handle them PHP > (CGI/FastCGI/CLI) opens file and check for it. So even with opcode caches > FastCGI PHP does open syscall for the requested script, however with opcode > caches it's absolutely useless. > > In case PHP scanner will handle shebang lines itself, we will able to save > this syscall. > > I never had time and enough flex/re2c knowledge to implement this idea > myself. May be you'll able to look into the problem. In case you find a > simple solution we will able to do it in php-5.3. > > Most PHP hosters and large sites use FastCGI with opcode caches (it is also > the primary way for MS Windows users), so this optimization is really > important. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/ming config.m4 ming.c
Hello Frank,
can you please sync HEAD which seems completely outdated beside that it
has const designatures which are somehow missing in 5.3. Anyway, this
commit makes ming at least compile with the latest available version
0.4rc1. Eitherway, if 0.4 is not coming out during alpha1 and no support
for 0.3 is available I fear we have to move ming to PECL.
marcus
Sunday, July 27, 2008, 11:32:48 PM, you wrote:
> helly Sun Jul 27 21:32:48 2008 UTC
> Modified files: (Branch: PHP_5_3)
> /php-src/ext/ming config.m4 ming.c
> Log:
> - Allow building with ming-0.4rc1 (the latest available ming)
> # Necessary to get gcov.php.net working again
>
>
> http://cvs.php.net/viewvc.cgi/php-src/ext/ming/config.m4?r1=1.22.2.6.2.4&r2=1.22.2.6.2.4.2.1&diff_format=u
> Index: php-src/ext/ming/config.m4
> diff -u php-src/ext/ming/config.m4:1.22.2.6.2.4
> php-src/ext/ming/config.m4:1.22.2.6.2.4.2.1
> --- php-src/ext/ming/config.m4:1.22.2.6.2.4 Tue Mar 6 10:13:40 2007
> +++ php-src/ext/ming/config.m4 Sun Jul 27 21:32:48 2008
> @@ -1,5 +1,5 @@
> dnl
> -dnl $Id: config.m4,v 1.22.2.6.2.4 2007/03/06 10:13:40 tony2001 Exp $
> +dnl $Id: config.m4,v 1.22.2.6.2.4.2.1 2008/07/27 21:32:48 helly Exp $
> dnl
>
> PHP_ARG_WITH(ming, for MING support,
> @@ -40,9 +40,12 @@
>PHP_ADD_INCLUDE($MING_INC_DIR)
>PHP_ADD_LIBRARY_WITH_PATH(ming, $MING_DIR/$PHP_LIBDIR, MING_SHARED_LIBADD)
>
> - PHP_CHECK_LIBRARY(ming, SWFPrebuiltClip, [
> AC_DEFINE(HAVE_SWFPREBUILTCLIP, 1, [ ]) ], [], [])
> - PHP_CHECK_LIBRARY(ming, SWFMovie_namedAnchor, [
> AC_DEFINE(HAVE_SWFMOVIE_NAMEDANCHOR, 1, [ ]) ], [], [])
> - PHP_CHECK_LIBRARY(ming, Ming_setSWFCompression, [
> AC_DEFINE(HAVE_MING_SETSWFCOMPRESSION, 1, [ ]) ], [], [])
> + PHP_CHECK_LIBRARY(ming, SWFPrebuiltClip, [
> AC_DEFINE(HAVE_SWFPREBUILTCLIP, 1, [ ]) ], [], [])
> + PHP_CHECK_LIBRARY(ming, SWFMovie_namedAnchor,[
> AC_DEFINE(HAVE_SWFMOVIE_NAMEDANCHOR,1, [ ]) ], [], [])
> + PHP_CHECK_LIBRARY(ming, Ming_setSWFCompression, [
> AC_DEFINE(HAVE_MING_SETSWFCOMPRESSION, 1, [ ]) ], [], [])
> + PHP_CHECK_LIBRARY(ming, SWFVideoStream_seek, [
> AC_DEFINE(HAVE_SWFVIDEOSTREAM_SEEK, 1, [ ]) ], [], [])
> + PHP_CHECK_LIBRARY(ming, SWFVideoStream_setFrameMode, [
> AC_DEFINE(HAVE_SWFVIDEOSTREAM_SETFRAMEMODE, 1, [ ]) ], [], [])
> + PHP_CHECK_LIBRARY(ming, SWFVideoStream_nextFrame,[
> AC_DEFINE(HAVE_SWFVIDEOSTREAM_NEXTFRAME,1, [ ]) ], [], [])
>
>old_CPPFLAGS=$CPPFLAGS
>CPPFLAGS=-I$MING_INC_DIR
> http://cvs.php.net/viewvc.cgi/php-src/ext/ming/ming.c?r1=1.79.2.4.2.8.2.8&r2=1.79.2.4.2.8.2.9&diff_format=u
> Index: php-src/ext/ming/ming.c
> diff -u php-src/ext/ming/ming.c:1.79.2.4.2.8.2.8
> php-src/ext/ming/ming.c:1.79.2.4.2.8.2.9
> --- php-src/ext/ming/ming.c:1.79.2.4.2.8.2.8Thu Jul 24 18:39:41 2008
> +++ php-src/ext/ming/ming.c Sun Jul 27 21:32:48 2008
> @@ -19,7 +19,7 @@
>+--+
> */
>
> -/* $Id: ming.c,v 1.79.2.4.2.8.2.8 2008/07/24 18:39:41 fmk Exp $ */
> +/* $Id: ming.c,v 1.79.2.4.2.8.2.9 2008/07/27 21:32:48 helly Exp $ */
>
> #ifdef HAVE_CONFIG_H
> #include "config.h"
> @@ -3521,6 +3521,7 @@
> }
> /* }}} */
>
> +#if HAVE_SWFVIDEOSTREAM_NEXTFRAME
> /* {{{ proto swfvideostream::nextFrame */
> PHP_METHOD(swfvideostream, nextFrame)
> {
> @@ -3531,7 +3532,9 @@
> RETURN_LONG(SWFVideoStream_nextFrame(getVideoStream(getThis()
> TSRMLS_CC)));
> }
> /* }}} */
> -
> +#endif
> +
> +#if HAVE_SWFVIDEOSTREAM_SETFRAMEMODE
> /* {{{ proto swfvideostream::setFrameMode */
> PHP_METHOD(swfvideostream, setFrameMode)
> {
> @@ -3547,7 +3550,9 @@
> RETURN_LONG(SWFVideoStream_setFrameMode(stream, mode));
> }
> /* }}} */
> +#endif
>
> +#if HAVE_SWFVIDEOSTREAM_SEEK
> /* {{{ proto swfvideostream::seek(frame, whence) */
> PHP_METHOD(swfvideostream, seek)
> {
> @@ -3563,16 +3568,22 @@
> RETURN_LONG(SWFVideoStream_seek(stream, frame, whence));
> }
> /* }}} */
> -
> -
> +#endif
> +
> static zend_function_entry swfvideostream_functions[] = {
> PHP_ME(swfvideostream, __construct,NULL, 0)
> PHP_ME(swfvideostream, setdimension, NULL, 0)
> PHP_ME(swfvideostream, getnumframes, NULL, 0)
> PHP_ME(swfvideostream, hasaudio, NULL, 0)
> +#if HAVE_SWFVIDEOSTREAM_SETFRAMEMODE
> PHP_ME(swfvideostream, setFrameMode, NULL, 0)
> +#endif
> +#if HAVE_SWFVIDEOSTREAM_NEXTFRAME
> PHP_ME(swfvideostream, nextFrame, NULL, 0)
> +#endif
> +#if HAVE_SWFVIDEOSTREAM_SEEK
> PHP_ME(swfvideostream, seek, NULL, 0)
> +#endif
> { NULL, NULL, NULL }
> };
>
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Update (XDebug project)
Please be careful when using ExtJS - it has a GPL or proprietary only licence. - RooJS should be a plugin replacement for it. see: http://www.roojs.com/trac/ Regards Alan Chung-Yang(Kenneth) Lee wrote: I am Chung-Yang (Kenneth) Lee, a current master student in Indiana University Bloomington under the information science major. For GSoC, I work on the XDebug project, which is to create a web front-end to deal with the profiler's output from XDebug. The main goal is to create a web-based application that make the output more readable and helpful to developers. [ Project Details ] The goal of this project is to build an interface that can visualize the cachegrind / callgrind output from XDebug, which is a pure text file containing information about function relationships within the code. To achieve this goal, I selected EXT JS grid as the back-end supported library. The system flow is users will first decide either to upload a file to be parsed or choose a file from an assigned directory. After the file is uploaded / chosen, the system will extract and calculate required information from the file and format it into a JSON object. The grid will then read in the JSON object and present the information to the front-end. Users can perform functions like sorting, filtering, ungrouping, moving columns around, etc. on the grid. [ Main Functionality ] - File upload - Cachegrind output parsing - Track Function calls - Track Function calls execution time - Function call tree and track time/percent taken for the whole tree processing and - Percent and Time format output filtering - List callers - List callees - Graph tree structure [ Progress ] Most of the functionalities were done. Users can now upload a file to get parsed and visualized from the interface. After the file is parsed, the interface will display information like function names, total self cost in ms and by percentage, invocation count. The information is displayed in a grid after the file is parsed and users can perform sorting, grouping / ungrouping, and moving columns on the grid as for now. Currently, I am working on the information filtering function that users can specify what information they need, for example, filtering out php internal functions, searching time consumed by a function that is greater / less than a specified number, etc. Making the file uploading process more manageable and making the whole application more configurable are two main tasks after the filtering function is done. Thanks, Kenneth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards 5.3 alpha1
Hello,
On 2008-07-26, at 14:21, Arnaud Le Blanc wrote:
On Saturday 26 July 2008 13:57:45 Lukas Kahwe Smith wrote:
On 26.07.2008, at 13:02, Johannes Schlüter wrote:
Again a general request to the developer and user community at
large:
Please concentrate on finding&fixing bugs instead of functional
changes
(including arginfo and parameter_parsing) and to make sure we
have all
changes covered in the wiki [2] so they can be added to release
notes
and the documentation.
Speaking of which, just going through the open 5.3 bugs that have not
been assigned to a developer I see the following ones as looking
to be
important to be dealt with:
http://bugs.php.net/bug.php?id=45044 (relative paths not resolved
correctly)
http://bugs.php.net/bug.php?id=43695 (Asynchronous socket connection
timing issue)
http://bugs.php.net/bug.php?id=45384 (parse_ini_file will result in
parse error with no trailing newline)
http://bugs.php.net/bug.php?id=45392 (ob_start()/ob_end_clean() and
memory_limit)
I have just taken a look at this bug, and the problems seems to be in
php_request_shutdown function from main/main.c. It just executes
buffers flush no matter what outcome of the script was (I mean error/
success) (somewhere around line 1495):
zend_try {
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1)
TSRMLS_CC);
} zend_end_try();
It can be avoided by adding if-stmt checking if there was an error:
if (!PG(last_error_message) || !(PG(last_error_type) & E_ERROR)) {
zend_try {
php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1)
TSRMLS_CC);
} zend_end_try();
}
I am not sure if it is the right solution, or if it does not
introduce any other problems I am not aware of (I have done "make
test" and haven;t noticed anything strange.)
Cheers
Michal
http://bugs.php.net/bug.php?id=44842 (parse_ini_file keys that start/
end with underscore)
http://bugs.php.net/bug.php?id=45288 (set_include_path()
functionality
broken)
http://bugs.php.net/bug.php?id=45608 (closures don't work in static
methods)
The rest are either assigned or PDO bugs (again, we really really
really need someone that looks after PDO).
Of course there are also still tons of open 5.2 bugs [1] :(
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
[1]
http://bugs.php.net/search.php?
cmd=display&status=Open&search_for=&php_os=&boolean=1&author_email=&bu
g_age=0&by=&order_by=id&direction=ASC&phpver=5.2&limit=30&assign=&begi
n=0
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
For "closures don't work in static methods" (45608), this is
because a closure
declared in a static method will always be called statically.
The example given in the report works if the closure is explicitly
declared as
static, but as shown by the bug report it may be better to
implicitly inherit
the ACC_STATIC flag of the declaring method. It seems that
Christian planed
to add this to his patch but it has never be included.
This could be as simple as this:
http://arnaud.lb.s3.amazonaws.com/closure_static.patch
For "relative paths not resolved correctly" (45044) I added a
comment on the
report about the cause of the bug, but I don't know what is the
better way to
fix that.
Regards,
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Optimizer Update
Great work, I've been periodically reviewing the commits and you're making excellent progress in terms of making the optimizer a general use tool. One thing I would suggest is creation of a "known issues" list, which can act as both a todo list and a warning list for people intending to use the optimizer. On 25-Jul-08, at 8:59 PM, Graham Kelly wrote: Hi, My Google Summer of Code project is to develop and release an initial version on the optimizer originally being developed by Ilia. The optimizer will be released to PECL as its own extension, however, it will require APC in order to run. Ive worked on cleaning up bugs and testing the existing code. In addition I have worked on refactoring some of the code to provide a base on which to build a more powerful and more robust optimizer. I have added a few additional optimizations including: 1) Optimization of basic math identities 2) Optimization of silence blocks 3) More functions for which we can pre-calculate return values for if they have all static parameters. (substr, acos, acosh, asin, asinh, atan, atanh, cos, cosh, sin, sinh, tan, tanh, exp, log10, sqrt, atan2, ceil, floor, fmod, ini_get [for PHP_INI_SYSTEM values only], ip2long, long2ip, trim, chop, rtrim, ltrim, rad2deg, deg2rad, abs) 4) worked on making function optimization more aggressive to reduce the number of required passes for full optimization. 5) A few more minor things here and there There are plans to change the optimizer hook in APC over to adding a new compile layer. This should help give the optimizer better control as well as make it more easily integrateable with other extensions. In the future I would like to work on a new control system and new analysis tools for the optimizer. Hopefully such eventual changes will open up the way for more powerful optimizations down the road. In addition there are some APC specific optimizations that might be able to be done. Hopefully the initial release of the optimizer will in available in PECL in the next few weeks. For now you can get it from pecl/optimizer in CVS. ~ Graham Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Update (XDebug project)
On Sun, 27 Jul 2008, David Coallier wrote: > > > > This sounds cool. Can we try it somewhere? > > > > I'll setup a host in a few days when I get back from vacation :) Isn't the source available through my CVS? If that's up to do date, it can be checked out with: cvs -d :pserver:[EMAIL PROTECTED]:/repository co xdebug-web You need to login first, and the password is "srmread". regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Update (XDebug project)
> > This sounds cool. Can we try it somewhere? > I'll setup a host in a few days when I get back from vacation :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_execute.c zend_vm_def.h zend_vm_execute.h
Hello Lukas, Sunday, July 27, 2008, 12:00:55 PM, you wrote: > On 27.07.2008, at 02:58, Marcus Boerger wrote: >> Hello Internals, >> >> apparently overloaded objects do not need to implement property >> access >> and we issue an E_NOTICE in case someone tries to none-the-less. >> Dmirty >> thankfully made this consistent for all handlers now. However this >> raised a >> question on my side, whether we should increase the severity to >> E_WARNING >> or even better E_RECOVERABLE_ERROR. To me the latter choice makes >> the most >> sense as trying to is most likely a severe issue in the software. For >> example someone create a database abstraction and then for a new db >> that >> has a C level implementation that allows to use the classes directly, >> probably a third party implementation, the properties are not >> implemneted. >> Since the tests were done using the other one errors due to property >> handling are probably noticed too late. And in the described situation >> anyway are clear errors rather than notices. And I cannot figure an >> example >> where it wouldn't be the case. > You know I am generally wary of using error levels that are higher > than necessary just to beat people with a stick that they are coding > themselves into a corner. This is what we have E_STRICT for and people > that want to do the right thing can use an error handler to make sure > they change their code to do the right thing. E_STRICT is for you can but you shouldn't. Here we speak about something that cannot be done. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Update (XDebug project)
Chung-Yang(Kenneth) Lee wrote: Most of the functionalities were done. Users can now upload a file to get parsed and visualized from the interface. After the file is parsed, the interface will display information like function names, total self cost in ms and by percentage, invocation count. The information is displayed in a grid after the file is parsed and users can perform sorting, grouping / ungrouping, and moving columns on the grid as for now. This sounds cool. Can we try it somewhere? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4
Sebastian Nohn kirjoitti: David Soria Parra wrote: -dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], [undefine([AC_PROG_CXX]) -AC_DEFUN([AC_PROG_CXX], [])]) +dnl Only allow AC_PROG_CXX and AC_PROG_CXXCPP if they are explicitly called (by PHP_REQUIRE_CXX). +dnl Otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler. +AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [], [ + undefine([AC_PROG_CXX]) + AC_DEFUN([AC_PROG_CXX], []) + undefine([AC_PROG_CXXCPP]) + AC_DEFUN([AC_PROG_CXXCPP], []) +]) AC_PROG_LIBTOOL This causes a syntax error in configure after doing a buildconf. I can reproduce that (5_2, no local modifications). Fixeth in all branches. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Replacement to ticks for signals
On Sunday 27 July 2008 16:04:58 Derick Rethans wrote:
> On Sun, 27 Jul 2008, Arnaud Le Blanc wrote:
>
> > Hi,
> >
> > I made a pcntl_signal_dispatch() function [1] to allow scripts that use
> > signals to work without ticks.
> >
> > This function just calls the pcntl's tick handler on-demand so that all
signal
> > handler functions are called if there are pending signals.
> >
> > It does not allow the signal handlers to be called at any time like with
> > ticks, but allows things like this:
> >
> > while (do_something()) {
> > /* main loop */
> > pcntl_signal_dispatch();
> > }
> >
> > or
> >
> > while (pcntl_signal_dispatch() && do_something()) {
> > /* main loop */
> > }
>
> Does the function block if there are no pending signals? If not, I think
> we should make that an option.
>
No, but I was thinking to implement sigwaitinfo()/sigtimedwait(), which blocks
indefinitly or for a given time until a signal is delivered. This also
requires to implement sigprocmask().
It would also be great to have signalfd() (which is select()able), but it's
Linux specific and requires quite recent Kernel and libc (that said, I'm
going to implement it if there are positive feedbacks about that).
Regards,
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4
David Soria Parra wrote: > >> -dnl Only allow AC_PROG_CXX if it's explicitly called (by >> PHP_REQUIRE_CXX) >> -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler >> -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], >> [undefine([AC_PROG_CXX]) >> -AC_DEFUN([AC_PROG_CXX], [])]) >> +dnl Only allow AC_PROG_CXX and AC_PROG_CXXCPP if they are explicitly >> called (by PHP_REQUIRE_CXX). >> +dnl Otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler. >> +AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [], [ >> + undefine([AC_PROG_CXX]) >> + AC_DEFUN([AC_PROG_CXX], []) >> + undefine([AC_PROG_CXXCPP]) >> + AC_DEFUN([AC_PROG_CXXCPP], []) >> +]) >> AC_PROG_LIBTOOL > > This causes a syntax error in configure after doing a buildconf. I can reproduce that (5_2, no local modifications). - Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New optimization idea; was: No runtime fetching of built-in global constants
Hi, On Sunday 27 July 2008 15:35:11 Matt Wilmas wrote: > > Sorry, but now I'm the one who's confused here, since I have no idea what > I'm supposed to look into exactly. :-/ I know about shebang lines, and I > know there's a check in the scanner now to skip over it (must have been > somewhere else with flex...). PHP itself doesn't "use" the shebang, does > it? I don't have much knowledge of *nix system stuff, but I thought the > shebang is for the OS to use when asked to run an executable script... The shebang line is used by the operating system to know which interpreter to use to execute the file. In most cases this does not cause any problem to the interpretor as lines starting with # are comments in many languages, but in PHP it's not a comment as long as it's not enclosed with , so PHP must check if there is a shebang line and skip it. > > So I don't understand what could be changed in the scanner to save the open > syscall -- since if the scanner is called, the file has already been opened, > right? Again, sorry, but I'll need more explanation. :-) Actually the CGI SAPI opens the file, seeks after the shebang line, and then passes the opened file descriptor to the scanner. I see two solutions for that: Make the scanner completely bypass the shebang line if cgi.check_shebang_line==1 Or let the executor decide wether to output the shebang or not by enclosing it in a "SHEBANG" opcode for example. Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4
Em Dom, 2008-07-27 às 17:17 +0300, Jani Taskinen escreveu: > Felipe Pena kirjoitti: > > Em Dom, 2008-07-27 às 17:05 +0300, Jani Taskinen escreveu: > >> David Soria Parra kirjoitti: > -dnl Only allow AC_PROG_CXX if it's explicitly called (by > PHP_REQUIRE_CXX) > -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler > -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], > [undefine([AC_PROG_CXX]) > -AC_DEFUN([AC_PROG_CXX], [])]) > +dnl Only allow AC_PROG_CXX and AC_PROG_CXXCPP if they are explicitly > called (by PHP_REQUIRE_CXX). > +dnl Otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler. > +AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [], [ > + undefine([AC_PROG_CXX]) > + AC_DEFUN([AC_PROG_CXX], []) > + undefine([AC_PROG_CXXCPP]) > + AC_DEFUN([AC_PROG_CXXCPP], []) > +]) > AC_PROG_LIBTOOL > >>> This causes a syntax error in configure after doing a buildconf. > >> Works fine for me and Tony. Make sure you really have latest CVS without > >> any > >> local changes. :) > >> > >> Without any more information about your system I have to say: Bogus. > > > > I can reproduce with latest CVS. > > > > Configuring libtool > > checking build system type... i686-pc-linux-gnu > > checking for ld used by /home/felipe/php5_2/meta_ccld... /usr/bin/ld > > checking if the linker (/usr/bin/ld) is GNU ld... yes > > checking for /usr/bin/ld option to reload object files... -r > > checking for BSD-compatible nm... /usr/bin/nm -B > > checking how to recognise dependent libraries... pass_all > > checking for object suffix... o > > checking for executable suffix... no > > /configure: 108149: Syntax error: "fi" unexpected > > It helps a lot when you people tell what branch you tried with.. > I'm guessing this is about PHP_5_2 now? > Yeah, exactly. > --Jani -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4
Felipe Pena kirjoitti: Em Dom, 2008-07-27 às 17:05 +0300, Jani Taskinen escreveu: David Soria Parra kirjoitti: -dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], [undefine([AC_PROG_CXX]) -AC_DEFUN([AC_PROG_CXX], [])]) +dnl Only allow AC_PROG_CXX and AC_PROG_CXXCPP if they are explicitly called (by PHP_REQUIRE_CXX). +dnl Otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler. +AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [], [ + undefine([AC_PROG_CXX]) + AC_DEFUN([AC_PROG_CXX], []) + undefine([AC_PROG_CXXCPP]) + AC_DEFUN([AC_PROG_CXXCPP], []) +]) AC_PROG_LIBTOOL This causes a syntax error in configure after doing a buildconf. Works fine for me and Tony. Make sure you really have latest CVS without any local changes. :) Without any more information about your system I have to say: Bogus. I can reproduce with latest CVS. Configuring libtool checking build system type... i686-pc-linux-gnu checking for ld used by /home/felipe/php5_2/meta_ccld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... no /configure: 108149: Syntax error: "fi" unexpected It helps a lot when you people tell what branch you tried with.. I'm guessing this is about PHP_5_2 now? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4
Em Dom, 2008-07-27 às 17:05 +0300, Jani Taskinen escreveu: > David Soria Parra kirjoitti: > > > >> -dnl Only allow AC_PROG_CXX if it's explicitly called (by > >> PHP_REQUIRE_CXX) > >> -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler > >> -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], > >> [undefine([AC_PROG_CXX]) > >> -AC_DEFUN([AC_PROG_CXX], [])]) > >> +dnl Only allow AC_PROG_CXX and AC_PROG_CXXCPP if they are explicitly > >> called (by PHP_REQUIRE_CXX). > >> +dnl Otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler. > >> +AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [], [ > >> + undefine([AC_PROG_CXX]) > >> + AC_DEFUN([AC_PROG_CXX], []) > >> + undefine([AC_PROG_CXXCPP]) > >> + AC_DEFUN([AC_PROG_CXXCPP], []) > >> +]) > >> AC_PROG_LIBTOOL > > > > This causes a syntax error in configure after doing a buildconf. > > Works fine for me and Tony. Make sure you really have latest CVS without any > local changes. :) > > Without any more information about your system I have to say: Bogus. I can reproduce with latest CVS. Configuring libtool checking build system type... i686-pc-linux-gnu checking for ld used by /home/felipe/php5_2/meta_ccld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for object suffix... o checking for executable suffix... no ./configure: 108149: Syntax error: "fi" unexpected -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4
David Soria Parra kirjoitti: -dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], [undefine([AC_PROG_CXX]) -AC_DEFUN([AC_PROG_CXX], [])]) +dnl Only allow AC_PROG_CXX and AC_PROG_CXXCPP if they are explicitly called (by PHP_REQUIRE_CXX). +dnl Otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler. +AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [], [ + undefine([AC_PROG_CXX]) + AC_DEFUN([AC_PROG_CXX], []) + undefine([AC_PROG_CXXCPP]) + AC_DEFUN([AC_PROG_CXXCPP], []) +]) AC_PROG_LIBTOOL This causes a syntax error in configure after doing a buildconf. Works fine for me and Tony. Make sure you really have latest CVS without any local changes. :) Without any more information about your system I have to say: Bogus. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Replacement to ticks for signals
On Sun, 27 Jul 2008, Arnaud Le Blanc wrote:
> Hi,
>
> I made a pcntl_signal_dispatch() function [1] to allow scripts that use
> signals to work without ticks.
>
> This function just calls the pcntl's tick handler on-demand so that all
> signal
> handler functions are called if there are pending signals.
>
> It does not allow the signal handlers to be called at any time like with
> ticks, but allows things like this:
>
> while (do_something()) {
> /* main loop */
> pcntl_signal_dispatch();
> }
>
> or
>
> while (pcntl_signal_dispatch() && do_something()) {
> /* main loop */
> }
Does the function block if there are no pending signals? If not, I think
we should make that an option.
regards,
Derick
--
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Replacement to ticks for signals
Hi,
I made a pcntl_signal_dispatch() function [1] to allow scripts that use
signals to work without ticks.
This function just calls the pcntl's tick handler on-demand so that all signal
handler functions are called if there are pending signals.
It does not allow the signal handlers to be called at any time like with
ticks, but allows things like this:
while (do_something()) {
/* main loop */
pcntl_signal_dispatch();
}
or
while (pcntl_signal_dispatch() && do_something()) {
/* main loop */
}
Can I commit this ?
[1] http://arnaud.lb.s3.amazonaws.com/pcntl_signal_dispatch.patch
Regards,
Arnaud
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New optimization idea; was: No runtime fetching of built-in global constants
Hi Dmitry,
- Original Message -
From: "Dmitry Stogov"
Sent: Sunday, July 27, 2008
> Hi Matt,
>
> At first as you are a scanner expert, I would like you to look into
> another optimization idea.
>
> Probably for historical reason PHP supports shebang lines
> (#! /usr/bin/php) on top of php files. Especially to handle them PHP
> (CGI/FastCGI/CLI) opens file and check for it. So even with opcode
> caches FastCGI PHP does open syscall for the requested script, however
> with opcode caches it's absolutely useless.
>
> In case PHP scanner will handle shebang lines itself, we will able to
> save this syscall.
Sorry, but now I'm the one who's confused here, since I have no idea what
I'm supposed to look into exactly. :-/ I know about shebang lines, and I
know there's a check in the scanner now to skip over it (must have been
somewhere else with flex...). PHP itself doesn't "use" the shebang, does
it? I don't have much knowledge of *nix system stuff, but I thought the
shebang is for the OS to use when asked to run an executable script...
So I don't understand what could be changed in the scanner to save the open
syscall -- since if the scanner is called, the file has already been opened,
right? Again, sorry, but I'll need more explanation. :-)
> I never had time and enough flex/re2c knowledge to implement this idea
> myself. May be you'll able to look into the problem. In case you find a
> simple solution we will able to do it in php-5.3.
>
> Most PHP hosters and large sites use FastCGI with opcode caches (it is
> also the primary way for MS Windows users), so this optimization is
> really important.
>
> [see below]
Yes, more reply below...
> Matt Wilmas wrote:
> > Hi Dmitry,
> >
> > I saw that you commited this patch, with the addition of only replacing
> > persistent constants (just mentioning for others on the list). The
attached
> > patches have a few tweaks:
> >
> > The main thing I noticed is that if "something" creates a persistent,
> > case-INsensitive constant (any of those in "standard" PHP, besides
> > TRUE/FALSE/NULL?), it could still wrongly be substituted. My change
> > eliminates that possibility.
>
> After yesterday's subbotnik I'm so stupid so cannot understand simple
> tings. :)
> Could you point me into the exact part of the patch.
Sure, I'll explain more. If something (extension, etc...) creates a
persistent constant "foo" and it does NOT have the CONST_CS flag, and
capital "FOO" or whatever is used in a script (and a case-sensitive version
doesn't exist, of course), it will be lowercased, as you know, and "foo"
will be found, but that can't be used since a case-sensitive version may be
defined later (TRUE/FALSE/NULL are exceptions, but OK to do since they have
CONST_CT_SUBST). Current zend_get_ct_const() behavior after finding
case-insensitive "foo":
if ((c->flags & CONST_CS) && ...) {
efree(lookup_name);
return NULL; /* Doesn't fail for "foo" since CONST_CS isn't
set... */
.
if (c->flags & CONST_CT_SUBST) {
return c; /* This doesn't happen since CONST_CT_SUBST isn't set... */
}
if ((c->flags & CONST_PERSISTENT) &&
...) {
return c; /* This DOES happen since CONST_PERSISTENT is set */
}
The last part is the problem, of course. Substitution should only be done
for ones that have:
CONST_CT_SUBST
or
CONST_PERSISTENT and whose case matches that used in the script (CONST_CS or
lowercase is used, e.g. "foo" in script is OK, not "FOO" or "Foo")
(BTW, that also implies that CT_SUBST is only useful for case-insensitive
constants (like T/F/N) and if something sets it with (CS | PERSISTENT), it
doesn't really do anything -- except not allow it to be used in "const ..."
declarations. :-P Though that could be desired, by something, and/or to
also have substitution even in a namespace.)
With my change, after finding case-insensitive "foo":
if ((c->flags & CONST_CT_SUBST) && !(c->flags & CONST_CS)) {
efree(lookup_name);
return c; /* Happens for TRUE/FALSE/NULL */
}
}
efree(lookup_name);
return NULL; /* Happens for "foo" before persistent check */
Hope that wasn't TOO verbose. :-O I just swapped the logic (succeed vs
fail) of that top part so the else { } block could be removed.
> > Checking Z_TYPE(c->value) != IS_CONSTANT[_ARRAY] isn't needed with the
> > persistent check now, is it?
>
> I think you are right, but it's better to have this checks, because
> nobody prohibit to create array constants in extensions.
OK. :-)
> > From orginal patch (zend_constants.c part), the memcmp(...) != 0 isn't
> > needed as it will always be true. If it wasn't, the *first* hash lookup
> > wouldn't have failed. :-) Like I said in the original message, it's old
> > code from a long time ago, but was never removed...
>
> I'll check it with more clear head.
I looked through the CVS logs/versions for zend_constants.c again, and the
memcmp() was needed before v1.40 (6 years ago). Tha
[PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4
-dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], [undefine([AC_PROG_CXX]) -AC_DEFUN([AC_PROG_CXX], [])]) +dnl Only allow AC_PROG_CXX and AC_PROG_CXXCPP if they are explicitly called (by PHP_REQUIRE_CXX). +dnl Otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler. +AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [], [ + undefine([AC_PROG_CXX]) + AC_DEFUN([AC_PROG_CXX], []) + undefine([AC_PROG_CXXCPP]) + AC_DEFUN([AC_PROG_CXXCPP], []) +]) AC_PROG_LIBTOOL This causes a syntax error in configure after doing a buildconf. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap ctor errors
On 27.07.2008, at 15:07, Knut Urdalen wrote: Hi David, That would be great! Currently I need to call the WSDL-file two times to be able to handle the exception. Resolution of this issue is scheduled for alpha2 (around mid to end of August). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap ctor errors
Hi David,
That would be great! Currently I need to call the WSDL-file two times to
be able to handle the exception.
Knut
David Zülke wrote:
I know this is horribly old, but I just stumbled across the same issue
again and realized it has not been tackled yet.
Shouldn't we fix that for 5.3?
David
Am 08.01.2007 um 14:51 schrieb Knut Urdalen:
I agree with Lukas here, currently you have to be proactive against
the location of the WSDL-file. I currently do like this in my
SoapClient's:
class MySoapClient extends SoapClient {
public function __construct($wsdl ,$options = array()) {
if(is_resource(@fopen($wsdl, 'r'))) {
parent::__construct($wsdl, $options);
} else {
throw new Exception("Parsing WSDL: Couldn't load from '$wsdl'");
}
}
}
to be able to catch that problem as an Exception.
Regards,
Knut Urdalen
Lukas Kahwe Smith wrote:
Hi,
why do I get warnings when I have failures in my ext/soap ctor?
try {
$client = new SoapClient('http://i_dont_exist.com/some.wsdl',
array('exceptions' => true));
} catch (Exception $e) { }
I guess even without the 'exceptions' => true it should always
return all issues as an exception. I think this was agreed upon for
constructor errors in PHP5, no?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New optimization idea; was: No runtime fetching of built-in global constants
Hi Matt,
At first as you are a scanner expert, I would like you to look into
another optimization idea.
Probably for historical reason PHP supports shebang lines
(#! /usr/bin/php) on top of php files. Especially to handle them PHP
(CGI/FastCGI/CLI) opens file and check for it. So even with opcode
caches FastCGI PHP does open syscall for the requested script, however
with opcode caches it's absolutely useless.
In case PHP scanner will handle shebang lines itself, we will able to
save this syscall.
I never had time and enough flex/re2c knowledge to implement this idea
myself. May be you'll able to look into the problem. In case you find a
simple solution we will able to do it in php-5.3.
Most PHP hosters and large sites use FastCGI with opcode caches (it is
also the primary way for MS Windows users), so this optimization is
really important.
[see below]
Matt Wilmas wrote:
Hi Dmitry,
I saw that you commited this patch, with the addition of only replacing
persistent constants (just mentioning for others on the list). The attached
patches have a few tweaks:
The main thing I noticed is that if "something" creates a persistent,
case-INsensitive constant (any of those in "standard" PHP, besides
TRUE/FALSE/NULL?), it could still wrongly be substituted. My change
eliminates that possibility.
After yesterday's subbotnik I'm so stupid so cannot understand simple
tings. :)
Could you point me into the exact part of the patch.
Checking Z_TYPE(c->value) != IS_CONSTANT[_ARRAY] isn't needed with the
persistent check now, is it?
I think you are right, but it's better to have this checks, because
nobody prohibit to create array constants in extensions.
From orginal patch (zend_constants.c part), the memcmp(...) != 0 isn't
needed as it will always be true. If it wasn't, the *first* hash lookup
wouldn't have failed. :-) Like I said in the original message, it's old
code from a long time ago, but was never removed...
I'll check it with more clear head.
Thanks. Dmitry.
- Matt
- Original Message -
From: "Dmitry Stogov"
Sent: Thursday, July 24, 2008
I would propose the attached patch for this optimization.
Opcode caches and encoders will have to disable this optimization with
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION
Any objections?
Thanks. Dmitry.
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.74
diff -u -p -d -r1.647.2.27.2.41.2.74 zend_compile.c
--- Zend/zend_compile.c 24 Jul 2008 11:47:49 - 1.647.2.27.2.41.2.74
+++ Zend/zend_compile.c 24 Jul 2008 14:40:12 -
@@ -3804,6 +3804,12 @@ static zend_constant* zend_get_ct_const(
if (c->flags & CONST_CT_SUBST) {
return c;
}
+ if (!CG(current_namespace) &&
+ !(CG(compiler_options) & ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION) &&
+ Z_TYPE(c->value) != IS_CONSTANT &&
+ Z_TYPE(c->value) != IS_CONSTANT_ARRAY) {
+ return c;
+ }
return NULL;
}
/* }}} */
@@ -5169,12 +5175,14 @@ void zend_do_use(znode *ns_name, znode *
void zend_do_declare_constant(znode *name, znode *value TSRMLS_DC) /*
{{{ */
{
zend_op *opline;
+ zend_constant *c;
if(Z_TYPE(value->u.constant) == IS_CONSTANT_ARRAY) {
zend_error(E_COMPILE_ERROR, "Arrays are not allowed as constants");
}
- if (zend_get_ct_const(&name->u.constant TSRMLS_CC)) {
+ c = zend_get_ct_const(&name->u.constant TSRMLS_CC);
+ if (c && (c->flags & CONST_CT_SUBST)) {
zend_error(E_COMPILE_ERROR, "Cannot redeclare constant '%s'",
Z_STRVAL(name->u.constant));
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.12.2.27
diff -u -p -d -r1.316.2.8.2.12.2.27 zend_compile.h
--- Zend/zend_compile.h 24 Jul 2008 11:47:49 - 1.316.2.8.2.12.2.27
+++ Zend/zend_compile.h 24 Jul 2008 14:40:13 -
@@ -762,6 +762,9 @@ END_EXTERN_C()
/* generate ZEND_DECLARE_INHERITED_CLASS_DELAYED opcode to delay early
binding */
#define ZEND_COMPILE_DELAYED_BINDING (1<<4)
+/* disable constant substitution at compile-time */
+#define ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION (1<<5)
+
/* The default value for CG(compiler_options) */
#define ZEND_COMPILE_DEFAULT ZEND_COMPILE_HANDLE_OP_ARRAY
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_execute.c zend_vm_def.h zend_vm_execute.h
On 27.07.2008, at 02:58, Marcus Boerger wrote: Hello Internals, apparently overloaded objects do not need to implement property access and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty thankfully made this consistent for all handlers now. However this raised a question on my side, whether we should increase the severity to E_WARNING or even better E_RECOVERABLE_ERROR. To me the latter choice makes the most sense as trying to is most likely a severe issue in the software. For example someone create a database abstraction and then for a new db that has a C level implementation that allows to use the classes directly, probably a third party implementation, the properties are not implemneted. Since the tests were done using the other one errors due to property handling are probably noticed too late. And in the described situation anyway are clear errors rather than notices. And I cannot figure an example where it wouldn't be the case. You know I am generally wary of using error levels that are higher than necessary just to beat people with a stick that they are coding themselves into a corner. This is what we have E_STRICT for and people that want to do the right thing can use an error handler to make sure they change their code to do the right thing. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_execute.c zend_vm_def.h zend_vm_execute.h
Marcus Boerger kirjoitti:
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we should increase the severity to E_WARNING
or even better E_RECOVERABLE_ERROR. To me the latter choice makes the most
sense as trying to is most likely a severe issue in the software. For
example someone create a database abstraction and then for a new db that
has a C level implementation that allows to use the classes directly,
probably a third party implementation, the properties are not implemneted.
Since the tests were done using the other one errors due to property
handling are probably noticed too late. And in the described situation
anyway are clear errors rather than notices. And I cannot figure an example
where it wouldn't be the case.
E_RECOVERABLE_ERROR sounds like the best choice.
--Jani
marcus
Saturday, July 26, 2008, 8:43:57 PM, you wrote:
Hi Marcus,
I set the same severity which was used for empty
read_property/write_property.
In case of changing they should be changed too.
I have no preference, so if you are interested in the change please
discuss it on @internals.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
can we increase the severity here? The user might think he is using a
normal object and relying on the property assignment to work. Imo it should
be an E_WARNING or even better an E_RECOVERABLE_ERROR.
marcus
Saturday, July 26, 2008, 4:08:16 PM, you wrote:
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_execute.c?r1=1.716.2.12.2.24.2.32&r2=1.716.2.12.2.24.2.33&diff_format=u
Index: ZendEngine2/zend_execute.c
diff -u ZendEngine2/zend_execute.c:1.716.2.12.2.24.2.32
ZendEngine2/zend_execute.c:1.716.2.12.2.24.2.33
--- ZendEngine2/zend_execute.c:1.716.2.12.2.24.2.32 Mon Jul 14 09:49:00 2008
+++ ZendEngine2/zend_execute.c Sat Jul 26 14:08:10 2008
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: zend_execute.c,v 1.716.2.12.2.24.2.32 2008/07/14 09:49:00 dmitry Exp $ */
+/* $Id: zend_execute.c,v 1.716.2.12.2.24.2.33 2008/07/26 14:08:10 dmitry Exp $
*/
#define ZEND_INTENSIVE_DEBUGGING 0
@@ -594,6 +594,11 @@
*retval = EG(uninitialized_zval_ptr);
PZVAL_LOCK(*retval);
}
+ if (value_op->op_type == IS_TMP_VAR) {
+ FREE_ZVAL(value);
+ } else if (value_op->op_type == IS_CONST) {
+ zval_ptr_dtor(&value);
+ }
FREE_OP(free_value);
return;
}
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_vm_def.h?r1=1.59.2.29.2.48.2.63&r2=1.59.2.29.2.48.2.64&diff_format=u
Index: ZendEngine2/zend_vm_def.h
diff -u ZendEngine2/zend_vm_def.h:1.59.2.29.2.48.2.63
ZendEngine2/zend_vm_def.h:1.59.2.29.2.48.2.64
--- ZendEngine2/zend_vm_def.h:1.59.2.29.2.48.2.63 Sat Jul 26 13:14:00 2008
+++ ZendEngine2/zend_vm_def.h Sat Jul 26 14:08:11 2008
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: zend_vm_def.h,v 1.59.2.29.2.48.2.63 2008/07/26 13:14:00 dmitry Exp $ */
+/* $Id: zend_vm_def.h,v 1.59.2.29.2.48.2.64 2008/07/26 14:08:11 dmitry Exp $ */
/* If you change this file, please regenerate the zend_vm_execute.h and
* zend_vm_opcodes.h files by running:
@@ -3479,7 +3479,11 @@
if (IS_OP2_TMP_FREE()) {
MAKE_REAL_ZVAL_PTR(offset);
}
-
Z_OBJ_HT_P(*container)->unset_property(*container, offset TSRMLS_CC);
+ if (Z_OBJ_HT_P(*container)->unset_property) {
+
Z_OBJ_HT_P(*container)->unset_property(*container, offset TSRMLS_CC);
+ } else {
+ zend_error(E_NOTICE, "Trying to unset property of
non-object");
+ }
if (IS_OP2_TMP_FREE()) {
zval_ptr_dtor(&offset);
} else {
@@ -3936,9 +3940,19 @@
MAKE_REAL_ZVAL_PTR(offset);
}
if (prop_dim) {
- result =
Z_OBJ_HT_P(*container)->has_property(*container, offset,
(opline->extended_value == ZEND_ISEMPTY) TSRMLS_CC);
+ if (Z_OBJ_HT_P(*container)->has_property) {
+ result =
Z_OBJ_HT_P(*container)->has_property(*container, offset,
(opline->extended_value == ZEND_ISEMPTY) TSRMLS_CC);
+ } else {
+ zend_error(E_NOTICE, "Tryi
