[PHP-DEV] buildconf fails on current HEAD
Hi All, I am trying to build PHP6 (checked out a while from CVS - HEAD) and found that ./buildconf fails. Following are the failure messages : [EMAIL PROTECTED] php6]$ ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13. rebuilding configure Zend/acinclude.m4:1095: error: m4_defn: undefined macro: _m4_divert_diversion aclocal.m4:1102: PHP_CHECK_SIZEOF is expanded from... autom4te: /usr/bin/m4 failed with exit status: 1 rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for ` config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. Zend/acinclude.m4:1095: error: m4_defn: undefined macro: _m4_divert_diversion aclocal.m4:1102: PHP_CHECK_SIZEOF is expanded from... autom4te: /usr/bin/m4 failed with exit status: 1 autoheader: /usr/bin/autom4te failed with exit status: 1 Am i doing something wrong ? or something is broken ? Thanks In advance! -- with Regards, Raghubansh
Re: [PHP-DEV] PHP mixin RFC
Personally I think that traits is a lot safer than mixing classes.There will
be a lot of things that will need to be considered in order to make it
logical for developers to use.
Quote from the RFC:
"Any method or property that already exists in the class or parent/extended
class cannot be changed unless using class_mixin() see below."
I'm pretty sure this is against all beliefs in the php world.
Runtime merging of classes and overriding methods is a no-no for me.
Traits seems much more safe since you cannot initialize a trait and can only
used to "flatter" other classes.
The proposed way of mixins will create confusion when trying to continue
development on an ongoing project and will need A LOT of extra documentation
just for explaining the hierarchy of the mixed classes.
A very simple case of mixins for php (that allready is implemented) can be
seen in Advogato: Mixins for php.
It has the following example.
***
class Person {
var $job = "person";
function show_job() {
echo "Hi, I work as a {$this->job}.";
}
}
class Bartender {
var $job = "bartender";
function show_job() {
echo "BARTENDER: ";
Person::show_job();
}
}
$b = new Bartender;
$b->show_job();
**
If you look at the example you can see that the Bartender class does NOT
extend the Person class, but when using Person::show_job(); the person's
method have access to the $b object's variables as if the bartender class
extended the person class.
IMO this is the safest way we can use mixins without getting into the
troubles of creating too many (complicated) ways to do the same thing.
G.
On Thu, Sep 11, 2008 at 7:07 AM, Edward Z. Yang <
[EMAIL PROTECTED]> wrote:
> Jonathan Bond-Caron wrote:
> > http://wiki.php.net/rfc/mixin
>
> It seems to me that class_mixin() is a bad idea for the core; it's more
> of a runkit type functionality than traits. After all, we don't allow
> dynamic inheritance, or dynamic interfaces...
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] buildconf fails on current HEAD
Raghubansh wrote: Hi All, I am trying to build PHP6 (checked out a while from CVS - HEAD) and found that ./buildconf fails. Following are the failure messages : [EMAIL PROTECTED] php6]$ ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.59 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13. rebuilding configure Zend/acinclude.m4:1095: error: m4_defn: undefined macro: _m4_divert_diversion aclocal.m4:1102: PHP_CHECK_SIZEOF is expanded from... autom4te: /usr/bin/m4 failed with exit status: 1 rebuilding main/php_config.h.in autoheader: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' autoheader: WARNING: and `config.h.top', to define templates for ` config.h.in' autoheader: WARNING: is deprecated and discouraged. autoheader: autoheader: WARNING: Using the third argument of `AC_DEFINE' and autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without autoheader: WARNING: `acconfig.h': autoheader: autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, autoheader: [Define if a function `main' is needed.]) autoheader: autoheader: WARNING: More sophisticated templates can also be produced, see the autoheader: WARNING: documentation. Zend/acinclude.m4:1095: error: m4_defn: undefined macro: _m4_divert_diversion aclocal.m4:1102: PHP_CHECK_SIZEOF is expanded from... autom4te: /usr/bin/m4 failed with exit status: 1 autoheader: /usr/bin/autom4te failed with exit status: 1 Am i doing something wrong ? or something is broken ? Yes, you're using buggy autoconf. Install autoconf 2.13 and it works. In most linux distros you can install multiple versions. Then you can use the PHP_AUTOCONF and PHP_AUTOHEADER macros to point to the version you wish to use, f.e.: PHP_AUTOCONF=autoconf-2.13 PHP_AUTOHEADER=autoheader-2.13 export PHP_AUTOCONF PHP_AUTOHEADER --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
Santi Saez wrote: Jani Taskinen escribió: Wrong: --disable-shared --enable-static Might or might not work, no guarantees. Dear Jani, Thanks for your reply, I have tried with a very simple: # ./configure --disable-all --disable-shared --enable-static But, generated binary uses shared libs ;-( Yes, that wasn't really the thing. Libtool is nasty but it is possible. With this small Makefile modification you'll get what you want: BUILD_CLI = $(LIBTOOL) --mode=link $(CC) -all-static ^^^ Just add the '-all-static' option there after $(CC) and before any other stuff on the line. And same for BUILD_CGI line too if you want that as all static too. I tested this and it worked, with some nasty notices but those can be ignored. :) BEWARE: You need ALL the libraries that PHP links to as static libs for this to work! --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf fails on current HEAD
Thanks Jani, I have using the same machine with Autoconf V2.59 since 2007 and it use to work :(. I shall get the autoconf-2.13. installed and check. thanks. with Regards, Raghubansh On Thu, Sep 11, 2008 at 1:18 PM, Jani Taskinen <[EMAIL PROTECTED]> wrote: > Raghubansh wrote: > >> Hi All, >> >> I am trying to build PHP6 (checked out a while from CVS - HEAD) and found >> that ./buildconf fails. Following are the failure messages : >> >> [EMAIL PROTECTED] php6]$ ./buildconf >> using default Zend directory >> buildconf: checking installation... >> buildconf: autoconf version 2.59 (ok) >> buildconf: Your version of autoconf likely contains buggy cache code. >> Running cvsclean for you. >> To avoid this, install autoconf-2.13. >> rebuilding configure >> Zend/acinclude.m4:1095: error: m4_defn: undefined macro: >> _m4_divert_diversion >> aclocal.m4:1102: PHP_CHECK_SIZEOF is expanded from... >> autom4te: /usr/bin/m4 failed with exit status: 1 >> rebuilding main/php_config.h.in >> autoheader: WARNING: Using auxiliary files such as `acconfig.h', >> `config.h.bot' >> autoheader: WARNING: and `config.h.top', to define templates for ` >> config.h.in' >> autoheader: WARNING: is deprecated and discouraged. >> autoheader: >> autoheader: WARNING: Using the third argument of `AC_DEFINE' and >> autoheader: WARNING: `AC_DEFINE_UNQUOTED' allows to define a template >> without >> autoheader: WARNING: `acconfig.h': >> autoheader: >> autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1, >> autoheader: [Define if a function `main' is needed.]) >> autoheader: >> autoheader: WARNING: More sophisticated templates can also be produced, >> see >> the >> autoheader: WARNING: documentation. >> Zend/acinclude.m4:1095: error: m4_defn: undefined macro: >> _m4_divert_diversion >> aclocal.m4:1102: PHP_CHECK_SIZEOF is expanded from... >> autom4te: /usr/bin/m4 failed with exit status: 1 >> autoheader: /usr/bin/autom4te failed with exit status: 1 >> >> Am i doing something wrong ? or something is broken ? >> > > Yes, you're using buggy autoconf. Install autoconf 2.13 and it works. > In most linux distros you can install multiple versions. Then you can use > the PHP_AUTOCONF and PHP_AUTOHEADER macros to point to the version > you wish to use, f.e.: > > PHP_AUTOCONF=autoconf-2.13 > PHP_AUTOHEADER=autoheader-2.13 > export PHP_AUTOCONF PHP_AUTOHEADER > > --Jani > > -- with Regards, Raghubansh
Re: [PHP-DEV] buildconf fails on current HEAD
On 11.09.2008 12:01, Raghubansh wrote: Thanks Jani, I have using the same machine with Autoconf V2.59 since 2007 and it use to work :(. I shall get the autoconf-2.13. installed and check. thanks. Can't see any problems with autoconf 2.61. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
hi, On Thu, Sep 11, 2008 at 8:35 AM, Daniel Henning <[EMAIL PROTECTED]> wrote: > Hi Scott, > >>This should go on the main bug tracker rather in PECL, there isn't a >>seperate release on PECL any more for PDO extensions. > > Ok. It was a bit confusing cause of some PDO-drivers which are still active > in PECL. > >>I can reproduce this on Windows but only with VC6 builds. The VC9 builds >>are working without issue. > > Yes, but "VC9 x86 builds, not compabitible with official apache releases". > Thats why I'm asking > for sqlite_external for getting into 5.3 snaps-build again. Scott is working on the VC6 problem with libsqlite3. In the mean time you can use http://apachelounge.com builds for apache as they use VC9. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 Backwards Compatibility
Hello Lester, Wednesday, September 10, 2008, 7:43:25 PM, you wrote: > Marcus Boerger wrote: >> Hello Lester, >>> Another major concern here since maintaining BC with *PHP4* is still an >>> unfortunate current requirement in the field is what happens when PEAR >>> actually uses namespace and other 5.3 only features. HOW will we manage >>> accessing versions of PEAR that are compatible with our active codebase and >>> so >>> ensure that we have compatible sets of packages? >> >> PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4 >> then we cannot support PEAR either. Anyway, as far as I know PEAR does a >> good job in maintenance, especially in supporting both PHP 4 and 5. And >> some people are working on a new system that supports PHP 5. > Marcus - I've never USED PHP4 in production, but it will be some time before > it has been replaced on a lot of ISP's so at present OUR users require > maintaining support for PHP on the only versions they have available - at > present. NOW it at least practical to freeze a version that supports PHP4 and > all the 'extras' that are compatible with that version and not allow any new > features to be included in that build. SO we do not have to test changes to > the code base for PHP5.3 against PHP4. There have always been problems with > using 'new' features but making them available to older versions, which the > compatibility libraries provide, but it is looking as if 'Built for PHP5.3' > will mean 'will not work on PHP5.2' much more so than previous 'minor version > changes'? Seems like we're on the same track that PHP 4 stays as it is and code that was designed for it can be happily maintained for it as well. So we're at discussing changes inbetween the 5 series. Practically I do not at all care for 5.0 or 5.1, they were experiements. However the move from 5.2 to 5.3 should be as easy as possible. If we have to many BC breaks there then we need to list them all and discuss them one after the other. marcus > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/lsces/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Hi Pierre,
>Scott is working on the VC6 problem with libsqlite3. In the mean time
>you can use http://apachelounge.com builds for apache as they use VC9.
That was one good hint with apachelounge. SQLite is working know with VC9 build
but testing is still not
possible on Windows (at least for my companies applications).
As I found out now XML-support is gone also... ("Class 'DomDocument' not found")
Thanks so far.
Kind regards,
Daniel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Daniel Henning wrote:
> Hi Pierre,
>
>> Scott is working on the VC6 problem with libsqlite3. In the mean time
>> you can use http://apachelounge.com builds for apache as they use VC9.
>
> That was one good hint with apachelounge. SQLite is working know with VC9
> build but testing is still not
> possible on Windows (at least for my companies applications).
> As I found out now XML-support is gone also... ("Class 'DomDocument' not
> found")
>
> Thanks so far.
> Kind regards,
> Daniel
Are you using the PHP 5.3 builds for VC9 from windows.php.net - but the
apachelounge build of the apache server using the alpha2 for vc9
domdocument works for me
php.exe" -r "$doc = new DomDocument(); var_dump($doc);"
object(DOMDocument)#1 (0) {
}
Thanks,
Elizabeth
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
hi Daniel,
On Thu, Sep 11, 2008 at 12:35 PM, Daniel Henning <[EMAIL PROTECTED]> wrote:
> Hi Pierre,
>
>>Scott is working on the VC6 problem with libsqlite3. In the mean time
>>you can use http://apachelounge.com builds for apache as they use VC9.
>
> That was one good hint with apachelounge. SQLite is working know with VC9
> build but testing is still not
> possible on Windows (at least for my companies applications).
> As I found out now XML-support is gone also... ("Class 'DomDocument' not
> found")
I can see the error too. I'm on it and will post a note here once it is fixed.
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Hi, >Are you using the PHP 5.3 builds for VC9 from windows.php.net - but the >apachelounge build of the apache server Yes. > using the alpha2 for vc9 domdocument works for me Thats right, CLI and vc6 are fine with xml-support. Regards, Daniel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Debugging PHP to try and find a fix to my ODBC issue (bug #46050)
Hi. I'm trying to debug a problem I'm having with PHP (see bug #46050). I've got php5.3-win32-200809111007.zip 11-Sep-2008 15:26 12.1M and php5.3-dbgpack-win32-200809111007.zip 11-Sep-2008 15:22 4.7M from http://snaps.php.net/win32 But the PDB files are not matching : D:\Personal Files\Software\PHP\Latest Versions\V5.3\php5ts.pdb: PDB does not match image. I would assume the debug files would match. Are they MS VS version specific. I got the debugger up by surprise. I've just installed the MS SQL 2005 Developer Edition and it seems that this debugger comes with it. Is there anything I'm able to do to help find the problem. I'm NOT a C expert, but I can slowly make my way through the code if I have some help. Regards, Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
Jani Taskinen escribió: > BEWARE: You need ALL the libraries that PHP links to as static libs for > this to work! And that is exactly what may not work ;) static libraries are being retired from linux distributions, this is at least the case of openSUSE, Fedora and probably others. -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
On 11.09.2008 18:35, Cristian Rodríguez wrote: Jani Taskinen escribió: BEWARE: You need ALL the libraries that PHP links to as static libs for this to work! And that is exactly what may not work ;) static libraries are being retired from linux distributions, this is at least the case of openSUSE, Fedora and probably others. Are you sure? I can see them in -devel packages all right. # rpm -qf /usr/lib64/libbz2.a libbz2-devel-1.0.5-13.1 -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Howto build statically linked PHP CGI (without shared libs)
Antony Dovgal wrote: On 11.09.2008 18:35, Cristian Rodríguez wrote: Jani Taskinen escribió: BEWARE: You need ALL the libraries that PHP links to as static libs for this to work! And that is exactly what may not work ;) static libraries are being retired from linux distributions, this is at least the case of openSUSE, Fedora and probably others. Are you sure? I can see them in -devel packages all right. # rpm -qf /usr/lib64/libbz2.a libbz2-devel-1.0.5-13.1 ..and you can always build your libs yourself too.. ;) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
Hi,
Multiple namespaces per file were introduced to allow certain workflows in PEAR
and frameworks like Symphony which can combine multiple classes and namespaces
in a single package.
They work like this:
namespace X;
...
namespace Y;
...
The problem is, no one thought of scoping "use" statements, so now those merged
files share their "use" imports, thus breaking all the code where collisions
occur.
Also we have the problems with name resolution of internal vs user classes and
autoloaders, discussed here.
And we also have the non-intuitive differentiation between resolving
functions/classes/constant which will most likely lead people to believe
functions/constants aren't supported in any way in namespaces (if they try, and
it doesn't work, they won't try second time).
Which leads me to the following proposal:
For PHP 5.3 we introduce namespaces with a very limited "safe" set of barebones
features, that we won't regret later for releasing and having to modify in a
non-BC way. It'll let people start porting their code and be ready for the full
featureset later on, which will be a proper superset of the 5.3 release:
1) We disable support for multiple namespaces per file as it is, as it can't be
used without ability to scope "use" statements as well.
2) We remove the statement "use" (regarding namespaces, not regarding
closures), until we get more feedback from the community on the exact preferred
resolution algorithms, and more thought is put to this.
For PHP 5.4 or 6:
1) Introduce file-level "use" statements with same syntax as now, but modified
resolution rules based on further discussion and feedback. And if someone is
about to say "we had plenty of discussion", well it's apparent we didn't have
enough given all the problems facing namespaces right now, or maybe not enough
of the constructive type of discussion.
2) Introduce ability to scope "use" and "namespace" statements with curly
brackets, so that multiple files can be safely merged without changing intent
(all file-level namespace can be converted with curly brackets, and the
existing curly bracket ones don't need to be converted), example:
namespace X {
use Y as Z {
...
}
}
namespace Y {
use X as Z {
...
}
}
Waiting for your feedback...
Regards,
Stan Vassilev
[PHP-DEV] Re: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
Stan Vassilev | FM wrote: > Hi, > > Multiple namespaces per file were introduced to allow certain > workflows in PEAR and frameworks like Symphony which can combine > multiple classes and namespaces in a single package. > > They work like this: > > > namespace X; > > ... > > namespace Y; > > ... > > > The problem is, no one thought of scoping "use" statements, so now > those merged files share their "use" imports, thus breaking all the > code where collisions occur. Hi, Stan, did you actually try this out? According to my checkout of CVS, you're wrong. Try this script: The output is: hi hi Fatal error: Class 'three::one' not found in /home/user/workspace/php5_func/test.php on line 11 Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
Stan Vassilev | FM wrote: Hi, Multiple namespaces per file were introduced to allow certain workflows in PEAR and frameworks like Symphony which can combine multiple classes and namespaces in a single package. They work like this: namespace X; ... namespace Y; ... The problem is, no one thought of scoping "use" statements, so now those merged files share their "use" imports, thus breaking all the code where collisions occur. Hi, Stan, did you actually try this out? According to my checkout of CVS, you're wrong. Try this script: What's the logic behind namespace declaration affecting file-level import statements. Looks like such a hack to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
Stan Vassilev | FM wrote: >> Stan Vassilev | FM wrote: >>> Hi, >>> >>> Multiple namespaces per file were introduced to allow certain >>> workflows in PEAR and frameworks like Symphony which can combine >>> multiple classes and namespaces in a single package. >>> >>> They work like this: >>> >>> >>> namespace X; >>> >>> ... >>> >>> namespace Y; >>> >>> ... >>> >>> >>> The problem is, no one thought of scoping "use" statements, so now >>> those merged files share their "use" imports, thus breaking all the >>> code where collisions occur. >> >> Hi, >> >> Stan, did you actually try this out? According to my checkout of CVS, >> you're wrong. Try this script: >> > > What's the logic behind namespace declaration affecting file-level > import statements. Looks like such a hack to me. ??? I'm confused. First you say that merged files share "use" imports, which is not true, then complain that namespace declaration affects file-level import statements. Which one is the problem? Greg Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Debugging PHP to try and find a fix to my ODBC issue (bug #46050)
On Thu, Sep 11, 2008 at 3:53 PM, Richard Quadling <[EMAIL PROTECTED]> wrote: > Hi. > > I'm trying to debug a problem I'm having with PHP (see bug #46050). > > I've got php5.3-win32-200809111007.zip 11-Sep-2008 15:26 > 12.1M and php5.3-dbgpack-win32-200809111007.zip 11-Sep-2008 15:22 > 4.7M from http://snaps.php.net/win32 > > But the PDB files are not matching : D:\Personal > Files\Software\PHP\Latest Versions\V5.3\php5ts.pdb: PDB does not match > image. > > I would assume the debug files would match. Are they MS VS version > specific. I got the debugger up by surprise. I've just installed the > MS SQL 2005 Developer Edition and it seems that this debugger comes > with it. > > > Is there anything I'm able to do to help find the problem. I'm NOT a C > expert, but I can slowly make my way through the code if I have some > help. They are built at the same time so they should work (and does here). However, can you post again in the windows internals list please? It is a better place to discuss this problem. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] add support for functions to use
Hi,
I've just finished implementing use for functions. This patch is
against PHP_5_3 and can be easily ported to HEAD. I am confident that
it is quite mature and have tests in the patch to prove it.
the patch is also at http://pear.php.net/~greg/usefunctions.patch.txt
This patch implements the following syntax:
func.inc:
main.php:
The output is "hi\nhi\nhi\n"
It can be used to alias any function, and so can also be useful for
overriding an internal function and saving it:
With this patch, function users should be a lot happier.
Thanks,
Greg
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.85
diff -u -u -r1.647.2.27.2.41.2.85 zend_compile.c
--- Zend/zend_compile.c 29 Aug 2008 10:17:08 - 1.647.2.27.2.41.2.85
+++ Zend/zend_compile.c 12 Sep 2008 01:56:14 -
@@ -139,6 +139,7 @@
CG(start_lineno) = 0;
CG(current_namespace) = NULL;
CG(current_import) = NULL;
+ CG(current_import_functions) = NULL;
init_compiler_declarables(TSRMLS_C);
zend_hash_apply(CG(auto_globals), (apply_func_t) zend_auto_global_arm
TSRMLS_CC);
zend_stack_init(&CG(labels_stack));
@@ -1536,22 +1537,10 @@
char *lcname;
int prefix_len = 0;
- if (check_namespace && CG(current_namespace)) {
- /* We assume we call function from the current namespace
- if it is not prefixed. */
- znode tmp;
-
- tmp.op_type = IS_CONST;
- tmp.u.constant = *CG(current_namespace);
- zval_copy_ctor(&tmp.u.constant);
- zend_do_build_namespace_name(&tmp, &tmp, function_name
TSRMLS_CC);
- *function_name = tmp;
-
- /* In run-time PHP will check for function with full name and
- internal function with short name */
- prefix_len = Z_STRLEN_P(CG(current_namespace)) + 2;
+ if (check_namespace) {
+ zend_resolve_function_name(function_name, &prefix_len
TSRMLS_CC);
}
-
+
lcname = zend_str_tolower_dup(function_name->u.constant.value.str.val,
function_name->u.constant.value.str.len);
if ((zend_hash_find(CG(function_table), lcname,
function_name->u.constant.value.str.len+1, (void **) &function)==FAILURE) ||
((CG(compiler_options) &
ZEND_COMPILE_IGNORE_INTERNAL_FUNCTIONS) &&
@@ -1672,6 +1661,55 @@
zend_do_extended_fcall_begin(TSRMLS_C);
}
+void zend_resolve_function_name(znode *function_name, int *prefix_len
TSRMLS_DC)
+{
+ char *compound;
+ char *lcname;
+ zval **ns;
+ znode tmp;
+
+ compound = memchr(Z_STRVAL(function_name->u.constant), ':',
Z_STRLEN(function_name->u.constant));
+ if (compound) {
+ /* This is a compound function name that contains namespace
prefix */
+ if (Z_TYPE(function_name->u.constant) == IS_STRING &&
+ Z_STRVAL(function_name->u.constant)[0] == ':') {
+ /* The STRING name has "::" prefix */
+ Z_STRLEN(function_name->u.constant) -= 2;
+ memmove(Z_STRVAL(function_name->u.constant),
Z_STRVAL(function_name->u.constant)+2, Z_STRLEN(function_name->u.constant)+1);
+ Z_STRVAL(function_name->u.constant) = erealloc(
+ Z_STRVAL(function_name->u.constant),
+ Z_STRLEN(function_name->u.constant) + 1);
+
+ /* check for self/parent/etc. */
+ if (ZEND_FETCH_CLASS_DEFAULT !=
zend_get_class_fetch_type(Z_STRVAL(function_name->u.constant),
Z_STRLEN(function_name->u.constant))) {
+ zend_error(E_COMPILE_ERROR, "'::%s' is a wrong
function name", Z_STRVAL(function_name->u.constant));
+ }
+ }
+ } else if (CG(current_import_functions) || CG(current_namespace)) {
+ /* this is a plain name (without ::) */
+ lcname =
zend_str_tolower_dup(Z_STRVAL(function_name->u.constant),
Z_STRLEN(function_name->u.constant));
+
+ if (CG(current_import_functions) &&
+ zend_hash_find(CG(current_import_functions), lcname,
Z_STRLEN(function_name->u.constant)+1, (void**)&ns) == SUCCESS) {
+ /* The given name is an import name. Substitute it. */
+ zval_dtor(&function_name->u.constant);
+ function_name->u.constant = **ns;
+ zval_copy_ctor(&function_name->u.constant);
+ } else if (CG(current_namespace)) {
+ tmp.op_type = IS_CONST;
+ tmp.u.constant = *CG(current_namespace);
+ zval_copy_ctor(&tmp.u.constant);
+ zend_do_build_namespace_name(&tmp, &tmp, function_
[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorder issues)
Stas and I continued our discussion off list, and decided to pop it back on the list, so here is 1 message, another to follow. Greg === Stanislav Malyshev wrote: > > Hi! > > >> >> ...the message you replied to? > > > > I must be missing something here. In my last reply, I raised a number > > of points, including having unqualified names resolve only to > > namespace and relation of this to functions and constants. I do not > > see these points addressed or discussed anywhere in your email. Some > > less important points - like tradeoffs you need to take for working > > with internal classes (second reply part in my email) - weren't > > mentioned either. Hi Stas, In your last reply, you asserted that the only solution was to always resolve unqualified names to namespace::name. The patch I sent actually shows that this is unnecessary. > > > > Also, I do not see the explanation how this patch is different from > > the last one and how the difference in the speed is achieved - you > > just claim it has gone from 466x to 5.2x but I did not find any > > explanation about what is the change allowed you to do this. I would > > like to understand what this change is and to do that from reading a > > patch is kind of hard and I can't be sure what I understood was > > actually your intent. Could you explain it? > > You could also contact me on IM or IRC if you prefer. Basically, the patch does 2 things 1) resolution order is changed to: foo.php: $a = new foo(); a) does namespace::foo class exist? b) try to autoload namespace::foo c) try to locate internal class ::foo 2) if internal class ::foo is found, then cache this information so that if another reference to the foo class occurs in foo.php, resolution short circuits to: a) use internal class ::foo This second point is why the slowdown went from ridiculous to slight. Since your primary complaint about the resolution order is performance, and the patch removes the performance problem, this makes your suggestion of never checking internal classes unnecessary. That was the point of my previous email with the patch. Clear now? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] Re: [PHP-DEV] namespace examples (solving name resolutionorder issues)
Hi,
This is the 2nd of two exchanges that occurred off-list that Stas and I
would like to put back on-list.
Greg
===
Stanislav Malyshev wrote:
> > Hi!
> >
>> >> Basically, the patch does 2 things
>> >>
>> >> 1) resolution order is changed to:
>> >>
>> >> foo.php:
>> >> $a = new foo();
>> >> a) does namespace::foo class exist?
>> >> b) try to autoload namespace::foo
>> >> c) try to locate internal class ::foo
>> >>
>> >> 2) if internal class ::foo is found, then cache this information
so that
>> >> if another reference to the foo class occurs in foo.php, resolution
>> >> short circuits to:
>> >> a) use internal class ::foo
>> >>
>> >> This second point is why the slowdown went from ridiculous to slight.
> >
> > OK, now I understand better what it does, thanks. Do I understand
> > right that the caching is in runtime, when the class access opcode is
> > executed (since you couldn't autoload in compile time)? If so, how
> > long the cache entry is kept there? I.e. if I have execution path that
> > goes to file A, then B, then A again, then C, then B, etc. and then
> > unroll the stack back - do I store all results for second entrance
> > into A? Is it per-op-array (since we don't have per-file data
> > structure AFAIK)? What happens if include path (or autoloader)
> > changes, so that the class name that could not be loaded before can be
> > loaded now - e.g. application adds plugin definitions, etc. - will it
> > be ensured that autoloading is never attempted again for the same
> > class? What happens if somebody loads that namespace::foo class
> > manually (with require) - will the old resolution hold or the new one
> > apply?
> >
> > Also I note that even if the cache stores all resolutions for all
> > internal classes times all namespaces, it will still require at least
> > one exhaustive autoload search per internal class per op-array - or
> > per file, if you somehow find a way to store cache per-file in
> > runtime, and these can not be eliminated with bytecode caching, unlike
> > all other filesystem accesses.
Hi,
The caching is at runtime. Basically, it's in executor_globals, and so
is not linked to any opcode array (I couldn't figure out any other
globally accessible storage location). It works like an associative
array. If file X.php loads XMLReader in namespace namespacename, it
creates this entry:
array(
'X.php\0namespacename::XMLReader' => {class entry for XMLReader}
);
So that the next time we reach X.php and the XMLReader class, it sees
this entry, and does not attempt autoload. As for your questions about
include_path/autoload, I had not added this to the patch, but the easy
solution is to clean the hash on include_path change, or autoload
change. I assume this code would break with the patch:
sneakyreader.php:
main.php:
Whereas with the current behavior, it would instead instantiate
foo::XMLReader on the second access. However, this is definitely a wtf
situation - the exact same looking line of code would load a different
class name entirely depending on what was included.
The cache does not eliminate the first autoload per-file.
I'm sure there are other issues to work out, but this should give a
better idea of what I am trying to do.
As for your question of whether to simply error out if foo::XMLReader
doesn't exist (in the main.php example above), this also would be
acceptable for classes, but not for functions, as the ratio of
user-defined to internal functions in any source code example is 1:many,
many. However, we don't autoload functions or constants, so load ordr
is an absolute, much as it was for classes in PHP 4 before autoload was
introduced.
It is not an easy problem to solve, but we do need to solve it prior to
the next release. Should we take this back on-list?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Scoping of "use" statements and a strategy for 5.3/6.0 release of namespace
Hi Stan, I realized I missed 2 of your points, response below: Stan Vassilev | FM wrote: > Hi, > > Multiple namespaces per file were introduced to allow certain > workflows in PEAR and frameworks like Symphony which can combine > multiple classes and namespaces in a single package. > > They work like this: > > > namespace X; > > ... > > namespace Y; > > ... > > > The problem is, no one thought of scoping "use" statements, so now > those merged files share their "use" imports, thus breaking all the > code where collisions occur. > > Also we have the problems with name resolution of internal vs user > classes and autoloaders, discussed here. I just posted a patch that solves this problem, and a few minutes ago forwarded two messages that further clarify how the patch works and why it is a good solution to the problem. > And we also have the non-intuitive differentiation between resolving > functions/classes/constant which will most likely lead people to > believe functions/constants aren't supported in any way in namespaces > (if they try, and it doesn't work, they won't try second time). The other 2 patches I have posted solve these issues decisively. Since these would change namespace edge cases and introduce a new way to import, I think an alpha3 is warranted. The name resolution changes should not affect any existing working code that utilizes namespaces, but should make it possible to do autoload without having to "use" every single namespace class. The patches do need review, and I am certain the patch introducing function::blah::here() could be better written, and needs a Sara/Dmitry type to take a quick look and say what could be done to improve it. However, I don't think these facts warrant removal of the key feature of namespaces, especially since they are relatively easy to solve - these patches did not take many hours to whip up, and do not change very much. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
