[PHP-DEV] alpha3 getting ready
Hi, Today we will package and tag PHP 5.3 alpha3. Any commits to the 5.3 branch today should be first ok'ed by Johannes. For windows build fixes Pierre should be kept in the loop. 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] New namespace implementation
Snapshot 5.3.0alpha3-dev acts like manual, I think the manual is correct. BTW - this is very useful feature. A "wrong-relative-resolving" rescuer ;) DG. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New namespace implementation
On Tue, Dec 2, 2008 at 23:34, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: The warning is correct. >>> >>> It is not correct - the use statement has effect, as documented in manual >>> http://php.net/manual/en/language.namespaces.importing.php. >> >> The manual is wrong. Importing global object is use \ArrayObject - note >> the \. > > From the look of it it seems like the page there has all \'s in the code > skipped (compare comments to the code). Could somebody from the docs team > please fix it? Already fixed. The problem is the highlight_string() function didn't understand namespaces and magically (and very annoyingly) strip stuff it doesn't understand. The box has been upgraded and the weekly updates on friday will fix it. In the meantime please use http://docs.php.net/manual/en/language.namespaces.importing.php -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New namespace implementation
The warning is correct. It is not correct - the use statement has effect, as documented in manual http://php.net/manual/en/language.namespaces.importing.php. The manual is wrong. Importing global object is use \ArrayObject - note the \. From the look of it it seems like the page there has all \'s in the code skipped (compare comments to the code). Could somebody from the docs team please fix it? -- 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 namespace implementation
The warning is correct. It is not correct - the use statement has effect, as documented in manual http://php.net/manual/en/language.namespaces.importing.php. The manual is wrong. Importing global object is use \ArrayObject - note the \. -- 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 namespace implementation
Hi! but it generates Warning: The use statement with non-compound name 'ArrayObject' has no effect. The warning is correct. It is not correct - the use statement has effect, as documented in manual http://php.net/manual/en/language.namespaces.importing.php. DG. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New namespace implementation
On 02.12.2008, at 22:25, David Grudl wrote: 2) Relative Resolving I pointed out to inappropriate relative resolving earlier (http://news.php.net/php.internals/41837 ). In the world of well-written namespaced frameworks the ratio of usage of "more nested" classes vs. "less nested" is in large majority in favor of the second (http://news.php.net/php.internals/41980 ), but PHP prefer the first way. Now, the new implementation offers way to resolve names relative when it is needed - using 'namespace' operator (as equivalent of the 'self' operator). So I think now there is no reason to use default relative resolving and it should be removed. Like Stas said, lets go with what we have and collect some feedback. Hopefully we will not have to do any larger changes to namespaces after alpha3, but if we have to we will. That being said I really hope that people honor the thought process that went into the current implementation by really giving things a go without prejudice. Your comments are noted and not ignored. 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] New namespace implementation
Hi! but it generates Warning: The use statement with non-compound name 'ArrayObject' has no effect. The warning is correct. What about voting? We already voted a lot, let's actually release something for a change. -- 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
[PHP-DEV] New namespace implementation
I just read the new namespace documentation and I must say that the new implementation is much more flexible. Great work! I had only two objections: 1) False warnings As http://php.net/manual/en/language.namespaces.importing.php says, it is possible to import non-compound name. // importing a global class use ArrayObject; but it generates Warning: The use statement with non-compound name 'ArrayObject' has no effect. 2) Relative Resolving I pointed out to inappropriate relative resolving earlier (http://news.php.net/php.internals/41837). In the world of well-written namespaced frameworks the ratio of usage of "more nested" classes vs. "less nested" is in large majority in favor of the second (http://news.php.net/php.internals/41980), but PHP prefer the first way. Now, the new implementation offers way to resolve names relative when it is needed - using 'namespace' operator (as equivalent of the 'self' operator). So I think now there is no reason to use default relative resolving and it should be removed. What about voting? David Grudl -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / Zend.m4 acinclude.m4 zend_float.h zend_operators.c zend_strtod.c /tests float_prec_001.phpt
Hi, >> Your macros are not compatible with autoconf 2.13: >>***BUG in Autoconf--please report*** AC_LINK_IFELSE > > Grmpf. Problems like this are why I absolutely loathe autoconf. I'll > install 2.13 right away and fix this. Done, tested with autoconf 2.13 and 2.61: http://news.php.net/php.zend-engine.cvs/7244 http://news.php.net/php.zend-engine.cvs/7245 Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / Zend.m4 acinclude.m4 zend_float.h zend_operators.c zend_strtod.c /tests float_prec_001.phpt
Hi, > Your macros are not compatible with autoconf 2.13: >***BUG in Autoconf--please report*** AC_LINK_IFELSE Grmpf. Problems like this are why I absolutely loathe autoconf. I'll install 2.13 right away and fix this. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / Zend.m4 acinclude.m4 zend_float.h zend_operators.c zend_strtod.c /tests float_prec_001.phpt
Christian Seiler wrote: > cseiler Tue Dec 2 16:19:10 2008 UTC > > Added files: (Branch: PHP_5_3) > /ZendEngine2 zend_float.h > /ZendEngine2/testsfloat_prec_001.phpt > > Modified files: > /ZendEngine2 Zend.m4 acinclude.m4 zend_operators.c zend_strtod.c > Log: > - MFH: Changed floating point behaviour to consistently use double precision > on all platforms and with all compilers. Your macros are not compatible with autoconf 2.13: [EMAIL PROTECTED] php-5.3 % ./buildconf --force Forcing buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) rebuilding aclocal.m4 rebuilding configure autoconf: Undefined macros: ***BUG in Autoconf--please report*** AC_LINK_IFELSE ***BUG in Autoconf--please report*** AC_LINK_IFELSE ***BUG in Autoconf--please report*** AC_LINK_IFELSE ***BUG in Autoconf--please report*** AC_LINK_IFELSE ***BUG in Autoconf--please report*** AC_LINK_IFELSE rebuilding acconfig.h rebuilding main/php_config.h.in -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apha3
On 02.12.2008 19:49, Christian Seiler wrote: > Hi, > >> I have given you ZE karma. Please commit this yourself no later than >> Tuesday evening! > > Thanks & done. Thanks to you! =) -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] apha3
Hi, > I have given you ZE karma. Please commit this yourself no later than > Tuesday evening! Thanks & done. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Managing a persistent object in a PHP extension
Hello,
I'm working on a PHP extension that maintains a [int -> SVG XML DOM
Structure] map that should be persistent through user requests to the
server.
I initialize and allocate my one and only global variable in
PHP_MINIT_FUNCTION through the ZEND_INIT_MODULES macro with the
function php_myext_init_globals (see below).
All works fine except the data in this object between requests is
inconsistent. I suppose that is because I have Apache compiled with
mpm-prefork which upon incoming request copies the parent process and
then modifies the __copy__ of my global object, not particular object
itself.
One solution, I suppose, would be recompiling Apache with mpm-worker
option though I'm afraid that won't be really a solution because it is
a "hybrid multi-threaded multi-__process__" which again does not
guarantee that any process copies won't be made. Please, correct me if
I'm wrong here.
The other option that comes in my mind is maintaining this global
object in a shared memory space and request that memory from every
process created. That is an option quite hard to implement though.
Actually, I don't think these things should be so complicated here to
achieve my goal. That is the reason I'm writing this. So the question
is:
Is it possible to maintain a global persistent object in Apache
mpm-prefork? If it is not, can this problem be solved with Apache
mpm-worker?
Thanks,
Martin
P.S. I use bunch of other libraries like libxml and glib for extension
internal workings though I suppose this fact is irrelevant to the
problem described.
static void php_myext_init_globals(zend_myext_globals *myext_globals TSRMLS_DC)
{
g_type_init();
myext_globals->myext_container = pemalloc(sizeof(php_myext_container),
1);
myext_globals->myext_container->my_hashtable =
g_hash_table_new(g_int_hash, g_int_equal);
}
where structure php_myext_container is defined as follows:
ZEND_BEGIN_MODULE_GLOBALS(myext)
php_myext_container* myext_container;
ZEND_END_MODULE_GLOBALS(myext)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
