Re: [PHP-DEV] some notes about traits
On 16 November 2011 00:17, Rasmus Schultz ras...@mindplay.dk wrote:
Here's a better example of something useful that actually works:
trait Accessors
{
public function __get($name)
{
return $this-{'get'.$name}();
}
public function __set($name, $value)
{
$this-{'set'.$name}($value);
}
}
class OrderLine
{
use Accessors;
public $price;
public $amount;
public function getTotal()
{
return $this-price * $this-amount;
}
}
$line = new OrderLine;
$line-price = 20;
$line-amount = 3;
echo Total cost: .$line-total;
I like that example. It shows, at a fairly simple level, the ability
to compose a class from potentially multiple traits.
Putting the __magic_methods in a trait, what a great idea. This
mechanism is allows for all sorts of easy to expand ideas.
You _COULD_ use this trait to implement discrete getters and setters ...
?php
/**
* Trait to provide setter and getter functionality
* with an exception for any missing method.
*/
trait Accessors
{
public function __get($name)
{
if (method_exists($this, 'get' . $name))
{
return $this-{'get' . $name}();
}
elseif (property_exists($this, $name))
{
return $this-{$name};
}
else
{
throw new Exception(Cannot retrieve value of
'$name'.);
}
}
public function __set($name, $value)
{
if (method_exists($this, 'set' . $name))
{
$this-{'set' . $name}($value);
}
elseif (property_exists($this, $name))
{
$this-{$name} = $value;
}
else
{
throw new Exception(Cannot set value for '$name'.);
}
}
}
/**
* @property float $price
* @property float $amount
* @property float $tax
* @property-readonly float $total
*/
class OrderLine
{
use Accessors;
protected $price;
protected $amount;
protected $tax;
public function getTotal()
{
return $this-price * $this-amount * (1 + ($this-tax / 100));
}
protected function getPrice()
{
return $this-price;
}
protected function getAmount()
{
return $this-amount;
}
protected function setPrice($price)
{
$this-price = $price;
}
protected function setAmount($amount)
{
$this-amount = $amount;
}
}
$line = new OrderLine;
$line-price = 20;
$line-amount = 3;
$line-tax = 10;
echo Total cost: .$line-total;
?
outputs ...
Total cost : 66
So, the actual methods are hidden from public, but a developer can
extend the class to add additional processing.
Interestingly, I've used property_exists to expose public access to
protected properties. I suppose that is always possible. Bad design
really. I would guess you wouldn't mix the different access mechanisms
(public/protected/private, __get/__set, getter()/setter()).
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc : Fantasy Shopper
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea :
fan.sh/6/370
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pecl sqlite
Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] session_regenerate_id() not replacing Set-Cookie header
On Tue, 15 Nov 2011 23:51:25 +0100, Patrick ALLAERT wrote: As per rfc6265, it seems incorrect: Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. @mike Since you are the one who introduced the comment, you might be the best person to comment on this. If you set replace to 1 it would replace any Set-Cookie header, not necessarily the session cookie header. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session_regenerate_id() not replacing Set-Cookie header
On Wed, Nov 16, 2011 at 12:12 PM, Michael Wallner m...@php.net wrote: On Tue, 15 Nov 2011 23:51:25 +0100, Patrick ALLAERT wrote: As per rfc6265, it seems incorrect: Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. @mike Since you are the one who introduced the comment, you might be the best person to comment on this. If you set replace to 1 it would replace any Set-Cookie header, not necessarily the session cookie header. Mike if we fix that, I would like to see https://bugs.php.net/bug.php?id=38104(previously reported as https://bugs.php.net/bug.php?id=31455) fixed also. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] pecl sqlite
2011/11/16 Ferenc Kovacs tyr...@gmail.com: Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. It's not intentional, the text weren't updated. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] some notes about traits
Hi Rasmus: On 16 Nov 2011, at 01:17, Rasmus Schultz wrote: I knew about the traits features in Scala, and I guess I assumed this would be similar - not so. Right, they are not the same. PHP's traits are much closer to the notion of traits introduced in the Smalltalk world, while Scala's traits are rather like mixins as for instance in Ruby. Aside issues like typing and whether that type information is preserved, the main difference is that PHP's traits do not use implicit conflict resolution. I believe the key to understanding traits, is understanding that traits are in fact an implementation detail - an artifact that does not really change or affect the nature of OOP in PHP as such, and by design, should not. I understand that now - thank you :-) From my perspective, a key difference from classes and interfaces, is that traits have no meaningful use at run-time - no type-hinting and with no real reflection-features that reveal the details. They cannot implement interfaces for classes, but classes can use them to implement interfaces. Traits just provide a set of method implementations that can be aggregated by classes. So in a sense, they're a design-time tool for the programmer. I like that explanation, thanks! So I guess my remaining quibble is that the documentation needs to relay this somehow - with a basic real-world example that actually uses an interface too, to clarify the difference, and to demonstrate how this tool use useful in conjunction with class and interface declarations. Hello world really doesn't explain anything, other than the syntax. [...] This may be a little too magical for an example in the documentation though - and doesn't demonstrate interfaces. I'll ponder this and post a better example if I can think of one... :-) As someone else already pointed out, there are tools to contribute such nuggets to the documentation. Please submit a patch. And just one other comment: var_dump($test instanceof CartBehavior); // = false Why would it be beneficial to throw an exception here? CartBehavior is a trait, and not a class or interface. The instanceof operator has no meaning for traits - it always returns false. You could argue that false is the expected result - I would argue that the only reason this happens to work at all, is because traits internally are classes. Suppose you thought you were actually doing a meaningful type-check of some sort? If by mistake you put a trait-name where you meant to put the name of an interface or class, such an error could be very hard to spot. While I agree that it can be hard to spot, I would usually advocate for less intrusive alternatives. Hmmm, well, I could put in a warning in strict mode, I guess. But that would require a consistent handling within all the other APIs we got, too. Especially is_a is such a candidate. And changing is_a seems to be a non-trivial thing. So, I will need to look carefully at that. Would be great if you could file a bug report for that. I hope this feedback is useful :-) Yes it is. I think it is especially important that other people actually write down their understanding of the mechanism. Blog posts, mailing list posts, improved documentation, they are all important. Thanks Stefan -- 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
Re: [PHP-DEV] pecl sqlite
On Wed, Nov 16, 2011 at 12:53 PM, Felipe Pena felipe...@gmail.com wrote: 2011/11/16 Ferenc Kovacs tyr...@gmail.com: Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. It's not intentional, the text weren't updated. you mean the pecl package description? I can change it, but where should it point to? sqlite3? or simply unmaintained? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: [PECL-DEV] Re: [PHP-DEV] pecl sqlite
On Wed, 16 Nov 2011, Ferenc Kovacs wrote: On Wed, Nov 16, 2011 at 12:53 PM, Felipe Pena felipe...@gmail.com wrote: 2011/11/16 Ferenc Kovacs tyr...@gmail.com: Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. It's not intentional, the text weren't updated. you mean the pecl package description? I can change it, but where should it point to? sqlite3? or simply unmaintained? PDOSqlite? cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl sqlite
On Wed, 2011-11-16 at 13:35 +0100, Ferenc Kovacs wrote: On Wed, Nov 16, 2011 at 12:53 PM, Felipe Pena felipe...@gmail.com wrote: 2011/11/16 Ferenc Kovacs tyr...@gmail.com: Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. It's not intentional, the text weren't updated. 5.4 is not yet released so PHP core is still the primary source for that extension ;-) you mean the pecl package description? I can change it, but where should it point to? sqlite3? or simply unmaintained? I would go for unmaintained. SQLite2 isn't maintained upstream for a few years. People can get the code if they have need to migrate or such, but other than that ... there's no good and simple migration path to something else. SQLite3 uses different APIs, different storage format and has a slightly different SQL standard interpretation. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl sqlite
On Nov 16, 2011, at 5:34 AM, Johannes Schlüter wrote: On Wed, 2011-11-16 at 13:35 +0100, Ferenc Kovacs wrote: On Wed, Nov 16, 2011 at 12:53 PM, Felipe Pena felipe...@gmail.com wrote: 2011/11/16 Ferenc Kovacs tyr...@gmail.com: Hi. We moved the sqlite ext from core to pecl with 5.4, but the http://pecl.php.net/package/sqlite still advertises using ext/sqlite instead. Is that intentional? The problem is, that for 5.3, the prefered way to use the sqlite ext is to use the one bundled in core, however for 5.4 and trunk, you can only install it from pecl. Maybe we could supersed it with ext/sqlite3? As it is in the core since 5.3, so all supported branches has it.. It's not intentional, the text weren't updated. 5.4 is not yet released so PHP core is still the primary source for that extension ;-) you mean the pecl package description? I can change it, but where should it point to? sqlite3? or simply unmaintained? I would go for unmaintained. SQLite2 isn't maintained upstream for a few years. People can get the code if they have need to migrate or such, but other than that ... there's no good and simple migration path to something else. SQLite3 uses different APIs, different storage format and has a slightly different SQL standard interpretation. We need to make pecl/sqlite work with 5.4, as currently it does not. I forget the details (and the related patch) but did work on one with Johannes many months ago. The last step (which failed) was to get pdo_sqlite2 to work with the shared PECL variant, IIRC. Then, make a release. Moving something to PECL should require that the PECL extension work with the distribution that it was [re]moved from. Otherwise, it was not moved. Johannes probably assumed I adjusted/committed the patch, and made a pecl/sqlite release, but he forgot that I forgot to do this, and I have since lost said patch and progress and most memories. Sorry :] Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pecl sqlite
On Wed, 2011-11-16 at 06:00 -0800, Philip Olson wrote: We need to make pecl/sqlite work with 5.4, as currently it does not. I forget the details (and the related patch) but did work on one with Johannes many months ago. The last step (which failed) was to get pdo_sqlite2 to work with the shared PECL variant, IIRC. Then, make a release. Moving something to PECL should require that the PECL extension work with the distribution that it was [re]moved from. Otherwise, it was not moved. Johannes probably assumed I adjusted/committed the patch, and made a pecl/sqlite release, but he forgot that I forgot to do this, and I have since lost said patch and progress and most memories. Sorry :] Looking at the patch from that time: The thing which was to be fixed was enabling the sqlite2 PDO driver. For that the patch added an configure option. What we discussed, but not decide, was whether we'd force the PDO driver on the user or not. If we force it on the user the user also needs to have PDO loaded, even when not using the PDO API. johannes Index: config.m4 === --- config.m4 (revision 313356) +++ config.m4 (working copy) @@ -9,8 +9,8 @@ PHP_ARG_ENABLE(sqlite-utf8, whether to enable UTF-8 support in sqlite (default: ISO-8859-1), [ --enable-sqlite-utf8 SQLite: Enable UTF-8 support for SQLite], no, no) +PHP_ARG_ENABLE(pdo-sqlite2, whether to aditionally enable pdo_sqlite2 driver. Depends on sqlite, [ --enable-pdo-sqlite2 SQLite: whether to aditionally enable pdo_sqlite2 driver. Depends on sqlite], no, no) - dnl dnl PHP_PROG_LEMON dnl @@ -46,7 +46,7 @@ if test $PHP_SQLITE != no; then - if test $PHP_PDO != no; then + if test $PHP_PDO_SQLITE2 != no; then PHP_CHECK_PDO_INCLUDES([], [AC_MSG_WARN([Cannot find php_pdo_driver.h.])]) if test -n $pdo_inc_path; then AC_DEFINE([PHP_SQLITE2_HAVE_PDO], [1], [Have PDO]) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP CLI webserver test failures
Hi Laruence, Is there anyway to make the PHP CLI webserver tests more resilient? They are failing on gcov.php.net and are high on the list of user test reports: http://gcov.php.net/viewer.php?version=PHP_HEADfunc=tests http://qa.php.net/reports/?version=5.4.0RC2-dev Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
I'll try to help Laruence improve the test coverage. If you guys have any suggestion for test starting point, let me know. On Wed, Nov 16, 2011 at 5:41 PM, Christopher Jones christopher.jo...@oracle.com wrote: Hi Laruence, Is there anyway to make the PHP CLI webserver tests more resilient? They are failing on gcov.php.net and are high on the list of user test reports: http://gcov.php.net/viewer.**php?version=PHP_HEADfunc=**testshttp://gcov.php.net/viewer.php?version=PHP_HEADfunc=tests http://qa.php.net/reports/?**version=5.4.0RC2-devhttp://qa.php.net/reports/?version=5.4.0RC2-dev Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
\o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. On Wed, Nov 16, 2011 at 9:15 PM, Klaus Silveira klaussilve...@php.netwrote: I'll try to help Laruence improve the test coverage. If you guys have any suggestion for test starting point, let me know. On Wed, Nov 16, 2011 at 5:41 PM, Christopher Jones christopher.jo...@oracle.com wrote: Hi Laruence, Is there anyway to make the PHP CLI webserver tests more resilient? They are failing on gcov.php.net and are high on the list of user test reports: http://gcov.php.net/viewer.**php?version=PHP_HEADfunc=**tests http://gcov.php.net/viewer.php?version=PHP_HEADfunc=tests http://qa.php.net/reports/?**version=5.4.0RC2-dev http://qa.php.net/reports/?version=5.4.0RC2-dev Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP CLI webserver test failures
2011/11/17 Ferenc Kovacs tyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. Klaus, if you wanna help, you'd better to fix failing cli server tests before improving code coverage. On Wed, Nov 16, 2011 at 9:15 PM, Klaus Silveira klaussilve...@php.net wrote: I'll try to help Laruence improve the test coverage. If you guys have any suggestion for test starting point, let me know. On Wed, Nov 16, 2011 at 5:41 PM, Christopher Jones christopher.jo...@oracle.com wrote: Hi Laruence, Is there anyway to make the PHP CLI webserver tests more resilient? They are failing on gcov.php.net and are high on the list of user test reports: http://gcov.php.net/viewer.**php?version=PHP_HEADfunc=**testshttp://gcov.php.net/viewer.php?version=PHP_HEADfunc=tests http://qa.php.net/reports/?**version=5.4.0RC2-devhttp://qa.php.net/reports/?version=5.4.0RC2-dev Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
On Wed, Nov 16, 2011 at 9:31 PM, Alexey Shein con...@gmail.com wrote: 2011/11/17 Ferenc Kovacs tyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. I would be also interested that (for run-tests.php), so if you have anything ping me Did you check the wiki about that? There are ideas laying around there, and there were even a effort to rewrite run-tests.php: https://wiki.php.net/qa/runtests/documentation phpruntests seems to had a better OOPish architechture, and it seems that it supported parallel test execution. I think that it would be a good think to first document the current behavior, use cases, and create a decoupled toolchain for running the testsuite. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP CLI webserver test failures
2011/11/17 Ferenc Kovacs tyr...@gmail.com: On Wed, Nov 16, 2011 at 9:31 PM, Alexey Shein con...@gmail.com wrote: 2011/11/17 Ferenc Kovacs tyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. I would be also interested that (for run-tests.php), so if you have anything ping me Did you check the wiki about that? There are ideas laying around there, and there were even a effort to rewrite run-tests.php: https://wiki.php.net/qa/runtests/documentation Hm, nice catch, will definitely check that out. I was only refering to phpt spec here: http://qa.php.net/phpt_details.php phpruntests seems to had a better OOPish architechture, and it seems that it supported parallel test execution. Is there any code to see? Or just architecture in the wiki? I think that it would be a good think to first document the current behavior, use cases, and create a decoupled toolchain for running the testsuite. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
On Wed, Nov 16, 2011 at 10:09 PM, Alexey Shein con...@gmail.com wrote: 2011/11/17 Ferenc Kovacs tyr...@gmail.com: On Wed, Nov 16, 2011 at 9:31 PM, Alexey Shein con...@gmail.com wrote: 2011/11/17 Ferenc Kovacs tyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. I would be also interested that (for run-tests.php), so if you have anything ping me Did you check the wiki about that? There are ideas laying around there, and there were even a effort to rewrite run-tests.php: https://wiki.php.net/qa/runtests/documentation Hm, nice catch, will definitely check that out. I was only refering to phpt spec here: http://qa.php.net/phpt_details.php phpruntests seems to had a better OOPish architechture, and it seems that it supported parallel test execution. Is there any code to see? Or just architecture in the wiki? http://svn.php.net/viewvc/php/phpruntests/trunk/src/taskScheduler/ -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP CLI webserver test failures
On 11/16/2011 01:09 PM, Alexey Shein wrote: 2011/11/17 Ferenc Kovacstyr...@gmail.com: On Wed, Nov 16, 2011 at 9:31 PM, Alexey Sheincon...@gmail.com wrote: 2011/11/17 Ferenc Kovacstyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. I would be also interested that (for run-tests.php), so if you have anything ping me Did you check the wiki about that? There are ideas laying around there, and there were even a effort to rewrite run-tests.php: https://wiki.php.net/qa/runtests/documentation Hm, nice catch, will definitely check that out. I was only refering to phpt spec here: http://qa.php.net/phpt_details.php phpruntests seems to had a better OOPish architechture, and it seems that it supported parallel test execution. Is there any code to see? Or just architecture in the wiki? http://svn.php.net/viewvc/php/phpruntests/trunk/ For some background, there might be some posts on Zoe's blog e.g: http://zoomsplatter.blogspot.com/2009/07/on-no-not-more-tests.html Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
2011/11/17 Christopher Jones christopher.jo...@oracle.com: On 11/16/2011 01:09 PM, Alexey Shein wrote: 2011/11/17 Ferenc Kovacstyr...@gmail.com: On Wed, Nov 16, 2011 at 9:31 PM, Alexey Sheincon...@gmail.com wrote: 2011/11/17 Ferenc Kovacstyr...@gmail.com: \o/ You could also ask Alex Shein, he was volunteered to update the http tests to use our new embedded developer server instead. Hi, I'm still into that, but unfortunately is very busy at work :( server-tests.php is a big outdated mess, and I still want to write my own phpt parser from scratch. I would be also interested that (for run-tests.php), so if you have anything ping me Did you check the wiki about that? There are ideas laying around there, and there were even a effort to rewrite run-tests.php: https://wiki.php.net/qa/runtests/documentation Hm, nice catch, will definitely check that out. I was only refering to phpt spec here: http://qa.php.net/phpt_details.php phpruntests seems to had a better OOPish architechture, and it seems that it supported parallel test execution. Is there any code to see? Or just architecture in the wiki? http://svn.php.net/viewvc/php/phpruntests/trunk/ For some background, there might be some posts on Zoe's blog e.g: http://zoomsplatter.blogspot.com/2009/07/on-no-not-more-tests.html Thanks. Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP CLI webserver test failures
Hi: thanks, I will look at it, the cli sever test all failed in trunk, but parts in branch maybe due to the port competing. thanks On Thu, Nov 17, 2011 at 3:41 AM, Christopher Jones christopher.jo...@oracle.com wrote: Hi Laruence, Is there anyway to make the PHP CLI webserver tests more resilient? They are failing on gcov.php.net and are high on the list of user test reports: http://gcov.php.net/viewer.php?version=PHP_HEADfunc=tests http://qa.php.net/reports/?version=5.4.0RC2-dev Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] some notes about traits
who can hook me up with a login, so I can contribute to the documentation? Here's a better example of something useful that actually works: Assuming your example is OK, you could edit the doc and submit it as a patch at https://edit.php.net.
Re: [PHP-DEV] some notes about traits
On 11/16/11 6:12 PM, Rasmus Schultz wrote: who can hook me up with a login, so I can contribute to the documentation? You can do it as an anonymous user on edit.php.net. Join in the chat so you can prod someone to merge your changes - you might also need to remind the doc mail list. Once you've had a few patches committed you will likely get karma to commit directly. Chris Here's a better example of something useful that actually works: Assuming your example is OK, you could edit the doc and submit it as a patch at https://edit.php.net. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
