[PHP-DEV] Re: [PHP-DOC] What is the use of the $replacement property in the RegexIterator class.
On 5 May 2010 17:25, Richard Quadling rquadl...@googlemail.com wrote: Hi. I'm in the process of getting the PHPDoc classes showing the correct inherited properties and methods (public/protected but not private). I picked RecursiveRegexIterator (it has the largest number of xi:includes in the documentation) as a test. Using php --rc I see that the inheritance chain is RecursiveRegexIterator, RegexIterator, FilterIterator and IteratorIterator. The property $replacement is part of RegexIterator. I can see no documentation for this in phpdoc, nor in the Doxygen at http://www.php.net/~helly/php/ext/spl/ In all the examples I've made so far, var_dump()-ing the RegexIterator results in a [replacement]=NULL Assigning a value to $replacement seems to have no bearing on the output. I believe the intention was to give that property a value which could be used with RegexIterator::REPLACE mode but that particular mode has not yet been fully implemented. There is a related bug ( http://bugs.php.net/50579 ) that has not been assigned; I can't say what the plan is for if/when the replacement mode will get some attention. See also: the PHP implementation of RegexIterator ( http://svn.php.net/viewvc/php/php-src/trunk/ext/spl/internal/regexiterator.inc?view=markup ). Regards, Richard. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autoboxing in PHP
Maybe this one? http://www.php-security.org/2010/05/03/mops-2010-006-php-addcslashes-interruption-information-leak-vulnerability/index.html Tyrael On Wed, May 5, 2010 at 1:26 PM, Mark Skilbeck markskilb...@gmail.comwrote: What exploits are there for __toString()? Just wondering. On 05/05/2010 07:50, Dmitry Stogov wrote: Hi Moriyoshi, I took just a quick look through the patch, but for me it looks like a bad idea. Introducing new magic function may bring a lot of troubles and open a new door for exploit writer (we already have problems with __toString() method). Also I afraid, this magic method will make php slower even if scripts don't use this future (at least the patch disables code specialization for ZEND_INIT_METHOD_CALL) and make some future type propagation optimizations non-applicable. At last the patch introduces 18 new grammar conflicts and I think it's not acceptable. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compilation of trunk with --enable-dtrace
Hello ! I'm currently trying to compile the trunk with dtrace under FreeBSD 8 with revision 298979 and i have the following problem : # ./buildconf # ./configure --enable-dtrace #make ... local/include -g -O2 -fvisibility=hidden -c /usr/home/fch/php/TSRM/tsrm_strtok_r.c -o TSRM/tsrm_strtok_r.lo /bin/sh /usr/home/fch/php/libtool --silent --preserve-dup-deps --mode=compile cc -ITSRM/ -I/usr/home/fch/php/TSRM/ -DPHP_ATOM_INC -I/usr/home/fch/php/include -I/usr/home/fch/php/main -I/usr/home/fch/php -I/usr/home/fch/php/ext/date/lib -I/usr/home/fch/php/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/fch/php/ext/sqlite3/libsqlite -I/usr/home/fch/php/TSRM -I/usr/home/fch/php/Zend-I/usr/local/include -g -O2 -fvisibility=hidden -c /usr/home/fch/php/TSRM/tsrm_virtual_cwd.c -o TSRM/tsrm_virtual_cwd.lo /bin/sh /usr/home/fch/php/libtool --silent --preserve-dup-deps --mode=compile cc -Imain/ -I/usr/home/fch/php/main/ -DPHP_ATOM_INC -I/usr/home/fch/php/include -I/usr/home/fch/php/main -I/usr/home/fch/php -I/usr/home/fch/php/ext/date/lib -I/usr/home/fch/php/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/fch/php/ext/sqlite3/libsqlite -I/usr/home/fch/php/TSRM -I/usr/home/fch/php/Zend-I/usr/local/include -g -O2 -fvisibility=hidden -c /usr/home/fch/php/main/main.c -o main/main.lo In file included from /usr/home/fch/php/main/main.c:84: /path/to/php/Zend/zend_dtrace.h:40:29: error: zend_dtrace_gen.h: No such file or directory Any suggestion ? All my apologize if it's not the good place to report this. Best regards, Fred -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Compilation of trunk with --enable-dtrace
FreeBSD Dtrace is known to be broken because of a syntax issue somewhere in their DTrace scripts that are included by default. FreeBSD dtrace is not supported at the moment. David On 2010-05-06, Frederic Hardy frederic.ha...@mageekbox.net wrote: Hello ! I'm currently trying to compile the trunk with dtrace under FreeBSD 8 with revision 298979 and i have the following problem : # ./buildconf # ./configure --enable-dtrace #make ... local/include -g -O2 -fvisibility=hidden -c /usr/home/fch/php/TSRM/tsrm_strtok_r.c -o TSRM/tsrm_strtok_r.lo /bin/sh /usr/home/fch/php/libtool --silent --preserve-dup-deps --mode=compile cc -ITSRM/ -I/usr/home/fch/php/TSRM/ -DPHP_ATOM_INC -I/usr/home/fch/php/include -I/usr/home/fch/php/main -I/usr/home/fch/php -I/usr/home/fch/php/ext/date/lib -I/usr/home/fch/php/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/fch/php/ext/sqlite3/libsqlite -I/usr/home/fch/php/TSRM -I/usr/home/fch/php/Zend-I/usr/local/include -g -O2 -fvisibility=hidden -c /usr/home/fch/php/TSRM/tsrm_virtual_cwd.c -o TSRM/tsrm_virtual_cwd.lo /bin/sh /usr/home/fch/php/libtool --silent --preserve-dup-deps --mode=compile cc -Imain/ -I/usr/home/fch/php/main/ -DPHP_ATOM_INC -I/usr/home/fch/php/include -I/usr/home/fch/php/main -I/usr/home/fch/php -I/usr/home/fch/php/ext/date/lib -I/usr/home/fch/php/ext/ereg/regex -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/fch/php/ext/sqlite3/libsqlite -I/usr/home/fch/php/TSRM -I/usr/home/fch/php/Zend-I/usr/local/include -g -O2 -fvisibility=hidden -c /usr/home/fch/php/main/main.c -o main/main.lo In file included from /usr/home/fch/php/main/main.c:84: /path/to/php/Zend/zend_dtrace.h:40:29: error: zend_dtrace_gen.h: No such file or directory Any suggestion ? All my apologize if it's not the good place to report this. Best regards, Fred -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt
On Thu, May 6, 2010 at 12:59 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, May 6, 2010 at 00:48, Sara Golemon poll...@php.net wrote: pollita Wed, 05 May 2010 22:48:14 + Revision: http://svn.php.net/viewvc?view=revisionrevision=299037 Log: Add JSON_Serializable interface Slight bikeshedding.. but we don't use underscore for interface/classnames... And I would go with JsonSerializable. However, where does it come from? Does it have to be an interface or why not using __toJson? I must have lived under a rock as I don't see any proposal either, be RFC or internals. Cheers, -- Pierre @pierrejoye | 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] Re: Compilation of trunk with --enable-dtrace
On 06.05.2010 15:21, David Soria Parra wrote: FreeBSD Dtrace is known to be broken because of a syntax issue somewhere in their DTrace scripts that are included by default. FreeBSD dtrace is not supported at the moment. Anyway, you need to check the result of dtrace execution and abort with a nice errmsg if it fails. Also you might want to detect dtrace's version before running it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trunk is alive and open
On 31.03.2010, at 07:22, Rasmus Lerdorf wrote: On 03/30/2010 08:41 PM, Philip Olson wrote: It's awesome that PHP has so many great options for the next Release Manager because all of the proposed people would do great. However, I'd like to see Rasmus become RM. Not sure about the co-RM topic but Chris Jones comes to mind. I love the way these two guys handle things, and it feels like a nice balance. And while Rasmus may [or may not] deny his BDFL status, I'd love to see it in high gear especially now that he's funemployed. I didn't actually volunteer. I think someone misunderstood that at some point. I'll do it if nobody else will, but both Derick and David seem keen, and I think they should work it out between them. The whole concept of a non-technical co-rm person, is kind of a moot point I think. We all know that person is Lukas and he will do his thing regardless. That's not a knock, by the way, we need a process guy to offset my anti-process approach so that we can meet somewhere in the middle. Just FYI: I will no longer serve as the process guy, nor anything else really. Feel free to remove my karma. I may write the occasional post here still of course as I will continue to be a PHP end user. Context: I just feel that with the things I feel are right, I will just end up being tied up in a perpetual battle. Over the years I got a few things to go the way I wanted (wiki, a todo list, RFCs) but there are simply some fundamental things where I am no longer motivated to work with the status quo, but where I do not see a realistic chance if this ever changing. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Compilation of trunk with --enable-dtrace
Hello ! I don't known why the dtrace version has a relation with the fact that the file zend_dtrace_gen.h is not in the trunk... Perhaps you can explain that to me ? error: zend_dtrace_gen.h: No suchfile or directory Best regards, Fred. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Compilation of trunk with --enable-dtrace
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.05.10 14:55, schrieb Frederic Hardy: Hello ! I don't known why the dtrace version has a relation with the fact that the file zend_dtrace_gen.h is not in the trunk... Perhaps you can explain that to me ? zend_dtrace_gen.h is generated during configure using dtrace -h and then the object file is generated using dtrace -G on Solaris and FreeBSD (mac os doesn't need a compiled object files of the probe description). On FreeBSD dtrace -h fails because of a syntax error in a dtrace script that comes with the OS, therefore the dtrace headers cannot be generated. We need to generate the headers as every OS generates different DTrace headers. david -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL4r8tAAoJEAT0aMuPE7Z1VqkQAJTchyHdMf8B5SaePTuAJKeS AnorTA+9La34r0zLdS6Da5TMoRuQB4a7hTTeM+8FuCwxdNKr6jBWyL92A2G4umxB D7o8IZ/HCMUX2G2UMIukTcTm/ZCmDYNHhExE1Grx9Gah7u+y1GpkynuMU6TuY5VK eDErRLi6E20S1W86Hq/RHGZP0ikqsWR6NixoLwJ4ySMWU095Tg8UIc/eAW+IfB3a GaDPbOWqZUgDzbJ2GXStZBJ9CIbZBzHLizCb5sR887fPaGrMT8/5L2nOC8uHm+4I W8EP+8g9cSaqjlc5E3RWZZphgGJsA+/D9pKqNy64BwLwn83qegMefMMEuZBnyaTn YDzuy2dHE+SeHElP1oRH68h/cABKFNZHeTsrwEeUnuIxDcMTaJevuEWpzFx1NB7k tRKmQOw2Cd+gYhdbazfUGkUHRyBc0EojNq3iwg/jsXDXfiBA/DgIhTOYcyh7cPeY Cx4kgXc3nEQJniBBerRkW7QSVA/XFHIfJQ6fHF20lqaYjc0mzfgthjW5Hf/ivhlx JJBcl9oIGxpwHX74e5Yo5KTgF+lnOEZYr1gjCDWusHy11Lvu4MQAlPdnSShXxyop vLii+EnpyKSrh29dEtiDkAiKKB6y9rUzs1h2HwtJiOsk8lGj9DeVualyTI1Got3Z TelI2vACc/vUSaMWiJL/ =kqvH -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt
Hi guys, I'd like to thank you for this implementation. @Pierre: There is a RFC I wrote: http://wiki.php.net/rfc/jsonable I'd suggest to rather be JSONSerializable or be Jsonable. JSON is an acronym, the same as PDO. We don't have interface for Pdo, but for PDO. So we should keep consistency. Cheers, On Thu, May 6, 2010 at 8:37 AM, Pierre Joye pierre@gmail.com wrote: On Thu, May 6, 2010 at 12:59 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, May 6, 2010 at 00:48, Sara Golemon poll...@php.net wrote: pollita Wed, 05 May 2010 22:48:14 + Revision: http://svn.php.net/viewvc?view=revisionrevision=299037 Log: Add JSON_Serializable interface Slight bikeshedding.. but we don't use underscore for interface/classnames... And I would go with JsonSerializable. However, where does it come from? Does it have to be an interface or why not using __toJson? I must have lived under a rock as I don't see any proposal either, be RFC or internals. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt
PS: Argh, sorry... pressed the send button without finishing to write the email. Consistency that matches with Serializable interface when dealing with (un)serialize(). So if we have to vote, I'd go for Jsonable. The method should be renamed to _toJSON (I can even accept __toJson here), using the same convention applied for __sleep, __toString, __wakeup, __invoke. Cheers, On Thu, May 6, 2010 at 2:41 PM, Guilherme Blanco guilhermebla...@gmail.com wrote: Hi guys, I'd like to thank you for this implementation. @Pierre: There is a RFC I wrote: http://wiki.php.net/rfc/jsonable I'd suggest to rather be JSONSerializable or be Jsonable. JSON is an acronym, the same as PDO. We don't have interface for Pdo, but for PDO. So we should keep consistency. Cheers, On Thu, May 6, 2010 at 8:37 AM, Pierre Joye pierre@gmail.com wrote: On Thu, May 6, 2010 at 12:59 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, May 6, 2010 at 00:48, Sara Golemon poll...@php.net wrote: pollita Wed, 05 May 2010 22:48:14 + Revision: http://svn.php.net/viewvc?view=revisionrevision=299037 Log: Add JSON_Serializable interface Slight bikeshedding.. but we don't use underscore for interface/classnames... And I would go with JsonSerializable. However, where does it come from? Does it have to be an interface or why not using __toJson? I must have lived under a rock as I don't see any proposal either, be RFC or internals. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PDO-SQLite version
In PHP 5.2, phpinfo() reports the PDO-SQLite version as 3.3.7. However, from the SVN history of the 5.2 branch, SQLite 3.3.15 and even part of 3.3.16 were merged in. The VERSION file was updated to track this, but someone changed it to 3.3.7 under the assumption that 3.3.17 was a typo. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/ext/pdo_sqlite/sqlite/ These version number discrepancies were a real gotcha when I was trying to pinpoint an obscure locking problem in SQLite 3.3.x. What version number should phpinfo() really report for PDO-SQLite? - Ken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/ NEWS ext/json/json.c ext/json/php_json.h ext/json/tests/serialize.phpt
hi, I like the feature, it is a nice and useful one. However nobody ever posted anything on internals about it. The differences between the implementation and the RFC as well as the questions raised by this addition show that it would be better to discuss prior to commit. But as it is in trunk, that's less a problem, that's why trunk exists: a development tree. I would still like to see some kind of discussions about it. I would prefer a simple __toJson for example (yes, that's magic) :). Cheers, On Thu, May 6, 2010 at 7:41 PM, Guilherme Blanco guilhermebla...@gmail.com wrote: Hi guys, I'd like to thank you for this implementation. @Pierre: There is a RFC I wrote: http://wiki.php.net/rfc/jsonable I'd suggest to rather be JSONSerializable or be Jsonable. JSON is an acronym, the same as PDO. We don't have interface for Pdo, but for PDO. So we should keep consistency. Cheers, On Thu, May 6, 2010 at 8:37 AM, Pierre Joye pierre@gmail.com wrote: On Thu, May 6, 2010 at 12:59 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, May 6, 2010 at 00:48, Sara Golemon poll...@php.net wrote: pollita Wed, 05 May 2010 22:48:14 + Revision: http://svn.php.net/viewvc?view=revisionrevision=299037 Log: Add JSON_Serializable interface Slight bikeshedding.. but we don't use underscore for interface/classnames... And I would go with JsonSerializable. However, where does it come from? Does it have to be an interface or why not using __toJson? I must have lived under a rock as I don't see any proposal either, be RFC or internals. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- Pierre @pierrejoye | 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] PDO-SQLite version
hi, Do you build php against an external version? Cheers, On Thu, May 6, 2010 at 7:48 PM, Ken Dreyer ktdre...@ktdreyer.com wrote: In PHP 5.2, phpinfo() reports the PDO-SQLite version as 3.3.7. However, from the SVN history of the 5.2 branch, SQLite 3.3.15 and even part of 3.3.16 were merged in. The VERSION file was updated to track this, but someone changed it to 3.3.7 under the assumption that 3.3.17 was a typo. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/ext/pdo_sqlite/sqlite/ These version number discrepancies were a real gotcha when I was trying to pinpoint an obscure locking problem in SQLite 3.3.x. What version number should phpinfo() really report for PDO-SQLite? - Ken -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | 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] PDO-SQLite version
I am referring to the SQLite version that is bundled in PDO-SQLite in PHP 5.2. That is the one I have been using in my PHP builds. I am suggesting that the version numbers reported by the VERSION file and the phpinfo() function are misleading. - Ken On Thu, May 6, 2010 at 12:43 PM, Pierre Joye pierre@gmail.com wrote: hi, Do you build php against an external version? Cheers, On Thu, May 6, 2010 at 7:48 PM, Ken Dreyer ktdre...@ktdreyer.com wrote: In PHP 5.2, phpinfo() reports the PDO-SQLite version as 3.3.7. However, from the SVN history of the 5.2 branch, SQLite 3.3.15 and even part of 3.3.16 were merged in. The VERSION file was updated to track this, but someone changed it to 3.3.7 under the assumption that 3.3.17 was a typo. http://svn.php.net/viewvc/php/php-src/branches/PHP_5_2/ext/pdo_sqlite/sqlite/ These version number discrepancies were a real gotcha when I was trying to pinpoint an obscure locking problem in SQLite 3.3.x. What version number should phpinfo() really report for PDO-SQLite? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/trunk/Zend/tests/traits/ error_001.phpt error_002.phpt error_003.phpt error_004.phpt error_005.phpt error_006.phpt error_007.phpt error_008.phpt error_009.p
Hi Felipe: Hope you don't mind that I post it on the list, think the discussion should be properly archived. On 06 May 2010, at 18:30, Felipe Pena wrote: Hello, 2010/5/6 Stefan Marr p...@stefan-marr.de Hi Felipe: On 05 May 2010, at 22:00, Felipe Pena wrote: One question... Looking at the grammar, I got a doubt... Is actually intended to allow constructions like 'trait foo extends ...' and 'trait foo implements ...' ? (I can't see an example like that on the RFC) The idea is that traits form its own hierarchy of composition, and since they can be composed from traits itself, it should not be necessary, to allow inheritance. So, no, extends and implements should not be allowed. The idea of allowing interfaces was rejected in the first big discussion. Interfaces belong to classes, and traits are solely meant to provide implementation. Since you can exclude methods, it does not fit well with the notion of interfaces. There are a number of things which are not quite clear in the grammar at the moment. My idea was that I just reuse the class grammar, and add exceptions for the situations which are not allowed. Mostly to avoid duplicating the relevant grammar parts. Do you think it would be better to do it the other way around, and use a dedicated grammar for traits? We could use a dedicated grammar or make the properly checks in the compiler. Both solutions looks good for me. I got a new question for you... Shouldn't we don't allow the implementation of magic methods and constructors in Traits? Hm, well, don't know, but I do not really see a reason to disallow magic methods. There are definitely use-case for something like __toString. Constructors are a complicated topic on its own. But in general, the initialization part might also be reusable. So, what would be your argument why they might be 'harmful'? Best regards Stefan -- Regards, Felipe Pena -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SVN Account Request: robertchu
Manage this group instead of Patrick Reilly. http://news.php.net/group.php?group=php.evangelism -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: robertchu
On Thu, May 6, 2010 at 23:04, Robert Chu robert@unit405.de wrote: Manage this group instead of Patrick Reilly. http://news.php.net/group.php?group=php.evangelism huh? You don't need SVN account to sign up to the mailinglist.. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: robertchu
Patrick Reilly prei...@php.net asked me to fill it out. He wants me to take over evangelism efforts. - Patrick On Thu, May 6, 2010 at 1:56 PM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Thu, May 6, 2010 at 23:04, Robert Chu robert@unit405.de wrote: Manage this group instead of Patrick Reilly. http://news.php.net/group.php?group=php.evangelism huh? You don't need SVN account to sign up to the mailinglist.. -Hannes
[PHP-DEV] PHP upgrade from 5.2.3 to 5.3.2
Hello php experts,
We are doing php upgrade from 5.2.3 to 5.3.2 (unix on Octeon/MIPS) and getting
a compilation error
* Issue with Octeon platform
o Round() API throws Maximum execution time exceeded error. Analyzed
the issue and Found the problem to be that mult function
(src/dist/php/Zend/zend_strtod.c) is being called indefinitely from pow5mult
function (src/dist/php/Zend/zend_strtod.c). It might be some problem with byte
alignment on this platform.
* We have filed a bug
o http://bugs.php.net/bug.php?id=51701 - Maximum execution time
exceeded error with round() API on octeon platform
Any idea about this
Here is a response from one of our platform developers after doing some analysis
In pow5mult():
for(;;) {
if (k 1) {
b1 = mult(b, p5);
Bfree(b);
b = b1;
}
if (!(k = 1)) {
break;
}
if (!(p51 = p5-next)) {
if (!(p51 = p5-next)) {
p51 = p5-next = mult(p5,p5);
p51-next = 0;
}
}
p5 = p51;
}
---
As it is suspected that mult is being called continuously from pow5mult: do we
know:
1. How b and p5 are changing over each iteration?
2. If the computation done by mult() in each of these iteration is correct
or not?
3. What is the impact of this computation on k?
4. The loop will break only with change in k but I don't see k changing
here in mult5pow().
Can anyone throw some light on this?
Thanks
